Dos límites de conversación del bot para amoCRM no funcionaban desde el lanzamiento: la culpa era de un AND en lugar de OR y de una rama defectuosa

Imagine la situación: los números aparecen en el panel de administración, el ajuste se guarda y la interfaz tiene el aspecto correcto. Pero, en realidad, no hace nada. Así fue como el 30 de septiembre se descubrió que ninguno de los dos límites de duración de las conversaciones funcionaba en el bot Octery y que, por lo visto, nunca había funcionado desde el principio.

Octery responde a los leads en los chats de amoCRM y transfiere la operación a un gestor. Hay dos límites. Max Messages determina cuántas respuestas dará el bot antes de llamar a una persona. Hard Stop Threshold define cuántos mensajes sin sentido consecutivos tolerará: "aaa", "test", "???" o incluso la salida de un bot ajeno. Cada mensaje de este tipo cuesta una llamada al modelo, así que no tiene sentido responder indefinidamente.

Dos errores que se ocultaban mutuamente

La decisión de transferir la conversación se tomaba después de la respuesta del modelo, dentro del pipeline de procesamiento. La condición se componía de tres comprobaciones unidas mediante AND. Según el significado de los ajustes, los límites son independientes: la transferencia debe producirse si se agota el contador de respuestas o si se acumula una serie de mensajes sin sentido. Con AND, el bot solo llamaba a un gestor cuando el cliente agotaba simultáneamente el límite de mensajes y escribía tonterías varias veces seguidas. Eso nunca ocurría.

El segundo error estaba en la rama que debía ejecutarse cuando se cumplía la condición. Esta sustituía la respuesta por "transfiriendo a un gestor" y establecía la intención manager. Sin embargo, los valores terminaban en campos cuyos nombres habían sido sustituidos por expresiones: el valor se insertaba en el campo del nombre y permanecía allí. Además, el envío de la respuesta y el registro leían los datos directamente del análisis de la respuesta del modelo, no de esa rama. Aunque alguien hubiera cambiado AND por OR, el cliente habría recibido una respuesta normal y los registros no habrían mostrado rastro alguno.

Una primera ejecución manual habría detectado cualquiera de los errores por separado. Juntos hicieron invisibles los límites.

Por qué nadie lo advirtió

La lógica residía en la configuración del pipeline, no en el código. No se puede escribir una prueba unitaria para esa configuración, ejecutarla en CI ni revisar el cambio como un diff legible: en una revisión solo parece que alguien "corrigió la condición". Llevar manualmente una conversación real hasta el límite requiere tiempo, por lo que las comprobaciones habituales nunca llegaban hasta allí. La pregunta "¿funcionan los límites?" no tenía una respuesta ni positiva ni negativa.

Qué se hizo

La decisión se trasladó a la API como una función pura independiente. El pipeline le pasa la respuesta del modelo y dos contadores del estado de la conversación, mientras que la propia función obtiene los límites de los ajustes de la empresa, de modo que quien la invoca no puede introducir otros valores. La salida es una única decisión final: texto, intención y motivo de la transferencia. Todos los pasos posteriores leen exclusivamente ese resultado.

Las fórmulas contienen dos trampas de desfase de una unidad. El contador de respuestas se calcula antes del mensaje actual: el bot da exactamente max_messages respuestas y después transfiere la conversación. La serie de mensajes sin sentido incluye el mensaje actual, tal como indica la ayuda de la interfaz. Si se activan ambas condiciones, se registra el límite de mensajes como motivo. Si la plantilla de la frase está vacía, se envía la frase predeterminada. También se eliminó un efecto secundario: la rama anterior clasificaba el mensaje como "sin sentido" y distorsionaba las analíticas.

Pruebas derivadas de la especificación

Primero se describió el comportamiento mediante escenarios y después cada uno se convirtió en una prueba, 16 en total. Los nombres hablan por sí solos: "hands off on the Nth non-meaningful message in a row, counting the current one" y "a meaningful message breaks the non-meaningful streak". La prueba "old AND case" se conservó deliberadamente: el único caso en el que la condición anterior llegaba a activarse ahora es un caso particular del nuevo comportamiento.

Riesgo del despliegue y conclusión

El principal riesgo no es técnico. Las empresas con límites bajos verán por primera vez cómo el bot deja de responder y llama a un gestor. Para ellas parecerá una función nueva, no una corrección. Por eso se les avisará antes de activarla, como un punto separado del plan de despliegue.

La conclusión práctica para los equipos que trabajan con pipelines no-code y low-code es sencilla: si una cifra es visible para el cliente en la interfaz, su comportamiento debe contar con una prueba automatizada, y el nombre de la prueba debe expresar la promesa hecha al cliente. Es preferible sacar de la configuración y trasladar al código la lógica de negocio de la que dependen los ingresos y la transferencia de un cliente a una persona, para poder leerla en un diff y ejecutarla en CI.