Cuando algo se rompe en un pipeline de contratación o staffing, el incidente tiene dos relojes. El primero es técnico: tiempo a detectar, tiempo a recuperar. El segundo es humano: cuánto pasa hasta que operadores y clientes dejan de doble-chequear cada paso a mano. A ese segundo reloj le digo latencia de confianza.

El outage termina. La duda no.

Puedes restaurar un portal, un webhook o un job en lote y igual perder una semana de velocidad. La gente reabre el mismo ticket “por si acaso”. Screenshot de cada confirmación. Ping a un humano que ya dijo que sí. Nada de eso aparece en dashboards de uptime. Todo aparece en throughput. En Cuando el portal se mueve, qué debe absorber el producto la lección era el cambio externo. La latencia de confianza es la secuela interna: aunque la dependencia ya esté estable, el hábito de desconfiar se queda hasta que das una razón concreta para soltarlo.

Qué sí acorta la latencia de confianza

Tres movimientos que de verdad ayudan:

1. Fallar ruidoso, recuperar ruidoso. El “tal vez funcionó” silencioso es veneno. Los operadores necesitan un fallo claro y una recuperación clara — en el mismo lugar donde ya miran.
2. Mostrar el recibo. Después del arreglo, saca a la superficie la evidencia que importa para el trabajo (último sync ok, último ID validado, último conteo de lote), no un “all systems green” vago.
3. Achicar el blast radius de la próxima duda. Si una dependencia mala congela todo, cada incidente entrena a asumir que toda la cadena es blanda. Limita interdependencias como la automatización falsificable limita claims que no puedes matar.

Qué no la acorta

Status pages pensadas para ingenieros. Posts de “nos tomamos en serio la confiabilidad”. Pedir que “confíen en el proceso” mientras la UI se ve idéntica al día en que mintió. La confianza no es un feeling que pides. Es un comportamiento que la gente abandona cuando el costo de equivocarse otra vez es alto. Tu trabajo es bajar ese costo con evidencia en el flujo, no con tono en un hilo.

El ángulo de producto para ECORPA

ECORPA vive entre equipos y portales de gobierno/aseguradoras que se mueven sin pedir permiso. Los incidentes no son fracaso moral; son input de diseño. El producto que gana después de un corte no es el que nunca falla. Es el que hace la hora siguiente más segura que la hora anterior al corte — menos saltos de contexto, verify/retry más claro, menos teatro. Si solo mides recovery time, vas a celebrar un deploy verde mientras la latencia de confianza se come la semana. Mide los dos relojes. Shippea para el más lento.