Every digital ordering system has a rail of suggestions somewhere near the cart. Almost all of them are ignored, and the reason is usually not the design. It is that the suggestion is worth too little to matter and too obvious to be interesting.

Here is what we learned building one, including the version that did not work, because the failure is more instructive than the fix.

Mistake one: optimising for a complete meal

The first version was clever in the wrong direction. It worked out which course was missing from the basket and offered it. On a ₹500 gravy order it confidently suggested a ₹20 roti.

Technically correct. Commercially worthless. It produced about a 4% uplift and, worse, it taught customers that the rail was full of trivia they could scroll past. You get roughly one piece of attention at the cart. Spending it on ₹20 is spending it on nothing.

Mistake two: the categories were wrong

The second problem was in the data, not the logic. Gravy, rice, biryani and sizzlers were all filed under one category called "main". Which meant the single most obvious pairing on an Indian Chinese menu, a gravy needs something under it, was invisible to the algorithm. Both halves of the pair were the same thing, so it could never see the gap.

If your menu categories are how you print the card rather than how the food is eaten, no recommendation engine on earth will help you. Fix the categories first.

Classify by role, not by menu section

What actually works is a small set of roles describing what a dish does in a meal:

Opener. Soup. Comes first, rarely alone.
Starter. Appetisers and fries. High margin and an easy yes.
Gravy. Needs a carb underneath it.
Carb. Rice, noodles. Needs a gravy on it.
One-dish meal. Biryani, a sizzler, rice already mixed with gravy.
Never suggested. Bread, extras, drinks.

That last one is the counterintuitive part. Drinks and breads are the classic upsell in every training manual, and they are exactly what to leave out of an automated rail. People add those themselves. Suggesting them burns your one slot on the cheapest item on the menu.

The pairing that does the work

Once dishes have roles, the logic is almost embarrassingly simple:

Gravy in the basket → suggest a carb. A gravy with nothing under it is the clearest unfinished order on the menu.
Carb in the basket → suggest a gravy. Rice on its own is not dinner.
Both already there → suggest a starter. The meal is built, so sell the thing eaten first.
A one-dish meal → suggest a starter, then a different one-dish meal, because the second person at the table is ordering too.

A category already in the basket is never suggested again. That one rule is what stops the rail offering a near-duplicate of something already there, which is the fastest way to look stupid.

Size the suggestion against the basket

This is the part that turns a recommendation into an upsell, and it is a single line of arithmetic. Aim at a proportion of what they are already spending, and refuse to show anything below a floor:

Target: around 35% of the current subtotal.
Floor: around 18% of subtotal, and never below a fixed rupee minimum.

Anything under the floor is dropped outright. The rest are ranked by how close they land to the target, and then by what has actually been selling in the last month.

The effect is that the rail scales with the customer. A ₹200 order sees suggestions around ₹180 to ₹230. A ₹1,400 order sees ₹400. Nobody is ever offered a roti on a feast, and nobody ordering a single coffee is shown a family platter.

What to check on your own menu

Do your categories describe how food is eaten? If "main" contains both the gravy and the rice, the most valuable pairing you have is invisible.
What is the cheapest thing you currently suggest? If the answer is under a tenth of a typical order, you are training people to ignore the rail.
Does the suggestion change with basket size? A fixed list of "popular items" is not an upsell, it is a second menu.
Are you measuring average order value with and without? If you cannot see the difference, you cannot tune it, and an untuned rail is just clutter.

The part that has nothing to do with software

None of this replaces a good counter person. Someone who knows that this customer always takes an extra portion of chilli paneer will beat any algorithm. What the system does is make the suggestion happen on every order, including the ones placed at 11pm by someone who never speaks to your staff at all, and including the ones on a Saturday when nobody has time to ask.

Consistency is the whole advantage. A good suggestion made half the time is worth less than an average one made every time.

Retova builds this into ordering across delivery, takeaway and dine-in, into café QR ordering, and it runs against the same menu yourcounter billing uses. Related reading:building a loyalty programme andwhat commission costs you. To see it on your own menu,get in touch.

How to raise average order value without annoying anybody