Com preparar les dades de la teva empresa per a un agent d'IA

Quan una pime implementa un agent d’IA sense preparar les dades primer, el resultat és previsible: l’agent comet errors, l’equip desconfia del sistema i el projecte s’atura abans que la inversió generi cap resultat. El problema no és l’agent. És la qualitat del material amb el qual treballa.

L’objectiu d’un agent d’IA en operacions no és substituir l’equip, sinó assumir la capa mecànica del procés perquè les persones de l’equip puguin dedicar el seu temps a la feina que importa de veritat: el criteri, la relació amb el client, les decisions que requereixen context. Per arribar-hi, les dades han de ser prou bones. I a la majoria de pimes, amb una setmana de feina concentrada, ho són.

serpixel (Clever European Business, S.L.) implementa agents d’IA a mida per a pimes en operacions, vendes i atenció al client. En tots els projectes, la fase de preparació de dades és la que determina si l’agent arrenca en setmanes o en mesos. Aquest article recull els passos concrets que seguim abans d’engegar qualsevol agent.

Per què les dades són la base d’un agent d’IA

Un agent d’IA no genera respostes a partir de coneixement general. Pren decisions dins d’un procés acotat fent servir dades reals del negoci: registres del CRM, historials de comandes, catàlegs de producte, tiquets de suport. Si aquestes dades estan incompletes, incoherents o disperses en sistemes sense connexió, l’agent pren decisions dolentes amb les mateixes dades dolentes que tindria una persona.

La diferència és que una persona detecta que alguna cosa no quadra i s’atura. Un agent processa el cas amb el que té.

Això no vol dir que les dades hagin de ser perfectes abans de començar. Vol dir que cal saber quines dades necessita el procés que es vol automatitzar, quina qualitat tenen avui i quins passos cal fer perquè siguin prou bones.

Els tres problemes de dades més habituals a les pimes

Abans de parlar de passos, val la pena nombrar els tres problemes que apareixen amb més freqüència.

Registres incomplets o incoherents

El CRM té clients sense correu electrònic, el ERP té productes sense codi de categoria, l’historial de comandes barreja tres formats de data perquè es va importar de tres sistemes. Aquest tipus de problema no bloqueja el negoci quan el gestiona una persona, perquè la persona omple els buits amb context. L’agent no pot fer-ho.

Un agent que rep una comanda d’un client que no és al CRM ha de prendre una decisió: crear el client automàticament? Derivar a una persona? Demanar més informació? Sense una regla clara i dades de suport, qualsevol opció pot generar feina extra.

Dades disperses en diversos sistemes sense connexió

El proveïdor de correu té el seu historial. El CRM en té un altre. El ERP en té un tercer. I l’equip de vendes té un full de càlcul a Google Drive que és “la versió bona”. Aquesta fragmentació és normal a pimes que han crescut amb les eines que tenien a mà, però bloqueja qualsevol agent que necessiti visibilitat completa del procés.

Un agent d’entrada de comandes necessita saber si el client existeix, quins productes ha demanat abans, quin estoc hi ha disponible i quina és l’adreça de lliurament habitual. Si aquesta informació és en quatre llocs distints i l’agent només pot accedir a dos, les comandes que processi contindran errors.

Informació sense estructura definida

Els missatges de WhatsApp arriben en text lliure. Les notes del CRM són camps de text sense format. Els comentaris de les comandes barregen instruccions de lliurament amb queixes del client i observacions internes. Aquesta informació és recuperable, però requereix que l’agent faci una capa extra d’interpretació, cosa que augmenta la probabilitat d’error.

L’estructura no significa rigidesa. Significa que el procés té regles clares: una comanda sempre porta producte, quantitat i destinació. Una incidència sempre porta client, canal i descripció. Amb aquestes regles, l’agent processa casos complexos de manera consistent.

Cinc passos per preparar les dades abans d’implementar l’agent

Aquests passos no requereixen un projecte de TI de sis mesos. Requereixen una setmana de feina concentrada i accés als sistemes on viuen les dades del procés que es vol automatitzar.

1. Defineix el perímetre de dades del procés

Abans de tocar res, escriu quines dades necessita l’agent per executar el procés de cap a cap. Per a un agent d’entrada de comandes per WhatsApp amb integració a Holded: nom del client, empresa, producte, quantitat, adreça de lliurament, forma de pagament habitual. Res més. El perímetre ha de ser estret.

2. Audita l’estat actual d’aquestes dades

Per a cada camp del perímetre, comprova: quants registres el tenen complet? Amb quins formats apareix? Hi ha duplicats? Aquesta auditoria no ha de ser exhaustiva. Només ha de respondre una pregunta: l’agent trobarà dades prou bones en el percentatge de casos que necessitem perquè el projecte tingui sentit?

Si el 70% de les comandes que arriben per WhatsApp vénen de clients ja registrats al CRM amb els camps mínims complets, l’agent pot començar a treballar amb aquest 70% i derivar el 30% restant a una persona. Si aquest percentatge és del 20%, cal fer més feina primer.

3. Neteja les dades del perímetre

No tot el sistema, només els registres del procés acotat. Si l’agent gestionarà comandes dels darrers 200 clients actius, neteja aquests 200 registres. Això és manejable en una tarda amb un full de càlcul i accés al CRM.

Els problemes més habituals: noms d’empresa amb variants (Empresa S.L., Empresa SL, empresa s.l.), correus amb errors tipogràfics, camps de producte amb descripcions incoherents (ref A-201, a201, A201) i adreces de lliurament en text lliure barrejades amb observacions internes.

4. Estableix regles d’entrada per a dades noves

De res serveix netejar les dades existents si les noves arriben en el mateix estat. Abans d’engegar l’agent, cal definir com es registra la informació nova: quins camps són obligatoris al CRM perquè l’agent pugui operar, quin format fa servir el catàleg de productes, com es documenta una adreça de lliurament.

Això no és burocràcia. És el contracte de dades entre l’equip humà i l’agent. Si l’agent necessita que els productes tinguin referència, descripció i unitat de mesura per processar una comanda, l’equip ha de saber que aquests tres camps són obligatoris quan es crea un producte nou.

5. Dissenya el fallback per als casos que l’agent no pot resoldre

Quan l’agent rep una comanda d’un client que no és al sistema, o un producte que no reconeix, què fa? La resposta no pot ser “que falli en silenci”. El fallback ha de ser part del disseny des del primer dia: derivar a una persona amb prou context perquè pugui resoldre-ho en dos minuts.

Un bon fallback redueix la pressió sobre la qualitat de les dades inicials. Si el 10% dels casos l’agent els passa a una persona, aquest 10% pot millorar-se amb el temps sense aturar el projecte.

Quan les dades són prou bones per arrencar

La resposta pràctica: quan l’agent pot gestionar autònomament el 65-70% dels casos sense errors, el projecte ja té sentit. El percentatge restant va al fallback humà, que amb el temps es redueix a mesura que es van completant les dades i refinant les regles.

L’error més habitual és esperar a tenir les dades perfectes abans d’engegar l’agent. Les dades perfectes no existeixen. El que existeix és un nivell de qualitat suficient per començar a mesurar i millorar. Aquest nivell s’assoleix en setmanes amb els cinc passos anteriors, no en mesos.

Un exemple concret: entrada de comandes per WhatsApp amb Holded

Per concretar, aquest és el perímetre de dades que auditem en un projecte d’agent d’entrada de comandes per WhatsApp amb integració a Holded:

• Al CRM: nom del contacte, empresa, telèfon de WhatsApp com a clau d’identificació, forma de pagament habitual, adreça de facturació, adreça de lliurament.
• Al catàleg de Holded: referència del producte, nom comercial, preu base, unitat de mesura, estoc disponible.
• A l’historial de comandes: darreres sis comandes per client, amb producte, quantitat i data.

Amb aquests tres conjunts de dades nets i accessibles, l’agent pot processar la majoria de comandes habituals sense intervenció humana. L’historial redueix l’ambigüitat en missatges com “el de sempre” o “el mateix que el mes passat”. La referència del producte evita errors per variants de nom. L’adreça de lliurament emmagatzemada evita haver-la de demanar a cada comanda.

Aquest perímetre és estret a propòsit. No necessites tot el CRM net, només els camps que toca el procés.

Si no saps per on començar

Si tens un procés concret en ment però no saps quines dades necessita o en quin estat estan les que tens, el primer pas és una sessió de descoberta. serpixel (Clever European Business, S.L.) duu a terme implementacions d’agents d’IA a mida per a pimes amb operacions repetitives, i la fase de preparació de dades forma part de cada projecte des del primer dia.

La conversa part del procés, no de la tecnologia. Si vols saber si les teves dades són prou bones per començar, reservem 30 minuts a Calendly. Sense compromís de contractació, només la conversa que cal per saber si el projecte té sentit i, si en té, per quin camí començar.