AI chatbots and voice assistants
A bot your customers do not have to escape from
You get an assistant that answers from your own content and knows what it does not know. On the cases that matter, it passes the caller to a person. Measured before launch, watched after.
Every chatbot demo works, because the person demonstrating it asks the questions it can answer. Real users do not. They arrive angry and halfway through a problem, using words nobody on your team would use. Then they ask the one thing the bot was never given. What separates a useful assistant from the kind customers learn to bypass is the handover. Knowing which questions it must refuse, and passing those to a human without making the customer start again. We design that first.
Customers do not hate bots. They hate dead ends
Ask people why they hate chatbots and nobody says the writing was poor. They say it would not let them through. The loop, the same three suggested replies, the phone menu with no zero.
That is a design failure, not a model failure. A bot deflecting every request is scored on deflection, so it deflects the ones it should not. Meanwhile the questions it answers confidently and wrongly never appear in any report, because a wrong answer that nobody challenges looks exactly like a success.
So we build two things before the conversation. A list of what the assistant must never answer alone, agreed with the people who own the risk. And a handover that carries the whole conversation across, so your customer never starts again from the top.
Where this sits next to our other AI work
A chatbot is the interface. What sits behind it decides which of our services you actually need, and the honest answer is usually more than one.
If the assistant answers from a document library, the engineering underneath is retrieval, and RAG development is the page describing how we build it. If the assistant books, cancels, refunds or updates a record, it is an agent, and the safety work is a different size. If you want drafting or summarising with no conversation at all, that is generative AI development.
- 01Chat interface plus your documents: this page, built on retrieval.
- 02Chat interface plus permission to change your systems: read the agents page first.
- 03No conversation, just output: generative AI development.
Assistants we have shipped
Named systems, running for named clients.
A voice agent answering the shop phone
ZhoopZhoop's agents take live customer calls over Twilio and book work while every technician is under a car. Deepgram handles speech and turn-taking, and staff see every transcript across all branches.
An assistant that asks before it searches
Military Cruise Deals lets a traveller describe the trip in plain words. The module asks a few follow-up questions, then turns the request into a validated search across ships, ports and dates.
A messaging assistant customers already have installed
ZhoopZhoop also runs on the Twilio WhatsApp Business API, so a customer asks about their repair in the app they use anyway. Outbound agents call suppliers to collect and compare parts quotes.
An assistant that waits for a yes
Trading CoPilot sends each alert to the trader over Telegram and waits for approval before executing anything through the broker connection. The bot proposes. A person decides.
- UnderstandWhat did they actually ask for?
- Check scopeIs this on the refuse list? Hand over now.
- RetrievePull from your content, not the model's memory.
- Answer or admitCite the source, or say it does not know.
- Hand overWhole conversation carried across to a person.
- ScoreEvery run graded against your cases.
The second station is the one most builds skip. Checking scope before retrieval is what stops an assistant improvising an answer to a question it was never meant to touch.
Writing the list of things it must never answer
This is a business conversation, not a technical one, and it is where the risk actually lives. Someone has to decide what the assistant does with a medical symptom, a legal threat, a safety report, or a request to reverse a charge.
We run that session with the people who carry the consequence: support leads, legal, whoever signs off refunds. The output is a written list. It goes into the build as a rule that fires before retrieval, so the assistant hands over rather than reasoning its way to an answer.
- Emergencies and safety reports route to a person immediately, every time.
- The assistant may say it does not know. Most demos have no way to express that.
- Anything irreversible waits for approval, which is a design decision rather than a prompt.
- Transcripts are kept and reviewable, so a complaint can be checked rather than argued about.
What we build on
Conversation
Channels
Build
Run
Systems that hold a conversation and then hand over
ZhoopZhoop
AI receptionist and parts procurement for a multi-branch auto repair business.
Read the case study →
Cruise Search AI
AI cruise discovery for military and veteran travelers.
Read the case study →
Trading CoPilot
Real-time AI trading alerts and execution companion for forex traders.
Read the case study →
Lexpair
AI legal lead generation and case matching for law firms.
Read the case study →
“I am extremely happy with the results and would highly recommend Hashlogics to anyone.”
Daniel Khin · CEO, PremiumAudit.io
The usual chatbot project against ours
The difference shows on the calls nobody rehearsed.
| Criterion | The usual approach | How we build |
|---|---|---|
| What it is measured on | Deflection rate. Fewer tickets looks like success. | Correct answers plus clean handovers, scored on graded cases. |
| Questions outside its scope | It answers anyway, confidently. | A refuse list fires first and routes to a person. |
| Reaching a human | Buried, or absent by design. | One step, with the conversation carried across. |
| Where answers come from | The model's memory, which cannot be checked. | Your content, cited, with room to say it does not know. |
| Wrong answers | Invisible. Nobody logs a confident mistake. | Transcripts kept, runs replayable, cases re-scored on every change. |
| After launch | The contract ends at go-live. | An agreed service level, or a documented handover to your team. |
01How do we stop it giving a customer the wrong answer?
You limit what it may answer, and you ground the rest in your own content with the source attached. The refuse list is agreed with your team before the build starts, and it fires before the model reasons about anything. For the questions it does handle, a reviewer can check the cited passage in seconds rather than trusting the wording.
02Will it just annoy customers who want a person?
Only if you hide the exit, and we do not build it that way. Reaching a human is one step, and the transcript travels with the customer so nobody repeats themselves. An assistant that hands over quickly on the hard cases gets more trust on the easy ones.
03Can it answer the phone as well as a chat window?
Yes. ZhoopZhoop runs voice agents over Twilio with Deepgram handling speech and turn-taking, alongside a WhatsApp assistant on the same system. Voice is harder than chat because interruptions and silence both mean something, and the handover rules matter more when somebody is waiting on the line.
04How do you measure whether it is actually good?
Your team writes the answers they would accept for a set of real conversations, including the awkward ones. Every release is scored against that set before it ships, and the same set runs again whenever the model changes. Deflection rate on its own is the metric that hides the failures.
05What about emergency or safety calls?
Those go straight to a person, and the rule is written before anything is built. An assistant that attempts a safety question is a liability whatever its accuracy, because the cost of the rare wrong answer is not recoverable. We treat that as a design constraint rather than a setting.
06Can it use the tools we already run?
Usually, and the limit is your systems rather than the model. We have shipped assistants wired to Twilio, WhatsApp, Telegram, calendars and internal databases. Where a system has a weak API, the assistant proposes the change and a person applies it, which is slower and considerably safer.
07We are a small business. Is this worth it below enterprise scale?
A single high-volume conversation is often where it pays best, and a multi-branch repair shop is not an enterprise. ZhoopZhoop started with one problem: calls going unanswered while everyone was working. Narrow scope with one clear job beats a general assistant that does everything adequately.
08Who owns the assistant and its transcripts?
You do. Source code, prompts, graded cases, transcripts and infrastructure accounts are yours in writing before work starts. Scoping conversations cost nothing, and where we have to go inside an existing codebase to answer honestly, a paid two-week diagnostic comes first.
Related
- RAG development →The retrieval engineering behind an assistant that cites its source.
- AI agent development →When the assistant has to act, not only answer.
- Generative AI development →Drafting and summarising, without a conversation.
- Should an AI receptionist handle emergency calls →The refuse list, argued in full.
- Why your RAG returns wrong answers →What goes wrong underneath the chat window.
