Voice Notes to the Kitchen: Modifiers, Allergies, and Special Requests

The free-text notes field is the most dangerous box in restaurant software. It accepts anything, guarantees nothing, and it is where roughly every serious kitchen incident story eventually points. The note was typed. It printed. It printed somewhere. It was 38 characters long on a printer that wraps at 32, and the word that got cut was the one that mattered.

Voice ordering makes this problem simultaneously worse and better. Worse, because speech is fluid and it is tempting to dump whatever a system heard into a text field and call it captured. Better, because a well-designed voice flow can enforce a discipline that touchscreens never managed: it can insist that "she has a shellfish allergy" become a flag, an acknowledgment, and a routing rule, rather than eleven words on a chit.

Getting there requires being precise about a distinction that most POS systems blur.

Three different things wearing one name

Everything a guest says beyond the dish name gets called a "special request." Operationally these are three separate object types with different pricing, routing and liability behavior.

Notice the last row. Free text is not a category of request; it is the absence of a category. Every time something lands there, the system has admitted it does not know what the thing is — and unknown objects cannot be priced, translated, routed, counted or audited.

Designing the spoken grammar for modifiers

People do not speak in structured fields, but they do speak in remarkably consistent patterns. A voice system worth buying recognizes six modifier shapes, and you can test any vendor against this list in ten minutes.

• Negative: "no onion," "hold the shallots," "without cheese." Watch out for the double negative — "not without the sauce" appears more often than you would think, usually as a correction.
• Additive: "add avocado," "extra bacon," "double protein." These carry price, so a silent drop costs real margin. At $2.50 a hit and 8 missed adds a night, that is roughly $7,300 a year.
• Substitution: "sub fries for the salad," "swap the rice." Two operations in one phrase: remove, then add, with a possible price delta.
• Required choice: temperature, protein, side, spice level. If the system lets an item fire without the required choice resolved, it is not ready for a kitchen.
• Preparation: "well done," "extra crispy," "on the side," "light dressing." Naturally free-text-shaped, which is exactly why they need a controlled list.
• Timing and coursing: "fire with the entrées," "hold until the table is done," "all at once." These belong on the ticket header, not the item line, and they are the most common source of expo confusion when they land in the wrong place.

The demo that matters is a four-modifier item, spoken in one breath, at real volume: "burger, medium rare, no onion, add avocado, fries instead of salad." That single sentence tests negative, additive, substitution and required-choice handling simultaneously. If it produces four correct objects with the right price delta, the mapping layer is real. The pipeline behind that resolution is described step by step in our explainer on how speech-to-order works.

Why allergies are a different problem entirely

An allergy is not a preference expressed forcefully. It has different consequences, different routing needs and a different legal posture, and the design has to reflect that at every layer.

Start with capture. Allergen terms should be treated as high-consequence vocabulary: weighted in recognition, and never silently discarded when confidence is low. A system that hears something 60 percent likely to be "no nuts" must not quietly resolve it to "no ice." It should surface the ambiguity immediately — while the guest is still at the table, which is the entire structural advantage voice has over an order typed at a station forty feet away.

Then confirmation. Any allergen detection should trigger an explicit spoken confirmation, and the read-back to the table should name the allergen aloud. This is not a technology behavior; it is a service standard that good rooms already keep. The technology's job is to make skipping it harder than doing it.

Then routing. This is where the real work happens and where notes are useless. Cross-contact is not a cleaning problem, it is a routing problem: shared fryer oil, a grill surface that just cooked something with butter, the same tongs, the same cutting board, the flour in the air in a room that makes its own pasta. A structured allergen flag can drive rules — route to the dedicated fryer, block the item entirely, require a manager confirmation. A string in a notes field can drive nothing. The full operational framework around that sits in this guide to allergen management for restaurants, which is worth reading alongside your local health code.

What the ticket should look like at the pass

The line reads tickets at three feet, in poor light, with wet hands, at speed. Design for that reality rather than for a screenshot.

Give the allergen its own real estate. A full-width banner at the top of the chit beats an asterisk on line four. Name the allergen in capitals — "TREE NUT ALLERGY," not "allergy" alone — because the word "allergy" tells a cook to be careful while the specific allergen tells them what to actually do differently.

Respect the character width. A 58 mm printer gives you about 32 characters per line, an 80 mm about 42. Anything longer wraps or truncates depending on firmware, and truncation is silent. Structured flags render inside those limits by design; free text does not.

Separate the cover. Many kitchens print the affected cover on its own chit so it can be produced on a different surface and tracked independently through the pass.

Require an acknowledgment. On a kitchen display, an allergy ticket should not be bumpable until someone explicitly acknowledges it. That timestamp becomes part of your record. It also takes about 1.5 seconds, which is a fair price.

Render in the language the station reads. An allergen flag translated per destination is trivially safe; a free-text note translated per destination is not translated at all. This is one more reason structure matters on a multilingual floor, which we take apart in multilingual voice ordering for diverse restaurant teams.

KwickVoice is in private pilot. The figures in this article are engineering and operational ranges from public sources and general practice, not measured claims about our own system, which we do not publish while the pilot runs. Nothing here is legal or food-safety advice; work with your own counsel and health authority.

The confirmation loop, in both directions

Most systems confirm forward — server to guest — and stop. The loop is only closed when the kitchen confirms back. Three checkpoints, each cheap:

1. Guest confirmation. The server reads the order back aloud, naming any allergen. The guest corrects it, or does not. Cost: a sentence that good servers already say.
2. System confirmation. The structured order is displayed or spoken back to the server before it fires — allergens and required choices first, not buried at the bottom. Cost: about three seconds.
3. Kitchen acknowledgment. The pass or the station explicitly acknowledges the flag. Cost: one tap, one timestamp.

Each checkpoint independently catches errors the others miss, which is why the combination is worth far more than any one of them. A misheard modifier that survives all three is genuinely rare — and if your system has no third checkpoint at all, that is the cheapest improvement available to you this month.

The record you will want later

There is a version of this that arrives as a phone call at 9pm on a Tuesday: a guest says they disclosed an allergy and it was not honored. What can you actually reconstruct?

With a notes field, the honest answer is usually very little — a truncated string, no timestamp on when it was entered, no evidence anyone read it. With structured capture you have the order, the flag, when it was set, which staff member set it, the confirmation event, the kitchen acknowledgment and the bump time. That is a defensible record built from data you were already generating.

Raw audio retention is a separate and heavier decision. Keeping conversation recordings creates obligations that vary by state and can create discovery exposure that operators rarely think through. A structured order plus timestamped confirmation events gives you most of the evidentiary value with a fraction of the risk. If you do retain audio, define the window explicitly, name who can access it, and check your state's recording-disclosure requirements before you switch anything on. The same discipline applies to orders arriving by phone, where the handoff into the POS is its own design problem — covered well in this walkthrough of sending phone orders straight into your point of sale.

A ten-point implementation checklist

1. Audit your current notes field. Export a month and read it. You will find allergies in there.
2. Build the controlled modifier list — every negative, additive, substitution, required choice and preparation your menu supports.
3. Give allergens a first-class flag type, separate from any modifier.
4. Define routing rules per allergen: dedicated fryer, separate board, blocked items.
5. Set ticket formatting: banner, capitals, character width, separate chit.
6. Add the kitchen acknowledgment step and confirm it cannot be bypassed.
7. Weight allergen terms in recognition and force confirmation on any low-confidence match.
8. Verify per-station language rendering with the people who read each screen.
9. Decide retention policy for structured events and for audio, in writing.
10. Drill the whole path in pre-shift before it happens live — the sequence is in our two-week rollout plan.

Two numbers are worth tracking monthly once you are live: the count of orders where an allergen flag was set, and the count where free text was used at all. The first should be stable and roughly match your historical rate. The second should trend toward zero. If free text is climbing, your controlled modifier list has a hole in it — and someone on the floor is politely routing around your safety design. Capture quality in a loud room affects all of this too, which is why the hardware side is worth reading in parallel in voice ordering in noisy dining rooms.

Frequently asked questions

Related reading

• What is speech-to-order? Voice ordering technology explained
• Voice ordering in noisy dining rooms: microphones and accuracy
• Multilingual voice ordering for diverse restaurant teams
• Training servers on voice ordering: a two-week rollout plan