Scenario walkthrough: a payment outage inquiry

Situation and rules

An online store customer reports that card payments are unavailable, while payment on delivery still works. The issue has been checked on several devices, and cards are not being charged. These details matter: the word “payment” alone does not determine which team should handle the inquiry.

In the example policy, website failures belong to engineering, charges and invoices to finance, and delivery to logistics. A payment-method outage affecting many customers requires urgent human review. The rule is included in the context so it can be checked against the facts.

Separate team, impact and review

The team question selects a route. The impact question assesses severity on a scale that distinguishes one customer's problem, a blocked payment method and a complete halt to ordering. The human_review question checks whether urgent human review is required.

The questions below come from an actual Playground example. They are editable inputs. A response appears after you run the request; no result is filled in beforehand here.

{
  "team": {
    "type": "choice",
    "instructions": "Which team should handle this request? Choose based on the main cause of the problem.",
    "criteria": {
      "engineering": "Engineering: website or integration failure",
      "finance": "Finance: invoices and refunds of charged payments",
      "logistics": "Logistics: shipping and delivery"
    }
  },
  "impact": {
    "type": "score",
    "instructions": "Assess how the described issue affects placing orders.",
    "criteria": [
      "Does not prevent placing orders",
      "Makes ordering harder for one customer",
      "Blocks one payment method for many customers",
      "Blocks every ordering method for all customers"
    ]
  },
  "human_review": {
    "type": "noul",
    "instructions": "Under the stated policy, this request requires urgent human review."
  }
}

Test what changes the decision

Under the stated rule, the expected route is engineering: the inquiry describes a page failure, not a charge. An alternative payment method works, so the context does not support a claim that all ordering has stopped. This is an expectation based on the rule. On 17 October 2026, we also recorded actual API responses to English versions of the original situation and a variant involving a delivery question; both requests, expectations and results are available in Workflow Lab.

Now change one circumstance: a payment was charged twice, a delivery is late or the scale of the problem is unknown. Record the expected decision for each version before running it. This tests the scenario's boundaries and shows whether the criteria are clear enough.

• Keep facts separate from the agent's assumptions.
• Do not equate inconvenience for one customer with a widespread outage.
• Provide a route to a person when necessary facts are missing.