Antes de automatizar el soporte, automatizamos la decisión de qué automatizar

Íbamos a automatizar el soporte con un agente. Terminamos automatizando otra cosa primero: la decisión de qué vale la pena automatizar. Un clasificador que separa, ticket por ticket, lo que resuelve un workflow de lo que necesita una persona — y por qué el resultado nos hizo construir menos.

En una plataforma financiera, el soporte interno es una fuente constante de interrupciones: pedidos que entran por un canal de chat, mezclados con conversación, cada uno contado a su manera. La tentación, con las herramientas de hoy, es obvia: tirarle un agente de IA encima y que resuelva solo.

Estuvimos a punto. Y frenamos. Esta es la historia de por qué — y de cómo un clasificador que construimos para decidir cuánto automatizar terminó cambiando qué íbamos a construir.

Lo que construimos (y lo que no)

Antes de automatizar nada, quisimos entender la demanda. Así que armamos algo deliberadamente chico: de forma periódica, un modelo lee los pedidos nuevos del canal, los clasifica contra el catálogo de acciones operativas que ya teníamos, y abre un ticket etiquetado con el resultado — o resoluble con esta acción, o necesita una persona.

Un detalle que importa: el MVP no ejecuta nada. Clasifica y deja el ticket. Una persona sigue leyendo y corriendo la acción. Nada que toque dinero se mueve sin aprobación humana. Queríamos la señal, no la automatización todavía.

Lo que la data mostró

El clasificador hace una sola pregunta por ticket: ¿hay un workflow de ops que ya resuelve esto, o necesita una persona? No busca oportunidades nuevas de automatización — compara cada mensaje contra el catálogo de acciones que ya operamos.

En unas cinco semanas, sobre algunas decenas de pedidos, el reparto fue: cerca de cuatro de cada diez ya tenían un workflow que los resolvía — y varias de esas acciones hoy son self-service en el panel. Los otros seis de cada diez no matcheaban ningún workflow y caían en una persona. Antes de sacar conclusiones revisamos una muestra de etiquetas a mano contra el criterio del equipo; se sostenían.

La decisión: no todo de una

Con eso sobre la mesa, decidimos no apurar la ejecución automática ni construirla toda de una. El clasificador se queda — barato, útil — como capa de medición y de triage. La automatización pasó a ser un ítem de backlog que compite por prioridad con el resto y avanza cuando una señal lo justifica: más volumen, o una feature nueva que recree la misma demanda. Empezando por lo de menor riesgo, y con lo que toca dinero siempre detrás de aprobación humana.

Para la parte que ya tiene respuesta, en cambio, automatizar no es avanzar: es optimizar la capa equivocada. Esos pedidos no necesitan un bot que los ejecute — necesitan que exista la vía de self-service, que es un trabajo distinto al de automatizar. La automatización se la guardamos a lo que de verdad la necesita.

Lo que aprendimos

El instinto, con un modelo capaz a mano, es saltar directo a la ejecución. Nuestra experiencia fue al revés: antes de construir un solo bot que resuelva, construimos el que decide — el que separa, ticket por ticket, lo que ya sabemos resolver de lo que necesita una persona. Automatizar la clasificación es barato; nos dio el mapa antes de gastar en el territorio.

Si tu equipo está por tirarle IA a un flujo operativo, un consejo barato: usá el modelo primero para clasificar y medir ese flujo, no para ejecutarlo. Vas a terminar automatizando menos, más tarde y con más confianza — y eso también es una decisión de ingeniería.

Quién lo escribió

  • Matías Ríos
    Matías Ríos LinkedIn
    Tech Lead

    Se ocupa de cómo trabaja el equipo, no solo de qué construye: los estándares, las decisiones y el proceso que sostienen a un equipo chico en una plataforma financiera.

Publicado el . Escrito con ayuda de agentes.