Design an approval flow for an agent that sends external emails.

Thistlewood Home, an online furniture retailer, built an assistant named Wren that reads post-purchase support tickets and drafts the reply: refund confirmations, shipping delay apologies, exchange offers. Osric Vandenberg runs support operations and decides how much of Wren's output leaves the building without a person's eyes on it first.

How to answer this, stage by stage

Nobody is grading whether you can draw a nice queue. They're grading whether your design still holds up the day the agent gets something expensive wrong.

Let's learn

Picture nine hundred post-purchase emails a week landing in one queue, and a support team that used to answer every single one by hand.

Thistlewood's support agents used to read each ticket, check the order in the warehouse system, and write a reply from scratch, deciding the refund amount themselves. It worked, but a busy Monday could push a reply out past two days, long enough for a customer to call a credit card company instead of waiting.

Three manual steps, each one a place a busy Monday could add a full day.

Now Wren drafts nearly every reply within a minute of the ticket landing. Most simply need a click. Osric still reads every one that touches a refund, but reading has quietly turned into skimming for the ones that look routine.

The tiering by dollar amount looks reasonable, right up until the branch that actually matters is a ledger conflict, not a number.

Here's the turn: the risk was never really "is the refund big." It was "does this email conflict with something that already happened somewhere else." A ten-dollar refund on a case with a hidden conflict is more dangerous than a two-hundred-dollar refund on a clean one, and a dollar-amount-only tiering system has no way to tell those two apart.

At its worst, an unreviewed money-touching email gets automated entirely, and one conflict slips through into a customer's inbox, and then their bank statement, before anyone at Thistlewood notices.

A reviewer who sees these four things can decide in seconds. A reviewer who sees the raw email cannot.

What I would leave alone: pure tracking and shipping-status emails, no money and no promise attached, are safe to auto-send from day one. Holding those too would just slow the ninety percent of tickets that were never the risk.

The lesson: a threshold on the wrong variable feels like safety and isn't. Size the tier by what actually causes harm, not by whatever number is easiest to type into a rule.

Now here is the same thing as a story

The short version above is what you'd say pitching this design to Thistlewood's head of customer experience. Read this one for how close the near miss actually came.

Osric Vandenberg has run support operations for five years, and before Wren, he was the one people called when a refund case got genuinely messy, two systems disagreeing, a customer who'd already been promised something by someone else.

In Wren's first weeks, Osric read every refund email in full, catching a wrong dollar amount here, an oddly worded apology there. As the drafts got cleaner week after week, he started reading the first line and trusting the rest, especially on the emails that looked routine.

Same wrong draft, two different endings. The gap between them is one live check, not a smarter model.

Then a customer emailed back, confused: "I think I already got this refund?" A teammate had processed a manual refund on the same order the week before, outside any system Wren could read from. Wren's draft, a second full refund confirmation, was already sitting in the two-hour queue when the reply came in. A colleague on the floor pulled it with four minutes to spare.

The ledger check didn't exist until week six. Everything before that ran on dollar amount alone, and got lucky once.

With the redesigned flow, every money-touching draft runs the ledger check before it ever queues. Run the same case forward: the second refund draft hits a conflict flag the moment Wren generates it, escalates to a hold regardless of the two-hour default, and Osric sees the conflict called out in plain words before it ever reaches a customer's inbox.

The old design asked "is this refund big enough to worry about." The new one asks "does anything already disagree with this."

I built the dollar-amount tiers first because they were the easiest rule to write down. It took four minutes and a lucky floor colleague to see that the real risk was never about the size of the number.

SPARK, in one screenNot a feature list. SPARK is what forces the anchor to survive its own risk.

The recap, one line per letter: situation is the manual reply workflow it replaces, payoff is time redirected to the genuinely hard cases, anchor is the ledger check plus risk-based hold windows, risk is a duplicate refund the tiering-by-size would have missed, and keep out is holding autonomous send back until the check has proven itself.

And if you want to be sure it really works, try it somewhere elseSame five letters, a debt collection agency's payment-reminder emails instead of a furniture retailer's refunds. A completely different industry, the same missing cross-check.

Meridian Recovery Partners built an agent that emails debtors with payment reminders and settlement offers on delinquent accounts. Rosalind Petrakis runs collections operations and, before the agent, personally approved every settlement offer over five hundred dollars.

Mapped onto SPARK: situation is Rosalind's team manually checking a debtor's payment history before offering any settlement; payoff is redirecting her attention to accounts with a genuine dispute instead of routine reminders; anchor is a live check against the payment ledger before any settlement offer queues, since an agent that doesn't know a payment posted an hour ago will offer a settlement on a debt that's already smaller than it thinks; risk is an offer that undercuts what's actually owed, sent to a debtor who now has it in writing; keep out is full autonomy on any offer above the smallest reminder tier, indefinitely, since a wrong number in writing is a real liability, not a UX inconvenience.

Swap "refund" for "settlement offer," and the same missing cross-check shows up in a completely different kind of email.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "hold money-touching output behind a live conflict check, size the hold by risk category, and let a conflict override the size," and stop.
Cost: there's no engineering time this quarter for a real-time ledger check. Say so honestly, and start with a daily batch reconciliation instead, catching conflicts within a day rather than instantly, since a day-old catch still beats no catch at all.
The model gets better, for real: even if Wren's drafting quality keeps improving, the ledger check still earns its place, because a better draft can still collide with a fact the model was never shown.

Where people run it wrong.
They tier by dollar amount alone and call the risk handled, since a number is the easiest thing to write a rule around.
They let the review queue quietly become a rubber stamp once the drafts start looking clean, without ever tracking whether edits are still happening.
They wait for a customer complaint to reveal a conflict a system-level check could have caught before the email ever queued.

How to use it live. When someone asks you to design an approval flow, ask one question first: what does this agent not know exists, that could make a perfectly reasonable draft actually wrong. Design the check around that gap, not around the size of the number in the email.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0