AI Agents
AI agents for restaurants and QSR: a guest-service agent on Agentforce and Data 360
A guest texts 'where's my order' during the dinner rush, and the answer lives in the POS, the loyalty system, and a delivery marketplace you don't own. That gap, not the cooking, is where an agent earns its place. Here is how to build a restaurant and QSR guest-service agent on Agentforce and Data 360, and the two calls that stay human.
At 7:15 on a Friday, a guest opens a chat and types “where is my order.” Simple question. The answer is scattered across three systems that don’t talk to each other during a rush.
A point-of-sale system took the order at the counter. A delivery marketplace is carrying the food. A loyalty profile knows this is the third late order this month for someone with 8,000 points. No single screen holds all three, and the person who could assemble them is expediting forty tickets.
That gap is where an agent belongs in a restaurant, and it is worth being precise about, because the wrong pitch sinks the project. Nobody needs AI to cook or to price a combo. What eats the shift is the conversation around the order: status checks, “you forgot the sauce” complaints, allergen questions, loyalty redemptions, spread across chat, SMS, WhatsApp, voice, and email, and across counter, drive-thru, app, and delivery.
So the whiteboard version. The agent runs the guest conversation around the order, on one profile that stitches the POS, loyalty, and delivery data together. It resolves the routine turns on its own, and it hands two things to a human every time: the money and the allergens. The rest of this is how to build that on Agentforce and Data 360, and why those two stay human.
The data problem comes before the agent
A restaurant guest does not have one identity. At the counter they are anonymous. In the app they are a logged-in loyalty member. On a delivery marketplace they are a masked handle the platform owns. The same person, three records, and the agent is useless until they are one.
This is the Data 360 job, and it comes first. Salesforce’s own restaurant materials describe the pattern plainly: Data 360 and MuleSoft unify POS, loyalty, and service data into a single guest profile. The agent grounds on that unified profile, not on any one source system.
Get the profile wrong and every downstream answer inherits the error. An agent that can’t tell the app order from the drive-thru order will confidently report the wrong status. A guest told their delivered order is “still being prepared” trusts the brand less, not more. The unified profile is the foundation the whole build stands on.
Say the words precisely, or the agent will get them wrong
Restaurant operations have exact vocabulary, and an agent grounded on loose definitions produces confident nonsense. The terms to build around:
- WISMO (“where is my order”) is the status-check conversation, the single highest-volume guest contact in food service.
- A ticket is one order as the kitchen sees it. It carries line items and modifiers (no onions, extra cheese, sauce on the side), and a modifier the agent drops is a remake.
- 86’d means an item the location is out of right now. An agent that offers to reorder an 86’d item creates a problem instead of solving one.
- A DSP (delivery service provider), or marketplace, is DoorDash, Uber Eats, and the like. When they carry the order, the live delivery status lives in their system, not yours.
- A make-good, or comp, is the recovery when something went wrong: a refund, a credit, a replacement, or loyalty points. This is money, and it is where autonomy stops.
- Loyalty tier and points are the guest’s standing and balance, which decide what a fair make-good even is for this person.
- Allergen and cross-contact are the safety layer. A menu question that touches allergens is not a menu question, it is a liability question.
Every one of these has to be a governed value the agent reads from a system, not a phrase it interprets. Which is why the data foundation comes before the agent.
The agent’s job is the conversation, not the kitchen
State the distinction plainly so nobody on the project misremembers it.
The POS owns the order, the kitchen owns the food, and the DSP owns the delivery. The agent owns the conversation around all three: assembling status, answering questions, capturing complaints, and drafting the recovery a human approves when money is involved.
Get that backwards and you build something that either duplicates the POS badly or makes refund decisions it should not own. Get it right and the agent earns its place on the turns that consume the shift. Model those as distinct subagents, each with a bounded set of actions:
- Order status (WISMO): read the ticket from the POS, and when a DSP is carrying it, read the delivery leg and report an honest combined status.
- Order modification: change or cancel while the ticket is still open, within a window the POS actually allows, and say so plainly when the kitchen has already started.
- Complaints and make-goods: capture what went wrong, propose a recovery sized to the loyalty standing, and route anything that spends money to a human.
- Menu and dietary FAQ: answer ingredient, nutrition, and availability questions from governed menu data, and escalate anything that turns on an allergy.
- Loyalty: check points, explain tier benefits, and redeem against the loyalty system of record.
The actions are integrations, and that is the hard part
Each subagent’s actions are where the build gets real, because a restaurant agent is mostly an integration project wearing an agent’s clothes. The reads and writes go to systems Salesforce doesn’t own.
Order status and modification call the POS. The delivery leg calls the DSP’s API. A make-good writes to the loyalty platform or the refund path. Use Apex or Flow actions for what lives in Salesforce, and MuleSoft-backed API actions for the POS, DSP, and loyalty systems that don’t.
The agent’s reasoning is only as good as those integrations are reliable. A flaky POS callout reaches the guest as an agent that “doesn’t know,” which is worse than no agent at all.
Menu and dietary answers are a grounding problem, not an action problem. Put the menu, ingredients, nutrition, and availability into a knowledge source and let a retriever pull the exact passages, so the agent answers from governed content instead of guessing. A menu that changes weekly is a data-freshness task you have to own, because a confidently wrong price or ingredient is a brand problem the moment it is sent.
The two calls that stay human
Two areas do not get full autonomy, and being firm about this is what makes the agent safe to ship.
Money. A refund, a credit, or a comp is a decision with a cost, and an agent that hands them out to end an awkward conversation is a liability. Let it propose a make-good, sized to the loyalty standing and the nature of the failure, and route the approval to a human above a threshold you set. Small, policy-bounded gestures can be automatic; anything beyond that gets a person. The handoff and escalation design is the control that keeps this honest.
Allergens. An allergy question is a safety question, and a language model is the wrong thing to improvise one. The agent should answer only from governed allergen data, state its limits, and escalate to a human the moment the guest signals a real allergy rather than a preference. “Confidently phrased” is exactly the failure mode you cannot accept when the downside is an allergic reaction. Draw that line in the guardrails and the grounding, and test it with adversarial questions before go-live.
What OpenTable’s build tells you
There is a public reference worth reading before you scope your own. Salesforce’s OpenTable story describes one of the first Agentforce deployments. OpenTable rolled autonomous agents out to restaurant partners first and then to diners, reporting tens of thousands of handled conversations within weeks.
In that account the agent takes routine tasks like redeeming loyalty points and changing reservation details, and augments human agents with recommendations on the harder cases. Read it as a pattern, not a promise. Start where volume and risk are both manageable, keep a human on the judgment calls, and let the agent assist people rather than replace them. The metrics are Salesforce’s account of one customer, so treat them as directional rather than a number you will hit.
The franchise and channel realities
Two more things shape a real restaurant build. Most brands are franchised, so the agent spans locations with different menus, different 86’d lists, and different operators. The data model has to carry location as a first-class dimension, or the agent will answer for the wrong store.
The channels are also wide. Salesforce’s restaurant materials describe guest-service agents working across chat, SMS, voice, WhatsApp, and email, with WhatsApp reaching guests through Salesforce’s digital-engagement channels. Each channel you turn on is a surface to test, not a free switch.
Cost scales with conversation volume, which in food service is large. Every turn the agent takes draws against its consumption budget, so the discipline that keeps the agent accurate (tight grounding, small actions, a unified profile instead of repeated lookups) is what keeps a high-volume deployment affordable. A WISMO agent handling the dinner rush is the best use case and the one most exposed to a sloppy, token-hungry design.
Where to start
Build the profile before you build the agent. If Data 360 and MuleSoft can hand you one guest record that ties the counter order, the app order, and the delivery order to the same loyalty member, the agent has a fair shot at every routine turn.
Then scope it narrow: status, modifications, menu FAQ, and loyalty, with money and allergens routed to a human from day one. That is a restaurant agent you can put in front of guests during a rush without holding your breath. Restaurants sit close to the rest of a retail and commerce estate, and the same guest profile that powers this agent powers the marketing and service around it.
Understanding the basics
What can an AI agent do for a restaurant or QSR?
It runs the guest conversation around the order across channels: checking order status (WISMO), making changes while a ticket is still open, answering menu and dietary questions from governed data, handling loyalty checks and redemptions, and capturing complaints. On Agentforce it does this over chat, SMS, WhatsApp, voice, and email. Decisions that spend money, like refunds and comps, and anything touching allergens should route to a human.
Why does a restaurant agent need Data 360?
Because a guest shows up as different identities at the counter, in the app, and on a delivery marketplace, and the agent can’t answer accurately until those are one profile. Data 360, with MuleSoft, unifies POS, loyalty, and service data into a single guest profile the agent grounds on, so it reports the order the guest placed rather than guessing from one system.
Should the agent handle refunds and comps automatically?
Only within a small, policy-bounded limit. A refund, credit, or comp is a decision with a cost, so let the agent propose a make-good sized to the guest’s loyalty standing and the nature of the failure, and route anything above your threshold to a human for approval. Full autonomy over money is where restaurant agents get into trouble.
How does the agent answer allergen questions safely?
By answering only from governed allergen and ingredient data, stating its limits, and escalating to a human the moment a guest signals a real allergy. An allergy question is a safety question, and a language model should not improvise one. Test this path with adversarial questions before go-live, because a confidently wrong allergen answer is the failure you cannot accept.
Thinking about a guest-service agent for a restaurant or QSR brand and want the guest profile and the human-in-the-loop lines drawn before you build? Talk to us. Getting the data foundation and the escalation design right is what separates an agent guests trust from one that makes the dinner rush worse.
