Before accepting an online ordering setup, require evidence that representative orders produce the agreed prices, reach the right people, and can be handled when something goes wrong. Agree on those checks with the vendor before the demonstration, not after it.
Acceptance is a decision about the vendor’s deliverable. It is different from a soft launch, which lets you observe how a system performs with real guests and staff. A successful demonstration does not prove that a busy Friday service will be trouble-free. It should, however, show that the setup meets the agreed requirements before you sign it off.
Choose baskets and fulfillment modes to check
Start with the menu and service rules you actually intend to launch. The owner or menu manager should supply current item prices, modifiers, availability, hours, pickup instructions, and delivery rules. The vendor should show how those decisions appear in the ordering flow and where the resulting order goes.
Pick enough baskets to cover meaningful differences, rather than checking the same simple order several times. Include:
- A single item for pickup, with no changes.
- An item with a required choice, such as a size or side.
- An item with an optional paid addition and a removed ingredient.
- A basket with multiple items and a special instruction.
- A delivery basket, if delivery is part of the agreed setup.
- An unavailable item or an order attempted outside the agreed hours.
For each basket, write down the inputs and expected result before anyone runs the check. Specify the fulfillment mode, address or pickup choice, item selections, and any relevant schedule. If you offer delivery, include an address inside the agreed area and one outside it. Agree on whether the latter should be blocked or handled another way.
Use a safe simulation or vendor-provided test environment. Confirm beforehand that it cannot charge a real card, send a guest message, or dispatch a courier. If a full end-to-end check needs a live service pilot, plan that separately with the people involved and do not treat it as a practice order. A simulation can show configured behavior, but it cannot establish how outside services will perform in live service.
The online ordering buying guide can help with the broader purchase. For acceptance, narrow the list to the functions, locations, and integrations included in your signed scope.
Set expected prices and notifications
A correct-looking menu is not enough. The guest, the restaurant, and any connected system need to see the right details at the right point. Agree on the expected basket total and on who receives each order notification. Ask the vendor to show both the guest-facing result and the restaurant-facing record.
For example, assume a pickup basket contains a $12 sandwich, a $2 paid addition, and a $4 drink. The expected item subtotal is $18. This example includes the paid addition but excludes tax, payment processing, delivery, and any other fees. Do not use $18 as the expected final charge if your agreed checkout adds any of those amounts; record the applicable amounts separately and calculate the complete expected total before testing.
The pass criterion is not merely that checkout displays a total. It is that the item choices and each applicable charge match the agreed menu and rules, and that the restaurant’s order record preserves the same details. Processing fees are an operating cost, not necessarily a guest-facing charge; check the quote and settlement records separately instead of adding an assumed processing fee to the basket.
For a notification check, name the recipient, channel, and trigger. For instance, if the agreement calls for an order alert at the restaurant, specify which device or account should receive it and what details staff need to identify and prepare the order. If a guest confirmation is included, agree on its content and timing. Review a simulated notification or preview without sending a real guest message.
Ask who can change menu prices and hours after handover, and whether changes require vendor help. A setup may pass the initial price check yet still leave an owner dependent on someone else for routine updates. Include a controlled update and reversal in the acceptance checks if self-service editing is part of the agreement.
Agree on failure and cancellation behavior
Owners need to know what staff should do when the normal order path stops. List the failures that matter to your operation and agree on the expected response for each. Depending on the scope, these might include a rejected payment, an unavailable item, a closed ordering window, a failed restaurant alert, or a cancellation request.
For a simulated rejected payment, a useful pass criterion is that the order is not presented to staff as paid and ready to prepare. Also agree on what the guest-facing screen should say and whether an unpaid order appears anywhere in the restaurant’s records. Use a test method that cannot create a real payment.
For cancellation, define the point at which staff can cancel, who is authorized to do it, and how the order status should appear afterward. If a payment has already been taken in live service, ask how a refund is initiated, who performs it, and how staff can confirm its status. Do not assume that canceling an order automatically refunds a payment or stops a courier; require the vendor to explain the actual workflow.
If delivery is included, ask who contacts or stops the delivery provider when an order is canceled. In a simulation, inspect the expected status or a safe test response without creating a real dispatch. If an alert fails, agree on the backup procedure: for example, who checks the order screen and how often during service. The vendor should distinguish a built-in alert from a manual staff procedure.
These checks reveal whether the documented workflow is understandable and behaves as agreed in the test conditions. They cannot prove every outage, refund, or delivery exception will resolve as expected in live service. Record any untested dependency and decide whether it prevents acceptance or needs a separately scheduled pilot.
Record evidence, issues, and the acceptance decision
Use one shared checklist with a named restaurant owner for each decision and a vendor contact responsible for corrections. The table below is a starting point. Replace its examples with your agreed scope, expected results, and evidence locations before testing.
| Check | Pass criterion | Evidence to retain | Decision owner |
|---|---|---|---|
| Representative pickup basket | Selections and calculated charges match the approved menu and checkout rules | Basket inputs, expected total, and order record or screenshots | Menu manager |
| Delivery eligibility, if included | Inside and outside addresses receive the agreed responses | Test addresses, expected results, and observed screens | Owner |
| Restaurant order alert | The agreed recipient can identify the order and its preparation details in the safe test | Alert preview or test record and recipient confirmation | Shift lead |
| Rejected payment | The simulated failure does not show the order as paid and ready to prepare | Test method, guest-facing result, and restaurant order status | Owner |
| Cancellation workflow | Authorized staff can follow the agreed steps and identify the resulting status | Steps, status record, and documented refund and delivery responsibilities | Owner |
For every failed check, log the inputs, expected result, actual result, date, and person responsible for the fix. Add a target date and the same retest steps. A vague note such as “notifications are unreliable” is harder to resolve than “the agreed restaurant alert did not appear in the test account for basket 3.”
Set the decision rule in advance. One practical rule is to withhold acceptance while any agreed launch-critical check fails. A minor display issue might be accepted as an exception if the owner understands the consequence and the vendor records a correction date. Do not call a failed check a pass simply because a workaround exists; document the workaround and decide explicitly whether it is acceptable.
Keep the final record with the setup agreement: checklist version, evidence, open issues, exceptions, acceptance date, and the names of the people approving it. If the agreement makes sign-off affect payment or other obligations, review those terms with a qualified adviser when needed.
Use this checklist on your current setup, then ask Fleksa about restaurant online ordering and verified US availability if it is relevant to your search. If the ordering flow will sit on a restaurant website, include the path from the website to checkout in the agreed checks.
Frequently asked questions
What evidence is enough to accept an ordering setup?
Keep the agreed test inputs and expected results alongside screenshots, order records, or other evidence of the observed results. The responsible restaurant owner should confirm each pass and explicitly approve any open exception.
Should a soft launch replace vendor acceptance?
No. Acceptance checks the agreed deliverable against defined criteria. A soft launch observes live operation with real guests and staff. Plan both when appropriate, with separate decisions and safeguards.
Can an owner accept a setup with open issues?
Yes, if the agreement permits it and the owner knowingly accepts the remaining risk. Record each exception, its operational effect, the responsible person, and the target correction date. Launch-critical failures should follow the decision rule agreed before testing.
