Programa piloto de chatbot con IA: un plan de 4 semanas que no fracasa

TL;DR:

• La mayoría de los pilotos de IA fracasa por ampliación del alcance, falta de criterios de éxito, participantes equivocados y ausencia de un plan de reversión. Cerca del 80% de los proyectos de IA no cumple sus objetivos, según el estudio de RAND de 2024 sobre fracasos de proyectos de IA.
• El plan de cuatro semanas: semana 1 para alcance y métricas, semana 2 para construir y probar offline, semana 3 para un lanzamiento gradual al 5-10% del tráfico y semana 4 para medir y decidir.
• Elige el caso de uso más estrecho posible. "Solo preguntas sobre el estado del pedido" es un piloto real. "Soporte con IA" no lo es.
• Define un criterio de cancelación antes de empezar. Si el bot queda más de 15 puntos por debajo del objetivo de contención, lo apagas; no lo rediseñas a mitad del piloto.

Un "piloto" puede ser una prueba real o una forma de aparentar actividad. La diferencia está en si preparas las condiciones para obtener una respuesta honesta al final. La mayoría de programas piloto no lo hace, y por eso el sector acumula chatbots desplegados a medias que nadie mantiene.

Este es el plan de cuatro semanas que conduce a un sí o un no. Es deliberadamente concreto. La ventaja de un plan concreto es que puedes terminarlo.

Por qué fracasan los pilotos

El estudio de RAND de 2024 situó la tasa de fracaso de los proyectos de IA cerca del 80%, más del doble que en proyectos de TI convencionales. El patrón de los análisis posteriores es constante. Los pilotos fracasan por uno de estos cuatro problemas:

Ampliación del alcance. El piloto empieza como "responder preguntas sobre el estado del pedido" y termina como "ser un agente de soporte completo en cinco canales y tres idiomas". El equipo se queda sin tiempo antes de terminar nada.

Falta de criterios de éxito. El piloto se lanza sin una métrica concreta. Al final, el equipo discute si un 32% de contención es bueno o malo porque nadie dejó por escrito el objetivo.

Participantes equivocados. Ingeniería construye el bot. Soporte nunca acepta las reglas de traspaso. Marketing no aprueba el tono. En la semana 4 no existe un responsable interno dispuesto a defender el resultado.

Ausencia de un plan de reversión. El bot rinde mal, pero ya está en la página principal de soporte y nadie es responsable de apagarlo. Así que permanece allí, medio roto, erosionando la confianza en el equipo que lo creó.

Cada paso de este plan existe para neutralizar uno de esos modos de fallo.

El piloto de 4 semanas de un vistazo

Cada semana termina con un entregable obligatorio. Si no puedes producirlo, no avanzas. Así se impide que el alcance crezca sin control.

Semana 1: alcance y métricas

Es la semana más importante. La mayoría de pilotos fracasa en la semana 1, aunque nadie lo advierta hasta la semana 4.

Define métricas de éxito

Escribe tres números antes de escribir código.

• Objetivo de tasa de contención. ¿Qué porcentaje de conversaciones debe resolver el bot sin traspaso humano? Sé realista. Para un caso estrecho, como solo estado de pedidos, entre 60% y 75% es razonable. Para un alcance amplio, espera entre 30% y 50% durante el primer mes.
• Objetivo de CSAT. La mayoría de equipos busca 4.0 o más sobre 5, o un 80% de valoraciones positivas. Por debajo de 3.5 es un fracaso, sin importar la contención.
• Objetivo de tiempo de resolución. ¿Cuánto debe durar una conversación resuelta? Dos minutos es un punto de partida razonable para casos transaccionales.

Escríbelos en un documento. Consigue la aprobación del responsable de soporte y del patrocinador ejecutivo. Ese es el documento que leerás el viernes de la semana 4.

Elige el caso de uso más estrecho posible

Aquí mueren los pilotos. El impulso es crear "un agente de soporte con IA". La disciplina consiste en crear "un bot de estado de pedidos".

Un buen caso para la semana 1 tiene:

• Un tipo de pregunta o un grupo muy relacionado, como devoluciones, estado de pedidos o restablecimiento de acceso
• Una o dos fuentes de conocimiento, como una sección del centro de ayuda o una API de estado
• Resolución en menos de cuatro turnos
• Un destino claro para el traspaso cuando el bot no pueda resolver

Malos casos para la semana 1:

• "Sustituir el soporte de nivel 1"
• "Responder cualquier cosa del sitio web"
• "Gestionar facturación, devoluciones y preguntas técnicas"

Un alcance estrecho no es falta de ambición. Es el único que termina a tiempo.

Identifica el conjunto de referencia de 25 preguntas

Extrae de tu bandeja de soporte 25 preguntas reales que coincidan con el alcance. Anonimízalas. Incluye 10 preguntas comunes, 5 casos límite, 5 preguntas sobre cumplimiento de políticas, 3 cuya respuesta no esté disponible y deba rechazarse, y 2 con tono hostil o confuso.

Usarás el mismo conjunto cada semana durante todo el piloto.

Elige la superficie de despliegue

Decide dónde vivirá el bot en la semana 3 antes de construirlo. Opciones, de menor a mayor riesgo:

1. Solo en el centro de ayuda
2. Prueba interna, con tu equipo como usuario
3. Páginas concretas del producto, como checkout
4. Widget en todo el sitio para el 5-10% de las sesiones
5. Página principal de soporte

La mayoría de pilotos debería elegir la opción 1 o 3. La página principal de soporte viene después del piloto.

Entregable de la semana 1: un documento de una página con el caso de uso, las tres métricas y sus objetivos, las 25 preguntas, la superficie de despliegue y el criterio de cancelación. Firmado por soporte y el patrocinador ejecutivo.

Semana 2: construcción y prueba offline

Ahora construyes. La condición es que el bot funcione con el conjunto de pruebas antes de enfrentarse a un cliente real.

Construye el bot

Configura la plataforma, carga la base de conocimiento y escribe el prompt de sistema. Para un caso estrecho son entre dos y cuatro días de trabajo, no dos semanas.

Resiste la tentación de añadir funciones. Un bot piloto no necesita 15 integraciones. Necesita responder correctamente al caso que definiste.

Ejecuta las 25 preguntas

Puntúa cada pregunta en cuatro dimensiones: precisión, tono, seguridad y calidad del traspaso. Consulta la metodología completa en nuestra guía de evaluación de chatbots.

Criterios para pasar a la semana 3:

• Precisión: al menos 90%
• Tono: al menos 85%
• Seguridad: 100%; un bot que falla una prueba de seguridad no se publica
• Calidad del traspaso: al menos 80%

Si no aprueba, itera. No pases a la semana 3 con una puntuación offline insuficiente esperando que producción lo arregle. No lo hará.

Configura las reglas de traspaso

Define cuándo escala el bot y a quién. Estos valores predeterminados suelen funcionar:

• Escalar ante cualquier petición explícita del usuario, como "quiero hablar con una persona"
• Escalar después de dos intentos fallidos de recuperación
• Escalar al detectar señales de frustración
• Escalar cualquier asunto fuera del alcance definido

Asegúrate de que los agentes sepan que el piloto está en marcha, qué cubre el bot y cómo reconocer los escalados.

Entregable de la semana 2: puntuaciones del conjunto de pruebas, prompt de sistema y fuentes documentados, reglas de escalado por escrito y briefing terminado para los agentes.

Semana 3: lanzamiento gradual

La prueba real. Pasa de la teoría a producción con cuidado.

Despliega al 5-10% del tráfico

No publiques en el 100% de la superficie el primer día. Usa segmentación por URL, muestreo por sesión o un despliegue porcentual si tu plataforma lo admite.

El objetivo del lanzamiento limitado es poder revertir al instante cuando algo falle. Y algo fallará.

Revisa conversaciones reales a diario

Cada mañana, lee entre 20 y 30 conversaciones del día anterior. Busca:

• Respuestas equivocadas
• Malos escalados: escalar cuando podía responder o continuar cuando debía escalar
• Errores de tono, como mostrarse despreocupado con un cliente frustrado
• Preguntas fuera del alcance del piloto

La primera semana con tráfico real siempre sorprende. Aparecen formulaciones que no probaste, errores tipográficos y preguntas que parecen coincidir con el alcance pero en realidad son distintas. Registra cada sorpresa.

Corrige los tres fallos principales

El miércoles de la semana 3 deberías tener una lista de fallos ordenada por frecuencia. Corrige los tres primeros, no todos. Las soluciones suelen ser:

• Añadir contenido ausente a la base de conocimiento
• Ajustar el prompt de sistema para una formulación concreta
• Endurecer o relajar una regla de escalado

Vuelve a ejecutar las 25 preguntas después de cada corrección para comprobar que no hayas introducido una regresión.

Entregable de la semana 3: lista de conversaciones revisadas, fallos principales ordenados, correcciones publicadas y puntuaciones más recientes.

Semana 4: mide y decide

Esta es la razón de ser del piloto. No permitas que se convierta en "la segunda parte de la semana 3".

Compara los resultados con los criterios

El lunes de la semana 4, reúne estos números:

• Tasa de contención de toda la semana 3
• CSAT de las encuestas posteriores a la conversación
• Tiempo de resolución
• Coste por conversación
• Tasa y calidad de los escalados

Colócalos junto a los objetivos escritos en la semana 1. No renegocies los objetivos. Los dejaste por escrito precisamente para evitar mover la portería.

Decide: ampliar, iterar o cancelar

Hay tres resultados posibles.

Ampliar. Alcanzaste o superaste las tres métricas principales. Escribe el plan de despliegue: próximas superficies, próximos alcances y responsable posterior al piloto. Consigue su aprobación esa misma semana.

Iterar. Alcanzaste una o dos métricas, pero fallaste otra. Es el resultado más peligroso porque no termina de forma natural. Fija una fecha límite, no más de cuatro semanas adicionales, y un nuevo control. Si vuelves a fallar, cancela.

Cancelar. Fallaste dos o tres métricas por márgenes importantes o activaste el criterio de cancelación. Apaga el bot ese mismo día y redacta el análisis posterior esa semana.

Ese análisis no es un castigo, sino el artefacto más valioso de un piloto fallido. Muchos segundos pilotos tienen éxito porque el primero enseñó al equipo a definir mejor el alcance.

Entregable de la semana 4: una decisión escrita, ampliar, iterar o cancelar, con los números que la justifican, el plan de despliegue o apagado y el alcance del siguiente piloto si corresponde.

Costes esperados del piloto frente a producción

Los costes del piloto son distintos a los de producción. En la semana 3, con tráfico limitado, la factura mensual puede ser de $50 a $500 según la plataforma. A plena escala, el mismo bot puede costar entre $2,000 y $10,000 al mes. Haz el cálculo de economía unitaria en la semana 4, no una vez que estés en producción.

Una regla aproximada para soporte: apunta a un coste por conversación resuelta inferior al 20% del coste de resolverla con una persona. Para muchos equipos, un ticket humano cuesta entre $5 y $15 contando todo el tiempo del agente. Eso deja un presupuesto de alrededor de $1 a $3 por conversación con IA, bastante por encima de lo que cobran la mayoría de plataformas modernas.

No es para ti

Hay dos pilotos que nunca deberían empezar.

El piloto de escaparate. La dirección quiere decir "tenemos IA". Nadie es responsable de las métricas. El bot aparece en un rincón poco visitado y nadie vuelve a mencionarlo. No es un piloto, es un comunicado de prensa. Cancélalo ahora y ahorra el presupuesto.

La táctica dilatoria. "Probémoslo durante un trimestre" suele significar "no nos comprometamos todavía". Si el piloto se amplía una y otra vez sin nueva evidencia, la respuesta no es otra extensión. La respuesta es tomar una decisión.

Un piloto real tiene alcance, métrica, fecha límite e interruptor de apagado. Si el tuyo no los tiene, corrígelo antes de dedicarle otra semana.

Preguntas frecuentes

P: ¿Por qué fracasan tantos proyectos de IA?

La cifra más citada, cerca del 80% según la investigación de RAND de 2024, cuenta proyectos que no cumplen sus objetivos declarados. Las causas se concentran en las tratadas aquí: ampliación del alcance, falta de criterios, ausencia de patrocinio ejecutivo y ningún momento honesto para decidir.

P: Cuatro semanas parecen pocas. ¿Podemos hacer un piloto de ocho semanas?

Sí, pero la estructura es la misma. Añade tiempo a la semana 2, construcción, o a la semana 3, lanzamiento gradual; no a la semana 1 ni a la 4. Definir el alcance durante más tiempo no mejora el resultado. Medir durante más tiempo normalmente tampoco.

P: ¿Qué ocurre si nuestros criterios de éxito resultan equivocados?

Reconócelo por escrito en la semana 4. "Buscábamos 70% de contención, logramos 52% y ahora creemos que 50% con 4.3 de CSAT es mejor que 70% con 3.8". Después ejecuta un segundo piloto con los nuevos criterios. No cambies los objetivos en silencio a mitad de la prueba.

P: ¿Quién es responsable del piloto?

Una persona concreta, sin excepciones. Normalmente es un responsable de soporte, con ingeniería y producto como apoyo. Si tres personas comparten la responsabilidad, no la tiene nadie.

Ejecuta las cuatro semanas y obtén una respuesta

Un piloto no es un ejercicio de marketing. Es una forma estructurada de descubrir si merece la pena ampliar un chatbot en tu empresa. Bien ejecutado, tarda cuatro semanas y produce un sí o un no claro. Mal ejecutado, deja un despliegue permanente a medias que le cuesta confianza al equipo.

Chatsy permite crear el agente y revisar el historial y las exportaciones de conversaciones. Controla el piloto añadiendo el embed solo a las páginas elegidas o aplicando una regla en el código de tu sitio; Chatsy no ofrece actualmente rollouts porcentuales ni reglas nativas de segmentación por URL. Empieza gratis o consulta los precios y ejecuta tu piloto este mes.