Account Health Score Routing Prompt

This prompt is for customer success engineers and platform builders who need to route accounts based on health signals such as product adoption, NPS, support volume, and usage trends. It produces a structured health tier with contributing factors and a recommended routing action. Use this prompt when your routing middleware must make decisions that depend on multi-signal health assessment rather than a single attribute like contract tier or support entitlement. The prompt is designed to be called before queue dispatch, escalation workflows, or proactive outreach campaigns. It expects pre-fetched account health data as input and does not perform live data retrieval.

Do not use this prompt when routing can be determined by a single deterministic field such as support_tier or contract_type. It is also inappropriate for real-time ticket triage where health signals are unavailable or for accounts with fewer than 30 days of activity history, as trend-based signals will be unreliable. The prompt assumes the caller has already resolved account identity and merged duplicate records. If your system cannot provide at least three of the five core health signals (adoption score, NPS, support volume, usage trend, and renewal date), use a simpler tier-based routing prompt instead.

Before deploying this prompt, validate that your upstream data pipeline can supply consistent, timestamped health indicators. Stale data—such as an NPS score from 18 months ago or usage data that stopped updating after a migration—will produce misleading health tiers. Implement a freshness check in your harness that rejects inputs where any critical signal exceeds your defined staleness threshold. Start with a narrow rollout to accounts with complete data, then expand to partial-data accounts once you have calibrated fallback behavior.

This prompt template is designed to be wired directly into your customer success routing middleware. It accepts a structured set of health indicators—adoption metrics, NPS scores, support ticket volume, and usage trends—and returns a deterministic health tier with contributing factors. The output is schema-constrained so that downstream dispatch logic can route the account to the correct queue, playbook, or human team without additional parsing.

textCopy
You are an account health scoring engine for a B2B SaaS platform. Your job is to analyze the provided account health signals and produce a structured health tier classification with contributing factors and a recommended routing action.

## INPUT
Account ID: [ACCOUNT_ID]
Account Name: [ACCOUNT_NAME]
Current Tier: [CURRENT_TIER]
Contract Renewal Date: [RENEWAL_DATE]

### Health Signals
- Product Adoption Score (0-100): [ADOPTION_SCORE]
- Adoption Trend (last 90 days): [ADOPTION_TREND]
- NPS Score (-100 to 100): [NPS_SCORE]
- NPS Response Rate (%): [NPS_RESPONSE_RATE]
- Open Support Tickets (last 30 days): [OPEN_TICKETS_30D]
- Ticket Trend vs Prior Period: [TICKET_TREND]
- Average Ticket Severity (1-4): [AVG_TICKET_SEVERITY]
- Active Users (last 30 days): [ACTIVE_USERS_30D]
- User Trend vs Prior Period: [USER_TREND]
- Feature Utilization Rate (%): [FEATURE_UTILIZATION]
- Time Since Last Login (days): [DAYS_SINCE_LAST_LOGIN]
- Health Survey Score (if available): [HEALTH_SURVEY_SCORE]
- Recent CSM Notes Summary: [CSM_NOTES_SUMMARY]

## CLASSIFICATION RULES
1. HEALTHY: Adoption >= 70, NPS >= 30, tickets stable or declining, users stable or growing, no concerning CSM notes.
2. AT-RISK: Adoption 40-69 OR NPS 0-29 OR ticket volume increasing >20% OR user count declining >10% OR concerning CSM notes present.
3. CRITICAL: Adoption < 40 OR NPS < 0 OR ticket severity averaging >= 3.5 OR days since last login > 60 OR multiple at-risk signals compounding.
4. INSUFFICIENT DATA: Fewer than 3 health signals available or data older than 90 days.

## CONFLICT RESOLUTION
When signals conflict (e.g., high adoption but low NPS), weigh recent trends more heavily than point-in-time scores. Flag the conflict explicitly in contributing factors. If NPS response rate is below 10%, treat NPS as low-confidence and do not let it alone drive a CRITICAL classification.

## CONSTRAINTS
- Do not invent missing data. Mark unavailable fields as "NOT_AVAILABLE".
- If contract renewal is within 60 days, increase risk sensitivity by one sub-tier.
- If CSM notes indicate an active success plan or executive engagement, note this as a mitigating factor.
- Do not recommend specific account manager names unless provided in CSM notes.

## OUTPUT SCHEMA
Return ONLY valid JSON matching this schema:
{
  "account_id": "string",
  "health_tier": "HEALTHY | AT-RISK | CRITICAL | INSUFFICIENT_DATA",
  "confidence": 0.0-1.0,
  "contributing_factors": [
    {
      "signal": "string (name of the health signal)",
      "value": "string (observed value)",
      "impact": "POSITIVE | NEGATIVE | NEUTRAL",
      "weight": "HIGH | MEDIUM | LOW"
    }
  ],
  "conflicts_detected": [
    {
      "signals": ["signal_a", "signal_b"],
      "description": "string explaining the contradiction",
      "resolution": "string explaining how the conflict was resolved"
    }
  ],
  "mitigating_factors": ["string"],
  "recommended_routing": {
    "queue": "STANDARD | PRIORITY | ESCALATION | CSM_OUTREACH | DATA_COLLECTION",
    "urgency": "ROUTINE | ELEVATED | HIGH",
    "suggested_playbook": "string (name of recommended playbook or action)",
    "human_review_required": true/false
  },
  "stale_data_warning": true/false,
  "rationale_summary": "string (2-3 sentence summary for downstream teams)"
}

Before deploying this prompt, replace each square-bracket placeholder with live data from your account data warehouse, CRM, support platform, and product analytics. The prompt expects numeric scores, trend descriptors, and a CSM notes summary—ensure your data pipeline normalizes these fields before injection. If any field is genuinely unavailable, pass "NOT_AVAILABLE" rather than omitting the placeholder, so the model can apply the INSUFFICIENT_DATA classification rules correctly. Test with accounts that have conflicting signals (high adoption but rising tickets) to verify the conflict resolution logic produces sensible routing decisions before you put this into production.

The Account Health Score Routing Prompt is designed to sit inside a customer success or support middleware layer, not as a standalone chatbot. The application should call this prompt when an account event triggers a health re-evaluation—such as a support ticket creation, a usage drop alert, or a scheduled weekly scan. The prompt expects a structured [ACCOUNT_DATA] payload containing health signals like adoption metrics, NPS scores, support volume, and usage trends. Before invoking the model, the application must assemble this payload from source systems (CRM, product analytics, ticketing platform) and validate that required fields are present and non-null. Missing or stale data should be flagged before the prompt runs, not discovered in the output.

Wire the prompt into a function that accepts an account ID, fetches the latest health signals, and constructs the [ACCOUNT_DATA] object. The function should enforce a schema check: required fields include account_id, signals (an array of health indicators with metric, value, trend, and last_updated timestamps), and previous_health_tier if available. After invoking the model, parse the JSON output and validate it against the expected [OUTPUT_SCHEMA]: a health_tier enum (healthy, at_risk, critical, churned), a confidence_score (0.0–1.0), an array of contributing_factors with factor and impact fields, and a recommended_routing object with queue, priority, and escalation boolean. If the output fails schema validation, retry once with the validation error injected into the [CONSTRAINTS] field. If it fails twice, log the failure and route the account to a manual review queue with the raw signals attached.

For high-risk routing decisions—specifically when the model returns critical or churned tiers—the implementation should require human approval before the routing action executes. Post the health assessment to a review dashboard where a customer success manager can confirm or override the tier and routing recommendation. Log every model invocation with the input signals, output tier, confidence score, and final routing decision for auditability. Use a model with strong JSON mode support (such as GPT-4o or Claude 3.5 Sonnet) and set temperature=0 to minimize variance in tier assignment. Avoid using this prompt for real-time, latency-sensitive routing where a sub-200ms response is required; the model call plus validation adds 500–1500ms, which is acceptable for async health scoring but not for inline ticket triage. If the account has contradictory signals—such as high NPS but declining usage—the prompt will flag this in contributing_factors, and the implementation should surface these contradictions in the review UI rather than silently accepting the tier label.