The problem
EHL is one of the world’s leading hospitality and management institutions. Its website attracts several million visitors a year, generating significant volumes of recurring questions historically handled manually by EHL’s marketing and admissions teams.
EHL’s web presence is rich but vast: hundreds of pages across multiple domains, PDFs, and ancillary documents. Information existed but wasn’t always easy to find, leading to a high volume of phone calls and emails on recurring questions (programs, fees, admissions, campus life). Many of them came outside business hours, when no one was available to respond, despite EHL’s strongly international audience.
The challenge:
- Deliver fast, accurate answers grounded in official content (zero tolerance for hallucinations on a public-facing institution)
- Respond in EHL’s tone, reflecting its editorial standards
- Capture high-intent visitors as qualified leads with full conversation context
- Maintain GDPR / Swiss nLPD compliance with strict data residency
- Operate at production-grade scale and latency, with full observability
My role
This project was developed when I was working as an AI consultant for Novatix. I led the project end-to-end, including:
- Initial discovery and AI use-case prioritization with EHL’s leadership
- Data architecture: content mapping, categorization, and indexing strategy
- Choice of tech stack (given EHL’s constraints and preferences)
- RAG system design and implementation
- Guardrail architecture and evaluation pipelines
- Agentic workflows (lead capture, CRM integration)
- Latency optimization and infrastructure scaling
- Leading the testing phase (both human and LLM-as-a-judge)
- Reporting and observability dashboard
- Production deployment on Azure
Technical approach
Content discovery & prioritization
The project began with a full audit of EHL’s web ecosystem. I mapped content into thematic categories (academic programs, admissions, campus life, etc.) and worked with EHL’s marketing and admissions teams to identify high-priority question patterns rooted in real user behavior instead of assumptions. The first production version targeted the main domain (ehl.edu), deliberately excluding the blog (thousands of articles with low Q&A signal) and satellite domains (graduate studies, Passugg, Singapore).
RAG architecture with metadata enrichment
The content was crawled with Firecrawl, because it’s excellent in converting web pages into structured markdown formatting. Then, the content was processed through a custom chunking pipeline: each chunk was enriched with structured metadata — page title, URL, section context and a description — to mitigate the classic RAG failure mode where chunk-level context loses the meaning held by the parent document.
The vector store was initially built on Pinecone, then migrated to Postgres + pgvector to consolidate infrastructure on Azure, reduce vendor lock-in, and lower operational cost. The corpus is re-indexed automatically every month: stale chunks are pruned, new pages embedded, modified content refreshed.
The chunks were separated into an english and a french database, with a metadata parameter giving the language.
Tone alignment & guardrails
The chatbot is built on an architecture based on LangChain. EHL’s editorial guidelines, brand values, and email-response patterns were encoded into the system prompts and retrieval behavior, so the chatbot can accurately answer while keeping EHL’s voice and identity.
The chatbot rephrases the user’s query to improve retrieval, and detects the language it was asked in to filter the metadata and query chunks in the matching language.
To meet EHL’s compliance and brand-safety requirements, I implemented a two-stage validation pipeline: every generated response is passed through a lighter, secondary LLM whose sole job is to validate compliance with EHL’s policies, detect prompt-injection attempts, and block unsafe or off-brand outputs before they reach the user. Every response cites its sources for full traceability.
Agentic capabilities
The chatbot can detect high-intent users (qualifying questions about applications, programs, costs) and propose to follow up by email or phone to connect to a recruiter. When a visitor opts in, an n8n workflow captures the contact details and the conversation context, and pushes them into EHL’s HubSpot CRM, enabling recruitment teams to follow up with rich, qualified context. This way, passive web visits are turned into actionable leads and recruiters can jump into the action instead of starting over every time.
Scalability & infrastructure
The entire system runs on EHL’s Microsoft Azure tenant in Switzerland, ensuring GDPR and nLPD compliance with Swiss data residency. Concurrent request handling is scaled through Azure Managed Redis with BullMQ job queues, letting the architecture absorb bursts of simultaneous conversations without latency degradation. The system is designed to handle hundreds to thousands of concurrent users: built for traffic spikes tied to marketing campaigns or program announcements. In practice, it has never reached such high numbers, but the infrastructure is there.
Evaluation: human + automated
Pre-deployment validation combined two layers: dozens of EHL stakeholders stress-tested the chatbot across teams (admissions, marketing, IT, leadership), and an automated LLM-as-a-judge evaluation pipeline scored responses on accuracy, tone, citation quality, and adherence to EHL’s editorial standards. This dual approach made it possible to iterate confidently without sacrificing quality.
Gathering opinions from across EHL’s teams mattered here specifically: the chatbot was public-facing and had to cover a wide range of subjects, and only through each stakeholder’s own perspective could we shape it to actually sound like EHL rather than like a generic assistant with EHL’s logo on it.
Latency optimization
The initial average response time of 7–8 seconds was considered too slow. After a few iterations, I was able to cut it in half (to 3–4 seconds) through a variety of methods:
- Model selection tuning (right-sizing per task)
- Prompt compression and context-window management
- Retrieval pipeline optimization
- Vector DB migration (Pinecone → Postgres/pgvector), although here the gain was negligible
Observability & reporting
Once the Digital Assistant was live, we naturally wanted to know how it was impacting users and EHL’s stakeholders. Therefore, I created an automated reporting pipeline tracking operational and business KPIs: question resolution rate, lead capture rate, latency, geographic distribution, language breakdown, peak usage patterns, user segmentation, and topic distribution, fueling both ongoing optimization and EHL’s marketing intelligence. This pipeline was also connected to their Google Analytics platform in order to track which campaign yielded the best engagement through the chatbot and understand the website visitors’ whole user journey.
The chatbot is an acquisition lever, turning interactions into qualified leads our recruitment teams can act on directly.
Marjo Jarvinen, Marketing and Recruitment Director, EHL
Outcome
The chatbot has been live in production on ehl.edu since its deployment in August 2025. Here are some key impact metrics from its first year of use:
- 63% of the questions are asked outside EHL’s business hours, a demand the institution couldn’t have served otherwise
- ~80% of questions are resolved directly by the chatbot
- ~75% of the remaining, unresolved questions are correctly redirected to the right human service
- ~7% of users opt in to be contacted. They become qualified leads delivered into HubSpot with conversation context for an EHL recruiter to pick up
- EHL international reach reflected in usage: the majority of conversations are in English, with a primary user base across Europe and Asia
What I’d do differently
With hindsight, the one thing I’d do differently on this project is worry less about potential concurrent requests. I designed the chatbot to be able to handle hundreds, if not thousands of simultaneous users, but in practice this is unlikely to happen. Even if a website is very popular, unless its central product or service isn’t a chatbot, most of the traffic won’t go be using it. I spent a lot of time creating, debugging and testing the system for the queue mode using Redis when in reality it hasn’t really made any difference (yet). If I had to start over, I would ship the chatbot earlier in beta, measure the traffic and daily messages and design (or not) the queuing system around this.
On the flip side, if EHL ever decide to promote the chatbot specifically, or if there was any other reason for its usage to spike unexpectedly, nobody will have to wait longer for their answer!