AI chatbots and voice assistants
AI chatbots your customers do not have to escape from
It answers from your own content, admits what it does not know, and hands the hard cases to a person in one step, not three.
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.
We published a ranked comparison of the firms in this space, ourselves included and not at the top. Read it before you shortlist anyone.
- 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
- Claude API
- OpenAI Chat Completions
- Deepgram Voice Agent
- Function calling
Channels
- Twilio Programmable Voice
- Twilio WhatsApp Business API
- Telegram Bot
- Web chat
- SMS
Build
- Python
- FastAPI
- LangGraph
- TypeScript
- React
- WebSockets
- PostgreSQL
- Redis
Run
- AWS
- Docker
- Sentry
- GitLab CI
Systems that hold a conversation and then hand over
ZhoopZhoop
AI receptionist and parts procurement for auto repair.
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 for forex traders.
Read the case study →
Lexpair
AI-assisted legal lead 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
Both look fine in a demo. The difference shows on the calls nobody rehearsed.
What it is measured on
The usual approach
Deflection rate. Fewer tickets looks like success.
How we build
Correct answers plus clean handovers, scored on graded cases.
Questions outside its scope
The usual approach
It answers anyway, confidently.
How we build
A refuse list fires first and routes to a person.
Reaching a human
The usual approach
Buried, or absent by design.
How we build
One step, with the conversation carried across.
Where answers come from
The usual approach
The model's memory, which cannot be checked.
How we build
Your content, cited, with room to say it does not know.
Wrong answers
The usual approach
Invisible. Nobody logs a confident mistake.
How we build
Transcripts kept, runs replayable, cases re-scored on every change.
After launch
The usual approach
The contract ends at go-live.
How we build
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 calls cost nothing. Every build then starts with a fixed-fee Blueprint, credited in full against the build, and if the plan isn't one you'd act on, you don't pay for it. The first 2 months of support and maintenance are free, with every build.
Related
- Best AI chatbot development companies →A ranked comparison of the firms in this space, us included and not at the top.
- 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.
- hire chatbot developers →Bring an engineer onto your team to build this.
