The best test baskets cover more than one possible mistake without trying every menu combination. Start with a plain item, an item with required and optional choices, and a basket that combines a modifier with delivery and a discount. Add scheduled orders and an invalid selection. Together, these reveal whether the menu, fulfillment choices and displayed totals match your intended setup.
Choose the baskets before you start clicking. Write down what each order should contain and cost, then compare that record with the simulated result. This is a way to select representative orders, not a substitute for agreeing on formal launch acceptance criteria with your provider.
Start with the menu choices guests actually make
Ask the person who maintains the menu for the current item list, prices, modifier rules and availability. Have a shift lead identify common changes and awkward orders: an added topping, a required side, an excluded ingredient or a choice with a quantity limit. The person responsible for your website can explain how guests will find those items and move to checkout.
Build a short list around the points where an order can change:
- A plain item: one available item with no modifiers. This gives you a baseline for the item name, price and pickup flow.
- A required choice: an item where the guest must choose a size, side or preparation. Try selecting one, and separately try continuing without it.
- An optional paid choice: add a topping or extra and check that its price appears once, on the right item.
- A restriction: try an unavailable item or a choice above the permitted limit. Record what the guest should see instead of assuming the basket will be accepted.
- Two similar items: order two of the same item but customize only one. The kitchen should be able to tell which is which.
Prioritize choices that change the kitchen ticket or the total. A rare combination can wait if it behaves like a common one, but a popular allergy-related request deserves careful attention. Check how the request is displayed to staff; an order note alone does not establish that an item is safe for a guest.
If you are still comparing systems, the online ordering buying guide can help frame the wider purchase. For basket selection, stay focused on the actual menu and rules you plan to launch.
Cover pickup, delivery and scheduled orders
A correct basket also needs to reach the right place at the right time. Ask the manager for pickup hours, delivery boundaries, lead times and any scheduling cutoffs. If a delivery partner or dispatch service is involved, ask who defines its coverage and charges. Do not assume that a provider of ordering software supplies couriers.
Choose an immediate pickup order as your baseline. Then select a scheduled pickup near a meaningful boundary, such as the first available pickup period or the last time the kitchen accepts orders. Write the expected date and time in the restaurant's local time. Check that the guest-facing confirmation and the staff view describe the same fulfillment time.
If you offer delivery, use one address inside the intended area and another outside it in a safe simulation. The inside-address basket should show the expected fulfillment method and any guest-facing charge. For the outside address, decide what should happen: for example, the guest may need to choose pickup instead. Also ask how an address near the boundary is handled and how staff are alerted when delivery is unavailable.
Include a scheduled delivery only if you intend to offer it. A small set of distinct baskets is more useful than testing every time slot with the same plain item. Change one meaningful condition at a time when diagnosing a problem, then run a combined basket to see how choices interact.
Keep practice separate from service. Use a sandbox or another agreed simulation method that cannot take a real card payment, send a guest message or dispatch a courier. Ask the provider how to verify those safeguards before entering test details. A later live service pilot is a separate exercise: plan its timing, staffing and stop procedure rather than treating a simulated checkout as proof of live operations.
Choose fee and discount combinations deliberately
Ask the person who sets prices for the guest-facing delivery fee, discount rules and any other charges you intend to use. Confirm whether a discount applies to an item, a subtotal or another amount, and whether it has eligibility conditions. Have the appropriate qualified adviser help with tax treatment where needed; the test should use the amounts your restaurant expects to show, not an assumed universal tax rule.
At minimum, select one basket without a discount and one eligible discounted basket. If a promotion has a minimum spend, choose a basket just below that threshold and another that meets it. If the ordering flow accepts promotion codes, also try an invalid or expired code and record the expected response. An invalid code should not quietly produce the same total as an eligible one.
Delivery fees and payment processing fees are different. A delivery charge may appear in the guest's order total; a processing fee may instead appear in the restaurant's settlement or bill. A guest total is not the restaurant's all-in operating cost. If you want to reconcile the latter, obtain the relevant processing, delivery and other quotes separately.
Also decide which exception is worth a basket of its own. Examples include an item becoming unavailable, a delivery address outside the service area or a discount that no longer qualifies after an item is removed. Record the expected message and whether the guest can proceed. Do not assign an expected payable total to an order that should be stopped.
Record expected totals in cents before testing
The following matrix is a hypothetical selection for one restaurant. The amounts are assumptions for practice, not Fleksa prices or tax guidance. Each row is a separate basket. The assumed tax amounts are provided for the example; your own expected amounts must come from your setup and applicable treatment.
For these guest totals, item prices and the stated delivery charge are fixed assumptions. The paid modifier and discount vary by basket; the listed tax is included. No exception charge is assumed, and an invalid basket has no payable total. Processing fees and the restaurant's other operating costs are excluded.
| Basket | Selections | Expected calculation in cents | What to check |
|---|---|---|---|
| Plain pickup | One item; immediate pickup | 900 item + 72 tax = 972 | Baseline item and total |
| Scheduled pickup | 1,200-cent item with a 150-cent extra | 1,200 + 150 + 108 tax = 1,458 | Extra appears once; scheduled time is clear |
| Discounted delivery | 1,200-cent item, 150-cent extra, 300-cent delivery charge and eligible 200-cent discount | 1,200 + 150 + 300 − 200 + 115 tax = 1,565 | Charge and discount appear correctly; address is in area |
| Missing required choice | Item requiring a side; no side selected | No payable total expected | Guest is prompted to make the required choice |
The table gives you a baseline, two changing price paths and one blocked path. Adapt the rows to your menu rather than copying the numbers. Add a threshold or out-of-area row if that rule is important to your launch. For each accepted basket, write down the item subtotal, every adjustment, tax and final total as separate integers in cents. This makes a one-cent discrepancy visible and avoids mistaking a formatting difference for a different amount.
Keep the expected result beside the observed result, not in your head. Note the basket, date, fulfillment method, expected and displayed totals, and what staff would receive. If something differs, save the steps and ask whether the issue is a menu setting, a rule or a product limitation. Correct the setup and repeat that basket; then repeat the combined basket if the change could affect it.
Before launch, use these selections to review your current setup with the people who own the menu and service rules. Then ask Fleksa about restaurant online ordering and verified US availability for the setup you need. If your ordering flow starts on your site, also review how it connects with your restaurant website.
Frequently asked questions
How many test baskets should a restaurant use?
Start with a plain order, a customized order, a delivery or scheduled order, and a blocked order. Add baskets for important rules such as discount thresholds or delivery boundaries. The right count depends on the choices your guests will actually see.
Should every basket use a different menu item?
No. Reusing an item can make it easier to isolate the effect of a modifier, fee or discount. Include enough different items to cover distinct menu rules and kitchen instructions.
Can a simulated basket prove a live launch will work?
No. A simulation can reveal setup problems without taking payment, messaging a guest or dispatching a courier. Plan any live service pilot separately, with staff ready to monitor orders and stop if needed.
