A WhatsApp concierge for hotels that never makes things up.

At a glance

Product	Concierge by Coderlytics — a WhatsApp guest-messaging platform for hotels (conciergeq.com)
Who it is for	Independent hotels and hotel groups in Europe: front desk, managers, group administrators
Engagement	In-house product, taken from architecture plan to a production-grade platform by Coderlytics
Timeline	About five weeks, from the first architecture document (9 August 2026) to MCP servers and a built-in staff assistant (September 2026)
Stack	.NET 10 and C#, Vue 3 and TypeScript, Astro, Azure SQL, Azure Service Bus, SignalR, Twilio WhatsApp
Hosting	Microsoft Azure, West Europe — infrastructure as code in Bicep, deployed by CI/CD

---

The problem

Every hotel front desk answers the same dozen questions all day. What is the WiFi password? When is breakfast? Is there parking? Can I check out late? Each answer takes a minute, and each minute is taken away from the guest standing at the desk.

Guests already have the answer channel they want in their pocket. They do not want to download a hotel app for a two-night stay, and most never will. They do use WhatsApp — in their own language.

Hotels that tried to fill that gap ran into three walls:

• Chatbots that make things up. A general-purpose AI bot can invent a checkout time, a spa price or a cancellation policy. For a hotel, a confident wrong answer is worse than no answer.
• Integration projects. Many guest-messaging tools start with a property-management-system integration. That turns a simple need into a months-long IT project before a single guest is helped.
• Data protection. Guest phone numbers and conversations are personal data. A hotel group needs clear consent, data separation between properties, and a real answer when a guest asks to be forgotten.

The brief we set ourselves was direct: let a guest scan a QR code and get a correct answer from the hotel on WhatsApp — with a person always one message away — and make onboarding a hotel a matter of configuration, not a project.

What Concierge does

For guests: scan, ask, get an answer

The guest never leaves WhatsApp. The concierge answers from the hotel's own content and hands over to a person when asked.

1. Scan. A QR code in the lobby, on the website or in the booking e-mail opens WhatsApp with a message already addressed to that hotel. At check-in, reception can print a stay QR tied to the guest's room and dates, so staff know exactly who is writing from room 204.
2. Ask, in their own language. Concierge detects the language of each message — English, Romanian, German, French or Spanish — and replies in that language when the hotel has written the answer, falling back to the hotel's default language otherwise.
3. Get the hotel's answer. Answers come only from content the hotel wrote: WiFi, breakfast, parking, spa, checkout, local tips. If nothing matches, the guest is offered the topics the hotel does cover, instead of a guess.
4. Reach a person. Asking for "staff", or for anything the FAQ cannot handle, escalates the conversation. The front desk replies from the dashboard and the guest receives it in the same WhatsApp thread.

Consent is recorded per guest, service and marketing consent are kept separate, and a STOP message is always honoured.

For hotel staff: one live dashboard

The live inbox. Escalated conversations stand out, guest phone numbers are masked, and staff reply in place.

The staff dashboard is where a hotel runs its guest communication:

• Inbox and escalations — every conversation, live, with delivery status coming back from WhatsApp. Staff step in with text or images; nobody needs to refresh a page.
• FAQ content — the knowledge the concierge answers from, edited by the hotel itself. Every topic can be written in five languages, grouped into collections, kept as a draft or set live, previewed as the guest would see it, and imported or exported in Excel.
• Check-in — issue, extend and check out stay QR codes, with automatic expiry for hotels that want it.
• Broadcasts — service notices and marketing campaigns sent through WhatsApp templates approved by Meta, with audiences that respect consent, quiet hours and scheduling, and delivery tracked per recipient.
• Analytics — the guest queue, traffic, human take-overs, and the most useful tile of all: missing answers, the questions guests asked that the FAQ could not answer yet. It tells a hotel exactly what to write next.
• Reports — seven report types (properties, check-ins, broadcasts, conversations, escalations, staff, FAQ) with saved filters, charts, Excel, PDF and CSV export, and scheduled delivery by e-mail.

The FAQ editor. The hotel owns every answer, in every language, and sees what the guest will receive before it goes live.

For hotel groups and the operator

A hotel group gets a My group workspace: its properties, which people hold a seat in which hotel, which AI assistants are allowed to connect, and guests' data requests across the estate — with group-level reports on top.

The Concierge operator has a clients console to onboard groups and properties, manage billing profiles and grant modules. For support, an operator can work as a property — a time-limited, fully audited, read-only session, so helping a customer never means borrowing their password.

Check-in: a stay QR ties the WhatsApp conversation to a room and a date window.

Why it is built this way

Five principles were written down before the first line of code, and every later decision was checked against them.

1. Correct before clever. Guest answers come from a deterministic rules engine that matches the question against the hotel's own FAQ. It cannot invent a price or a policy, it costs nothing per message, and hotels get value on day one. A grounded AI answer mode is designed to plug in later behind the same interface, per hotel — without changing the guest channel, the dashboard or the data.

2. Multi-tenant from day one. Every hotel is an isolated tenant from the very first commit. Onboarding hotel number two — or number two hundred — is configuration: create the property, connect a WhatsApp number, load the FAQ.

3. Channel-agnostic core. WhatsApp is the first channel, not the architecture. Messages travel inside the platform in a channel-neutral envelope, so new channels or a different messaging provider can be adopted without touching the core logic.

4. A person is always available. The concierge handles the repeatable questions; complaints, exceptions and judgement calls always reach a human.

5. Everything is auditable. Every guest message, automated reply, staff action and administrative change is recorded. That is what compliance requires, and it is also what makes the FAQ better every week.

How it works

The platform at a glance: five backend hosts, two web front-ends, and managed Azure services underneath. Select the diagram to open it full size.

Follow one message through the system:

1. The guest writes. WhatsApp delivers the message to Twilio, which calls the Concierge Gateway.
2. The Gateway checks and hands off. It verifies Twilio's signature, works out which hotel (and, for a stay QR, which room) the guest is talking to, and puts the message on an Azure Service Bus queue. It acknowledges WhatsApp immediately and never waits for processing — a burst of guests arriving at once simply queues up.
3. The Orchestrator answers. It takes the message from the queue, ignores it if the same message was already processed, finds or creates the guest and conversation, detects the language, and asks the responder for an answer from the hotel's live FAQ. It stores the inbound message, the reply and any escalation, then sends the reply back through Twilio.
4. Staff see it live. The Orchestrator publishes domain events. The Dashboard API receives them and pushes them over SignalR to the right hotel's dashboard — only that hotel's staff are ever notified.
5. Staff reply. A reply written in the dashboard is dispatched by a background service over WhatsApp, and the delivery receipt flows back into the conversation.

A message that repeatedly fails is moved to a dead-letter queue for inspection instead of being retried forever. Everything runs on Azure in West Europe: five App Service hosts, two Static Web Apps for the dashboard and the marketing site, Azure SQL, Service Bus, Blob Storage, Key Vault, e-mail through Azure Communication Services, and Application Insights for telemetry.

The codebase follows a strict layered architecture — domain, application, rules engine, infrastructure and five host projects — with dependencies pointing inwards only. Every external dependency sits behind an interface selected by configuration, which is why the complete platform, all six local processes, runs on a laptop with no cloud keys at all.

Engineering challenges we solved

Tenant isolation enforced twice

In a multi-tenant product, the most expensive bug is one hotel seeing another hotel's guests. Concierge does not rely on every query remembering a WHERE HotelId = … clause.

Every database command declares its scope — a hotel, a hotel group, or a named, justified cross-tenant operation such as sign-in or a group roll-up report. The connection publishes that scope to the database session, and Azure SQL row-level security filters and blocks rows outside it. If a query is ever written wrongly, the database refuses to return the other tenant's data. Dedicated automated tests prove the isolation between hotels and between groups.

Reliable messaging at the edge

WhatsApp webhooks can arrive twice, and a slow response invites retries. The Gateway only validates, resolves and enqueues; the Orchestrator de-duplicates on the provider's message id before doing anything. The result: no double answers, no lost messages, and a front door that stays fast however busy the hotel gets.

One use case, many front doors

The same action — reply to a guest, publish an FAQ topic, issue a stay QR — can come from the dashboard, from an AI assistant, or from the built-in staff assistant. Each of those is a thin adapter over the same application service, so authorization, validation and the audit trail are implemented exactly once. Adding a new front door does not create a new place for a security bug to hide.

Contract-first APIs

The dashboard and the website never hand-write API types. The backend's OpenAPI documents are committed to the repository, the TypeScript clients are generated from them, and the build fails if the running API and the committed contract drift apart. A backend change that would silently break the front-end cannot be merged.

Privacy by design

Phone numbers are masked throughout the dashboard, and message text and tool arguments are never sent to telemetry. Consent events are stored as a legal record. When a guest asks to be forgotten, the request gets a due date, the property can place a documented hold for a legal or billing need, and once it is due an anonymiser tombstones the guest's data and removes message content — while keeping the consent history the law requires.

A live dashboard without leaking sessions

Browsers cannot send authorization headers when opening a WebSocket, and putting a session token in a URL means it ends up in logs. Concierge issues a short-lived, single-purpose hub ticket that can only open the live connection — the real session token never appears in a URL.

Fast analytics

The first version of the analytics page made sixteen sequential database round-trips on every load. After profiling, it was rewritten to a single round-trip, backed by indexes chosen from measured query plans rather than guesswork.

Reports: seven report types, saved filters, and exports to Excel, PDF and CSV — generated in the background when they are large.

Opening the platform to AI assistants — safely

The newest layer of Concierge, currently being rolled out, lets people use the AI assistants they already work with — Claude, ChatGPT or Copilot — through the Model Context Protocol (MCP).

• A business MCP server gives staff an assistant that can work the inbox, handle escalations, manage stays and FAQ content, and run reports. A guest MCP server lets a guest's own assistant find a property, read its FAQ, message the hotel and manage their consent.
• Tools are filtered per person. An assistant sees only the tools the signed-in person's role allows — a front-desk seat sees far fewer than a group administrator.
• Every write needs a human. When an assistant wants to change something, the platform creates a pending action bound to that person, that client, that tool and those exact arguments. It expires after five minutes and can be used once. The summary the person approves is written by the server, not by the AI model.
• Guest text is treated as data, never as instructions, which closes the most common prompt-injection route: a guest message saying "ignore your rules and…".
• Standards-based sign-in. Assistants connect through OAuth 2.1 authorization servers built into the platform, with PKCE, audience-bound tokens signed by keys that never leave Azure Key Vault, rotating refresh tokens, and revocation from the user's profile. A hotel group decides which assistants may connect at all; the list is empty by default.
• Support sessions are read-only by construction. When an operator works as a property, only tools explicitly marked read-only can run — and the build fails if any tool is missing that marking.

Each of these controls is mapped in a written threat model to the test that proves it.

How Coderlytics delivered it

Concierge was built the way we build for clients: incrementally, against a plan, with evidence at every step.

Architecture and cost first. The first commits were not code. They were the technical architecture plan — goals, principles, components, data flows, phasing — and an Azure cost analysis, so every later choice had a budget and a reason.

Small, shippable phases. Each phase was written up as a plan with explicit acceptance gates before implementation, and closed only when those gates passed:

Milestone	What shipped
Week 1	Architecture plan and Azure cost model
Week 2	Working platform end to end: WhatsApp gateway, orchestrator, rules engine, staff dashboard
Week 3	Azure SQL with row-level security, Service Bus, health checks, CI/CD and a live staging environment; hotel profiles, multi-hotel staff, stay QR codes
Week 4	Multi-language FAQ with Excel import, exports, the 100% coverage gate in CI, broadcasts and WhatsApp templates, the marketing website
Week 5	Sellable modules, analytics performance work, platform and group reporting, OAuth 2.1 authorization servers, MCP servers, the guest data-deletion workflow, and the built-in staff assistant

Quality gates that cannot be skipped. Every push runs the full pipeline:

• compiler warnings are errors and code formatting is verified;
• 100% line coverage is enforced on the domain, application and rules-engine layers — the code that decides what guests are told and who may see what;
• the dashboard's stores, composables, router and API client have 100% coverage thresholds too;
• API contracts are checked for drift, and the marketing site runs Lighthouse CI;
• the Bicep infrastructure is compiled and linted.

Infrastructure as code, no stored secrets. All Azure resources are declared in Bicep. The release pipeline authenticates to Azure with federated identity instead of stored credentials, applies infrastructure only when it has changed, grants each host's managed identity the least database access it needs, runs database migrations, deploys, and smoke-tests every host's health endpoint. Production releases go to staging slots first and are swapped in.

Documentation as a deliverable. Architecture, configuration and deployment, local run guide, API endpoint reference, security threat model, and a plain-language guide for non-technical stakeholders — written alongside the code, not after it.

By the numbers

Automated backend test cases	963
Dashboard unit tests	368
Line coverage on the domain, application and rules-engine layers	100%, enforced in CI
Backend hosts / web front-ends	5 / 2
HTTP API endpoints across the gateway and dashboard API	~200
MCP tools for AI assistants	120
Versioned database migrations	45
Guest languages / website languages	5 / 4
Report types, each exportable to Excel, PDF and CSV	7
From architecture plan to platform	~5 weeks

What comes next

Concierge was designed so the next steps are additions, not rewrites:

• Grounded AI answers for hotels that opt in — natural conversation that answers only from the hotel's own FAQ, with per-hotel token budgets and the rules engine kept as the safe fallback.
• A website chat widget, reusing the same conversation core as WhatsApp.
• Connectors to hotel systems such as property-management and point-of-sale platforms, behind the same interfaces the platform already uses.

What this shows

Concierge is a product, but the method is the same one we bring to client platforms: decide the principles before the code, make isolation and security properties of the architecture rather than habits of the developers, automate the proof, and deliver in phases that each leave something working.

If you are planning a platform that has to be correct, secure and ready for many customers from its first release — or modernizing one that was not — talk to us.