01

Choose a repeatable support problem

Start with a small group of questions that already have documented answers, such as setting up a workspace or finding a product control. Avoid using a first pilot to resolve account disputes or make exceptions to policy.

Write down what a good answer contains: the relevant step, any prerequisites, and what to do if the step does not work. This gives reviewers a concrete standard rather than asking whether a reply sounds helpful.

02

Give the employee a maintained source

Use current help material with clear headings and a named owner. Remove contradictory versions before adding the source. In Aivah, follow the current knowledge setup guide and review the saved employee’s source status.

Keep a reference copy for testing. Ask the same question in several ordinary ways and verify the answer against that reference. Source processing is a separate check from answer quality.

Read related guides

03

Make clarification useful

For a setup problem, ask which step failed and what error the customer sees. Do not request passwords, secret keys or unnecessary personal information. If the source does not cover the issue, acknowledge that gap.

An illustrative exchange: the customer says setup is stuck; the employee asks for the step and error message; the customer provides them; the employee offers the documented fix or prepares the unresolved details for a specialist. The order matters because a generic fix may not fit the problem.

04

Design the human handoff before launch

Decide who owns unresolved questions and how customers can reach them. A useful handoff includes the customer’s goal, relevant steps already tried, the exact error where appropriate, and the remaining question.

Where an external action is configured, verify the destination record after a controlled test. If the action is unavailable, provide the approved support contact path instead of claiming that a ticket was created.

  • Check permission to share the required context.
  • Avoid copying unrelated conversation history.
  • Confirm that the correct team can see the record.
  • Define the expected response process without inventing a response-time promise.
05

Measure resolution and customer effort together

Review whether answers are correct, whether customers have to repeat themselves and whether cases reopen. A low handoff count can hide customers abandoning the conversation. A high handoff count may be appropriate for complex issues.

Start with a reviewed sample and a small rollout. Keep a record of prompts, responses, source versions and corrections so that improvement means fewer repeated errors, not simply more chats.

Read related guides