Send each request to the cheapest model or tool that fits
Reads a customer email or ticket and picks a route from your list: help articles, a tool, a larger model or a person. Best where replies are not streamed.
Try it on this example
Earlier messages in the thread, if any: [TaskGrid, 2 Sep] Your Team plan renews on 1 October. Did you know you can switch to annual billing at any time? Annual plans are billed once a year at a lower price per seat. Reply to this email or go to Settings > Billing to switch.
Customer email or message
- Does the request give enough detail to act on without asking a clarifying question?Yes80%
- Which route in the routing policy should handle this request?Person99%
- How much work does a good answer to the request take?Multi-step91%
- Does answering the request need data from this customer's own account?Yes97%
- Does the request ask to change, create, cancel or pay for something?Yes98%
- Does the request ask for anything on the policy's list for a person?Yes98%
- Does a full answer need a calculation, such as a price, a saving or a prorated amount?Yes95%
- Does the customer say they cannot use the product or are blocked from work right now?No95%
These are real answers stored from one run on this example.
The prism behind it
Send each request to the cheapest model or tool that fits
Fields
- Customer email or message
- Earlier messages in the thread, if any
Context
Routing policy for the support assistant of a project management software company. Customer emails and in-app messages are routed before any model drafts a reply. Replies are not streamed, so routing runs first. Routes: - Help centre answer: a question the published help articles answer, such as how a feature works, what a plan includes, or published list prices. Handled by the small model with the help articles. - Account lookup: needs this customer's own records, such as invoices, seats, plan, usage or past tickets, read through the account tool with no change. - Account change: asks to change the account through a tool the assistant may use: change the plan or billing period, add or remove seats, update the billing contact, or cancel. - Large model: troubleshooting over several steps, an integration or API problem, a long piece of writing, or a comparison that needs reasoning. - Person: anything on the list for a person below. - No reply needed: an auto-reply, a thank-you with nothing asked, or spam. For a person: - A refund, credit, discount or waived charge. - An exception to the terms. - Anything a salesperson or other staff member is said to have promised. - A security incident or a suspected account takeover. - A request for personal data or for its deletion. - A legal threat or a complaint. Prices, savings, prorating and other calculations are done by the billing tool, never by a model.
Questions
Does the request give enough detail to act on without asking a clarifying question? Yes / No
Read the request and any earlier messages in the thread. Yes: It is clear what the customer wants and which account, item or feature it concerns, so the assistant can act or answer. No: The assistant would first have to ask what the customer means, which account or item, or what went wrong.
Which route in the routing policy should handle this request? Choice
Read the request, any earlier messages and the routes in the context. If the request asks for several things, choose the route for the part that needs the most; that is, of the options that fit any part, choose the one lowest in the list.
How much work does a good answer to the request take? Scale
Read the request and any earlier messages. Rate the work a good answer needs, whoever gives it, leaving out any calculation the billing tool will do.
Does answering the request need data from this customer's own account? Yes / No
Read the request and any earlier messages. Yes: A good answer needs this customer's own records, such as their plan, seats, invoices, usage or tickets. No: The published help articles or general knowledge are enough.
Does the request ask to change, create, cancel or pay for something? Yes / No
Read the request and any earlier messages. Yes: The customer asks for something to be changed, created, cancelled, applied, refunded or paid, on their account or elsewhere. No: The customer only asks a question or asks for information.
Does the request ask for anything on the policy's list for a person? Yes / No
Read the request, any earlier messages and the list for a person in the context: a refund, credit, discount or waived charge; an exception to the terms; anything staff are said to have promised; a security incident or suspected takeover; a request for personal data or its deletion; a legal threat or a complaint. Yes: At least one part of the request is on that list. No: No part of the request is on that list.
Does a full answer need a calculation, such as a price, a saving or a prorated amount? Yes / No
Read the request and any earlier messages. Do not do any calculation yourself. Yes: A full answer needs a number worked out, such as a total, a saving, a prorated charge or a difference between two prices. No: No number needs to be worked out. Quoting a published price is No.
Does the customer say they cannot use the product or are blocked from work right now? Yes / No
Read the request and any earlier messages. Yes: The customer says the product is down for them, they cannot log in, or their team is blocked from working now. No: The customer says nothing of the kind. A request that is merely wanted soon is No.
Lens columns
enough_detail, enough_detail_probability, route, route_probability, complexity, complexity_average, needs_account_data, needs_account_data_probability, changes_something, changes_something_probability, reserved_for_person, reserved_for_person_probability, needs_calculation, needs_calculation_probability, blocked_now, blocked_now_probability
Run it on your own text
Add this prism in the app, change any question, and test it on a file of your own.