Support chatbot with a custom knowledge base

Overview

A customer support and sales chatbot built on the OpenAI API, answering from the client’s own material rather than general knowledge, and embeddable in any website with a single script tag.

The problem

The client wanted a support bot answering from their own material. Most of the cost in a project like this is not the model call. It is keeping answers grounded, letting non-technical staff fix bad ones, and behaving sensibly when things break.

What I built

Content ingestion and chunking into a searchable knowledge base, prompt construction that anchors answers to that material, conversation state across turns, streaming responses, an embeddable widget that drops into any site with one script tag, and a management dashboard where staff read real conversations, see what the bot answered badly, and correct it without touching code.

Complexities tackled

Knowing when to stop. The correct behaviour for a question the knowledge base cannot answer is to hand over to a human, not to produce a confident guess. That boundary took more iteration than the retrieval did, because a model will always produce something, and something is worse than nothing when a customer acts on it.

Failure modes are normal operation. Rate limits and model timeouts are not exceptions in a production chatbot, they are Tuesday. The bot degrades rather than dying, and the user sees an honest message rather than a spinner that never resolves.

Making corrections a staff job, not a developer job. The dashboard exists so the people who read the conversations can fix the answers. A support bot that needs a developer for every wrong answer stops improving the week the project ends.

An offline variant. A later deployment could not send data to a third-party API at all, so a version was built that answers with no network round trip.

Three deployment shapes for one product. The chatbot is not one artefact. There is the API service, the embeddable widget a customer drops into their own site, and a set of serverless functions doing the work that must not sit inside a request. Each has different constraints: the widget has to survive being loaded into a page it knows nothing about, and the serverless side has to be callable from a browser that is not on the same origin. Splitting them was what let the embed stay a single script tag.

Containerised so it deploys the same way twice. The service ships with its own container definition and a deploy script rather than a set of instructions, because a chatbot that answers from a client’s own material has to be redeployable when that material changes, and a deployment that only one person can perform is a liability rather than a feature.

Stack

Python and FastAPI behind an OpenAI integration, Firebase for storage and serverless functions, a JavaScript embed widget, containerised for deployment, embeddable widget, admin dashboard.