Support Ticket Unresolved Item Audit Prompt

This prompt is designed for support operations and quality assurance (QA) teams who need to systematically audit closed support tickets. Its core job is to analyze a full ticket transcript and identify any customer questions, explicit requests, or agent commitments that were left unaddressed before the ticket was closed. The primary user is a QA analyst, team lead, or operations manager responsible for ensuring service quality, preventing customer churn from ignored issues, and gathering data for agent coaching. The required context is a complete, unredacted ticket transcript including all public replies, internal notes, and system events, along with the official closure reason.

Use this prompt when you have a high volume of closed tickets and need a structured, repeatable audit process that scales beyond manual review. It is appropriate for tickets of medium-to-high complexity where multiple issues may be interleaved, and where a premature or incomplete resolution is a significant business risk. The prompt is designed to be wired into a batch processing pipeline where its output—a structured JSON audit report—can be ingested by a dashboard, a QA scoring system, or a re-open queue. It is not a replacement for a real-time agent assist tool; it is a post-hoc analysis instrument.

Do not use this prompt for real-time conversation guidance, for tickets still in progress, or for legal/compliance discovery where a human attorney's review is mandatory. It is not designed to judge agent politeness, tone, or adherence to scripts unless those factors directly caused an item to be dropped. The prompt's value is in its strict focus on factual resolution status: was a question asked, and was an answer provided? If your workflow requires sentiment analysis, script adherence scoring, or fraud detection, those should be separate evaluation steps. After running this audit, the next step is to route high-severity unresolved items to a human reviewer for final disposition and, if necessary, ticket re-opening.

This prompt template is the core of the unresolved item audit workflow. It is designed to be copied directly into your AI harness, with placeholders that you replace with real ticket data, severity definitions, and output constraints before execution. The template assumes you have already extracted the full conversation transcript and ticket metadata from your support platform. It does not include retrieval steps; those belong in the implementation harness.

textCopy
You are a support quality auditor. Your task is to analyze a closed support ticket transcript and identify every question, request, or commitment that was not fully addressed before the ticket was closed.

## INPUT
Ticket ID: [TICKET_ID]
Closure Reason: [CLOSURE_REASON]
Transcript:
[TRANSCRIPT]

## DEFINITIONS
- **Unresolved Question**: A direct or implied question from the customer that received no answer, a partial answer, or a deflection.
- **Unresolved Request**: A customer request for action, information, or escalation that was acknowledged but not completed.
- **Unresolved Commitment**: A statement by the support agent promising follow-up, investigation, or future action that has no evidence of completion in the transcript.

## SEVERITY CLASSIFICATION
Use these levels for each finding:
- **BLOCKER**: The unresolved item prevents the customer from using the product or service. Ticket should not have been closed.
- **HIGH**: The unresolved item materially impacts the customer's outcome or satisfaction. Re-open recommended.
- **MEDIUM**: The unresolved item is a quality gap but does not change the core resolution. Note for coaching.
- **LOW**: Minor follow-up or clarification that could be handled in a new interaction.

## CONSTRAINTS
- Only flag items where the transcript provides clear evidence the item was raised and not resolved.
- Do not flag rhetorical questions, social niceties, or items the customer explicitly withdrew.
- If the agent provided a partial answer, classify it as unresolved and note what was missing.
- If the customer's question was ambiguous and the agent did not seek clarification, flag it as unresolved with a note about the ambiguity.
- Do not invent items not present in the transcript.

## OUTPUT_SCHEMA
Return a JSON object with this structure:
{
  "ticket_id": "string",
  "audit_timestamp": "ISO 8601",
  "total_unresolved_items": integer,
  "reopen_recommended": boolean,
  "reopen_reason": "string or null",
  "findings": [
    {
      "finding_id": "string",
      "type": "unresolved_question | unresolved_request | unresolved_commitment",
      "severity": "BLOCKER | HIGH | MEDIUM | LOW",
      "customer_turn_reference": "string (turn number or timestamp from transcript)",
      "agent_turn_reference": "string or null (where the item should have been addressed)",
      "description": "string (what was asked or promised)",
      "evidence_excerpt": "string (verbatim quote from transcript)",
      "gap_analysis": "string (why this was not resolved)",
      "recommended_action": "string"
    }
  ]
}

## EXAMPLES
[EXAMPLES]

## RISK_LEVEL
[RISK_LEVEL]

To adapt this template, replace each square-bracket placeholder with real data. [TRANSCRIPT] should contain the full conversation with turn markers or timestamps. [EXAMPLES] should include one or two few-shot examples showing correct severity classification, especially for borderline cases like partial answers. [RISK_LEVEL] should be set to HIGH for regulated industries or customer-facing audit workflows, which triggers additional constraints in the harness such as requiring human review before the audit report is finalized. If your support platform uses custom closure reasons, map them into [CLOSURE_REASON] and consider adding a [CLOSURE_REASON_DEFINITIONS] section if the model needs to interpret them. The output schema is designed for programmatic consumption; do not modify the field names without updating downstream validators.

This prompt is designed as a batch audit step, not a real-time chat interaction. The primary integration point is a post-resolution quality assurance (QA) pipeline that runs after a support ticket is closed. The application should fetch the full ticket transcript, including all agent and customer messages, and inject it into the [TICKET_TRANSCRIPT] placeholder. The model choice should favor strong reasoning and long-context handling; GPT-4o or Claude 3.5 Sonnet are appropriate defaults. Because this is a high-stakes audit that can trigger ticket re-opening, the system must never automatically act on the model's output. The generated audit report must be routed to a human QA reviewer queue for confirmation before any ticket status change occurs.

The implementation should wrap the LLM call in a validation layer that enforces the expected output schema. Parse the JSON response and verify that every identified unresolved item includes a turn_reference (a quote or message index from the transcript) and a severity value from the allowed enum: critical, high, medium, or low. If the model output fails JSON parsing or schema validation, implement a single retry with the validation error message appended to the prompt as a correction hint. If the retry also fails, log the raw output and flag the ticket for manual audit without an AI-generated report. Logging must capture the ticket ID, prompt version, model used, raw response, validation status, and the final reviewer disposition for every audit run. This creates an evidence trail for QA process improvement and model performance monitoring.

Avoid wiring this prompt directly into a customer-facing chatbot or an automated ticket-closure workflow. The model can misclassify rhetorical questions as unresolved or miss implicit requests that a human reviewer would catch. The harness should treat the AI output as a draft audit that accelerates human review, not a replacement for it. For high-volume support operations, consider batching audits during off-peak hours and caching transcripts to avoid repeated fetches. If your ticketing system supports webhooks, trigger the audit pipeline on a ticket.closed event and enqueue the result for QA review within your existing support tooling. The next step after implementing the harness is to build a golden dataset of 50–100 manually audited tickets to measure precision and recall before scaling the pipeline.