Most chatbot projects fail before they start — not because the technology is hard, but because the scope is fuzzy. If you commit to one narrow job, a website chatbot that answers real customer questions from your own content is genuinely a one-week build. Here is the schedule we use, day by day, and the decisions that matter at each step.
Day 1: define one job and write the questions down
A chatbot that answers everything will disappoint everyone. Pick a single, measurable job: answering pre-sales questions, handling order-status lookups, or routing support tickets. Then collect the raw material — the last fifty emails or contact-form messages you received, grouped into themes. You will usually find that twenty questions cover most of your traffic. Write those twenty down: they become your test set, your content checklist, and your success criteria. If you cannot describe what a good answer looks like for each one, the bot cannot either.
Day 2: gather and clean your content
Retrieval is only as good as what it retrieves. Pull together the pages, PDFs, policy documents, and FAQ entries that already contain your answers, then do three things: remove duplicates, split long documents into coherent chunks of a few paragraphs each, and rewrite anything that is out of date. Keep the structure plain — headings and short paragraphs — because chunk boundaries matter more than formatting. A folder of twenty clean pages beats a three-hundred-page PDF dump. Note where each chunk came from; you will want to show sources later.
Day 3: choose the simplest approach that works
There are three realistic architectures, and the right one is almost always the simplest:
- Keyword and FAQ matching — fast and cheap, fine for a small, stable question set.
- Retrieval plus a language model — relevant chunks of your content are fetched first, and the model writes an answer grounded in them. This is the default choice for most sites.
- A fine-tuned model — worth it only when you need a specific tone or format that prompting cannot reach. Skip it in week one.
Start with retrieval plus a model you can host or rent cheaply. If retrieval alone surfaces the right snippet for half the questions, you can even skip generation and show the source text directly.
Day 4: build retrieval and write the system prompt
Off-the-shelf embedding models handle indexing well enough on day four. When a question arrives, retrieve the top few matches and pass them to the model with a short system prompt: answer only from the provided material, name the source page, and say clearly when the answer is not in the documents. That last instruction — permission to say I do not know — does more for answer quality than any clever phrasing. Keep answers short: two to four sentences plus a link. Long answers hide errors.
Day 5: wire up the interface
Embed the chat as a small widget on the pages where the questions actually arise, not buried on a contact page. Three behaviours matter more than styling: a visible hand-off to a human when the user asks for one or the bot is unsure, a transcript log you can actually read, and a graceful fallback when the service is down. Capture every question and answer to storage — this log is how you improve the bot, and it doubles as a list of content you are missing.
Day 6: test like an attacker
Run your twenty-question test set, then try to break it. Ask the questions in unusual wording, with typos, and in other languages if your customers use them. Try the questions the bot should refuse: pricing you do not publish, legal advice, anything about competitors. Every wrong answer gets one of two fixes — better source content or a tighter retrieval filter — and both make the next round cleaner. Repeat until the test set passes. One honest afternoon of adversarial testing is worth more than another week of tuning.
Day 7: launch small and measure
Release to a fraction of your traffic, or to a single page, and watch three numbers: how often conversations finish without a human hand-off, how often users rephrase a question (a sign the answer missed), and which questions matched no content at all. Fix the top gaps weekly. After two or three cycles the bot handles the routine questions reliably, and you will know from your own logs — not from a vendor promise — whether it is ready for every page.
A week is enough because the hard parts are editorial, not technical: deciding the job, cleaning the content, and testing honestly. The model is the easy part — your documents are the product.
