Skip to documentation

Test answers privately

Use the private preview to test Knowledge quality. Use the installed website widget to test the whole customer experience.

8 min readUpdated 6 October 2026

Create a five-question test#

An owner or admin can open Websites, choose the website, and select Private test. Choose Create five-question test, then Open private test or Copy test link.

The link authorises a preview for that website's Knowledge. It is valid for 24 hours and contains private access information, so share it only with intended reviewers. Creating a new test revokes unfinished previous tests for the same website. Reopening an older link is not a reliable way to keep a second review session running.

In your workspaceCreate the preview for the correct website
WorkspaceSelect the business account
WebsitesOpen the intended website
Private testCreate the five-question preview
KnowledgeReview the sources this website can use
The preview is scoped to the selected website and its enabled Knowledge.

What the preview tests#

The private preview sends real questions to the assistant using the site's current enabled Knowledge, including shared workspace entries that apply to the site. It keeps a short question-and-answer history within that test and asks the assistant to answer in the visitor's language.

It does not consume the workspace's customer conversation allowance. It is a Knowledge preview, not the installed storefront widget: it does not reproduce the visitor's current product page, authenticated customer context, live Action execution or the customer handoff form. Validate those on the actual website after configuration.

Data boundariesWhat enters a private answer test
Keep these boundaries clear
Website sourcesEnabled Knowledge attached to this website
Shared sourcesEnabled entries in the same workspace
Preview historyThe short question sequence in this session
Excluded pathsLive page context, private Actions and handoff form
This diagram shows the scope of the preview, not a promise of a live integration.

Choose questions that expose gaps#

  • A common fact: ask about a frequently requested policy or service and compare the answer with the original source.
  • A useful distinction: ask what differs between two services or products that are both described in Knowledge.
  • Another language: ask a normal customer question in a language your business receives.
  • An unknown: ask for a price, appointment or exception that the business has not documented.
  • A follow-up: refer back to an earlier answer and check whether the conversation remains useful.

Use actual business questions and verify the facts yourself. A fluent answer is not evidence that a missing policy or unavailable operation exists.

Understand the counter and failures#

The preview permits five questions. Successful turns reduce the remaining count. If the answer generation fails, the server releases the question slot; the interface explains that the unavailable answer did not consume it. Once the allowance is exhausted, return to the website workspace and reload it to show Create five-question test again if another review is necessary.

If a link expires, was replaced by a new test, or belongs to a removed website, create a fresh test from the correct website. If a temporary service error persists across fresh tests, keep the question and error text for support without sharing the access token.

Credential lifecycleThe preview has a bounded lifecycle
CreatedOne active preview replaces an unfinished prior test
Question budgetFive questions in the session
ExpiryTwenty-four hours after creation
Technical failureFailed generation releases the reserved slot
The question limit and expiry belong to private tests, not paid usage periods.

Use findings before launch#

For incorrect or incomplete facts, inspect the Knowledge source and fix the website or manual entry. Re-crawl changed website content, or save a corrected business fact, then repeat the question. Existing conversation answers are not rewritten when a source changes.

Finish with a public-widget check on a relevant page. Confirm that the installation is detected, the intended appearance loads, and any configured request or Action has the expected confirmation and result. The private preview alone cannot prove that the live integration is ready.

WorkflowCorrect the source before judging the retest
ReadInspect the actual enabled source snapshot
CorrectUpdate a fact or specific answering boundary
RetestAsk the failed and adjacent question
RecordKeep the source and expected outcome in your test notes
One targeted correction gives a more interpretable result than several unrelated edits.

Worked example: a fact is present, but an exception is missing#

A shop's private preview explains the standard return period correctly but offers the same answer for an opened sealed product. The reviewer compares the stored source with the published policy and sees that the exception paragraph was not collected. This is a source-coverage problem, not evidence that the assistant needs a more enthusiastic tone.

The maintainer adds the verified exception to a website-scoped Business fact or repairs the public page and refreshes its crawl. A fresh preview then tests both an ordinary eligible return and the excluded category. The reviewer closes the issue only when the distinction is preserved. Repeatedly asking the failed question before changing the source would spend preview capacity without checking a correction.

Keep a review record with its evidence limits#

For each run, save the questions, expected source, observed outcome and any source revision made during the run. Use an anonymised maintenance note rather than a copy of personal customer information. Share the private preview only with reviewers authorised for that site's Knowledge.

Mark separately which customer-facing behaviours remain untested. The private preview can support a Knowledge-quality decision; a launch decision also needs the relevant installed page, operation or handoff checks. If the source has not changed and only the answer wording varies, do not claim a fact was repaired merely because a later response sounds better.

Example: spend five questions on a policy revision#

Suppose a retailer changes its delivery policy to support a new country with an exception for oversized items. The review should focus on that revision rather than a general tour of the assistant. Ask whether an ordinary item can be delivered to the new country, ask for the stated timing, ask whether the oversized exception applies, ask what happens for an unsupported destination and use a follow-up that refers to the first answer.

Write the expected source paragraph next to each question before running the test. Amounts, destinations and timing should match the approved policy; unavailable details should remain unavailable. A good result is a clear distinction between supported and unsupported cases, not five confident affirmative replies. Include a language variation in a later dedicated test if the policy translation needs review rather than trying to test everything in one small run.

Keep the source state stable while running the five questions. If a reviewer changes the fact midway, record exactly when that happened and treat subsequent replies as a check of the new state. A mixed-revision run is still useful evidence, but it cannot be presented as five outcomes under one unchanged policy. This simple discipline makes comparisons after a correction meaningful.

Test coverageFive questions, five different checks
FactAn important answer present in an enabled source
ExceptionA condition that changes the ordinary rule
DetailA specific product or service question
UnknownA fact the business has not supplied
BoundaryA request needing an unavailable operation or human route
Suggested questions use your own verified policy and synthetic customer situations.

Map each launch claim to its own test#

For a policy explanation, use the private preview and compare its reply with stored Knowledge. For a product-specific pronoun such as “Does this fit?”, use the installed widget on the relevant product page. For a current order result, use the authorised connected Action and a permitted test record. For human follow-up, submit a controlled confirmed request and check the team's mailbox.

The same words can hide different claims. “Where is my order?” may ask how to find tracking generally, or request a live result for a particular private order. Only the first is an ordinary Knowledge explanation. A preview that explains the tracking process has not shown that a signed-in customer's order ownership is verified or that a provider lookup succeeds.

Use the mapping when preparing the launch sheet: a policy can pass while live lookup remains unconfigured. That is an honest useful first release if the visitor is given the business's real alternative. It is not necessary to pretend that every integration is ready. Production widget tests follow normal customer usage rules, so budget them separately from the private preview rather than interpreting its free review allowance as a production billing exemption.

Compare the evidencePreview and installed widget test different things
Private previewCurrent Knowledge, wording and unknown-answer behaviour
Installed pageDomain detection and current-page support
Live connectionIdentity, authorized records and permitted outputs
Submitted handoffRecorded request and actual delivery state
Use both paths before claiming that the integrated customer experience is ready.

Choose the smallest source correction that fixes the cause#

If the expected fact is missing, read the stored documents and check source readiness, enablement and scope. A public page may have changed after the last collection or extraction may have omitted the relevant paragraph. Publish and re-crawl website text, or add a verified manual fact under the correct website. Reloading the preview alone does not collect a fresh public page.

If the fact exists but the reply makes an unsupported exception, inspect Answering guidance and any other source that states the rule differently. Correct contradictions instead of layering a second instruction over them. Guidance can tell the assistant how to explain the limits; it cannot grant a refund or create a live operation. Keep the policy owner involved when the business rule itself is unclear.

After the focused edit, create a fresh run for the failed case and a nearby ordinary case. If a technical error prevents generation, record the safe error and time and follow troubleshooting before changing unrelated sources. A released preview question slot means that failed generation did not consume that slot; it is not evidence that repeated retries will repair an underlying missing fact.

Need help with this?

Tell us which website, guide and step you are working on. Keep passwords and private customer details out of the message.

Contact Reesponder

Search documentation

Search by task, feature, setting or error. Your search runs in this browser.