A guest app that failed because nobody asked housekeeping

The situation

Hospitality in the UAE competes on service at a level that makes small operational failures expensive. A guest paying resort rates who waits an hour for towels does not complain to the front desk; they mention it in a review that sits in front of the next several thousand prospective guests.

Guest apps are the standard response: let the guest request things directly, skip the phone call, track the request. The group had built one and launched it across all nine properties.

The problem

Adoption after four months was about four per cent of guests, and the group was preparing to write the investment off.

The app was not broken. It was well designed, it worked, and guests who used it had a reasonable experience the first time. Almost none of them used it twice.

The reason turned up within a day of arriving on site, and it was not visible from anywhere in the technology. A guest request submitted through the app arrived in a web dashboard on a desktop computer in the back office. Housekeeping staff do not work at a desktop computer. They work on floors, with a trolley.

So a supervisor had improvised. Requests were printed out, in batches, roughly every hour, and carried to the relevant floor. There was a laminated card at the housekeeping desk explaining the routine. Median response time to an in-app request was about seventy-four minutes, against ten minutes for the telephone, and guests had drawn the obvious conclusion.

The group had specified, designed and tested the app entirely with guests. Nobody had asked the people who would have to answer it.

What we did

Our first recommendation was to stop the planned feature work, which had been scoped as a response to low adoption, and to fix fulfilment instead. Adding features to a product that loses to a telephone makes a better product that still loses to a telephone.

We spent two weeks shadowing housekeeping, maintenance and food service across three properties. Not interviews; shadowing, on shift, including a night shift. That produced the constraint list that should have existed at the start: staff are mobile, frequently have one hand occupied, work in noisy environments, and change shift mid-request.

We rebuilt the staff side as a mobile application with the queue on the device, one-tap acknowledgement so a guest sees that a request has been picked up, and explicit handover at shift change so a request cannot be orphaned. Routing by floor and role replaced the single shared dashboard.

The guest app changed very little. It gained an acknowledgement state, because the largest single driver of a second phone call was a guest not knowing whether anyone had seen the request.

The outcome

Adoption rose from about four per cent to sixty-one within a quarter of the rebuild.

Median response time to an in-app request fell from about seventy-four minutes to nineteen, which is what actually moved adoption. Guests did not need a better app; they needed the app to be faster than picking up the phone.

The group changed how it specifies internal products as a result. A feature that creates work for staff is now specified with those staff in the room, which sounds like an obvious principle and had cost eleven weeks and a written-off launch to arrive at.

The app was a doorbell wired to a room nobody sat in. Everything about the doorbell was fine.