Retención dentro de la ventana de 48 horas
El problema
Las cancelaciones se registran, se recopilan y solo se procesan más tarde. Los procesos batch, ETL o las listas manuales generan latencia. Los agentes suelen recibir los registros horas después del evento, mientras que la priorización se realiza demasiado tarde o manualmente. Como resultado, las ventanas críticas de procesamiento se reducen o se pierden por completo. La causa principal reside en la arquitectura de los sistemas: muchos sistemas heredados están optimizados para la consistencia y el almacenamiento de datos, no para la ejecución en tiempo real.
La solución
El procesamiento se realiza en tiempo real y de forma basada en eventos. Los registros se importan, priorizan y enrutan automáticamente de forma determinista hacia colas operativas. Las ventanas de 48 horas se representan mediante TTL dentro de etapas de campaña definidas. Si un registro alcanza este límite sin completarse, se activa una transición basada en reglas hacia la siguiente etapa de la campaña, incluyendo métricas predefinidas. Esto garantiza que el procesamiento sea transparente, coherente y gestionado conforme a los SLA.
Entrevista: Retención en una empresa energética
Una conversación entre un Operations Manager (J) y Dialfire (SA).
J (Empresa energética:)
“Nuestro problema principal era la inconsistencia entre el ERP y el escritorio del agente. La cancelación estaba en el sistema, pero la logística de datos detrás de ella era lenta. Procesos ETL, trabajos batch, exportaciones manuales. Para cuando un lead aparecía priorizado en la cola outbound, a menudo ya habían pasado entre seis y diez horas. En la práctica, trabajábamos contra nuestra propia TI y contra la ventana de 48 horas.”
SA (Dialfire:)
“Ese es un problema clásico de arquitectura. Los sistemas ERP y CRM están optimizados para el almacenamiento de datos, no para ejecuciones críticas en tiempo. Nosotros posicionamos Dialfire como un hub orquestado entre ambos. En lugar de esperar el siguiente ciclo ETL, el ERP desencadena un evento. El registro se transfiere directamente al motor de taskflow mediante webhook. La respuesta de la API es inmediata, sin persistencia intermedia en listas o archivos.”
J (Empresa energética:)
“Internamente, esto fue bastante controvertido. El departamento de TI era escéptico respecto a colocar otro sistema más entre el ERP y los agentes o equipos. La preocupación era añadir complejidad y nuevas fuentes potenciales de errores.”
SA (Dialfire:)
“Conocemos bien esa discusión. Técnicamente, reducimos la complejidad porque eliminamos la lógica batch y las transferencias manuales. Dialfire es stateless en el routing, y cada registro se procesa exactamente una vez. Al mismo tiempo, métricas como estado, detalles de estado, TTL y reglas de transición pueden definirse libremente dentro del taskflow. Esto hace que el flujo de datos sea transparente, flexible y trazable, en lugar de frágil.”
J (Empresa energética:)
“Un verdadero cuello de botella para nosotros era la priorización. Antes, todo se ejecutaba cronológicamente. Un cliente con cancelación y alto valor contractual terminaba en la misma cola que un proceso puramente administrativo. El agente debía decidir qué era más importante, bajo presión de tiempo y alto volumen. Eso simplemente no funcionaba.”
SA (Dialfire:)
“La priorización pertenece al sistema, no a la cabeza del agente. En el taskflow asignamos una priorización dinámica de llamadas, por ejemplo mediante $call_order. Esta se basa en SLA, motivo de cancelación, valor contractual o historial. Los leads nuevos y críticos pasan al inicio de la cola. Paralelamente, establecemos un TTL (Time-to-Live) de 48 horas. Después de 48 horas sin cierre, el registro no se cierra automáticamente. Las 48 horas simplemente definen la duración dentro de una etapa de campaña.
Por ejemplo: se recibe una cancelación, el cliente se identifica como recuperable y se transfiere a Dialfire mediante interfaz. Allí comienza en la etapa de importación (TTL de 48h) y posteriormente pasa a la etapa de llamadas para ser gestionado por equipos inbound o agentes individuales. Si no se produce un cierre, el registro avanza de forma determinista hacia la siguiente tarea, por ejemplo un webhook de regreso al sistema.”
J (Empresa energética:)
“Eso tuvo un impacto medible. Nuestro time-to-first-call disminuyó significativamente y por primera vez podemos ver claramente qué leads siguen dentro del SLA. Antes, los agentes invertían tiempo en registros que, en la práctica, ya no tenían valor.”
SA (Dialfire:)
“Ese es exactamente el objetivo: concentrar el tiempo neto de trabajo en contactos convertibles. Lo que ocurre dentro del taskflow es completamente configurable y sigue la lógica del proceso correspondiente. Las etapas de campaña pueden ajustarse dinámicamente: prioridades, transiciones y reglas de procesamiento no son estáticas, sino controlables. Así se garantiza que ningún lead permanezca en un estado indefinido.”
J (Empresa energética:)
“Otro punto crítico eran los fines de semana. Las cancelaciones realizadas el viernes por la noche seguían en el sistema el lunes, pero ya fuera de cualquier ventana útil. Nadie tenía una visión clara de qué seguía siendo aprovechable.”
SA (Dialfire:)
“Esa es la consecuencia de procesos rígidos. En el taskflow, en cambio, métricas como estado y detalle de estado pueden definirse y vincularse con reglas claras de retraso. Para cada etapa de campaña puede especificarse después de cuánto tiempo se produce la transición a la siguiente etapa, por ejemplo después de 4 horas, 48 horas o 365 días. Durante la transición, el registro recibe exactamente el estado o detalle de estado definido en la lógica. De esta forma, el flujo permanece basado en reglas y transparente, independientemente del día de la semana o del momento de procesamiento.”
J (Empresa energética):
“La escalabilidad también era crítica para nosotros. Con altos volúmenes, antes sufríamos cuellos de botella, retrasos en procesos batch y, en el peor de los casos, llamadas duplicadas de distintos equipos. Eso era costoso y generaba discusiones internas.”
SA (Dialfire:)
“El routing está basado en eventos y escala horizontalmente. Procesamos varios miles de eventos por minuto. Cada registro se enruta de forma única y queda completamente registrado. El procesamiento duplicado queda excluido a nivel de sistema, independientemente del volumen.”
J (Empresa energética:)
“Más adelante incluso ampliamos el concepto más allá de la retención clásica de cancelaciones. La clave aquí son las señales de intención desde el frontend.”
SA (Dialfire:)
“Por ejemplo, el IP tracking en B2B: cuando Leadinfo reconoce a un cliente existente en la página de tarifas, eso constituye una señal clara de alta intención. Este trigger se envía directamente a Dialfire mediante webhook y se incorpora inmediatamente al taskflow sin retrasos. Allí, el estado actual determina qué tarea se ejecuta a continuación, y el lead se enruta específicamente hacia agentes o equipos disponibles, incluyendo el contexto. Operativamente, esto se parece más a una gestión inbound proactiva que al outbound clásico.”
J (Empresa energética):
“La mayor ventaja operativa para nosotros fue que no tuvimos que reconstruir nuestros sistemas centrales. El ERP sigue siendo pesado, pero estable. Dialfire actúa como una capa flexible de procesamiento casi en tiempo real: cada registro tiene un estado que determina lo que sucede a continuación. Después se entrega a la siguiente tarea, que a su vez determina el flujo posterior según el estado y la lógica. La arquitectura puede procesar cantidades extremadamente grandes de datos, las importaciones son muy rápidas y las lógicas de tareas, actualizaciones de estado y transiciones controladas por TTL son totalmente configurables.”
SA (Dialfire:)
“Ese es exactamente el enfoque. No reemplazamos los sistemas heredados. Evitamos su latencia. La eficiencia surge allí donde los datos se convierten en acción sin retrasos batch: de manera trazable, medible y sin pasos manuales intermedios.”