Case study · 03
The AI understands the request. It doesn't get to decide.
Hotels lose goodwill in two places: calls nobody answers, and messaging handled by template bots that confidently say the wrong thing. Our concierge is built to be boring on purpose — grounded answers, a fixed menu of actions, and a human on the hook for everything else.
In build — no public instance. The running stack is an internal demo behind a firewall, so there is nothing here to link. Ask us for a walkthrough.
Phase 0 — built and verified · 2026 · Researched, designed and built in-house by NeuroX AI
42
Decisions on the record
Numbered ADRs, reversals kept with their reasons
5
Capabilities, fixed
F&B, cleaning, maintenance, transport, bill summary
3
Surfaces shipped
Guest web by QR, native staff app, admin console
2
SLA clocks per item
Response/attend and resolution, tracked separately
01 — The idea
The bet: determinism beats ambition here.
Every competitor in this category is chasing open-ended agentic behaviour, and in a hotel that is precisely the wrong ambition. A concierge that can say anything can promise a late checkout nobody approved, quote a price that does not exist, or invent a policy — and the hotel, not the vendor, absorbs it. The blast radius of a confident wrong answer is a real guest standing at a real front desk.
So the model's job is narrowed to the one thing it is genuinely reliable at: working out what a person means, in their own language. It answers strictly from the hotel's own FAQ and never invents; it fulfils a closed set of five structured requests through deterministic tools; and anything outside that set becomes a ticket routed to a human, with the guest kept informed while a person resolves it. Classification is not authority.
The consequence we care about most is that “the bot understood it” stops counting as an outcome. Every guest request becomes a typed, clocked, owned work item — and requests the system cannot classify still land in a real department under a fallback SLA rather than disappearing into a transcript nobody reads.
02 — What we shipped
Not a landing page. A whole product.
- 01
Grounded in the hotel's own FAQ
Answers come from the property's knowledge base or they do not come at all. There is no fallback to general knowledge and no improvising around a gap — an unanswerable question becomes a ticket instead of a plausible guess.
- 02
A closed five-capability menu
Food and beverage ordering, room cleaning, maintenance reporting, taxi and transport, and a bill summary. Five structured flows executed by deterministic tools — not five prompts hoping for the right tool call.
- 03
Straight to the owning department
Food goes to the kitchen, cleaning to housekeeping, a fault to maintenance — routed directly rather than queued at a front desk that then has to relay it. No middleman, and no delay added by the handoff.
- 04
Two clocks, not one
Response/attend and resolution are tracked as separate SLAs against service calendars, with a pre-breach alarm. A single resolution clock becomes unenforceable the moment an outside vendor is involved, and pausing it is a closed, audited list of reasons.
- 05
Assignment through the real roster
Zone, then published roster, then attendance, then rest, then role, then least-loaded — resolving to one accountable owner. Rostered-but-absent is the normal case in a hotel, so the model treats it as the default rather than an exception.
- 06
Escalation follows the power to act
It re-points to whoever can actually chase the vendor, and after hours collapses onto the duty rota. Escalating a vendor wait back to the engineer who already dispatched in eight minutes just teaches staff to stop acknowledging tickets.
- 07
Nothing falls through
A request the system cannot classify is filed as unclassified into a real department with a fallback SLA, then promoted by an admin. It is on somebody's clock from the first second, which is the opposite of how template bots fail.
- 08
QR in, no install
Guests scan a code and land in a mobile web app — no download, because install friction is where guest adoption dies. Onboarding runs QR to mobile and OTP to room claim to an approval gate, read-only until approved and revoked at checkout.
03 — Engineering
How it's built: research first, decisions written down.
Four parallel research tracks — competitive landscape, integration ecosystem, AI architecture, and trust/privacy/compliance — fed the product and engineering plan before any code was written. Every non-obvious claim in those documents carries an inline source, and every consequential choice is a numbered ADR.
42 ADRs, including the reversals
Guest data moved server-side, the surface mix changed, and PMS integration was cut from v1 — each recorded as a numbered decision with its reasoning rather than quietly rewritten. The reversals are the useful part of the record: they are what stops the same question being reopened every month.
No PMS integration in v1, on purpose
The India-first launch properties have no usable integration path, so rooms and occupancy are admin-managed and folio posting is replaced by an in-house stay tab. A PmsPort interface is defined with no adapter behind it, which keeps the eventual migration cheap without pretending the integration exists.
One script is the source of truth
The planning documents are authoritative for decisions; verify-all.sh is authoritative for what actually works. It replays every migration from an empty database on demand — added after a run failed in five unrelated-looking places because new migration files only ever reached the database through Docker's initdb hook.
Compliance shaped by the market, not the template
DPDP Act 2023 governs rather than GDPR, and the European working-time research is retained as justification for the roster model rather than loaded as a live ruleset. DPDP is not a weaker GDPR — its obligations differ in shape, and treating it as a subset would have been the easy mistake.
What it runs on
- FastAPI · Python · uvicorn
- PostgreSQL · 13 migrations
- Redis
- React Native + Expo (staff)
- React · Vite (guest · admin)
- Shared TypeScript contract
- Docker Compose · nginx
- WhatsApp/SMS status rail
- verify-all.sh in CI
Why this is on our site: it's the discipline, not the demo.
This is the project where you can see how we make decisions rather than just what we shipped: four research tracks before the first commit, 42 decisions written down with their reversals intact, and a hard line drawn around what the model is allowed to decide. Most client work arrives needing exactly that — someone to work out which parts of an AI feature must be deterministic before it goes anywhere near a paying customer.
Contact
Want one of these for your idea?
Tell us what you're trying to build in 2-3 sentences. We reply within one business day.
Or skip the form — book a Calendly slot directlyadmin@neuroxai.com · +91 70149 99768
Remote-first team across India · US · EU · HQ in Udaipur, India