A “one-time” exception becomes the rule

The system has a rule. For example: discount capped at 10%.

Then someone says:

“Let’s do 25% just this once. Keep the rule — only for this order.”

The first time, that sounds reasonable. The customer is upset, a manager decides, work continues.

The problem sits in “just this once.”

Without a reason, a limit, and a trail, the exception does not stay rare — it repeats.

Why the exception sticks

Because the button works.

The next time the same situation appears, the team does not reopen the rule. They press the same override. A week later the “exception” is the main path — nobody calls it that.

After a while it looks like this:

• The written rule says one thing; real sales do another
• New staff learn “how to get around it” first
• Reports do not show why a discount was given
• Managers say “that’s how the system works” — while the system stays quiet

At that point the override is no longer an exception.

It is a hidden rule.

When an exception is fine

I do not ban overrides. Real operations sometimes need them.

But I do not accept them without three things:

• Reason — why we left the rule this time (short, written)
• Boundary — who may do it, and up to what limit
• Trail — who, when, which order; a signal to rewrite the rule if it keeps repeating

With those, an exception can stay an exception.

Without them, you have written a second rule — a weaker one that nobody can see.

Bottom line

“Just this once” is not a plan.

A plan is a reason, a boundary, and a trail.

Otherwise the exception stays.

And a month later the team has the same conversation — only nobody still calls it an exception.