Exception Policy

Specs describe the happy path. The card clears, the invite is accepted, the file uploads, and every one of those screens gets drawn in detail. What the product does when the flow breaks usually goes to engineering as a blank.

So the same scene kept repeating. Theo, wiring up billing, hits the branch where the card is declined and asks Mia what to do. She's in a meeting, the deadline is that day, and Theo decides on the spot: retry once, then lock the account. The same week someone working on coupons hits a similar case and decides differently: retry five times, then let it through. Both choices are defensible, and the product now handles two incidents of the same kind in two different ways.

The bill arrives later. A customer calls Sofia to ask what happens to the documents they have built up if the payment didn't go through. The answer isn't written down anywhere, so Sofia asks Theo, and Theo opens the code before he can answer. Exactly one person knows what the product actually does.

An exception policy exists to settle that answer before the code does. A business rule — a condition the business cannot break — comes first, an edge case finds the boundary situation where that condition wobbles, and this document says what happens in each of those situations.

Six fields cover one exception. A failed card payment fills them in like this.

1. Trigger condition — written so a machine can evaluate it. Not "if payment fails" but "if the card issuer returns a decline on a recurring charge." A condition that needs human interpretation gets translated differently by every engineer who reads it.
2. Immediate behavior — what the product does at that moment. On the first failure the subscription isn't cancelled; the account moves to a payment-overdue state and every feature stays open.
3. Retries and deadlines — how many attempts, how far apart. Three attempts three days apart puts the last one on day nine.
4. Notification — who hears about it, when, and through what channel. Email to the billing contact on the first failure, the account admin on the second, an in-product banner on the third. If the recipient has no authority to change the payment method, the notice goes out and nothing happens.
5. End state — where the account lands if nothing gets resolved. Read-only for 30 days, then the retention period closes. This field lines up with promises made in the terms of service, so the wording isn't chosen freely.
6. Manual override — who can step outside the policy and how far. Enterprise customers run late because of invoicing procedures, which creates exceptions to the exception. Write down whether support can stretch 30 days to 60, and whose approval that takes.

Field 3 is the one most often left blank. Plenty of documents stop at "retry on failure," which hands the count and the interval to whoever writes the code and quietly drops the question of when to tell the customer. If the reasoning behind three attempts three days apart needs to survive, keep a decision record beside it and leave only the decision here.

The product manager who owns the feature drafts it. When engineering writes it, the document tilts toward whatever is easiest to build right now; when support writes it, it covers only the tickets that already arrived. Fewer gaps appear when the person who sees the whole flow and holds the decision writes first and the others review.

Review comes from three directions. Engineering checks that the trigger condition is something a machine can evaluate, support checks that the sentences can be read to a customer as written, and legal checks that the end state matches the contract.

Three people read it, at three different moments.

1. Engineers read it before writing code. If the conditions and deadlines are there as numbers, they get transcribed. If they're blank, they get invented.
2. Support reads it the moment a ticket arrives. For Sofia to answer "you're read-only with 27 days left" without checking with anyone, that number has to be in the document.
3. Designers read it when choosing screen copy and deciding which buttons belong on that screen. Noa can't write the overdue banner without knowing what happens a few days later.

Since all three read the same document, keep one copy of it somewhere easy to find.

"This case isn't in the exception policy. If all three attempts fail, what happens to the seats?"

The document has no answer, so the build stops here.

"Let's settle the policy before we start building. If it reaches me blank, I'm inventing the banner copy."

An empty field lands on the desk of whoever writes the screen text.

"Policy is read-only for 30 days, then deletion. I told the customer exactly that."

Support answered on the spot instead of escalating.

At Pagedeck the document started with a seat reduction. An account tried to drop to eight seats with nine people already invited, and the product silently removed whoever had been invited last. Days later that person lost access to documents they had been working in, and a ticket arrived. Mia collected the similar situations and found eleven of them. In nine, the product was already doing something that nobody had ever decided it should do.

The most common reading is that an exception policy is a collection of error messages. The visible output is a sentence on a screen, so that's what it looks like from outside. But copy is part of one field out of six, and the thing that actually needs agreement is what state the account is in a few days later. Tidy up only the copy and a polite "your payment didn't go through" still leaves nobody knowing when the account locks.

Treating it as a document that can wait is just as common. Exceptions are rare, so they don't feel urgent. What's rare, though, is each individual situation, not exceptions as a whole. Ten situations that each happen three times in a thousand add up to dozens a month, and every one of those gets handled by hand. Six months without a policy leaves a product whose behavior can only be learned by reading the code, and by then the work starts with investigating what already shipped rather than writing anything down.