Human Handoff Summary Prompt for Escalation Queues

This prompt is designed for support and operations teams routing escalated AI interactions to human reviewers. It takes raw conversation transcripts, system notes, and escalation triggers as input and produces a structured handoff summary that a human agent can read in under 30 seconds. Use this prompt when the cost of context-switching for human reviewers is high, when escalation reasons must be auditable, and when handoff consistency across shifts or teams matters. This prompt belongs inside an escalation workflow, not as a standalone chatbot. It assumes that an upstream process has already determined that escalation is required and has captured the relevant conversation context.

Do not use this prompt for real-time triage decisions, for generating customer-facing messages, or as a replacement for a CRM ticket body. The summary is an internal artifact for human reviewers. It works best when the upstream system provides a complete conversation transcript, a clear escalation reason code, and any tool-call or system-action logs. If the transcript is truncated, the escalation reason is missing, or the user's identity and account context are absent, the summary will be incomplete and may mislead the reviewer. In high-risk domains such as healthcare, finance, or legal, always include source evidence and require human verification of the summary before any downstream action.

Before deploying this prompt, confirm that your escalation pipeline captures the required inputs: the full conversation transcript, the escalation trigger, any attempted automated resolutions, and relevant user or account metadata. Wire the prompt into a step that fires only after escalation is confirmed, and validate the output against a schema that enforces required fields like urgency classification and attempted resolutions. Start with a small set of escalation types and expand as you tune the summary format to your team's review workflow.

The following prompt template is designed to be placed in your system instructions or invoked as part of an escalation handler. Its job is to compress the entire conversation history into a structured summary that a human agent can read in under 30 seconds and immediately act on. The template uses square-bracket placeholders that your application must populate with live data before sending the request to the model. Do not leave any placeholder unresolved in production; missing context will cause the model to hallucinate details or omit critical escalation signals.

textCopy
You are an escalation summarizer. Your output will be read by a human support agent who has no prior context about this conversation. Produce a structured handoff summary using the exact schema below.

## Conversation Context
[CONVERSATION_HISTORY]

## User Account Context
[USER_ACCOUNT_CONTEXT]

## Escalation Trigger
[ESCALATION_TRIGGER_REASON]

## Output Schema
Return a JSON object with these fields:
- "summary": A 2-3 sentence plain-language summary of what the user needs and what has happened so far.
- "escalation_reason": The specific reason this conversation was escalated, selected from [ESCALATION_REASON_CODES].
- "attempted_resolutions": An array of actions the AI already attempted, in chronological order. Each entry must include "action", "result", and "user_response" fields.
- "urgency": One of [URGENCY_LEVELS].
- "user_sentiment": A brief assessment of the user's emotional state based on the conversation.
- "open_questions": An array of questions the human agent should resolve.
- "required_actions": An array of concrete next steps the human agent should take.
- "context_links": An array of relevant internal references (ticket IDs, order numbers, knowledge base articles) extracted from the conversation.

## Constraints
- Do not invent details not present in [CONVERSATION_HISTORY] or [USER_ACCOUNT_CONTEXT].
- If the conversation contains PII, preserve it only in the "context_links" field and redact it from the "summary".
- If the escalation reason is unclear, set "escalation_reason" to "UNSPECIFIED" and flag this in "open_questions".
- Keep the total output under 500 words.
- Do not include conversational filler, apologies, or greetings in the JSON output.

To adapt this template for your own system, replace each placeholder with data from your application context. [CONVERSATION_HISTORY] should contain the full transcript of the user-AI interaction leading up to escalation. [USER_ACCOUNT_CONTEXT] should include relevant account metadata such as plan tier, recent orders, or prior ticket history. [ESCALATION_TRIGGER_REASON] is the machine-readable reason the escalation path was activated, such as CONFIDENCE_BELOW_THRESHOLD or TOOL_FAILURE_EXHAUSTED_RETRIES. [ESCALATION_REASON_CODES] and [URGENCY_LEVELS] should be replaced with your organization's actual enum values so the output matches downstream routing logic. If your escalation handler already classifies urgency before invoking this prompt, you can remove the urgency field from the schema and inject the pre-computed value directly into the handoff payload.

Before deploying this prompt, validate its output against a golden dataset of known escalation scenarios. Test for summary completeness by checking that every open_question maps to an unresolved thread in the conversation history. Test for hallucination by ensuring no context_links reference IDs that do not appear in the input. For high-risk domains such as healthcare or finance, route every handoff summary through a brief human review step before it reaches the queue, and log the raw model output alongside the final reviewed version for audit purposes.

This prompt is designed to be the final step in an AI-driven support or operations workflow before a human agent takes over. It should be triggered by an upstream classifier or a confidence-threshold rule that determines the AI can no longer resolve the issue autonomously. The harness must provide the prompt with the full conversation transcript, a list of tools the AI attempted to use and their results, and the specific reason code for the escalation. Without this structured input, the summary will lack the diagnostic detail a human reviewer needs to avoid restarting the investigation from scratch.

Wire the prompt into a serverless function or a dedicated service endpoint that is called by your orchestration layer. The function should assemble the [CONVERSATION_HISTORY], [ATTEMPTED_RESOLUTIONS], and [ESCALATION_REASON] variables from your session store and tool-execution logs. Before calling the model, validate that the input variables are not empty and that the conversation history contains at least one user turn. After receiving the model's output, parse the JSON and validate it against the expected [OUTPUT_SCHEMA] using a library like jsonschema or pydantic. If validation fails, implement a single retry with a stricter prompt that includes the validation error message. Log the raw prompt, the model's response, and the validation result to your observability platform for debugging and audit trails.

For high-stakes domains like healthcare or finance, do not surface the AI-generated summary directly to the human agent without a review gate. Instead, post the structured summary to an internal queue and require a human triage lead to confirm the urgency classification and context completeness before it enters the active support queue. Use a fast, cost-effective model like Claude 3.5 Haiku or GPT-4o-mini for the initial summary generation, reserving more powerful models for cases where the initial summary fails validation or is flagged by the human reviewer. Avoid wiring this prompt directly to a customer-facing 'transfer' message; the output is an internal operations artifact, and the user-facing handoff message should be a separate, controlled template that simply informs the user they are being transferred.