AI chatbots that give useful answers, then hand off when they should.
We build chatbots around the conversation that keeps breaking. First define the real questions, answer sources and human boundary, then build what earns a place.
19 years of software delivery experienceWorkflow first, before a model, interface or tool choiceHuman boundary defined before a chatbot is live
The chat window
- Has my order shipped yet?
- It shipped on Tuesday and is due Friday.Order record
- It is late. Can I have the delivery charge back?
- I can see the delay. I cannot approve a refund.Needs judgement
Outside the chat window
- Owner
- Not named
- Context carried
- None
The last step is outside the chat window. It still belongs to the workflow.
An invented exchange, illustrating the boundary this page argues for. Not a customer record.
A chatbot is not the answer to every repeated question.
Some questions need a better help centre; some point to a product or policy problem. A chatbot fits when the information, permissions and handoff path can be made clear enough to trust.
A chatbot can help when
The same question keeps arriving, the answer comes from approved information, and there is a useful next step or clean escalation path.
Fix something else first when
The answer does not exist, nobody owns the exception, the data is unreliable or the real problem is a process that should be simplified.
One capability, shaped around the job the conversation needs done.
Start where people are already waiting for an answer.
Customer support assistants
Answer common product, account, policy and post-purchase questions from approved information, with a route to a person when the issue needs more context.
Knowledge assistants
Make internal policies, documents and operating guidance easier for teams to find, while keeping the authoritative source visible.
Product and service guides
Help users understand options, gather the right information and move into the next approved step without forcing them through a generic form.
Conversation-to-workflow handoffs
Capture structured context, route an exception and connect the conversation to the team or system that owns the next action.
A few real questions, chat transcripts or tickets, plus the current route through the team, are more useful than a finished technical brief.
Need a workflow assessment?Build the conversation around the workflow, not the chat window.
Four steps in order, beginning with the questions people already ask.
Map the question path
Review the question types, the current source of the answer, the point where the conversation breaks and the people who receive it today.
Define the first job
Name what the chatbot may answer, retrieve, collect, trigger or hand off. A focused first job is more useful than an assistant that claims to do everything.
Connect the right information and actions
Prepare the approved knowledge, system access, permissions and escalation path around that job.
Review and improve the live conversation
Use the questions, failures and handoffs that appear after launch to improve the source, workflow or service behind it.
Agree what “correct” looks like before it goes live.
“It sounds good” is not a standard. Before launch, the workflow owner should be able to name the important questions and which requests must always reach a person.
Before a useful buildAfter the first workflow is defined
“Make a chatbot for support.”
BecomesA named question type, answer source, action boundary and escalation owner.
“It seems accurate.”
BecomesReal examples with an agreed definition of a good and unacceptable answer.
“Send difficult ones to a human.”
BecomesSpecific conditions for stopping, the person/team receiving context and the record they need.
That gives you an evaluation set built from real examples, not an impression after a demo. A chatbot can become more fluent without becoming more reliable.
Make the human boundary part of the build.
A useful escalation is designed, not added as an apology at the bottom of the chat. The person receiving the handoff should not make the user start again.
The chatbot should stop when
The answer cannot be supported by an approved source, the request needs judgement or the action falls outside the permission it has been given.
The handoff should carry
The question, relevant context, what has already been tried and the next decision the human owner needs to make.
See the customer-question work behind the approach.
These are documented results from delivered client work. They show the kind of customer interaction and operational work the team has already been trusted to improve.
Conscious Chemist, product-question response time
38% faster product-question response time in a personalized shopping workflow.
Cited as context for the kind of customer-question work behind this approach, not as an AI chatbot implementation.
Conscious Chemist, engagement and retention
+15% engagement and retention from the same customer interaction engagement.
The same engagement, cited for the customer interaction it involved rather than as a chatbot result.
The relevant question is not whether the labels match, but whether the work involved a real question path, a known answer source and an outcome that mattered.
A live chatbot should make the rest of the workflow clearer.
The first live conversations show which questions are still unclear, where the approved source is incomplete and which exceptions keep returning to the same people.
Review resolved questions
Which questions reached a useful answer and which needed a person, more data or a different route?
Improve the underlying work
Use repeated exceptions to fix the source, process or ownership issue that made the chatbot necessary in the first place.
The useful review looks at the work around the chatbot, not just the chat. If customers keep asking for something the business cannot give, the fix may be a policy or product change.
See data engineeringChoose the technology after the operating rules are clear.
Buyers do not need a wall of tool logos. They need to know where an answer comes from, who sees the data and what happens when the system is uncertain.
Answer sources
Approved knowledge and source ownership matter more than a broad document upload.
System boundaries
Access, permissions and actions are defined around the workflow rather than assumed from the chat interface.
Evaluation
Real questions and agreed answers create a way to judge reliability before and after a change.
Operational visibility
Questions, exceptions and handoffs reveal what to improve in the chatbot and the work around it.
Know when a custom chatbot is worth building.
The decision is between the simplest intervention that solves the real problem and a system that can safely carry part of the workflow. That distinction prevents overbuying.
- The answer is fixed, simple and rarely changes.A clearer help page, FAQ or guided form.The simplest intervention, and it is not a build
- A repeatable system action happens without a conversation.Workflow automation that runs in the background.Nobody needs to ask, so nobody needs to be answered
- The user needs a contextual answer, a controlled action or a clean handoff.An AI chatbot designed around the workflow. · you are hereThe conversation carries part of the workflow
Questions teams should settle early.
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.
Show us the conversation that keeps breaking.
Tell us what people ask and where the answer comes from today. We will help identify whether a chatbot, an automation or a product change is worth doing first.