Phone Orders Print in Toast, Not on a Notepad
Toast phone ordering ends in a printed ticket. Here is the path from a ringing phone to the kitchen display, what the menu brings across, and what to test.
On this page
At 7:40 on a Friday the phone rings, and the order goes onto the back of a guest check because every hand at the counter is already in a bag. Between two walk-ins, someone keys it into Toast one modifier at a time and hopes the half-and-half was what the caller said.
Most nights that works. On a Friday it does not, and the order that got written down wrong is the one the pass remakes while the line waits.
TL;DR:
- Toast runs your menu, your modifiers, your kitchen display and your till. It does not pick up the phone at 7:40.
- The order has to land as a Toast ticket, with the modifiers your line reads, not as a message to the counter.
- Kovo reads your Toast menu, reads the order back, and writes the ticket into Toast. A $0.00 test ticket proves the path first.
- A card you already hold is charged while the caller talks, so the kitchen sees the ticket during the call. A first-time caller gets a link.
- Your limit decides what the phone takes: 10 items and 8 of one item is where it starts, and you can change either.
What Toast does, and what it never hears about
Toast is good at everything after somebody picks up: the menu, the modifier groups, the kitchen display, the tax, the tender. What it never hears about is the call, because the call happens outside it.
So the order arrives the long way. Someone hears it, holds it in their head, keys it into Toast, and takes the payment, all while a guest is standing at the counter waiting for a bag.
There are three ways shops try to close that gap, and only one ends in a clean ticket:
- A person with a handset. Works, but it pulls a body off the counter and puts a queue in front of the guest who is already there.
- A message pad. The caller leaves a name and a number, and most of them do not wait for the callback. Industry estimates put around 60% of missed calls down to someone trying to order or book, and those callers ring the place two blocks over instead.
- An agent that writes to Toast. The call becomes a normal Toast ticket, modifiers included, and the kitchen never knows the difference.
Kovo is the third. The rest of this page is the path, including the parts a vendor demo skips.
Ring to ticket, step by step
Each of these can fail on its own, which is why it is worth watching the whole path once with your own menu.
- The call is answered. Kovo picks up on the first ring, including after close and on holidays.
- The menu is read. The agent talks from your Toast catalog: items, sizes, choice groups, prices, and whatever is marked unavailable.
- The order is built as the caller speaks. "Half mushroom, half pepperoni, extra crispy" becomes two topping paths and a doneness, not a sentence.
- The order is read back. The caller hears the ticket before it is placed, and a wrong half gets caught before the kitchen sees it.
- Payment happens, or it doesn't. Cards off, the order is confirmed and paid at the counter. Cards on, the card you hold is charged while they talk, or a first-time caller gets a link.
- The ticket lands in Toast. It shows on the kitchen display like any counter order, with the same modifier groups the line already reads.
Step 3 is where a weak integration dies. Something that only knows item names and prices will happily accept an order and produce a ticket your kitchen cannot build. That is why the menu matters more than the voice.
The menu it reads is yours
One menu source per shop. For a Toast restaurant, that is the Toast menu you already maintain, so the phone quotes the prices you set this morning rather than a copy somebody typed in at setup.
Kovo refreshes that menu in the background once a day, and an answered call only refreshes when the copy is two days old. Nobody stands on a phone waiting for Toast to answer.
What survives the refresh:
- An edit you make survives the next refresh.
- A change Toast makes to any other field lands.
- An item Toast deletes is deleted here.
- An item you deleted does not come back tomorrow morning.
That last rule is the one that saves a Friday. Without it, a deleted item reappears every morning and the agent offers it to the first caller of the day.
Sold out is yours to set. Mark the short rib sold out on the menu board and it stops being offered, even when the imported menu still says it is available. A restock brings it back.
One thing Toast cannot carry is a note on a single line. An instruction that is not a modifier, like "cut in squares", needs its own modifier group in Toast, or the ticket prints without it.
Modifiers, and the orders that break a demo
Toast modifier groups are flexible, which is exactly why a generic phone agent struggles with them. The patterns that matter:
- Nested groups. A pizza where each half opens its own set of toppings.
- Required choices. A combo that cannot be ordered without a side and a drink.
- Price by modifier. Oat milk, extra cheese, a premium crust.
- Instructions that are not modifiers. Extra crispy, light sauce, cut in squares.
Kovo keeps the nested groups because it reads them straight from your catalog. The test is not whether the agent can say "large pepperoni". The test is whether the ticket shows the same structure your cashier would have built, in the same Toast modifier groups your line already reads.
So test with the order your kitchen gets wrong most often. A pizzeria should start with a half-and-half pie, a deli with a sandwich that has three substitutions, a QSR with the combo that has a required drink. The pizzeria guide walks that case through in detail.
Payment, and what the kitchen sees
Three paths, and they behave differently on the line:
| How they pay | What the kitchen sees |
|---|---|
| At the counter, with cards off | the ticket prints as soon as the order is confirmed |
| The card you already hold, charged on the call | the ticket reaches the kitchen while the caller is still talking |
| A first-time caller, paying a link | the line stays open, and the ticket is released when the money lands |
No card number is read to the agent, recorded, or written down on any of the three. That is the point of the card on file and of the link: a phone line is a bad place for card digits, and a recording of one is worse. How the payment paths work covers the returning-caller case in full.
What to test before you pay for anything
Run this on a demo or a trial, in this order. It takes twenty minutes and it separates a working path from a rehearsed one.
- One item, no modifiers. Does the ticket land on the kitchen display?
- One item with two modifiers. Do both show where the kitchen expects them?
- A half-and-half or a required combo. Does the structure survive?
- An item marked unavailable in Toast. Does the agent stop offering it after a refresh?
- An order past your limit. Is it refused, and is the caller told why?
- A card order, if you use cards. Does the ticket print at the right moment?
- The test connection. Kovo prints a $0.00 ticket so you can prove the path without a real order.
If a vendor cannot show you the ticket for the half-and-half, the rest of the demo is theatre.
What it costs
Kovo is $99 a month for 750 connected minutes, roughly 300 calls, or $299 for 5,000 minutes. There is no per-minute charge and no overage: at the cap, calls forward to your own phone instead of being answered.
A call under 10 seconds is never billed, and no single call bills past 12 minutes. The trial is 14 days and needs no card. The chat on your website runs on the same minutes and the same menu, so a guest who would rather type gets the same ticket.
FAQ
Does the order land in Toast, or print somewhere else?
It lands in Toast, so it shows on your kitchen display the way a counter order does. Kovo reads your Toast menu and writes the finished order back as a Toast ticket. A test connection prints one $0.00 ticket first, so you can watch the path work before a real order ever uses it.
What happens when we 86 something mid-service?
Mark it sold out on the menu board and it stops being offered, and your 86 outranks a menu that still says the item is available. A restock brings it back. The menu is pulled in the background once a day, and an answered call only pulls when the copy is two days old, so nobody waits on Toast during a rush.
Do modifiers come through on the ticket?
Yes. Nested choice groups come across, so a half-and-half pizza opens a separate set of toppings on each half, and extra crispy stays a modifier instead of a note. Toast prints them in its own modifier groups, which is what your line already reads. Toast carries no per-line note field, so an instruction that is not a modifier needs its own group in Toast.
Is the card charged before the ticket reaches Toast?
Only if you turn cards on. A caller who has paid you before has a card on file, and it is charged while they are still talking, so the ticket reaches the kitchen during the call. A first-time caller gets a link and the line stays open until it is paid. With cards off, the ticket prints straight away and they pay at the counter.
What order is too big for the phone to send?
Your own limit decides it. 10 items in total and 8 of one item is where it starts, and you can change either, add a value limit, or set one to zero to turn it off. Above the limit the call rings your shop when large-party routing is on and a handset is set. Otherwise the agent says the order is too large to send through and keeps taking what fits.
Final Thoughts
Toast is not the problem. The unanswered ring is. A phone order that becomes a Toast ticket, with the modifiers your kitchen actually reads, closes the loop without adding a person to the counter.
Load your own menu, order the pie your line gets wrong, and look at the ticket rather than the transcript. Take a test call with your own menu, print the $0.00 test ticket, and decide from that. The other integration walkthroughs cover the rest of the till drawer.