Trust recovers far more slowly than it is built

What it is

A private mail is sent by the assistant to the wrong person. After auto-send is switched off, even three weeks of every message going right does not get the switch turned back on. Getting to “willing to use” may take a few easy days; getting to “willing to use again” takes much longer. Trust recovers far more slowly than it is built: the two time curves are asymmetric; repair is dearer than construction.

What is slow is the temporal process, not the counting problem of “how many successes to offset one failure.” Counting is another layer.

Why it happens

While trust is being built, people collect evidence that it can, still watching by default, with small risk. After collapse, people collect evidence that it will not harm them again, already withdrawn by default; each new handover is a willing assumption of a known injury. Sampling slows: not using it means not seeing successes, not seeing successes means harder recovery — a negative loop.

Memory leans too. The injury’s plot, blame, and spread (colleagues were told) is re-extracted; everyday correctness sinks. Muir described trust rising and falling with experience; collapse rewrites the weights of experience as “prove safety first,” and the observation window that proof needs is longer than the window the original trial needed.

Studying it

After a collapse event, measure willingness to hand over and actual switch state by day or week, against a curve of building from zero with no collapse. Independent variables: whether a short window of low-stakes success is forced after collapse, length of the observation window, whether the system can still be seen working for others. Dependent variables: days to return to pre-collapse handover, dropout along the way.

Split “the rating came back” from “the switch went back on.” Ratings can return politely in days; behaviour often does not.

Where it stops holding

Low-stakes failures that can be undone in one click can recover fast, and this time gap narrows. If the user has no alternative path, they may keep using it in a state of distrust — it looks like recovery, it is being locked in. New users have not collapsed; there is no recovery curve. Do not fold “admitting the error offsets some of the damage” into this entry’s clock — that is handling, not time.

Applying it

• After collapse, do not push people to turn a high-stakes switch back on with a one-shot “we have fixed it.” First give an observable, low-stakes success window so sampling can start again.
• Keep a manual path, so people who do not trust are not locked inside the system pretending to recover.
• Operate recovery as a process measured in weeks: review switch state, not whether an apology was sent.
• Check: after an incident, log how many people still have automation off, and for how many days. If three days after the statement the rating is back and the switch has not moved, recovery has not happened — only politeness.

Related

• Same group: L5.04.1 A single severe error can destroy long-built trust · L5.04.3 How an error is handled affects trust more than the error itself
• Nearby: L5.10 Asymmetric Effect of First Failures on Trust · L5.09 Overtrust and Trust Collapse · L5.03 Trust Calibration
• Search terms: slow trust recovery · trust repair · rebuilding trust