Answer the questions your team answers forty times a day, without guessing at the ones that matter.
We automate the support work that is genuinely repetitive and route the rest to a person with the context attached, because the expensive failure in support is a confident wrong answer.
Where an answer is found today, illustrative. No figure on this page is read off this drawing.
Four handoffs that make support slower than the work requires.
None of these is a chatbot problem. A conversational surface on top of them makes the same retrieval failure faster and more public.
The same question, answered from scratch
An agent finds the answer in a document, a past ticket or a colleague, and that retrieval happens again the next time the question arrives.
Tickets that only need routing sit in a queue
A request that a rule could classify waits behind requests that need judgement, and both get slower.
The answer exists and the agent cannot find it
Information is spread across a help centre, a wiki, a shared drive and one person who has been there longest.
Resolution needs another system
The agent knows what to do and has to open two more tools to do it, so the handling time is mostly navigation.
The cost is not only handling time.
Response time becomes the product
For a customer comparing suppliers, how fast you answer is often the only difference they can actually observe before buying.
Senior people absorb the overflow
Escalation is the release valve, so the most expensive people spend their day on questions that were answered last week.
The knowledge stays in individuals
When the person who knows leaves, the answer leaves. That is a business risk carried as a staffing convenience.
You cannot tell which questions matter
Volume is visible, patterns are not, so the product never learns what keeps confusing people.
What the workflow looks like afterwards.
The same ticket, followed twice: the route it takes today and the route it takes afterwards. The numbers pair the two where you want to compare them.
Every question is triaged by a person.
Answers are reconstructed per ticket.
Uncertain cases are answered anyway.
Resolution needs several tools.
Nobody knows which questions repeat.
Rule-classifiable requests are routed on arrival; people see the ones needing judgement.
Approved answers are retrieved from named sources, with the source shown.
Uncertain cases stop and reach a person with the case context already gathered.
The action happens where the agent already is, within permitted boundaries.
Recurring questions are visible, so the product or the help content can be fixed at source.
What to automate, what to assist, and what to leave with a person.
Support automation fails when the split is drawn by volume instead of by consequence. The question is not how often something is asked. It is what a wrong answer costs.
Automate
- Automate the answer
Factual, stable, and answerable from an approved source
The answer does not change, and showing its source makes it checkable.
Assist
- Automate the retrieval, a person sends
Repetitive but account-specific
The lookup is the work; the judgement about this customer is not.
- Automate with a confirmation step
Needs a system action within a clear rule
Reversible actions can proceed; irreversible ones should pause.
Leave with a person
- Person, immediately
Emotionally charged, or the customer is already unhappy
A correct answer delivered by a machine to an angry customer is still a bad outcome.
- Person, always
Anything involving money moving, or a legal commitment
The cost of being wrong is not proportional to the cost of the question.
- Leave it, and record that you did
Rare and complex
Automating the long tail costs more to maintain than the time it recovers.
The last two rows are where most of the argument happens. A support automation that quietly handles refunds is not a productivity gain, it is an unmanaged liability.
How the work runs, step by step
Read the last few hundred real tickets
Not a summary. The actual mix, including the ones that went badly, because the exception pattern is the design input.
Agree the approved answer sources
Which documents are authoritative, who owns them and what happens when they do not cover a question. The third is the part usually missing.
Draw the consequence split
The table above, filled in against your actual request types, with a named owner for the cases that must stop.
Build the narrow version first
One request type, end to end, including the stop condition. A narrow system that is trusted beats a broad one that is checked.
Feed the recurring questions back
Into the help content and the product. The point is fewer questions arriving, not faster answers to the same volume forever.
Where this work has been done
Customer-facing answer quality and production controls are the two things this work depends on, and both are in delivered Viithiisys work.
Conscious Chemist, product-question response
A documented 38% faster product-question response in a customer-facing product experience.
That is a product surface rather than a support desk.
Fitelo, evaluation and cost controls in production
An AI product running with evaluation and cost controls rather than shipped and watched.
The same discipline this page requires before an answer reaches a customer.
Vizitor, in daily multi-site use
In production at scale: 500+ workplaces across 15+ countries.
Deflection rate is the wrong measure, and it is the one every vendor reports.
The usual advice is to measure deflection, the share of contacts resolved without a person. It is the easiest number to produce and it can rise while service gets worse.
Deflection rate
What it appears to showFewer contacts reaching people
Read it withRepeat-contact rate within 48 hours
The least deceptive single choiceHow it misleadsA customer who gave up is counted as deflected. So is one who got a wrong answer and did not realise
First-response time
What it appears to showFaster service
Read it withTime to actual resolution
How it misleadsAn instant automated reply that answers nothing improves this while resolving nothing
Automation coverage
What it appears to showBreadth of what is handled
Read it withCoverage weighted by volume
How it misleadsCoverage of rare questions costs maintenance and recovers little time
CSAT on automated interactions
What it appears to showCustomers are satisfied
Read it withAbandonment rate inside the flow
How it misleadsOnly the people who completed the flow are surveyed. The ones who abandoned are absent
Agent handling time
What it appears to showEfficiency gain
Read it withVolume mix, not just the average
How it misleadsFalls if easy cases are removed, even when nothing improved for the customer
The pairing in the last column is the point: each measure is usable beside its counterweight and misleading alone. If only one is reported, make it repeat-contact rate.
What this connects to, and who builds it
Support automation borders several other services. Each row names the part of the problem and the page that covers it.
- The conversational surfaceAI Chatbot DevelopmentA customer-facing answering experience
- Multi-step work with permitted actionsAI Agent DevelopmentWhere the case needs context gathered and actions taken
- Connecting to your existing systemsAI IntegrationLanding results in the ticketing or CRM system
- If the answers are not reliable yetData EngineeringThe constraint is source information, before it is anything else
- If the problem crosses channelsCustomer Experience AutomationWhere the customer has to repeat themselves between channels
- If the answers people need are internalKnowledge AutomationStaff asking each other the same questions
Show us your last two hundred tickets.
That is the fastest way to tell whether this is a support automation problem, a documentation problem or a product problem. All three are common, and only the first is work this page describes.
Questions we are actually asked
Pick a topic, or ask us directly. We answer every inbound within one business day.
Still have questions?
Talk to a senior engineer, not a bot.