Choose menu-based add-ons when the extra belongs to a particular item, such as avocado on a sandwich or a sauce for wings. Choose basket-based add-ons when the offer makes sense for the order as a whole, such as a bottled drink or a shared side. Many restaurants need both, but not every item needs an offer.
The right structure depends on three practical questions: Can the guest tell what they are buying? Can the kitchen tell where it belongs? And can the restaurant fulfill it without slowing down the rest of the order? Start with those questions before deciding where an offer appears on screen.
Map item-specific and shared add-ons
A menu-based add-on is attached to a particular item. A guest ordering two burgers might add cheese to one and bacon to the other. The selection needs to stay with the correct burger all the way through preparation and packing.
A basket-based add-on is offered for the overall order. A bottled soda, a tub of sauce, or a family-size side may not need to belong to one entrée. The order still needs to show the quantity and price clearly, but staff can generally pack the extra separately.
Do not confuse the structure with screen placement. A system may present an item-specific choice while a guest builds an entrée, and a shared offer later in checkout. The buying decision here is how the extra relates to the order and how that relationship reaches staff. The exact screen placement is a separate thing to test.
Make a short list of possible extras and ask the people who handle them for input:
- Kitchen lead: Which extras change preparation, cooking time, or plating? Which can be packed independently?
- Order packer: What information must appear on the ticket to avoid a missing or misplaced extra?
- Menu manager: Which items are eligible, and are prices and descriptions current?
- Owner or manager: What does the extra cost, and who will keep availability and prices up to date?
Include required choices, such as a mandatory side selection, in the conversation, but keep them distinct from optional paid extras. A guest should not have to decipher whether an add-on is required or whether its price is included. Your restaurant website and ordering menu should use descriptions that make sense together.
Also decide what happens when there is more than one eligible item. If a guest orders two bowls and selects one extra protein, the order must make clear which bowl gets it. If the system cannot preserve that relationship, consider a different offer or a simpler menu configuration rather than expecting staff to guess.
Check preparation and inventory implications
Start with the physical path of each extra. An ingredient added during cooking has a different workflow from a sealed drink placed in a bag. For each candidate, note where it is stored, who handles it, when it is added, and how staff know it has been completed.
Item-specific choices can reduce ambiguity for the guest, but they can add work at the station. An extra topping may require a separate step for one item in a multi-item order. If the ticket groups all modifiers away from their parent items, the kitchen may have to stop and interpret the order. Ask vendors to show the complete ticket or kitchen display, not just the guest-facing menu.
Shared extras can be easier to pack when they are separate products. They can also be forgotten if the packer sees only entrée details or if drinks are stored away from the packing station. A basket-level sauce is especially risky when guests might expect it on a particular entrée. Name it as a separate container and specify its size where that matters.
Stock deserves the same attention. A popular extra might use an ingredient already needed for core dishes. Decide who marks it unavailable, how quickly that change reaches ordering, and whether staff can still sell the parent item without it. Ask the provider how availability is managed; do not assume that menu controls track physical inventory.
Before expanding a list of extras, set an operating limit. For example, a kitchen may decide it can reliably handle only a few distinct optional toppings during its busiest period. That is a local capacity decision, not a software setting. If staff routinely have to leave the line or reopen packed bags, a smaller offer list may be more valuable than a longer one.
When reviewing systems, use the online ordering buying guide for broader questions about order flow. For add-ons specifically, request a demonstration of multiple quantities, unavailable items, ticket wording, and how an order change is handled.
Compare relevance and clarity with a decision matrix
The matrix below is a starting point, not a rule that every restaurant must follow. The best structure is the one that preserves the relationship between an extra and the food while remaining easy to fulfill. A separate item can still be offered alongside a particular entrée if that is the clearest option available.
| Extra | Useful structure | Why it fits | Check before launch |
|---|---|---|---|
| Cheese on one burger | Menu-based | It changes a specific item. | Does the ticket identify the correct burger and quantity? |
| Extra sauce in a cup | Basket-based if shared; menu-based if tied to an entrée | Its intended use determines whether the parent item matters. | Does the description say it is a separate cup? |
| Bottled drink | Basket-based | It can usually be packed independently. | Are flavor, quantity, and packer instructions clear? |
| Extra protein on a bowl | Menu-based | The kitchen needs to know which bowl changes. | Can it be disabled when the ingredient is unavailable? |
Consider this hypothetical setup: a counter-service restaurant sells burgers and bowls, with a packer assembling takeout bags. Cheese changes an individual burger, so the manager attaches it to that item. A bottled drink is packed separately and is useful with either entrée, so the manager offers it for the basket. Sauce is sold in a labeled cup; if guests commonly want it for a particular bowl, the manager checks whether the order can identify that bowl without implying the sauce is already mixed in.
That recommendation assumes the ordering system can show the chosen relationship clearly to both guest and staff. If it cannot, the manager should simplify the offer or ask about another configuration. A shared drink offer is not automatically relevant to every basket: a guest who already selected drinks may find a repeated prompt irritating. Ask whether the system can limit duplicates or quantities, and decide whether its available controls fit the menu.
Descriptions should answer the questions a guest cannot ask the cook at checkout. Is the extra a portion on the food or a separate container? How much is included? Is the displayed price for each item or for the whole order? Keep names short, but make the distinction visible before the guest confirms the order.
Review the order from the guest's side and then from the kitchen's side. A clear screen is not enough if the resulting ticket loses the item association. Likewise, a detailed ticket does not fix a guest-facing description that makes a separate sauce look like an ingredient already on the dish.
Measure contribution and fulfillment errors
More add-on sales do not necessarily mean more useful contribution. Compare the money left after the costs that change with each extra, then consider the staff time and errors associated with fulfilling it. Record the assumptions so you can replace them with your own numbers.
Here is a separate hypothetical monthly example. A restaurant sells 40 extra portions of cheese at $1.50 each. The added cheese and packaging cost $0.50 per portion, or $20 total. Assume $4 in incremental payment processing costs attributable to these sales. Sales are $60, so contribution after those variable costs is $36: $60 minus $20 minus $4. This is not profit.
The calculation excludes fixed costs such as the ordering subscription, rent, and scheduled labor. It also excludes exception costs such as replacements, refunds, and extra delivery trips, as well as any additional labor caused by the add-on. If two replacements cost $2 each, the contribution after those stated exception costs falls to $32. The example does not assign an order-system fee or make a claim about any provider's processing rates.
Use the same method for each candidate, but do not compare totals alone. A shared side may sell fewer units and still be worth offering if it is easy to pack and leaves useful contribution. An item-specific topping may sell well but cause enough corrections to consume its advantage. Include any incremental preparation time you can reasonably estimate, and identify costs you cannot yet measure.
Track a small set of measures by add-on and structure:
- Selection: How many eligible orders include the extra? Define eligibility consistently; a cheese offer for burgers should not be divided by all orders containing only bowls.
- Contribution: What remains after the variable costs you have identified? List fixed and exception costs separately.
- Fulfillment: How many extras were missing, attached to the wrong item, or replaced? Record both the count and the number of orders with that extra.
- Staff friction: Where did someone have to clarify a ticket, search for stock, or reopen a bag? Note the cause, not just the delay.
A simple log is useful even if it is imperfect. A missing drink and a wrong-burger topping point to different fixes. Review a sample of completed orders with the people who prepare and pack them, and compare notes with guest reports. A small sample can reveal a confusing label, but it cannot establish a reliable long-term error rate or prove that the offer caused a change in sales.
For the wider cost picture, the guide to comparing direct and marketplace contribution can help separate order-level costs from add-on economics. Ask for written quotes for software and processing, and use your own ingredient and labor figures rather than treating an example as a forecast.
Check the workflow before offering extras
First, run a simulation with staff using a demonstration or test environment. Build an order with two similar entrées, an extra on only one, and a separate basket item. Check the guest summary and the resulting ticket or kitchen display. Confirm which person would prepare and pack each extra. The simulation must not charge a card, send a guest message, or dispatch a courier.
Then decide whether the setup is ready for a limited live service pilot. A live pilot involves real orders, so brief staff, monitor availability, and have a manager review mistakes and corrections. Do not treat the simulated check as proof that the workflow will hold up during a rush. Pause or simplify an offer if the ticket is unclear or the station cannot keep up.
Use the matrix to review your current menu with your kitchen lead and packer. Then ask Fleksa about restaurant online ordering, including verified US availability and how its current setup would show your specific add-ons to guests and staff.
Frequently asked questions
Can a restaurant use both add-on structures?
Yes. Item-specific toppings and separately packed drinks serve different purposes. Check that the ordering system can represent each relationship clearly and that staff can fulfill both.
Should every menu item have an add-on?
No. Offer an extra when it is relevant, understandable, and practical to prepare. A short list can be easier for guests and staff to manage.
What should I ask a vendor to demonstrate?
Ask to see the guest summary and staff ticket for multiple items, quantities, an unavailable extra, and an item-specific selection. Also ask how menu changes reach the ordering flow.
