Template - Support
ScoreCustomer priority
What priority a request should get, combining urgency with account context.
A score decision that ranks requests on a four-level priority scale using both what the customer says and who they are.
The decision
What priority should this customer request get?
Levels, lowest to highest
- 0
Low: No time pressure and no meaningful business impact. - 1
Normal: Standard request. Handle in queue order. - 2
High: Significant impact or a high-value account with a real problem. - 3
Urgent: High-value account blocked, or widespread impact with a deadline.
Evidence checks (asked in the same request)
- High-value account: The request comes from an enterprise or high-value account.
- Blocking issue: The customer is blocked from using the product.
Expected output: A score from 0 to 3, a probability for each level, and a confidence value, plus one probability per evidence check.
Input
The Decisions API reads one input. Combine these fields into it as labeled text so the model sees the facts the decision depends on.
| Field | Type | Required | Description |
|---|---|---|---|
message | string | Yes | The customer's message, verbatim. Include the subject line if there is one. |
account_tier | string | Yes | Plan or segment, e.g. "Enterprise, 1,200 seats". Priority can't be judged from the message alone. |
Worked examples
Enterprise account blocked before a deadline
Enterprise account (1,200 seats, premium support). Their SSO login is failing for the entire company since 9am and they have a board demo tomorrow.
A careful reviewer would say: Urgent. A large account, company-wide impact, and a deadline within a day.
Run this exampleRoadmap question from a free user
Free plan user asking whether dark mode is on the roadmap. Just curious, no rush.
A careful reviewer would say: Low. A product question with no impact or time pressure.
Run this example
Expected answers are human judgments written for this template, not model output.
How it works
Urgency describes the problem. Priority describes what you do about it, and that depends on who is asking. This template expects account context in the input and will not work well without it.
Write the level descriptions to match your service tiers. If enterprise customers get a one-hour response, the top levels should describe the situations where that commitment applies.
Human review and thresholds
Recommended review policy
Queue ordering can be automated. Anything that triggers a page, a named owner, or a customer-facing commitment should be confirmed by a person.
Choosing thresholds
Over-prioritizing wastes senior attention. Under-prioritizing a large account's outage risks the account. If the second cost dominates, act on the probability of the top two levels rather than the rounded score.
- Starting automation threshold
- 80%
- Starting don’t-decide threshold
- 50%
Starting points for the playground, not recommendations. The right values depend on your costs and on how the model’s confidence tracks accuracy on your data. Calibrate them.
Limitations
- Without account data, this collapses into the ticket urgency template.
- Prioritizing by account value is a business choice with fairness implications. Make that choice deliberately, in the rubric, where people can see it.
- The model cannot know about commitments made outside the message, such as a promise from an account executive.
Use it in your code
The template definition is plain JSON: the question, the evidence checks, the input fields, and the starting policy. The SDK call below sends the same question and checks to the Decisions API from your server.
{
"$format": "thethinkloop.template/v1",
"slug": "customer-priority",
"title": "Customer priority",
"decides": "What priority a request should get, combining urgency with account context.",
"question": {
"name": "decision",
"type": "score",
"instructions": "What priority should this customer request get?",
"levels": [
{
"label": "Low",
"description": "No time pressure and no meaningful business impact."
},
{
"label": "Normal",
"description": "Standard request. Handle in queue order."
},
{
"label": "High",
"description": "Significant impact or a high-value account with a real problem."
},
{
"label": "Urgent",
"description": "High-value account blocked, or widespread impact with a deadline."
}
]
},
"evidenceChecks": [
{
"name": "factor_1",
"label": "High-value account",
"type": "predicate",
"instructions": "The request comes from an enterprise or high-value account."
},
{
"name": "factor_2",
"label": "Blocking issue",
"type": "predicate",
"instructions": "The customer is blocked from using the product."
}
],
"inputs": [
{
"name": "message",
"type": "string",
"required": true,
"description": "The customer's message, verbatim. Include the subject line if there is one."
},
{
"name": "account_tier",
"type": "string",
"required": true,
"description": "Plan or segment, e.g. \"Enterprise, 1,200 seats\". Priority can't be judged from the message alone."
}
],
"expectedOutput": "A score from 0 to 3, a probability for each level, and a confidence value, plus one probability per evidence check.",
"examples": [
{
"title": "Enterprise account blocked before a deadline",
"input": "Enterprise account (1,200 seats, premium support). Their SSO login is failing for the entire company since 9am and they have a board demo tomorrow.",
"expected": "Urgent"
},
{
"title": "Roadmap question from a free user",
"input": "Free plan user asking whether dark mode is on the roadmap. Just curious, no rush.",
"expected": "Low"
}
],
"startingPolicy": {
"automateAt": 0.8,
"abstainBelow": 0.5,
"note": "A starting point for exploration, not a recommendation. Calibrate against your own labeled examples."
}
}import OpenAI from "openai"; // openai >= 7.30.0
const client = new OpenAI(); // reads OPENAI_API_KEY on the server
const decision = await client.decisions.create({
model: "gpt-6-luna",
input: "Enterprise account (1,200 seats, premium support). Their SSO login is failing for the entire company since 9am and they have a board demo tomorrow.",
questions: [
{
type: "score",
name: "decision",
instructions: "What priority should this customer request get?",
levels: [
{
label: "Low",
description: "No time pressure and no meaningful business impact."
},
{
label: "Normal",
description: "Standard request. Handle in queue order."
},
{
label: "High",
description: "Significant impact or a high-value account with a real problem."
},
{
label: "Urgent",
description: "High-value account blocked, or widespread impact with a deadline."
}
]
},
{
type: "predicate",
name: "factor_1",
instructions: "The request comes from an enterprise or high-value account."
},
{
type: "predicate",
name: "factor_2",
instructions: "The customer is blocked from using the product."
}
],
});
// Answers come back in question order. A question can also be refused.
const [main, ...checks] = decision.answers;
if (main.type === "refusal") throw new Error("The model declined to answer.");
if (main.type === "score") {
console.log(main.score, main.confidence, main.probabilities);
}
Download it as customer-priority.json, or browse all developer resources.
Need this decision tuned to your policy?
Related
- Score template
Ticket urgency
How urgently a support ticket needs a response, on a four-level rubric.
- Score template
SLA breach risk
How likely a ticket is to breach its response-time commitment.
- Score template
Account health
How healthy a customer account is, from written account notes.
- Guide
Predicate vs choice vs score
Most decisions can be phrased three ways, and each returns different information. Which type fits which decision, with worked examples and common mistakes.
- Guide
AI decision routing
A routing decision is several smaller decisions plus a rule that combines them. How to design that rule, where people fit, and what to log.
- Guide
Human-in-the-loop AI
When should AI decide and when should it ask? Review patterns, what reviewers need to see, sizing the queue, and keeping oversight real.