AI & Automation
What I learned building a 24/7 AI chatbot
Most "AI chatbot for your business" posts are written by people who installed a widget and called it a day. This post is the opposite: I designed and shipped a real chatbot for a small business website — the one answering questions on my studio's own site — and I want to walk through the architecture that actually survived contact with real visitors.
The mistake everyone makes: AI-first
The default architecture people imagine is: visitor types → AI answers. Simple, and wrong for business use. A raw language model asked about your prices, your hours or your service area will cheerfully make something up. For a restaurant, a hallucinated "yes we're open Mondays" is a real-world failure with a real customer standing at a locked door.
The architecture that worked: three tiers
What I shipped instead is a three-tier flow, and I'd build it the same way again:
- Tier 1 — knowledge base first. Common questions (pricing ranges, process, timelines, "can you work with my industry") are answered from a curated knowledge base instantly, with zero AI involvement. Deterministic questions get deterministic answers.
- Tier 2 — AI for the long tail. Only when the knowledge base misses does a fast model step in, and it's constrained: a strict system prompt, facts from the knowledge base only, and hard limits on how much it can say.
- Tier 3 — human escape hatch, always. The moment intent turns serious — pricing specifics, complaints, anything the bot is unsure about — the conversation is handed to a human, with a WhatsApp thread one tap away. The bot's job is to triage, not to close.
Details that mattered more than the model
Short replies, no markdown. Visitors read chat on phones; asterisks and bullet walls feel like documentation. The system prompt enforces plain, short sentences.
Never repeat yourself. The bot offers the WhatsApp handoff once per conversation, not after every reply. Repeating contact details reads as desperation.
An editable brain. The knowledge base and prompt are editable from an admin panel without touching code — because every week of real conversations teaches you what people actually ask.
Fail gracefully. If the AI API is down or slow, the visitor gets the human handoff links, not a spinner or an error. The worst outcome is a silent failure nobody notices.
What it's genuinely good for
After running it live, the honest scorecard: the chatbot earns its keep on after-hours triage and repetitive questions. The questions that arrive at odd hours used to be morning backlog; now most are answered on the spot or arrive pre-qualified. It does not replace a human for anything revenue-critical — and it shouldn't try.
What I'd do differently
Two things. I'd seed the knowledge base from real support messages earlier instead of writing it cold — the first week of live traffic rewrote half my assumptions about what people ask. And I'd put the API key behind a server proxy from day one rather than moving it later; it's a five-minute job at the start and an annoying one after launch.
Should you add one?
If your site gets real questions — bookings, quotes, "do you deliver to my area" — a constrained, KB-first chatbot is one of the highest-leverage upgrades available to a small business right now, and it's now a service I offer through Nexa Dev Studio. If your site gets three visitors a day, fix traffic first. The chatbot is a multiplier, not an engine.