A severe allergy was spoken aloud and the ticket carries no trace

The words were heard. Pull the transcript and you will usually find the allergy stated clearly, which means the failure happened after transcription — in a model that has nowhere to put it. Confirm that across 30 days of calls rather than 1 recording: match transcripts against a term list, then for every match fetch the order payload sent to the point of sale and the text that actually printed at the station. Classify each into 4 buckets — a structured allergen field, free text that printed on the prep ticket, free text that did not, and nothing at all. Those 4 counts are the diagnosis, and they are the number the operator needs before deciding anything.

Build the term list from how guests actually speak, not from a dictionary. People rarely say 'nut allergy'. They say she can't have nuts, he's coeliac, no dairy at all, it makes her really ill, is there gluten in that. The alias work is the same discipline as teaching an agent the menu, described in teaching an ordering agent to hear your menu, and it has to cover the languages your guests call in.

Where the words go after they are heard

Count the characters your own thermal ticket prints on 1 line before assuming a sentence fits, and stand at a KDS screen to see how much of a note is visible without scrolling. Most operators have never checked either. Note limits also differ per platform — Toast, Square, Lightspeed and every delivery aggregator define their own note fields and their own lengths, so read the documentation for the one you inject into rather than assuming a shared behaviour. If the transcript itself is missing the words, this is a different problem and it is diagnosed in the agent is accurate at three in the afternoon and useless at seven.

Four causes, in the order they are usually true

1. There is no typed field anywhere in the model. By a wide margin the most common cause, and the one people investigate last because it feels too simple. Every layer is doing exactly what it was built to do; the concept does not exist in any of them. Read the order schema first. If there is no allergen field, stop investigating the agent — no prompt, model or voice provider fixes a field that was never defined.
2. The free text is truncated or misplaced by the injection path. Compare the notes string your system sent against the notes string the point of sale stored. Missing characters means a length limit. Present but attached to the order rather than the line item means it will not travel to the station that cooks the dish, which looks identical from the dining room and is a different fix.
3. Notes print on the receipt and not on the prep ticket. Place a live test order containing a distinctive token — a nonsense word nobody would type by accident — then physically collect all 6 artefacts it produces: customer receipt, expo ticket, station ticket, KDS tile, packing label, delivery-partner copy. Read them. The token will be missing from at least 1, and that is your answer.
4. The read-back summarised instead of repeating. An agent that says 'and I've noted an allergy' has confirmed nothing: the guest cannot correct an allergen they never heard repeated, and the transcript gives you no evidence of what was captured. Read-back is the commit boundary of a phone order, argued in the read-back is where a spoken order becomes a ticket, and allergens are the one field that must be spoken back in full.

A 5th pattern hides inside the others. Guests very often state the allergy at the start of the call, before any item exists, then order 3 dishes. If the agent binds the allergy to the current item rather than to the order, it attaches to nothing and disappears. That is a state-tracking failure of the same family as the one traced in three modifiers in one breath and two land.

An allergy is not a modifier

Modelling allergens as modifiers is the mistake that produces most of the rest. A modifier changes a dish — no onions, extra cheese — and its scope is 1 line item. An allergy changes whether a dish may be made at all, and its scope is frequently the whole order: a shared fryer, a shared grill surface, a garnish added at the pass. A guest saying 1 person at a table of 6 cannot have nuts is not modifying 1 line; they are placing a condition over everything the kitchen is about to prepare. A catalog that can only express per-item modifiers cannot represent that, and no amount of prompt engineering makes it able to.

The allergy object, and why it fails closed

• Allergen, from a controlled list the operator maintains to match whatever the local labelling regime names, plus an other option carrying free text. Confirm that list against your own regulator rather than copying somebody else's. A controlled list is what makes the field reportable and lets the catalog answer whether a dish contains it.
• Scope. Which line items it binds, with whole-order as a legitimate and common value. This is the field that separates an allergy from a modifier.
• Severity as the guest stated it. An enum, not prose, and explicitly a record of what was said rather than an assessment of anything.
• Stated-at. Which turn of the call it appeared in, so the review process can find cases where it was heard early and bound late.
• Confirmed-by-read-back. A boolean that must be true, set only when the agent spoke the allergen and the affected items back and the guest agreed.
• Resolution. Accepted by the kitchen, refused, or escalated to a person — with the person's identity recorded when it is the third.

Then make the order refuse to close while any of those are unresolved. This is the one field where the correct fallback is a human rather than a retry: if the agent cannot confirm the allergen, the scope and the read-back, it hands the call to a member of staff. That only works if the transfer itself is reliable, which is a separate and frequently broken piece of machinery covered in the handoff works and the call still dies. And if the point-of-sale integration cannot carry a structured allergen field at all, the order must not be injected silently as a note — it goes to a person, every time, until the integration can hold it.

An allergy that degrades quietly into a free-text note has not been recorded. It has been stored somewhere nobody is required to look.

After the fix: proving it stays fixed

• Re-run the 4-bucket count every 30 days. Same query, minutes to run once written, and it catches the day a POS update changes note routing.
• Alert on any order carrying allergy language in the transcript with no allergy object attached. That 1 check is worth more than any dashboard, because it fires on the case that matters, and 90 days of it tells you whether the fix held.
• Add allergen calls to the weekly review sample deliberately rather than at random, using the ritual described in the weekly listen-back on orders that went wrong.
• Give the agent a read path into placed orders, so a guest ringing back to check the allergy was recorded gets an answer instead of a transfer — the missing capability behind half the calls are people asking where their food is.
• Fix the same field on the other ordering surfaces. Whether guests order through a native app or a table QR code, allergens live in the order model rather than in a screen, which is one of the less obvious consequences of the choice weighed in installed app versus scan to order at the table.

None of this is a large build. It is a field, a constraint, a read-back rule and a refusal to degrade — the kind of narrow, high-consequence scope we treat as core in MVP and product builds rather than as something to add after launch. The rest of this silo sits under voice and phone ordering agents, and the wider practice is described under restaurants and food service.

• voice ordering
• allergens
• POS integration
• order modelling