The request determines the destination, not a fixed keypad menu.
ANONYMIZED REAL-WORLD SPECIFICATION
Multi-site AI phone system for transport and logistics
An anonymized real-world requirement: centralize a multi-site phone system with around twenty routing rules, four languages, schedules, on-call handling, transfers and messages.
AT A GLANCE
One phone number. Several sites. Different rules for different calls.
The same operating logic must hold across French, English, Spanish and German.
Business hours, closures and on-call handling trigger different flows.
Each handled call is expected to leave a usable written record.
CALL FLOWS
Five scenarios that show where the real complexity sits.
The rule set does more than map a keyword to a number. It includes clarification questions, unavailability rules and different behavior depending on urgency and time of day.
01
Operations: resolve ambiguity
- Incoming request
- The caller asks for “operations” without identifying the relevant entity.
- Decision
- The agent asks a clarification question to identify the relevant operating branch.
- Outcome
- The call is then transferred to the corresponding operations team.
02
Accounting: customer or supplier?
- Incoming request
- The caller simply asks for accounting.
- Decision
- The agent must distinguish customer accounting from supplier accounting before routing.
- Outcome
- The destination changes with the answer instead of sending every accounting call to the same contact.
03
Breakdown or accident: time changes the outcome
- Incoming request
- A call concerns a breakdown, accident or service request.
- Decision
- The phone system checks whether the call arrives during business hours or a closed period.
- Outcome
- During business hours the flow targets the relevant service; after hours it offers transfer to the on-call service.
04
Executive call: message by default, escalation if urgent
- Incoming request
- The caller asks directly for a member of the executive team.
- Decision
- The default path is message taking and callback unless the caller explicitly states an urgent need.
- Outcome
- A declared urgent request can be escalated to reception instead of being handled as a direct transfer.
05
Destination unavailable: keep a clear fallback
- Incoming request
- The correct contact has been identified but the destination does not answer.
- Decision
- The agent offers structured message taking and checks whether the situation is urgent.
- Outcome
- The flow ends with a prepared callback; if urgent, it can be escalated to reception.
CONTEXT
Centralizing calls for a transport group operating across several sites.
The specification describes one main phone system shared by several activities and locations. The answering layer must identify the need, determine the right destination and keep a consistent caller experience across different teams.
One entry point
A main phone number centralizes calls intended for several entities, departments and contacts.
Several sites
Destinations are spread across several locations, with fixed and mobile lines selected according to the reason for calling.
A B2B environment
The answering experience must remain professional and understand vocabulary specific to transport, operations and service requests.
REQUIREMENTS
Answer, qualify, route and leave an actionable record.
The requirement goes beyond replacing voicemail. The phone system must apply business rules from the first interaction and adapt the next step.
Consistent answering
The stated objective is to answer inbound calls without excessive waiting and avoid leaving a call untreated.
First-contact qualification
The assistant must understand the requested department, person or reason before applying the corresponding rule.
Post-call record
Each handled call must produce a written summary with the context the team needs for follow-up.
ROUTING
Around twenty business routing rules instead of a fixed phone menu.
The initial rule set maps naturally expressed requests to an action: direct transfer, clarification question, message taking or escalation.
Clarify before transfer
Some generic requests, such as operations or accounting, require an additional question to identify the correct entity or team.
Transfer directly
When a reason clearly matches one destination, the system should route the call to the configured number.
Handle unavailability
If the destination does not answer, the flow must be able to switch to message taking, with a different rule when urgency is declared.
Keep rules editable
Adding, changing and removing routing rules must remain manageable without heavy technical dependency.
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.
SCHEDULES & ON-CALL
The same phone number, with different behavior depending on when the call arrives.
The specification distinguishes business hours, breaks, evenings, weekends, public holidays and exceptional closures.
During business hours
The system greets the caller, identifies the request and applies the corresponding transfer or message rule.
Outside business hours
Routine requests switch to message taking for later follow-up.
On-call service
An after-hours service request follows a dedicated flow that can offer a transfer to the on-call destination.
MULTILINGUAL
Four languages through the same answering layer.
French remains the primary language. English, Spanish and German must also be supported, with language detection or switching during the conversation.
Language detection
The answering layer must be able to recognize the caller’s language or switch when requested.
Business rules remain consistent
Changing language must not alter routing, schedules or the operational logic of the scenario.
MESSAGES & REPORTING
Every handled call should leave actionable context.
Message taking and reporting are part of the initial requirement, including when a transfer occurred or the call arrived outside business hours.
Structured message
Available identity, company, callback number and reason should be structured rather than left in an unstructured voicemail.
Systematic summary
The expected record includes timestamp, useful contact details, identified reason, action taken and a transcript or summary.
Monitoring indicators
The planned reporting includes call volume, answer rate, reason distribution, successful transfers, average handling time and messages taken.
OPERATIONAL PRINCIPLE
A useful phone system does not just answer. It knows what should happen next.
TECHNICAL CONSTRAINTS
Existing telephony, low latency, administrative autonomy and continuity.
The required setup must integrate with existing telephony, transfer to multiple destinations and remain manageable by the organization’s teams.
Telephony compatibility
The system must work with the existing line and carrier and route calls to several fixed or mobile destinations.
Voice responsiveness
End-to-end latency must remain low enough to preserve a natural conversation.
Self-service administration
Messages, transfer rules, destinations, schedules and calendar exceptions should be editable without heavy intervention.
Service continuity
The requirement also includes a fallback mechanism if the solution becomes unavailable.
HOW TO READ THIS CASE
This page describes a real requirement, not performance results.
This study is based on a fully anonymized real-world business specification. It presents requirements, rules and expected indicators without attributing undocumented performance results to the organization.
Objectives are not results
Answering every call, reducing front-desk workload or improving routing are stated objectives in the specification, not measured gains.
Separate benchmark
Kalyvox latency, intent-accuracy and task-completion measurements come from a separate product benchmark, independent from this case study.
VALIDATE BEFORE GO-LIVE
The specification requires as many safeguards as features.
These are not measured outcomes. They are explicit requirements for keeping a multi-site phone system operational day to day.
Control overly long calls
A four-minute maximum call duration is specified. The behavior beyond that point must be defined: progressive closure, message capture or another controlled exit.
Understand industry vocabulary
Recognition needs to remain robust for terms such as operations, freight forwarding, exceptional convoy, on-call service, tanks or silos, including in imperfect acoustic environments.
Integrate with existing telephony
The requirement is to keep the existing phone setup and transfer to multiple fixed and mobile destinations across several locations.
Handle exceptional closures
Teams need to be able to change schedules, messages, destinations and calendar exceptions such as public holidays or seasonal closures.
Keep a real fallback path
The specification requires continuity behavior if the solution is unavailable, with fallback to voicemail or reception.
Govern voice, transcripts and history
Caller disclosure, limited retention, data access, GDPR rights and transcript security are all part of the stated compliance scope.
This case shows why voice routing quickly becomes a rules problem, not just an answering problem.
Kalyvox reading of the specification: three lessons emerge from the requested structure, without presenting them as achieved outcomes.
The right question can matter more than a transfer
Two common intents explicitly require clarification before routing. Quality therefore depends as much on disambiguation as on the ability to transfer.
Availability and intent need to be evaluated together
The same service request follows a different path depending on time of day. The decision engine therefore combines intent, calendar context and urgency.
Reporting is part of the phone system
The requirement includes tracking call volume, answer rate, reasons, successful transfers, duration and messages. The phone becomes an operational data source, not only a conversation channel.
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