Los portales de terceros cambian. Se mueven labels. Desaparecen botones. Un flujo que el lunes funcionaba el martes falla sin changelog para ti. Si tu producto solo aguanta el happy path, ese martes no es anécdota de ops. Es un veredicto de producto. Lo aprendí automatizando sobre portales de seguridad social y contratación en Colombia — el mismo piso que después marcó ECORPA. Esto no es un how-to de afiliaciones. Es qué debe absorber el producto cuando la pantalla es de otro.

El martes en que la pantalla cambió

No necesitas el nombre de la entidad. Necesitas la escena: un camino rutinario que el equipo corría cada día, un selector que se movió, una confirmación que dejó de aparecer, y una fila de gente esperando mientras alguien reaprendía el portal a mano. El primer impulso es llamarlo drama. No es drama. Es el entorno. Tu trabajo es decidir qué se rompe en público, qué falla cerrado y qué nunca prometiste.

Tres reacciones que se sienten bien y envejecen mal

Parche rápido y olvido. Restauras la demo. No restauras confianza. El próximo cambio pega en el mismo punto blando. Fingir que no pasó. Marketing sigue diciendo "set and forget". Los operadores saben que no. Esa brecha se vuelve tu marca. Redibujar el contrato. Tratas el portal como dependencia inestable. Aislas adapters, haces el fallo visible y dejas de vender permanencia que no controlas. Solo la tercera reacción compone.

Qué debe absorber el producto vs el operador

El producto debe absorber: volver a ubicar el paso correcto, traducir un intent conocido a la forma actual de UI o API, y fallar con una razón clara cuando no puede. El operador debe absorber: juicios que el sistema no puede poseer — excepciones, documentos borde, visto bueno humano. Si automatizas el juicio para lucir inteligente en una demo, creas respuestas silenciosamente incorrectas. Eso es peor que un stop visible.

Blast radius

Una integración rota no puede tumbar todo el flujo. Si un solo cambio de portal congela afiliaciones, consultas y validación documental juntas, no construiste un sistema. Construiste un único punto frágil con UI bonita. Decisión de ship que sigo usando: no shippeamos un camino "fully automatic" para un paso cuya dependencia externa cambia sin aviso, salvo que el fallo sea ruidoso, acotado y recuperable sin reescribir el resto del producto. Esa regla mató features que se veían geniales en un deck. Van al 99% del cajón.

Señal de salud después del cambio

La métrica útil no es "¿parcheamos?". Es: ¿cuánto tarda el sistema en volver a ser confiable para quien depende de él — y cuántos otros flujos siguieron arriba mientras arreglábamos este? Si la recuperación siempre es una sesión heroica y una fila silenciosa, el producto todavía vende el happy path.

Qué significa en el caso ECORPA

ECORPA tiene que ser honesta con portales que no posee. El sitio personal es donde escribo la lección de diseño. El sitio de la empresa es donde vive la promesa de producto. Superficies distintas, misma alergia al teatro — más sobre ese corte en por qué tools va aparte de ECORPA. Si automatizas encima de la UI de otro, escribe qué vas a absorber, qué nunca vas a prometer y qué observación te haría des-shippear el claim de happy path. Luego construye para el martes.