Launch checklist

You have configured the experience and tested it as a visitor. This final checklist helps you slow down for one last review before the widget becomes part of the normal customer journey.

You do not need every Zeltino feature to launch. Complete the sections that apply to the experience you built, skip features you have not configured, and focus on whether the full path works from the visitor's first message to the team's follow-up.

In this article, you'll review:

• Knowledge, appearance, and behaviour readiness
• Domain verification and widget installation
• Visitor starting points and automations
• Handoff, team operations, and notifications
• Booking readiness
• How to enable or stop the visitor experience
• What to review after launch

Use this checklist after completing Quick setup and testing the installed visitor journey. The project is ready when the configuration persists, the intended website can show the widget, and your team can work with the records the experience creates.

Knowledge readiness#

Start with the information behind the assistant's answers. Your first-launch topics should each have one current, clearly scoped source.

• [ ] Each first-launch topic has a current website or text source.
• [ ] Website URLs are public and use the canonical https:// address.
• [ ] Source hints state when the assistant should rely on each source.
• [ ] Important sources show a ready state such as Fetched or Complete.
• [ ] Conflicting or outdated information has been corrected or removed.
• [ ] Test questions preserve important prices, conditions, restrictions, and exceptions from the source.
• [ ] A question not answered by the sources does not produce an invented business fact.

Appearance and trust#

Next, look at the widget as a visitor would. It should be readable, recognizable, and connected to real privacy and support destinations.

• [ ] The agent name and subtitle are appropriate for visitors.
• [ ] Text and chat bubbles remain readable against the selected colors.
• [ ] The widget preview has been checked at wide and narrow sizes.
• [ ] The support email works and belongs to the team that will receive visitor contact.
• [ ] Privacy text and the privacy URL are current and approved for the website.
• [ ] Email, restart, and voice controls are enabled only when the team wants visitors to use them.
• [ ] Appearance still shows the saved configuration after reload.

Behaviour and boundaries#

The assistant should sound appropriate in both routine and difficult conversations. Its boundaries should be deliberate and specific.

• [ ] The voice style fits normal factual and explanatory replies.
• [ ] Emoji use matches the intended customer communication.
• [ ] Excluded subjects are specific enough to test.
• [ ] Direct and indirect versions of each excluded subject have been tested.
• [ ] Behaviour layers contain style and handling instructions, not business facts.
• [ ] Enabled layers do not conflict with one another.
• [ ] Behaviour still shows the saved configuration after reload.

Domain and widget installation#

This section confirms that the production website—not only a preview or test page—can load the correct project widget.

• [ ] The Installation domain matches the public website where the widget is installed.
• [ ] The project-specific script is installed in the site-wide location required by the website platform.
• [ ] The latest website changes are published.
• [ ] The domain status is Active and verification shows Passed.
• [ ] Enable chat widget on this website is turned on for the launch domain.
• [ ] The widget opens from a private browser window on the production page.
• [ ] The widget does not appear on an unapproved domain.
• [ ] The website still loads and navigates normally with the widget installed.

Visitor starting points and automations#

Review only the prompts and journeys you plan to use at launch. Every active path should have a clear trigger, ready dependencies, and a tested ending.

• [ ] Suggested questions use clear visitor language.
• [ ] Their When to show and page targeting settings match the intended journey.
• [ ] Every active chat flow has a valid trigger and a tested action path.
• [ ] Every reachable branch has been tested, not only the primary branch.
• [ ] Lead-capture actions use an active lead form.
• [ ] Meeting actions use an eligible public meeting type with saved availability.
• [ ] Ticket actions capture an email before ticket creation on every reachable branch.
• [ ] Referenced categories, meeting types, forms, and assignees are still available.
• [ ] Draft or paused items are not expected to run for visitors.

Skip checklist items for features you have not configured. Do not activate an extra feature only to make the checklist longer.

Handoff and team operations#

A visitor handoff is ready only when the team can find, understand, and work with the resulting record.

• [ ] The escalation form requests email and only the optional details the team needs.
• [ ] Ticket creation and category routing match the intended handoff.
• [ ] At least one teammate can find and work the resulting conversation.
• [ ] Teammates understand the difference between a visitor message, an internal conversation comment, a customer ticket reply, and an internal ticket note.
• [ ] Lead, ticket, and booking test records contain the expected submitted values and links.
• [ ] Test records have been resolved, archived, closed, or cancelled as appropriate after review.
• [ ] Role access has been checked with the least-privileged teammate expected to do the work.

Notifications#

Notifications should reach the people responsible for the event without creating noise for the rest of the workspace.

• [ ] Workspace email/mobile policy is enabled only for the events the team wants.
• [ ] Category notifications are enabled only for categories that need attention.
• [ ] Active workspace members know which alerts they will receive.
• [ ] Personal mobile preferences have been checked on supported devices.
• [ ] A test event reaches the expected recipient and opens the correct record.

Booking readiness#

If visitors can book a meeting, complete one booking exactly as a customer would. This confirms that availability and the public meeting experience agree.

• [ ] The meeting host and timezone are correct.
• [ ] Weekly availability and date overrides reflect real working hours.
• [ ] Duration, buffers, slot interval, minimum notice, and booking horizon are intentional.
• [ ] One-on-one or group capacity matches the intended meeting type.
• [ ] The phone or HTTPS video location is usable.
• [ ] The public booking page and confirmation copy have been reviewed.
• [ ] A complete test booking appears in Zeltino and can be rescheduled or cancelled.

Measurement and review#

Decide who will review the first real conversations and when the team will look at analytics. Ownership matters more than collecting a large number of metrics on day one.

• [ ] The team knows when telemetry coverage begins for the project.
• [ ] The launch date and the configuration being launched are recorded internally.
• [ ] Someone owns the first conversation review after launch.
• [ ] Someone owns the first analytics review after a suitable observation period.
• [ ] The team will compare metrics with actual conversations before deciding what to change.
• [ ] The team has agreed to change one meaningful knowledge, behaviour, or automation element at a time.

Enable the visitor experience#

When all applicable checks pass, you are ready to make the widget available on the launch domain:

1. In Settings > Installation, open the verified launch domain.
2. Turn on Enable chat widget on this website if it is not already enabled.
3. Open the public site in a fresh private browser window.
4. Complete one final question and one configured visitor outcome.
5. Confirm the conversation and any connected record in Zeltino.

The verified-domain widget control is the saved availability setting for that website. Complete the final question and visitor outcome before considering the launch finished.

If you need to stop the widget#

If you notice a serious problem after enabling the widget, you can stop the visitor experience on that domain without deleting the project configuration or existing records.

1. In Settings > Installation, open the affected domain.
2. Turn off Enable chat widget on this website.
3. Confirm that the setting is saved.
4. Open the website in a fresh private window and verify that the visitor widget is no longer available there.

Disabling the widget on a domain does not delete its existing conversations, leads, tickets, bookings, knowledge sources, or configuration.

After launch#

Launch is the beginning of the learning process, not the end of configuration. Review new conversations for unanswered questions, incorrect source use, confusing wording, unexpected flow branches, and failed handoffs. Use analytics to identify where to investigate, then use the underlying conversations and configuration to decide what should change.

Repeat Test the complete visitor experience after material changes to knowledge, behaviour, installation, automations, escalation, notifications, or booking.