Something will go wrong, so design for that

Failure is not the exception in your process. It is a permanent, predictable part of it.

Most processes are designed for the path where everything works, then patched afterwards for the times it does not. That is backwards, because the working path is the one that needs least support. Nobody feels strongly about a transaction that completed as expected. Strong feelings, in both directions, come from the moments something broke and the customer discovered what kind of organisation they had chosen. Those moments are where reputations are actually formed.

Treating failure as a designed state changes what you build. It means deciding in advance who tells the customer, how quickly, and what they are entitled to offer. It means the person who receives the bad news having enough information to say what happens next, rather than promising to find out. It means the exception path being staffed and resourced, not left as overflow work that competes with everything else and always loses.

There is an odd upside here. A problem handled visibly and competently often leaves someone more confident than a transaction that simply went smoothly, because they now have evidence about behaviour under strain. Smooth service proves nothing about character. Recovery does. That is not a reason to break things, but it is a reason to stop treating recovery as an embarrassment to be minimised and start treating it as one of the few chances you get to demonstrate anything at all.