For assistants that answer, not assistants that act
Chatbot Development
A chatbot is a conversation, not a task-runner, and that distinction should decide the build before a vendor is chosen. This practice ships assistants that answer from a governed knowledge boundary and hand off cleanly the moment a question falls outside it. The scope stays conversational; changing a system belongs to an agent instead.
How a governed chatbot actually gets built
Knowledge grounding, escalation design and the boundary that keeps answers honest.
90 secSample frame · video pending01Before any conversation design
A chatbot is the wrong answer to some pressure
Chatbots solve a narrow problem well and a broad one badly, so the decision belongs before conversation design starts. Four questions settle whether a conversational assistant fits the pressure your team is actually under.
Does the answer already exist in writing?
A chatbot grounds itself in documented content. If the answer only lives in someone's head, write it down first, or the assistant has nothing reliable to retrieve.
Is the request conversational or transactional?
Answering a question is conversational. Cancelling an order or updating a record is transactional, and belongs to an agent regardless of how the request is phrased.
Does volume justify the grounding effort?
Building an approved knowledge boundary takes real curation work. A handful of questions weekly rarely justifies it; a queue outgrowing headcount usually does.
What happens when the assistant does not know?
Every deployment needs an honest decline and a clean handoff. A chatbot without one will guess, and a guess in a support channel becomes a fresh incident.
| Scripted bot | Grounded assistant | |
|---|---|---|
| Coverage | Fixed decision tree | Answers within an approved boundary |
| Handles rephrasing | Poorly | Reliably, by design |
| Maintenance | Manual flow editing | Content updates alone |
| Escalation | Often a dead end | A clean handoff by design |
| Right for | Narrow, stable flows | Broad support or product questions |
02Agreed before any build
The ledger that keeps the scope honest
Before conversation design starts, the engagement draws four lines: the material you supply, the system this practice builds, the assistant you take delivery of, and the decisions that never move to us. Each scenario draws that line in a slightly different place for the situation closest to yours.
- Your side
You bring
- Your existing help center and closed support tickets
- The questions customers ask most often
- Any escalation rules your agents already follow
- Our side
We build
- A knowledge boundary built from your approved content
- A conversation flow tuned to your support tone
- A grounded retrieval layer that cites its source
- Your side
You receive
- An assistant answering only from approved knowledge
- A clean handoff path for anything unanswered
- Analytics showing every question the assistant declined
Never leaves you
- The support policy and escalation rules themselves
- Every customer conversation and its transcript
- Final say on what the assistant may state
Where the line sitsThe knowledge boundary gets drawn before conversation design starts, so declining gracefully beats inventing an answer.
03What actually drives the number
Four drivers, not a flat rate card
Chatbot work is priced against the assessment, not a template, because these four factors change the effort by multiples.
Knowledge boundary curation depth
Well-structured documentation grounds an assistant quickly. Scattered content across many systems needs consolidation work first, before any conversation design starts.
Escalation and handoff complexity
A single support queue is simple to route into. Multiple teams, tiers or channels require routing logic most teams underestimate.
Legacy bot migration scope
Replacing a scripted bot costs more than a greenfield build, because every existing flow needs a decision about whether it survives.
Integration surface
A standalone widget is straightforward. Embedding inside a product, a helpdesk and a messaging channel at once multiplies the integration work.
04Evidence and proof
Assistants judged on what they declined, not just what they answered.
Chatbot proof is deflection and honest escalation, not conversation counts. Every record here waits for written client approval before production.
Explore case studies
A patient support queue stopped growing faster than the team.
Koru Health fielded rising patient questions through a small support team. A grounded assistant answered routine questions and escalated the rest with full context attached.
- Tickets answered without an agent
- A clear majority
- Escalation context lost
- None
An internal help desk stopped losing requests in a shared inbox.
Orra Systems ran internal support through a shared inbox that buried urgent requests. A scoped assistant now answers routine policy questions and routes the rest by priority.
- Routine questions handled directly
- Most of the queue
- Misrouted urgent requests
- Eliminated
We could finally see every question the assistant declined, which told us exactly what to write next.
Sample · pending client approval
05Read this first
When a custom chatbot is not the right fit
Selling a custom conversational build to a team whose need is already packaged would cost more than it earns us in trust. The exits are marked before the pitch. When a custom build is justified, it runs on retrieval-augmented generation, a governed content store and the messaging or helpdesk platform already in place.
- AI Customer Support
A packaged support assistant already fits
If the need is customer support specifically, a productised route reaches production faster than a custom conversational build.
- AI Receptionist
The need is a phone-answering receptionist
Voice-first call handling is a different interaction model from a text chatbot, and a packaged route already covers it.
- AI Agent Development
The task changes systems, not just answers
If the assistant needs to cancel, update or trigger a workflow, the right build is an agent, not a chatbot.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Scoped build | The knowledge boundary is settled | Tone and escalation policy | Conversation and retrieval delivery |
| Delivery pod | The boundary will grow with usage | Priorities each cycle | Engineering, quality, releases |
| Team extension | Your leads run delivery well | Architecture and standards | Named engineers and continuity |
06Straight answers
Asked before a chatbot budget commits.
01Can the chatbot also update records or trigger workflows?
Not in this scope. A chatbot answers from an approved knowledge boundary; changing a system, cancelling an order or updating a record is agent territory and needs a different architecture entirely.
02How do you stop the chatbot inventing answers?
Every response is grounded in retrieval against approved content, and the assistant is tested on questions outside that boundary before launch, so declining beats guessing by design.
03Which platforms does the chatbot integrate with?
Helpdesk platforms, product surfaces and messaging channels most commonly, chosen against where your customers already ask questions rather than a default integration list.
04How long does a first chatbot build take?
Timeline depends on how much of your knowledge boundary already exists in writing and how many platforms it needs to reach, so the assessment sets the schedule, not a template.
05Can you take over a chatbot another vendor built?
Yes, starting with an assessment of the existing conversation flow and knowledge boundary rather than a rebuild pitch. Many inherited bots need boundary work, not a replacement.
06What happens to questions the chatbot cannot answer?
They route to a clean handoff path with the conversation history attached, so a human never starts from zero, and the gap gets logged for the next content update.
07Do you write the knowledge content, or do we?
You keep ownership and authority over content; this practice structures it for retrieval and flags where existing documentation is too thin to ground an answer confidently.
08Is a chatbot the same thing as an AI agent?
No. A chatbot answers questions inside a defined scope. An agent takes actions on connected systems, which is a different risk profile and a different build entirely.