Deflection is not
resolution.
Most chatbots are built to reduce tickets. Ours are built to finish the task — booking the slot, checking the order, taking the payment — and to hand over cleanly the moment they cannot.
Quick answer
What is the difference between a chatbot and a voice agent?
A chatbot handles text conversations on a website, messaging platform or app, while a voice agent handles spoken conversation over the telephone. The underlying capability is the same — understanding intent, retrieving information from connected systems, and completing an action — but the constraints differ. Voice requires low latency, tolerance for interruption and handling of accent and background noise; text allows richer formatting, buttons and links. In practice most organisations need both, because customers reach for the channel nearest to hand, and a system that resolves a booking by text but cannot do so by phone simply moves the queue rather than shortening it.
Most chatbots are built
to reduce tickets, not solve them.
A conversation that ends in a form is not a resolution. It is a delay with a friendlier interface.
Failure 01
The deflection machine
It answers questions nobody was blocked on, then hands anything real to a form. The ticket count falls and the resolution time does not, because the work simply moved.
Failure 02
The dead end
It cannot help and cannot escalate, so the customer restarts with a person and repeats everything. The conversation was a delay rather than a service.
Failure 03
The wrong language
It handles formal English confidently and fails on how customers actually write — mixed script, transliteration, abbreviation. Most of the market is filtered out by the interface.
Four deliverables, not a feature list.
Each engagement is scoped around what the system must finish, not how many questions it can answer.
01
Resolution design
The tasks the system will complete end to end, defined before it is built, so success is measured in completions rather than in deflections.
02
System connections
Read and write access to the calendar, records or order system, so the assistant changes state rather than describing it.
03
Handover with context
When escalation is needed, a person receives the full conversation and the customer does not repeat themselves.
04
Language handling
Behaviour across English, Urdu and Roman Urdu as your audience requires, tested against how customers actually write rather than how documentation assumes.
Five steps, in this
order, every time.
Scope decides what the system finishes. Everything after that is testing it against how people actually talk.
- 1
Define
Choose the tasks it must complete, and the ones it must hand over. Scope is what makes it good.
- 2
Connect
Wire it to the systems that hold the answer. An assistant without access can only guess.
- 3
Script
Set tone, refusal behaviour and escalation rules. What it will not do matters as much as what it will.
- 4
Test
Run real transcripts, mixed language and hostile input. Injection defences verified per input path.
- 5
Tune
Review conversations weekly at first. The gap between expected and actual questions is always large.
Intelligence rules in the Standard, each with a verification method.
Classified Critical: approval, override and no public training on your data.
Systems shipped that cannot escalate to a person.
Why untrusted input must be treated as data, never instruction.
A conversational system takes text from strangers and passes it to a model that also receives your instructions. Rule INT-06 requires that untrusted input be handled as data rather than as instruction, with injection defences present and tested. Without this, a customer can write text that redirects the assistant's behaviour — extracting information it should not disclose, or triggering actions it should not take. Verification is direct: submit crafted instruction text through every untrusted input path and confirm the system does not follow it.
Source: The Qawex Standard v1.0, rule INT-06 · /standard/intelligence/Answers, not brochures.
Will customers know they are talking to a machine?
Yes, and they should be told. We disclose it clearly at the start of the conversation. Attempting to pass an assistant off as a person damages trust when it is discovered, and it is always discovered. Disclosure costs nothing and makes escalation feel like a service rather than a rescue.
Can it handle Urdu and Roman Urdu?
Yes, and this is tested against real customer messages rather than clean sample text. Mixed script, transliteration and abbreviation are how a large part of the Pakistani market actually writes, and a system that only handles formal English filters out the customers it was built to serve.
What happens when it cannot help?
It escalates with the full conversation attached, so the person taking over starts with context and the customer does not repeat themselves. A system that cannot escalate is not shipped, and the escalation path is defined during scoping rather than added afterwards.
Can it take bookings and payments?
Bookings, yes, with direct calendar and record access. Payments are possible but treated as a high-impact action requiring explicit confirmation, with the transaction handled by a payment provider rather than by the assistant. The approval threshold is documented before deployment.
How much of our support volume will it handle?
We do not quote a figure before seeing your conversations, because the honest answer depends entirely on what your customers ask. The scoping stage reviews real transcripts and reports what proportion is task-completable, which is a more useful number than an industry average.
See what your conversations contain.
The scoping review reads real transcripts and reports what proportion could be completed end to end. Yours whether or not you build with us.