Tablero de compromisos de cierres sobre el CRM

Contexto

Una unidad de negocio de un grupo empresarial B2B, con operación en varios países, sostiene una reunión mensual de “compromisos de cierre”: cada líder de vertical presenta qué oportunidades del CRM se compromete a cerrar, cuáles son upside y qué pasó con lo prometido el mes anterior. El soporte era un PowerPoint armado a mano, reutilizado mes a mes ocultando láminas anteriores: al iniciar el proyecto, el archivo acumulaba más de 160 láminas.

Problema

El dato de gestión comercial vivía en dos lugares —el CRM y el PowerPoint— y las correcciones se hacían sobre la lámina, no sobre el sistema de origen. La comparación entre compromiso y cierre real dependía de capturas manuales guardadas en láminas ocultas, y en la reunión mensual aparecían con frecuencia oportunidades ya cerradas o mal clasificadas: la causa era la duplicación de la fuente de verdad. Durante la construcción surgió además un problema de modelo de datos: la “vertical” de cada oportunidad no existía como dato propio en el CRM.

Solución

Se definió una regla previa a la primera línea de código: el dashboard es de solo lectura y toda corrección de datos ocurre en el CRM, con un enlace directo desde cada oportunidad a su registro de origen.

• Los datos incompletos del CRM (cuenta sin país, propietario fuera de lista vigente, oportunidad sin línea de negocio) se muestran como advertencias separadas de los totales, sin corregirse en la aplicación.
• El snapshot mensual quedó como eje del sistema: en la fecha de la reunión se congela una foto de compromiso y upside, y ese registro mide el cumplimiento del mes siguiente.
• Los snapshots históricos se reconstruyeron a partir de las láminas ocultas del PowerPoint original, para tener serie continua desde el primer día.
• La misma regla de solo lectura se extendió a los agentes de IA de la construcción, con las herramientas de escritura sobre el CRM bloqueadas.

Resultados

• La aplicación quedó desplegada en un ambiente de prueba, con inicio de sesión corporativo real, y se usa en las reuniones mensuales de compromisos, que dejaron de depender del PowerPoint.
• En una de las primeras reuniones con el dashboard se plantearon ocho pedidos de ajuste; siete de los ocho quedaron implementados al día siguiente.
• 146 cambios registrados en el repositorio de trabajo y 86 pruebas unitarias, con coautoría de asistentes de IA en el 98,6 % de los cambios.

Arquitectura y decisiones

La aplicación consume las oportunidades del CRM y las clasifica con reglas de negocio explícitas por probabilidad, vertical y territorio, sin escribir de vuelta sobre el sistema de origen. El snapshot mensual es un registro inmutable, tomado en la fecha de cada reunión, que vincula el estado de las oportunidades en ese momento con el compromiso y el upside declarados; ese registro es la base para medir el cumplimiento del mes siguiente sin depender de capturas manuales.

El acceso de los agentes de IA al CRM durante la construcción se configuró en modo exclusivo de lectura, dejando cualquier escritura futura como un proyecto aparte con confirmación humana previa. La infraestructura se construyó como código, con identidades administradas en lugar de credenciales de larga duración y despliegue con autenticación federada. Se aplicó además un endurecimiento de seguridad previo a una prueba de penetración externa, con los desvíos temporales respecto del marco de arquitectura corporativo declarados por escrito, con responsable y fecha de revisión.