The client
A device maker whose customers are clinics
A manufacturer of medical-aesthetics and physiotherapy devices, selling to clinics and practitioners in many markets. Its customers buy expensive equipment, train their staff on it and depend on it working every day.
That makes every conversation matter — before the sale, during onboarding and whenever a device misbehaves.
The challenge
Sales, service and engineering sharing one queue
Every message waited for a person, and the right person was usually busy with a different kind of message. Demo requests sat behind training questions. Engineers answered the same documentation queries again and again. Leads waited behind support tickets.
The surface area
The answers existed — in product sheets, training material and technical manuals. Getting them to the customer quickly did not.
Constraints
What we had to design around
- Three jobs, one inboxA buyer asking for a demo, a practitioner looking for a training video and a technician with a fault code all write to the same WhatsApp number. Each needs a different answer, from a different team, at a different speed.
- Leads go coldA clinic comparing devices does not wait a day for a reply. Qualifying the lead and offering a demo slot had to happen inside the first conversation, and land in the CRM without anyone retyping it.
- Medical equipmentDevice advice is not small talk. Troubleshooting had to come from the technical manuals, not from what a language model remembers, and anything beyond the manual had to reach an engineer.
- Many languagesCustomers write in their own language, and the documentation does not always exist in it. The agents had to search across languages and answer in the one the customer used.
- Room to growNew markets and new channels were coming. Adding an agent or a channel had to be an addition, not a rebuild.
Our approach
One front door, three specialists behind it
A single chatbot that sells, answers FAQs and troubleshoots devices does all three badly. The sales conversation needs to steer towards a demo. The technical one needs to stay inside the manual. Mixed together, neither is reliable.
So we split the work. A triage agent reads each message and sends it to the specialist that owns it, each with its own flows and tools. All of them read one knowledge base, so a product described by the sales agent matches the one in the technical manual.
The solution
Five layers, from a WhatsApp message to a CRM record
- Channels — WhatsApp Business and a web chat interface, both talking to the same API. A customer gets the same answer wherever they ask.
- Triage agent — Classifies each message — sales, service or device fault — and routes it to the specialist that owns it. A response generator writes the reply back to the channel it came in on. Built on Agno.
- Sales assistant agent — Runs the qualification conversation, recommends products, offers demo slots from the sales team’s calendars and writes the qualified lead into the CRM.
- Customer FAQ and technical support agents — The FAQ agent answers on training, products and documentation in the customer’s language. The technical support agent walks through device troubleshooting from the manuals and, when that is not enough, logs an incident ticket in the service platform. An escalation agent hands anything else to a person with the conversation attached.
- Shared knowledge base — Product, training and technical documentation, customer data and conversation history, embedded with multilingual preprocessing and searched with GraphRAG. Every agent reads the same source.

Responsible by design
Four rules for agents that talk to clinics
Ground
Device answers come from the manual.
The technical support agent retrieves the relevant manual section before it answers. If the documentation does not cover the fault, it says so and opens a ticket.
Escalate
The agents know where their job ends.
A dedicated escalation agent hands complex faults, complaints and anything off-script to a person — with the full conversation, so the customer never repeats themselves.
Guard
Guardrails sit between every agent and the customer.
Replies pass through guardrails before they are sent, and customer feedback is logged against each conversation so weak answers surface quickly.
Record
Nothing said in a chat is lost.
Qualified leads go to the CRM, faults go to the service platform, and conversation history stays with the customer for the next contact.
The second rule matters most. The point is not to keep customers away from people. It is to make sure that when they reach one, it is the right one, and the groundwork is done.
Results
What changed for customers and teams
- 70% of routine customer queries handled automatically — demo requests, training and documentation questions and first-line device faults are resolved by the agents end to end.
- 60–70% shorter response times, because every message is triaged and routed the moment it arrives instead of waiting for the right person to see it.
- 50% higher operational efficiency — leads reach sales already qualified and in the CRM, and tickets reach engineers with the troubleshooting already done.
- 25% lower customer service cost within six months, on an architecture built to take more agents, markets and channels.
Sales spends its time on qualified leads. Engineers spend theirs on the faults the manual does not cover.
Beyond the numbers
What else changes
Every conversation now leaves a record someone can use. Which products clinics ask about before buying, which faults recur on which device, which training topics confuse practitioners — questions nobody had time to answer from a shared inbox now sit in the CRM, the ticket log and the conversation history.
And because each agent owns one job, the next market or the next channel is configuration plus, at most, one more specialist.
If your sales leads wait behind support tickets
The first question is what share of your inbound messages are routine. A week of conversations answers that, before anything gets built.