Staff the appeal before you launch
If your automated decision can tell a person no, you have already created the need for an appeal — and shipping the no before you have staffed the appeal is launching half a system and calling it whole.
Count the halves of the system you are about to ship. There is the deciding half — automated, fast, scalable, the part everyone in the room is proud of, the part that can render a verdict on a thousand people before lunch. And there is the contesting half — slow, human, expensive, the part that lets a person who was told no say you were wrong about me and be heard by someone who can do something about it. Most launches ship the first half and defer the second. The deciding half goes live on the launch date; the appeal path becomes a line in the backlog, to be built after the complaints arrive, if they arrive loudly enough. That is not a phased rollout. It is a decision apparatus shipped without a brake.
The reason this happens is not malice; it is gravity. The deciding half is the product — it is what the roadmap is about, what the demo shows, what the metrics reward. The contesting half is a cost center that produces nothing the dashboard counts. So under every ordinary pressure of shipping, the appeal slides right: it is the thing you will get to, the thing a smaller team can bolt on later, the thing that does not block launch. And it does not block launch, because the system works fine at launch — for everyone the system was right about. The people it was wrong about are not in the launch demo. They show up later, one at a time, into a queue you have not built, staffed by no one, with no authority to reverse anything even if someone were there to read the request.
So state the directive plainly: before you launch a system that makes adverse decisions about people, stand up the appeal path, and resource it as part of the launch. Not a form that files a ticket into a void. A real one — with humans who have the authority and the record to reverse a decision — costed and staffed against the volume of decisions you are about to make and the rate at which you expect to be wrong. The right to contest a decision is a public promise your product is making the moment it can say no. Staffing the appeal is how you keep it.
You shipped the no and deferred the yes-you-were-wrong
Look closely at what deferring the appeal actually does, because it is worse than a gap in coverage. When the deciding half runs at machine speed and the contesting half runs at the speed of an understaffed queue — or does not run at all — you have built a system that can say no far faster than it can be told it was wrong. The two halves are not merely unequal; they are asymmetric in a way that compounds. Every day the deciding half runs, it produces more decisions than the contesting half could ever review, so the backlog of the unheard grows structurally, by design, faster than anyone can work it down. The errors do not get corrected. They get absorbed — by the people the system was wrong about, who paid for a mistake they were given no working way to surface.
A system that can say no faster than it can be told it was wrong is not efficient; it is unaccountable at scale, on purpose.
This is the brake that was never installed. We would not accept a vehicle whose accelerator shipped in the first release and whose brakes were slated for a later sprint, because we understand that the ability to stop is not a feature of a car — it is part of what makes the thing a car rather than a hazard. An automated decision system without a functioning appeal is in exactly that condition. It can commit the organization to a consequential judgment about a person at scale, and the person on the wrong end of an error has no lever that reaches anyone able to pull it back. The gap between the decision and the correction does not disappear because you deferred building the correction. It just moves onto the balance sheet of the person you erred against, who did not choose to carry it.
What a staffed appeal actually requires at launch
An appeal path is not a mailbox, so do not confuse having one with having built one. At launch, five things have to be true, and each of them is concrete enough to put on the checklist. First, a real address — a place a person can actually reach, findable at the moment they are told no, that leads somewhere a human will look. Second, humans on the other end with genuine authority to overturn the decision, not a script that re-reads the same policy back to the person and calls it a review. An appeal that can only confirm the original answer is not an appeal; it is the first decision wearing a second coat.
Third, those humans need access to the decision record — the evidence the decision rested on and the rules in force when it was made — so the reviewer can re-decide the case rather than merely re-run the same process that produced the error the first time. A reviewer who sees only the output cannot do anything but ratify it. Fourth, a resourcing plan sized to the decision volume and its expected error rate, because an appeal path staffed for the errors you wish you had, rather than the ones you will actually make, is understaffed the day it opens. And fifth, a loop that feeds reversals back into the system, so that a decision overturned on appeal becomes information the deciding half learns from, rather than a correction made once and forgotten while the same error keeps being manufactured upstream. Miss any one of these and you have the appearance of an appeal without the function — a door that opens onto a wall.
Launch the whole system or none of it
Here is the reframing that should change what you scope. An automated decision without a staffed appeal is not a feature that is missing a feature. It is an accountability failure, and it was designed in — chosen at the planning table when the deciding half was scoped for launch and the contesting half was scoped for later. The failure is not that complaints will pile up; that is a symptom. The failure is that you will have stood up an apparatus that can act adversely on people at scale and cannot, in practice, be made to answer for it. That is a property of the system as launched, not an operational hiccup to be smoothed out in maintenance.
The fix is a matter of where you draw the definition of done. The appeal path belongs inside it — a launch gate, not a post-launch ticket. If the deciding half is ready and the contesting half is not, the system is not ready, in the same sense that a product that computes an answer but cannot display it is not ready. Resource the appeal against the volume you are about to generate, staff it with people who can actually reverse, give them the record so they can re-decide, and wire the reversals back in. The right to contest is empty without a contestant who can be heard by someone able to act — and you are the one deciding, at launch, whether that someone exists. Decide that they do, before the first no goes out, not after the hundredth complaint comes in.
— Dispatches · Summit Cognitive
Continue from here
Turn the argument into a practice.
Get new dispatches, assess how your organization handles consequential decisions, or explore Summit Cognitive.