Most chatbot projects fail for a boring reason: nobody decided what the bot should know before they started building it. Chatbase is a good illustration of that. It will take a folder of PDFs, a help centre URL, or a pile of pasted text and turn it into a working assistant in about ten minutes. The ten minutes isn’t the hard part.
The hard part is choosing what goes in, writing instructions the bot can actually follow, and testing it against the questions your customers really ask. Here’s the process, in the order I’d do it, with the decisions that matter at each stage.
Step 1: Build an inventory before you build anything else
Picture a twelve-person SaaS company selling bookkeeping software to freelancers. Between the help centre, the onboarding email sequence, the pricing page, and an internal Notion page that gets updated twice a year, there’s roughly 180 pages of existing content. That’s plenty to start with. Nobody needs to write new copy from scratch.
Pull it all into one folder and sort it into three buckets:
- Authoritative and current. Help centre articles, product documentation, refund policy, the FAQ your support team pastes from every day.
- Useful but risky. Old pricing pages, screenshots with outdated plan names, blog posts written before a rebrand.
- Never feed this in. Draft policies, competitor comparisons, anything containing customer names or personal data.
That second bucket is where most bots learn to lie. If a 2023 pricing table sits in the knowledge base alongside the 2025 one, the assistant has no way to know which is correct, and it will happily quote the wrong number.
Keep each answer short and self-contained
Retrieval works by matching your question to a chunk of text. A 3,000-word support page gets split into pieces, and a piece that starts mid-sentence with “this must be done first” is useless on its own. Rewrite long pages into discrete questions and answers, each under 150 words, each understandable without the surrounding context.
Cut anything with an expiry date
Promotions, launch dates, beta features, “coming this quarter” promises. Anything time-sensitive becomes a hallucination generator three months later.
Step 2: Create the bot and upload in priority order
Sign up, create a new chatbot, and upload in the order of how authoritative each source is. Help centre export first, then the documentation PDFs, then the pricing page as a URL, then the internal FAQ. Chatbase will show you how many characters it has ingested from each source, and that number is worth watching. A 40-page PDF that contributes 900 characters is mostly images and tables, and the bot learned almost nothing from it.
If you’re still deciding whether this approach suits your situation at all, there’s a solid primer on the no-code way to train an AI chatbot on your own data that covers the fundamentals before you commit an afternoon to it.
Step 3: Write the system prompt like a job description
This is the single highest-leverage piece of the whole build. Treat it as a brief for a new support hire on their first day, not as a technical setting. A weak prompt says “be helpful and friendly.” A useful one says this:
“You are the support assistant for Ledgerline, a bookkeeping tool for freelancers. Answer in under 90 words. Use only the uploaded sources. If the answer isn’t there, say: ‘I don’t have that in front of me, but our team replies to email within one business day,’ and link them to support@example.com. Never quote Enterprise pricing; route those to sales. Never give tax advice. If someone mentions a refund over 30 days, apologise once and escalate to a human.”
Every sentence in that prompt removes a category of bad output. Length limit stops the rambling essays. Source restriction reduces invented answers. The escalation rule tells the bot what to do with its hands when it doesn’t know something, which is the scenario that decides whether people trust it.
Guard rails to write on day one
Tone (plain, no exclamation marks), length (a hard word cap), refused topics (legal, medical, tax, anything about a competitor), and a fallback route (email, live chat, phone). Set the greeting message separately from the system prompt, and include a sample question or two so the widget shows people what to ask.
Step 4: Test with the questions you dread
Forget the tidy questions. Type in the messy ones your support inbox actually receives:
- The vague one: “it’s not working”
- The two-part one: “can I add a team member and still pay monthly?”
- The trap: “is the annual plan cheaper?” when your sources list both prices
- The one your documentation answers badly
- The one where the honest answer is “we can’t do that”
- The angry one, phrased with swearing
Run 25 of these before you embed anything. Score each reply as correct, deflected, or invented. If more than two or three fall into the third category, go back to step 1 rather than tweaking the prompt. Hallucinations are usually a source problem wearing a prompt costume.
Step 5: Embed it where hesitant people already are
The widget script takes one line to paste, but placement changes results more than the script does. Put it on the help centre, the pricing page, and the order confirmation screen where people wonder what happens next. Keep it away from checkout, where an extra distraction costs conversions.
Add a lead-capture form on the pre-sales version of the bot, and leave it off the support version, where asking for an email before answering feels like a toll booth.
Step 6: Review transcripts weekly, not forever
Pick one number to track: the share of conversations that end without a human stepping in. If a bot handles 2,400 chats a month and 1,300 of them close cleanly, that’s 54%. Watch it weekly.
Then spend fifteen minutes reading the transcripts that failed. Every failure falls into one of three piles: the answer didn’t exist in the sources, it existed but was phrased badly, or the bot needed to escalate and didn’t. Add an article for the first, rewrite for the second, adjust the prompt for the third. Twelve new help articles in the first month is a normal output of this exercise, and they help human agents too.
Common failure modes and their fixes
The same four problems show up in almost every build:
- Answers from nowhere. Tighten the prompt, cut stale sources, and lower the confidence threshold so the bot says “I don’t know” sooner.
- Right answer, wrong length. Add a word cap. A 400-word reply to a yes/no question reads as evasion.
- Duplicated sources. Two versions of the same article produce two versions of the same answer. Delete the loser.
- Nobody asks anything. The greeting is too generic. Start it with a real question people recognise from their own inbox.
If you find yourself wanting to wire the bot into a Slack channel, an internal ticketing tool, or a second website, that’s a sign the build has legs. It’s also the point where a wider set of no-code building skills pays off; a structured way to build AI tools without writing code keeps you from hitting a wall when a simple upload-and-embed no longer covers it.
What a healthy setup looks like after 30 days
A month in, the numbers should look roughly like this: one bot answering across two surfaces, a resolution rate somewhere between 50% and 65%, a help centre that’s grown by a dozen articles, and a prompt that has been edited six or seven times. The failures aren’t gone, they’re just different ones, which is the point.
The teams that get real value out of this tool don’t treat the launch as the finish line. They treat the weekly transcript review as a permanent fifteen-minute job, the same way they treat inbox triage or a stand-up. The bot gets quietly better, and the questions it can’t answer become a to-do list for the people who write the documentation. That loop, not the upload button, is what makes a support assistant worth keeping.