Refund request detection

Tell whether a customer is actually asking for money back.

Problem

Messages that mention charges are not all refund requests: some ask for an invoice, an explanation or a plan change. Treating every mention of money as a refund request floods the refund queue.

Goal

Start the refund flow only for messages that ask for money back, and route the rest as ordinary billing questions.

Input / state

The customer's message.

message: The customer's message, unedited.

Decision question

NoulQuestion key requests_refund

Does the customer ask for money back, a refund, a reversed charge, or a credit for a payment?

What counts as yes and no

trueThe message asks for some or all of a payment to be returned or credited.
falseThe message mentions a charge or price but asks for something else, such as an invoice, an explanation or a plan change.

Allowed outcomes

Decided in your code from the answer and its confidence. Thresholds are yours to set and test.

Refund requestedProbability of yes is above your upper threshold.
UnclearProbability falls between your thresholds.
No refund requestProbability of yes is below your lower threshold.

Example scenarios

Predefined demonstrations. No model is called; the outcome shown is an illustrative judgment.

Example state

Adapted from System One API reference

{
  "message": "I was charged twice for my subscription this month. Please refund the extra charge."
}

Outcome

Illustrative

Refund requested

Probability of yes is above your upper threshold.

Why

The customer explicitly asks for a charge to be refunded.

Better together with

Complementary classifiers, and what each one adds here.

Refund information checkChoice
Once a refund is requested, check the request has what the policy needs.
Combined inRefund request resolution
Refund policy eligibilityChoice
Detection says a refund is wanted; eligibility says whether the policy allows it.
Combined inRefund request resolution
Support ticket routingChoice
Pull refund requests out of billing tickets and into the refund flow.
Combined inSupport inbox triage

Used in chains

Sources

Primary documentation this classifier builds on. Scenarios on this page are illustrative, not taken from production use.

SourcedTypeSafe docs · Documentation
System One
Defines the Choice, Score and Noul primitives and walks through a refund request built from a state, independent questions and deterministic checks in code.
SourcedTypeSafe docs · Documentation
System One API reference
The request schema (model, state, questions) and answer schema (choice, score, noul with probabilities and confidence) used by the request snippets here.
SourcedTypeSafe docs · Pattern
Screen with a Noul first
Uses two thresholds (0.7 and 0.3 as starting points) so a yes, a no and an unsettled answer each get their own handling.

Using it well

Keep this question narrow. Whether the refund is allowed is a separate decision with its own state.
Run it on billing messages only, or ask it alongside routing in the same request.

Request definition

POST https://api.typesafe.ai/v1/systemone

{
  "model": "jev-latest",
  "state": {
    "message": "<message>"
  },
  "questions": {
    "requests_refund": {
      "type": "noul",
      "instructions": "Does the customer ask for money back, a refund, a reversed charge, or a credit for a payment?",
      "criteria": {
        "true": "The message asks for some or all of a payment to be returned or credited.",
        "false": "The message mentions a charge or price but asks for something else, such as an invoice, an explanation or a plan change."
      }
    }
  }
}

Request shape from the System One API reference; a Kev server accepts the same body. Replace the placeholder state with your data. Requests need your own API key or server.