Lo que un CRM para WhatsApp no te dice hasta que ya lo montaste

Elegir CRM para WhatsApp se parece a comparar teléfonos: todos muestran la misma lista de funciones y ninguna te dice cómo se comporta el aparato al tercer mes. Los tres problemas que siguen no salen en ninguna demo, aparecen con el sistema ya cargado de contactos reales, y ninguno de los tres da un mensaje de error.

1. Dar de baja del boletín puede dejarte mudo por WhatsApp

Casi todos los CRM tienen un interruptor de "no contactar". Lo que suele estar mal explicado es que hay dos, y se parecen mucho.

Uno es global: apaga correo, SMS, llamada y WhatsApp de una sola vez. El otro es por canal: apaga solo el que le digas.

En agosto encontramos una sincronización de bajas —de la plataforma de correos hacia el CRM— que estaba usando el global. El efecto: cualquier persona que se diera de baja del boletín habría dejado de recibir también los mensajes de WhatsApp, y el bot se habría quedado mudo con ella. Sin error, sin log, sin nada que lo delatara.

No alcanzó a pasarle a ningún contacto real porque todavía no había bajas. Lo comprobamos contra la API con un contacto propio y lo revertimos: marcar solo el correo devuelve 200, se guarda, y el interruptor general sigue apagado.

Dos trampas al escribir eso, si alguien lo automatiza:

• La configuración por canal se manda completa. Enviar solo la clave del correo borra el estado de los demás.
• Para decidir si alguien puede recibir un mensaje hay que mirar las dos: el interruptor global y el del canal. Mirar una sola deja gente dentro de la lista por error.

La baja de un boletín es del boletín, no de la relación.

2. El cliente que ya compró sigue recibiendo el seguimiento

Este es más común de lo que parece y da vergüenza cuando pasa.

Marcamos una oportunidad como ganada y asumimos que el contacto sale de las cadenas de seguimiento. No sale. El CRM no infiere nada del estado de la oportunidad: cada flujo sigue su cadena hasta el final.

Lo medimos en una simulación de venta completa. Un día después de quedar como ganado, el comprador seguía con el flujo de "no agendó" activo, además de otros dos. O sea: alguien que ya pagó iba a recibir durante semanas mensajes pidiéndole que agende.

El arreglo es un paso explícito de "sacar de estos flujos" al final del flujo que cierra. No lo cubre nadie más: ni el estado de la oportunidad, ni el puente de mensajería.

Y hay un detalle incómodo para verificarlo: no encontramos ningún endpoint que devuelva en qué flujos está enrolado un contacto. Probamos cuatro variantes y todas dieron 404. Se ve únicamente en la ficha del contacto, en la pestaña de acciones, donde aparecen los flujos activos y los pasados. Sirve como prueba por efecto: antes del arreglo, el flujo estaba entre los activos; después, entre los pasados.

Si tienes cadenas de nurture andando, esta es la revisión de esta semana. Un lead que compró —o que el bot descartó— recibiendo "venga a la sala" durante un año es el tipo de daño que no da error en ninguna parte.

3. El tablero puede estar vacío con tráfico real

El tercero duele distinto, porque no rompe la operación: rompe la promesa.

Un cliente con conversaciones del mismo día, ventana de treinta días, y el widget de tiempo medio de respuesta decía "no se han encontrado datos".

La primera explicación parecía obvia. Los mensajes entrantes llegaban etiquetados como WhatsApp y los salientes como proveedor personalizado, porque un puente propio tiene que mandar la salida de esa forma para que el CRM no la marque como fallida. Con cada dirección en un canal distinto, no hay par que emparejar.

Encajaba tan bien que la dimos por buena. Y no se sostuvo. Registramos a mano un par entrante más saliente por el mismo canal, los dos aceptados con 201 y con cuatro segundos de diferencia, y el widget siguió sin datos. La asimetría existe y es real, pero no era la causa.

Lo dejamos escrito así, sin cerrar, porque es más útil que una explicación bonita: quedan como hipótesis que la métrica se agregue por lotes, o que solo cuente respuestas de un usuario humano en canales nativos.

Lo caro no es el gráfico. Si el contrato promete un tiempo de respuesta "medido en el tablero del cliente", esa promesa no se puede probar aunque el sistema cumpla de sobra. Eso se revisa al montar el tablero, no al firmar.

Del mismo día salió otro hallazgo hermano: el gráfico de contactos por fuente agrupa por la atribución del contacto, no por el campo de texto libre que uno rellena. Un sistema que crea contactos por API sin atribución deja ese gráfico vacío para siempre.

Qué preguntar antes de firmar

Tres preguntas que cambian la decisión:

1. ¿El "no contactar" es por canal o apaga todo? Y si es por canal, ¿la integración de correos lo respeta?
2. ¿Cerrar una venta saca al contacto de los seguimientos, o hay que hacerlo a mano en cada flujo?
3. ¿Las métricas del tablero se pueden reproducir, o solo se ven bonitas en la demo?

Ninguna se responde leyendo la página de precios. Se responden montando una simulación completa —un lead que entra, conversa, compra y se cierra— y mirando qué quedó encendido después.

Escribimos aparte cómo se ve un embudo de ventas por WhatsApp que sí está encendido. Y si prefieres saltarte los tres tropiezos, así montamos un CRM para WhatsApp.