Restoring trust takes far more successes than the failures that caused the damage

What it is

One wrong entity type on a filing, and handover drops. Getting back to handover from before the drop takes not one “filed right,” but a run of them — fifteen clean filings is not rare. Restoring trust takes far more successes than the failures that caused the damage.

This is a count. The collapse entry says recovery is slower than building; that is a clock. Unit-asymmetric update is step size. Here the step sizes are summed into “how many times to get back to where it was.”

Why it happens

The downward step is large, the upward step small; returning to the origin takes many ups. Failure may also switch sampling off: people stop handing over, successes cannot accumulate, the count stretches further. So “far more” has two layers: the arithmetic of the step ratio, plus sampling slowing. If after a failure the product has no still-observable low-stakes success path, the count can stop at never enough.

This agrees with “trust is formed from experience”: a statement that “we have fixed it” does not count as one success. Success has to be a completion the user saw, on the same task. Muir’s update does not eat a press release.

Studying it

After one moderate failure, give observable successes one by one, and find the n at which handover returns to the pre-failure level. Independent variables: band of the failure, whether successes are same task and same band, whether a low-stakes path stays open after the failure. Dependent variables: n, rate of dropout that makes n unreachable.

n will be larger for higher-stakes failures. Report by band; do not give one universal multiple.

Where it stops holding

When the failure is recalled at once and the user barely took a consequence, n can approach 1. After collapse people have already withdrawn; the count has not started; what has to be solved first is opening sampling again, which is a temporal process. Showing typical failures to press overtrust is deliberately adding negative samples, not talking about a recovery count. n after an early failure is usually larger, because the first portrait has to be overturned as well.

Applying it

• What you plan after a failure is not one “we have fixed it,” but a same-task path on which the user can see successes in a row. Operate to the n you have measured, not to a comms calendar.
• Keep a low-stakes channel so success counts have somewhere to accumulate. Automation off and no manually visible hits, and n cannot start.
• Do not push people to turn a high-stakes switch back on at success 2 or 3. The count is not there yet.
• Check: after an incident, track at which same-task success handover returns to baseline. If the rating is back the day the statement goes out, and behaviour waits until the tenth-odd, the product is spending politeness as if the count were done.

Related

• Same group: L5.10.1 One failure weakens trust more than one success strengthens it · L5.10.2 Users generalise a failure in one domain to the system's whole capability · L5.10.3 An early failure weighs more than an equivalent late one, because there is no success history to offset it · L5.10.4 How a failure is handled can partly offset the damage; admitting the error beats downplaying it
• Nearby: L5.04 Collapse of Trust · L5.09 Overtrust and Trust Collapse · L5.03 Trust Calibration
• Search terms: trust recovery count · more successes than failures · asymmetric repair