Cuando algo falla: la reparación
Páginas de este taller
En esta página
Las personas se malinterpretan constantemente y casi nunca lo notan, porque reparan sobre la marcha: «¿cómo?», «no, me refería a…», «perdona, ¿el jueves o el martes?». Schegloff, Jefferson y Sacks describieron en 1977 cómo funciona esa reparación y observaron una preferencia clara: se repara pronto, en el turno siguiente, y a ser posible lo hace quien cometió el problema.
En el diseño conversacional, la reparación se llama fallback (literalmente, «recurso de reserva»): lo que hace el sistema cuando no ha interpretado la respuesta, no encuentra la información, no puede actuar o ha perdido el hilo. No es una frase de disculpa. Es una ruta para recuperar la meta de la persona.
1. Cada fallo, su reparación
Un único «No te he entendido» para todo no explica qué ha pasado ni cómo seguir. Microsoft recomienda diseñar reparaciones distintas según la función y decidir de antemano cuándo pasar la conversación a una persona. Estas son las clases de fallo más comunes:
| Situación | Qué necesita la persona | Reparación recomendada |
|---|---|---|
| Silencio, no hay respuesta | Saber si el sistema sigue esperando | Esperar lo adecuado al canal, recordar la pregunta y ofrecer repetir, saltar o salir |
| No se interpreta la respuesta | Reformular sin perder lo hecho | Decir qué parte falta o qué opciones resolverían la duda |
| Petición fuera de alcance | Saber si hay otra vía | Explicar el límite concreto y ofrecer el canal o la tarea más cercana |
| No se encuentra información | Saber si no existe o si la búsqueda falló | Distinguir «no aparece en la fuente» de «no he podido consultar la fuente» (véase el taller sobre RAG) |
| Un servicio no responde | No repetir una acción a ciegas | Decir si la acción se ejecutó o no, ofrecer un reintento seguro y conservar el estado |
| Acción a medias | Saber qué se hizo y qué falta | Separar lo completado de lo pendiente; no anunciar un éxito global |
| Respuesta ambigua | Que no se ejecute lo que no era | Una pregunta estrecha con las interpretaciones posibles |
| El mismo fallo se repite | Salir del bucle | Cambiar de estrategia, ofrecer otra forma de responder o derivar |
| Se pierde la sesión | Retomar sin repetir ni duplicar | Resumir lo confirmado y preguntar si se continúa |
| Caso urgente o delicado | Llegar a la ayuda adecuada | Interrumpir el flujo y dar de inmediato la vía apropiada |
2. Reparar en el sitio
La reparación tiene que ser local: recordar qué se estaba resolviendo, qué respuesta sería válida y qué se sabe ya. Y debe crecer con cada intento, igual que una persona pasa de un «¿cómo?» a una explicación más larga cuando el primero no funciona:
Diálogo anotado
Una reparación que crece
- Máquina
¿Qué ciudad quieres visitar?
- Persona
Lo de siempre.
La persona presupone un conocimiento compartido que el sistema no tiene registrado.
- Máquina
¿Qué ciudad?
Primer intento: un iniciador de reparación breve, como el «¿cómo?» entre personas.
- Persona
Ya te lo he dicho.
- Máquina
Puedes escribir el nombre de una ciudad o elegir una de tus últimas búsquedas: Sevilla, Bilbao o Valencia.
Segundo intento: cambia de estrategia y ofrece lo que sí sabe. No repite la misma pregunta.
- Persona
Bilbao.
La ayuda adicional aparece cuando hace falta; no se carga a todo el mundo con instrucciones largas por adelantado. En voz, las opciones deben ser breves y dejar tiempo para procesarlas. En texto se pueden dar ejemplos o botones.
3. Una escalera de reintentos
Repetir exactamente la misma pregunta esperando otro resultado no es reparar. Todo bucle necesita una condición de salida. Como punto de partida, que luego se ajusta con datos:
Míralo
La escalera de reintentos
- Paso 1: Primer fallo: reparación breve (actual)
- Paso 2: Segundo fallo: cambio de estrategia
- Paso 3: Tercer fallo (o antes, si hay riesgo): salida
Paso 1 de 3
Primer fallo: reparación breve
«Tres intentos» no es una regla universal. En una elección sencilla puede bastar un intento y una lista; para dictar un dato difícil puede convenir más tiempo o un canal alternativo. Lo que no cambia es el criterio: cada intento aporta una ayuda nueva y la persona conserva siempre una salida. W3C, en sus notas sobre accesibilidad cognitiva, insiste en lo mismo: alternativas para quien no es reconocido por voz y pruebas con personas diversas para comprobar que no hay bucles frustrantes.
Hay que distinguir tres tipos de reintento, porque tienen causas distintas:
- de comprensión: la respuesta no encaja con lo esperado
- de espera: la persona no responde
- técnicos: un servicio no contesta
4. Fundamentación: comprobar que se comparte lo mismo
Clark y Brennan llamaron fundamentación (grounding) al trabajo que hacen los interlocutores para asegurarse de que comparten lo que se ha dicho: asentir, repetir un dato clave, pedir una aclaración. Cuanto más cuesta un malentendido, más fundamentación hace falta. Es el mismo criterio que guía las confirmaciones de la página anterior.
Para un sistema, fundamentar significa hacer visible lo que ha registrado («Tengo: Sevilla, viernes, por la tarde») cuando de eso depende algo importante, y permitir que la persona lo corrija sin empezar de nuevo.
5. Corregir la causa, no acumular variantes
Las reparaciones son datos sobre el diseño. Leídas en conjunto, dicen qué cambiar:
- si muchas personas malinterpretan la pregunta, reescribe la pregunta
- si piden con frecuencia una tarea que falta, reconsidera el alcance
- si la fuente no tiene la respuesta, corrige el contenido o la expectativa
- si la persona no sabe qué puede decir, mejora las señales
- si un fallo técnico se repite, arregla el servicio o comunica su estado real
La reparación es una red de seguridad, no una licencia para mantener una pregunta confusa.