Test the complete visitor experience

Before inviting customers to use Zeltino, take one complete journey through it yourself. Open the widget on the installed website, ask the kinds of questions your visitors ask, complete any configured next step, and then review what your team receives.

This is more useful than checking settings one page at a time. It shows whether knowledge, behaviour, page context, automations, and team records work together in the experience your customer will actually see.

In this article, you'll learn:

• How to prepare a reliable test
• How to check the installed widget and its appearance
• How to test knowledge and behaviour
• How to test questions, targeting, and visitor outcomes
• How to review the resulting team records
• How to verify notifications
• How to record problems and finish the launch review

Before you begin#

A good test starts with a known question and a known expected result. Before opening the widget, confirm that:

• the correct workspace and project are selected;
• at least one relevant website or text source is ready;
• Appearance and Behaviour show the saved configuration;
• the website domain is Active in Settings > Installation;
• Enable chat widget on this website is turned on;
• any suggested question, form, contact option, flow, category, or meeting type included in the test is saved and active;
• the teammates receiving test notifications know when the test will run.

Prepare several realistic questions. Write down the expected answer and the source that contains it so the tester can judge the result without guessing. If teammates will receive notifications, let them know when the test is starting.

Test installation and presentation#

Begin with what every visitor encounters first: whether the widget appears and whether it feels usable on the real website.

1. Open the public website in a private browser window.
2. Confirm that the widget appears on the exact domain you verified.
3. Open the widget and check the agent name, subtitle, colors, bubble contrast, and corner radius.
4. Check the privacy and support controls you enabled.
5. Restart the conversation if that control is enabled and confirm that the visitor understands what happened.
6. Repeat the presentation check at a narrow mobile-browser width.

If the widget does not appear, first confirm that the current domain matches the domain in Installation, the latest website changes are published, and the widget is enabled for that domain. Solve the installation issue before testing answers; otherwise later results will not represent the real visitor path.

Test knowledge answers#

Once the widget is visible, move on to the information it provides. Use more than one phrasing for the same topic so you are testing meaning rather than one memorized sentence.

1. Ask a direct question whose answer is stated clearly in a ready knowledge source.
2. Ask the same question with different wording.
3. Ask a question that requires an exception or condition stated in the source.
4. Ask a related question that the source does not answer.
5. Compare each reply with the source rather than with what the tester remembers.

A useful result is grounded in available content, preserves important conditions, and does not invent a missing fact. If a key fact is absent, update the relevant knowledge source and repeat the same question after the source is ready.

Test behaviour boundaries#

Now listen to how the assistant communicates the answer. This is a separate check from factual accuracy: knowledge supplies the facts, while Behaviour shapes tone and boundaries.

1. Check that the selected voice style fits a short factual reply and a longer explanatory reply.
2. If emoji use is off, confirm that the assistant does not add casual emoji decoration.
3. Ask directly about each excluded subject.
4. Ask about the same excluded subject indirectly or with different wording.
5. Confirm that an exclusion does not block a nearby topic the assistant should still answer.

If a reply contains the wrong fact, review knowledge. If the fact is correct but the wording or handling is wrong, review Behaviour.

Test suggested questions and page targeting#

Suggested questions should appear at the right moment and on the right page. Start with a fresh conversation so an earlier message does not affect the display condition.

1. Start a new conversation and confirm that the saved question appears at the configured time.
2. Select the question and check that it sends the exact visitor wording you intended.
3. Confirm that the assistant answers from the expected source.
4. If the question targets a specific page path, open that path and a page outside it.
5. Confirm that the question appears only where intended.

Repeat the test with a fresh conversation when the question is set to Before first message. An existing conversation may already be past that display point.

Test each configured visitor outcome#

Only test the outcomes included in your setup. Follow every branch a visitor can reach, including incomplete or invalid input. A form that opens correctly is not fully tested until the saved result is visible to the team.

Outcome	Visitor check	Team-side check
Lead form	Required and optional fields, consent text, completion message	A lead contains the submitted values and links to the relevant context
Callback option	Phone capture and completion message	The lead contains the callback details expected by the team
Schedule call	Available slots, timezone, questions, and confirmation	The booking appears with the expected meeting type, host, invitee, and linked records
Enquiry or escalation	Required contact fields and confirmation	The conversation is available and a ticket is created only when that option is configured
Chat flow	Trigger, messages, questions, branches, and final action	Captured details, category, lead, ticket, or booking match the tested branch

For a branched flow, test every answer path. A successful primary route does not prove that another branch has valid dependencies.

Review the conversation#

After finishing the visitor side, switch back to Zeltino. The conversation and its connected records show whether the journey produced the context your team needs.

1. In Zeltino, open Conversations.
2. Find the test conversation and read the message sequence from the beginning.
3. Review captured details, categories, routing evidence, visitor context, and linked outcomes that apply to the test.
4. Open any linked lead, ticket, or booking and compare it with the values entered by the tester.
5. Confirm that internal comments and notes remain team-only and do not appear as visitor messages.

Review the actual evidence and captured fields. Do not treat a generated overview as a substitute for the underlying messages and records.

Test notifications#

If workspace or category notifications are enabled, create each covered event deliberately rather than assuming one successful alert proves the rest:

1. Create the exact event covered by the notification policy.
2. Confirm that an active workspace member receives the expected email or supported mobile alert.
3. Select the notification and confirm that it opens the correct workspace and record.
4. Confirm that a personal mobile opt-out prevents that alert for the opted-out device without changing the workspace policy.

Test new-conversation, new-lead, and category events separately. One successful event does not verify the others.

Record the result#

When a test fails, capture enough context to repeat it. For each failure, record:

• the workspace and project;
• the website domain and page path;
• the test time and visitor wording;
• the expected source, trigger, action, or notification;
• the actual visitor result;
• the resulting conversation, lead, ticket, or booking identifier available in the UI.

Change one relevant setting, save it, and repeat the same wording and path. Keeping the test stable makes it easier to see whether the change solved the problem.

Finish the launch review#

When the complete path works from a fresh visitor session and the expected team records are correct, you are ready for the final readiness check. Complete the Launch checklist before enabling the experience for normal customer traffic.