Chat Conversation to CRM Record Prompt Template

This prompt is designed for CRM integration engineers who need to convert unstructured chat transcripts into structured CRM payloads. The primary job-to-be-done is extracting customer details, intent, sentiment, and action items from a conversation and mapping them to standard CRM objects like Contacts, Opportunities, and Activities. The ideal user is a backend engineer or platform developer building an automated pipeline that ingests chat logs from Intercom, Zendesk, or a custom chat widget and pushes normalized records into Salesforce, HubSpot, or a similar system of record.

Use this prompt when you have a complete, self-contained chat transcript and a known target CRM schema. The prompt expects [CONVERSATION_TRANSCRIPT] as raw text, [CRM_SCHEMA] defining the target fields and their types, and [COMPANY_CONTEXT] providing account-specific defaults like the CRM owner ID or standard picklist values. It is most effective when the transcript includes clear participant roles, timestamps, and a coherent thread. The prompt includes instructions for entity resolution against existing records and duplicate detection, making it suitable for pipelines that must avoid creating redundant contacts or opportunities.

Do not use this prompt for real-time, streaming chat where the conversation is incomplete, or for transcripts that mix multiple unrelated customer threads. It is also not a replacement for a proper CRM API integration—the output is a structured payload that still requires validation, deduplication logic, and an upsert strategy in your application layer. If the transcript contains sensitive PII that should not be processed by a third-party model, handle redaction before the prompt or use a local deployment. For high-volume production use, pair this prompt with a confidence threshold eval and a human review queue for records flagged as ambiguous or low-confidence.

This template is the core instruction set for extracting structured CRM data from a raw chat conversation. It is designed to be dropped into your application's prompt layer, with placeholders that your system must populate at runtime. The prompt instructs the model to parse the transcript, identify entities, and output a clean JSON payload that matches a target CRM schema. It also includes explicit instructions for handling ambiguity, detecting duplicates, and flagging low-confidence extractions, which are critical for maintaining CRM data integrity.

textCopy
You are an expert CRM data extraction system. Your task is to analyze the provided chat transcript and produce a structured JSON payload for CRM ingestion.

### INPUT
Chat Transcript:
[CHAT_TRANSCRIPT]

### OUTPUT SCHEMA
You must output a single, valid JSON object conforming to this structure. Do not include any text outside the JSON object.
{
  "contact": {
    "full_name": "string | null",
    "email_address": "string | null (must be a valid email format)",
    "phone_number": "string | null (E.164 format preferred)",
    "company_name": "string | null"
  },
  "opportunity": {
    "name": "string | null",
    "stage": "string | null (one of: 'Prospecting', 'Qualification', 'Proposal', 'Closed Won', 'Closed Lost')",
    "amount": "number | null",
    "close_date": "string | null (ISO 8601 date YYYY-MM-DD)"
  },
  "activity": {
    "type": "string | null (one of: 'Call', 'Email', 'Meeting', 'Chat')",
    "subject": "string | null",
    "notes": "string | null (a concise summary of the conversation)"
  },
  "intent": {
    "primary_intent": "string | null (e.g., 'Support', 'Sales Inquiry', 'Complaint', 'General Question')",
    "sentiment": "string | null (one of: 'Positive', 'Neutral', 'Negative')"
  },
  "action_items": [
    {
      "description": "string",
      "assignee": "string | null",
      "due_date": "string | null (ISO 8601 date YYYY-MM-DD)"
    }
  ],
  "flags": [
    "string (e.g., 'DUPLICATE_DETECTED', 'LOW_CONFIDENCE_CONTACT', 'ESCALATION_REQUIRED')"
  ]
}

### CONSTRAINTS
- Extract only information explicitly stated or strongly implied in the transcript. Do not invent details.
- If a field's value is not present, return `null` for that field.
- For the `opportunity.stage`, infer the most logical stage based on the conversation. If unclear, return `null`.
- If you detect that the contact's email or phone matches an existing record, add the `DUPLICATE_DETECTED` flag.
- If you are unsure about the accuracy of a key extraction (like a name or company), add the `LOW_CONFIDENCE_CONTACT` flag.
- If the customer expresses significant frustration or a legal threat, add the `ESCALATION_REQUIRED` flag.
- Ensure all dates are in ISO 8601 YYYY-MM-DD format.

### EXAMPLES
Input Transcript:
"Hi, this is Sarah from Acme Corp. I need a quote for 50 licenses."
Output:
{
  "contact": { "full_name": "Sarah", "company_name": "Acme Corp", ... },
  "opportunity": { "stage": "Prospecting", ... },
  ...
}

To adapt this template, replace the [CHAT_TRANSCRIPT] placeholder with the actual conversation text. You can tighten the OUTPUT_SCHEMA to match your specific CRM's API contract exactly, adding or removing fields as needed. The CONSTRAINTS section is your primary lever for controlling data quality; add rules specific to your business logic, such as validating against a list of known competitors or enforcing specific deal stages. The EXAMPLES section should be populated with 2-3 representative transcripts and their ideal outputs to significantly improve accuracy through few-shot learning. Before deploying, run this prompt against a golden dataset of 50 transcripts and measure field-level accuracy, especially for the flags array, as incorrect flags can create significant downstream noise for your sales team.

This prompt is designed to sit inside a post-generation repair loop, not as a standalone call. The typical integration pattern is: (1) receive a chat transcript, (2) attempt structured extraction with a primary prompt, (3) validate the output against the CRM schema, and (4) if validation fails or the model returns prose instead of JSON, invoke this repair prompt with the failed output and the original transcript. The repair prompt expects both [ORIGINAL_TRANSCRIPT] and [FAILED_OUTPUT] as inputs, along with the [CRM_SCHEMA] defining required fields, types, and enum values for contact, opportunity, and activity records.

Wire the prompt into a retry pipeline with a maximum of two repair attempts before escalating to a human review queue. After each repair attempt, validate the output against the CRM schema using a deterministic validator—check for required field presence, correct types, valid enum values, and duplicate detection flags. Log every repair attempt with the original transcript ID, the failed output, the repair prompt version, and the validation result. For high-confidence duplicate detection (confidence > 0.85), route to a merge-review queue rather than auto-creating records. Use a model with strong JSON mode support (e.g., GPT-4o, Claude 3.5 Sonnet) and set response_format to json_object to reduce format drift. If the model still returns prose after two repair attempts, log the failure and surface the transcript to a human operator with the partial extraction results pre-filled.

The most common production failure mode is entity resolution—the model creates a new contact when an existing one matches. Mitigate this by passing a [KNOWN_CONTACTS] list into the prompt context and requiring the model to output a duplicate_of field with a confidence score. For CRM systems with strict write permissions, implement a two-stage pipeline: first extract and resolve entities, then generate the CRM payload only after entity resolution is confirmed. Never auto-commit records with confidence < 0.7 or duplicate_of scores in the ambiguous range (0.4–0.6). These should always route to human review with the evidence highlighted.