Case studies / Customer support
How a support team standardized AI-powered refund investigations
Before Murmurator, every support specialist had their own AI-assisted way of deciding whether a refund request met policy, and no two of them gathered the same evidence.
The team now runs the same controlled workflow for every refund investigation: the same context, the same policy, one model call, and a refund that can only be issued by a condition the definition spells out.
Steps in the workflow
9
One of them calls a model. The other eight are the definition doing exactly what it says.
Where the policy lives
One artifact
Versioned, owned by the account, pulled into the prompt at run time rather than pasted into it.
Refunds issued without a condition passing
None
The action sits behind a condition in the definition, not behind a sentence in a prompt.
This is an example scenario, not a customer. We wrote it to show how this kind of work is put together in Murmurator. The workflow is real and you can build it; the team, the people and the situation are invented. Nothing on this page reports a measured result, because we do not have one to report.
The problem
Three specialists, three investigations
Nobody did anything wrong here. Each specialist found a way to get a genuinely hard job done faster, and each way worked. The problem is that there were three of them, none was written down, and the customer's experience depended on who picked up the ticket.
The same refund request, once per person
- The policy is a paragraph inside three different prompts, each a different vintage
- Order history, payment history and account age are looked up again on every ticket
- Two specialists asked the same question get different answers, and both are defensible
- Nobody can say which refunds the AI influenced, or on what evidence
- The threshold for escalating to a manager lives in people's heads
- When Priya is on leave, her process leaves with her
The expertise is real. It is just held in three people rather than written down, and it walks out of the building with them.
The workflow
One investigation, run the same way every time
The same work, written down as steps. The model still reads the evidence and forms a view — that part genuinely needs judgment. Everything around it is fixed, and it is the same on the four hundredth ticket as on the first.
- Context is gathered by the workflow, not by whoever is on shift
- The policy is one artifact, so improving it improves every future run
- The refund call is reachable only through a condition you can read in the definition
1 step of 9 call a model. The rest are the definition doing exactly what it says.
Trigger Deterministic
A Zendesk ticket is tagged for refund review, or a specialist runs the workflow by hand from the ticket.
Gather context Deterministic
The order and its payment history from Stripe, the customer's previous tickets from Zendesk, and plan and tenure from the product database. One step each, the same fields every time, through connections scoped once.
Load the current policy Deterministic
The refund policy is an artifact the account owns and versions. The step pulls the current text into the prompt, so the rules the model reads are the rules the team last agreed to — not a paragraph copied into a prompt eight months ago.
AI assessment AI
One model call reads the evidence beside the policy and answers: which clause applies, what points for and against, what is missing, and how confident it is.
Validate the output Deterministic
The step declares a JSON schema. An answer that is not in that shape fails the step rather than flowing into the next one as prose nothing downstream can read.
Apply the business rules Deterministic
Conditions read values, not sentences. Amount above the auto-approval limit, account younger than thirty days, a second refund this quarter, or low model confidence each route the run to a person. The thresholds are in the definition, where they can be reviewed and changed on the record.
Hand off where a person is required Deterministic
Held cases post to the refunds channel with the amount, the clause, the evidence and what makes this one unusual compared with the others this week — enough for the reviewer to plausibly say no.
Issue the refund Deterministic
Straightforward cases continue to a Stripe connection scoped to refunds. Held cases resume as a second workflow when someone approves. Either way the model's part ended at the assessment; the call is made because a condition passed.
Verify and record Deterministic
The charge is re-read from Stripe to confirm the refund actually landed, the outcome is written back onto the ticket, and the run keeps its inputs, outputs and token counts against the workflow version that produced them.
A model reasons here The workflow decides, the same way every run
Why it is built this way
Why the model does one step and not the other eight
This is the decision the whole workflow turns on. A model is used where the work is reading a situation and forming a view. Everything that follows from that view is arithmetic, policy or an API call, and none of those improve by being asked nicely.
AI
Reading the request against the policy
Refund requests arrive as prose. "It arrived damaged but I did use it twice" has to be weighed against a clause written for the general case. That is judgment, it does not reduce to a rule, and it is exactly what a model is good at.
Deterministic
Deciding whether the amount needs a human
This is a comparison between a number and a threshold the business set. Asking a model to make it introduces variance into a decision that has a correct answer, and moves a business rule out of the definition and into a prompt where nobody reviews it.
Deterministic
Issuing the refund
Moving money requires no judgment at all by the time you get here — the judgment already happened, upstream, and was validated. The workflow controls this step explicitly so that the answer to "could the AI have refunded this on its own?" is a definition you can read rather than a promise about a prompt.
Deterministic
Fetching the order and payment history
There is one right way to look up an order. Letting each run discover it again wastes tokens, invites a model to fetch the wrong thing, and makes two investigations of the same ticket incomparable.
AI can reason. The workflow controls what happens. On this page that is not a slogan — it is one step out of nine.
Before and after
What actually changed
The work is the same. Who owns it, and what is repeatable about it, is not.
Before
Everyone's own AI process
- Individual prompts, each a different vintage, none reviewed
- The same order, payment and account context gathered again on every ticket
- Two specialists, two defensible answers, and no way to tell which was applied
- The escalation threshold lives in whoever is on shift
- Tribal knowledge that leaves when the person does
- Auditing means asking people what they remember doing
After
One workflow the team owns
- One workflow, versioned, that the whole team runs
- Context gathered once by the definition, the same fields every time
- The policy is an artifact; improving it improves every run that follows
- Thresholds are conditions in the definition, readable without running anything
- The model's output is validated against a schema before anything acts on it
- Every run keeps its inputs, outputs, logs and the version that produced them
What this would change
What the team gets out of it
The point of this is not that the AI got better. The model is doing roughly what it was doing in three separate chat windows. What changed is that the process around it became something the organization owns.
- A new specialist runs the team's process on day one instead of inventing their own
- A policy change is one edit to one artifact, not a message asking everyone to update their prompt
- The question "why was this refunded?" is answered with a link to the run
- Improvements compound, because there is one place to make them
- The blast radius is visible — the Stripe connection can issue refunds and nothing else
No numbers here, on purpose. Time saved, error rates and volumes depend entirely on the team running the process, and we have not measured this one. When a customer has measured theirs and is willing to publish it, their figures will appear here with their name on them.
More case studies
Read next
Turn an AI process into a workflow.
14-day free trial with $5 of built-in AI included. No card, no per-run fees, cancel anytime.