The Liveline journal
Route the intent, not just the inbox
Design conversation routing around the help a customer needs, while preserving the channel and account where the conversation began.
- routing
- operations
A customer asking for a quote on Instagram may need the same team as someone asking on WhatsApp. Meanwhile, two messages in the same inbox may have entirely different destinations: a new service inquiry and a problem with work already completed.
Separate where a conversation arrived from what needs to happen next. The channel tells you where to reply. The customer's intent helps you decide who should handle it.
Begin with a few clear destinations
Sketch your routing policy around responsibilities your team already understands. A small service business might begin with new inquiries, existing-customer support, and a general fallback.
| Intent | Destination | Useful context |
|---|---|---|
| Exploring a service | New inquiries | Service needed, relevant location, preferred timing |
| Asking about existing work | Customer support | Reference if available, question, what changed |
| Unclear or mixed request | General triage | Customer's own description and one clarifying question |
These are suggested responsibilities, not a requirement to create three people or three agents. One person may cover several destinations. What matters is that each destination has a defined purpose and a way to handle requests outside that purpose.
Write descriptions that distinguish the routes
A label such as “Sales” is shorthand for your team, but it leaves plenty of room for interpretation. Describe the work in plain language:
New inquiries: Help people exploring a service for the first time. Explain the offering and collect the information needed for a quote. Requests about an existing job belong with customer support.
That final boundary matters. Two routes that both claim to “help all customers with questions” provide no useful distinction.
Liveline uses agent roles and natural-language routing descriptions to guide routing. Treat those descriptions as operational instructions: specific enough to distinguish responsibilities, short enough for your team to review, and updated when responsibilities change.
Preserve the return address
Routing should not detach a conversation from the account where it began. If a business connects multiple numbers or social profiles, the person handling the request still needs to know which business presence the customer contacted.
Preserve the incoming channel and account.
Use the request to select a responsibility.
Keep the thread and its history available.
Liveline binds conversations to their originating channel account so outbound replies use that account. This does not mean a person contacting you on two platforms automatically becomes one merged conversation. Design your process around the identity and history your system actually has.
Give uncertainty a destination
“Can you help with the installation you quoted last week?” contains both a sales reference and a possible support request. The right move may be one clarifying question: is the customer ready to proceed, or asking about an installation already completed?
A fallback route should make progress on that uncertainty. Define what it can ask, what it can answer, and when it should bring in a person. Avoid designing a loop in which several specialists repeatedly send the same request back to each other.
Customers should not need to understand your internal departments to get an answer. Let them describe the problem in their own words.
Review a small set of real conversations
Create a review set from representative messages with personal details removed. Include a clear request for each destination, an ambiguous request, an existing-customer message that mentions buying something, and an explicit request for a person.
Write down the expected destination before testing. Then compare the route taken and the next reply. A technically correct route can still produce a poor experience if the receiving assistant asks for information already in the thread.
Change one unclear description at a time and repeat the review set. Add new examples when your team finds a recurring mistake. Good routing is a maintained operating policy, not a one-time choice of department names.
For the moment a specialist needs a person, continue with designing a useful human handoff.
