Sistema de tracking de llamadas end-to-end

La agencia opera ventas para múltiples clientes, con dos equipos que llaman a los clientes de formas completamente distintas. El equipo de pre-venta trabaja desde celulares Android rooteados de la agencia; el equipo operativo llama desde un sistema web con un teléfono embebido. Nada de esa actividad era visible: no había registro de quién llamó a quién, cuánto duró o qué se dijo. Las cotizaciones avanzaban en Kommo CRM sin conexión con las llamadas que las impulsaban, y la gerencia no podía medir el desempeño comercial más allá de las ventas cerradas.

• Las llamadas de pre-venta ocurren en celulares Android rooteados de la agencia — ninguna API de grabación de Play Store funciona ahí; capturar audio requiere una app a medida con acceso root (Magisk/superusuario).
• En el flujo Android no había otro lugar donde guardar las grabaciones — el audio solo existe en el dispositivo, así que el audio completo tiene que vivir en nuestro servidor, y el costo de almacenamiento crece con el volumen de llamadas.
• Las llamadas de operativa corren por un teléfono Twilio embebido en el sistema web — una vía de captura completamente separada, con grabaciones hospedadas en el proveedor.
• Los datos de llamadas, los cambios de estado de cotizaciones y la identidad del cliente vivían en sistemas desconectados (celulares, Twilio, Kommo) — sin trazabilidad de punta a punta de pre-venta a post-venta.

Flujo 1 — pre-venta: una app Android a medida en los celulares rooteados sigue el estado de llamada del equipo en tiempo real (ringing / offhook / idle vía TelephonyManager). La vendedora se loguea con su cuenta de la agencia, así cada llamada queda vinculada a su ID de trabajador. Al finalizar la llamada, la app sube la metadata (duración, número, entrante/saliente) más el audio completo a nuestro servidor — la grabación solo existe en el dispositivo, así que nuestro servidor es su hogar permanente. Flujo 2 — operativa: las llamadas salen del teléfono Twilio embebido en el sistema web; al terminar, Twilio dispara un webhook a nuestro endpoint y guardamos solo la URL de grabación del proveedor. Un pipeline en segundo plano descarga el audio temporalmente, lo transcribe con Whisper, lo resume con un LLM y descarta la copia local. Ambos flujos — más los webhooks de Kommo que replican cambios de estado de cotizaciones — convergen en el mismo historial unificado por cliente en MongoDB, con trazabilidad completa pre-venta → post-venta, incluyendo señales de interés en otros servicios de la agencia. Cualquier llamada del historial se puede re-transcribir y re-resumir bajo demanda con un botón, reusando el mismo pipeline. Un dashboard en React muestra el embudo (lead → prospecto → cliente) con KPIs por vendedora: llamadas realizadas, cotizaciones por estado, reuniones agendadas.

Diseñaría antes el esquema de eventos del historial unificado — lo migramos una vez cuando cambiaron los payloads de Kommo, y un envelope versionado desde el día uno lo habría hecho gratis. También agregaría políticas de retención de almacenamiento para el audio del flujo Android desde el inicio; las añadimos después, cuando el volumen hizo visible el costo. Y colas dead-letter en la ingesta de webhooks más temprano — los reintentos transitorios de Twilio nos enseñaron esa lección en producción.