Cómo medir el desempeño de tu equipo o proveedor de IA a los 90 días

El error de medir actividad en vez de resultado

El día 90 llega y alguien prepara una presentación. Tiene capturas de pantalla del dashboard, un listado de automatizaciones activas, una cifra de “horas ahorradas” que nadie puede rastrear hasta un proceso real de la empresa. La sala asiente. El proveedor se va con la sensación de que cumplió. Y el negocio sigue sin saber si el proceso que motivó el contrato (cobranza más lenta, cotizaciones que tardan días, soporte que se satura) mejoró en algo medible.

Este error se repite tanto porque medir actividad es fácil y medir resultado exige trabajo previo: haber definido, antes de empezar, cuál era la línea base. Sin ese número de partida (tiempo promedio de respuesta, tasa de error, costo por transacción, lo que sea relevante al proceso) cualquier revisión a los 90 días se vuelve una conversación de opiniones. El proveedor dice que “se avanzó mucho”. El área interna dice que “se siente más lento el cambio de lo esperado”. Nadie tiene con qué zanjar la discusión.

El costo de este error no es solo el dinero del contrato. Es el tiempo. Noventa días son suficientes para que un proceso mal diseñado se vuelva costumbre, para que el equipo se acostumbre a convivir con un sistema a medias y para que la ventana de corregir sin fricción se cierre. Cuando la revisión de 90 días se hace bien, en cambio, es el momento más barato para cortar o corregir: ya hay evidencia acumulada, pero el hundimiento de recursos todavía es manejable.

La pregunta que debería abrir cualquier revisión de 90 días no es “¿qué se hizo?”. Es “¿qué proceso de negocio funciona hoy distinto, y mejor, que hace 90 días, y con qué número lo puedo probar?”. Si nadie en la sala puede responder esa pregunta con datos, la revisión todavía no empezó de verdad.

Qué es (y qué no) la revisión de 90 días

La revisión de 90 días es un corte de caja del proyecto de IA, no una ceremonia de cierre de etapa. Se hace con la misma disciplina con la que se revisan los números de un área comercial: contra una meta definida antes, con evidencia verificable, y con una decisión al final, no solo con un “sigamos así” dicho de pasada.

• No es una demo. Que el sistema “funcione” frente a la pantalla durante la reunión no dice nada sobre si funciona todos los días sin que alguien lo esté vigilando de cerca.
• No es un conteo de entregables técnicos. Diez automatizaciones instaladas valen cero si nadie las usa en el proceso real o si el proceso real sigue corriendo en paralelo, a mano, “por si acaso”.
• No es una encuesta de satisfacción del proveedor. Que el equipo diga que “el proveedor es muy profesional” no reemplaza la pregunta de si el KPI se movió contra la línea base.
• No es solo revisar el contrato punto por punto. El contrato importa y se revisa en el marco de comparación, pero cumplir la letra del contrato no es lo mismo que haber resuelto el dolor que originó el proyecto.
• No es responsabilidad exclusiva del proveedor. Si el equipo interno no usa el sistema o no entregó los datos que el proyecto necesitaba, la revisión también debe exponer esa parte.

Qué revisar con evidencia (y no con impresiones)

Hay cuatro preguntas que deberían estar respondidas, con evidencia, antes de que termine la reunión de los 90 días. Si alguna no tiene respuesta con datos, la revisión no está completa: solo se pospuso para la siguiente reunión.

Qué proceso concreto mejoró

• Nombra el proceso, no el sistema. No es “el CRM” o “el agente”; es “el proceso de seguimiento a cotizaciones” o “el proceso de asignación de tickets”.
• Pide el antes y el después del mismo proceso, no de dos procesos distintos que sea fácil confundir para hacer ver bien el resultado.
• Verifica que el cambio sea atribuible al proyecto, no a una temporada más tranquila, a menos personal rotando o a una campaña comercial que movió la demanda por su cuenta.

Qué KPI se movió contra la línea base

• Exige el número de partida. Si nadie puede mostrar cuál era el KPI antes de empezar, la conversación de “mejoró” carece de referencia real.
• Compara el mismo KPI, en la misma unidad, en el mismo periodo del negocio. Evita comparar un mes de temporada alta contra uno de temporada baja sin ajustar.
• Desconfía de los promedios que ocultan varianza. Un tiempo de respuesta “promedio” que bajó puede esconder que el 20% de los casos sigue tardando igual o peor que antes.

Si el sistema se usa a diario

• Pide evidencia de uso, no de instalación: registros de acceso, volumen de casos procesados, frecuencia real de uso por la persona que debería usarlo.
• Pregunta directamente al usuario del proceso, no solo al responsable del proyecto, si lo usa todos los días o si convive con el proceso viejo “por las dudas”.
• Un sistema con adopción baja después de 90 días casi nunca se arregla con más capacitación; suele significar que el proceso rediseñado no calzó con cómo trabaja realmente el equipo.

Dependencia total o transferencia real

• Pregunta qué pasa si el proveedor desaparece mañana. Si la respuesta es “se detiene todo”, no hubo transferencia de conocimiento, solo una caja negra operando.
• Verifica quién tiene acceso, documentación y capacidad de ajustar el sistema sin depender de una llamada externa cada vez que algo falla.
• Diferencia dependencia técnica razonable de dependencia total. Es normal seguir necesitando soporte especializado; no es normal que el negocio no entienda ni pueda tocar su propio sistema.

El marco de revisión: comparar contra lo prometido

La revisión de 90 días necesita un punto de comparación objetivo, y ese punto es lo que se firmó, no lo que se recuerda haber conversado en una llamada. El contrato o los términos de referencia (TDR) del proyecto son el primer documento que se abre antes de la reunión de revisión, no después de ella.

• Lista, uno por uno, los entregables prometidos en el contrato o TDR, con su fecha comprometida, y márcalos como cumplido, cumplido parcial o no cumplido.
• Compara el alcance entregado contra el alcance cotizado. Es común que en el camino se “simplifique” el proyecto sin que nadie lo documente como un cambio de alcance real.
• Revisa los indicadores de éxito que el propio proveedor propuso al vender el proyecto. Si prometió una reducción de tiempo o de costo, esa cifra es la vara con la que se le mide, no una vara nueva más cómoda.
• Anota las desviaciones con causa, no solo con etiqueta. Que algo no se cumpliera puede deberse al proveedor, al equipo interno o a datos que no estaban listos; la causa cambia la decisión final.

Escuchar a quien usa el proceso todos los días

El informe del proveedor y el informe del responsable interno del proyecto casi siempre coinciden en que “vamos bien”. Ninguno de los dos es la fuente más confiable sobre cómo funciona el proceso en el día a día; esa fuente es la persona que ejecuta el proceso, no quien lo gestiona desde arriba.

• Habla directamente con quien opera el proceso, sin que el proveedor ni el líder del proyecto estén presentes filtrando la respuesta.
• Pregunta qué hace distinto desde que existe el sistema, en lugar de preguntar “¿te gusta?”, que casi siempre obtiene una respuesta cortés y poco útil.
• Busca las quejas específicas, no la satisfacción general. Un “funciona bien pero yo igual reviso todo a mano después” es la señal más valiosa de la revisión completa.
• Cruza lo que dice el usuario con los datos de uso. Si el usuario dice que lo usa a diario pero los registros muestran uso esporádico, ahí hay una conversación pendiente.

Decidir: continuar, ajustar o cortar (y documentarlo)

Toda revisión de 90 días termina en una decisión, no en un acta de buenas intenciones. Hay tres caminos posibles y cada uno tiene un criterio claro para tomarlo, no una preferencia personal de quien está más cómodo evitando el conflicto.

• Continuar sin cambios: el proceso mejoró de forma medible, el KPI se movió contra la línea base, el uso diario es real y hay transferencia razonable de conocimiento.
• Ajustar el alcance o el equipo: hay evidencia parcial (el proceso mejoró pero el KPI todavía no, o el uso es bajo por una fricción identificable); se corrige con un plan de ajuste con fecha, no con “vamos a seguir viendo”.
• Cortar la relación o el proyecto: después de 90 días no hay evidencia de mejora en el proceso ni movimiento del KPI, y las causas no son datos faltantes del lado interno sino ejecución del proveedor o del equipo.

La decisión se documenta por escrito, con fecha, con la evidencia que la sustenta y con quién la aprobó. No por burocracia: porque a los 180 días alguien va a preguntar por qué se continuó, se ajustó o se cortó, y “nos pareció que iba bien” no es una respuesta que resista una auditoría interna. Si el proyecto avanza a una etapa de revisión más profunda, esta documentación es exactamente el insumo que necesita una auditoría completa de un proyecto de IA ya implementado.

Cómo se ve en la práctica

Una empresa de distribución de insumos médicos, mediana, alrededor de 60 personas, en Perú, contrató a un proveedor externo para automatizar la gestión de pedidos que llegaban por WhatsApp y correo. A los 90 días, el proveedor presentó un informe con doce automatizaciones activas, un asistente de atención inicial funcionando y capturas de un dashboard con “95% de mensajes procesados”.

En la revisión, el gerente de operaciones pidió tres cosas antes de aprobar la renovación: el tiempo promedio de procesamiento de un pedido antes del proyecto, el tiempo promedio después, y una conversación directa con las dos personas que digitaban los pedidos en el sistema interno. El proveedor no tenía la línea base porque nunca se levantó al inicio del contrato. Las dos personas del área confirmaron que seguían digitando cada pedido a mano en el sistema de facturación, porque el asistente solo “clasificaba” el mensaje pero no lo cargaba al sistema que de verdad importaba para cobrar.

El resultado real de los 90 días era el siguiente: actividad alta (doce automatizaciones, un asistente “conversando” con los clientes) pero cero movimiento en el único KPI que le importaba al negocio, que era el tiempo entre que llegaba el pedido y se emitía la factura. La empresa no cortó de inmediato: exigió un ajuste con fecha (conectar el asistente al sistema de facturación en 30 días, con línea base medida esa misma semana) y condicionó el pago del siguiente hito a mostrar el nuevo tiempo de procesamiento con datos, no con capturas de pantalla.

Treinta días después, con la integración hecha, el tiempo de emisión de factura bajó de un poco más de un día a menos de dos horas en el 70% de los pedidos, medido con el mismo criterio que se había definido en la revisión de 90 días. La lección que quedó puertas adentro no fue “el proveedor era malo”; fue que la primera revisión, sin línea base ni conversación con el usuario real, casi aprueba una renovación basada únicamente en actividad.

Mi criterio

Cómo saber si hiciste bien la revisión de 90 días

Una revisión de 90 días bien hecha se nota porque termina en una decisión concreta, con evidencia que cualquier persona externa al proyecto podría revisar sin depender de la palabra de nadie en la sala.

• Tienes la línea base del KPI que existía antes del proyecto, no solo el número de después.
• Puedes nombrar el proceso concreto que cambió, no solo listar herramientas o automatizaciones instaladas.
• Hablaste directamente con quien usa el proceso todos los días, sin filtro del proveedor ni del responsable interno.
• Verificaste qué pasa con el sistema si el proveedor deja de estar disponible mañana mismo.
• La decisión (continuar, ajustar o cortar) quedó documentada por escrito, con fecha y con quién la aprobó.

Si alguno de estos puntos no tiene respuesta clara, la revisión de 90 días todavía no terminó, aunque la reunión ya se haya hecho. Y si el resultado es ajustar, esta misma disciplina (línea base, evidencia, usuarios reales, decisión documentada) es la que después sostiene una auditoría más profunda del proyecto ya implementado.