“Add a chatbot” sounds like a widget. In reality, chatbot development for websites is a software project: it touches brand voice, data access, conversion flows, privacy, security, and support operations. The teams that succeed treat chat as a system: scoped roles, approved knowledge, integration rules, and a feedback loop based on real transcripts.
This checklist walks through a practical, production-grade build process: discovery → design → implementation → testing → launch → iteration. If your goal is lead capture, the build should map to a conversion-and-handoff system like the AI Revenue Concierge Chatbot (Website + IG DM) rather than a generic FAQ widget.
Phase 0: Decide what the chatbot is responsible for
Before you choose tools or write prompts, lock the bot’s role. Common roles:
- Lead qualification + booking (sales routing)
- Support triage (deflection + escalation)
- Product discovery (recommendations + policy answers)
- Internal knowledge (team-facing, not customer-facing)
Role ambiguity is the #1 cause of chatbots that hallucinate or frustrate users. For multi-role systems, consider splitting roles into separate flows (or separate agents) with explicit boundaries, similar to the discipline described on Company Agent Builder.
Phase 1: Discovery (what you’re building and why)
1) Define one primary outcome
Choose the main outcome for the first version. Examples:
- book qualified calls
- reduce repetitive tickets
- increase add-to-cart from product questions
Trying to do all three in v1 creates a bot that does none of them well.
2) Map the top intents (real customer language)
Don’t guess intents. Pull them from reality:
- support tickets
- site search queries
- sales call transcripts
- DMs and emails
Write intents in user language (“Can you do this in two weeks?”) not internal taxonomy (“timeline inquiry”).
3) Define what the bot must never do
Set boundaries early: pricing exceptions, legal commitments, medical advice, refunds beyond policy, account changes, or anything you cannot verify. Trustworthy automation starts with risk thinking (see NIST AI Risk Management Framework).
4) Decide the escalation rules
Define triggers that require a human:
- high-value lead signals (budget/timeline/fit)
- complaints or emotional language
- policy disputes
- low-confidence answers
Phase 2: Knowledge and content (the “source of truth”)
Most chatbot failures are content failures. If your policies are inconsistent across pages, your bot will be inconsistent too.
1) Inventory your approved sources
- key website pages (services, pricing ranges, policies)
- help center / FAQ
- product catalog data (if ecommerce)
- internal SOPs (if internal bot)
2) Clean and version the sources
Decide who owns updates. A bot answering from outdated policies is worse than no bot.
3) Create an “answer hierarchy”
When sources conflict, what wins? Example hierarchy:
- legal/policy pages > help center > marketing pages > old docs
4) Define allowed claims and language
Create a short “claims policy”: what you can say, what you can’t, and what requires hedging. This preserves brand trust and reduces risky outputs.
Phase 3: Conversation design (flows that route, not ramble)
1) Design the entry experience
Decide how chat starts:
- passive widget (“Questions?”)
- intent menu on key pages
- behavior-based trigger (exit intent, repeat visits)
Avoid aggressive triggers that interrupt tasks.
2) Build intent-based flows
For each top intent, design:
- the first bot message (sets tone + offers direction)
- 2–4 qualification questions (minimum viable)
- the routed outcome (book, capture, resource, escalate)
3) Add “repair” behaviors
Users type unexpected things. Your bot needs repair patterns:
- clarifying question (“Do you mean A or B?”)
- safe fallback (“I’m not sure—want me to connect you?”)
- graceful exit (“No worries—here’s the right page.”)
4) Make the bot accessible by design
Chat UI should support keyboard navigation, readable contrast, and screen reader labels. WCAG is the reference (see WCAG overview). Accessibility is not “nice to have” if the bot blocks key site functions.
Phase 4: Implementation (website + integrations)
1) Choose where the bot runs
Most teams run web chat as part of their website stack. If you’re already shipping conversion-focused sites, align the bot implementation with your broader web build system (see Website & Web Development Services for how we think about QA, tracking, and launch discipline).
2) Integrate the systems that make the bot useful
- CRM: create lead records with tags and transcript links
- Calendar: booking for qualified leads
- Support desk: ticket creation + routing for support intents
- Notifications: alert humans for high-intent conversations
3) Implement security basics
Because chat is a public input channel, treat it like an application surface. Use baseline web app security guidance such as the OWASP Top 10 to inform mitigations: validate inputs, lock down access, and reduce sensitive data exposure.
4) Implement consent and data minimization
Collect only what you need, when you need it. If you’re triggering marketing follow-ups, follow responsible email practices; the FTC CAN-SPAM guide is a useful baseline even outside the U.S.
Phase 5: QA and test scenarios (where most teams cut corners)
Chatbot testing must be transcript-based. You are testing a system’s behavior, not a UI element.
1) Create a test matrix
- happy paths for each intent
- edge cases (weird phrasing, incomplete info)
- policy-sensitive questions
- handoff triggers
- mobile behavior (widget overlap, keyboard issues)
2) Test for “unsafe confidence”
AI systems often answer confidently even when wrong. Your QA should include prompts that try to pull the bot outside scope. If it cannot refuse or escalate safely, it’s not ready. Risk thinking from frameworks like NIST AI RMF applies here: test failure modes, not just success cases.
3) Accessibility testing
Test keyboard navigation, focus management, and screen reader labeling. Chat widgets often fail here—especially when third-party scripts are involved.
4) Security and abuse testing
Test spam and injection-style inputs. Verify rate limiting. Confirm your integrations don’t accept untrusted payloads.
Phase 6: Launch (pilot, then expand)
1) Pilot on high-intent pages
Start on pricing, services, and booking pages. Don’t launch sitewide first. The goal is to observe high-signal conversations and iterate quickly.
2) Monitor transcripts daily for the first week
Early monitoring reveals the real work: what people ask, where they drop off, and where the bot needs better handoff.
3) Set a cadence for iteration
Weekly transcript review + monthly flow updates is a realistic baseline. Otherwise, the bot decays as your business changes.
Phase 7: Governance (so it stays good)
Governance is the difference between a bot that compounds and one that becomes embarrassing. Define:
- who owns content updates
- who reviews logs and transcripts
- what changes require approval
- how you handle incidents (wrong answers, complaints)
Closing perspective
Chatbot development for websites isn’t “add AI.” It’s build a conversion-and-support layer with clear roles, approved knowledge, safe boundaries, and measurable routing outcomes. Do discovery well, constrain scope, integrate properly, test aggressively, and run it like a living system. That’s how web chat becomes leverage instead of noise.
If you want a lead-focused version shipped end-to-end (conversation design → build → routing → launch), the reference internal system is the AI Revenue Concierge Chatbot (Website + IG DM).
Appendix: discovery questions that save weeks later
- What is the one “conversion event” we care about? (booked call, lead captured, ticket resolved)
- Which page contexts change the conversation? (pricing vs services vs product pages)
- What are the top 10 questions sales/support repeats weekly?
- What counts as a “qualified” lead? Define explicit rules, not vibes.
- What data is safe to collect? (email, company, budget range) and what is not.
- What is the human response SLA? If you escalate a hot lead, how fast can a human reply?
Appendix: the build artifacts you should expect
A production chatbot build should leave behind artifacts you can reuse and audit:
- intent list + routing map
- conversation scripts/flows (versioned)
- knowledge source inventory + update owner
- handoff rules + escalation triggers
- integration spec (what data goes where)
- QA test matrix + launch checklist
Appendix: the transcript review loop (simple, but non-negotiable)
Set a weekly 30-minute review that answers three questions:
- Where did users drop? Rewrite or reorder that question.
- What did users ask that we didn’t cover? Add it to the knowledge base or intent menu.
- Where should handoff happen earlier? Adjust escalation thresholds.
This is how a chatbot becomes a living system instead of a stale widget.