Start with a small group of items that represents how your restaurant actually takes and prepares orders. Include a straightforward favorite, an item with required choices, one with optional extras, and a combination or other more complicated item. Leave out dishes the team cannot reliably price, prepare or pack during the pilot.
The goal is to test the ordering path as well as the food. A short menu can reveal whether guests understand their choices, whether the kitchen receives usable instructions, and whether staff can handle an unavailable item. It does not need to represent every category on day one.
Choose items that test different order paths
Make a list of the actions an online guest needs to take. Can they select a size? Must they choose a side? Can they remove an ingredient or add a paid extra? Choose dishes that cover those actions without adding several items that all test the same thing.
For a hypothetical neighborhood sandwich shop, a useful first set might be a standard sandwich, a sandwich with a required bread choice, a sandwich with a paid cheese add-on, and a meal with a required side. The shop could add a bottled drink if it wants to check a separate, ready-to-pack item. These are examples of order paths, not a recommended menu size for every restaurant.
Include a popular item only if the team can fulfill it consistently in the pilot window. A popular dish with frequent substitutions may deserve a later launch. A less popular dish can be useful early if it exposes an important choice that no other item covers.
Ask the people closest to each part of service for input:
- Owner or manager: Decide the pilot hours, order capacity and prices, and identify the person who can pause the channel.
- Kitchen lead: Flag preparation steps, common substitutions and choices that need to appear clearly on the order.
- Front-of-house or packing lead: Check item names, handoff instructions, packaging and likely guest questions.
- Person setting up the menu: Confirm how items, required choices, extras, hours and unavailable items can be configured.
Use the same names and descriptions staff recognize. If a guest orders “house special” but the kitchen calls it something else, agree on a clear name before launch. A short description should identify the main ingredients and the choices the guest must make; it should not require the guest to guess what comes with the dish.
Confirm availability and pricing before publishing
For every candidate, check that the ingredients, packaging and staff time are available throughout the proposed ordering window. An item served only after 5 p.m. should not appear available at lunch unless the ordering setup can enforce that restriction. Ask how to pause one item without closing the whole menu, and decide who has permission to do it.
Then compare the online price and options with the restaurant's intended offer. Check each required choice, paid extra and combination price. If a side is included in a meal, the guest should not be charged for it again unless a particular upgrade has a stated extra price. Ask how the system displays an unavailable choice and whether a guest can still complete the rest of an order.
Consider a separate hypothetical price check: a sandwich is $10, a cheese add-on is $2, and a drink is $3. Selecting all three should produce an item subtotal of $15. That subtotal includes the sandwich, cheese and drink only. It excludes any delivery charge, payment processing cost, tax and other operating costs. Confirm those amounts separately rather than treating the menu subtotal as the restaurant's profit.
Review the guest-facing total as well as the kitchen-facing order. The guest needs to see what is being charged; the kitchen needs to see the actual choices. If either view is confusing, revise the item before it enters the pilot.
A higher online price may help cover channel costs, but it can also change what guests choose. Compare the full operating costs and the guest's total before setting a price. The direct-order contribution guide offers a framework for that comparison. For this launch decision, the immediate question is simpler: can staff explain and fulfill every price and choice shown?
Run a controlled pilot without disrupting service
Set a narrow pilot window that the team can support, such as a normally quieter service period. Choose a manageable order limit based on actual staffing and kitchen capacity. Tell staff who watches incoming orders, who packs them and who can stop taking new orders if the kitchen falls behind. A limit is useful only if someone is responsible for enforcing it.
Before inviting guests, run simulated checks with staff. Use a practice or sandbox method that does not create a real card payment, send a guest message or dispatch a courier. Ask the provider how to do this safely; if the setup cannot support it, walk through the order screens and a printed or handwritten kitchen ticket instead.
For the sandwich shop example, have one person act as the guest and another check the kitchen instructions. Simulate the meal with its required side, then repeat with the cheese add-on. Check the following:
- The required choice is clear, and an incomplete selection cannot be mistaken for a complete order.
- The displayed item subtotal matches the selections.
- The kitchen can identify the item, side and paid extra without asking the guest to interpret the ticket.
- The packing lead can match the prepared food to the intended pickup or delivery handoff.
- Staff know how to mark an item unavailable and what happens to an order already received.
Record the result as pass, fix or retest. A simulation checks the setup and the team's understanding; it does not prove the process will hold up during a busy service. Once the checks pass, a live pilot with real guests can expose timing and workload problems. Keep it small, monitor it, and be ready to pause rather than assume every order will flow correctly.
Agree on what to do when something goes wrong. If an ingredient runs out after an order arrives, assign a staff member to contact the guest through an appropriate real-service process and resolve the order. Do not use real guest contact as part of practice. Ask the provider how cancellations and refunds are handled before they are needed.
Score candidates, then expand in small batches
Use this launch-menu scorecard to compare candidates. Give one point for each condition met: the item is reliably available during pilot hours; its price and choices are clear; the kitchen can execute and identify it; and it tests a useful ordering path not already covered. A score is a prompt for discussion, not an automatic decision.
The hypothetical sandwich shop has the following candidates. The scores reflect the assumptions in the table, not measured results.
| Candidate | Score out of 4 | Reason | Decision |
|---|---|---|---|
| Standard sandwich | 4 | Available, clearly priced and easy to identify; tests a basic order. | Include. |
| Sandwich with paid cheese | 4 | Available and clear; tests an extra charge and kitchen instruction. | Include. |
| Meal with required side | 4 | Available and clear; tests a required choice and packing. | Include. |
| Special with changing ingredients | 2 | Tests a different item and the kitchen can identify it, but availability and description change. | Hold until the recipe and availability are stable. |
The required bread-choice sandwich from the earlier example can be assessed the same way. Include it if the choice adds useful coverage and staff can fulfill it consistently. If another selected item already tests the same choice, it may be reasonable to wait. The scorecard helps keep a menu small without leaving an important order path untested.
After the live pilot, review problems with the people who handled them. Before adding a batch, set acceptance criteria: prices and choices are correct, the kitchen can read the order, packing matches it, and staff can manage availability within the agreed capacity. Fix and retest failures before adding more complexity. If service timing is the problem, change the window or capacity before expanding.
Add the next items by the new behavior they test, not simply by menu order. For example, add a dish with two required choices only after the team handles one required choice reliably. Review its availability and price, simulate its order path safely, then watch it during a limited live period. Keep a short log of the decision and any unresolved issue so the next shift knows what changed.
If you are still comparing software, use the online ordering buying guide to frame the wider decision, and check how the menu will appear on your restaurant website. Then use the scorecard on your current setup and ask Fleksa about its restaurant online ordering and verified US availability for your location.
Frequently asked questions
How many items should be on a launch menu?
There is no universal number. Include enough items to cover your important order paths while staying within the team's preparation, packing and monitoring capacity. Add more only after the first group meets your acceptance criteria.
Should the launch menu include a complicated item?
Yes, if it tests an important choice and the team can fulfill it reliably. A meal with a required side, for example, can reveal problems that a simple item cannot. Hold complex items whose prices or availability are not settled.
When is the menu ready to expand?
Expand after simulated checks pass and the limited live pilot shows that staff can handle orders within the agreed capacity. Correct pricing, kitchen-ticket, availability or handoff problems first, then introduce the next items in a small batch.
