Decision-1 for Support Tickets: Routing Without Generating a Reply
When a ticket fits both billing and technical support, how much confidence is enough to route it automatically?
- Decision-1 selects from defined options and returns probabilities. It does not write a customer reply or explain its reasoning.
- Input costs $0.042 per million tokens; output is free. A million tickets cost $42 in model input charges only if each request uses 1,000 input tokens.
- Use labeled tickets to set an automation threshold, and give uncertain cases a review path instead of forcing every ticket into a team.
Use it to choose the team; keep reply writing separate
If your application needs to send a ticket to billing, technical support or account support, Microsoft-Decision-1 can produce the routing decision directly. You supply the ticket and define the choices. The model selects one and returns probabilities for the options.
That output is useful to software deciding what to do next. It is not a message to the customer, and it does not explain why a team was selected. Your application still moves the ticket into a queue; a generative model can then draft a response if the workflow needs one.
Microsoft introduced Decision-1 on October 9, using a post-trained Qwen3.5-9B foundation and offering access through Microsoft Foundry and OpenRouter. The practical adoption question is whether a step needs a bounded decision or new prose. A support system can need both without using the same model for both jobs.
Team selection, yes-or-no gates and priority scores are different outputs
Choose the question type to match the action your application will take. A department is a category; severity has an order; a repeat-contact check is a yes-or-no condition.
| Support decision | Type | Output |
|---|---|---|
| Which team owns the ticket? | choice | One selected option, plus a probability for every option |
| Has the customer contacted support before? | noul | A probability between 0 and 1 |
| How severe is the incident? | score | A position on an ordered scale, plus probabilities for its levels |
For a four-level severity scale, the score ranges from 0 to 3 and can fall between levels because it is a probability-weighted average of their indexes. A value such as 1.7 is a position on your scale, not an accuracy percentage. Validate how that ordering behaves before using it to prioritize a queue.
The request contains a text or JSON state and typed questions. Related questions can share one request. Define the departments clearly: overlapping labels leave the model to interpret a boundary your team has not agreed on.
A million tickets cost $42 only under a stated token assumption
Microsoft’s listed price, checked October 26, is $0.042 per million input tokens, with free output. The unit is tokens, not tickets. Count the whole input, including the instructions and criteria used to classify the ticket.
These are arithmetic examples, assuming one request per ticket and no retries. They are not measured customer bills.
| Tickets | Assumed input per request | Total input tokens | Model input charge |
|---|---|---|---|
| 100,000 | 1,000 tokens | 100 million | $4.20 |
| 1 million | 1,000 tokens | 1 billion | $42 |
| 1 million | 3,000 tokens | 3 billion | $126 |
Reply generation, application hosting and human review sit outside those figures. Measure token usage on representative requests before budgeting: a short question and a long conversation history are different inputs even though each counts as one ticket.
Set the automation threshold from the cost of a wrong route
The highest-probability option is not automatically a good enough decision. Microsoft’s guidance calls for evaluation on representative data and thresholds based on the costs of false positives and false negatives. It does not prescribe a universal confidence cutoff.
A practical starting point is a set of historical tickets with the correct team attached. Compare predictions against those labels, then decide which cases can proceed automatically. Low-confidence results can go to a person or another model. Including a cannot tell option also gives the model a way to abstain when the supplied information does not support a forced choice.
Test changes to wording and option order, too. A numerical response is still sensitive to how the task is framed. Since Decision-1 supplies no written rationale, reviewers need access to the original ticket and the criteria used to classify it.
Foundry uses a dedicated Decision API endpoint; the request’s model value is your deployment name, not simply the catalog identifier. Start with the routing step and measure accuracy, input usage and review rate before deciding how much of the existing workflow to move.