Un dels nostres clients d'hostaleria —un hotel boutique d'unes 50 habitacions en zona turística alpina europea— va arribar a MindRise amb un problema que es nota poc però que pesa molt en el dia a dia: el personal de recepció dedicava unes 2-3 hores diàries a contestar les mateixes consultes una vegada darrere l'altra. Horaris de l'spa, recomanacions de restaurants, com arribar al telecadira més proper, què hi ha de meteorologia per als propers dies, com reservar una taula al restaurant de l'hotel. Multiplicat per quatre idiomes —espanyol, anglès, francès i català— i per una temporada alta de cinc mesos a l'any.
El càlcul net, fet amb el director de l'hotel, sortia a unes 42 hores al mes de temps real de personal qualificat dedicat a tasques repetitives. Temps que no es podia destinar a check-ins, a atenció presencial, a problemes reals dels hostes ni a coordinar equips. La direcció ho havia identificat com un punt clar de millora però no sabia per on començar.
Aquest article explica el cas pas a pas: què trobàrem al diagnòstic, per què la solució òbvia (un chatbot) no era suficient, com vam dissenyar la solució que finalment es va implantar i quins resultats vam mesurar als tres mesos d'estar en producció.
El problema en concret
Quan analitzem un cas, sempre comencem demanant una mostra del flux real d'una setmana. En aquest hotel, la mostra incloïa:
- 87 consultes per WhatsApp en una setmana, en quatre idiomes diferents
- 34 consultes a recepció presencial sobre temes que es podrien resoldre per missatge
- 12 trucades telefòniques amb la mateixa naturalesa
- Una distribució del temps mitjana de 8-12 minuts per consulta (incloent cerca d'informació, redacció de la resposta, possible seguiment)
El patró era predictible: el 70% de les consultes es repetia setmana rere setmana. Recomanacions de restaurants a 10 minuts a peu. Horari del telecadira més proper. Si l'spa estava obert els diumenges. Si calia reservar el sopar al restaurant de l'hotel. Quina previsió hi havia de neu per als propers tres dies.
Aquest perfil de consultes té dues característiques: són fàcilment automatitzables (resposta amb informació estructurada) i, alhora, requereixen context actualitzat (meteorologia avui, esdeveniments locals aquest cap de setmana, horaris que canvien per temporada). No és el típic FAQ estàtic. Necessitàvem una solució que combinés base de coneixement pròpia amb accés a dades en temps real.
Per què un chatbot estàndard no servia
Aquí entra una distinció que sempre intentem explicar als clients abans de proposar res. Un chatbot tradicional —del tipus que es desplega en una plataforma estàndard amb tres prompts— hauria resolt el 30-40% de les consultes. Hauria estat capaç de respondre horaris fixos i preguntes estàtiques. Però hauria fallat en el 60% restant: les consultes que requereixen accés a sistemes externs (meteorologia, esdeveniments, disponibilitat), les que necessiten redacció multidioma fluida, i les que han de redirigir a una persona quan la cosa es complica.
L'altra opció extrema —construir un agent complex amb arquitectura de planificació— hauria estat sobreingeniería per aquest cas. No calia que el sistema "raonés" sobre seqüències llargues d'accions. Calia que respongués bé, en quatre idiomes, amb context fresc, i que sabés quan derivar a recepció.
La conclusió després del diagnòstic va ser clara: necessitàvem una arquitectura intermèdia. Un sistema amb capacitats d'agent per fer consultes externes en temps real, però amb un disseny més simple que un agent generalista. El que tècnicament anomenem un sistema híbrid, però que al client li expliquem com "un assistent que sap el que sap del teu hotel, busca el que no sap quan ho necessita, i sap quan callar i avisar al teu equip".
La solució que vam dissenyar
L'arquitectura final va combinar set components clau, cadascun amb una funció específica:
WhatsApp Business API com a canal principal. És on els hostes ja escriuen, així que no calia educar-los en una nova interfície. Es va connectar mitjançant l'API oficial de Meta, no a través de tercers, perquè volíem control complet sobre el flux de dades i complint amb requisits de privacitat de l'hotel.
Kapso com a capa d'orquestració de la conversa. S'encarrega de mantenir el context d'una conversa al llarg del temps (un mateix hoste pot escriure dimecres a la nit i continuar la conversa dijous al matí), gestionar el flux de torns, i decidir quan derivar a un humà.
n8n self-hosted com a motor d'integracions. Aquí és on passen totes les coses: connexió amb la base de coneixement de l'hotel, consultes a serveis externs, lectura i escriptura a Google Sheets per a registre operatiu, gestió de fallbacks. Self-hosted perquè les dades dels hostes mai surten de la infraestructura del client.
GPT-4.1-mini com a model principal de generació. Era la millor relació qualitat-cost-velocitat per al cas. Models més potents oferien marginalment millor resposta a un cost molt superior; models més petits no mantenien la qualitat multilingüe que requeríem.
Perplexity com a font d'informació actualitzada en temps real. Quan un hoste pregunta per la previsió meteorològica, els esdeveniments d'aquest cap de setmana o el preu de les forfaits avui, Perplexity respon amb informació al dia, no amb dades obsoletes del training del model.
Redis per a la gestió de sessions i memòria a curt termini de cada conversa.
PostgreSQL per al registre persistent de totes les interaccions, sense incloure dades personals identificables. Imprescindible per a auditoria, millora contínua i compliance.
Tot el sistema opera en quatre idiomes amb detecció automàtica del primer missatge. Si un hoste comença en francès, tota la conversa segueix en francès tret que canviï explícitament. La detecció va ser un dels punts més delicats: els primers missatges curts ("Hola") són ambigus entre català i castellà, així que vam haver d'afinar el sistema amb regles de fallback intel·ligent.
Resultats mesurables als 3 mesos
Tres mesos després de la posada en producció, vam fer la mesura objectiva amb el director de l'hotel. Els resultats:
Reducció de càrrega de personal: 42 hores/mes alliberades del personal de recepció en consultes repetitives. Equivalent a unes 1,4 hores de personal qualificat per dia.
Cobertura de consultes: el 73% de les consultes entrants es resolen completament pel sistema sense intervenció humana. El 27% restant es deriva a recepció amb context complet, no com a "missatge nou": l'equip sap què s'ha demanat, què s'ha respost ja i per què s'està derivant.
Temps de resposta: 4-8 segons de mitjana per al 73% automatitzat. Abans, els missatges fora d'hores podien quedar sense resposta durant 2-6 hores. Ara la primera resposta és immediata 24/7.
Multidioma efectiu: 4 idiomes en producció amb detecció automàtica. La distribució real va ser un 38% castellà, 27% francès, 21% anglès, 14% català. Sense el sistema, l'hotel només garantia atenció fluida en dos idiomes a recepció en hores diürnes.
Cost operatiu: aproximadament 80€/mes de costos d'IA (models + Perplexity + infraestructura compartida). Comparat amb el cost de personal alliberat, el retorn d'inversió va ser positiu des del primer mes.
Aquests no són números teòrics: són mesurats amb dades reals durant tres mesos de producció.
Què vam aprendre
Tres lliçons clau d'aquest projecte que apliquem ara a cassos similars:
1. La detecció d'idioma val la pena treballar-la bé. Els primers missatges són curts i ambigus. Vam tenir un bug inicial en el qual el sistema queia per defecte a un idioma equivocat quan la sessió de Redis encara no s'havia creat. Va ser un dia de debug, però una vegada arreglat, la fiabilitat del sistema multilingüe va saltar significativament.
2. La integració amb el personal humà és tan important com l'automatització. El 27% de consultes que es deriven no són "fracassos" del sistema. Són exactament el que volíem: el sistema sap quan no està a l'alçada i ho passa a humans amb context. Aquest disseny —el "saber callar"— va ser una de les decisions de producte més importants, no una concessió.
3. El model més car no sempre és el millor. Vam fer evaluacions amb GPT-4o, Claude Sonnet i GPT-4.1-mini. La diferència de qualitat percebuda pels hostes va ser mínima; la diferència de cost era 3-5x. Per a aquest cas concret, mini era la decisió correcta. Per a un cas de banca o legal, probablement hauria estat al revés.
Conclusió
Aquest projecte és un cas relativament típic del que fem a MindRise: un problema operatiu real, un disseny acotat a la complexitat necessària, una arquitectura agnòstica de cap eina concreta i resultats mesurables. No és un piloto que mai surt de proves; és un sistema en producció que continua funcionant cada dia.
Si tens un cas similar —tasques operatives repetitives, multidioma, integració amb sistemes externs—, escriu-nos. Et donarem una valoració honesta abans de plantejar res. A vegades el caso justifica un sistema com aquest. Altres vegades una solució més simple ja resol el problema. La diferència entre les dues respostes la sabem després de mirar les dades reals, no abans.