Un chatbot que atiende WhatsApp y guarda clientes en el CRM parece una sola cosa, pero por dentro son varios servicios encadenados, y cualquiera puede fallar un sábado de noche. Esta guía explica dónde se corta la cadena, qué respaldar, cómo comprobar que el respaldo sirve y qué preguntarle al proveedor.
Dónde se puede cortar la cadena
Cuando una pyme dice «se cayó el bot», casi siempre falló una de estas piezas:
- La API de WhatsApp. Meta recibe los mensajes del cliente y los reenvía a tu servidor mediante webhooks. Si tu servidor no responde, según su documentación de webhooks Meta reintenta enseguida y luego algunas veces más, con menor frecuencia, durante las siguientes 36 horas. Si lo que falla es Meta, lo confirmas en su página oficial de estado de WhatsApp Business API.
- El servidor donde corre la automatización (n8n u otra herramienta similar). Suele ser una sola máquina: si se apaga, los flujos dejan de ejecutarse y los mensajes quedan sin respuesta.
- La API del CRM (HubSpot, Pipedrive, Notion, una planilla). Si no responde, el bot conversa igual, pero el lead no queda registrado. HubSpot, por ejemplo, publica sus incidentes en status.hubspot.com.
Una caída de Meta o del CRM no la arreglas tú: la esperas y la amortiguas. Una caída de tu servidor sí es tuya, y ahí el respaldo decide cuánto pierdes.
Qué respaldar y cada cuánto
En una instalación de n8n, la propia documentación oficial de respaldo y restauración indica que una copia completa incluye la carpeta de usuario .n8n (con el archivo de configuración, la clave de cifrado de credenciales y, si usas SQLite por defecto, la base de datos) más la base de datos externa, si configuraste una. Lo que más se olvida es la clave de cifrado: sin ella, las credenciales respaldadas no se pueden restaurar. Para exportar flujos en archivos legibles existe el comando n8n export:workflow --backup y su equivalente para credenciales, descritos en la referencia de comandos de n8n.
Traducido a una lista para una pyme:
- Flujos de automatización: cada vez que alguien los modifique, y además una copia automática diaria.
- Credenciales y clave de cifrado: aparte, en un gestor de contraseñas, nunca en el mismo disco del servidor.
- Base de datos del bot: diaria; cada pocas horas si agenda citas o guarda cotizaciones.
- Configuración del servidor: variables de entorno, archivo de Docker, dominios y certificados. Cambia poco, pero sin ella reinstalar tarda horas.
- Acceso a la cuenta de Meta Business: en manos de la empresa, no solo del proveedor.
Una copia que vive en el mismo servidor no es un respaldo: si se pierde el disco, se pierde todo junto. Debe salir a otro lugar, como un almacenamiento en la nube o un segundo servidor.
Cómo probar que la recuperación funciona
Un respaldo que nunca se restauró es solo una promesa. La prueba honesta es sencilla: levanta un servidor limpio, restaura la copia y verifica que el bot responde a un mensaje de prueba y que ese lead llega al CRM. Anota cuánto demoró y qué faltó. Lo habitual es descubrir que faltaba la clave de cifrado, que un token había vencido o que el dominio apuntaba a la máquina vieja; mejor verlo en un ensayo que en una caída real.
Repite el ensayo al menos cada semestre y cada vez que cambies de proveedor o servidor. Si nadie puede hacerlo, ese ya es el dato más importante.
Amortiguar mientras el servicio vuelve
Mientras el servidor vuelve, el cliente sigue escribiendo. Tres medidas reducen el daño:
- Mensaje de ausencia en WhatsApp Business con un teléfono o correo alternativo.
- Plan B para el CRM: si la API del CRM falla, el lead se envía por correo al equipo o se guarda en una cola para reintentar, como explicamos en la guía para integrar el chatbot con HubSpot, Pipedrive o Notion.
- Un responsable con acceso al panel de Meta, al servidor y al CRM, sin depender de una sola persona externa.
Qué preguntarle al proveedor: RTO y RPO en palabras simples
Dos siglas resumen el tema y vale la pena pedirlas por escrito. El RTO (tiempo objetivo de recuperación) responde «¿cuánto puede estar caído el bot?». El RPO (punto objetivo de recuperación) responde «¿cuántas horas de datos puedo perder?»: con respaldo diario, hasta un día. Son conceptos definidos en guías públicas de continuidad como la NIST SP 800-34, y no hace falta ser técnico para usarlos: fija cuánto tiempo y cuántos datos tu negocio tolera perder, y pídele al proveedor que lo cumpla.
Para una pyme con chatbot, respaldos, ensayos de restauración y responsables definidos forman, en el fondo, un plan de recuperación ante desastres a escala pequeña. Basta una página con qué se respalda, dónde, cada cuánto, quién restaura y cuánto debería demorar.
Preguntas concretas para quien opera tu bot:
- ¿Dónde corre el bot, quién tiene acceso y qué se respalda, cada cuánto y en qué lugar?
- ¿Cuándo restauraron un respaldo por última vez y cuánto demoró?
- ¿Qué pasa con los mensajes que llegan mientras el bot está caído?
- Si terminamos el contrato, ¿me entregan flujos, credenciales y acceso a la cuenta de WhatsApp?
Si varias respuestas son vagas, revisa también las banderas rojas al elegir una agencia de chatbot. La continuidad no se compra una vez: se revisa cada cierto tiempo, como el extintor de la oficina.