The requirement starts with front-desk staff handling checkout, vehicle handover, walk-in customers and phone calls at the same time.
ANONYMIZED REAL-WORLD SPECIFICATION
AI phone system for a multi-site auto repair network
An anonymized real-world requirement: reduce front-desk call load across an auto repair network, route by location and service, send booking/quote flows by SMS, handle vehicle-status calls and enforce strict no-pricing/no-diagnosis guardrails.
AT A GLANCE
Reduce front-desk call load without letting AI improvise on mechanical issues.
The requested location and call intent determine the destination: workshop, body shop, accounting, roadside assistance or a specific branch.
Booking, quote and diagnostic requests are redirected to web or scheduling flows sent by SMS.
For vehicle-status calls, the assistant captures the caller name and license plate before attempting workshop transfer.
CALL FLOWS
Five flows separating automation, transfer and hard guardrails.
The specification does not ask for an assistant that answers everything. It defines when the system can act, when it must transfer and when it must refuse to answer.
01
Service, inspection or tires
- Incoming request
- The caller wants to book routine maintenance or a periodic inspection.
- Decision
- The assistant identifies the standard service need and the requested location.
- Outcome
- An SMS immediately sends the scheduling link for the relevant location.
02
Pricing or quote: do not answer by phone
- Incoming request
- The caller asks for a price, estimate or quote.
- Decision
- The rule explicitly prohibits the assistant from giving pricing or estimates.
- Outcome
- The caller is redirected by SMS to the online quote form.
03
Mechanical question: no diagnosis
- Incoming request
- The caller asks about breakdown severity, a warning light or a repair recommendation.
- Decision
- The assistant provides no technical advice and does not diagnose the vehicle.
- Outcome
- An SMS redirects the caller to book an in-shop diagnostic appointment.
04
“Is my car ready?”
- Incoming request
- A customer calls to check the status of a vehicle already in the shop.
- Decision
- The assistant asks for the caller name and license plate before routing the call.
- Outcome
- The call is transferred to the workshop manager at the relevant location.
- Fallback
- If the workshop does not answer, the captured name and plate are used to send a written alert to the workshop manager.
05
Specialized service or specific location
- Incoming request
- The call concerns a claim, body repair, business billing, urgent roadside assistance or a specific branch.
- Decision
- The assistant applies the configured destination for the identified service or branch.
- Outcome
- Body-repair calls go to the centralized body shop, billing to finance, roadside emergencies to the on-call mobile line and branch requests to that location’s internal line.
CONTEXT
Phone calls compete directly with in-person service.
In the documented network, front-desk staff combine checkout, vehicle handover, in-person customer handling and inbound calls. Absences, leave and unexpected staffing gaps make that load harder to absorb.
Calls interrupt the counter
The requirement starts from a straightforward operational conflict: answering the phone pulls front-desk staff away from customers already on site.
Calls can go unanswered
When the front desk is busy or understaffed, the document describes calls ringing without useful handling or going unanswered.
Stated objective: remove inbound calls from the front desk
The specification states an objective of removing 100% of inbound-call handling from the front desk. This is a design objective, not a measured outcome.
GUARDRAILS
Two hard prohibitions shape the assistant’s behavior.
The scope is deliberately constrained. The assistant can greet and route callers, but must never substitute for a quote or a mechanical diagnosis.
No price, estimate or quote
Any pricing request leaves the voice flow and moves to the online quote tool delivered by SMS.
No technical advice
The assistant does not assess breakdown severity, warning lights or recommended repairs.
A useful next step instead of a dead end
Each refusal triggers a concrete next step: online quote or booking an in-shop diagnostic.
BOOKING
Identify the location, then send the right schedule by SMS.
For standard requests—inspection, service or tires—the requested flow avoids human intervention during the call.
Identify the service need
The assistant distinguishes routine maintenance and periodic inspection needs before continuing.
Identify the branch
The requested location is a required routing input because each branch can have its own schedule.
Send the matching link
The expected next step is an immediate SMS containing the relevant branch’s Calendly or scheduling link.
ROUTING LOGIC
Clarify when needed. Transfer when the destination is clear.
The interesting part is not the number of rules. It is the ability to combine direct routing, clarification, fallback and escalation in one consistent flow.
WORKSHOP STATUS
Capture the license plate before transferring to the workshop.
The “is my car ready?” flow adds minimal qualification before transfer so the workshop has useful context if follow-up is needed.
Caller name
The caller identity is captured before routing to the workshop manager.
License plate
The license plate acts as an operational identifier for the vehicle concerned.
Written fallback if no one answers
If the transfer fails, the captured information must be usable as a written alert for the workshop manager.
NETWORK ROUTING
The right destination may be local, centralized or on-call.
The network mixes different destination types, so routing must understand both the requested service and the group’s operating model.
Body repair and claims
These calls are routed to a centralized body shop rather than handled independently by each branch.
Accounting and business billing
Business billing and administrative requests are routed to the configured finance team.
Urgent roadside assistance
The requirement calls for direct transfer to the roadside-assistance on-call mobile line.
Specific branch request
When a caller explicitly requests one location, the call should reach that branch’s internal line rather than a generic destination.
HOW TO READ THIS CASE
The document describes a target operating model, not achieved performance.
The specification precisely documents desired call flows and business restrictions. It contains no measured answer-rate, missed-call reduction or productivity outcome.
Objective ≠ outcome
Complete front-desk offloading is a stated target. This case study does not present it as achieved.
Product performance stays separate
Latency, intent accuracy, task completion and transfer performance remain documented in the separate Kalyvox Voice Benchmark.
OPERATIONAL PRINCIPLE
A useful phone system does not just answer. It knows what should happen next.
VALIDATE BEFORE GO-LIVE
Routing depends on location-specific configuration.
Operational reading of the specification: several parameters need unambiguous configuration for the assistant to apply the correct destinations and guardrails.
Map each branch to its schedule
The booking link sent by SMS must match the location identified during the call.
Map each branch to its workshop manager
The vehicle-status flow depends on a correct transfer destination for the relevant branch.
Define the no-answer alert channel
The fallback must deliver the caller name and license plate to the correct manager when the workshop does not answer.
Make guardrails higher priority
A pricing or diagnosis request must trigger the configured deflection before any attempt to answer the underlying technical question.
Keep the on-call destination current
Roadside-assistance routing must point to the currently active on-call mobile line.
In an auto repair network, assistant limits are part of the routing design.
The points below are derived from the requested workflows. They are not measured performance outcomes.
Refusal can be a business action
Not giving a price or diagnosis is not bot failure: the intended flow is to refuse and then send the correct next step by SMS.
Location is a routing key
Intent alone is not always enough. Booking and workshop-status flows also require the relevant branch.
Context should survive a failed transfer
Capturing name and license plate before workshop transfer allows a failed transfer to become an actionable follow-up.
SOURCE FRAMEWORK
A real requirement, fully anonymized.
Names, companies, locations, phone numbers, email addresses and identifying details have been removed. Only operational elements useful for understanding the phone architecture are retained.
Browse other studies