Review customer conversations

Open a retained conversation#

Sign in with owner or admin access to the workspace and select Conversations. The list shows recent retained conversations, with their website, creation time, first-message preview, status and message count. Helpful or not helpful feedback appears when the visitor has submitted it.

Select a conversation to read its messages in time order. The detail header shows the website hostname and stored current page path. Stored until shows the transcript's retention expiry, which matters when reviewing an older case.

Use the website filter and know the list limit#

Choose a website from the selector, or All websites to view recent conversations across the workspace. The portal loads the latest 30 retained conversations for the selected scope. It does not provide a conversation search field, transcript export or a next-page control.

If a conversation is not in the list, check the selected workspace, website filter and retention period. The absence of a thread from this recent list does not by itself prove no visitor spoke to the assistant. Removed websites can still have retained conversations under All websites.

Read the full exchange before judging it#

Look at the visitor's original question, the assistant's answer and the next response together. A negative rating may signal an incorrect fact, a missing capability or simply a request that requires human judgment. Check the business source before correcting a policy.

The portal is a transcript review interface, not an agent inbox for live replies. There is no control to type a response to the visitor, assign a teammate or manually resolve the thread here. Use configured human handoff and your business's follow-up channel when a person needs to respond.

Understand status and feedback#

The assistant can mark a conversation resolved when its response indicates a natural completion. A later visitor message can reopen that conversation. A resolved state is a conversational signal, not proof that an order, refund or appointment was completed in another system.

Feedback is a helpful/not helpful conversation rating. It does not rewrite the answer or automatically turn the visitor's statement into verified Knowledge. For handoff delivery, use Escalations rather than expecting the conversation status alone to describe email delivery.

Turn a finding into a verified correction#

1. Identify the exact sentence, missing condition or unsupported promise.
2. Open the relevant Knowledge source and compare it with the original business policy.
3. Correct the website and re-crawl, or edit the manual fact or answering guidance.
4. Test the same question against the updated source.
5. For live data or an operation, verify the relevant connected Action instead of adding a static claim.

Changes affect subsequent answers; the earlier transcript remains a record of what was said. Avoid copying personal customer information into shared Knowledge when documenting the lesson from a conversation.

Worked example: an accurate rule with a missing exception#

A customer asks whether an opened accessory can be returned. The assistant quotes the standard return period, but the current policy excludes a particular sealed category once opened. Review the exact policy paragraph before deciding whether the answer was wrong, incomplete or based on an older source. Check both the website crawl and any manual fact that repeats the rule.

Correct the source containing the omission, refresh it if necessary and ask a new test about the sealed category. Follow it with a normal eligible return. The desired result is a correct distinction between the two, with an appropriate contact route for uncertainty. Keep the review note about the policy condition; the customer’s name and order number are not needed to fix that general answer.

Before you close a review finding#

Confirm that the change reached the same website and source scope as the original conversation. Verify the normal question and the relevant exception, and inspect connected-system evidence separately if an operation was involved. Make sure a promised human follow-up has a configured route rather than relying on a transcript status.

If you cannot reproduce the reported issue, record which retained evidence you could inspect and what remains unknown. A missing old transcript should remain an evidence limit, not become a conclusion that the customer did not ask the question. Keep the final note brief enough that another maintainer can repeat the test.

Build a review sample that answers a question#

Start with a purpose: “Are visitors finding the delivery exceptions?” produces a more useful review than “Read some chats”. Choose a period, select one website and record which retained threads you can actually see. A recent list is a working sample, not an export of all historical traffic. Busy websites can push a reported conversation out of the latest thirty even before its retention expires.

Read a few successful exchanges as well as complaints. A correct answer followed by another question can reveal that the next step was unclear, while a negative rating after an accurate refusal may indicate a capability gap. Record the business issue in ordinary terms: “Collection times missing on the locations page”, rather than saving the customer's full message in a shared document.

For each finding, keep the question type, page, source you checked, proposed change and the result of a fresh test. Use a short anonymised example if it helps the person maintaining that source. Do not paste addresses, order references or contact details into Business facts. If a case needs a private record, take it through the approved business support process. This keeps a review programme useful without creating a second uncontrolled transcript archive.

Separate a good answer from a completed operation#

Suppose the visitor asks to change a delivery address. A reply that explains how to ask the team can be a successful support answer without changing the order. A reply saying that an Action completed needs stronger evidence: inspect the relevant Action run and the record in the connected system. Neither a resolved conversation nor a friendly final message establishes that the address was updated.

Record these outcomes separately when assessing quality. “Policy explained”, “request handed to the team” and “external operation confirmed” describe different results. If a conversation contains an attempted lookup, check whether the returned result was authoritative, whether it was interpreted correctly and whether the visitor had permission to see it. If the operation was blocked, an honest explanation and useful alternative may be the right answer.

Do not turn a handful of reviewed threads into a claim about sales conversion or total support savings. Conversation review shows the interactions available in the portal. Wider performance questions need a defined measurement method and the appropriate analytics or business records. This distinction is particularly useful when an answer was accurate but the customer still abandoned a purchase for another reason.

Run a small, repeatable quality routine#

Choose one manageable question family each week, such as returns eligibility or store opening hours. Compare the reviewed answers with the current source of truth, identify the smallest source change that fixes the problem and assign that change to the person who maintains the information. If the same condition is inconsistent across two sources, remove the contradiction before adding another instruction.

After the change, test the original question and a nearby exception. For a returns rule, include an ordinary unopened item, an excluded item and a request outside the stated period. A single happy-path reply does not show that the exception is handled. Then review later real conversations for the same topic when they are available. Keep the earlier transcript unchanged as evidence of the earlier answer.

Decide when a finding can be closed. A missing fact is closed when the corrected source is usable and the test explains it appropriately. A broken operation is closed when the connected result is correct and authorised. A handoff issue is closed when the configured route works and the team understands its follow-up responsibility. These concrete completion criteria keep reviews from becoming a cycle of vague “make the assistant better” requests.