Half onion, extra light sauce, well-done, cut in eight. Fire It captures placement, quantity, and preparation as structured fields — not as a note the kitchen has to interpret.
Pizzeria phone orders live and die on modifier accuracy. Fire It represents pizza modifiers as structured fields: placement (whole/left/right), quantity (extra, double), preparation (well-done, light sauce), and free-form notes bounded per item. The kitchen ticket reflects the placement and modifiers the caller confirmed.
Free-text notes flatten those three axes into a paragraph the make-line has to parse. Structured capture keeps each axis addressable, so the kitchen ticket can print them where the make-line expects.
Crust and size are required. Toppings might be free-form. Fire It's required-group logic enforces the difference: the caller cannot skip past a required group, and the model cannot fabricate an option that isn't on your menu.
When the kitchen 86's a topping, the change syncs and the agent stops offering it. If a caller specifically asks for it, the agent says it's not available today and offers the nearest alternative you've configured.
Half-and-half is the canonical stress test for pizza voice AI. The caller says 'half pepperoni, half mushroom, extra cheese on the mushroom side.' Fire It captures that as three structured entries: pepperoni on the left half, mushroom on the right half, extra cheese with right-half placement. The ticket the make-line reads reflects the same placements the caller confirmed. Vendors that flatten half-and-half into a note field are the ones whose kitchens end up guessing at the pass, and those are the vendors whose customers post the online complaints that show up on your local search results.
'Extra light sauce' and 'no sauce' are different orders with different execution. 'Well done' and 'lightly baked' are different orders with different execution. Fire It represents intensity as a structured enum on each applicable modifier — light, regular, extra, double — so the make-line reads a value instead of interpreting an adjective. That is the difference between a caller getting the pizza they asked for and a caller getting the pizza the make-line guessed at from a two-word note.
The best modifier schema in the world is worthless if the make-line ticket doesn't display the fields correctly. Fire It's ticket templates support pizzeria-specific layouts — placement rendered as a diagram, intensity called out inline, prep flags at the bottom. The template is configured per printer or per KDS zone. Ask any voice AI vendor for a printed sample ticket from a live call before you sign; the answer to that question is diagnostic.
Modifier accuracy on the phone is not a switch you flip; it's a two-week rollout with a specific sequence for pizza. Do this in the order below and the accuracy curve arrives on week two instead of month two. Skip a step and the make-line pays for it in extra recuts and remakes during the Friday-night window that matters most.
Pizzeria voice AI is a poor fit for shops whose modifier vocabulary changes weekly with the specials board, or shops whose owner doesn't want the phone answered on the first ring under any circumstance. In either case the honest recommendation is to keep the human answering line and use Fire It only for after-hours capture, where the alternative is voicemail and the modifier complexity of an after-hours call is naturally lower. See the pizzerias hub at /solutions/pizzerias for the operator framing and /use-cases/restaurant-menu-voice-ordering for the general menu-binding architecture that sits underneath modifier capture.
Start on Fire It or try the live Neon Slice demo — no card required.