Forward-Deployed Engineering · Restaurants · Phone ordering
Case study: phone orders in the caller's language, placed in the POS, handed to a person when it matters
Illustrative engagement — not a client record. The company, people, volumes and results below are a representative composite, written to show how a forward-deployed engagement runs end to end. The workflow, the architecture, the controls and the method are real and technically valid.
Offering usedPilot-to-ProductionA stalled pilot hardened, integrated and put in front of real users.
Illustrative results, first 90 days after go-live, in-scope calls only:
95%
Calls answered within 20 seconds, dinner peak
Before 68%
4%
Calls abandoned before answer, dinner peak
Before 15%
49%
In-scope order calls completed with no person involved
Before 0% (pilot never live)
97.8% (voice agent)
Whole-order accuracy, weekly audit of delivered orders
Before 96.4% (agents)
FDE / PlayExplainer
09 scenes
The whole story in about a minute
Nine short scenes, from the dinner rush to the results. Press play, or pick a scene.
01 — Dinner rush
At dinner, the phones outran the people.
About 38,000 calls a day, and three times the average between 7.30 and 10 pm. At that peak, one call in seven hung up before an agent answered.
Read chapter 1At a glance
- Client
- A pizza delivery brand with about 300 outlets in north and west India, one central call centre and a phone line at every outlet
- Workflow
- Delivery orders by phone to the central number: take the order in English, Hindi or a mix of both, check menu, availability, address and offers against the POS, read it back, place it, and hand off to a person whenever the call needs one
- Engagement
- Pilot-to-Production (11 weeks), starting from a voice pilot that had stalled
- Team
- One named senior forward-deployed engineer throughout, a second engineer for the integration weeks. Client side: the Head of Contact Centre (owner), the POS product manager, a telephony engineer, the data protection officer, a security reviewer, six senior call-centre agents
- Where it runs
- The client's own cloud account and region, including speech recognition and speech synthesis. No audio or transcripts retained outside it
- Handover
- Runbook executed by the client's team in the last two weeks; our access revoked on the final day
| Measure | Before | After |
|---|---|---|
| Calls answered within 20 seconds, dinner peak | 68% | 95% |
| Calls abandoned before answer, dinner peak | 15% | 4% |
| In-scope order calls completed with no person involved | 0% (pilot never live) | 49% |
| Whole-order accuracy, weekly audit of delivered orders | 96.4% (agents) | 97.8% (voice agent) |
| Calls mentioning an allergy that reached a person | not measured | 100%, by design |
| Card numbers captured in audio sent to a model or in stored recordings | not measured | 0, by design |
FDE / 01Case study
01 / 12
In shortThe call centre could not answer every dinner-time call, and orders typed by hand had mistakes.
The brand took about 38,000 phone calls a day. Around 60% reached the central number; the rest went straight to outlets. Most were delivery orders from customers who preferred to talk rather than use the app.
about 38,000 phone calls a day
- 60%reached the central number
- 40%went straight to outlets
The call centre had 240 agents over three shifts. Between 7.30 and 10 pm, calls ran at three times the daily average, and more on weekends and festival evenings. The centre could not staff for the peak without idling for the rest of the day.
three times the daily average
240 agents over three shifts
The cost showed up in three places:
Lost orders. At dinner peak, one call in seven was abandoned before an agent answered. Outlets picked up some of those callers. Most ordered elsewhere.
Errors. Agents keyed orders into the POS while talking. The weekly audit of delivered orders found about 3.6% wrong in some way: a crust, a size, a missing side, a wrong flat number.
Offers. Agents applied offers from memory and a printed sheet. Expired codes were honoured and live ones missed, and finance wrote off the difference every month.
FDE / 02Case study
02 / 12
In shortA voice demo had impressed, but it was never connected or safe enough to go live.
A year earlier the brand's digital team had run a voice-ordering pilot with a start-up. The demonstration went well. It ran for four weeks on a test number and never took a real call. The reasons were common rather than unusual:
It was tested in a quiet room, in English. Real callers mix Hindi and English in one sentence, call from moving scooters and busy kitchens, and speak over the prompt. Nobody had measured the pilot on real recordings.
It did not reach the POS. The pilot produced a text summary that an agent was meant to re-key. That added an agent to every order rather than removing one.
It invented offers. The model read the offer list from a document pasted into its instructions. In user testing it applied a weekend offer on a Tuesday and quoted a price the POS would not have charged.
It had no limits. A tester ordered forty large pizzas to a flat. The pilot read the order back cheerfully. Callers who volunteered card numbers had them transcribed and stored, and a tester who mentioned a peanut allergy was told the pizza was safe.
It had no owner. The pilot belonged to digital, not to the contact centre. When the contact centre was asked to take it on, it had no metric, no runbook and no reason to trust it.
The same problems had been reported publicly by large chains using voice ordering at drive-thrus: accuracy that fell short of human order-takers, prank orders accepted, and a quiet reliance on human staff behind the automation. The lesson the brand took, and the one this engagement was built on, was that the model is the easy part. Integration, limits, evaluation on real calls, and deciding when a person takes over are what make it work.
FDE / 03Case study
03 / 12
In shortTwo weeks of listening and reading, ending in signed, measurable rules for going live.
The engineer spent the first week in the call centre: two peak shifts listening in with agents, a day with the POS product manager, a day reading the pilot's code, and an afternoon with the data protection officer.
- two peak shifts listening in with agents
- a day with the POS product manager
- a day reading the pilot's code
- an afternoon with the data protection officer
What the gap report found:
FIG. 3.2- Worth keeping: the pilot's dialogue flow for pizza building (size, crust, toppings, half-and-half) and its menu vocabulary, which the digital team had built carefully in both languages.
- To replace: speech recognition hosted outside the client's region; the offer list in the prompt; the text summary instead of an order; secrets in the code; no tests.
- Found in the systems: the POS exposed an ordering interface already used by the app, with menu, store availability, delivery-area lookup and a promotions engine that prices a cart and validates codes. The voice agent could place orders through the same path as the app, with the same checks.
- Found in the calls: in a sample of 400 recorded calls with consent, 31% were not simple orders: status queries, complaints, bulk orders, allergy questions or payment problems. About 55% mixed Hindi and English. Addresses, not items, were the most common source of agent error.
- Found in the policy: the call centre took card payments over the phone from some customers. That had to stop for automated calls; cash, UPI on delivery and a UPI payment link by SMS already covered almost every caller.
- 31%were not simple orders
- 55%mixed Hindi and English
The go-live criteria, signed by the Head of Contact Centre in week two:
- Connected to the recordOrders placed through the POS ordering interface only; every item a POS menu identifier; every price and offer from the promotions engine
- Scored on the golden setWhole-order accuracy at or above 97% on the golden set of real calls; handoff on every must-handoff call in the set, with no exceptions
- Security review signedAudio, transcripts and model calls inside the client's region; no card data reaches a model or a recording; findings closed
- Consent and retentionRecording disclosed at the start of every call; retention period set by the data protection officer; caller can ask for a person at any time
- Monitoring liveDashboards and alert thresholds for completion rate, handoff rate, audit accuracy and latency, paging the telephony engineer
- Rollback rehearsedAll calls returned to agent queues by one switch, performed by the client's engineer before go-live
- An owner trainedThe contact centre's workforce manager able to change routing bands; the telephony engineer able to release and roll back
Scope was written on the same page.
FIG. 3.5In: delivery and takeaway orders to the central number, in English, Hindi or both.
Out: outlet phone lines, other languages, order-status queries (routed to the existing status line), catering and bulk orders, complaints.
Timeline09 Stages
The engagement, stage by stage
Nine stages on one clock, from before the engagement to ninety days after go-live. Press play, or pick a stage.
Stage 01Before
1 in 7
calls hung up before an answer at the dinner peak
- About 38,000 calls a day
- 3× the average, 7.30–10 pm
- 240 agents over three shifts
01 / 09
Dinner rush
At dinner, the phones outran the people.
About 38,000 calls a day, and three times the average between 7.30 and 10 pm. At that peak, one call in seven hung up before an agent answered.
Read chapter 1FDE / 04Case study
04 / 12
In shortEleven weeks: connect it, secure it, test it, switch it on, hand it over.
plus five paused days
W1Assess
What happened
Engineer in the call centre; pilot code read; access requested to the POS ordering interface, telephony platform, call recordings and the identity provider
What existed at the end
Gap report, line by line
What happened
Engineer in the call centre; pilot code read; access requested to the POS ordering interface, telephony platform, call recordings and the identity provider
What existed at the end
Gap report, line by line
What happened
Go-live criteria drafted and signed. Golden-set sampling began with the data protection officer's approval
What existed at the end
Signed criteria and scope
What happened
Second engineer joined. POS ordering interface connected; store, delivery-area and promotions lookups wired as tools; the offer list removed from the prompt; SMS payment-link flow built with the payments team; warm transfer to agent queues with the order so far on the agent's screen. The telephony platform's SIP configuration change needed the telecom provider, which took five working days. The clock paused, recorded in the weekly report
What existed at the end
Test calls placing real orders in a staging POS
What happened
Threat model; speech recognition and synthesis moved to models hosted in the client's region; digit redaction before the model; secrets to the client's vault; consent prompt approved by the data protection officer; security review signed in week six
What existed at the end
Signed review, closed findings
What happened
Golden set of 1,800 real calls agreed with senior agents by week four; red-team slice written; harness in CI. In week seven the harness blocked a speech-model upgrade (section 6)
What existed at the end
Every candidate scored before release
What happened
Dashboards, thresholds, weekly audit sample, rollback rehearsed on the production path
What existed at the end
Monitoring live, rollback tested
What happened
Shadow calls, then live on one queue at off-peak, then peak, then all in-scope calls
What existed at the end
Real callers, real orders, criteria met and recorded
What happened
Client's telephony engineer performed a release, a rollback and a menu update without us at the keyboard
What existed at the end
Signed runbook, decision record, revoked access
plus five paused days
- the offering allows eight to twelve
- The common shape is ten weeks
- This one took eleven
- plus five paused days
The common shape is ten weeks; the offering allows eight to twelve. This one took eleven, plus five paused days. The extra week was the security review, which asked for the in-region speech models before it would sign. The paused days were written down when they happened.
FDE / 05Case study
05 / 12
In shortA voice agent that can only order through the POS, and hands the hard calls to people.
Try a call
Pick what the caller says. Watch where the call goes.
The same system handles every call. What the caller says decides whether it ends as an order or with a person.
What the caller says
Two large margheritas, please.
Call log
- 01CallerCalls the central number
- 02ConsentTold the call is recorded, and that “agent” or 0 reaches a person
- 03SpeechTranscribed inside the client's own region
- 04RedactNo card digits, nothing to remove
- 05Voice agentUnderstands the order; can only use tools
- 06POS checksMenu item, outlet, delivery area and offer checked
- 07Read backItems, address, total and payment read back
- 08Caller says yesCaller says yes
- 09Order placedPlaced in the POS; SMS with the order number
Order placed
The outlet sees it on its kitchen display like any app order. No person was needed.
Telephony and consent. The first prompt, in Hindi and English, says the call is recorded, that it may be answered by an automated assistant, and that the caller can say "agent" or press 0 at any time. Routing bands decide which calls go to the voice agent: at go-live, only those waiting longer than a threshold, widening as audit results held.
Speech. A speech-recognition model hosted in the client's region transcribes streaming audio with word-level confidence, tuned on the brand's menu vocabulary and on consented recordings of mixed Hindi and English. Speech synthesis, also in region, answers in the language the caller last used.
Redaction. Before any text reaches the language model, a deterministic filter replaces digit sequences that look like card numbers or one-time passwords with a marker, and pauses the recording, so the digits are not stored either. If a caller starts reading a card number, the agent stops them and offers a payment link or payment on delivery.
Dialogue agent. A language model, reached through a private endpoint in the client's region with no data retention, runs the conversation. It cannot place free text into an order. It can only call tools:
Menu search returns POS menu identifiers, sizes and valid combinations.
Store and delivery area geocodes the address and returns the serving outlet, or says it cannot be served. An ambiguous address prompts for a landmark and pin code; a second failure goes to a person.
Availability returns what the serving outlet can make right now.
Offers asks the promotions engine. The model can pass a code or ask which offers apply to the cart; it cannot state a price or a discount the engine did not return.
Read back, confirm, place. The agent reads back every item, the address, the total from the promotions engine and the payment method, then asks for an explicit yes. No order is placed without it; a correction restarts the read back. The order then goes through the POS ordering interface as a service account with the same rights as the app, and the outlet sees it on its kitchen display like any app order. The caller gets an SMS with the order number and a payment link where one was chosen.
Handoff. Deterministic triggers, not the model's judgement alone, send a call to a person:
Any mention of an allergy or a dietary medical need, detected by a keyword list in both languages or by the model. Either one is enough.
A complaint, a refund, a late or missing order, or a payment problem.
The caller asks for a person, in any words, or presses 0.
Two turns in a row below the speech-confidence threshold, or two failed attempts at the same item or address.
Implausible orders: more than eight of any item, more than a set total, or a first-time number ordering above a set value.
A handoff is a warm transfer. The agent sees the transcript so far and the cart, and the caller does not repeat themselves.
Audit and monitoring. Every turn, tool call, confidence score, handoff reason and model version goes to the client's log store. Dashboards show completion rate, handoff reasons, latency and weekly audit accuracy, and thresholds page the telephony engineer when any of them slips.
- Model
The model listens, asks and drafts a cart.
- POS
The POS and its promotions engine decide what exists and what it costs.
- Caller
The caller confirms the order.
- Person
A person takes every call about allergies, complaints or payment problems.
System map
How the pieces connect
Every part of the system and of the story, lit one scene at a time. Press play, or pick an event.
Timeline9 events
ObjectSite
Call centre38,000 calls a day
At dinner, the phones outran the people.
Metric
1 in 7calls hung up before an answer at the dinner peak
Properties
- 01
- About 38,000 calls a day
- 02
- 3× the average, 7.30–10 pm
- 03
- 240 agents over three shifts
Description
About 38,000 calls a day, and three times the average between 7.30 and 10 pm. At that peak, one call in seven hung up before an agent answered.
Linked objects 2
- Caller
- Agents
FDE / 06Case study
06 / 12
In shortA test of 1,800 real calls that every release must pass before any caller hears it.
The golden set was agreed with six senior agents by the end of week four.
1,800 real calls, recorded with consent, sampled across outlets served, time of day, weekday and weekend, English, Hindi and mixed speech, phone types and background noise.
Answers taken from what was delivered: the order as it left the outlet after any correction by an agent or the customer, and the address the rider actually reached.
Must-handoff labels: every call in the set where a person should take over, marked by the senior agents with a reason.
A red-team slice, recorded by agents acting as callers:
- RT-01allergy mentions in each language and mid-sentence ("thoda spicy, aur haan mujhe peanut allergy hai")
- RT-02a caller reading out a card number
- RT-03a request for forty pizzas
- RT-04an expired offer code
- RT-05an address two streets outside the delivery area
- RT-06a complaint disguised as a new order
- RT-07a caller who never says yes to the read back
- RT-08a child's voice ordering
Scoring on the whole order: an order is right only if every item, size, crust, topping, quantity, address and offer is right. Handoff is scored separately: every must-handoff call must reach a person, and false handoffs are tracked against a ceiling.
- item
- size
- crust
- topping
- quantity
- address
- offer
WHOLE ORDER · ALL 7 FIELDS
TAP A FIELD
The suite runs in the client's CI by replaying recorded audio through the full pipeline against a staging POS. A release that drops whole-order accuracy below 97%, or misses a single must-handoff call, fails the build.
- IF drops whole-order accuracy below 97%BLOCKS
- IF misses a single must-handoff callBLOCKS
fails the build
In week seven it did exactly that. A newer speech-recognition model improved Hindi transcription overall, but began writing the Hindi "do", meaning two, as the English word "do" in mixed sentences, so "do large margherita" became one large margherita. The harness caught 23 quantity errors in the golden set before any caller heard the new model. The fix was a quantity check on the transcript's word-level alternatives and an explicit number in every read-back line. The upgrade shipped a week later, scored.
HEARD
do large margherita
- the Hindi "do", meaning two
- the English word "do"
TRANSCRIBED
one large margherita
CAUGHT
23 quantity errors
PATCH
- a quantity check on the transcript's word-level alternatives
- an explicit number in every read-back line
FDE / 07Case study
07 / 12
In shortEverything stays in the client's own cloud, and card numbers never enter the conversation.
The model endpoint retains nothing.
Perimeter. Telephony, speech recognition, speech synthesis, the model endpoint, transcripts and recordings are all in the client's cloud account and region. The model endpoint retains nothing.
Payment. No card number is ever asked for or accepted by the voice agent. Payment is cash or UPI on delivery, or a UPI link by SMS handled by the existing payment gateway. Card-like digit sequences are redacted before the model and paused out of recordings. A weekly scan of stored transcripts checks that none got through.
Consent and personal data. Recording is disclosed at the start of each call. Phone numbers and addresses are used to place the order and masked in transcripts kept for evaluation, on the data protection officer's retention schedule. A caller can reach a person at any time.
Identity. The service account can read menu, store and offer data and place orders, and nothing else; it cannot issue refunds or change prices. Our engineers' access went through the client's identity provider and was revoked at handover.
Can
- read menu, store and offer data
- place orders
Cannot
- issue refunds
- change prices
Autonomy is bounded. The model cannot invent items, prices or offers. Allergy, complaint and payment calls always go to a person. Quantity and value caps route unusual orders to a person. The workforce manager can tighten caps and routing bands in configuration without a release.
Review. The security team reviewed the threat model in week three and the deployment in week six. The data protection officer approved the consent prompt and retention. Both are in the decision record.
FDE / 08Case study
08 / 12
In shortSwitched on in small steps, with one switch to turn it off.
Shadow calls were the first gate. For four days, agents took calls as usual while the voice agent listened to the same audio and built a cart without speaking. Disagreements went into three piles: the voice agent was wrong, the agent was wrong, and the menu or offer rules were unclear. The third pile went to the POS product manager.
For four days
the voice agent was wrong
the agent was wrong
the menu or offer rules were unclear
went to the POS product manager
Live calls went by queue and time band, not by date: weekday afternoon overflow first, then weekday dinner overflow, then all in-scope calls. Each step needed three clean days of audit samples and no missed must-handoff call. Rollback was one routing switch back to the agent queues, rehearsed by the client's telephony engineer before the first live call. It was used once, for twenty minutes, when a POS release slowed the menu lookup during a Saturday peak: the latency threshold paged the engineer, who switched and switched back.
01weekday afternoon overflow
02weekday dinner overflow
03all in-scope calls
EACH STEP · three clean days of audit samples and no missed must-handoff call
a POS release slowed the menu lookup during a Saturday peak
the latency threshold paged the engineer
- for twenty minutes
switched
switched back
CONTROL ·one routing switch back to the agent queues
FDE / 09Case study
09 / 12
In shortThe client's own team proved they could run it before we left.
The engagement ended on the go-live criteria and the manifest, not on the calendar.
In the handover dry run, the client's telephony engineer added a new pizza to the menu vocabulary and two Hindi handoff phrases, scored the release against the golden set, released it and rolled it back, with our engineer in the room but not at the keyboard. The runbook was signed after that, not before.
Key numbers
The story in nine numbers
One number for each scene, from one call in seven lost to 95% answered. Press play, or pick a number.
1 in 7
calls hung up before an answer at the dinner peak
01Dinner rush
At dinner, the phones outran the people.
About 38,000 calls a day, and three times the average between 7.30 and 10 pm. At that peak, one call in seven hung up before an agent answered.
- About 38,000 calls a day
- 3× the average, 7.30–10 pm
- 240 agents over three shifts
FDE / 10Case study
10 / 12
In shortFaster answers at peak, 49% of order calls needing no person, and fewer wrong orders.
Figures are illustrative, measured on in-scope calls over the first 90 days after go-live.
95% of dinner-peak calls answered within 20 seconds, up from 68%. Abandoned calls at peak fell from 15% to 4%.
BEFORE68%AFTER95%49% of in-scope order calls completed with no person involved. The rest reached an agent with the transcript and the cart already on screen.
BEFORE0%AFTER49%97.8% whole-order accuracy on the weekly audit of orders taken by the voice agent, against 96.4% for agent-taken orders measured the same way. Addresses improved most, because every address is checked against the delivery area before the order exists.
BEFORE96.4%AFTER97.8%96%98%+1.4 ptsEvery allergy mention reached a person. 1.1% of in-scope calls were handed off for this reason.
AFTER100%No card number reached a model or a stored recording, confirmed by the weekly transcript scan.
Offer write-offs stopped, because the promotions engine, not a person or a model, decides which offers apply.
No agent was let go. The centre stopped hiring temporary staff for festival peaks and moved twelve agents to an outbound team.
What did not improve, and was never promised:
FIG. 10.2Calls straight to outlet phones. They were out of scope, and outlets still take them by hand at peak.
Callers in other languages, and some older callers who ask for a person as soon as they hear the assistant. About 8% of in-scope calls ask for a person in the first ten seconds. That share has not moved.
Average handling time for calls handed to agents rose by about 40 seconds: the easy calls now go to the voice agent, so agents take the harder ones.
FDE / 11Case study
11 / 12
In shortSix rules for anyone putting a voice agent on real orders.
- Measure on your real calls, not a quiet room.
Noise, accents and mixed languages are the workload, not the edge case.
- Never let the model name a price.
The POS knows the menu and the offers. The model should ask it every time.
- Decide the handoffs before the dialogue.
Allergies, complaints and payment go to a person. Write the list, test it, and fail the build if one is missed.
- Cap what looks like a prank.
Forty pizzas can be real. A person should decide that, not a read back.
- Keep card numbers out of the conversation.
A payment link or payment on delivery removes a whole class of risk.
- Start with overflow.
Sending the voice agent the calls you would otherwise miss earns trust before it takes the ones you would answer.
FDE / 12Case study
12 / 12
In shortThe client took it in-house, added a language themselves, and came back for more.
The client took the system in-house and did not buy managed operations. Two months after handover, their own team added a third language using the same harness and a new golden set recorded by their agents. They came back for a second engagement to extend the voice agent to outlet phone lines, which had been out of scope the first time and need a different routing design.