Por qué tener equipo de IT propio no reemplaza la experiencia en agentes

Dicen que nadie escarmienta en cabeza ajena. En implementaciones de agentes de IA, escarmentar en cabeza ajena es exactamente lo que se compra cuando se trabaja con alguien que ya hizo esto varias veces.

Un equipo interno, por bueno que sea, ve un caso: el suyo. Y la diferencia entre un equipo y otro casi nunca es de talento técnico. Es cuántas veces vio romperse lo mismo.

¿Qué es concretamente lo que se aprende repitiendo?

Una lista de situaciones que no aparecen en ninguna documentación porque no son de la tecnología: son del choque entre la tecnología y cómo funciona una empresa de verdad. Cinco de esa lista, todas vistas en implementaciones reales.

Un seguimiento automático configurado en días calendario que sale un domingo, cuando no hay nadie del otro lado para atender la respuesta.

Un número de WhatsApp bloqueado por patrones de envío anormales, cosa que pasa y que hay que prevenir desde el diseño del flujo, no cuando ya pasó.

Un criterio de qué cuenta como tarea resuelta que nadie escribió antes de empezar, y que aparece por primera vez el día de la primera factura, que es el peor día posible para discutirlo.

Un cliente que en vez de escribir manda un audio de dos minutos, o una foto de una foto, y el proceso no lo contemplaba.

Una regla de distribución por zona que asigna el lead a una sucursal donde ese día no hay nadie, porque la regla se escribió mirando el mapa y no el turno.

¿Por qué nada de esto está publicado?

Porque no es conocimiento general, es casuística. La documentación de las plataformas explica qué se puede hacer, no qué sale mal. Y lo que sale mal casi nunca es un error técnico: es una combinación puntual del proceso de esa empresa con una regla de la plataforma con una costumbre del equipo.

Nadie escribe eso porque no se puede generalizar. Se acumula, que es distinto.

¿Un equipo de IT interno no aprende lo mismo?

Aprende exactamente lo mismo. La diferencia es el orden en que lo aprende y quién está adelante mientras aprende.

Un equipo que implementa agentes seguido llega al proyecto nuevo con esa lista ya escrita y la usa como checklist en la primera reunión de configuración. Un equipo interno la va descubriendo, y cada punto de la lista se descubre con un cliente real del otro lado. El costo no es de horas de ingeniería. Es de conversaciones que salieron mal antes de que alguien supiera que ese caso existía.

¿Qué habría que pedirle entonces a un socio?

Tres cosas concretas, y las tres se piden antes de firmar.

Que traiga la lista de situacionales a la primera reunión, no que la arme con el cliente sobre la marcha. Si la conversación arranca por "contame tu proceso" y no aparece ninguna pregunta incómoda, esa lista no existe.

Que diga qué no va a funcionar. Un proveedor que dice que sí a todo está prometiendo algo que después va a negociar en la implementación.

Que cuente un caso donde se equivocó y qué cambió después. No hay forma de acumular casuística sin haberse equivocado en el camino, así que un socio que no puede nombrar ni un caso propio está contando otra historia.

¿Cuándo no hace falta un socio?

Cuando el proceso es simple de verdad: un solo canal, sin integraciones con sistemas propios, con respuestas que no dependen del estado de nada y con volumen bajo. Ahí, un equipo interno lo resuelve y no hay ninguna razón para sumar a nadie más.

El problema es que casi ningún proceso que valga la pena automatizar cumple las cuatro condiciones. En cuanto una sola se rompe, empieza la lista de arriba.