The call you lose money on arrives at 8pm on a Saturday. Both lines are engaged, the host is carrying plates, and somebody wants a table for six. An AI phone agent picks that call up. This post is a design document for it: what goes into the agent, what it has to be connected to, and what you must keep a person for.
Why peak hour is the whole problem
A restaurant phone line is not busy evenly. It is quiet all afternoon and then unusable for three hours, and those three hours are when a booking is worth the most. Missed calls are not spread across the week. They are concentrated in the window where every one of them is a table.
Staffing for that peak does not work, because you would be paying somebody to sit beside a phone that rings twice at 4pm. Voicemail does not work either, because a person who wants a table tonight calls the next restaurant instead of leaving a message.
An agent suits exactly this shape of demand: many short, near identical calls arriving at once, about a small set of facts you already know. Your hours. Whether you have a table. Whether you deliver to that pin code. How long a collection order takes.
What the agent actually is
A Foan voice agent is a few paragraphs of text plus a set of connections. You write it into four fields on the agent page.
Agent Identity is who it is. "You are the reservations line for a 60 cover Italian restaurant. Your name is Riya." Short and concrete beats elaborate.
Agent Personality is how it behaves. Restaurant callers are in a hurry and often standing somewhere noisy, so brisk and warm beats chatty.
Agent Task is the job, and it is where you fix the order of business: establish whether the caller wants a table or food to collect, handle that one thing, end the call.
Language and accent is a single free text field on voice agents, not a dropdown. Write what you would tell a new host: "Indian English, follows the caller into Hindi or Hinglish". Callers switch language mid sentence on a restaurant line constantly, and what happens when they do is worth understanding before you write that line.
Budget your words. All the instruction fields together are capped at 4,000 characters, with a warning at 3,000. On this use case the cap is useful. A restaurant agent that needs three pages of prompt is an agent being asked to do several jobs at once.
Which messages does the caller hear?
Four fixed messages sit in the Call Messages section, and on a restaurant line they carry more weight than the prompt does.
The greeting sets the shape of the call. "Thanks for calling, are you looking to book a table or place a collection order?" gets you to the branch in one turn instead of four.
The closing message is where the booking gets repeated back. A caller who hears the date, time and party size read out will correct it there and then, which is the cheapest error check you will ever build.
The escalation message is what plays when the call is on its way to a person. The voicemail message only matters if you also call people back.
Where do the restaurant's facts live?
Hours, the table holding policy, the cancellation rule, parking, whether the terrace is covered when it rains. All of that belongs in a knowledge base: up to five files of 4 MB each as PDF, DOCX, TXT or MD, or text pasted straight into the form.
Design around one property. A knowledge source cannot be edited once uploaded, because editing is not available in the product today. So split your files by how often they change. The address, the parking directions and the alcohol policy can sit in one stable document for a year. Anything seasonal goes in its own small file that you delete and replace rather than patch. Building a knowledge base your voice agent will not hallucinate from covers the structure in detail.
Retrieval is semantic, so the caller's wording does not have to match the document's. A small knowledge base is placed in front of the model directly. A larger one becomes something the agent searches during the conversation, which costs a beat. For a single restaurant, tight and small reads faster than exhaustive.
What about the menu?
The menu is the one thing that fits a knowledge base badly, because it is long and it changes.
There is a separate feature for it. A catalogue attaches to the agent through Product Search, and it exists so an agent can look items up in a list rather than read a document. A menu is a list of items. "Do you have a vegan main under 600 rupees" is a product search, not a document question.
If the menu genuinely changes daily, neither an uploaded file nor a catalogue upload is the right home for the specials. Put them behind a tool, so the agent reads today's list from your own system at the moment somebody asks. That is the only version of "our menu changes daily" that is still true on a Wednesday.
Can it take a takeaway order?
It can take one. Whether it can place one is up to you.
The agent's only way to change anything in the world is a function tool: a named action with a set of questions, pointed at a URL you own. When the agent uses it, Foan sends a POST to that URL with the answers and then speaks whatever you send back. There is an optional bearer token for authentication, no custom header field, and no choice of HTTP method.
So a collection order works if you have an endpoint that accepts one. If the order has to end up on a printed ticket in your kitchen, something must write it there. An agent cannot type into a till it has no connection to. Be honest with yourself about this before you promise customers an order line.
Two settings decide whether the order line is usable or a mess. Confirm before running is on by default and should stay on, so the agent reads the order back and waits for a yes before it sends anything. Prevent duplicates is also on by default, and it stops a caller who says yes twice from producing two tickets for the same food.
One more, because it is the most common design mistake on this vertical: the caller's phone number already arrives with every tool call. Never add a question asking the caller to read their number out. They are standing on a road.
An agent also holds at most five tools. Check availability, create booking, place order, today's specials, one spare. That is not room for a tool per menu category, and the limit is a useful forcing function.
This is quicker to try than to read about, so create a free account, build a booking agent and forward your own mobile to it for one evening service. Restaurants covers the phone channel across a group of outlets, and pricing tells you what a busy Friday actually costs.
How do the calls reach the agent?
You do not have to move your number. Conditional call forwarding on the SIM you already publish sends unanswered calls to the agent, so staff keep first refusal and the agent catches the overflow at 8pm. One dial code sets it, one cancels it, and the original caller's number survives the forward, so the agent still knows who it is talking to. Giving your agent a number without porting has the codes.
The limit to plan for: a forwarded line generally carries one call at a time. A Saturday night restaurant is exactly the business that outgrows that, so treat forwarding as the pilot and a number of the agent's own as the destination.
What must stay with a person
Name these in the instructions rather than hoping the agent works them out.
A party of twelve is not a booking, it is a negotiation about a deposit and a set menu. A complaint about last night's meal needs a manager, not a cheerful confirmation. Refunds, lost property and press enquiries go to a human immediately. And a caller who asks for a person twice should get one without having to argue.
Handover is configured over the API rather than through a dashboard screen. The behaviour is this: the agent says one connecting line, the caller hears hold music, Foan rings your number, whoever picks up hears a short spoken briefing of the call so far, and then joins the caller. The AI leaves at that moment. If nobody answers inside the ring window, the caller gets an apology and the call ends rather than sitting in silence.
Design around that last part. A handover nobody picks up during service is worse than no handover at all. Point it at the phone that is genuinely held by a person at 8pm, not at the office landline.
Where to go next
Start with one job rather than the whole phone line. An agent that books tables well is worth more than one that half handles bookings, orders, directions and complaints. When the booking agent is behaving, add the collection order tool.
Restaurants covers what the phone channel looks like across a group of outlets, and phone agents covers the mechanics of the call itself.
Try it on your own number
Build an agent, point a number at it and listen to the first call.