VIP Customer Identification Prompt

This prompt is designed for support platform engineers who need to flag high-value, strategic, or executive-escalation accounts before a ticket enters the routing engine. The primary job-to-be-done is to produce a deterministic VIP boolean with a tier justification and special-handling instructions, ensuring that your routing middleware respects commercial agreements and prevents high-touch accounts from landing in standard queues. The ideal user is an engineering lead or platform developer embedding this classification step into a pre-routing middleware layer, where the output directly controls queue assignment, agent notification, and SLA enforcement.

Use this prompt when you have access to structured account metadata—such as a customer tier label, a contract segment, or an executive escalation flag—and you need a normalized VIP decision that downstream systems can act on without ambiguity. The prompt expects inputs like [ACCOUNT_TIER], [ESCALATION_FLAGS], and [REQUEST_CONTEXT] to make a binary classification. It is not designed for general priority scoring, sentiment-based urgency detection, or SLA breach prediction; those tasks require separate classification steps that incorporate time-series data, queue depth, and agent availability. Applying this prompt to those problems will produce brittle results because it lacks the temporal and operational context those decisions demand.

Before wiring this into production, ensure you have a clear definition of what constitutes a VIP account in your organization. The prompt's effectiveness depends entirely on the quality and consistency of the [VIP_CRITERIA] you provide. If your account tier data is stale, if executive escalation lists are maintained manually, or if 'strategic' is a subjective label, you will get false positives that degrade queue fairness and erode trust in the routing system. The next section provides the copy-ready template; after that, the implementation harness explains how to add validation, logging, and human review checkpoints to catch these failure modes before they reach production.

This prompt template is designed to be pasted directly into your routing middleware. It accepts live account and ticket data, evaluates it against configurable VIP criteria, and returns a structured boolean decision with tier justification and special-handling instructions. The template uses square-bracket placeholders for all dynamic inputs, ensuring it can be adapted to any CRM, ticketing system, or account data model without leaking implementation details.

codeCopy
SYSTEM:
You are a VIP customer identification router. Your job is to analyze account and ticket data to determine if a customer qualifies for VIP treatment before routing. You must be conservative: only flag as VIP when evidence is clear. False positives degrade queue fairness for genuine high-priority customers.

INPUT DATA:
- Account Tier: [ACCOUNT_TIER]
- Contract SLA: [CONTRACT_SLA]
- Annual Revenue: [ANNUAL_REVENUE]
- Strategic Flag: [STRATEGIC_FLAG]
- Executive Contact: [EXECUTIVE_CONTACT]
- Support History: [SUPPORT_HISTORY_SUMMARY]
- Ticket Subject: [TICKET_SUBJECT]
- Ticket Priority: [TICKET_PRIORITY]
- Requesting User Role: [USER_ROLE]
- Escalation History: [ESCALATION_HISTORY]

VIP CRITERIA:
A customer is VIP if ANY of the following are true:
1. Account tier is "Enterprise" or "Strategic" AND contract SLA is "Platinum" or "Diamond"
2. Annual revenue exceeds [REVENUE_THRESHOLD]
3. Strategic flag is explicitly set to TRUE
4. Executive contact field is populated AND ticket priority is "Critical" or "Urgent"
5. Escalation history shows prior executive or VP-level involvement in last 90 days

[ADDITIONAL_VIP_RULES]

OUTPUT SCHEMA:
{
  "is_vip": boolean,
  "confidence": "high" | "medium" | "low",
  "matched_criteria": ["criterion_1", "criterion_2"],
  "tier_justification": "string explaining why VIP status was assigned or denied",
  "special_handling": {
    "priority_queue": boolean,
    "dedicated_agent_required": boolean,
    "executive_notification": boolean,
    "sla_override_minutes": number | null,
    "handling_instructions": "string with specific routing or response requirements"
  },
  "fallback_tier": "string indicating standard routing tier if not VIP"
}

CONSTRAINTS:
- Do not flag as VIP based on a single weak signal (e.g., ticket priority alone without account context)
- If account data is missing or incomplete, set confidence to "low" and default to standard routing
- For trial or freemium accounts, only flag as VIP if executive contact is present AND ticket is critical
- Do not use customer name, industry, or sentiment as VIP signals unless explicitly listed in criteria
- If multiple criteria are partially met but none fully satisfied, explain ambiguity in tier_justification

USER:
Analyze the provided account and ticket data against the VIP criteria. Return only the JSON output.

To adapt this template, replace each square-bracket placeholder with live data from your CRM, ticketing system, or account database. The [ADDITIONAL_VIP_RULES] placeholder allows you to inject organization-specific criteria, such as partner status, NPS score thresholds, or recent expansion signals. The [REVENUE_THRESHOLD] should be set to a concrete value matching your segmentation model. Ensure that all input fields are populated before invocation; missing fields should be passed as null or empty strings rather than omitted, so the model can correctly assess data completeness and adjust confidence accordingly.

Before deploying, validate this prompt against your golden test set, including edge cases like trial accounts with executive contacts, enterprise accounts with missing SLA data, and recently downgraded accounts still in grace periods. Run eval checks for false-positive VIP flags that would unfairly prioritize non-critical requests over genuine high-priority work. If your routing middleware supports it, log the full prompt and response for audit trails and observability into VIP classification decisions over time.

The VIP identification prompt is not a standalone chatbot; it is a classification component inside a routing middleware pipeline. When a support ticket, email, or API request arrives, the middleware must first resolve the customer's account context—pulling CRM fields, contract metadata, and support history—before calling the model. The prompt receives this resolved context as [CUSTOMER_PROFILE] and returns a structured VIP boolean with tier justification. The middleware then uses this output to branch the request into premium queues, assign named support engineers, or trigger executive escalation workflows. The model's job is narrow: read the evidence and produce a deterministic classification. The application owns the routing action.

Wire the prompt into a classification step with a strict JSON schema validator. The expected output shape is { "is_vip": boolean, "vip_tier": "executive" | "strategic" | "enterprise" | "standard", "confidence": 0.0-1.0, "justification": ["string"], "special_handling": ["string"] }. If the model returns malformed JSON, missing required fields, or an invalid enum value, the harness should retry once with a repair prompt that includes the validation error. If the retry also fails, log the failure and route the request to a manual review queue rather than guessing. For high-throughput systems, consider a lightweight regex pre-check on the account tier field before invoking the model—if the CRM already has a definitive tier: enterprise with a vip_flag: true, you can short-circuit the LLM call entirely and save latency and cost.

Model choice matters here. This is a classification task with high precision requirements, not a creative generation task. A smaller, faster model (e.g., Claude Haiku, GPT-4o-mini, or a fine-tuned open-weight model) is usually sufficient and keeps per-request cost low. However, if your VIP criteria involve nuanced judgment—such as detecting executive escalation tone in free-text notes or weighing contradictory account signals—test whether a larger model reduces false positives. Log every classification decision with the input context, model output, validator result, and final routing action. This audit trail is essential when a VIP customer is misrouted to a standard queue and your team needs to diagnose whether the prompt, the account data, or the routing logic failed.

Avoid over-escalation drift. The most common production failure mode is the prompt becoming too generous with VIP flags over time, degrading queue fairness for non-VIP customers. Implement a false-positive monitor: track the ratio of VIP classifications to total requests and alert if it exceeds historical baselines. Periodically run a golden eval set containing known VIP and non-VIP accounts through the prompt and compare against expected labels. If you add new VIP criteria (e.g., a new strategic partner program), update the eval set before deploying the prompt change. For regulated industries, require a human reviewer to confirm VIP classifications above a configurable confidence threshold before the request bypasses standard queues.