Use launch and improvement checklists

Use this guide before every public launch and during the first weeks after launch. You will test the whole experience, name the reviewer, and improve from evidence instead of changing several things at once.

Before you begin

Make sure the employee has one clear job, an owner, current source material, finished preparation, and a private test route. Identify who can approve knowledge, instructions, consent wording, and connected actions.

Steps

Before you publish

Use this quick review alongside the detailed steps below. It is a reminder, not an automated test or a certification. Keep a separate record of your results and the owner's approval.

Before you publishReset checklist

Tick each item after testing it. For optional features, confirm that they are disabled or not applicable. Progress stays only while this guide is open; refreshing resets it.

Review the visitor experience

Known questions match the current, approved sources.Unknown questions get an honest response and an approved help route.The correct employee, greeting, face, and voice are used, where enabled.Connected actions are limited; sending or changing information requires confirmation.Lead fields and consent are approved; an authorised test reaches the intended destination, if enabled.The intended visitor can use the link or embed on both a phone and a larger screen.Private information is not exposed; stop/end controls work where applicable.An owner, review date, and usage budget are agreed.

0 of 8 reviewed. Keep the experience private until every applicable check passes.

1. Complete the private test

Open the employee in Employees and review Overview and Knowledge. Use Talk to [employee name] or start a new conversation in Chat with the intended employee. Completed processing does not replace the answer checks below.

Check all of the following:

• Ask at least five questions directly answered by the sources.
• Ask at least three questions the sources do not answer.
• Test one request the employee should refuse and one it should hand to a person.
• Test every approved connected action and its confirmation step.
• Check the opening message, voice, appearance, and microphone or camera controls that apply.
• Confirm lead fields and consent wording with the responsible owner.

2. Test the public experience

Use Deploy → Web & embeds to find the intended experience, then test every published direct link and website placement. Use both a phone-sized screen and a larger screen, and test text and voice separately when enabled.

If lead capture is enabled, arrange an authorised test with the receiving team and label it clearly as test data. Confirm where it arrives. Use a sandbox or an approved reversible test for connected actions; do not charge a card, send messages to real customers, or delete data just to test the agent. Test the intended visitor access in a private browser window as well, including any access restrictions you configured.

3. Record launch ownership

Record the launch date, the employee name, the published methods, the enabled actions, the reviewer, the review schedule, and the usage-credit budget approved by your organization.

4. Launch in one place

Begin with one link or placement. Monitor it before expanding to more audiences or channels.

5. Run the weekly improvement review

Use Insights and the detailed records available in Chat history, Leads, Quiz, and Call history.

1. Read examples that need attention.
2. Group repeated questions, failures, and missing knowledge.
3. Check source, phone, and connected-action failures.
4. Update one knowledge or instruction issue.
5. Retest privately before changing the public version.
6. Compare the later records with the earlier examples.

Expected result

The public experience has passed a documented private and visitor test. Your team knows who reviews it, when the next review happens, which actions and consent wording were approved, and what evidence will trigger an improvement.

Status meanings

Use Ready to launch only as your team's checklist decision after every required test passes. Use Needs work when a source, boundary, consent choice, connected action, handoff, visitor path, or review owner is incomplete. These are review decisions, not Aivah system statuses.

Usage credit impact

Private tests, public conversations, voice, content generation, and connected activity may use usage credits. No fixed calculation is documented here. Review the current balance in the workspace and set a budget before launch.

Information stored or shared

A public employee can create conversations, lead submissions, call or quiz records, usage, and connected-service activity depending on its setup. Connected services may receive the information needed for an approved action. Collect only necessary visitor information and protect any exported records.

Limits and permanent actions

Insights distinguishes usage analytics from summaries based on up to 50 recent records; some signals use keyword estimates. Review the employee, date range, and underlying records before making a decision. Do not assume an export includes all history. Do not enable irreversible public actions without confirmation and human review. Retest every link and website placement after an update.

Common problems and recovery

• Preparation is not completed: open the employee details, use Refresh status, and inspect the source problem before publishing. A refresh alone does not repair it.
• Unknown questions produce guesses: add an explicit unavailable-information response and handoff rule.
• A public action is too powerful: remove it or reduce permissions before launch.
• A test lead is missing: confirm the employee and date range in Insights, open Leads, and check other pages.
• The results are unclear: read the detailed records and change only one source or instruction before retesting.

Next step

Use Manage, test, and improve an AI employee for the full quality loop, then publish and manage a shared experience.