Use cases

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

Example · Support email · plan change with a promise from sales

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

From: Leona Fisk <leona.fisk@lumen-studio.example> To: support@taskgrid.example Subject: Switching to annual billing Hi, We're on the Team plan with 14 seats, billed monthly. Your renewal email said we could switch to annual billing. Could you move us to annual from our next invoice, and tell me roughly what we'd save over the year compared with staying monthly? Also, when I spoke to Hector in your sales team in August he said you'd waive the difference for the rest of this billing month if we switched. Can you make sure that's applied? Thanks, Leona Operations Lead, Lumen Studio
  1. Does the request give enough detail to act on without asking a clarifying question?Yes80%
  2. Which route in the routing policy should handle this request?Person99%
  3. How much work does a good answer to the request take?Multi-step91%
  4. Does answering the request need data from this customer's own account?Yes97%
  5. Does the request ask to change, create, cancel or pay for something?Yes98%
  6. Does the request ask for anything on the policy's list for a person?Yes98%
  7. Does a full answer need a calculation, such as a price, a saving or a prorated amount?Yes95%
  8. 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 fits8 questions

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

  1. 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.

  2. 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.

    • No reply needed An auto-reply, a thank-you with nothing asked, or spam.
    • Help centre answer Answered from the published help articles with no need for this customer's records.
    • Account lookup Needs this customer's own records through the account tool, but changes nothing.
    • Account change Asks for a change the assistant may make with its tools, such as the billing period, seats or billing contact.
    • Large model Needs troubleshooting over several steps, an integration or API answer, long writing or reasoning.
    • Person Asks for something the policy sends to a person, such as a refund, a waived charge, an exception or a promise made by staff.
  3. 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.

    • Single fact One lookup or one sentence answers it.
    • A few facts Two or three facts or steps, each answered on its own.
    • Multi-step Four or more steps, or steps where each depends on the one before, or a long piece of writing.
    • Expert work Open-ended analysis or debugging a specialist would do.
  4. 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.

  5. 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.

  6. 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.

  7. 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.

  8. 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.

Ask for an invite