Most website chatbots fail for the same reason most bad prompts fail: nobody defined the job. The widget looks modern. The bot greets visitors. Then it invents shipping policies, loops on "I understand your frustration," and your support team quietly adds "please email us instead" to the homepage.
A simple chatbot that works is closer to a well-labeled FAQ with routing than to a sci-fi concierge. Build the boring version first.
What "simple" should mean
| Capability | In scope for v1 | Out of scope for v1 |
|---|---|---|
| Answer FAQs from your docs | Yes | Live inventory promises |
| Capture lead contact + intent | Yes | Full CRM autonomy |
| Hand off to human with transcript | Yes | Fully resolving angry legal issues |
| Multilingual if you already support it | Maybe | 20 personas / joke mode |
| Cite which help article it used | Yes | Unrestricted web browsing |
If your v1 needs "browse the whole internet and negotiate," you do not have a chatbot project. You have a product project.
The four ingredients you actually need
1) A single primary job
Write one sentence: "This bot exists to __ so that __."
Examples that work:
- "Deflect tier-1 product how-to questions so humans handle edge cases."
- "Qualify inbound leads with 4 questions and book a calendar link."
- "Help shoppers find the right size guide and shipping policy."
Examples that do not:
- "Be helpful."
- "Increase engagement."
- "Replace support."
2) A knowledge source with an owner
The bot should answer from:
- A help center / docs you control, or
- A short curated FAQ doc you update on purpose
Not from: half-remembered marketing copy in the system prompt, or whatever the base model believes about your industry.
Owner rule: every knowledge doc has a human who updates it when policy changes. No owner → the bot will eventually lie.
3) Escalation rules written in plain language
Define when the bot must stop and hand off:
- User asks for refund beyond policy, legal threat, medical/financial personal advice
- User is angry after two failed answers
- Bot confidence is low / retrieval found nothing
- User says "human" / "agent" / "rep"
Escalation should include transcript + URL + user contact if available. A handoff that makes people retype everything is worse than no bot.
4) Measurement that can kill the project
Track for two weeks:
- Containment rate (resolved without human): only if resolution is real
- Handoff rate and reason codes
- Thumbs down / "wrong answer" rate
- Top unanswered questions (these become new FAQ entries)
If you only track "messages sent," you will optimize for chatter.
Architecture choices without the vendor fog
| Approach | Best for | Watch-outs |
|---|---|---|
| Hosted chatbot SaaS + your URLs/docs | Most marketing sites | Crawl lag; stale pages |
| Helpdesk-native bot (Zendesk, Intercom, etc.) | Existing support stack | Pricing; workflow fit |
| Custom GPT-style assistant linked from site | Internal or logged-in tools | Not always ideal as anonymous widget |
| Fully custom (your backend + model API) | Strict data control / productized bot | You own evals, safety, uptime |
Pick the lowest layer that meets security and handoff needs. Custom is not a badge of honor.
Prompt / policy block that prevents personality disasters
Whatever platform you use, keep a short system policy:
"You are [Company] support for [product]. Only answer from the knowledge provided. If the answer is not there, say you do not know and offer [email/calendar/human]. Never invent pricing, legal commitments, or medical claims. Tone: [clear, concise, no slang]. If the user is upset, acknowledge once, then solve or escalate: no long empathy theater."
Personality is optional. Accuracy is not.
Implementation checklist (one afternoon + one week of watch)
| Step | Output |
|---|---|
| 1. Write the one-sentence job | Scope doc |
| 2. Export top 20 support questions from last 90 days | FAQ seed |
| 3. Draft answers a human would stand behind | Knowledge v1 |
| 4. Configure retrieval / upload docs | Bot connected to truth |
| 5. Write escalation rules + test them | Handoff path works |
| 6. Soft launch on 10% traffic or a single page | Limited blast radius |
| 7. Review 30 transcripts | Fix knowledge + prompts |
| 8. Expand or shut off | Decision based on data |
Skipping transcript review is how you ship a polite liar.
Worked example: SaaS help bot
Job: Answer how-to and billing-FAQ questions; escalate account access and refunds.
Knowledge: Help center + a one-page billing policy.
Escalation: refund requests, "can't log in," abuse, anything not in docs.
Success in week two: 25–40% of chats deflected cleanly; wrong-answer rate under a threshold you set; three new FAQ articles written from unanswered clusters.
Failure: Bot invents a free plan feature; containment looks high because users gave up.
Tool path on aihowto.pro
Start with the Chatbot Builder Blueprint to force use case, knowledge sources, and tone into a concrete plan before you buy a widget. If the bot needs to take actions across tools (create tickets, post to Slack), sketch that separately with the No-Code Automation Builder so the chat layer and the automation layer do not get tangled in one vague project.
Legal and trust basics (do not skip)
- Disclose that visitors are talking to a bot
- Do not collect sensitive data you are not ready to secure
- Align answers with published policy; marketing hyperbole in the system prompt becomes a compliance problem
- Keep a kill switch (disable widget) if retrieval breaks after a site redesign
Bottom line
A simple website chatbot needs a narrow job, owned knowledge, hard escalation, and transcript review. Themes and witty greetings are decoration. Ship the boring bot that answers twenty questions correctly and knows when to shut up: then earn the right to expand scope.