Del problema al primer alcance

Un error frecuente es empezar con «queremos un asistente de IA» y descubrir después para qué. Esta página va en sentido contrario: del problema observado a un primer alcance pequeño, comprobable y honesto. En el sector se le suele llamar MVP (minimum viable product, producto mínimo viable): la versión más pequeña que permite completar tareas reales y aprender de ellas.

1. Formular el problema

Un primer alcance no es un asistente pequeño que intenta hablar de cualquier cosa. Es una experiencia que permite completar un conjunto reducido de tareas reales, con expectativas y límites claros. La unidad de alcance es el resultado para la persona, no el número de temas, pantallas o intenciones que el sistema reconoce.

Para separar el problema de la solución, conviene redactar una hipótesis con este molde:

Para [grupo de personas], la tarea [tarea concreta] resulta difícil por [obstáculo observado]. Una experiencia conversacional debería ayudarles a conseguir [resultado observable] con menos [tiempo, errores, esfuerzo o incertidumbre], manteniendo [condición de calidad o seguridad].

Compara dos formulaciones:

La segunda se puede investigar, medir y, sobre todo, refutar. Si resulta que el abandono se debe a otra cosa, el asistente no lo arreglará.

2. Casos de uso, no temas

«Facturas» es un tema. «Encontrar una factura, comprobar si está pagada y descargarla» es un caso de uso: tiene principio, fin y un resultado que se puede comprobar.

La diferencia es la misma que hay entre un campo semántico y un acto de habla. Un tema agrupa palabras; un caso de uso describe a alguien que quiere conseguir algo. Para cada caso, una ficha breve:

Para cada caso diseña, como mínimo, cinco recorridos: el camino normal, una variación en los datos, una interrupción, un fallo de un servicio externo y una salida. Ese mínimo evita confundir «cubrir el caso» con dibujar solo el intercambio ideal.

3. Elegir por dónde empezar

Las tareas candidatas se ordenan con unos pocos criterios:

Lo habitual es empezar por una tarea de mucho valor y riesgo manejable. Si el resultado depende de una decisión crítica, de datos sensibles o de acciones irreversibles, conviene empezar por orientar o preparar, y dejar la ejecución para más adelante, con controles.

La regla del 80/20 (cubrir primero los caminos que concentran la mayoría de los casos) sirve para priorizar, pero no para olvidar el resto. La guía de Google habla de la «cola larga»: casos raros que, juntos, son muchos. No hace falta automatizarlos todos, pero cada uno merece una salida segura. Un caso raro que puede borrar datos o dejar a alguien sin servicio merece más diseño que uno frecuente y sin consecuencias.

4. Dibujar el perímetro

Documenta tres listas, para el equipo y, en lenguaje sencillo, para las personas usuarias:

1. Puede hacer: tareas, fuentes y acciones concretas.
2. No puede hacer: límites funcionales, tipos de caso o decisiones fuera de alcance.
3. Puede empezar, pero debe detenerse o derivar: faltan datos, el riesgo es alto, hay una excepción o hace falta criterio humano.

Una limitación que se comunica tarde se vive como una promesa rota. En una primera versión es mejor un sistema estrecho y predecible que uno amplio y sorprendente.

5. Qué medir desde el principio

Pocas medidas, ligadas al problema:

• éxito de la tarea: cuántas llegan al resultado correcto
• abandono por punto: dónde se interrumpe el recorrido y qué necesitaba la persona
• esfuerzo: turnos, repeticiones, correcciones y tiempo, siempre en relación con la complejidad de la tarea
• recuperación: cuántos errores se resuelven sin empezar de nuevo
• exactitud real: si la acción ocurrió de verdad, no solo si el asistente dijo que ocurrió
• confianza ajustada: si la persona sabe distinguir una respuesta confirmada de una tentativa
• derivación útil: si las transferencias llegan al sitio adecuado con el contexto necesario
• coste y tiempo de respuesta

No optimices solo para hacer menos turnos. Una pregunta de más puede evitar una acción equivocada, y una decisión importante puede necesitar una conversación más larga.

6. Un lanzamiento por fases

• explorar: entrevistas, observación del proceso actual, revisión de consultas e incidencias reales
• prototipar: representar turnos y estados críticos sin construir toda la infraestructura
• probar en pequeño: casos representativos y personas diversas, observando dónde se confunden
• lanzar con alcance limitado: pocas tareas, pocos permisos o un solo canal, con soporte humano preparado
• ampliar con datos: añadir lo que falta con frecuencia y corregir lo que falla de forma repetida