Multi-Channel Chatbot Routing WhatsApp and Website Enquiries into One Backend

A UK healthcare services clinic had two digital front doors: a website chat widget and a WhatsApp number. Both were useful. Both generated real enquiries. Together, they created an operational mess. The team had to check two places, compare partial conversations, work out whether two messages were from the same person, and decide who should reply.

The client did not ask us for a smarter chatbot. They asked for a cleaner handover. The clinic needed a backend that could receive messages from both channels, classify the intent in the same way, capture consent, log the conversation and route a clear summary to the right team member. The value was not more chat. The value was one operational view.

The problem

The website widget was good at catching people while they were browsing service pages. WhatsApp was better for people already close to taking action, especially on mobile. The problem was that each channel created a different shape of handover. One produced short structured snippets. The other produced informal messages, screenshots, voice-note summaries and follow-up questions.

The team had no consistent triage layer. A website enquiry about pricing might be sent to reception, while the same intent on WhatsApp might sit with a manager because it looked more urgent. A nervous patient asking about suitability might be treated as a general question in one channel and a booking lead in another. The inconsistency made workload unpredictable and created room for missed context.

Duplicate enquiries were the quiet drain. A person would ask a question on the website, then send a WhatsApp message thirty minutes later because they wanted a faster reply. The team saw two entries, not one journey. That meant repeated questions, awkward replies and occasional confusion about whether consent had already been captured.

The approach

We started by defining the intents the clinic actually needed to route. We kept the list practical: new booking, pricing question, suitability question, urgent concern, existing patient follow-up, complaint, document request and out-of-scope message. The aim was not to label every nuance. It was to give the team enough structure to act quickly.

Then we built the normalisation layer. Messages from the website widget and WhatsApp provider arrive in different formats, so the backend turns them into a common event shape: channel, contact details, message text, timestamp, consent state, conversation history and source page where available. Once messages share that structure, the same AI classifier can process both channels.

The classifier assigns intent, urgency and routing recommendation. It also writes a short human-readable summary. That summary matters because staff do not want a raw transcript when they are busy. They need the point: what the person wants, what channel they used, whether consent has been captured, and who should reply.

Consent capture was built into the journey instead of being treated as an afterthought. If the clinic needs permission before follow-up, the system records whether consent was given and includes that status in the routed summary. That reduced the chance of staff replying from habit without checking the compliance detail.

What the system actually does

When a message arrives from either channel, the backend logs it, links it to an existing conversation where possible, and sends it through the AI classifier. The system decides the intent, checks for urgency signals, records consent status and prepares a concise summary for the team.

The routing rules then send the right notification to the right place. A booking-ready enquiry goes to the front desk. A suitability question goes to the treatment coordinator. An urgent concern is marked clearly so it does not sit inside the normal queue. Every routed message includes the conversation history, so the human reply starts with context.

The team can review conversation logs across both channels. That gives managers a better view of volume, common intents, handover quality and gaps in website content. If the same question keeps appearing, the clinic can improve the page or template rather than answering it manually forever.

We kept the staff experience deliberately plain. The routed summary is short, the owner is clear, and the consent state is visible before anyone replies. That sounds basic, but it is what makes the system usable during a busy clinic day. No one wants to read a long machine-written report before deciding who should answer a simple enquiry.

The outcome

Two channels now feed one backend: the website widget and WhatsApp. The same classifier logic handles intent across both, which means the team is no longer making routing decisions based on where the message arrived. Around 70 percent of enquiries are triaged before human review, so staff start with a summary and suggested owner instead of an unstructured inbox.

The anonymised client described the change like this: “We still speak to people ourselves, but now the message arrives in the right place with the context attached. We are not piecing the story together from two screens.”

What we would do differently next time

We would spend more time on duplicate detection in the first version. Matching by phone number and email address worked for many cases, but not all. Some people used a website widget without contact details and then moved to WhatsApp later. The next version would use softer signals, such as timing, service interest and repeated wording, while still avoiding risky assumptions.

We would also define escalation language earlier. The routing worked, but the wording of urgent notifications needed tuning so staff treated genuine urgent concerns differently from high-intent sales enquiries. In healthcare services, that distinction matters operationally and ethically.

The main lesson is that channel projects should be designed around the team, not around the widget. A chatbot that answers a question is useful. A routing layer that gives staff one clean view of demand is often more valuable.

For clinics with WhatsApp and website chat running side by side, the next step is usually not another inbox. It is one backend that makes both channels behave like part of the same operation.