El bot que hace una sola cosa: por qué le quitamos funciones en vez de agregarle

Una institución de educación superior necesitaba atender a los alumnos que escriben para darse de baja. Llegamos a la primera sesión con una propuesta que casi siempre incomoda: que el bot hiciera menos de lo que estaban imaginando.

El problema: la ambición se paga con abandono

El instinto, cuando se compra un bot, es pedirle todo. Que salude, que perfile, que entienda el contexto, que ofrezca alternativas, que maneje objeciones, que intente retener, y ya de paso que registre todo en el sistema. Cada una de esas funciones suena razonable por separado.

Juntas producen una conversación larga con una persona que no quiere conversar. Un alumno que escribe para darse de baja ya tomó una decisión y muchas veces trae encima un problema que le apena contar. Cada pregunta de más es una oportunidad de que cierre la ventana. Y una conversación abandonada no es un alumno retenido: es un alumno que se fue sin que nadie supiera por qué — el peor de los dos desenlaces, porque además no deja aprendizaje.

Hay un detalle que hace este fallo especialmente caro: no aparece en ningún reporte. Nadie mide las conversaciones que no ocurrieron.

La solución: un solo trabajo

El bot tiene un objetivo y nada más: averiguar el motivo de la baja y pasar la conversación, en ese momento, al área que puede resolverlo.

Si el problema es dinero, va al área de financiamiento. Si es académico, va a coordinación académica. Dos rutas, definidas con la institución antes de escribir la primera línea de código. No perfila, no vende, no maneja objeciones, no intenta convencer.

Esa última parte es la que cuesta más trabajo defender en una junta, y es la más importante. El bot no tiene facultad para ofrecer una beca, un cambio de modalidad o una prórroga; la persona del área sí. Pretender que la máquina retenga es ponerla a hacer un trabajo que no puede terminar, y el alumno lo nota a la tercera respuesta genérica.

Los casos incómodos van primero

El flujo feliz —alumno escribe, dice su motivo, se escala— es el más fácil de construir y el menos probable de encontrar en estado puro. Por eso el diseño arrancó por el otro lado, con los tres casos que tumban a un bot de atención:

El alumno que ya pagó y el sistema no registró el pago, que llega molesto y con razón. El que no es alumno, porque marcó mal o le reenviaron el número. Y el número equivocado a secas.

Un bot que no contempla estos tres entra en loop justo con las personas menos dispuestas a tolerarlo. Resolverlos primero cambia el resto del diseño, porque obliga a que el bot sepa reconocer cuándo no es su conversación.

Por qué le importa a la dirección

Un bot ambicioso que se atora no es neutral: destruye conversaciones que una persona habría salvado. Es un resultado peor que no tener bot, y llega disfrazado de modernización.

Cada función que le quitas a un bot de atención es una oportunidad menos de perder a la persona. Va en contra del instinto de comprar la solución que “hace todo”, y es la misma razón por la que empezamos por el proceso y no por la plataforma: la pregunta útil no es qué puede hacer la herramienta, sino qué es lo único que tiene que salir bien.

Las cifras de esta página son decisiones de diseño documentadas en el alcance del proyecto, no resultados de negocio del cliente. Cuando existan resultados medidos, se agregan aquí con su fecha.

¿Tienes un proceso donde la gente llega molesta?

Cancelaciones, reclamos, bajas, soporte de primer nivel. Si tu bot actual pierde esas conversaciones —o estás por comprar uno que hace de todo—, agenda una sesión de 30 minutos. Revisamos qué es lo único que tiene que salir bien.