> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stateset.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ResponseCX Workflows

> The workflows teams automate first — and which billable outcome each one produces.

# ResponseCX Workflows

These are the flows teams automate first. Each one maps to a **billable outcome**, so the workflow
and the unit you're paid for are the same thing — which is why "did it resolve?" has a definite
answer rather than a judgement call.

| Workflow            | Outcome produced          |
| ------------------- | ------------------------- |
| WISMO               | WISMO Resolution          |
| Returns and refunds | Resolved Return / RMA     |
| Order changes       | Resolved Customer Contact |
| Escalation          | Triage Outcome            |

See [Billing](/stateset-billing) for which are live today.

## WISMO — where is my order

The highest-volume ticket type in most stores, and the easiest to resolve without a human.

1. Pull the latest fulfilment and carrier status.
2. Detect exceptions or delays.
3. Answer, or offer resolution options if the news is bad.

<Tip>
  Automate this first. It's high volume, low risk, and the resolution is almost always "here is the
  information" rather than an action with consequences — so it builds confidence in the agent before
  you point it at refunds.
</Tip>

## Returns and refunds

1. Validate eligibility against policy — window, condition, item.
2. Create the return authorisation.
3. Trigger the refund or exchange.
4. Notify the customer with return tracking.

<Warning>
  Step 3 is where money moves, so it belongs behind the [review
  gate](/stateset-response/responsecx-workflow-studio). Refunds at or above the High-Value Action
  threshold — **\$100 by default** — require human approval before execution.

  Also: approving a return doesn't restock anything. Receipt does. See the
  [returns workflow](/stateset-icommerce/stateset-icommerce-returns-workflow) for the state machine.
</Warning>

## Order changes

1. Verify order state and payment status.
2. Apply the update — address, quantity, substitution.
3. Recalculate totals and validate constraints.
4. Confirm with the customer.

Step 1 matters more than it looks: a shipped order can't have its address changed, and attempting it
produces a confusing failure rather than a clean refusal. Check state before promising anything.

## Escalation

Escalation isn't a failure path — it's a **first-class outcome**, billed as a Triage Outcome, and
the correct result when the agent shouldn't decide.

1. Detect a low-confidence outcome, a policy exception, or a
   [refused decision](/stateset-nsr-decisions).
2. Route to human review **with full context** — the conversation, the order, and what the agent was
   about to do.
3. Resume automation after approval.

<Note>
  The design point: a refusal is the right answer, not a broken one. An agent that escalates rather
  than guessing is working correctly, and you're paid for the triage. That's what makes
  refuse-by-default commercially viable instead of a cost.
</Note>

## What runs underneath

These workflows execute as durable [Temporal workflows](/next-temporal/workflow) through a
15-phase pipeline you configure per brand in
[Workflow Studio](/stateset-response/responsecx-workflow-studio). Because each step is a replayable
activity, an escalation can wait hours or days for a human without holding a connection open.

## Configuring them

| Concern                                 | Where                                                            |
| --------------------------------------- | ---------------------------------------------------------------- |
| Which phases run, and skip rules        | [Workflow Studio](/stateset-response/responsecx-workflow-studio) |
| Model, escalation phrases, takeover     | [Settings](/response-api-reference/settings)                     |
| Named policy constraints                | [Rules](/response-api-reference/rules)                           |
| Authorisation for consequential actions | [Decision gate](/next-temporal/policy-engine)                    |

## Related

* [ResponseCX Platform](/stateset-response/responsecx-platform) — architecture and outcome model
* [Workflow Studio](/stateset-response/responsecx-workflow-studio)
* [Billing](/stateset-billing) — outcome SKUs and disputes