Quan ha d'escalar un agent d'IA a una persona: com dissenyar el traspàs

Dues històries reals de pilots, amb el mateix producte i resultats oposats. En la primera, l'agent atén la queixa d'un dels clients més grans de l'empresa i insisteix a resoldre-la amb la política estàndard de devolucions. Tècnicament no s'equivoca; comercialment, el dany triga mesos a reparar-se. En la segona, l'agent escala pràcticament tot el que entra "per si de cas". Al cap de tres setmanes, l'equip gestiona el mateix volum de sempre, però ara amb una eina més pel mig, i el pilot es cancel·la per no aportar res.

Cap dels dos agents no va fallar per falta de capacitat. Tots dos van fallar pel mateix: ningú no havia dissenyat el límit entre el que l'agent resol i el que passa a una persona. Aquest límit —quan escalar, amb quin context, a qui i què passa després— és la decisió de disseny més important d'un agent operatiu, per davant del to, els guions o les integracions. I és també la més descuidada, perquè no es veu en una demo.

Aquest article explica com dibuixar-lo. Parlem d'agents que executen fluxos operatius reals —trucades, correus, seguiments, amb estats i registre—, com els que descrivim a com els agents d'IA estan transformant les operacions B2B, no de chatbots que responen preguntes soltes.

L'escalat no és un error de l'agent: és part del disseny

La intuïció equivocada més estesa és tractar l'escalat com una derrota: "si l'agent escala, és que no funciona". D'aquí surten agents configurats per resoldre-ho tot, que és exactament com es fabrica el primer error visible davant d'un client que importa.

La lògica correcta és la contrària. Un agent operatiu val per dues coses: pel que resol sol i per la qualitat amb què lliura el que no li correspon resoldre. La segona meitat és la que protegeix la primera: l'equip confia a deixar volum en mans de l'agent precisament perquè sap que el que és sensible li arribarà a temps i amb context. Sense aquesta confiança, algú acaba revisant-ho tot "per si de cas", i l'estalvi desapareix.

Per això l'escalat es dissenya abans de llançar, amb la mateixa serietat que el flux principal. A la pràctica, forma part d'acotar l'abast —els estats, què es resol sol, les condicions de parada— que ja recomanem definir en triar el primer procés que automatitzar.

Les dues maneres de fallar: escalar massa i massa poc

El límit mal posat falla en dues direccions, i convé reconèixer-les totes dues perquè es corregeixen de manera diferent.

Escalar massa poc produeix errors visibles: una queixa tractada com a consulta rutinària, una condició especial concedida sense criteri comercial, un cas amb implicació legal respost amb una plantilla. Cadascun d'aquests errors és car per si mateix, però el cost real és un altre: la credibilitat del projecte. Un sol cas sensible mal resolt en públic pesa més que cent casos rutinaris ben despatxats.

Escalar massa produeix un fracàs silenciós: l'agent funciona, no comet errors, i tot i així no serveix. Si la meitat dels casos acaben en una persona, l'equip no ha recuperat hores; ha afegit un pas. Aquesta manera de fallar és més traïdora perquè no genera incidents per investigar: simplement, al final del pilot, les mètriques d'estalvi no apareixen, com es veu de seguida en posar en números quant estalvia un agent.

Els dos errors tenen la mateixa arrel: un límit definit per sensacions ("això sembla delicat") en lloc de per regles explícites. La solució no és un agent més llest, és un límit més ben dibuixat.

Resoldre, suggerir, escalar: el límit es dibuixa en tres zones

L'eina pràctica per dibuixar el límit és classificar cada tipus de cas del flux en una de tres zones.

Resoldre. L'agent actua de principi a fi: respon la consulta d'horari, confirma la cita, registra el motiu de la trucada, envia el recordatori. Aquí van els casos amb resposta correcta definible i cost de l'error baix. És la zona que genera l'estalvi.

Suggerir. L'agent prepara la feina i una persona aprova: redacta l'esborrany de resposta a una reclamació, proposa una classificació dubtosa, prepara la fitxa del lead amb la seva recomanació. És la zona intermèdia per a casos en què l'agent aporta el 80 % de l'esforç però la decisió final necessita criteri humà. En una bústia compartida, per exemple, aquesta zona és la diferència entre un pilot prudent i un de temerari.

Escalar. L'agent transfereix el cas complet, amb context, a la persona adequada, i deixa d'actuar-hi. Aquí van els casos sensibles per definició, estiguin ben o mal resolts: la zona no existeix perquè l'agent no en sàpiga, sinó perquè no li correspon.

L'exercici de disseny consisteix a recórrer els tipus de cas del procés i assignar cadascun a una zona, per escrit. La regla d'or: el que no està assignat explícitament acaba a "resoldre" per defecte, perquè és el que l'agent farà si ningú no li diu el contrari. Els buits del mapa són els futurs incidents.

Els senyals que han de disparar un traspàs

Amb les zones definides, falten els disparadors: les condicions concretes que mouen un cas a "escalar" encara que en principi fos rutinari. A la pràctica se'n repeteixen vuit, gairebé amb independència del flux:

• El client demana una persona. Es respecta sempre, a la primera. Insistir a resoldre després d'aquesta petició és la manera més ràpida de cremar la confiança en el canal.
• Llenguatge hostil o càrrega emocional alta. Enuig, amenaça de baixa, menció a reclamació formal. L'objectiu de l'agent passa de resoldre a aterrar bé el traspàs.
• Compte estratègic o import alt. Una llista de comptes i un llindar econòmic que es consulten abans d'actuar, no després.
• Implicació legal o de compliment. Mencions a reclamacions, protecció de dades, condicions contractuals. Zona de persona, sense excepcions.
• Petició de condicions especials. Descomptes, ajornaments, excepcions a la política. L'agent pot capturar la petició; la decisió és comercial, com vam veure als recordatoris de pagament.
• Dades insuficients o contradictòries. Si la font de veritat no respon o es contradiu, l'agent no inventa: escala amb el que té.
• Confiança baixa en la pròpia interpretació. Cas ambigu que no encaixa en cap patró conegut. Millor un escalat de més que una resposta inventada.
• Reintents esgotats. Si després del nombre d'intents definit el cas no avança (ningú no confirma, ningú no signa, ningú no respon), passa a una persona en lloc d'insistir sense límit.

Cada flux hi afegeix els seus —urgències a les trucades fora d'horari, senyals d'intenció a la qualificació de leads—, però aquests vuit cobreixen la majoria dels casos sensibles des del primer dia.

Un bon traspàs és un expedient, no un avís

Aquí es decideix la meitat de l'experiència. Un escalat que només diu "tens un cas pendent" obliga la persona a reconstruir la història i, pitjor, obliga el client a repetir-la. Aquell "ja l'hi he explicat a l'assistent" és el moment exacte en què el client conclou que l'automatització empitjora el servei.

Un traspàs ben dissenyat lliura cinc coses:

• El fil complet: cada missatge, trucada o intent, en ordre, sense resums que substitueixin l'original.
• Un resum operatiu: què demana el client, què s'ha fet ja i —clau— per què s'escala, citant el disparador concret.
• Les dades capturades: client, referència, dates, imports, document pendent. Tot el que l'agent ja va validar, perquè ningú no ho torni a demanar.
• L'estat del cas: en quin punt del flux queda i quines accions automàtiques s'han aturat.
• La urgència: no és el mateix una consulta que pot esperar a demà que un client enfadat amb un servei aturat.

La prova de qualitat és simple: la persona que rep el cas hauria de poder actuar sense fer al client ni una sola pregunta que l'agent ja hagués fet. Si no pot, el traspàs ha fallat, encara que l'enrutament hagi funcionat perfectament.

A qui arriba cada cas: enrutament i urgència

"Escalar a una persona" és una simplificació: en una operació real hi ha diverses persones possibles, i equivocar-se de destinació costa gairebé tant com no escalar. Les queixes de comptes estratègics van al responsable del compte; les peticions de condicions, a comercial; les urgències tècniques fora d'horari, a la guàrdia; la resta, a la cua general de l'equip amb la seva prioritat.

El disseny mínim és una taula de dues columnes —tipus de cas, destinació— més una regla d'urgència: quins casos poden esperar al següent dia laborable i quins avisen immediatament pel canal que l'equip miri de veritat. Sense aquesta taula, tots els escalats cauen a la mateixa safata, els urgents esperen darrere dels trivials i l'avantatge d'escalar a temps es perd a la cua.

Convé definir també el compromís de resposta intern: de res no serveix un traspàs impecable si el cas espera dos dies que algú l'obri. L'agent pot dir al client "una persona de l'equip et contactarà avui" només si l'enrutament i el compromís intern ho fan veritat.

Què passa després del traspàs

Tres decisions tanquen el disseny i solen oblidar-se.

L'agent para. Des del moment del traspàs, cap acció automàtica més sobre aquest cas: ni recordatoris, ni reintents, ni missatges de cortesia. Res no erosiona més la confiança que un client que ja està parlant amb una persona i continua rebent missatges de l'agent.

El tancament queda registrat. Quan la persona resol, el cas es tanca amb el seu resultat al mateix registre on l'agent va documentar la seva part. Sense això, les mètriques del procés es trenquen just en els casos més importants.

Cada escalat ensenya alguna cosa. La revisió periòdica dels casos escalats és el mecanisme de millora del límit: els que la persona va resoldre en un minut amb una resposta estàndard són candidats a passar a "resoldre" o "suggerir"; els casos que l'agent va resoldre sol i després es van reobrir són candidats a nous disparadors. El límit del primer dia és una hipòtesi; el de la setmana vuit hauria de ser millor.

Les mètriques que diuen si el límit està ben posat

Quatre números basten per saber si el disseny funciona, i convé mirar-los junts perquè es compensen entre si:

• Taxa de resolució sense intervenció: percentatge de casos que l'agent tanca sol. És la mètrica de l'estalvi.
• Precisió de l'escalat: dels casos escalats, quants necessitaven de veritat una persona. Els "falsos positius" —casos que la persona retorna o despatxa en un minut— assenyalen un límit massa prudent.
• Fuites: casos que l'agent va resoldre sol i van acabar en reobertura, queixa o correcció. Són els "falsos negatius", els més cars; haurien de tendir a zero en els tipus de cas sensibles.
• Temps fins a persona: quant triga un cas escalat a estar atès. Mesura si l'enrutament i els compromisos interns funcionen.

La trampa habitual és optimitzar la primera a costa de la tercera: apujar la resolució automàtica deixant passar casos que no tocava. Per això es miren juntes. Un bon ajust del límit apuja la resolució sense intervenció i manté les fuites a ratlla; si només aconsegueix una de les dues, el límit està mal posat.

Les primeres setmanes, una taxa d'escalat alta no és mala senyal: és un límit prudent mentre es calibra. El senyal d'alarma és que no evolucioni: mateix percentatge d'escalats la setmana u que la vuit significa que ningú no està revisant i ajustant.

Com hi encaixa BeeAgent

A BeeAgent l'escalat no és una funció afegida: és part del flux des del disseny. Cada agent es configura amb les seves tres zones —què resol sol, què prepara com a suggeriment, què transfereix—, els seus disparadors (petició de persona, comptes assenyalats, llindars, senyals de risc, reintents esgotats) i el seu enrutament per tipus de cas i urgència. El traspàs viatja amb el fil complet, el resum, les dades capturades i el motiu de l'escalat, i el cas queda aturat per a l'agent fins que una persona el tanca.

I com que és una plataforma sense codi, ajustar el límit —afegir un disparador, moure un tipus de cas de "resoldre" a "suggerir", canviar una destinació— ho fa l'equip d'operacions en minuts, sense projecte de desenvolupament. Aquest cicle curt d'ajust és el que permet que el límit millori setmana a setmana, com explica la guia per configurar el teu primer agent sense codi. És, de fet, la diferència de fons entre un agent operatiu i un bot de respostes, que desenvolupem a bot d'atenció al client vs agent d'IA.

Dissenya el límit aquesta setmana

No cal un projecte per començar: cal una tarda i les persones que coneixen el procés.

Primer, llista els tipus de cas del flux que vols automatitzar i assigna cadascun a una zona: resoldre, suggerir o escalar. Tot el que quedi sense assignar, tracta-ho com a buit per tancar, no com a detall menor. Segon, escriu els disparadors partint dels vuit d'aquest article i afegint-hi els teus: la teva llista de comptes estratègics, els teus llindars, les teves urgències. Tercer, dibuixa la taula d'enrutament —tipus de cas, destinació, urgència— i acorda el compromís de resposta intern amb cada destinació.

Amb això llançat, reserva 30 minuts a la setmana per a les dues llistes que afinen el límit: escalats que sobraven i resolucions que es van fugar. Quatre setmanes d'aquest cicle valen més que qualsevol configuració inicial perfecta.

Conclusió

Un agent d'IA operatiu no es jutja només pel que resol, sinó per com lliura el que no li correspon resoldre. El límit entre les dues coses —les zones, els disparadors, el traspàs amb context, l'enrutament i les mètriques que el vigilen— és disseny, no atzar: es defineix abans de llançar i s'afina cada setmana amb dades. Ben posat, és el que permet a l'equip confiar volum real a l'agent sense por de la sorpresa visible; mal posat, és la raó per la qual la majoria dels pilots que fracassen ho fan.

Si estàs dissenyant aquest límit per a la teva operació, als casos d'ús pots veure com es concreta en fluxos reals —de l'atenció al client a les trucades sortints— o escriu-nos i el dibuixem junts sobre el teu procés.