01 · La situación
Comercial actualizó la propuesta. El resto sigue con la anterior.
Imaginemos un evento cuyo cliente pide más asistentes y un cambio de horario. Comercial prepara una nueva propuesta, pero operaciones conserva la primera. Algunos cambios están confirmados; otros siguen en una conversación pendiente.
Antes de plantear una herramienta, comprobaría cómo se distingue una petición de cambio de un compromiso aprobado, y dónde se pierde esa información.
02 · Qué analizaría
Del presupuesto a lo que se prepara.
- Dónde se crean y guardan las propuestas y cómo se identifica la versión vigente.
- Por qué canales llegan los cambios y quién puede confirmarlos.
- Qué se ha comunicado al cliente y qué sigue pendiente de validación.
- Qué información necesitan operaciones, proveedores y administración.
- Cómo se comprueba que cada equipo trabaja con lo aprobado.
03 · Qué diseñaría
Versiones, decisiones y responsabilidades claras.
Definiría el circuito funcional antes de elegir herramientas o encargar el desarrollo:
- Una referencia vigente
- Definir cómo identificar el evento, la versión y su estado: borrador, enviada, aceptada o sustituida. Conservar el histórico y distinguir lo aprobado de los cambios pendientes.
- Reglas de aprobación
- Establecer quién valida cada cambio, qué requiere confirmación del cliente y qué debe revisar el equipo antes de comprometer precios, servicios o disponibilidad.
- Traspaso a la operación
- Definir qué necesita cada equipo, quién comunica los cambios aprobados y cómo se confirma su recepción. Un envío de correo no demuestra que la operación esté actualizada.
- Excepciones y control
- Acordar cómo actuar ante cambios de última hora, versiones contradictorias o falta de confirmación. Registrar quién decide y qué queda pendiente, con acceso según la función de cada persona.
Petición: el cliente solicita más asistentes y otro horario. Registrar el cambio sin tratarlo todavía como aprobado.
Validación: comprobar capacidad, recursos y condiciones con las personas responsables. Preparar la revisión y obtener las confirmaciones necesarias.
Ejecución: publicar la referencia aprobada, identificar qué cambió y confirmar el traspaso a los equipos. Mantener visibles los asuntos pendientes.
04 · Dónde podría aportar la IA
Apoyar la revisión sin asumir decisiones.
Si el diagnóstico lo justificara, la IA podría proponer una comparación entre versiones o preparar un resumen de cambios enlazado a los documentos originales. Definiría qué debe comprobar una persona antes de utilizarlo.
No debería interpretar un mensaje ambiguo como aceptación, autorizar un precio ni prometer disponibilidad. El control de versiones y los avisos pueden resolverse con procesos y automatización convencional, sin IA.
05 · Qué recibiría la empresa
Una base para valorar la implementación.
Un mapa del proceso comercial y operativo, los campos de información, estados y transiciones, responsables y permisos, reglas de aprobación y traspaso, escenarios de prueba y criterios de aceptación. Las dependencias de sistemas se validarían con el equipo técnico.
Soy Tamara González Molina, Consultora Estratégica de IA y Arquitecta Funcional de Soluciones de IA. No vendo herramientas ni desarrollo software. Empiezo por entender el negocio y defino cómo debería funcionar la solución.
06 · Cómo validar la mejora
Comprobar que los equipos ejecutan lo acordado.
En un piloto revisaría cambios sin confirmación, diferencias entre documentos y preparación, consultas para aclarar la versión vigente y tiempo de traspaso. Compararía una muestra inicial con eventos de complejidad similar y acordaría los criterios de éxito, sin presuponer ahorros.
El punto de partida puede ser un diagnóstico estratégico de IA. Conoce también mi consultoría para empresas o el ejemplo de seguimiento de peticiones entre turnos.