Del diagnóstico al piloto: ruta realista para los primeros 90 días

Por qué 90 días y no menos ni más

El piloto de 90 días es la unidad de tiempo razonable para validar adopción de agentes IA. Más corto (30-45 días) no alcanza a superar la curva de aprendizaje inicial — ves el ruido, no la señal. Más largo (6 meses) diluye urgencia, difunde accountability y hace que el proyecto compita con otras prioridades.

90 días tiene suficiente tiempo para: instrumentar, entrenar, ajustar, medir baseline vs post, iterar al menos dos veces, y producir decisión go/no-go informada.

Este artículo aterriza semana por semana qué hacer. Es un template pragmático, no una metodología sagrada. Adaptá a tu contexto.

Pre-semana 0: condiciones sin las cuales no se empieza

Antes de firmar el kick-off, confirmar:

• Sponsor ejecutivo comprometido con 30 minutos quincenales reservados para review.
• Product owner del piloto con 30-40% de su tiempo disponible los primeros 60 días.
• Equipo técnico asignado (mínimo 1 ingeniero con 50% bandwidth, idealmente 2).
• Presupuesto aprobado con aprobación para extender si el piloto muestra señal.
• Proceso candidato definido con volumen, métricas actuales y objetivos claros.
• Legal/compliance informado si hay datos sensibles.
• Comunicación al equipo operativo — nadie se entera por rumor.

Sin estos siete puntos, el piloto empieza con la pata rota y no termina bien.

Semanas 1-2: instrumentación y baseline

El error clásico: saltar a construir el agente. Correcto: primero instrumentar qué estás midiendo y capturar baseline actual. Sin baseline, al final del piloto no podés decir si mejoraste.

Actividades

• Instrumentar KPIs: tiempo de respuesta, resolución, NPS/CSAT, volumen por categoría, costo.
• Capturar baseline: 2 semanas completas de datos con el proceso actual sin cambios.
• Exportar dataset de entrenamiento: 500-2.000 conversaciones anonimizadas etiquetadas.
• Documentar playbooks actuales del equipo humano: cómo responden los 10 casos más frecuentes.
• Mapear integraciones técnicas necesarias: ¿qué APIs consumir? ¿qué webhooks?
• Definir "qué es éxito": no genérico. Target específico — "bajar MTTR de 4h a 1h30, contener 55% sin escalación".
• Definir criterios de rollback: ¿cuándo cortamos el piloto por resultado negativo?

Entregables fin de semana 2

• Dashboard de KPIs con datos baseline.
• Dataset etiquetado listo para entrenar.
• Documento de playbooks (puede ser informal, 5-10 páginas).
• Arquitectura técnica bosquejada.
• Criterios de éxito y rollback firmados.

Error a evitar

"Empecemos ya el prototipo, medimos después". Una vez empezado, capturar baseline post-hoc es imposible. Perdés la medida verdaderamente limpia.

Semanas 3-4: construcción de primer squad

Ya con baseline y playbooks, construir la primera versión del agente IA.

Actividades

• Configurar plataforma (Fanfusion Hub o alternativa) con squad inicial.
• Cargar FAQs, playbooks y knowledge base curada.
• Definir roles y permisos: qué puede responder solo, qué escala, qué requiere humano.
• Integrar con canal (WhatsApp, web chat, email).
• Integrar con CRM / backend para acciones (consultar pedido, actualizar ticket).
• Configurar guardrails: qué no debe responder, cómo detectar casos sensibles.
• Configurar audit log y observabilidad.

Entregables fin de semana 4

• Squad funcionando en ambiente de staging con 20 casos de prueba manuales.
• Integración end-to-end verificada.
• Playbook de operación (qué hace el equipo humano: aprobar, corregir, escalar).
• Plan de comunicación a clientes (si aplica — muchos pilotos internos).

Error a evitar

Intentar cubrir todos los casos desde día uno. Scope narrow: 2-3 tipos de consulta, no 15. Expandí en semanas siguientes.

Semanas 5-6: soft launch interno

El agente ya funciona pero no lo ve público externo aún. Test interno con tráfico real o sintético.

Actividades

• Lanzar en "modo sombra": el agente responde pero su output va a staff, no a cliente. Comparar con respuesta del humano.
• Medir concordancia: ¿cuántas respuestas IA son aceptables? ¿cuántas necesitan corrección?
• Identificar patrones de error: ¿fallan en un tipo de consulta específico? ¿con cierta fraseología del usuario?
• Iterar: ajustar playbooks, prompts, configuración del squad.
• Calibrar confianza: ¿a partir de qué score responde solo vs escala?

Entregables fin de semana 6

• Reporte de concordancia con ejemplos por categoría.
• Iteración #1 del squad aplicada.
• Métrica de "respuestas aceptables sin corrección" ≥ umbral definido (típicamente 70-80% para avanzar).

Error a evitar

Pasar a clientes sin semanas de shadow mode. Los primeros contactos reales con errores grandes cuestan reputación y credibilidad interna.

Semanas 7-8: producción acotada

Primera exposición a tráfico real, pero con filtros:

Actividades

• Lanzar a subconjunto controlado: ej. 20-30% del tráfico del canal, o a un segmento específico de clientes (ej. "consultas de Colombia" o "clientes del plan básico").
• Humano revisa todas las respuestas antes de enviarse — o revisa post-hoc pero con muestreo alto (50%+).
• Dashboard en tiempo real: CSAT por respuesta IA, errores, escalaciones.
• Stand-up diario 15 minutos para ver qué salió y qué ajustar.

Entregables fin de semana 8

• 500+ conversaciones reales procesadas por el squad.
• KPIs actualizados (comparar vs baseline).
• Lista de iteraciones priorizadas.

Error a evitar

Lanzar sin supervisión humana "porque el staging se veía bien". Los casos reales revelan edge cases que ninguna QA cubre.

Semanas 9-10: expansión y ajuste

Con datos reales de producción, ajustar y expandir scope.

Actividades

• Ampliar a 50-70% del tráfico del canal.
• Expandir tipos de consulta cubiertos (si los primeros están estables).
• Pasar revisión humana de "todas" a "muestreo + alertas de riesgo".
• Integrar señales de CX (NPS post-conversación) en ajuste.
• Identificar oportunidades de automatización adicional: acciones que hoy el agente deriva al humano pero podría hacer (ej. cancelar pedido, actualizar dirección).

Entregables fin de semana 10

• Scope expandido documentado.
• MTTR, contención, CSAT con mejora vs baseline medible.
• Decisión preliminar go/no-go.

Error a evitar

Expandir scope cuando el scope original aún no está estable. "Éxito en lo básico antes de expandir" no es opcional.

Semanas 11-12: evaluación final y decisión

Última iteración y preparación de la decisión para los próximos 6 meses.

Actividades

• Consolidar datos del piloto completo: antes vs después.
• Calcular ROI: ahorro de tiempo/costo humano, mejora de KPIs, valor de escala.
• Documentar aprendizajes: qué funcionó, qué no, qué cambiaría.
• Presentación ejecutiva con recomendación: scale, continue iterating, o sunset.
• Plan de los siguientes 6 meses si se aprueba scale.

Entregables fin de semana 12

• Reporte final del piloto.
• ROI validado con números, no proyecciones.
• Plan de scale firmado o decisión de pausa.

Qué medir a lo largo de los 90 días

KPIs estándar de pilot IA de CX:

• Contención automática: % de conversaciones resueltas sin intervención humana.
• Handoff rate: % escalado a humano.
• MTTR: tiempo de resolución.
• CSAT / NPS post-conversación: señal de calidad percibida.
• Accuracy / concordancia: % de respuestas IA aceptadas vs corregidas en revisión.
• Cobertura: % de casos donde el agente tiene capacidad de responder.
• Incidentes graves: respuestas peligrosas, hallucinations, datos incorrectos. Count absoluto, objetivo tender a 0.
• Costo por interacción: tokens + infraestructura vs costo humano equivalente.

Estos se miden semanal desde semana 3. Dashboard visible para todo el equipo del piloto.

Señales de que va bien

• Semana 4: squad construido, playbooks claros.
• Semana 6: concordancia en shadow > 70%.
• Semana 8: CSAT de respuestas IA ≥ CSAT humano baseline.
• Semana 10: contención ≥ 40% con errores graves en tendencia descendente.
• Semana 12: ROI positivo proyectado sobre 6-12 meses.

Señales de alerta

• Semana 6: concordancia < 50%. Algo del dataset o playbooks está mal.
• Semana 8: CSAT IA significativamente menor que humano. Calidad percibida baja.
• Semana 10: incidentes graves no bajan. El agente sigue siendo riesgo.
• Semana 12: ROI no alcanza umbral acordado. Decisión honesta de pausa.

Tener alertas claras permite decisión sin emotividad en semana 12.

Cuando el piloto no alcanza

Falla pasa. El comportamiento correcto:

• Post-mortem honesto: ¿falló el producto, la implementación, el proceso elegido, o el contexto organizacional?
• Distinguir "no funcionó con este scope" de "no funciona en general". Un piloto fallado en un proceso puede ser éxito en otro.
• Comunicación clara a dirección: qué aprendimos, qué no, qué haríamos distinto.
• Decisión: parar IA indefinidamente, hacer otro piloto con scope distinto, o postergar hasta que cambien condiciones.

Un piloto que se mata porque no funcionó es más responsable que un piloto que se extiende indefinidamente esperando resultados.

Qué falla en los primeros 90 días (y cómo evitarlo)

El mayor riesgo no es técnico — es operacional. Lo que rompe pilotos:

Falla 1: KB incompleta o desactualizada. Se arranca con intención de "completamos después" y el "después" no llega. El squad responde con info limitada o incorrecta. Prevención: KB mínima viable debe estar antes del día 1 operación.

Falla 2: Owner ausente. El líder del cliente que dijo que iba a dedicar 5 horas semanales termina dando 1. El squad degrada. Prevención: contractualmente comprometer capacidad del owner; si no se honra, el piloto pausa.

Falla 3: Scope creep. Se arrancó con soporte básico pero en semana 3 se le pide que también venda. Rompe métricas, confunde KB, diluye foco. Prevención: scope congelado primer 90 días; expansión en fase 2.

Falla 4: Expectativas irrealistas. CEO espera 95% automatización en mes 1. Resultado imposible crea frustración. Prevención: setear baseline y curva realista desde diagnóstico, firmada por ambos.

Falla 5: Métricas sin acción. Weekly review se llena de datos pero nadie decide nada. Piloto navega sin rumbo. Prevención: cada weekly review produce 1-3 acciones concretas con owner y deadline.

Falla 6: Resistencia del equipo humano. "Nos va a reemplazar el bot". Afecta adopción. Prevención: comunicar pronto que el squad libera tiempo para trabajo de mayor valor, no para reducir headcount.

Métricas que se reportan cada semana

Las 10 métricas del weekly review de piloto:

1. Volumen de interacciones (semana vs anteriores).
2. Contención del squad (%).
3. CSAT (promedio + distribución).
4. TTFMR (mediana).
5. Tasa de escalación + razones top 3.
6. Costo por interacción resuelta.
7. Top 5 intents (por volumen).
8. Top 5 issues recurrentes (candidatos a KB update).
9. Incidentes de la semana (si los hubo).
10. Acciones de la semana pasada: estado (done/doing/blocked).

Si el weekly no puede caber en 30 min con estas 10 métricas, se está midiendo demasiado. Priorizar estas antes de expandir.

Señales de que el piloto está listo para pasar a producción

Al día 90 evaluamos contra criterios:

• KPIs primarios alcanzados o cerca. Al menos 70% del target original.
• CSAT igual o mejor que baseline humana.
• No incidentes graves en últimos 30 días.
• Owner satisfecho con el modo operativo.
• Equipo humano acepta el squad como parte del equipo.
• Plan claro para expansión (qué squad 2, qué canal 2, qué geografía 2).

Si los 6 check, squad pasa a producción. Si alguno falla, extendemos piloto 30-60 días con plan específico para cerrar gap.

Preguntas frecuentes

¿Puedo hacer pilotos de menos de 90 días?

Sí, pero con ajustes. 45-60 días funciona si el scope es muy acotado (ej. solo FAQs públicas) y el equipo tiene readiness avanzado. Menos de 45 días es marketing.

¿Quién tiene que estar en los reviews semanales?

Product owner, lead técnico, operador de área afectada. 30-45 minutos. Sponsor ejecutivo en reviews quincenales. Más asistentes diluye.

¿Cuánto cuesta un piloto típico?

Implementación de 90 días con plataforma incluida: USD 30-100k según scope y personalización. Con equipo interno + plataforma self-service: 10-30k.

¿Cómo convenzo a dirección de aprobar?

Con ROI proyectado específico y riesgo acotado. "Si funciona: ahorro de X al año. Si no: invertimos Y durante 90 días con decisión clara de parar". Nunca prometas certeza.

¿Qué pasa si dirección cambia en medio del piloto?

Documentar obsesivamente los aprendizajes y resultados. El nuevo sponsor necesita evidencia, no historia. A veces el piloto sobrevive transiciones gracias al rigor de documentación.

¿Se puede hacer el piloto con equipo interno sin consultora?

Sí. Requiere gente con experiencia IA aplicada (no solo prompts). Alternativa: usar plataforma como Fanfusion Hub que reduce necesidad de expertise técnico profundo.

¿Qué porcentaje de pilotos termina en scale?

En nuestra práctica: 70% escalan, 15% iteran con otro scope, 15% se pausan definitivamente. Los que escalan respetaron las condiciones pre-kickoff; los que fracasan típicamente las saltaron.

Si tenés diagnóstico hecho y necesitás aterrizar un piloto bien diseñado, empezá con un diagnóstico de 10 minutos — proponemos el scope de piloto que más señal te dará. Más profundidad: Cómo preparar un diagnóstico, Señales de que estás listo, ROI de un diagnóstico, plataforma en /platform.