Write useful answering guidance

When to use Answering guidance#

Use guidance when a fact alone does not explain the intended response. Examples include asking which model a customer owns before discussing compatibility, explaining a returns exception carefully, or requiring a person to review a sensitive request.

Keep the factual policy in a Business facts entry or accessible website page. Then write handling guidance that refers to that policy. This separation makes it easier to update a real fee or timeframe without accidentally leaving a conflicting instruction behind.

Create a scoped guidance entry#

1. Open Knowledge → Add Knowledge.
2. Write a clear Title, such as “Handling warranty exceptions”.
3. Choose the website or Shared workspace Knowledge scope.
4. Select Answering guidance as the Type.
5. Write the instructions in Content and choose Save Knowledge.

Owners and admins can maintain these entries. Website scope is safest when handling differs between brands or domains. Shared guidance influences every website in that workspace.

Make the decision rule concrete#

When a customer reports a possible warranty issue, ask for the
product model and a short description of the fault.
Explain only the warranty terms recorded in our verified policy.
Do not promise that a refund or replacement has been approved.
If the request needs an exception or human judgment, explain the
next contact step. Invite the Talk to the team form only when
human handoff is enabled for this workspace.

Use this as a structure and adapt it to your own business policy. Give the assistant a clear trigger, useful follow-up and honest next step. Avoid sweeping instructions such as “always say yes” or “never mention a limitation”.

Respect real capabilities and confirmation#

Guidance is prioritised during answer preparation, but it cannot authorise an order update, verify a customer identity or submit a request on its own. An available Action must be configured and enabled for an operation. A human handoff request requires the visitor's email, phone and explicit confirmation through the form.

Do not ask the assistant to claim that an email was sent, a booking exists or an exception was approved before the corresponding result is known. “Be helpful” should mean a truthful, relevant next step rather than a fabricated completed outcome.

Do not use guidance as a secret store#

The guidance label distinguishes handling instructions from business facts; it is not an access-control boundary for confidential material. Do not put passwords, API credentials, internal customer records or information that must never influence a public response into an entry.

Keep guidance compatible with verified sources. If a source and instruction disagree, correct the inconsistency rather than trying to hide it with wording. You can pause an entry by clearing Use this entry in answers.

Test the boundary as well as the ideal case#

Use a private test for an ordinary question, a borderline exception and a request that the assistant cannot complete. Inspect what it actually says and check that the follow-up remains useful.

Then test the installed widget if guidance depends on the current page, handoff or Actions. The private Knowledge preview does not execute those live flows. After edits, re-test the affected question; previously recorded answers are not rewritten.

Worked example: ask one useful compatibility question#

A customer asks whether a charger fits their device. The approved compatibility facts distinguish device models, but the customer has not named theirs. Guidance tells the assistant to ask for that model before applying the relevant rule, instead of collecting a full postal address or account record for an ordinary public-product question.

When the model is known, the reply uses the supported compatibility facts. If that model is not documented, the guidance points to the approved enquiry route without saying it probably fits. The reviewer checks both a listed model and an unlisted one. The aim is to obtain the missing decision input and stop at the factual boundary, not to make every answer longer.

Remove conflicting handling instructions#

If two active guidance entries give different directions for the same case, assign one approved policy owner and reconcile them. Separate instructions that govern different situations with explicit triggers; pause obsolete versions rather than hoping an implied priority will resolve the conflict. Do not claim that source ordering creates a guaranteed decision rule.

Check whether the revised guidance still fits each website in its scope. A useful contact instruction for one brand can be wrong for another. Keep the actual contact facts in their maintained source and test whether the customer receives the right route. The evaluation section below adds language, boundary and live-flow checks where those dependencies exist.

Use a trigger, a useful question and a stopping point#

Write guidance around a recognizable situation. For example, when a customer asks whether an accessory fits their device, the assistant needs the device model before choosing a compatibility rule. The trigger is the compatibility question; the follow-up is the model; the factual answer comes from verified product information. This is more useful than a broad instruction to be helpful, which supplies no missing decision input.

Add a stopping point for cases outside the available information. If compatibility is not recorded for the named model, ask the customer to use the approved contact route rather than claiming it should probably fit. Guidance should make the limitation understandable and actionable. It should not suppress uncertainty or instruct the assistant to invent a confident answer. Ask only for information the support task needs; do not collect full account details merely to explain a public product policy.

Keep each instruction coherent enough to test. A source containing dozens of unrelated rules is harder to review than entries with distinct subjects and owners. Use website scope where handling differs by brand. Check whether another active instruction contradicts the new one. If one says to promise immediate approval and another requires team review, clarify the intended behaviour instead of layering a third general instruction over both.

Worked example: explain a limit without abandoning the customer#

Consider a customer asking for an unsupported custom product alteration. The weak direction “never tell a customer we cannot help” encourages a promise the business has not made. A better instruction identifies the alteration requested, explains only the published options and gives the genuine custom-enquiry route if the business has one. If there is no such route, it should not invent a submission or approval.

Keep the product options and fees in Business facts or the approved page. The guidance handles the moment when the request falls outside them. It can ask a relevant clarifying question if that would distinguish a supported option, but it should not make the customer provide private account information to discover an unavailable public service.

Test a standard supported option, an ambiguous option and an explicitly unsupported change. Record whether the assistant distinguished the cases and provided a reachable next step. If the business later enables a connected custom-request operation, verify that configuration separately before updating the handling instruction. A polite conversation and an external request are separate outcomes; the guidance should use wording that accurately reflects which one has occurred.

Evaluate the handling rather than just its tone#

Write the intended behaviour before running a test. The ordinary case may require a direct answer; an ambiguous case a follow-up; an unavailable operation an honest boundary. Check that the assistant asks only the useful question and does not make the customer repeat information already available in the conversation. Also check that the explanation remains consistent with the source policy after the guidance is applied.

For a multilingual business, test a representative question in another customer language while keeping the underlying factual rule unchanged. Translation should not expand a return exception or turn an estimate into a guarantee. If the guidance depends on a product page, test the installed widget there. If it depends on handoff or Action confirmation, test that live flow separately. Private test is not an execution test for those connected functions.

After changing guidance, inspect the next answer rather than expecting earlier transcript text to change. Keep an approved owner and a review event for the instruction. If the rule becomes obsolete, pause or edit it rather than leaving multiple competing directions active. Avoid secrets or private customer records in the entry: the guidance label marks its purpose but is not a confidential vault. Use narrow business instructions whose contents are appropriate to influence a customer-facing response.