Realiza un simulacro de caída: encuentra la herramienta de terceros que puede arruinar la primera experiencia de tu cliente

Imagina esto: tu primer cliente hace clic en el enlace de incorporación que enviaste y no pasa nada. No porque tu idea sea débil. No porque tu propuesta no fuera acertada. Sino porque la herramienta que lleva el enlace, la agenda, el archivo o el inicio de sesión está caída. Ese es el tipo de fallo que hace que una startup de dos personas sienta que funciona sobre un hilo frágil.

No necesitas un plan de desastre para cada posible fallo. Necesitas un pequeño simulacro: encuentra la única herramienta de terceros que puede romper la primera experiencia de tu cliente, prueba qué pasa cuando falla y escribe el plan de contingencia antes de que la caída te sorprenda.

La dependencia que puedes ver

La mayoría de las startups tempranas no se construyen sobre un stack. Se construyen sobre un puñado de herramientas que hacen el trabajo silencioso: correo electrónico, programación, formularios, intercambio de archivos, gestores de contraseñas, enlaces de pago, una app SaaS que no elegiste pero en la que ahora confías. Cada una es una dependencia de terceros. Algunas son deseables. Algunas pocas son estructurales.

Una gran caída hace evidente esa distinción. Microsoft confirmó una caída generalizada y de varias horas en Outlook/Exchange Online que provocó retrasos, fallos y problemas de autenticación en el correo electrónico. Microsoft dijo que identificó un problema en un componente de autenticación y estaba probando una estrategia de remediación en parte de su infraestructura. La interrupción no se limitó a Outlook o Exchange Online; la página de estado de Microsoft listó una degradación más amplia del servicio Microsoft 365.

Esa es la parte que los fundadores subestiman. Cuando un servicio se tambalea, el flujo de trabajo orientado al cliente puede tambalearse con él. Downdetector registró un aumento brusco en los informes de problemas de Outlook durante la caída. Los usuarios reportaron impactos prácticos, incluidos fallos de inicio de sesión, correos faltantes y archivos inaccesibles. Si tu primer cliente está esperando un enlace, una invitación o un documento, esos no son problemas abstractos. Son el momento en que tu startup parece poco confiable.

Al final de la información, Microsoft dijo que la conectividad de las bandejas de entrada había vuelto a la normalidad, pero que la búsqueda y las colas de correo atrasadas podrían seguir afectadas. Incluso cuando el titular dice «arreglado», el cliente puede seguir atascado. Por eso un plan de contingencia ante caídas no se trata de demostrar que la herramienta es perfecta. Se trata de saber qué harás cuando no lo sea.

Realiza el simulacro antes de la próxima incorporación

Haz esto antes de tu próxima incorporación de cliente, no después de la primera queja. Pon un temporizador para un bloque corto. Ten a mano un cuaderno, un navegador y a la persona que realmente se encarga de la configuración del cliente. No estás redactando una política. Estás haciendo un pequeño mapa de dónde puede romperse el flujo de trabajo de tu primer cliente.

1. Lista cada dependencia orientada al cliente. Anota todo lo que un cliente toca o espera: enlaces de correo electrónico, invitaciones de calendario, formularios, carpetas de archivos, flujos de restablecimiento de contraseña, páginas de pago, bandejas de soporte, páginas de estado, la herramienta SaaS que almacena la lista de verificación de incorporación.
2. Marca lo crítico frente a lo deseable. Pregúntate: si esta herramienta falla durante unas horas, ¿puede el cliente completar el primer paso? Si sí, es deseable. Si no, es crítica. Una invitación de calendario puede ser crítica si es la única forma en que el cliente agenda una llamada. Una carpeta compartida puede ser crítica si contiene el contrato o el primer entregable.
3. Define el plan de contingencia. Para cada dependencia crítica, escribe un plan de contingencia en lenguaje sencillo. «Envía un correo sencillo con el enlace y pídele que responda.» «Usa un enlace de calendario de respaldo.» «Envía el archivo desde una unidad personal.» «Mueve la llamada a un número de teléfono.» El plan de contingencia debe ser aburrido, rápido y posible bajo estrés.
4. Asigna un responsable. Una persona es responsable del simulacro. Una persona es responsable del plan de contingencia. En una startup de dos personas, suele ser tú o el otro fundador, pero debe ser un nombre, no «el equipo».
5. Establece una fecha de prueba. Elige una fecha antes de la próxima incorporación. En esa fecha, simula el fallo. No te limites a imaginarlo. Desactiva la herramienta, bloquea el enlace o usa una cuenta de prueba que no pueda iniciar sesión. Observa qué le pasa al recorrido del cliente.

La prueba debe ser lo suficientemente pequeña como para que puedas terminarla en una tarde. No intentas romper toda la empresa. Intentas encontrar el lugar donde un cliente se atasca y nadie sabe qué decir.

El plan de contingencia que retiene a un cliente

El mejor plan de contingencia no es un sistema de respaldo sofisticado. Es un mensaje que puedes enviar rápidamente. Debe decir, en términos humanos, que algo no funciona, qué estás haciendo al respecto y qué debe hacer el cliente a continuación. No escondas el problema. No pretendas que el retraso es culpa del cliente. No envíes una nota genérica de «estamos al tanto» que lo deje colgando.

Un buen mensaje de contingencia tiene tres partes:

• Qué está fallando. «El enlace del calendario no carga.»
• Qué estás haciendo. «Estamos pasando a un enlace de respaldo.»
• Qué debe hacer el cliente. «Responde a este correo y te enviaré una nueva invitación.»

Guarda ese mensaje en una nota que puedas encontrar. Guarda el enlace de respaldo en el mismo lugar. Guarda el número de teléfono del responsable en el mismo lugar. Cuando ocurra la caída, no estarás calmado. Estarás respondiendo a un cliente, revisando una página de estado e intentando recordar dónde está el archivo. El simulacro no se trata de evitar el pánico. Se trata de hacer evidente el siguiente paso.

Después de la prueba, anota lo que aprendiste. ¿El plan de contingencia era demasiado lento? ¿El recorrido del cliente dependía de un inicio de sesión que no se podía recuperar? ¿El responsable no sabía dónde estaba el enlace de respaldo? Corrige una cosa. Luego establece la próxima fecha de prueba. Una startup de dos personas no necesita un departamento de confiabilidad. Necesita un hábito: antes de que un nuevo cliente entre en el flujo de trabajo, pregunta qué pasa cuando la herramienta desaparece.

Ese es todo el punto. Tu primer cliente no necesita un stack perfecto. Necesita un equipo que pueda seguir avanzando cuando el stack tropiece. Realiza el simulacro. Encuentra el hilo frágil. Córtalo en la prueba, no en la conversación en vivo.