
Project Details
- Name:AI Customer-Support Chatbot Platform
- Category:Business Strategy
- Author:Stratgik
- Client:Confidential - consumer-facing enterprise
- Location:AI / Customer Experience
- Share:
AI Customer-Support Chatbot Platform
An AI-powered support chatbot that answers routine customer questions instantly and hands complex cases to humans with full context - cutting load on the support team.
A consumer-facing business was answering the same fifty questions endlessly — order status, returns policy, store timings — while genuinely complex cases waited in the same queue. We built an AI support chatbot that resolves routine enquiries instantly, around the clock, and hands anything it cannot confidently answer to a human with full conversation context. It runs on the client's own infrastructure. Here is how it was built and what to expect if you commission similar work.
The challenge
The overwhelming majority of tickets were mechanical; a small minority needed judgment. Because everything arrived in one undifferentiated queue, hard cases waited behind easy ones. Hiring more agents scales cost linearly with volume forever, and a decision-tree bot with buttons fails the moment a customer phrases something in their own words.
Our approach
We treated this as a retrieval problem first and a language problem second. The value is not fluent English; it is that the answer given is the company's actual policy rather than a plausible invention. Approved content is chunked, embedded and indexed; at query time the system retrieves relevant passages and the model answers only from those. Below a confidence threshold it escalates rather than guesses, carrying the transcript and identifiers so nobody repeats themselves. Order lookups run through explicit calls to the client's own APIs, never from model memory.
Architecture and key decisions
| Decision | What we chose | Trade-off accepted |
|---|---|---|
| Answer generation | Retrieval over the client's own content, with a refusal threshold | More engineering than a raw prompt; content quality becomes the ceiling on answers |
| Hosting | The client's own infrastructure | More operational responsibility than a SaaS widget, in exchange for data control and no per-conversation pricing |
| Model layer | Provider-abstracted, swappable | A thin layer to maintain; avoids being repriced or deprecated by one vendor |
| Live data | Explicit API calls for order and account lookups | Each integration is real work; removes an entire class of hallucinated facts |
| Admin console | Non-technical content editing plus conversation analytics | Extra scope; keeps developers out of the update loop permanently |
The console matters more than it looks: a bot whose answers only a developer can change decays within weeks.
How we sequenced the work
We read real tickets before touching a model, categorising enquiries to find which intents actually dominate — almost never what the team assumes. Then the retrieval layer, the escalation handover, shadow mode where agents reviewed drafted answers, a limited live surface, then widening intent by intent based on observed traffic rather than ambition.
What to look for if you're commissioning this
Ask how hallucination is prevented. If the answer is "a good prompt", walk away — grounding, retrieval and a refusal threshold are the mechanism. Ask who owns the conversation data; our security practice treats transcripts as customer data. Ask who can edit answers without a developer, and what per-conversation cost looks like at ten times current volume. Insist on an evaluation set of real questions with known-correct answers, run against every change — without it, every update is a guess. Our build vs buy tool frames the hosted-versus-built choice in cost terms. Failures here are predictable: launching across every intent at once, building on stale documentation, or hiding the escalation path to inflate deflection numbers.
Typical cost and timeline
General ranges for this class of work, not this client's figures. A narrow bot over existing documentation with escalation typically runs six to ten weeks. A production system with live API lookups, admin console, analytics and self-hosting typically runs three to five months. Ongoing cost splits into inference, which scales with volume, and hosting plus maintenance, which is largely fixed. See our cost estimator and pricing.
The outcome
Routine questions get instant answers at any hour, the human team focuses on cases that need judgment, and the business gained a live view of what customers actually ask — which now feeds product and content decisions.
Frequently asked questions
Will an AI chatbot make things up about my business?
Not if it is built correctly. A grounded system retrieves passages from your own approved content and answers only from those, with a confidence threshold below which it refuses and escalates. Hallucination becomes a real risk when a system answers from general model knowledge with no retrieval, no source grounding and no refusal path.
How much of my support volume can realistically be automated?
It depends on how repetitive your enquiries are and how good your documentation is, so we will not quote a percentage before reading your tickets. The honest first step is categorising a few months of history. Businesses with a long tail of judgment-heavy cases automate far less than those whose queue is mostly order status and policy questions.
Should I self-host or use an off-the-shelf support bot?
Off-the-shelf is faster and sensible when your needs are generic and volume is modest. Self-hosting makes sense when you need data control, deep integration with internal systems, or when per-conversation vendor pricing becomes punitive at your projected volume. The decision is mostly economic and regulatory rather than technical, and both paths deserve honest modelling first.
What happens when the bot cannot answer?
It hands the conversation to a human along with the full transcript, the sources it consulted and any identifiers already captured. The customer does not repeat themselves and the agent starts with context rather than a cold ticket. Designing this handover properly separates a bot customers tolerate from one they immediately try to bypass.
How do I keep answers accurate as the business changes?
Through an admin console your support team controls directly, so policy changes reach the bot the same day rather than waiting on a developer. Alongside that, a fixed evaluation set should be re-run whenever content, prompts or the underlying model change, so regressions are caught internally before customers find them.
If you are considering an AI support layer, book a free 30-minute technical session through our contact page — we will tell you honestly whether your ticket mix justifies it. For senior oversight of the decision itself, see fractional CTO.
