How to Rebuild Trust After You Have Lost It

Four years ago I shipped a change to our settlement engine on a Thursday afternoon, right before a long weekend, because I was convinced it was low risk. It wasn't. By Saturday morning we had double-paid a batch of merchants and underpaid another, and the reconciliation report that should have caught it had been quietly failing for two days. I spent the weekend on the phone with our finance team and three of the affected merchants. One of them, a small logistics firm that ran payroll off our payouts, told me flatly that they had already started looking at a competitor. That sentence stayed with me longer than the incident did.

Losing trust is fast. You can do it in a single bad deploy, a missed SLA, or one meeting where you overpromise a date you have no business promising. Rebuilding it is slow, unglamorous, and mostly invisible. There is no launch announcement for "we have been boringly reliable for six months." But that boring stretch is the entire game, and most engineering leaders get the rebuild wrong because they treat it as a communications problem instead of an operational one.

Name the breach precisely

The first mistake people make is being vague about what actually broke. "We had some issues" is not an apology, it is a dodge, and the person you burned can smell it. When I called that logistics merchant back, I did not say we experienced a disruption. I said: we ran a settlement job with a bug that paid you twice on Tuesday and short-paid you on Wednesday, our reconciliation check was broken so nobody noticed for 48 hours, and that is on us. Specificity is the first deposit back into the account.

Being precise costs you something, which is exactly why it works. It signals you actually understand the failure and are not hiding behind the passive voice. The people you need to win back are usually technical enough, or burned enough, to tell the difference between a real diagnosis and a PR statement. I would rather hand a customer an uncomfortably detailed post-mortem than a polished one that leaves them guessing whether we even know what happened.

Stop the bleeding before the story

There is a strong temptation, especially from the commercial side of the house, to get out in front of a trust failure with messaging. Resist it until the thing is actually contained. Nothing destroys credibility faster than a reassuring email that lands while the problem is still happening. I have watched a well-meaning account manager send "everything is now resolved" forty minutes before the second wave of failed transactions hit, and it turned a recoverable incident into a relationship-ending one.

Order matters here. Contain, verify, then communicate. In that settlement mess my priority was not the narrative, it was making sure no further payout ran until we had frozen the job and checked the next batch by hand against the ledger. Only once I could say with certainty that the bleeding had stopped did I start reaching out. A promise you cannot yet keep is not reassurance, it is a second failure queued up behind the first.

Over-correct visibly, on purpose

Trust does not come back at the level you lost it. For a period, you have to over-deliver on the exact dimension you failed on, and you have to make that over-delivery visible. After the settlement incident, we did not just fix the reconciliation check. We started sending affected merchants a short daily confirmation that their payouts had reconciled cleanly, with the actual figures, for about six weeks. Nobody asked for it. That was the point.

Was it slightly excessive? Yes. Did some merchants ignore the emails entirely? Also yes. But the two who had one foot out the door both mentioned those confirmations when they decided to stay. The over-correction is not really about the information you send. It is a costly signal that you are paying attention now in a way you demonstrably were not before. You can dial it back later, quietly, once the relationship has stabilized. You cannot skip it.

Trust is rebuilt in the gap between what you promised and what you actually did, measured over many small occasions, not one grand gesture.

Make the apology carry a mechanism

An apology without a change behind it is just noise, and experienced people discount it to zero. When I say sorry to a customer or to my own team, I try to attach the specific mechanism that makes the failure less likely to recur. Not a vague commitment to "do better," but a concrete change they can hold me to.

The difference sounds subtle but it is enormous in practice. Compare "we take reliability seriously and apologize for the inconvenience" with the version I actually used: we have added a hard gate so no settlement job can run if the reconciliation check has failed in the previous 24 hours, and we have removed the ability to deploy to that service after 2pm on a Friday. The second one gives the other party something real. It converts an emotional transaction into an accountability structure, and it lets them verify later whether you kept your word.

Repair internal trust before external

Here is the part leaders skip because it is uncomfortable: your team watched you fail too, and they watched how you handled it. If you throw an engineer under the bus in the customer post-mortem, you may buy back a sliver of external trust at the cost of every ounce of internal trust you had. I have seen a CTO name a junior engineer in a client call as the cause of an outage. He kept the client for another quarter. He lost two senior engineers within six weeks, and the team stopped surfacing problems early because surfacing problems had become dangerous.

The engineer who wrote the settlement bug was mortified. My job in that moment was not to reassure them it was fine, because it wasn't, but to make clear that the system failed, not just the person. A single individual should never be able to double-pay merchants without a check catching it. That framing is not soft, it is accurate, and it keeps people willing to tell you the truth. A team that hides failures from you will eventually hand you a much larger one.

Measure the rebuild, don't vibe it

You cannot manage a trust rebuild on feeling. Pick a small number of concrete signals and watch them over weeks, not days. The things I actually track after a trust hit:

• Support ticket sentiment and volume from the affected accounts, week over week
• Whether the customer starts routing more volume to us again, or holds flat
• How quickly my own team escalates problems now versus before the incident
• The recurrence rate of the specific failure class, not just the exact bug
• Renewal conversations that happen on time rather than being quietly delayed

None of these move overnight, and that is the honest, slightly deflating truth of it. The volume from that logistics merchant took nearly five months to return to where it had been. If I had been judging the recovery by whether the customer sounded friendly on calls, I would have declared victory in week three and stopped doing the work that actually mattered. Sentiment is a lagging, noisy signal. Behavior is the real one.

Don't keep relitigating the original sin

There is a failure mode on the other side of all this earnestness: apologizing forever. At some point the constant referencing of the incident becomes its own kind of self-indulgence, and it keeps the wound open for the very people you are trying to move past it. I have worked with a leader who opened every review for a year with a reference to one outage. The team was ready to move on long before he was.

Once the mechanisms are in place and the metrics have turned, let the incident recede. Rebuilt trust looks like normalcy, not perpetual penance. The goal is to get back to a state where the relationship is boring again, where the customer is not thinking about your reliability because they have no reason to. If you are still bringing it up months later, you have shifted from accountability to seeking absolution, and those are not the same thing.

Know when it is genuinely unrecoverable

Not every relationship comes back, and pretending otherwise wastes everyone's time. Some breaches, especially repeated ones, exhaust the other party's patience past the point of return. If you have already burned a customer once and you fail them the same way again, the honest move is often to help them exit cleanly rather than to launch another rebuild campaign they no longer believe in.

We lost one merchant permanently after that period, a payments reseller who had been burned by us twice on unrelated issues within a year. I did not fight it. I made sure their offboarding and final reconciliation were flawless, because how you handle the ending is also a reputation, and the payments world is smaller than people think. Two of their referrals later became customers, partly, I suspect, because we did not make the divorce ugly.

Conclusion

The thing nobody tells you about rebuilding trust is that you do not get to feel finished. There is no moment where the ledger balances and someone tells you the debt is cleared. One day you simply notice the customer has stopped watching you nervously, your team is surfacing bugs before they ship, and the incident has become a story you tell rather than a wound you nurse. If I could give my younger self one instruction, it would be this: assume every relationship you have is one careless Thursday deploy away from needing this playbook, and build the boring guardrails now, while nobody is angry with you yet. The rebuild is always more expensive than the prevention. I have paid for both, and I would take the guardrails every single time.