Most hotel groups now get a version of the same pitch: an AI layer that sits on top of Oracle OPERA Cloud, pulls guest and reservation data, and automates some slice of operations. The pitch usually sounds similar across vendors. The underlying integrations do not. Before signing anything, a buyer needs a way to tell a genuinely connected, production-ready tool from a demo that happens to work with a sandbox account.
Start With How It Actually Connects
Oracle's Hospitality Integration Platform (OHIP) is the sanctioned path into OPERA Cloud. Vendors that are OHIP-certified have gone through Oracle's validation process for the specific APIs they use, whether that is reservations, profiles, housekeeping status, or folio data. This matters for two practical reasons: certified integrations are less likely to break on OPERA's update cycle, and certification usually means the vendor has committed to a support relationship with Oracle rather than a one-off workaround.
Ask directly which OHIP APIs the tool consumes and which it writes to. A tool that only reads reservation and profile data is a different animal from one that writes back housekeeping status or creates folio postings. Read-only integrations are lower risk and faster to approve internally. Write-back integrations unlock more automation but require more scrutiny on error handling, since a bad write into a live PMS record is harder to undo than a missed read.
Trace the Data Flow, Not Just the Feature List
Feature lists describe outcomes. They rarely describe the path data takes to get there, and that path is where most operational risk lives. For any AI-connected tool, ask the vendor to walk through a single scenario end to end:
- What triggers the data pull from OPERA (a webhook, a polling interval, a manual sync)?
- How fresh is the data when the AI layer acts on it, and what happens if OPERA is in scheduled maintenance?
- Where is guest data stored once it leaves the PMS, and for how long?
- What happens if the AI model produces an incorrect or low-confidence output, does a human see it before it reaches a guest or a PMS record?
A vendor that answers these questions with specifics, including sync intervals and fallback behavior, is describing a system they have actually run in production. Vague answers here are a signal worth taking seriously, regardless of how polished the interface is.
Evaluate for the Operational Reality of the Property, Not the Sales Demo
Demos are built on clean data. Real properties have duplicate guest profiles, rate codes that were set up eight years ago, and housekeeping boards updated inconsistently by shift. A useful evaluation puts the tool in front of that mess before contract signature, not after.
Three things worth checking specifically:
- Profile matching logic. If a guest has two profiles in OPERA because of a spelling variation, does the AI layer merge context correctly or treat them as strangers? This directly affects any tool claiming to surface "guest intelligence" to staff.
- Multi-property behavior. If the group runs OPERA Cloud across several properties, does the tool respect property-level permissions, or does it flatten everything into one dataset that a front desk agent at Property A should not be able to see?
- Failure visibility. When the integration drops, does staff get a clear signal, or does the tool silently fall back to stale data without saying so?
This is also where the difference between a connected tool and a genuinely useful one shows up. An AI layer that routes guest requests and automates service recovery, for example the approach Hermes takes when it sits on top of OPERA Cloud, is only as good as its ability to handle these messy edge cases without escalating everything to a human anyway. If a tool can't demonstrate that on the buyer's own data during a pilot, the production behavior will likely disappoint.
Questions to Put Directly to the Vendor
A short list, but each one should get a specific answer, not a marketing sentence:
- Is the OHIP certification current for the specific OPERA Cloud modules we use?
- What is the maximum data latency between an event in OPERA and the AI layer acting on it?
- What happens to guest data if we cancel the contract, and how quickly is it deleted?
- Can you show a case, even anonymized, where the integration failed and how it recovered?
- Does your pricing scale with room count, transaction volume, or both, and what triggers a tier change?
The gap between "connects to OPERA" and "runs reliably on OPERA" is almost always found in the answers to these five questions, not in the product demo.
Run a Bounded Pilot Before Committing
The most reliable evaluation method remains a short, scoped pilot on live but limited data, such as one property or one department for 30 to 45 days. Set two or three measurable outcomes in advance, for example response time to guest requests or reduction in manual data entry, and track them against a baseline from before the pilot. An illustrative property in this kind of pilot might see guest request routing time drop from a manual 12-15 minutes to under 3, but the number only means something if it was measured the same way before and after.
Buying AI software that touches a live PMS is not the same as buying a point-solution app. The integration layer, the data handling, and the failure behavior matter as much as the AI itself. A buyer who asks about OHIP certification, traces the actual data flow, and insists on a real pilot will end up with a much clearer picture than one who evaluates on feature lists and demo polish alone.