One of our hospitality clients —a boutique hotel of around 50 rooms in a European alpine tourist area— came to MindRise with a problem that's barely noticeable but weighs heavily on day-to-day operations: the reception staff spent around 2-3 hours daily answering the same queries over and over again. Spa opening hours, restaurant recommendations, how to get to the nearest chairlift, weather forecasts for the coming days, how to book a table at the hotel restaurant. Multiplied across four languages —Spanish, English, French and Catalan— and across a high season of five months a year.
The net calculation, done with the hotel director, came to around 42 hours per month of qualified staff time spent on repetitive tasks. Time that couldn't be allocated to check-ins, in-person attention, real guest problems or team coordination. Management had identified it as a clear improvement point but didn't know where to start.
This article explains the case step by step: what we found in the diagnosis, why the obvious solution (a chatbot) wasn't enough, how we designed the solution that was finally implemented and what results we measured three months into production.
The problem in detail
When we analyse a case, we always start by asking for a sample of a real week's flow. In this hotel, the sample included:
- 87 WhatsApp queries in a week, across four different languages
- 34 in-person reception queries about topics that could be solved by message
- 12 phone calls of the same nature
- An average time distribution of 8-12 minutes per query (including information lookup, response drafting, possible follow-up)
The pattern was predictable: 70% of queries repeated week after week. Restaurant recommendations 10 minutes' walk away. The nearest chairlift's schedule. Whether the spa was open on Sundays. Whether dinner at the hotel restaurant needed to be reserved. The snow forecast for the next three days.
This query profile has two characteristics: they are easily automatable (response with structured information) and, at the same time, require updated context (today's weather, this weekend's local events, schedules that change by season). It's not the typical static FAQ. We needed a solution that combined an in-house knowledge base with access to real-time data.
Why a standard chatbot wouldn't do
This is where a distinction we always try to explain to clients before proposing anything comes in. A traditional chatbot —the kind that gets deployed on a standard platform with three prompts— would have solved 30-40% of queries. It would have been capable of answering fixed schedules and static questions. But it would have failed on the remaining 60%: queries requiring access to external systems (weather, events, availability), those needing fluid multilingual drafting, and those that have to escalate to a person when things get complicated.
The other extreme option —building a complex agent with planning architecture— would have been overengineering for this case. We didn't need the system to "reason" about long sequences of actions. We needed it to respond well, in four languages, with fresh context, and to know when to hand off to reception.
The conclusion after the diagnosis was clear: we needed an intermediate architecture. A system with agent capabilities to make external queries in real time, but with a simpler design than a general-purpose agent. What we technically call a hybrid system, but explain to the client as "an assistant that knows what it knows about your hotel, searches for what it doesn't when it needs to, and knows when to keep quiet and alert your team".
The solution we designed
The final architecture combined seven key components, each with a specific function:
WhatsApp Business API as the main channel. It's where guests already write, so there was no need to educate them on a new interface. Connected via Meta's official API, not through third parties, because we wanted complete control over data flow and to meet the hotel's privacy requirements.
Kapso as the conversation orchestration layer. It handles maintaining the context of a conversation over time (the same guest can write Wednesday night and continue the conversation Thursday morning), managing turn flow, and deciding when to hand off to a human.
n8n self-hosted as the integrations engine. This is where everything happens: connection with the hotel's knowledge base, queries to external services, reading and writing to Google Sheets for operational logging, fallback management. Self-hosted because guest data never leaves the client's infrastructure.
GPT-4.1-mini as the main generation model. It was the best quality-cost-speed ratio for the case. More powerful models offered marginally better responses at a much higher cost; smaller models didn't maintain the multilingual quality we required.
Perplexity as the source of real-time updated information. When a guest asks about the weather forecast, this weekend's events or today's ski pass price, Perplexity responds with up-to-date information, not stale data from the model's training.
Redis for session management and short-term memory of each conversation.
PostgreSQL for persistent logging of all interactions, without including personally identifiable data. Essential for audit, continuous improvement and compliance.
The whole system operates in four languages with automatic detection from the first message. If a guest starts in French, the entire conversation continues in French unless they explicitly switch. Detection was one of the trickiest points: short opening messages ("Hi") are ambiguous between Catalan and Spanish, so we had to tune the system with intelligent fallback rules.
Measurable results at 3 months
Three months after going to production, we did the objective measurement with the hotel director. The results:
Staff workload reduction: 42 hours/month freed from reception staff on repetitive queries. Equivalent to about 1.4 hours of qualified staff per day.
Query coverage: 73% of incoming queries are resolved completely by the system with no human intervention. The remaining 27% gets escalated to reception with full context, not as a "new message": the team knows what's been asked, what's already been answered, and why it's being escalated.
Response time: 4-8 seconds average for the 73% automated. Before, after-hours messages could go unanswered for 2-6 hours. Now the first response is immediate 24/7.
Effective multilingual: 4 languages in production with automatic detection. The actual distribution was 38% Spanish, 27% French, 21% English, 14% Catalan. Without the system, the hotel only guaranteed fluid attention in two languages at reception during daytime hours.
Operational cost: approximately €80/month in AI costs (models + Perplexity + shared infrastructure). Compared to the cost of staff time freed, ROI was positive from the first month.
These aren't theoretical numbers: they're measured with real data over three months of production.
What we learned
Three key lessons from this project that we now apply to similar cases:
1. Language detection is worth working on properly. First messages are short and ambiguous. We had an initial bug where the system defaulted to the wrong language when the Redis session hadn't yet been created. It was a day of debugging, but once fixed, the reliability of the multilingual system jumped significantly.
2. Integration with human staff is as important as automation. The 27% of queries that get escalated aren't system "failures". They're exactly what we wanted: the system knows when it's not up to it and passes it to humans with context. This design —the "knowing when to be quiet"— was one of the most important product decisions, not a concession.
3. The most expensive model isn't always the best. We did evaluations with GPT-4o, Claude Sonnet and GPT-4.1-mini. The quality difference perceived by guests was minimal; the cost difference was 3-5x. For this specific case, mini was the right decision. For a banking or legal case, it would probably have been the other way around.
Conclusion
This project is a relatively typical case of what we do at MindRise: a real operational problem, a design scoped to the necessary complexity, an architecture agnostic to any specific tool, and measurable results. It's not a pilot that never leaves testing; it's a system in production that keeps working every day.
If you have a similar case —repetitive operational tasks, multilingual, integration with external systems—, get in touch. We'll give you an honest assessment before proposing anything. Sometimes the case justifies a system like this. Other times a simpler solution already solves the problem. The difference between the two answers is something we know after looking at the real data, not before.