Partner and Reseller Account Routing Prompt

This prompt is for channel platform engineers who need to classify incoming requests from partners, resellers, and distributors before routing them to the correct queue, team, or workflow. It distinguishes partner-submitted requests from end-customer requests, identifies the partner type and tier, and determines the support entitlement that should apply. Use this when your AI system sits at the ingress point of a multi-tier channel model and must make routing decisions that respect partner program rules, contractual obligations, and commercial agreements.

The prompt assumes you have access to account metadata, partner program data, and request context at classification time. You will need to provide the partner's program tier (e.g., Gold, Silver, Registered), partner type (e.g., reseller, distributor, MSP, referral partner), the original request content, and any end-customer account identifiers if the partner is submitting on behalf of a customer. The prompt works best when these fields are resolved before invocation through your account service or CRM integration, not embedded inline in the request text. If your system cannot reliably distinguish a partner-submitted ticket from a direct customer ticket at the metadata level, add a pre-classification step before this prompt.

Do not use this prompt for direct-to-customer routing where no channel partner relationship exists. It is not designed for internal team routing, employee support, or consumer-facing triage. If your channel model includes nested partner hierarchies (e.g., distributor-to-reseller-to-customer chains), pair this prompt with the Parent-Child Account Hierarchy Routing Prompt to resolve inherited entitlements correctly. For high-stakes routing decisions where misclassification could breach a partner agreement or SLA, implement a human review step for low-confidence classifications and log the full classification payload for audit.

This prompt template is designed for channel platform engineers who need to route partner-submitted requests differently from direct customer requests. It classifies the partner type (e.g., distributor, reseller, MSP, referral partner), determines the partner's tier and support entitlement, and identifies whether the request originates from the partner themselves or from an end customer on whose behalf the partner is acting. This distinction is critical in multi-tier channel models where routing a partner's own technical issue to an end-customer queue creates a broken experience, and routing an end-customer issue through a partner escalation path without proper context delays resolution.

textCopy
You are a channel routing classifier for a SaaS platform. Your job is to analyze an incoming support request and determine the correct routing path based on partner and account attributes.

INPUT:
- Request Content: [REQUEST_CONTENT]
- Submitting Account ID: [ACCOUNT_ID]
- Account Type: [ACCOUNT_TYPE]
- Partner Program Tier: [PARTNER_TIER]
- Contracted Support Entitlement: [SUPPORT_ENTITLEMENT]
- Request Origin Channel: [ORIGIN_CHANNEL]
- End Customer Indicator: [END_CUSTOMER_FLAG]
- Partner Specialization Tags: [SPECIALIZATION_TAGS]

CLASSIFICATION TASK:
1. Determine whether the request is submitted by a partner for themselves (Partner-Direct) or on behalf of an end customer (Partner-Delegated).
2. Classify the partner type from: Distributor, Reseller, MSP, Referral, SI, ISV, or Unknown.
3. Extract the effective support tier from the partner's program tier and contracted entitlement. If the partner has a custom or bespoke entitlement, flag it.
4. Identify the request category from: Technical Support, Billing, Licensing, Pre-Sales, RMA, Training, or Other.
5. Assign a priority level: Critical, High, Normal, or Low based on the partner tier and request content.
6. Determine the routing target: Partner Support Queue, End Customer Queue, Escalation Engineering, Partner Success Manager, Sales Engineer, or Manual Review.

OUTPUT_SCHEMA:
{
  "classification": {
    "request_origin": "Partner-Direct | Partner-Delegated | Unclear",
    "partner_type": "Distributor | Reseller | MSP | Referral | SI | ISV | Unknown",
    "effective_tier": "Tier-1 | Tier-2 | Tier-3 | Custom",
    "custom_entitlement_flag": true | false,
    "request_category": "Technical Support | Billing | Licensing | Pre-Sales | RMA | Training | Other",
    "priority": "Critical | High | Normal | Low",
    "routing_target": "Partner Support Queue | End Customer Queue | Escalation Engineering | Partner Success Manager | Sales Engineer | Manual Review",
    "confidence": 0.0-1.0
  },
  "routing_instructions": {
    "queue_name": "string",
    "escalation_path": "string or null",
    "sla_timer_start": "immediate | business-hours | next-business-day",
    "special_handling_notes": ["string"]
  },
  "ambiguity_flags": {
    "partner_vs_end_customer_unclear": true | false,
    "tier_conflict": true | false,
    "missing_entitlement_data": true | false,
    "requires_human_review": true | false
  }
}

CONSTRAINTS:
- If the request origin is unclear between Partner-Direct and Partner-Delegated, set ambiguity_flags.partner_vs_end_customer_unclear to true and route to Manual Review.
- If the partner has a custom entitlement that doesn't map cleanly to Tier-1/2/3, set effective_tier to "Custom", custom_entitlement_flag to true, and include the custom terms in special_handling_notes.
- Never route a Partner-Delegated request to the Partner Support Queue unless the partner is explicitly requesting help with the delegation process itself.
- If the partner tier is missing or unrecognized, default to the lowest supported tier and flag for review.
- For Critical priority requests from Tier-2 or higher partners, include an escalation path to Escalation Engineering.
- Return only valid JSON. No additional commentary.

To adapt this prompt, replace each square-bracket placeholder with data from your account and ticketing systems. The [REQUEST_CONTENT] field should contain the raw ticket body or initial message. [PARTNER_TIER] and [SUPPORT_ENTITLEMENT] should come from your partner relationship management system or contract database. The [END_CUSTOMER_FLAG] is a boolean that your application layer should set based on whether the submitting account has an associated end-customer record. If your system doesn't track this explicitly, remove the field and rely on the model to infer it from the request content, but expect higher ambiguity rates. Before deploying, run this prompt against a golden dataset of at least 50 labeled partner requests covering all partner types, tiers, and both origin modes. Measure precision and recall on the request_origin and routing_target fields specifically, as these are the most common failure points in channel routing systems.

The partner and reseller account routing prompt is designed to sit inside a classification middleware layer—typically a serverless function, an API gateway plugin, or a message queue consumer—that inspects incoming requests before they reach downstream support queues, ticketing systems, or agent dispatch logic. The prompt expects structured input containing the requesting account's metadata, any declared partner relationship, and the raw request content. The application layer is responsible for assembling this context from your CRM, partner portal, or identity provider before calling the model. Do not pass raw, unenriched user input directly to the prompt; the model needs the account's partner type, tier, and entitlement fields to make a reliable routing decision.

Validation and output enforcement should happen in the application layer, not inside the prompt. After the model returns its classification, validate that the output contains the required fields: partner_type (must match your internal taxonomy), routing_path (must map to an actual queue or workflow ID in your system), confidence_score (a float between 0.0 and 1.0), and escalation_required (boolean). If any field is missing, out of range, or contains an unrecognized enum value, reject the output and retry with a stricter schema instruction appended to the prompt. Implement a retry budget of 2 attempts before falling back to a default routing rule—typically routing to a manual review queue with a flag indicating classification failure. Log every classification attempt, including the raw model output, validation errors, and fallback decisions, so you can debug taxonomy drift or model behavior changes over time.

Human review gates are essential for this workflow because misrouting a partner-submitted request as a standard customer ticket can violate SLAs, damage channel relationships, or expose internal pricing to resellers. Any classification where confidence_score falls below your threshold (start with 0.85 and tune based on production data) should route to a human triage queue with the model's best guess and the original input attached. Similarly, any request where the model detects a partner vs. end-customer ambiguity—for example, a reseller employee submitting a ticket about their own account rather than a customer's—must be flagged for human review. The prompt includes an ambiguity_flag field for this purpose; your harness should treat any true value as a mandatory escalation regardless of confidence score. For regulated industries, consider requiring human approval on all partner routing decisions during an initial shadow-mode deployment before enabling automated dispatch.

Model choice and latency considerations matter here because routing prompts sit on the critical path of request intake. Use a fast, cost-efficient model for this classification task—GPT-4o-mini, Claude Haiku, or an equivalent small model is usually sufficient for structured classification with a well-defined taxonomy. Reserve larger models for the downstream workflows that actually handle the routed request. If your partner taxonomy is stable and your account metadata is clean, consider caching classification results per account for a configurable TTL (e.g., 24 hours) to avoid redundant model calls for repeat requests from the same partner. Invalidate the cache immediately when account tier, partner status, or contract entitlements change. For high-throughput systems, implement a circuit breaker that falls back to static routing rules if the model endpoint returns errors or exceeds latency targets for more than a configurable percentage of requests in a rolling window.

Observability and debugging require structured logging at every decision point. Log the input context hash (not raw PII), the model's raw classification, validation results, retry count, final routing decision, and whether human review was triggered. Emit metrics for classification confidence distribution, retry rate, fallback rate, and human escalation rate so you can detect drift—if confidence scores trend downward or escalation rates spike, your partner taxonomy may need updating or the model may be encountering new partner types it wasn't calibrated for. Wire these metrics into your existing monitoring dashboards alongside queue depth and SLA adherence metrics so you can correlate routing quality with downstream operational outcomes. When debugging misroutes, always compare the model's classification against the ground-truth partner data in your CRM to identify whether the error came from stale context, ambiguous input, or model confusion between similar partner tiers.