El ticket que estaba listo
Un cliente reporta en Freshdesk, nuestro sistema de tickets, que los saldos no se le actualizan. En nuestro protocolo eso es nivel 2: la operación sigue funcionando, pero ese vendedor no puede trabajar como debería. Tenemos cuatro horas hábiles para responder y dieciséis para resolver.
Uno de los cuatro desarrolladores que se reparten los tickets lo arregla esa misma mañana. Escribe el arreglo en un hilo de Slack, la plataforma de comunicación interna que usamos. Ahí queda.
El reloj del SLA no se detiene cuando el problema se arregla. Se detiene cuando el cliente se entera. Y el cliente se entera cuando Sofi lee ese hilo, vuelve a Freshdesk y se lo cuenta. Esa mañana Sofi estaba en otra cosa.
“A veces el ticket estaba solucionado hace 4 horas, pero como yo no había tenido tiempo de mirar el mensaje en Slack, habíamos roto el SLA hace 2 horas debido a que no pude contestar.”
Sofi es Chief of Staff de Yom y durante más de un año supervisó al equipo de soporte. No arreglaba los tickets. Su trabajo era mirar su lista para saber cuál de los cuatro desarrolladores se encargaba de la app y cuál del admin, etiquetar al que correspondía y después perseguirlo.
“Muchas veces debía mirar mi lista para entender qué pedirle a quién, porque teníamos desarrolladores encargados de la app, el admin, y así. Luego yo misma tenía que hacer seguimiento.”
Había otra parte del protocolo que la obligaba a estar disponible siempre: el nivel de severidad de cada ticket lo asignamos nosotros, por impacto operacional real y no por la urgencia que declara el cliente, dentro de los primeros diez minutos. Alguien tenía que mirar cada ticket en esos diez minutos, y ese alguien era ella.
Dos o tres horas diarias. Cuatro o cinco en los días complicados, prácticamente la mitad de su jornada de trabajo.
“Todo esto me pegaba en mis KPIs y también en mi capacidad de poder gestionar todo el trabajo que tenía.”
El cuello de botella nunca fue arreglar los problemas. Los desarrolladores arreglaban. Era clasificar lo que entraba, empujar lo que se quedaba dormido y avisar que estaban arreglados. Por eso lo primero que Sofi automatizó no fue resolver tickets.
Una semana
Nadie le pidió a Sofi que construyera nada.
“Simplemente lo hice. Estaba cansada de responder tickets y de revisar constantemente los mensajes de Slack para asegurarme de que no rompiéramos el SLA.”
No sabía programar. Lo que sabía era construir flujos en n8n, una herramienta para armar automatizaciones sin escribir código, y cuando necesitaba código se lo pedía a Gemini o a ChatGPT.
Eso no alcanzaba. Un flujo se dispara con un evento y ejecuta pasos en orden. Un agente tiene que estar corriendo en alguna parte, decidir qué hacer en cada caso, usar herramientas y recuperarse cuando algo falla. Así que esa semana aprendió qué era un servidor. Intentó hostear a Nori, su agente, en su computador y no resultó. Después encontró Railway, una plataforma de infraestructura en la nube que sirve para dejar aplicaciones funcionando en internet, y ahí lo dejó.
También tuvo que aprender algo de ciberseguridad básica, cosa que no aparecía en ninguno de sus flujos anteriores. OpenClaw, el framework de código abierto con el que construyó a Nori, le pedía algo distinto.
“Antes trabajaba principalmente con n8n, por lo que ya sabía construir flujos y automatizaciones. OpenClaw me obligó a aprender sobre arquitectura de agentes y sobre cómo optimizar un agente para que funcionara de manera rápida, estable y correcta.”
Una semana completa, y casi todo ese tiempo se le fue en entender la herramienta antes de poder usarla.
La primera versión no resolvía tickets ni los clasificaba. Hacía una sola cosa: poner en el ticket de Freshdesk lo que estaba pasando en Slack, y en Slack lo que llegaba al ticket.
“Por eso la primera función de Nori fue la de hacer un puente en la comunicación entre los devs y el ticket en Freshdesk (o el cliente), porque era lo primero que me quitaba un montón de trabajo de encima.”
De una skill a ocho
Nadie escribió un plan para Nori. Cada capacidad nueva salió de una molestia concreta, y la siguiente apareció cuando la anterior dejó al descubierto el cuello de botella que seguía.
Comunicar. Lleva a Freshdesk lo que ocurre en Slack y al revés: qué cliente es, qué mandó, en qué va el caso.
Asignar. Cuando un ticket hay que escalarlo al equipo técnico, Nori etiqueta al responsable.
Vigilar el reloj. Avisa cuando un ticket se queda dormido o cuando nadie se está haciendo cargo.
Diagnosticar. Trabaja con Yom Expert, el agente interno con acceso al repositorio de datos, para entender a qué se puede deber lo que reporta el cliente.
Proponer el arreglo. Arma una propuesta de cambio y la sube como PR para que un desarrollador la revise.
Analizar el mes. Entrega por qué rompimos SLA y qué habría que mejorar.
Aprender. Cuando detecta que una respuesta se repite para cierto tipo de ticket, la incorpora a su base de conocimiento.
Resumir el día. Abre la mañana con qué tickets hay abiertos y quién está a cargo de cada uno.
Leída en orden, la lista se mueve desde la periferia hacia el centro. Empieza por lo más lejano al problema, que es contarle a alguien que algo ocurrió, y se va acercando al problema mismo: entenderlo, proponer cómo arreglarlo. Nadie decidió ese orden. Fue el que salió.
Las herramientas también cambiaron. Al principio Nori vivía entre Freshdesk y Slack y no hacía nada más que eso.
“Nos servía para tener comunicación entre los devs y Freshdesk sin que dependiéramos de un humano.”
Hoy está conectado además a Yom Expert y a Linear, el sistema donde los desarrolladores organizan y priorizan su trabajo. Linear recibe la información del ticket y la ordena, de modo que llega directamente al lugar donde ellos ya están. Slack quedó solo como canal de comunicación interno y Freshdesk con el cliente.
Dos cambios de modelo
En ocho meses cambiamos dos veces el modelo que hace funcionar a Nori.
Partió con Gemini. Se caía seguido y cometía bastantes errores. En abril decidimos moverlo a Claude; el cambio recién quedó funcionando el 27 de mayo. En junio lo movimos de Claude a OpenAI.
“Gemini tenía muchos errores y Nori se caía muy seguido. Con Claude dejó de pasar, pero luego vimos que OpenAI podía ser mucho más rápido. Lo probamos y efectivamente lo era (y de pasada es más barato).”
Las ocho skills no se rehicieron. Las conexiones a Freshdesk, Slack, Linear y Yom Expert siguieron funcionando igual. La base de conocimiento que Nori había ido armando siguió ahí. Lo único que se cambió fue el modelo que está por debajo.
Los dos cambios se hicieron sin rehacer a Nori. Uno de los dos nos costó un mes.
Mayo
Nori estuvo veintisiete días sin funcionar bien, del 1 al 27 de mayo.
La cadena partió con algo administrativo: se acabaron los créditos que teníamos comprados en Claude. Nori tenía configurado un respaldo para ese caso, Gemini, que viene incluido en nuestro plan de Google Workspace. El respaldo se activó como estaba previsto. Lo que nunca habíamos hecho era probar si ese respaldo servía para lo que Nori hace.
No servía, por tres razones.
La primera fue la cuota. En los registros aparece el error 429 RESOURCE_EXHAUSTED: “You exceeded your current quota”. Venir incluido no quiere decir ilimitado. Nori hace muchas llamadas por ticket y se consumía el cupo disponible rápido.
La segunda es la que más me preocupa. Para hacer su trabajo Nori no conversa: ejecuta. Etiqueta a alguien, escribe en el ticket, consulta el repositorio. Gemini, en vez de ejecutar esas instrucciones, las escribía en Slack como texto. Intentamos forzarlo por configuración y no resultó.
“Nori podía parecer que estaba respondiendo, pero no ejecutaba la acción real.”
La tercera fue que se colgaba. Gemini devolvía turnos vacíos y, como Nori reutilizaba la misma sesión, no lograba recuperarse solo.
Mientras todo eso pasaba, nadie podía entrar a arreglarlo.
“Yo era la única persona con acceso al repositorio y estaba de vacaciones, por lo que nadie podía entrar a corregir la configuración.”
Tampoco teníamos nada que nos avisara. Ninguna alerta, ningún tablero, ninguna revisión automática. Lo que nos avisó fue que los clientes dejaron de recibir respuestas. Diego lo notó y me escribió. Sofi lo vio al volver de vacaciones, entre muchos mensajes acumulados, y mientras tanto quedó otra persona a cargo de responder los tickets sin el contexto necesario para hacerlo.
El 25 de mayo le quitamos a Claude el límite prepagado, para que Nori pudiera seguir funcionando y nos cobraran después. El 27 quedó implementado el cambio y Nori volvió a operar. Una semana más tarde lo movimos a OpenAI.
Mayo fue el peor mes del año en cumplimiento de SLA. Sería cómodo atribuirlo entero a Nori y no sería cierto: ese mes coincidieron tres cosas. Nori caído, Sofi de vacaciones, y 45 tickets contra los 41 de un mes normal.
Teníamos un respaldo y nunca lo probamos. Ese fue el error, y nos lo cobró de la peor manera posible, que es sin hacer ruido: un sistema que se cae da error y alguien lo nota, pero Nori siguió pareciendo activo durante veintisiete días.
Los PRs
De las ocho capacidades de Nori, la que más se acercaba al trabajo de verdad era proponer el arreglo: armar un PR —la forma en que un programador propone un cambio al código para que otro lo revise antes de aplicarlo— y dejarlo listo.
Nori propuso siete en toda su historia.
Seis fueron en un mismo ticket. Los seis se aprobaron y se incorporaron tal como venían, y no funcionaron: hubo que seguir iterando sobre el problema después. El séptimo quedó como borrador y terminó reemplazado por cambios que hizo un desarrollador trabajando con Claude.
Después de eso nadie le volvió a pedir un PR.
“Normalmente era yo quien se los solicitaba, pero al ver que no se estaban utilizando y que solo agregaban ruido al ticket, dejé de pedírselos.”
Lo que ocurre hoy es que el diagnóstico de Nori se usa y el arreglo no. Antes de aprobar una propuesta suya, el desarrollador rehace toda la investigación por su cuenta, con Claude, y sube los cambios desde ahí. El motivo es más concreto que una desconfianza hacia los agentes.
“Los devs no pueden ver el proceso completo que siguió Nori y prefieren mantener control sobre lo que se modifica en el código.”
Revisar un PR de Nori cuesta más que rehacer el trabajo, porque para revisarlo hay que reconstruir un razonamiento que no quedó escrito en ninguna parte: qué miró, qué descartó, qué probó. Sofi defiende la postura de los desarrolladores, y tiene razón.
“Me parece una preocupación razonable, porque al menos existe la sensación compartida de que el código base tiene problemas. En ese contexto, es lógico que quieran entender muy bien qué se va a tocar y por qué.”
Al trabajo duplicado se le suma otra cosa. Como el desarrollador resuelve por otro lado, Nori nunca se entera de si su propuesta era correcta, y nosotros tampoco.
Le preguntamos a Sofi qué tendría que entregar Nori para que un desarrollador aprobara un PR sin rehacer la investigación: la causa probable con evidencia concreta, qué archivos revisó y por qué cada cambio, qué alternativas descartó, qué verificaciones ejecutó y con qué resultado, qué no pudo comprobar y qué requiere revisión humana. Y pidió algo sobre el formato.
“Slack es poco amistoso para los textos demasiado largos y, en general, he observado que el equipo deja de leer cuando la explicación es extensa. Nori debería entregar suficiente evidencia para generar confianza, pero en un formato que pueda escanearse rápidamente.”
Nadie decidió apagar esa capacidad. Simplemente dejamos de usarla.
Agosto y los números
En agosto Nori empezó a contestar esto en Slack:
“You have hit your ChatGPT usage limit (prolite plan). Try again in ~2443 min.”
Dos mil cuatrocientos cuarenta y tres minutos son cuarenta horas. Y no fue culpa de Nori.
Con el tiempo que Nori le había liberado, Sofi construyó un segundo agente: Yomi, que acompaña el onboarding y los temas de cultura interna. Los dos comparten la misma cuenta de suscripción y, por lo tanto, el mismo límite de uso. Cuando a Yomi le agregamos la capacidad de navegar páginas web, su consumo subió, y el que se quedó sin capacidad para responder fue Nori. Subimos de plan y se resolvió.
Nori no corre sobre una API que cobre por consumo. Corre sobre una suscripción, que costaba unos US$100 al mes y pasó a US$170 cuando subimos de plan. En mayo, cuando le quitamos el límite prepagado a Claude, esa semana de consumo libre nos costó US$600. Los dos esquemas fallan distinto: con suscripción chocas contra un techo y tu operación se detiene; con consumo no hay techo, hay factura.
Los tickets no bajaron. Entre enero y septiembre recibimos 369, unos 41 al mes, y la línea es plana.
El cumplimiento de SLA tampoco mejoró. Enero cerró en 89,6%, marzo en 97,6%, mayo en 80% y septiembre en 92,5%: un número plano y con ruido. El mejor mes del año fue marzo, con un Nori mucho más simple que el de hoy.
Lo que sí cambió fue el tiempo de Sofi.
Antes dedicaba unas dos horas y media diarias a coordinar tickets: 52 horas al mes para 41 tickets, es decir 77 minutos de Chief of Staff por cada ticket. A US$25 la hora, cada ticket costaba unos US$32. Hoy le dedica cinco minutos al día y revisa uno de cada tres: alrededor de tres minutos por ticket.
La suscripción que mueve a Nori cuesta US$170 al mes. Repartida entre 41 tickets, son US$4 por ticket. Treinta y dos dólares de tiempo humano contra cuatro de software: aguanta que le multipliquen el precio por ocho y sigue conviniendo.
Nori no mejoró nuestro servicio. Cambió cuánta atención humana cuesta sostenerlo en el mismo nivel.
Lo que aprendimos
Lo primero no es sobre tecnología. La persona que tenía el problema fue la que construyó la solución, en una semana, sin saber programar y sin pedirle permiso a nadie. No hubo proyecto, comité ni presupuesto.
El modelo resultó ser la pieza reemplazable. Lo cambiamos dos veces y no hubo que rehacer nada: lo que costó construir fueron las skills, las conexiones y el conocimiento acumulado, y todo eso sobrevivió.
Un agente puede fallar sin hacer ruido, y eso sí es nuevo. Un sistema que se cae da error y alguien lo nota. Nori pasó veintisiete días pareciendo que trabajaba. El riesgo no es que la inteligencia artificial se equivoque: es que entregue algo plausible y todo parezca normal.
Que una sola persona tuviera acceso al repositorio convirtió una falla de un día en una de un mes.
El costo depende menos de cuánto uses el agente que del esquema en que lo estés pagando. Y si tienes dos agentes en la misma cuenta, comparten un límite que alguien tiene que administrar; si nadie lo hace, uno le quita la capacidad al otro sin avisarle a nadie.
Las capacidades que no funcionan tampoco se apagan. Nadie las evalúa, nadie decide, nadie lo anota en ninguna parte: simplemente se dejan de pedir.
La orden que no funcionó
Durante más de un año pedí que en Yom adoptáramos inteligencia artificial. Lo dije en reuniones, lo puse en objetivos, lo repetí muchas veces. No pasó nada.
Lo que pasó fue que alguien se cansó de un proceso y lo resolvió por su cuenta. La empresa se movió cuando el agente lo construyó la persona que sufría el problema.
Y después vino la parte que no había previsto. Con el tiempo que Nori le devolvió, Sofi no se puso a hacer más de lo mismo: construyó el siguiente agente. La eficiencia que ganamos en soporte se transformó en capacidad nueva en otra parte de la empresa, y esa es la única manera en que he visto que esto se componga.
Por eso insisto en que lo aburrido vale dos veces. Vale la primera porque ahí está la plata de este año: el proceso que nadie quiere mirar es el que tiene el costo por tarea más alto y la mayor proporción de trabajo repetido. Y vale la segunda porque, cuando funciona, alguien más lo ve. El tiempo que recuperó Sofi se convirtió en otro agente, y ese resultado hizo que un ingeniero se tomara en serio un proyecto que había empezado una persona que no sabía programar.
Coordinar tickets de soporte era, por lejos, lo más aburrido que teníamos. Nos costó veintisiete días caídos, seis cambios de código que no funcionaron y una semana de US$600 entender qué había ahí adentro.
Desde septiembre, Nori dejó de ser el agente que intenta hacerlo todo. Hoy es la primera pieza de una cadena: clasifica el ticket y detecta si ya vimos uno parecido, y de ahí el caso pasa a otro agente, Atalaya SRE, que lo arma con la evidencia y se lo entrega al desarrollador listo para trabajar. Eso lo construyó Jhossep, uno de nuestros ingenieros, encima de lo que había hecho Sofi.
Es la misma idea que ella había pedido para los PRs: que el agente no entregue una conclusión, sino el camino. En tres semanas van más de treinta casos entregados así, de seis clientes, y seis de cada diez tickets nuevos llegan con un antecedente de la misma familia. También existe ahora Atalaya, que es justamente lo que no teníamos en mayo: alertas con su propio instructivo para cuando algo se rompe.
Una Chief of Staff que no sabía programar construyó la primera versión en una semana. Un ingeniero construyó la segunda encima. Eso es lo aburrido pagando por segunda vez.