Half pepperoni, half veggie, and the kitchen makes it whole
In short
If a topping requested for one half lands on the whole pizza, the agent is not mishearing. Check whether the modifier carries a portion dimension at all. If it does not, the order shape cannot be represented, every layer downstream faithfully records something the guest did not ask for, and the fix is a catalog change followed by a read-back that speaks the portion next to the topping.
Key takeaways
- If the modifier has no left, right or whole dimension, the agent was never able to be right about a split.
- Portion belongs on the modifier application, not on a duplicate half-pizza product. Duplicating products moves the bug, it does not remove it.
- A portion scope that exists in the POS but not in the ordering catalog fails silently, because the payload is accepted and normalised.
- Pick one pricing rule for a half upcharge and run it on every channel, or the phone total and the web total will diverge.
- The read-back must put the portion word next to the topping and state what the other half carries, including nothing.
The recording is clean. The guest says pepperoni on one half, peppers and onion on the other, and the chit that prints carries a large pizza with pepperoni, peppers and onion across the whole thing. Nothing mumbled, nothing dropped, no noise. The agent understood the request perfectly and then wrote it into a field that has no concept of a half.
This is not a speech problem and it is not a prompt problem. It is a shape problem: the guest asked for something the item cannot hold. Every layer after that point behaves correctly and produces the wrong pizza, which is why the bug survives so much tuning — each component is doing exactly what it was told.
Ten minutes with the 10 most-customised items
- Pull the 10 items that carry the most modifiers by order volume. Pizzas, build-your-own bowls, platters and sharing boards are where portion requests concentrate.
- For each one, open its modifier groups and look for any dimension that is not option and quantity. You are looking for a field that says where on the item this applies — half, left, right, first, second.
- If that field does not exist, stop. The diagnosis is complete and no amount of agent work will change it. Skip to the model below.
- If it does exist, check whether the ordering catalog exposes it or only the POS holds it. Fetch one item through the same API path your agent uses and read the response, rather than trusting the back-office screen.
- Then send 1 deliberately split test order end to end and read the accepted order the POS returns, not the payload you sent. A silently normalised portion looks identical to success in a request log.
Four causes, and only 1 of them lives in the agent
| What you see | Cause | Confirming check |
|---|---|---|
| The topping is applied to the whole item, every time, on every channel | No portion dimension exists anywhere in the model | Read the item's modifier groups. There is no field to look at |
| The web ordering page can split it and the agent cannot | Portion exists in the POS but is not exposed on the path the agent reads | Fetch the same item through the agent's own API path and diff the two responses |
| The split is right and the total is wrong | Pricing rules cannot express half of an upcharge, so they charge whole or nothing | Price a half-topping order by hand and compare against the printed total |
| One half is right and the other half is empty | The utterance bound the second topping implicitly and the agent never carried the reference | Replay the turns against the order builder with transcription removed |
Only the 4th row is an agent defect, and it is a specific one: the guest says 'and mushrooms on the other side', which requires holding a reference to a portion the agent is not currently editing. That is the same class of state failure that loses a modifier attached to the wrong line, taken apart in three modifiers in one breath and only two landing. The other 3 rows are catalog work.
The agent understood the request perfectly and then wrote it into a field that has no concept of a half.
The shape that can hold the request
Portion is a property of the modifier application, not a property of the product. A line item carries a portion scheme; each applied option carries the portion it covers; the default is whole. That single change makes every split expressible without a second product.
- Declare a portion scheme on the item. Whole-only for most things, halves for round items, quarters if the kitchen genuinely makes them. If the kitchen will not make quarters, do not model quarters.
- Mark each modifier group portionable or not. Size, crust, bake and dough are properties of the whole item and must reject a portion outright. Toppings and sauces are portionable.
- Make the application a triple: option, portion, quantity. 'Extra pepperoni, left half' and 'pepperoni, whole' are the same option with different scopes, not 2 catalog entries.
- Validate at the boundary and fail loudly. A portion value outside the item's scheme, or a portion on a non-portionable group, must be rejected with a message the agent can act on rather than normalised away into a whole.
- Keep the mapping to the POS in one place. If the POS expresses halves as separate codes, that translation belongs in the mapping layer; the ordering catalog keeps a portion field so the agent never learns a POS convention. The general shape of that boundary is set out in building an order payload the POS will accept.
One cost is worth naming. A portion dimension multiplies the option space the agent has to search, and catalog lookup is already the stage that dominates the pause a caller hears. If you add portions without caching the catalog, you will trade a wrong pizza for a slow one — the trade examined in the pause after the guest stops talking.
Pricing half of an upcharge
3 rules are defensible, and the failure is not choosing between them but running different ones on different channels. Write the choice into the catalog once.
- Full upcharge on any portion. Simple, predictable, and guests rarely argue about a cheap topping. It gets expensive-looking on a premium topping placed on a quarter.
- Pro-rata by portion, with a stated rounding rule and direction. Fairer, and it needs a decision about what happens at fractions the pricing engine cannot represent — pick round-up or round-down and write it down.
- Highest-half base pricing. The item's base price is the more expensive of the two halves, with toppings priced by one of the rules above. This is the conventional pizza approach and it survives a guest combining a premium half with a plain one.
Whichever rule you pick, the total has to be final before anything asks the guest to pay. A payment link sent mid-call for an amount that later changes because a half was repriced is a support ticket by design, which is one reason the payment shapes in taking payment on a phone order without a card number all place the charge after the order is settled rather than during it.
The read-back that proves the portion landed
A read-back only catches an error the guest can hear. 'A large pizza with pepperoni, peppers and onion' is true of both the order they placed and the order that will be made, so it confirms nothing. The portion word has to sit next to the topping it scopes.
- Speak the scope first, then the toppings: 'left half pepperoni; right half peppers and onion'. Grouping by portion is how the kitchen reads the chit, so it is also how the guest can check it.
- State the other half even when the guest did not. If they only asked for pepperoni on one half, say the rest is plain. Silence is where the assumption hides.
- Name whole-item modifiers separately from portioned ones, so 'thin crust' is not heard as applying to a half.
- Read the total after the portions, not before. If a pricing rule changed the amount, that is the moment the guest can object cheaply.
That last point is the general rule about where a spoken order becomes a commitment, argued in the read-back where a spoken order becomes a ticket. Split items simply make the boundary sharper, because a wrong split is not a small wrong — it is a remake, a late order and, usually, a guest on the phone asking where their food is, which is the demand pattern described in when most of the calls are people asking where their food is.
When the catalog cannot be changed yet
Sometimes the POS genuinely cannot express a portion and replacing it is not this quarter's project. The honest interim behaviour is to say so during the call: the agent states that it cannot split this item, offers the 2 closest orderable outcomes — 2 smaller items, or the topping on the whole — and hands to a person if the guest wants neither. What it must never do is accept the words and write a whole.
It is also worth noticing that this is not a voice problem at all. A server on a handheld hits the same wall, on the same item, because the constraint is the model rather than the channel — one reason device decisions like handhelds or stations for table service should not be made before the catalog can express what staff need to enter. Getting that model right is menu-modelling work in voice and phone ordering and across software for restaurants and food service, and rebuilding an ordering catalog around it is a product build rather than a configuration change.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
Can prompt engineering fix half-and-half orders?
No. If the item has no portion dimension, there is no field for the agent to write a half into, and the best-behaved model in the world will either apply the topping to the whole item or drop it. Prompt work can change what the agent says about the limitation — refusing clearly instead of guessing — but it cannot create a shape the catalog does not have.
Should we model quarters as well as halves?
Only if the kitchen actually makes them. A portion scheme is a promise about production, not a data-modelling flourish: every value you expose has to be something the line can execute and the chit can express legibly. Most operations settle on halves, and treat anything finer as an off-menu request that a person handles.
How do we handle a topping the guest wants on the whole pizza plus one on a half?
That is the case duplicated half-and-half products cannot express, and it is the reason portion belongs on the application rather than the product. With a portion field, the order carries 2 applications of the same group — 1 scoped whole, 1 scoped left — and the kitchen chit groups them by section. With a duplicate product you are back to typing it into a note.
Is a wrong split visible in accuracy reporting?
Usually not, and that is why it persists. Order-level accuracy compares items and modifier names, and both are present — the topping was ordered and the topping is on the ticket. The error is in a scope that the report never looks at. Catch it by scoring split orders as their own class, or by counting remakes on portionable items separately.
- voice ordering
- menu modelling
- modifiers
- catalog
The work behind this page
Builds from our portfolio that this page draws on.
Read next
- Three modifiers in one breath and only two reach the ticketThe recording contains three customisations and the printed chit carries two. Which one goes missing tells you which layer dropped it — and transcription is the least likely answer.diagnostic
- Read-back: the moment a spoken order becomes a kitchen ticketRead-back is the commit boundary of a phone order — the last moment a wrong item is still free to fix. Everything the kitchen will act on differently has to be spoken before anything is written.definition
- The pause after the guest stops talking is where the order is lostCallers do not abandon at random. They abandon at the turns that trigger a menu lookup — the first item, and any turn after a customisation — which tells you where the delay actually is.diagnostic
- A severe allergy was spoken aloud and the ticket carries no traceA guest states an allergy, the recording proves it, and the prep ticket shows nothing. That is a schema failure, not a listening failure — and the repair is a typed object that stops the order closing.diagnostic
- Off-menu: the requests an agent must never improvise onOff-menu is not a property of the request. It is a property of your catalog on the day the call arrives — and only one of the three requests that sound off-menu actually is.definition
- The agent is accurate at three in the afternoon and useless at sevenAccuracy that tracks the clock rather than the order is an audio problem. Caller-side noise, the room behind the handset and a degraded audio path fail the same way and need three different fixes.diagnostic
Related across the site
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation