Launch planning
A Website Chatbot Launch Checklist with Clear Stop Rules
Plan a controlled website chatbot launch with owners, evidence gates, customer-path checks and a rollback runbook. Includes a worked launch decision.
By HostDesk · Updated · 7 min read
A working chat window is one part of a launch. Someone also needs to own the approved answers, receive exceptions, confirm what the assistant may do and stop the rollout when the real customer path fails.
This product-agnostic checklist organizes those decisions in order. Use it after defining your use case and acceptance tests. It is an operating runbook, not evidence that a particular vendor includes every control described here.
Agree on a narrow first scope
Write one sentence describing who the assistant will help, which pages it appears on and which tasks it will support. An initial scope might cover general service questions and a route to the team while leaving account changes and live availability outside the rollout. Choose the scope your business can verify and operate.
Name the person authorized to approve the launch and the person who can stop it. They may be the same person in a small business, but the responsibility should be explicit. Record the launch window, timezone, available support coverage and where the team will report a problem.
NIST's AI RMF treats monitoring and response as ongoing responsibilities and includes mechanisms for disengaging systems when needed. This checklist translates that general principle into a small-business launch sequence; completing it is not a compliance certification.
| Decision | Required entry |
|---|---|
| Scope | Audience, included pages, supported tasks and explicit boundaries. |
| Authority | Approver, operator and source owners with a reachable contact route. |
| Coverage | Hours, timezone and how requests wait when the team is unavailable. |
| Stop mechanism | Who disables the affected experience and how the normal contact route remains usable. |
| Evidence | Versioned sources, acceptance results and a record of the final decision. |
Approve the sources before exposing the assistant
Have responsible owners review the prices, conditions, service areas and exceptions in the initial scope. Resolve contradictions instead of assuming the assistant will choose the right page. Keep the source version used for acceptance testing so you can tell whether a later failure came from a content change.
Check regional differences explicitly. A business serving US and Canadian customers should make currency, supported locations, contact hours and relevant policy versions clear where they differ. Avoid creating location pages or alternate policies simply to fill a geographic template.
Remove material the assistant should not use, and decide how unavailable or private information will be handled. A visitor's statement that they qualify for a discount is not approval from the business. If a workflow depends on an authorized provider, verify that exact connection and deployed environment separately rather than relying on a setup label.
Run acceptance cases and preserve the actual replies
Test the main questions, important exceptions, unsupported requests and temporary failures. Write the expected behavior before running each case. Save the actual reply, evidence references, destination and any authorized receipt. A screenshot of a friendly greeting is not proof that the difficult cases work.
Check the full customer path on the deployed site. Can a visitor open and close the assistant, read the answer, follow the relevant link and recover from an error? Use the devices and access methods that matter to the audience. A hidden button or inaccessible confirmation can break an otherwise accurate answer.
W3C's form-notification guidance explains that people need clear feedback about both successful and unsuccessful submissions. Apply that principle when a chat flow passes a visitor into a form: the user should know what happened and what remains to be done. A narrow spot check does not certify accessibility.
| Gate | Evidence to preserve | Reason to pause |
|---|---|---|
| Answer | Applicable approved source and actual reply. | Unsupported price, policy or exception. |
| Interface | Observed mobile and keyboard path, including close and recovery. | A customer cannot reach or understand the next step. |
| Request | Actual saved request record and receiving route where supported. | The interface claims success without the corresponding record. |
| Boundary | Reply when information or an authorized tool is unavailable. | Invented availability, completion or private information. |
| Stop | Rehearsed operator action and working ordinary contact path. | No reliable way to stop the affected flow. |
Rehearse an ordinary request and a failure
Send a clearly labelled test through the permitted request route and have the receiving person locate it. Confirm the difference between a record being saved, a notification being delivered and a person following up. Write who checks the queue when the usual owner is away.
Then rehearse a safe failure. Use a controlled test setting or a supported simulation rather than deliberately breaking a live provider. Check what customers see when a destination is unavailable and whether the ordinary contact route remains clear. The goal is an understandable limit, not an assertion that an unavailable action succeeded.
Prepare the stop procedure in concrete terms: affected pages or workflow, authorized operator, exact control, verification step and communication owner. Removing the whole assistant may be unnecessary if the platform can reliably disable only the affected action, but do not assume that selective control exists until verified.
Worked example: a launch that should wait
This is a fictional service-business rehearsal. The approved scope covers answering service questions and saving appointment requests. Tests confirm the general policy answers, but a mobile request produces 'Your visit is booked' while the only saved record is an unconfirmed enquiry. The receiving team also cannot find a request made after hours.
The correct launch decision is pause, with two separate fixes. The completion wording must reflect an enquiry rather than a confirmed appointment. The operator must locate and verify the receiving path before exposure expands. Passing the policy questions does not compensate for either defect.
A closure record would contain the corrected deployed reply, an actual test enquiry reference, receiving-team confirmation of its presence and a repeated after-hours case. These are required future checks in the fictional runbook, not results we observed in HostDesk or any customer account.
| Field | Entry |
|---|---|
| Decision | Pause the request workflow; do not expand exposure. |
| Owners | Content owner corrects status wording; operator verifies the receiving path. |
| Retest | Mobile submission, after-hours request, actual record read-back and accurate status. |
| Resume condition | Approver reviews preserved evidence and signs a new scope/version decision. |
Expand in stages with a named review point
Start with exposure small enough that the team can inspect what happens and respond promptly. Define the first review point before launch: a chosen date or a manageable number of real conversations. That number is an operating choice, not a universal safe sample size or proof of statistical reliability.
Review accuracy, customer burden, failed requests and workload alongside any business outcomes. Keep incidents separate from routine sampled quality rates. A serious problem can require an immediate pause even while the aggregate score looks acceptable.
Before adding pages, languages or actions, repeat the affected evidence and operation checks. Keep a changelog connecting each expansion to source versions, acceptance cases and the approver. A launch is successful when the supported customer path works and the business can maintain it, rather than when the widget is merely visible.