Before signing with an online ordering provider, ask to see your menu, your service rules, and your busiest shift represented in the demonstration. Test a difficult basket, a pickup or delivery choice, and at least one failure and recovery scenario. Then compare what worked with what the provider has actually included in its written quote.
The goal is not to make a demo fail. It is to find out what your staff and guests will have to do when an order is complicated, a change comes in, or something stops working. Set pass criteria before the meeting so a smooth presentation does not substitute for an answer.
If you are still deciding which features belong on your shortlist, start with the online ordering buying guide. The steps below are for the next stage: demonstrating the details that matter at your restaurant.
Prepare a representative menu and service schedule
Give each shortlisted provider the same small test pack. You do not need to build the entire menu before the demo. You do need enough detail to expose rules that a simple burger-and-fries example would miss.
Ask the person who maintains your menu to supply a few real items, prices, modifiers, and availability rules. Include a required choice, an optional paid extra, an item with limited availability, and an instruction the kitchen must see. Have the shift manager add the pickup and delivery hours, preparation-time assumptions, and any periods when the restaurant stops accepting orders.
Also identify who will receive orders during service and where they need to see them. A counter team working from one screen has different needs from a kitchen and front counter using separate devices. Bring a staff member from each affected area to the demonstration, or collect their questions beforehand.
Send providers the test pack in advance, but do not send them a preferred answer to every step. Ask them to prepare a simulated environment and explain which parts use your actual setup and which are mock-ups. Confirm who enters the menu, who checks it, and what work would remain after signing. If setup assistance is offered, ask where it ends and what it costs.
Pass criteria: The sample items and rules are represented accurately; the people receiving orders can identify what they need to do; and any manual setup work has a named owner. A provider can still be worth considering if a rule needs a workaround, but write down the extra steps rather than treating the rule as automated.
Test a complex basket and fulfillment choice
Run the same basket from the guest view through to the staff view. The following example is hypothetical; use your own items and prices if they expose a more important service problem.
A guest selects two bowls at $12 each, adds one $2 protein extra, and chooses a required side for each bowl. One bowl has a preparation note. The food subtotal should be $26. The guest then selects delivery with an assumed $5 delivery charge, making the displayed total $31 before any other charges or applicable tax. The $5 is a guest charge in this example, not proof of the restaurant's courier cost or the provider's fee.
Ask the demonstrator to show the choices and note in the basket before checkout, then show exactly how the same order appears to the team. Can staff tell which bowl gets the extra and which gets the note? Is the required side attached to the correct item? If the guest changes one bowl, does the updated basket still make sense?
Next, switch to pickup and check the available time choices against the schedule you supplied. Then try a delivery address that should be outside your intended area. Ask how the system handles an unavailable fulfillment choice, and what the guest sees. If your restaurant uses scheduled orders, ask to see an order placed for a later service period as well as one for the next available time.
Finally, ask what happens when an item sells out during a shift. Who can make it unavailable, how quickly does that change appear to guests, and what happens to an order already submitted? Do not assume an unavailable-item control also changes inventory elsewhere. Ask the provider to demonstrate the actual workflow and name any separate tools or staff steps involved.
Pass criteria: The basket preserves item-level choices, the total is understandable, fulfillment choices match the agreed rules, and staff can read the submitted order without guessing. If a step depends on an integration, ask which connection is required, whether it is included in the quote, and who supports it.
Ask about failure and recovery scenarios
A normal order is only part of the job. Ask the provider to walk through interruptions using simulated orders and staff actions. Confirm before the demonstration that the practice environment will not take a real card payment, send a guest message, or dispatch a courier.
An order needs attention
Have the demonstrator show what happens if the restaurant cannot fulfill a submitted item. Ask who sees the issue, whether staff can change or cancel the order, and how the guest is informed. If a refund is part of the workflow, ask where staff initiate it and how its status is tracked. A simulated explanation is enough for the demo; do not run a real payment to test it.
The pass criterion is a clear sequence from problem to resolution, including who contacts the guest and who approves any refund. Record any step that requires a phone call, another dashboard, or provider support.
The restaurant loses a connection or device
Ask what the guest sees if an order cannot reach the restaurant, and how staff know that something is wrong. Then ask how the team identifies orders that need attention after the connection or device is restored. Have the provider explain what is retained, what must be checked manually, and whether any payment has been authorized or captured at each stage.
Do not accept a general promise that the system works offline as a substitute for this walkthrough. Your pass criterion might be that the manager can describe the recovery steps and identify who to call without relying on a guest to report the problem. If the provider cannot demonstrate a step, document the answer and any remaining question for the quote or contract discussion.
A delivery handoff goes wrong
Ask who handles a delivery that is delayed, rejected, or assigned incorrectly. The answer may involve the restaurant, an ordering provider, a dispatch service, or a courier. Request a step-by-step account of where staff see the status and whom they contact. Do not trigger a real dispatch during practice.
Be clear about the limit of a demonstration: a staged screen can show a workflow, but it cannot prove how a service will perform on a busy Friday. If you later arrange a live service pilot, define its scope and get agreement from everyone involved. Live orders, payments, guest communications, and delivery dispatches require a separate, deliberate plan; they are not part of the simulated checks above.
Score the demonstration against the written quote
Use a scorecard immediately after each demo, while the details are fresh. The table gives a practical starting point. Mark each row pass, pass with a documented workaround, or unresolved. Add the name or role responsible for the next action; do not average a serious unresolved issue away with several easy passes.
| Scenario | Pass evidence | Quote or follow-up check |
|---|---|---|
| Menu and setup | Required choices, prices, and availability match the test pack. | Who enters and checks the menu, and is that work included? |
| Basket and fulfillment | Item choices reach staff clearly; pickup and delivery rules behave as agreed. | List any required integrations, configuration, or extra charges. |
| Interruption | Staff can explain how to identify affected orders and recover. | Confirm support access, responsibilities, and any limits in writing. |
| Change or cancellation | The team can follow the guest-contact and refund steps in a simulation. | Identify which party handles each step and which costs may apply. |
For example, a provider might pass the basket test but need a manual call to handle a delivery problem. That is a pass with a workaround only if your team can realistically make the call during service and the provider confirms who accepts it. If nobody can identify the contact or the hours of support, leave the row unresolved.
Compare the scorecard with an itemized quote for the same location and expected operating setup. Ask for recurring subscription charges, setup, hardware or add-ons, payment processing, delivery or dispatch charges, and any other applicable costs to be separated. Also ask which features, support arrangements, and integrations shown in the demo are included. A guest delivery charge, the restaurant's delivery expense, payment fees, and food sales are different figures; do not treat one as a substitute for another.
Use your own expected order volume to compare operational quote totals, and note what each estimate excludes. Ask who pays each delivery charge and whether a guest charge offsets any restaurant expense. The guide to remaining direct delivery costs can help you frame those questions. Ask a qualified adviser about contract, legal, or tax treatment when needed.
Before choosing, send the provider your unresolved rows and request written answers alongside the final quote. If an important workflow depends on a future change, ask for the commitment and timing in writing rather than counting it as a present-day pass.
Put the checklist to work
Run the same scenarios against your current setup first. Note where staff improvise and where guests may get stuck, then use those findings to brief vendors. When you are ready, ask Fleksa about restaurant online ordering, verify availability for your US location, and request a demonstration using your checklist.
Frequently asked questions
How much of my menu should I provide for a demo?
Provide a small but representative sample: items with required choices, paid extras, preparation notes, and availability restrictions. Add enough schedule detail to test your real pickup and delivery rules.
Should a provider pass every scenario?
It should meet your essential criteria or offer a workaround your team can operate. Record unresolved issues and extra work, then decide whether the written quote and support terms make the trade-off acceptable.
Can a demo prove the system will work during a busy shift?
No. A simulation shows workflows and exposes questions, but it does not establish live service performance. If you arrange a live pilot, plan its orders, payments, guest communications, and delivery activity separately.
