Support Ticket Multi-Field Record Assembly Prompt Template

This prompt is designed for support platform engineers who need to convert messy, multi-format ticket submissions into a single, clean, structured record. The core job-to-be-done is normalizing heterogeneous inputs—email bodies, chat transcripts, and web form submissions from tools like Zendesk, Intercom, or Salesforce—into a unified JSON object containing product, issue type, severity, and customer details. Use this when your ingestion pipeline must produce consistent, queryable records for downstream routing, analytics, or CRM updates. The prompt excels at cross-field validation and conflict resolution when multiple sources within a single ticket disagree, such as a user selecting 'Low' severity in a form but writing 'URGENT' in the email body.

The ideal user is an integration or platform engineer building a support data pipeline. You should have access to the raw, unprocessed ticket payload, including any metadata like submission channel or timestamp. The prompt requires you to supply an [OUTPUT_SCHEMA] defining your target record structure and [CONSTRAINTS] specifying your normalization rules, such as canonical product names or severity level enums. It is critical to include [EXAMPLES] that demonstrate how to handle conflicting signals—for instance, showing that explicit statements in the message body should override default form values when they conflict. You should also provide a [RISK_LEVEL] directive to control whether the prompt should flag ambiguous cases for human review or attempt a best-effort resolution.

Do not use this prompt for real-time chatbot intent classification or simple single-field extraction tasks. It is over-engineered for pulling out just an email address or a sentiment score; a simpler, cheaper extraction prompt will suffice. Similarly, do not use this when you need to resolve entities across multiple separate tickets—this prompt assembles a record from a single submission, not a cross-document entity resolution task. If your input is a scanned PDF or an image, pre-process it with an OCR or document intelligence prompt first, as this template expects pre-extracted text. For high-stakes fields like priority or financial impact, always route low-confidence outputs to a human review queue rather than trusting automated resolution.

This prompt template is designed to be the core instruction set for your AI model when ingesting messy, multi-source support data. It forces the model to act as a data assembly engine, not a conversational agent. The primary job is to reconcile information from an email body, a chat transcript, and a structured form submission into a single, coherent JSON record. The template uses square-bracket placeholders for all dynamic inputs and configuration, ensuring you can swap in data from your application's middleware without altering the core logic. Before using this, ensure you have already extracted the raw text from each source; this prompt handles the semantic merging, not the initial file parsing.

textCopy
You are a support data normalization engine. Your task is to assemble a single, definitive support ticket record from the provided sources. You must resolve conflicts, infer missing values only when explicitly allowed, and flag any data that is ambiguous or contradictory.

## INPUT DATA
[EMAIL_BODY]
[CHAT_TRANSCRIPT]
[FORM_DATA]

## OUTPUT SCHEMA
You must produce a single JSON object conforming to this exact schema. Do not include any other text.
{
  "ticket": {
    "product": {
      "name": "string | null",
      "version": "string | null"
    },
    "issue": {
      "type": "string | null",
      "severity": "string | null",
      "summary": "string"
    },
    "customer": {
      "id": "string | null",
      "name": "string | null",
      "email": "string | null",
      "plan": "string | null"
    },
    "source_priority": ["email", "chat", "form"]
  },
  "assembly_metadata": {
    "conflicts": [
      {
        "field": "string",
        "values": ["string"],
        "resolved_by": "source_name",
        "rationale": "string"
      }
    ],
    "missing_required": ["string"],
    "inferred_fields": ["string"]
  }
}

## RESOLUTION RULES
1.  **Source Priority:** When sources conflict on a single field, trust the source listed first in the `source_priority` array unless that source's value is null or explicitly marked as uncertain.
2.  **Null Handling:** A field should only be `null` if no source provides a usable value. Do not hallucinate data.
3.  **Inference:** You may infer the `issue.summary` from the most detailed source if it is not explicitly stated. You may NOT infer any customer PII or the `issue.severity`. If you infer a value, list the field name in `inferred_fields`.
4.  **Conflict Logging:** Every time sources provide different non-null values for the same field, you must log it in the `conflicts` array with a clear rationale for the chosen value.
5.  **Validation:** The `missing_required` array must list any field from the schema that is still null after assembly, excluding the `conflicts` and `inferred_fields` metadata.

## CONSTRAINTS
- Do not add any fields not present in the schema.
- If a customer email is found in any source, validate its format. If it's malformed, set it to null and note it in the conflicts.
- The `issue.severity` must be one of: "Critical", "High", "Medium", "Low", or null.

To adapt this template for your environment, start by replacing the placeholders with your actual data strings. The [EMAIL_BODY], [CHAT_TRANSCRIPT], and [FORM_DATA] are the raw text payloads your application extracts before calling the model. The source_priority array inside the schema is a critical configuration lever; adjust the order to match your organization's trust hierarchy. For example, if your intake form is the most reliable source of truth, move "form" to the front of the array. After pasting this prompt into your harness, you must implement a post-processing validation step in your application code to verify the model's JSON output against the schema and to check the assembly_metadata.missing_required list. If that list is not empty, your application should either reject the record and request human review or trigger a follow-up prompt to gather the missing data.

This prompt is designed to be called from a backend service or an integration middleware, not directly from an end-user chat interface. The typical caller is a ticket ingestion pipeline that receives raw text from multiple channels—email bodies, chat transcripts, web form submissions, or API payloads—and needs a unified, structured record before writing to the ticketing system. The application layer is responsible for gathering the raw sources, assembling the [INPUT] block with clear source labels, and injecting any available [CONTEXT] such as the customer's account tier, recent ticket history, or product catalog. The prompt itself should be treated as a stateless transformation: one call per ticket, with all evidence provided inline.

Validation and retry loop. Before the model output reaches your database, run a strict JSON schema validator against the [OUTPUT_SCHEMA] you provided in the prompt. Check that all required fields are present, enums match allowed values, and cross-field consistency rules hold (e.g., if severity is 'critical', priority must be 'urgent' or 'high'). If validation fails, do not silently drop the record. Instead, feed the validation error messages back into a retry prompt that includes the original input, the failed output, and a specific instruction to fix only the flagged fields. Limit retries to two attempts. After two failures, route the ticket to a human review queue with the raw sources, the partial output, and the validation errors attached. Log every validation failure and retry attempt for later prompt debugging.

Model choice and latency budget. This is a structured extraction task with moderate complexity—multiple fields, cross-source conflict resolution, and normalization rules. A capable mid-tier model (e.g., GPT-4o, Claude 3.5 Sonnet, or an equivalent open-weight model fine-tuned for JSON extraction) is appropriate. Set a timeout of 15 seconds for the model call. If latency is critical and the input is short, a smaller model with strong JSON mode may suffice, but test it against your conflict-resolution edge cases before cutting over. For high-volume pipelines, batch requests where the provider supports it, but keep each ticket as an independent request to avoid cross-contamination.

Source grounding and audit trail. The prompt instructs the model to include a source_fields map that traces each output field back to its originating source. Preserve this map in your database alongside the assembled record. When a human reviewer later questions a field value, the source map lets them jump directly to the raw text that produced it. If your ticketing system supports custom fields or metadata, store the full prompt input, the raw model output, the validation result, and the retry count. This audit trail is essential for debugging prompt drift, evaluating extraction quality over time, and defending the automation to compliance or QA teams.

When to escalate instead of assembling. Not every ticket should go through this prompt. If the input is empty, contains only an image with no text, or is flagged by a prior classification step as abusive or out-of-scope, skip assembly and route directly to a triage queue. Similarly, if the model's confidence flags indicate low certainty on critical fields like issue_type or severity, and the retry loop fails to resolve them, escalate rather than risk a misrouted ticket. The assembly prompt is a productivity tool, not a replacement for human judgment on ambiguous or high-stakes submissions.