Mobile Key, Middleware and a Three-Year Lock-In
A 22-property resort group wants digital check-in and mobile key. Its PMS vendor offers a proprietary mobile-key module at $1.10 per occupied room-night; a middleware startup offers an open API layer that would let the group keep PMS, lock and app vendors independent, at a fixed $140k annual fee. The locks are BLE-capable but only through the lock vendor's own cloud. The brand already ships a guest app that cannot be modified. Roughly 30% of arrivals are international, many without data on arrival, and a meaningful share of guests are over 70. The group's current PMS contract auto-renews for three years unless notice is given 90 days out.
1. Recommend an integration architecture and defend it against the obvious objection that the startup adds a single point of failure.
Read the worked answer
Recommendation: middleware, with conditions. The decisive question is not build-versus-buy cost, it is where the guest journey lives. With the proprietary module, the PMS vendor owns the guest's check-in experience and every future change of lock vendor or guest app becomes a re-platforming project. With middleware, the group keeps the right to swap any component.
The 'single point of failure' objection is real but misdirected. The proprietary module is also a single point of failure - one vendor, one contract, no exit - it is simply a failure the group has already accepted. The correct test is whether the middleware degrades gracefully: mobile key must fall back to a printed key or front-desk card without a guest noticing, check-in must be able to complete at the desk, and the app must not block on the middleware. Specify that, then test it by killing the middleware in a pilot.
Conditions before signing: contractual API service levels with remedies; data ownership and full export on exit; escrow of the integration layer; a cap on per-transaction pricing as volume grows; and removal of the PMS auto-renewal so the middleware decision is not locked behind a three-year clock.
Judge both options against the same number - total cost at 22 properties and realistic occupancy - and note that $1.10 per room-night scales with success while $140k does not.
2. Design a pilot that would actually change your mind, and identify what would make you abandon the approach.
Read the worked answer
Pilot scope. One property, 8–10 weeks, deliberately chosen for a mixed arrival profile rather than the best-performing hotel. If it only works at a property with English-speaking repeat guests and good connectivity, it has told you nothing transferable.
Pre-register the measures, because after the pilot everyone will find a story that fits the outcome they wanted:
- Mobile check-in completion rate among eligible arrivals, and abandonment point.
- Key delivery success rate on first attempt, and time from arrival to room for mobile versus desk.
- Front-desk labour minutes per arrival - the benefit is usually staff time, not guest delight.
- Fallback frequency and what triggered it.
- Share of guests who cannot or will not use it, segmented by age and by whether they have data on arrival.
Accessibility and equity tests are pass/fail, not scores. If mobile key is the only fast path, guests without smartphones or data, or with accessibility needs, must not end up queuing behind a thinner front desk. Test the desk staffing model alongside the technology; the failure mode is that the benefit is taken as headcount reduction and the fallback collapses.
Abandon if: first-attempt key delivery falls below roughly 95%, fallback requires staff intervention more than a few times a day, or the pilot cannot demonstrate it works with the middleware deliberately taken offline. Also abandon if the lock vendor will not commit to an interface that survives their next hardware generation - that condition alone determines whether the middleware is worth its fee.