The context
The current dashboard is organized across five pages, each addressing a different layer of the revenue management workflow. This is the story of how it got built, what the architecture looks like underneath it, and what it actually proves about where AI belongs in a hotel's operating stack.
Studio Oriente operates an internal lab — SO Labs — that builds practical, AI-powered tools for the hospitality sector. This BI platform was the first major SO Labs build: a working demo designed to show hotel executives what's possible before they commit to enterprise tooling. The brief was simple: build something real, build it fast, and make it show the full arc of what a revenue manager actually needs.
The problem with hotel analytics
as it actually exists
Most hotels either have too little analytical infrastructure — a PMS with basic reports, an Excel file maintained by the revenue manager, and a lot of gut instinct — or too much, in the form of expensive enterprise BI platforms that require dedicated analysts to operate and never quite connect to how the hotel's commercial team actually thinks.
The gap between "I need to know where we're behind on pace" and "I need to run a report" is where revenue decisions get made badly. The question isn't whether hotels have data. They do. The question is whether they can get to it in the time it takes to make a pricing decision.
"The question isn't whether hotels have data. The question is whether they can get to it in the time it takes to make a pricing decision."
This platform is the answer to that gap. Five pages, a live Claude briefing, a Vanna-powered natural language query interface, and a cost structure that makes it accessible to any independent hotel or small group.
What the stack actually
looks like
The technical architecture is deliberately lean. MySQL handles the data layer — a single database with 29,151 reservation rows, structured around the hotel's real segmentation: Deluxe, Golden, Golden Superior, Suite, Emerald, Dunas, Silver room types, with market and tour operator data attached to each booking.
Retool sits on top as the UI layer — handling the component logic, filter state, and API calls. The Claude integration uses a two-query pattern: a JavaScript query builds the prompt from current filter state and data, then triggers a REST call to the Anthropic API. Components read the response from the REST query's .data object.
Vanna is embedded as an iframe — a pragmatic decision. Integrating Vanna natively into Retool's component model turned out to be more brittle than it was worth. The iframe gives Vanna its own context, lets it do what it does well, and surfaces the result inside the dashboard without pretending the integration is tighter than it is.
Five pages that cover
the full workflow
Together, the five pages cover the full arc of how a revenue manager actually thinks: where are we now, why are we there, where are we going, what do I need to export, and what else do I want to know that nobody thought to put on a dashboard.
What Claude actually
adds to this system
It's worth being precise about what Claude does in this stack — because it's specific, and getting the specificity wrong would misrepresent what the tool actually is.
On the KPI page: Claude generates an executive briefing that updates with every filter change. The prompt includes the current data state — which segment filter is active, what the comparison period is, whether it's looking at arrivals or bookings — and Claude produces structured analysis: headline metric, interpretation, business implication, recommended action. It doesn't just summarize the numbers. It reads them.
On the AI SQL Agent page: Vanna handles the hard part — translating a plain English question into syntactically correct SQL against a real hotel database. Out of the box, Vanna returns the generated SQL, a raw data table, and a basic Plotly chart. The narrative layer — the summary, the key insights, the interpretation of what the numbers mean — that's Claude. When you ask "What was Q1 2026 revenue by market compared to last year?" and get back a structured breakdown with growth rates and a line flagging that Europe is the only market in decline, Vanna found the data and Claude read it.
"Vanna found the data. Claude read it. The two together produce something neither delivers alone."
This is an important architectural point. The AI is not making pricing decisions. It's not running the hotel. It's doing what AI is actually good at in this context: pattern recognition at the data layer, structured communication at the insight layer, and natural language access at the query layer. The revenue manager still makes the call. The system just removes the time cost of getting to the information.
What this proves —
and what it doesn't
It's not comprehensive. It doesn't push prices or place restrictions into a CRS' inventory. A production revenue management system has depth that this demo doesn't attempt.
But for a few weeks of work and €40 a month, it covers the shape of the problem with some precision. It proves that a small group or independent hotel can have live BI, AI-generated analysis, and natural language querying — without a €50,000 enterprise contract or a data engineering team.
That's the actual claim. Not that this replaces IDeaS or Duetto. That it brings the analytical surface area that used to require enterprise tooling into reach for the kinds of properties that are currently making decisions from a weekly Excel file.
"For €40 a month, it covers the shape of the problem with some precision."
If you're a hotel group that wants to see what this looks like pointed at your actual data — or an agency that wants to understand how to offer it to clients — that's exactly what Studio Oriente builds. Get in touch.