To test an optional add-on responsibly, show one relevant offer to some guests, leave a comparable group’s checkout unchanged, and measure both contribution and checkout friction. Set a stopping rule before the test begins. If the offer makes more money per checkout visitor but causes too many errors or abandoned checkouts, fix or remove it.
Keep the choice genuinely optional. A guest who wants only the original meal should be able to continue without answering an extra question or hunting for a decline button. This is different from a required modifier, such as choosing how a burger is cooked.
Choose one relevant offer and set exclusions
Start with an add-on that makes sense beside a specific item. A sauce with a sandwich is easier to understand than a generic promotion shown to every guest. Pick one offer for the first test so the result is easier to interpret and the kitchen can spot problems.
Ask the people closest to the work for the inputs:
- Kitchen lead: Is the add-on available, easy to pack, and clearly named on the order? Are there combinations that should not receive the offer?
- Manager: What is the selling price, and what are the incremental ingredient and packaging costs? Would the offer create extra work during a rush?
- Ordering-system provider: Can the offer be shown only with the intended item, skipped easily, and measured against a comparable control? How are selections displayed to staff?
- Front-of-house or support staff: What guest complaints or correction requests should count as an offer-related error?
Write down exclusions before launch. For example, do not offer the same sauce twice if it is already included in the selected meal. Remove the offer when the item is unavailable. Consider whether the kitchen can fulfill it during every service period in the test; if not, limit both comparison groups to the same eligible periods.
Check the language on the guest screen and the kitchen ticket. The price should be visible before selection, and the add-on should not be preselected. A clear decline or continue option helps guests understand that their meal is complete without it.
Set a control and choose the primary outcome
The cleanest comparison assigns eligible checkout visitors to two groups at the same time. The control sees the usual checkout. The test group sees the optional offer. Both groups should otherwise see the same prices, ordering steps, service hours, and eligibility rules.
Ask your provider whether it can assign groups consistently and report results separately. If it cannot, alternating comparable service periods may be a practical fallback, but the result is less certain: weather, promotions, staffing, and demand can change between periods. Record those differences rather than treating them as effects of the offer.
Use contribution per eligible checkout start as the primary outcome. Divide the contribution from completed orders in each group by the number of eligible visitors who started checkout in that group. This puts the value of add-ons and the cost of abandoned checkouts in the same comparison.
Define a checkout start consistently before collecting data. For example, it could be the point where an eligible guest opens the checkout page. Count each group using the same definition, including visitors who do not finish. If guests can return or switch devices, ask how the system counts them and note the limitation.
Also track add-on selection rate and average completed-order value. They explain what happened, but neither is enough to declare success. A higher basket among completed orders can hide the loss of guests who left before paying.
Choose a test window in advance that covers the service periods you want represented. Avoid ending it just because the first few orders look promising. Small groups can swing sharply, so treat a short or uneven result as a reason to gather more evidence, not as proof.
Calculate contribution, not just basket size
The following example is hypothetical. It uses two groups of 100 eligible checkout starts. Assume each completed order contributes $8 before the add-on. The add-on sells for $3 and has $1 in incremental ingredient and packaging costs, leaving $2 per add-on. The test group sells 20 add-ons.
In the control, 80 guests complete an order. Contribution is 80 × $8, or $640. In the test group, 78 guests complete an order. Base-order contribution is 78 × $8, or $624; add-ons contribute another 20 × $2, or $40. Total contribution is $664.
That is $6.40 per checkout start for the control and $6.64 for the test group. The test group’s completed-order value may also be higher, but the $24 contribution difference is the more useful comparison because it includes the two fewer completed orders.
This simplified calculation includes the assumed variable costs already reflected in the $8 base contribution and the add-on’s ingredient and packaging costs. It excludes fixed costs, such as rent and subscriptions. Assume no additional variable processing, labor, or other costs from the offer and no exception costs, such as refunds or remakes. For a real decision, include those costs where they differ between groups; otherwise the apparent gain may shrink or disappear.
Use actual order-level costs where practical. If the add-on replaces something a guest would otherwise have bought, include that lost contribution too. A substitute is not necessarily an incremental sale. The contribution comparison guide has more detail on separating sales from the costs of fulfilling them.
The example is not a forecast, and 100 starts per group is not a reliable universal sample size. Even a positive contribution result needs to pass the operating guardrails below.
Use an experiment card and stop for friction
Put the offer, measures, and stop rules on one page before launch. The card below uses the same hypothetical sauce test. Its thresholds are management choices for this example, not industry standards.
| Decision | Control | Offer group | Action or limit |
|---|---|---|---|
| Eligible guest | Sandwich checkout; usual flow | Same eligibility; optional $3 sauce | Exclude meals that already include the sauce |
| Primary outcome | $6.40 contribution per start | $6.64 contribution per start | Compare after accounting for differing costs |
| Abandonment | 20 of 100 starts: 20% | 22 of 100 starts: 22% | Pause if the offer group is more than 3 percentage points higher |
| Offer-related errors | 1 of 80 completed orders: 1.25% | 4 of 78 completed orders: about 5.1% | Pause if the offer group is more than 2 percentage points higher |
In this example, abandonment is 2 percentage points higher in the offer group, below the stated pause threshold. Errors are about 3.9 points higher, above their threshold. Pause the offer despite the $24 contribution advantage. Review the four affected orders for issues such as a confusing ticket label or a missing item, correct the cause, and set up a fresh comparison before deciding whether to keep the offer.
Define an error before the test, including how staff will attribute it to the offer. Count affected completed orders once for the rate, even if an order has more than one related issue. Review complaints and refunds as well as kitchen records. If the data cannot distinguish an offer-related error from an unrelated problem, investigate the affected orders rather than forcing a precise rate.
Assign someone to check the card during service and someone with authority to pause the offer. A serious menu or fulfillment problem can justify stopping immediately, even before a numerical threshold is reached. Record the change and the time it happened so the results remain interpretable.
Check the guest and kitchen flow before launch
Run a simulated check before any live service pilot. Use a demo or test environment to confirm that the offer appears only for eligible items, shows the correct price, can be skipped, and reaches the kitchen in understandable language when selected. Confirm that removing the main item also handles the add-on as intended. Do not send a real payment, guest message, or courier dispatch during practice.
If a safe test environment is unavailable, ask the provider to demonstrate the flow without triggering those real-world actions. Do not assume a screen preview proves that the kitchen ticket, reporting, or availability rules work.
A live pilot is different: real guests place real orders, and staff fulfill them. Start only after the simulation and staff briefing. During the pilot, monitor the agreed measures and give the kitchen a direct way to report problems. Check whether the system can turn the offer off promptly without disrupting the rest of the menu.
If the current setup cannot separate control and offer groups, report checkout starts, or identify add-on selections, ask what can be exported and what staff would need to record manually. That limitation may make a small, time-based comparison the practical choice, but it should also lower confidence in the result. The online ordering buying guide can help frame those reporting questions.
Use the card to assess your current flow, then ask Fleksa about restaurant online ordering, the measurement and offer controls you need, and verified availability in the US.
Frequently asked questions
Should an optional add-on be selected by default?
For this test, leave it unselected. A guest should be able to see the price, choose the add-on deliberately, and continue without it.
Is a higher average order value enough to keep the offer?
No. Compare contribution per eligible checkout start and check abandonment and order errors. A larger average completed order can coexist with fewer completed orders or higher fulfillment costs.
What if my ordering system cannot run a split test?
Ask about reporting and use comparable alternating service periods if necessary. Keep the rules consistent, record outside changes, and treat the comparison as less certain than simultaneous assignment.
