Worked case: returns and refunds at a mid-size online retailer

A self-directed case from public sources only: policy, help centre, ten complaint threads, law, a walk through the journey. Six artifacts, every number tagged.

Version 1.2, reviewed. Every figure carries a source tag: what the tags mean. The six blank templates this case fills are at /templates.

Read this before anything else. This is a self-directed case study built from public sources. It is not client work. There is no client. Nobody hired me, nobody reviewed the retailer's real process with me, and no internal document was used to build it. Everything below was assembled from a published returns policy, help centre articles, public complaint threads, consumer law and a walk through the published customer journey.

I publish it for one reason. The six blank templates in this pack are worth very little until you have seen them filled to the standard they are asking for, and most public examples of "a filled requirements register" are a heading list with filler text under it.

The retailer is not named, and here is why

Every source I used is public, so naming the shop would be legal and easy. I decided against it twice.

The first reason is that an unsolicited public teardown of a company that never asked for one is a different product from a teaching artifact, and I do not want to sell the second while quietly shipping the first. The second reason is practical: the moment a real name is on the page, readers argue about the shop. I have watched it happen to other people's case studies. The method is the point, and the method reproduces on any retailer with a published returns policy in about two evenings.

If you build your own version, you have the same choice, and it is a real one. Name the company and your case gets checkable, which is worth a lot. Leave it out and you keep the reader looking at your reasoning. Either is defensible. Saying nothing about which you chose is not.

How to read the numbers

Every figure in this case carries a tag saying where it came from. This is not decoration. It is the whole difference between an analyst and someone who fills gaps with confident guesses, and it is the habit that took me longest to build.

Tags combine when a claim has more than one origin. [MINE, OPEN, OQ-01] reads as "a number I chose, still unresolved, tracked as open question 1", and the question id sits inside the tag so you can find it in one search. Template 1 in this pack carries the same legend, because the convention belongs to the pack rather than to this case: it governs the four templates that hold claims about the business, and the review log and the one-page summary carry no tags at all.

Two things I did not do. I did not put a fake damage claim through a real shop's process to collect timings for a marketing artifact, so anything tagged [WALKTHROUGH] records what the published process forces a customer to do, checked up to the point where a genuine order would have been required. And I did not turn a count into a percentage anywhere, which is the single easiest way to get caught by a reviewer who reads carefully.

One more note if you have read the BRD piece on this site. It counts the same problem the same way, from the same ten threads, because it is the same case seen from the document end rather than the workshop end. Neither has a queue export behind it, and both say so in the line where the number appears. That is the version you can build from outside, which is the version most people who are trying to get hired actually need.

Case sheet

The six artifacts and where they are

Section 1 is the brief. It is not one of the six, it is the thing that makes the six defensible, and it is the section most people skip.

1. Brief

1.1 How I know there is a problem

Five sources, and the right-hand column is the half that matters.

Thread selection, stated so you can attack it. I took the first ten threads on a public review site that matched the word "damaged", newest first, on 14 March 2026, and read each one to the end. I did not skip the ones that ended happily. Two of the ten did.

1.2 What I actually observed

Numbered, because a reviewer's comment should be able to land on one line instead of a paragraph.

OBS-01 [WALKTHROUGH] There is no online form for a damaged delivery. The help centre article ends with a phone number and an opening time.

OBS-02 [WALKTHROUGH] The phone line runs 09:00 to 17:00 on working days. A parcel opened on Friday evening waits until Monday to start.

OBS-03 [HELP] Photographic evidence is requested by email after the call, not before it. The customer therefore makes contact twice before anything is assessed.

OBS-04 [THREADS n=10] Four of the ten threads I read ended with the customer chasing an unanswered case rather than with a decision, refund or refusal. This is a count of ten threads I chose myself. It is not a rate, and no rate can be obtained from outside the company. Section 3.2 says the same thing on the face of the model.

OBS-05 [THREADS n=10] In three of those four, a second agent asked for evidence the customer had already sent. The thread had restarted.

OBS-06 [HELP] The help centre says the company aims to resolve returns within five working days. It does not say what happens when it does not, and the word "aim" is doing a great deal of work in that sentence.

OBS-07 [POLICY] Partial refunds are described as available only above 40 EUR order value, worded as a hard rule in the policy and in two help centre articles. Nowhere is there a reason.

OBS-08 [HELP] A returned item is inspected on receipt, and the outcome of that inspection can change the refund. So somebody at the goods-in dock is making a judgement that appears in no policy the customer can read.

1.3 The problem, counted as far as it can be counted

The failure is not that refunds are refused. It is that a case can enter a state where nobody owns it and no clock is running, and the only mechanism that moves it again is the customer's own persistence.

I would like to tell you how often that happens. I cannot. The honest statement of the problem is this one:

A damaged-delivery case that lacks sufficient evidence at the first call has no named owner and no due date. Four of the ten complaint threads I read ended in exactly that state [THREADS n=10]. The frequency across all cases is unknown from outside the company, and measuring it is the first thing I would do with access [OPEN, OQ-06].

That paragraph is duller than "40% of cases stall". It is also the only version that survives a reviewer with ten seconds and a suspicious mind.

1.4 The anti-goal

I am not trying to reduce the number of refunds. If refunds fall after this change, I want that explained rather than celebrated, because the most efficient way to reduce refunds is to make claiming one harder, and that is the failure mode this work could most easily produce.

Writing the anti-goal down costs one sentence and stops the team optimising the metric that would make the business worse.

1.5 Scope

In scope. Damaged-delivery refunds for web store orders, from the moment the customer wants to report damage to the moment a refund decision is recorded.

Out of scope, with a reason for each.

Not decided yet, which is not the same as out of scope.

The distinction between those two tables is the one I most often see collapsed. Items in the first table are gone. The item in the second one is coming back, and it will come back at the worst possible moment unless it has a date on it.

1.6 What would change my mind

If the queue export showed that parked cases are rare and short, this work is not worth a release slot and I would say so. The measurement in OQ-06 is therefore not a nice-to-have at the end. It is the thing that decides whether the rest of this case is right.

2. Stakeholder map

Seven rows. The column that earns the page is "Decision right", and the row that earns the page is number 3.

Decision right legend. A approves, their yes is required. V vetoes, their no stops it. D decides in practice, holds the outcome day to day whatever the org chart says. C consulted. I informed.

2.1 The row nobody invites

The interesting stakeholder in this case is not the Head of Customer Care. It is the goods-in lead at the warehouse.

That role is not in the meeting where a refund window gets shortened. It has no formal approval right anywhere I can see. It also physically receives the returned item, decides whether its condition matches what was claimed, and decides whether it goes back on the shelf or into the scrap bin. The published process gives it a decision that the published policy never mentions.

The to-be in section 3 makes that position worse, and it does so as a direct consequence of the change I am recommending. If the refund is approved from photographs before the parcel arrives, then the dispute about condition happens after the money has left. Today the sequence protects the role by accident. My change removes that accident without replacing it, which is why REQ-017 exists and why the first line of my one-pager asks for whoever holds it to be in the room before this ships.

That is what a decision right looks like when it is not on the org chart. If a row in your map does not tell me what that person loses when the project succeeds, the row is decoration.

2.2 What is missing from this map, and why

Every name. I have roles and no people, because public sources do not carry a staff list and I am not going to guess at one. Where a real engagement would have a name, this map has an open question, and the register in section 8 carries it as OQ-03.

An empty owner slot with a question against it reads as diligence. An invented name reads as something else, and it is the kind of thing that unravels in the first interview when somebody asks how you met her.

3. Process

Both models describe the same slice: a damaged delivery on a web store order, from the customer noticing the damage to a refund decision being recorded.

3.1 As-is

DAMAGED DELIVERY, AS IT RUNS TODAY

  Customer notices damage
        |
        v
  Customer calls ................. phone only, 09:00-17:00 working days   [WALKTHROUGH]
        |
        v
  Agent opens the order .......... asks for photos by email, thread starts [HELP]
        |
        v
  +--------------------------+
  |   Evidence enough?       | .... judged by the agent, no written test   [WALKTHROUGH]
  +--------------------------+
      |                    |
     YES                  NO
      |                    |
      v                    v
  Refund issued        CASE PARKED
  2-5 working days     no owner, no clock, no due date
  [POLICY]                   |
                             v
                     Customer chases it
                     new call, new agent, thread restarts               [THREADS n=10]

3.2 The exception path, which is the point of this model

Step 6b is the artifact. It is the only part of the as-is worth drawing, and my first draft did not have it at all.

What actually happens in that state. The case exists as an email thread and a call note. It carries a reference the customer can quote, and that reference carries no due date. No queue owns it, because a shared mailbox is not an owner, it is a room where cases go to stop being anybody's. No alert fires, because nothing is late. Nothing is late because no clock was ever started.

How the case leaves that state. The customer chases. That is the mechanism. In the ten threads I read, the second contact is always initiated by the customer, never by the company [THREADS n=10].

How often it happens. Unknown, and unknowable from outside. Four of the ten threads I chose ended here, which is a count of ten threads and not a frequency. The model carries that on its face: parked branch, frequency unknown, flagged for measurement. Turning it into a percentage would have been the easiest thing in this whole document for a reviewer to catch, and I nearly did it.

3.3 To-be

Two changes. Not ten.

DAMAGED DELIVERY, PROPOSED

  Customer notices damage
        |
        v
  Self-service form .............. photos attached, available 24/7   <-- CHANGE 1
        |
        v
  Automated pre-check ............ order value and delivery date,
        |                          BR-04 and BR-11 applied, may approve, never refuse
        v
  +--------------------------+
  |  Decision within 48 h?   | .... clock starts at the form submission timestamp
  +--------------------------+
      |                    |
     YES                  NO
      |                    |
      v                    v
  Refund issued        ESCALATED                                     <-- CHANGE 2
  same working day     named duty owner, due date on the case,
                       customer told who has it and by when
                             |
                             v
                     Still an exception path.
                     It just has a name and a deadline on it.

Change 1. Evidence is collected before a human sees the case. The customer describes the damage once, in a form, with photographs attached, at whatever hour they opened the parcel. The pre-check applies the two rules that can be applied mechanically and either approves or passes the case to a person with the reason it stopped.

Change 2. The parked branch gets an owner and a clock. A case with no decision at 48 hours is assigned to a named individual on a duty rota, with a due date written to the case and a message to the customer naming both.

The parked branch still exists in the to-be. Pretending it will not is how you lose the first review. Cases will still arrive that a rule cannot settle, and the design question was never how to eliminate them. It was who holds them and by when.

3.4 What I deliberately did not change

A to-be that fixes everything is a to-be that nobody has costed.

• Change-of-mind returns. Out of scope, different policy, and dragging them in would triple the size of this.
• The 40 EUR threshold. It is not mine to change, and I could not even find its owner.
• The accounting posting. Untouched, which keeps Finance systems out of the release.
• The 2 to 5 working day payout window. That is a payment operation, not a decision, and no evidence I have says it is the problem.
• The phone line. It stays. Removing it would be a cost saving dressed as a customer improvement, and the phone is the only channel for anyone the form does not fit.
• A customer-facing status tracker. Tempting, genuinely useful, and a third change. The first two have to be measured before I spend anyone's release slot on a fourth screen.
• Staffing hours. See OQ-04, which is where that argument actually belongs.

3.5 What the to-be makes worse

Three things, and I would rather write them here than have them found.

1. The condition dispute moves after the money. Deciding from photographs before the parcel arrives shifts risk onto the goods-in dock. REQ-017 is the way back, and it is not optional. The goods-in lead should see this before it ships.
2. A 48 hour clock in calendar hours produces weekend escalations. A form submitted at 23:50 on Friday is due at 23:50 on Sunday, and it will escalate to a duty rota that may not exist. OQ-04, with a fallback that changes the public promise if the answer is no.
3. Self-service moves evidence work onto the customer. Someone whose parcel never arrived has nothing to photograph, and on the phone they at least got a human. That case is now explicitly out of scope with an owner named, which is a decision rather than an oversight, and it arrived through review rather than through my own diligence. See RL-04.

4. Requirements register

Five requirements, each traceable, each testable by someone who cannot ask me what I meant.

On the numbering. IDs REQ-001 to REQ-013 are reserved for the change-of-mind slice, which this case puts out of scope. Nothing below REQ-014 is written yet. I mention it because the first question anyone asks about this register is why it starts at fourteen.

REQ-014 Refund on damaged delivery

Acceptance criteria

1. Photo upload accepts up to 3 files, 10 MB each. A fourth file is rejected before upload with a message that names the limit, and the accepted formats are listed on the form itself rather than in a help article.
2. A refund decision is recorded within 48 hours of the timestamp on the submitted form, not the moment an agent opens it. If no decision is recorded by then, the case is assigned under REQ-015 and the customer is told who holds it and by when.
3. Partial refunds are permitted only when the order value is above 40 EUR (BR-11). At or below 40 EUR the refund is full or refused, never partial.

Notes on the numbers. The 3 files at 10 MB is [MINE]. I found no such limit in any public source and I chose it, which is exactly why it stays visible rather than being quietly absorbed into a design document. The 48 hours is also [MINE], and it is deliberately tighter than the published five working days. It is the single number in this case most likely to be changed by its rule owner, and the design does not fall over if it becomes 72.

Open questions. OQ-04 (weekend rota), OQ-05 (partial refunds in release 1).

REQ-015 Escalation ownership

Acceptance criteria

1. On breach of the 48 hour window the case is assigned to a named individual on the duty rota. Assignment to a shared mailbox, a group or a queue does not satisfy this criterion.
2. The assignment writes a due date to the case: the earlier of five working days from submission (BR-07) or 24 hours from assignment.
3. The customer receives one message naming the person holding the case and the date by which they will hear back. A reassignment sends one further message. A case reopened by the customer sends none, because a reopen is not an escalation.

Why criterion 1 is worded as a prohibition. Because every implementation of this requirement that I have seen goes to a queue, and a queue satisfies the sentence "the case is assigned" while changing nothing at all.

REQ-016 Evidence retention

Acceptance criteria

1. Photographs are deleted 90 days after the case closes, by a scheduled job rather than on request [MINE, OPEN, OQ-01].
2. A case reopened inside the retention window keeps its evidence. A case reopened after it starts with none, and the customer is told that before they reopen rather than after.
3. Deletion is logged with case id and timestamp, and the log outlives the photographs.

Open question OQ-01. The 90 days is proposed, not confirmed. It has to be checked against the statutory retention limits in the relevant market and against how long a claim can be brought. Owner: legal. Due: before build starts. Fallback if the date passes: photographs default to the shortest defensible period and the decision goes up rather than sideways. An open question without a fallback is a wish.

REQ-017 Condition dispute after payout

Acceptance criteria

1. Where the item received does not match the evidence, the goods-in lead can reopen the case within five working days of receipt, from the goods-in screen, without going through Customer Care.
2. A reopened case names what does not match, in a list of stated reasons rather than free text, and carries at least one photograph taken at the dock.
3. Money already paid is never reversed automatically. The reopened case goes to a named owner in Customer Care with the same 48 hour clock as any other case.

Why criterion 3 exists. Automatic clawback is the obvious design and it is the one that produces the complaint thread. A person decides, and the customer hears from a person.

REQ-018 The automated pre-check may approve, never refuse

Acceptance criteria

1. The pre-check can approve a refund that satisfies BR-04 and BR-11 and issue it with no human involvement.
2. It cannot refuse. Anything it does not approve is passed to a person, together with the reason it stopped, phrased in the words of the rule that stopped it rather than an error code.
3. Every automated approval records the rule version that approved it, so a later change to BR-11 can be traced to the cases decided under the old one.

4.1 Five must-haves in one release is a smell

It is, and I left it. Here is the answer to the question a delivery manager will ask.

If I had to cut one, it would be the automation inside REQ-016 criterion 1: a scheduled deletion job becomes a diarised manual deletion for release 1, with the same 90 day rule and the same log. The obligation stays, the build shrinks.

I would not cut REQ-017 or REQ-018, because both are the safety rails on the change that moves money earlier. Shipping change 1 without them is how a process improvement becomes an incident.

5. Business rules register

Four rules. Each one carries what is established, what I inferred, who owns it and what should trigger a review. The Status column is the one most registers leave out, and leaving it out is how a rule that somebody proposed on a Tuesday becomes a rule that "has always been there".

BR-04 Damage reporting window

Damage in transit must be reported within 14 days of delivery.

Established. The window and its wording appear in the published returns policy [POLICY].

Inferred, not confirmed. That the figure is aligned to a carrier claim window. It would explain the shape of the rule. I have no carrier contract and no cost data, so it is an inference wearing a label, and the rule owner can confirm or kill it in one sentence.

Constraint I may not design away. A policy window and a statutory right are different things, and in this market the statutory route for goods that were not as described outlasts a 14 day policy clock [LAW]. So BR-04 governs the fast lane, not the customer's entire entitlement, and the form must not tell a customer on day 15 that they have no rights. I am not a lawyer. That sentence is written for legal to correct rather than to rely on.

Review trigger. A change of carrier or a change to the carrier claim terms.

BR-07 Resolution window

No refund case may stay open longer than five working days.

Established. The help centre says the company aims to resolve returns within five working days [HELP].

The problem with that sentence. "Aims to" is not a rule. From outside I cannot tell whether five working days is a commitment that can be breached or a target that cannot, and the difference decides whether REQ-015 has anything to attach to. A target with no breach state is a wish with a number in it.

Owner. Head of Customer Care, unnamed. OQ-02, due 30 April 2026. Fallback: if it is only a target, it is published as a target on the policy page and the escalation in REQ-015 hangs off the 48 hour window instead, which is mine and therefore mine to guarantee.

Review trigger. Any change to the published promise, and any quarter in which the breach rate is measured for the first time.

BR-11 Partial refund threshold

Partial refunds are permitted only above 40 EUR order value.

Established. The 40 EUR figure and its wording as a hard rule, from the published policy and two help centre articles, consistent across all three [POLICY].

Inferred, not confirmed. The rationale. Below 40 EUR the handling cost of a split refund plausibly exceeds the amount recovered. I have no cost data of any kind. Flagged for the rule owner to confirm or kill.

Owner. Whoever signs off refund policy in Finance. I could not name a person from public sources, so the row is open rather than blank. OQ-03.

Review trigger. A change in the payment provider's per-transaction fee, which is the input most likely to move the break-even point the rule is standing on.

Why this rule gets a page to itself, and when it got one. This page is what came out of RL-05. In v1.1 the rule was one line in the register: the number, and nothing else. "BR-11: partial refunds above 40 EUR only" is a rule with no reason and no owner, and it reads like a law of physics. Rules outlive the people who set them. I have sat in a workshop where a threshold nobody could explain survived a redesign, because changing it felt riskier than keeping it, and the only defence against that is writing down the argument while somebody still remembers it.

BR-12 Ownership of a missed window

A case that misses its decision window is assigned to a named person, not to a queue.

Status. Proposed by me. This rule does not exist today, and no public source implies it. It is here because REQ-015 needs a rule to trace to, and inventing the rule silently inside a requirement is how registers rot.

Traces to. BR-07. A deadline with no owner is a deadline nobody keeps and nobody breaks.

Owner if adopted. Head of Customer Care.

Review trigger. Any change to the duty rota, and any month in which the rota is not staffed for a full weekend.

6. Review log

I asked two people to pull this document apart, with the instruction to be unkind. Neither of them works for the retailer. Nobody inside the company was asked anything at any point in this case, and that includes the review: these are two peers reading a document, not stakeholders confirming facts about their own process.

Who read it. A developer on the delivery side, who reads process models before registers and has spent years being handed requirements that come apart in build. A business analyst I have worked with, who reviews requirements documents for a living and was asked for the objections rather than the compliment. Two sessions, both after the self-review against the scorecard that produced v1.1.

Five objections came back. Four changed the case. One I accepted only in part, and the disagreement is recorded here rather than quietly dropped.

The log is the artifact I would read first if this were somebody else's pack. Finished drafts are cheap.

Reviewed version: v1.2, 9 April 2026. Reviewers: two peers, two sessions, neither with access to the retailer. Objections raised: 5. Accepted: 4. Held with reason: 1.

RL-01 "Your as-is is the happy path"

Who and when. The developer, 2 April 2026, about ten minutes into a session that started with the process model and never reached the register.

Objection. The first version of the as-is had no parked branch at all. It ran call, evidence, decision, refund, and stopped. Which made the to-be look like an improvement on a process that was already working.

Why it mattered. If the as-is only shows the path where things go well, the to-be is being compared with a fiction, and every benefit claimed for it is unearned. It took the reviewer about forty seconds to see it.

What changed. The parked branch is now in the model, and it is the reason the model exists. Section 3.2 describes the state in full: no owner, no clock, customer-driven exit. The frequency label sits on the diagram rather than in a footnote. Two further consequences fell out of it, REQ-015 and BR-12, neither of which existed in v1.0.

Status. Accepted in full. This objection produced more of the case than my own first pass did, which is the argument for having one.

RL-02 "Under 48 hours from what moment?"

Who and when. The developer, 2 April 2026, same session, reading REQ-014 for what a build team would have to test.

Objection. The first draft of REQ-014 criterion 2 said a decision is returned within 48 hours and never named the start event.

Why it mattered. Two readings both fit the sentence. One counts from the moment the customer presses submit. The other counts from the moment the case is received on our side. The gap between them is most of a working day, and it is exactly the kind of thing that gets discovered at a sprint review with two people disagreeing about whether the work is done.

What changed. The clock is anchored to the timestamp on the submitted form. The criterion says so in the criterion, not in a note underneath it.

What the fix exposed. Anchoring the clock immediately raised a second question that the vague version had been hiding: 48 clock hours or 48 working hours. I chose clock hours, because a customer holding a broken item does not care about our rota, and that choice produces weekend escalations into a rota that may not exist. That is now OQ-04, with a fallback that changes the public promise if Customer Care cannot staff it. One vague sentence was concealing two decisions.

Status. Accepted in full, and it is the cheapest fix in the document.

RL-03 "Four in ten is a count, not a rate"

Who and when. The business analyst, 6 April 2026, after reading the source table in section 1.1 and then the brief.

Objection. An early draft of the brief said four in ten damaged-delivery cases end without an owner. I had ten complaint threads that I selected myself, four of which ended that way, and I had turned that into a statement about all cases.

Why it mattered. My own source table says complaint threads do not give a representative sample. The document was contradicting its own method two pages later, and a reader who noticed would be right to stop reading.

What changed. Every use of the figure now names the denominator, the selection method and the date. The model carries "frequency unknown, flagged for measurement" on its face. OQ-06 says what I would measure first with access.

What I did not accept. The reviewer's stronger version was to cut the number entirely and say only that the branch exists. I kept the count. A reader who wants to check it can repeat my selection in twenty minutes, and a labelled count with a stated method is more useful than a shrug. If the label is doing its job, keeping the number costs nothing. If the label is not doing its job, cutting the number would not have saved me anyway.

Status. Accepted on labelling, held on the number. The disagreement stands and it is a reasonable one.

RL-04 "A customer whose parcel never arrived has nothing to photograph"

Who and when. The business analyst, 6 April 2026, same session, on the to-be model rather than the register.

Objection. The to-be routes everything through a form built around photographic evidence. A customer whose parcel was stolen, lost or never delivered has no photograph to give, and on the phone they at least got a person who could improvise.

Why it mattered. The self-service change quietly makes one group of customers worse off, and it was the group least able to argue about it. Nothing in v1.1 said so.

What changed. Non-delivery and lost parcels are now explicitly out of scope, with a reason and an owner, in section 1.5. The exception is named rather than unnoticed.

Why the fix did not go into REQ-014. The obvious response was a fourth acceptance criterion covering a no-photo path. I did not add one, because that would have buried a scope decision inside a requirement where no reviewer would find it. An exception you exclude on purpose is a decision and belongs in the scope section. An exception you did not notice is a defect with a delivery date on it. Hiding the first inside a criterion is how it turns into the second.

Status. Accepted, with the fix deliberately placed somewhere other than where it was requested.

RL-05 "Why 40 EUR? Who set that?"

Who and when. The business analyst, 6 April 2026, same session, reading the rules register straight after the requirements.

Objection. v1.1 carried the 40 EUR partial refund threshold as one line in the register: the number, and nothing else. No source beside it, no owner, no reason.

Why it mattered. The figure itself was never in doubt, it is published. What was missing was everything that lets somebody argue with it later. A number with no recorded reason reads like a fact of nature, and nobody argues with those. That is how a threshold survives a redesign it should not have survived, because changing it feels riskier than keeping it, and the argument for it is only available while somebody still remembers it.

What changed. The threshold got a page of its own, BR-11. The established part is the figure and its wording as a hard rule, consistent across the published policy and two help centre articles. The rationale is written down and labelled as my inference, because I have no cost data of any kind and nothing public explains the number. The owner is whoever signs off refund policy in Finance; no name is available from public sources, so the row is open rather than blank and the gap is tracked as OQ-03. A review trigger names the input most likely to move the rule, the payment provider's per-transaction fee.

What I did not change. The number. It is published policy, I cannot improve on it from outside the company, and the objection was never about the figure anyway. It was about the silence around it.

Status. Accepted. This is the objection that produced an artifact rather than an edit, which is what the good ones tend to do. Nothing in v1.1 would have told a reader that the reason under BR-11 is mine and not the company's.

7. One-page summary

Written last. Read first. Addressed to the person who has to say yes or no.

To: Head of Customer Care From: Sebastian Koczyk, business analyst Date: 9 April 2026 Subject: Damaged-delivery refunds, decision requested by 30 April 2026

Decision requested. Approve automatic escalation of undecided refund cases after 48 hours, with a named owner per case, and a self-service form that collects photographic evidence before a person sees the case. Cost: one process change and a queue configuration. Effect: cases that currently stall get an owner and a deadline. How many stall cannot be answered from outside the company, and it is the first thing I would measure.

The problem in three lines. A damaged-delivery case that lacks sufficient evidence at the first call has no named owner and no due date. The only thing that moves it is the customer chasing us. Four of the ten public complaint threads I read ended in exactly that state, which is a count of ten threads and not a rate.

Options.

No cost figures anywhere on this page. I cannot price internal effort from outside the company, and an invented figure would be the first thing to break in the room.

Recommendation. Option B. It is two changes rather than ten, both are reversible, and it produces the measurement that tells us whether Option C is ever worth funding. Sebastian Koczyk, 9 April 2026.

If we do nothing. Nothing breaks visibly. Cases continue to leave through the customer's persistence, the five working day line stays unmeasured, and the cost sits with customers who give up and with agents who absorb the second and third call.

What I need from you, by 30 April 2026.

1. Confirm whether five working days is a commitment or a target (OQ-02).
2. Decide whether partial refunds are in release 1 (OQ-05).
3. Name the duty rota owner, and tell me whether it covers weekends (OQ-04).
4. Put the goods-in lead in the room before anything ships.

What I could not answer. How often cases stall today. It cannot be obtained from outside, and it is the first number I would pull with access.

8. Open questions register

Every open question has an owner, a date and a fallback. The fallback is the part people leave out, and without it an open question is a wish with a due date attached.

How to use this case

The point of publishing a finished case is not that you copy it. A returns case with my structure and my rules, submitted by you, is worth less than a rough one built on a process you can talk about for twenty minutes. Here is the same method on a different process, in five steps.

Step 1. Pick a process you can watch from the outside

Time: thirty minutes, and most of that is rejecting candidates.

Three tests, all of which have to pass. The rules must be published somewhere you can read. The failures must be visible in public, usually in complaint threads or reviews. And you must be able to walk at least part of it yourself as a customer.

Appointment booking at a clinic passes. Airline rebooking after a cancellation passes. Anything happening entirely inside a company you have never worked at fails, and no amount of writing will fix that.

Pick something that annoyed you personally in the last month. You will still be interested in it on the third evening, which is when this actually gets built.

The trap: picking a process because it sounds impressive. Trading settlement is a worse choice than a clinic booking if you cannot see a single real failure in it.

Step 2. Collect facts, and tag every one

Time: one evening, two if the policy is long.

Build the five-source table from section 1.1 for your process. Fill the right-hand column first, because knowing what a source cannot tell you is what stops you inventing it later.

Then write numbered observations, each with a tag saying where it came from. Nothing enters the document untagged. When you cannot find something, that is not a dead end, it is an open question with an owner and a date, and it belongs in the register from section 8.

The trap: upgrading a count into a rate. Four threads out of ten that you picked yourself is four threads out of ten that you picked yourself, on every page it appears.

Puts you past: check 05, "Open questions are listed with an owner and a date".

Step 3. Draw the as-is until you find where work stops

Time: three to four hours, including one full redraw. There is always one full redraw.

Draw it, then go looking for the branch nobody owns: the state a case can enter where no clock is running and nothing but a human's persistence will move it again. Every process has one. In mine it is a parked case in a shared mailbox. In a clinic it is the referral that came back incomplete.

When you find it, that branch is the model. Everything else is context.

Then write the to-be, and change exactly two things. Write down what you deliberately did not change, and what your change makes worse. Both lists are shorter to write than they look and they are the difference between a proposal and a wish.

The trap: modelling what should happen instead of what does. If your as-is has no failure branch, you have drawn a brochure.

Puts you past: check 03, "The as-is model shows the exception path, not the happy one".

Step 4. Write five requirements and the rules behind them

Time: three to four hours, most of it not spent writing.

Five, not fifteen. For each one: the statement, what it traces to, where it came from, and three acceptance criteria that a tester could run without phoning you. Any duration gets a start event. Any threshold gets a rule id, and any rule gets an owner and a rationale, with your inferences labelled as inferences.

Then write the one-pager last and put the decision in the first line. If your page has no decision, no owner and no date, it is a covering note.

The trap: a number with no source. If the honest answer is "it seemed reasonable", tag it as yours and leave it visible. A visible choice can be argued with. A hidden one gets renegotiated mid-build by whoever sits closest to the keyboard.

Puts you past: checks 01 and 02, "Every requirement traces to a named business rule" and "Acceptance criteria are testable without asking the author". The stakeholder map you write alongside it puts you past check 04, "Each stakeholder has a decision right, not just a job title", as long as every row says what that person loses when the project succeeds.

Step 5. Get it broken, and keep the log

Time: thirty minutes after the review. The review itself costs you one favour from somebody competent.

Send it to one person who will tell you it is wrong, and ask them for the unkind version rather than the encouraging one. Write down what they said, what you changed, and where you held your ground and why.

Publish the log with the case. It is the artifact that cannot be faked, and it is the one I read first.

The trap: publishing only the version that makes you look good. Hiding the objections hides the only proof that you can take feedback without collapsing, which is the thing anybody deciding whether to work with you is actually trying to find out.

Scorecard. The twenty-five checks behind this case are in the scorecard, versioned and dated. It is not inside this pack: it is a separate free file at analify.com/scorecard, with no email address asked for. Run them on your own work before somebody else does, or hand the scorecard to a colleague and ask them to be unkind.

Licence. Use this case and the templates in your own job applications and at work, including commercially. Do not resell them as your own product. If something here helped you land an interview, tell me. While this site is young that is the only feedback loop I have.

All six templates · The scorecard · The Case File notes