Studio case
Lighthouse, in the room where they price.
Revenue Guru is a revenue management team pricing independent hotels every day. They read Lighthouse rate data in one window and the hotel in another. We connected the Lighthouse API into Ovimore, so the market now sits beside the numbers they price on, and their own Claude reads the rates in the same conversation.
The result: the same market data at half their Lighthouse subscription, and pricing strategies they tune in a conversation.
What Lighthouse is.
A rate shopper. It collects what competitors charge, how guests review them, and where a hotel ranks, through Booking.com, Expedia and Tripadvisor.
No revenue manager reads it on its own. A competitor's rate only means something next to today's occupancy, the current price, how much is already on the books, what last year did, and the targets the hotel has to hit. Lighthouse holds the first part of that picture. The hotel holds the rest.
The problem was the switching.
Rates in one tool, the hotel in another. Every strategy meant moving between them.
Setting a price is trial and error against the rest of the picture. Try a rate, check what it does to revenue, check whether the targets still land, try again. Each check lived on a different screen: the market in Lighthouse, the books in the PMS, the comp set in a spreadsheet.
Multiply that by every hotel in the portfolio, every week. The thinking was good. The route to it was not.
What we built.
The Lighthouse API, connected into Ovimore. The market data lands where the hotel data already lives.
Inside Ovimore it surfaces as three screens: Rates for competitor prices per stay date, Ranking for where each hotel stands on the three channels, and Strategy for how the comp set prices against itself.
On top of that sits the Ovimore MCP layer. It lets Revenue Guru's own Claude read the Lighthouse rate data next to the revenue data, in the same conversation.
Pricing became a conversation.
The whole revenue team works in Ovimore. Their strategies and targets live in a second brain their Claude already knows.
Revenue Guru's revenue team already ran on Ovimore as its BI tooling, so the Lighthouse data arrived in a place everyone works. And their Claude already held their pricing strategies and the targets each hotel has to hit.
Tuning a strategy used to be a series of trial prices across screens. Now it is a question. Claude reads the market and the books through the Ovimore MCP, and answers against their own strategy.
What they built on top of it.
The part of this story that is not ours, and the part that proves the rest.
With the data open, Revenue Guru's own team automated the message flow to their clients: the note that explains why a pricing strategy was chosen now writes itself from the same data the strategy came from.
Revenue Guru built that automation themselves; our work ends at the data source it runs on. What it changed for them: clients hear the reasoning behind their strategy, and the team explains it the same way.
That is what shipping a data source should look like. We opened it, and the people who use it carried it somewhere we had not planned.
The result.
The API costs less than the seats.
Reading Lighthouse through the API instead of through the regular licence cut Revenue Guru's Lighthouse subscription cost by 50%. The same market data, in a better place, for half the price of that one subscription.