PlaysbyMoat8
Back to the library
The workflow guideSupport

Answer routine support questions with a clear human handoff

Use an approved help center to draft concise answers while routing unsupported or sensitive requests to a person.

6 implementation stepsAdvanced

How this works

Use an approved help center to draft concise answers while routing unsupported or sensitive requests to a person.

Use the maintained help center for bounded answers and make human escalation an ordinary part of the service. Retrieval quality and a confident tone do not establish resolution; track what happened after the reply and honor explicit requests for a person.

Before you start

Defined operating scope

Routine service questions have approved answers and clear reasons for human handoff.

Required source material

Obtain Maintained help-center articles; Anonymized evaluation questions; Handoff and data-handling rules. If connectors are unavailable, use authorized files with the same fields.

Decision and exception rules

The user asks for a human. Initiate the defined handoff without forcing more bot troubleshooting.

Prepare the inputs

help_corpus
Required

Approved articles and supported versions

Keep current and retired material distinguishable.

customer_question
Required

Question and permitted context

Avoid collecting unnecessary sensitive information.

evaluation_set
Required

Anonymized questions and expected behavior

Include unanswerable and escalation examples.

handoff_rules
Required

Human requests, sensitive topics and unsupported inputs

Define a working destination and acknowledgement.

Implementation, step by step

  1. Establish the working record

    • Confirm the selected records, effective versions and responsible owner.
    • Check help_corpus, customer_question, evaluation_set, handoff_rules before beginning. Record the source version and the selected scope; an unavailable value stays unknown rather than becoming an inferred fact.

    Checkpoint: The input record identifies the selected help_corpus and any missing required fields.

  2. Prepare clear knowledge articles with relevant synonyms

    • Prepare concise articles with relevant terminology and synonyms while retaining clear applicability limits.
    • Test supported, unsupported, sensitive and human-request cases end to end.

    Checkpoint: A saved intermediate result for: Prepare clear knowledge articles with relevant synonyms.

  3. Evaluate responses against expected answers and improve weak coverage

    • Evaluate answerable questions, missing coverage and escalation cases; fix knowledge gaps or routing before opening wider access.
    • Distinguish answered, user-confirmed resolved and successfully handed-off outcomes.

    Checkpoint: A saved intermediate result for: Evaluate responses against expected answers and improve weak coverage.

  4. Answer supported questions and disclose that an assistant is responding

    • Draft a supported answer with source context and make clear that an assistant is responding.
    • Test supported, unsupported, sensitive and human-request cases end to end.

    Checkpoint: A saved intermediate result for: Answer supported questions and disclose that an assistant is responding.

  5. Escalate low-confidence, sensitive, unsupported-media, or human-request cases and track outcomes

    • Escalate unsupported or sensitive questions and human requests, preserving context and verifying the handoff receipt.
    • Distinguish answered, user-confirmed resolved and successfully handed-off outcomes.

    Checkpoint: A saved intermediate result for: Escalate low-confidence, sensitive, unsupported-media, or human-request cases and track outcomes.

  6. Package the result and unresolved work

    • Validate handoff behavior and resolution criteria. A thank-you does not prove resolution; confidence scores and retrieval alone do not guarantee accuracy.
    • A thank-you or high confidence score is not proof of resolution.

    Checkpoint: A bounded support workflow with accessible human escalation. Unresolved items remain visible in the review record.

Decisions along the way

The user asks for a human.

Initiate the defined handoff without forcing more bot troubleshooting.

Only weakly related articles are retrieved.

State the gap and escalate rather than assembling an unsupported answer.

The handoff destination fails.

Tell the user the transfer is not confirmed and provide the approved fallback path.

What you will produce

knowledge-support-with-clear-handoff-result.json

JSON

A bounded support workflow with accessible human escalation. Label proposed and completed states separately.

Include: question_id · answer_or_handoff · supporting_articles · coverage_gap · handoff_receipt · resolution_state · status · evidence_reference · review_note

knowledge-support-with-clear-handoff-review.md

Markdown

Keep the evidence and unresolved decisions needed to apply this result, including exceptions involving handoff_rules.

Include: source_reference · question · owner · next_action

Check the result

  • Test supported, unsupported, sensitive and human-request cases end to end.
  • Distinguish answered, user-confirmed resolved and successfully handed-off outcomes.
  • Inspect help_corpus and customer_question in both the original and output; confirm that record identity and interpretation survived the transformation.
  • Validate handoff behavior and resolution criteria. A thank-you does not prove resolution; confidence scores and retrieval alone do not guarantee accuracy.

When something goes wrong

The user asks for a human.

Initiate the defined handoff without forcing more bot troubleshooting. Retain the affected evidence and recovery status.

Only weakly related articles are retrieved.

State the gap and escalate rather than assembling an unsupported answer. Retain the affected evidence and recovery status.

The handoff destination fails.

Tell the user the transfer is not confirmed and provide the approved fallback path. Retain the affected evidence and recovery status.

A worked example

SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT

Request

Answer routine support questions with a clear human handoff for the following bounded example; prepare the result for review.

Inputs

Synthetic example: User asks about a billing exception not covered by the help center and explicitly requests a person. The assistant finds only general billing FAQs.

Expected result

Synthetic expected result: Acknowledge the request, capture necessary context and route to billing support. General FAQs are not presented as a ruling on the exception; transfer status is verified.

Run a small pilot

Start small

Trial a representative batch containing the ordinary case and the exception demonstrated above.

Record the baseline

Record current preparation time, review effort and correction types for the same records.

Agree success criteria

Agree acceptable review and error limits; measure verified resolution rate; correct handoff rate and unsupported-answer rate.

Stop or revise

The handoff destination fails. Pause affected records and apply this recovery: Tell the user the transfer is not confirmed and provide the approved fallback path.

Keep the scope clear

  • A thank-you or high confidence score is not proof of resolution.
  • Do not take account actions beyond the approved support scope or claim an unverified handoff succeeded.

Check before using

Validate handoff behavior and resolution criteria. A thank-you does not prove resolution; confidence scores and retrieval alone do not guarantee accuracy.

Business activities

  • Resolve customer questions

Editorially adapted workflow; not independently tested.

FROM A RECIPE TO YOUR WORKFLOW

Bring the company context together.

This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.

For this recipe: Maintained help-center articles · Anonymized evaluation questions · Handoff and data-handling rules

Start with one recurring task, agree which sources to use, and review the first result with your team.

Discuss this workflow

What does your team do?

Choose the recurring work you would like to improve.

A field guide, made for work.

Plays is a curated library of anonymized business workflows. Each recipe explains the inputs, steps, tools, and checks you can adapt to your team. These are editorial guides, not independently tested implementations.

When you share a company website, the guide may read a limited number of public pages on that website. Messages and retrieved page text are sent to our AI provider, NVIDIA, to recommend relevant workflows. Share a general description rather than confidential information.

Saved workflows and selected activities stay in this browser. Your chat history and selected company website are kept in this tab and cleared when you reload or start a new chat. The server does not store conversations. Live source monitoring is not enabled.

If you allow analytics, PostHog receives page views and actions such as workflow saves, skill downloads and link clicks. Random browser and session identifiers connect these actions without identifying you by name. Your choice and browser identifier expire after 90 days; sessions restart after 30 minutes of inactivity or 24 hours. We use local storage, not analytics cookies. Messages, company URLs, search text, full referrers and IP addresses are not sent. There are no person profiles or session recordings. You can decline or withdraw in Analytics settings; Do Not Track and Global Privacy Control keep analytics off.

Read the Plays Privacy Notice ↗