On-Property Service Intelligence · Documentation
Business Problem & Solution
The problem On-Property Service Intelligence solves in the hospitality ecosystem and how this downscaled demo proves it.
← On-Property Service IntelligenceThe problem — service signals scatter, and the floor pays for it
On any property, requests for service arrive through every door at once: a guest taps "make up room" on the in-room panel, a minibar sensor reports an over-temperature reading, the guest app asks for two extra pillows, a staff member calls in a flickering corridor light. Each channel speaks its own dialect, none of them carries a priority, and the person on the floor has to read, classify, judge urgency, and route — repeatedly, under load. The slow, lossy step is human triage, and that is exactly where a guest's small ask quietly ages into a complaint.
App 07 sits at that choke point. It is the perception-and-triage front door for on-property service: it reads the raw signal, classifies what kind of work it is and how urgent, holds anything it is not confident about for a human, and — on an operator's confirm — dispatches it as a structured request that app 14 turns into an assigned, SLA-tracked work order. The operator stays in the loop on the decision that matters; the rote reading and routing is done for them.
What this demo proves — and what it simplifies
It proves the coupling is real, not narrated: a request confirmed here emits `service.requested` on the shared event bus, and app 14 creates and auto-assigns a work order from it — live, even when 14's tab is not open. One signal becomes one tracked unit of work across two apps, with no app holding a private copy of the truth.
It simplifies the model call. The `perceive` stage is a SIMULATED metered stage: it returns a canned-but-plausible classification and a stable pseudo-confidence derived from the signal text (so reruns match), and it writes a real cost-ledger row with a mode flag. There is no live model in the dev demo (OSS-only, no API key). The classification rules, the confirm gate, the dispatch, and the live floor board are all real; only the perception call itself is stood in for.
Reality contract
Synthetic data only — three invented properties (Aurelia Bayfront · Cedar & Sky Resort · The Marigold Court), their zones and rooms, and ~14 inbound signals across in-room, sensor, staff and guest-app channels. No real guests, brands, or PII. Confidence scores, costs and priorities shown anywhere are representative and labelled. The cost meter, mode toggle and per-stage trace live only in the dark "Behind the scenes" inspector — never on the operator surface.