A reliable chatbot launch starts with decisions, not configuration. Before building, collect the business goal, approved source material, customer journeys, escalation owners, privacy roles, technical access, and acceptance criteria. This checklist turns those inputs into a controlled agency delivery process.
Poor onboarding creates predictable failures: the assistant learns outdated policies, notifications go to the wrong person, a booking calendar uses the wrong timezone, or launch waits for access nobody requested. The checklist below is designed to expose those gaps before they affect customers.
Phase 1: Commercial and project ownership
- Signed scope, commercial terms, start date, target launch date, and change-control process.
- Client sponsor with authority to approve scope, content, privacy decisions, and launch.
- Day-to-day content owner and technical contact with defined response expectations.
- Named agency owner for implementation, testing, documentation, and handoff.
- Agreed communication channel, review cadence, and record of decisions.
Phase 2: Outcome and customer journey
Ask the client to choose one primary result. A chatbot with seven equal priorities is difficult to design and evaluate. Secondary capabilities can still exist, but one journey should define launch success.
| Decision | Questions to answer | Required output |
|---|---|---|
| Audience | Who will use it, where, and in which languages? | Named customer segments and launch pages |
| Primary intent | Which repeated problem should it solve first? | Prioritized intent list with examples |
| Conversion | What useful next action should a visitor complete? | Lead, booking, answer, sale, or escalation definition |
| Human fallback | When must a person take over and who owns it? | Escalation rules, recipients, and response expectation |
| Success | What baseline and outcome will be measured? | Metric definitions, data source, and review date |
Phase 3: Knowledge and answer boundaries
- List approved website domains, sections, documents, FAQs, and policies.
- Identify private, outdated, duplicate, contradictory, or prohibited sources.
- Assign an owner and review date to information that changes frequently.
- Provide real anonymized customer questions, including difficult and incomplete ones.
- Define topics the assistant must decline, qualify, search for, or escalate.
- Agree on how sources should appear and what happens when no reliable answer is available.
Chirps can train on approved website content and documents, and live website search can help retrieve current public pages that are not present in the trained knowledge. Search is not a substitute for clear ownership: verify that the website itself is current and that high-risk answers have suitable boundaries.
Phase 4: Privacy, security, and legal roles
Document who decides why and how personal data is processed, who processes it on whose behalf, what data is necessary, how long it is retained, and how requests or incidents are handled. The European Data Protection Board explains the distinction between controllers and processors. The UK Information Commissioner's Office also provides guidance on controller-processor contracts.
- Approved privacy notice and the link shown to visitors where applicable.
- Cookie and tracking choices appropriate to the client's site and jurisdictions.
- Minimal lead, booking, voice, and conversation fields needed for the workflow.
- Rules for sensitive data, minors, regulated subjects, deletion, retention, and access requests.
- Authorized dashboard users, roles, two-factor authentication expectations, and offboarding process.
- Approved connectors and notification recipients, including credential ownership and revocation.
Phase 5: Experience and brand configuration
| Area | Collect from the client | Verify in staging |
|---|---|---|
| Identity | Assistant name, logo/avatar, brand colors, tone, and supported languages | Readable light/dark modes and accurate identity |
| Entry | Welcome message, starter prompts, attention grabber, and launch pages | No obstruction of navigation, consent, or mobile controls |
| Conversation | Input placeholder, source display, feedback, and uncertainty language | Keyboard, touch, scrolling, links, and long messages |
| Conversion | Lead fields, booking service, timezone, confirmations, and follow-up | Submission, duplicate prevention, notifications, and error recovery |
| Voice | Call mode, number, greeting, language, hours, and transfer rules | Permissions, audio, fallback, inbound/outbound policy, and end state |
Phase 6: Access and installation
- CMS, tag manager, repository, or developer contact needed to install the embed.
- Staging and production domains plus any domain restrictions or content security policy requirements.
- Google Calendar or other booking authorization owned by the correct client account.
- Notification-channel access for email, WhatsApp, SMS, Telegram, Discord, or webhook testing.
- Connector credentials supplied through the intended secure authorization flow, never pasted into project chat or documents.
- Rollback owner and method if the widget must be disabled after launch.
Phase 7: Acceptance testing
Acceptance criteria should describe observable behavior, not a vague request to make the bot smart. Test the same scenarios on desktop and mobile and keep evidence of approval.
- Approved questions return accurate answers and useful links or sources.
- Unsupported questions produce the agreed fallback without invented facts.
- Lead capture records the intended fields and dispatches to the correct recipient.
- Bookings respect service duration, availability, timezone, and confirmation behavior.
- Human takeover and notifications preserve enough context for useful follow-up.
- Cookie choices, privacy links, feedback, close behavior, and session continuity work as agreed.
- The widget is usable on target browsers, mobile widths, keyboard navigation, light mode, and dark mode.
- The host website continues to work when the widget or an external dependency is unavailable.
Phase 8: Launch and handoff
- Written client approval of configuration, source set, tests, and known limitations.
- Launch window, responsible contacts, rollback trigger, and post-launch observation period.
- Dashboard access and role assignment for people who actually need it.
- Short operating guide for conversations, takeover, leads, bookings, analytics, and updates.
- First review meeting scheduled with agreed reports and decision owners.
- Maintenance scope mapped to the monthly chatbot retainer.
How this fits an agency delivery system
Use this checklist after qualifying the niche with the business scorecard and before finalizing the proposal and statement of work. If your service is still being designed, start with the chatbot agency launch guide.
Sources and further reading
- EDPB: Data controller or data processor
- ICO: Contracts and liabilities between controllers and processors
- NIST AI Resource Center
- Chirps documentation
This checklist is general implementation guidance. Privacy, sector, employment, telecommunications, accessibility, and consumer requirements vary; obtain appropriate professional advice.