Author
InnPractice
October 14, 2026
Hotels are not short of technology. Walk the floor at Hospitality Tech Expo and it is clear there is no shortage of systems promising efficiency, insight and profitability. Yet most owners and operators can point to at least one investment that never delivered what it promised, and at least one system the team quietly works around.
That was the question we put to our recent keynote panel at the Hospitality Tech Expo at London ExCeL: why do some technology investments transform a hotel, while others become expensive systems nobody uses?
Dean Crews, co-founder of InnPractice brought the owner-and-operator view, Michelle Daniel, COO of OSS-Systems, brought her experience of building systems to solve real challenges, Dan Barnes of Flourish Hospitality brought the people side and Michael Donald of Halo Business Consulting moderated.
Thirty minutes on a stage is nowhere near long enough to fully answer the question, and it was never meant to be. So here are some insights from three people who do this every day, and the areas they would want you to think about before committing to anything.
Start with the problem, not the product
The first mistake often happens long before anyone sees a demo. A hotel goes looking for a solution without being able to describe the problem, and without being clear about which kind of return it is buying.
Dean’s discipline is to hold two timeframes at once.
“I’d focus on immediate operational impact and then long-term strategic impact as two ways of looking at that initial tech implementation. If we’re buying a POS or PMS system, what’s the immediate, what’s the long term, what’s the benefit?” Dean Crews, InnPractice
Price may be an accepted pain point, but the shape of the quote is not. The market has split into out-of-the-box solutions and modular ones, and the modular ones are often where the direct comparison fallsapart. Dean described a quote that looked extremely competitive until you noticed it excluded payment, printers and screens, all of which are not really extras but the basics of a working till.
The other useful distinction is between technology that has to earn a return and technology a hotel accepts as necessary. A PMS falls into the second category, and so usually do HR and sign-in systems. Energy management in bedrooms is a harder sell: fifty thousand pounds of it may produce nothing tangible on a spreadsheet while making the guest experience considerably better, and protecting the rate you charge. That is the honest version of a business case. Some of it you can count, some of it protects something you would otherwise lose.
Walk the building before you choose the software
Michelle’s answer to “do we need a new system?” starts somewhere most procurement processes never go.
“I have to sit down and say, can I take a walk of your building. That’s the first thing I ever do.” Michelle Daniel, OSS-Systems
Part of what she is looking for is what is already there, because most hotels are carrying more than they realise. Different general managers and different operations people have each chosen something they knew or liked, and the result is a stack of legacy systems that nobody designed: one for maintenance, one for compliance, another for revenue, on and on, none of them talking to each other.
The rest is infrastructure, and this is where ambition meets the building. Cabling that was specified years ago, in-room hardware that cannot do what the brand standard now requires, and the constraint nobody puts in the business case: everything a team uses now runs on a phone, and in plenty of hotels there is simply no signal. It is unique to every property, which is why she will not recommend anything from a brochure. She is also blunt about why some of this technology gets bought in the first place, describing much of it as a knee-jerk reaction to a problem the hotel has not properly diagnosed.
Dan added the question that should sit alongside every purchase: if you are implementing a new technology, can you be confident it will still be relevant in five years? Otherwise you are gambling on replacing it. Michelle extended it to the commercial terms. Will it cost you to upgrade every year, or does the product move with you as it improves?
Resistance is information, not obstruction
When a system goes in and nobody uses it, an easy explanation is resistance to change. Dan’s point is that the resistance is telling you something about how the change was run. Everybody has a natural immunity to change, he argues, and a set of self-protective instincts that exist so they do not get hurt or scared.
He went back to the basics of change management: a compelling reason, a coalition of people who help drive it, and buy-in from the start rather than a decision that arrives fully formed. Then the sharper point, which is about identity rather than software. A chef who has used the same ordering system for fifteen years is not being awkward. A new one can feel like being told those fifteen years count for nothing.
Which is why training completion measures almost nothing. The question is not whether someone was trained. It is whether they have the confidence to use the thing on a busy service. Forget the humans at the centre of it, and resistance is what you get.
Every hotel technology rollout has someone in a position where they don’t quite understand the benefits and fear how it could affect them. They are not resisting the software.
“It’s not a fear of the technology itself. There’s that fear of looking stupid by not being able to use the system correctly.” Dan Barnes, Flourish Hospitality
Adoption belongs to the operator, not to IT
So where should accountability sit? Dean started with where it should not. Putting it with IT is the common mistake, because people expect the IT manager to chase everyone, and that is not what IT is for or interested in. Their job is to make the system work and perform. Adoption comes from hotel operations, through the management structure.
His example is the one every operator recognises. You can buy the ordering system, but if a chef carries on ringing his mate the butcher, you have not bought anything, and the chaos runs all the way through to accounts and payments.
He is equally clear about what actually gets a system adopted, and it is not the feature list. In this global industry, hotel teams don’t always have English as their first language, confidence levels in tech can be inconsistent, and if a system is challenging to use, they might simply ignore it. In that situation, you could be dead in the water before you start. Dan’s addition was about who uses what: supervisors and leaders need to know the system properly, while for the people cleaning rooms at pace it has to be close to effortless. Clean the room, tick to say it is done, move on.
Which brings you to the line that sums up the whole adoption question.
“The adoption of it is only successful by the people who are using it, not necessarily the
people who are making the decisions to buy it.” Dean Crews, InnPractice
Dean made one further point worth repeating: when a system is reported as broken, the honest answer is often a training gap rather than a fault. And the employee-facing systems that attract the most resistance at launch are frequently the ones people defend a year later. Time and attendance is the classic example. The reaction on day one is that Big Brother is watching. The reality a few months in is that nobody forgets to clock in, everybody gets paid accurately, and holiday balances are visible in real time.
A good partner does not support from a distance
If adoption belongs to the operator, the provider is not off the hook. Michelle's test is whether the people selling the system understand the job it has to survive.
“Tech people in general can be a bit distant, but everyone in my team is hospitality. They all worked in the hotel industry, so they understand the pain.” Michelle Daniel, OSS-Systems
In practice, that means being in the building after go-live rather than emailing from a distance. She described a London rollout where the hotel moved its PMS on the same day her team went in, which sent stress levels through the roof. One housekeeper told her she was frightened of making a mistake, and what she needed was not more training but reassurance that an error would not be held against her. Michelle’s team stayed on extra days and were there each morning while the lists were worked through. The housekeeper understood the new system inside twenty minutes and was flying by the second day.
And one boundary that gets crossed constantly. A technology partner can explain a system. It is not their job to tell a team that their working day, or their pay, is about to be calculated differently. Somebody from the hotel needs to have that conversation first.
Remove the friction, keep the hospitality
This was where the conversation got interesting, because nobody argued for a frictionless hotel. Dan put the clearest frame on the upside and on how it gets wasted. If technology hands a manager five hours back, the worst thing to do is fill those five hours with more tasks. They should go on guests, or on coaching and developing the team.
Dean has watched a business try to engineer friction out entirely and watched the guests object. He described how one business spent six years making the experience frictionless, and the feedback was that guests quite liked the friction. They liked talking to people. That was what they were buying. His description of an over-automated arrival is the best shorthand anyone offered all session.
“Hello Mr Crews, there’s your key, have you got the app, see you later. You’ve taken away the friction, but you’ve created tension.” Dean Crews, InnPractice
The problem is not the app. It is the assumption that everyone wants the same thing. Dan’s answer was to give people the choice: the frequent business traveller wants to get off a plane and into a room, while someone visiting a city for the first time or celebrating an occasion wants a conversation. The same hotel has to do both. And how you explain the system to your team decides which one you get. Tell people the purpose is less work, and less is exactly what they will do.
Dean’s warning is what happens when the saving is the only thing anyone measures. He described a golf club that replaced the starter’s hut with a QR code, so you can now arrive, play and leave without speaking to anyone. The payroll saving is real. So is the lost spend on a sleeve of balls and a drink afterwards, and the conversation that used to prompt both. He had a hospitality version too: a restaurant allergy process where the tableside ordering technology was impressive and the allergy conversation itself had been designed for compliance rather than for the guest trying to read a tiny screen.
Michael added the example of the famous brass key fobs at The Goring, and the handful of seconds it bought every time a guest collected it. How was your day? What are your plans this evening? A job that could look like an inefficiency, is in fact the relationship builder.
None of which is an argument against automation. Michelle described a hands-free pod hotel, where there is no reception desk at all: the room arrives in your wallet like a boarding pass, the gates let you in, and checking out triggers a housekeeping job automatically. It works, Dan argued, because the guest bought that concept from the very first click and their expectations are set accordingly. The trouble starts when the same thinking is retrofitted into an existing hotel. Michelle’s worry is what gets lost in between: teams who never learn the craft because the transactions have been automated away, and a technology stack that will never teach them. Culture is the hotel’s job.
On stage, Dean named the practical thing that stops good technology ever reaching a hotel: integration, particularly under a franchise agreement, where the brand dictates the providers. You can find a piece of technology that would make a real difference, and if it will not talk to the mandated PMS or meet the payment requirement, that is the end of it.
Know what good looks like, and when to expect it
Expectations are where investments quietly fail, and Michelle is specific about the timeline.
“It takes three months to embed before people are actually doing it properly. Between three and six months you start getting what I call measurable data.” Michelle Daniel, OSS-Systems
What that data looks like is operational rather than financial: cleaning times, the number of rooms each person turns around, maintenance jobs closing faster, planned maintenance happening instead of reactive call-outs, and front office able to check guests in for longer so nobody is left waiting. Her favourite example is what it does for supervisors, who used to spend their shift chasing checklists instead of doing the job they were there for, which is inspecting bedrooms.
The early warning signs show up in the same place. Usage drops off. New starters never got the training. The average cleaning time per room is not what it should be. By the time the tickets and the complaints arrive, you are already at risk of losing the customer.
Dan’s measures are human and observable. Is anyone still running the old spreadsheet in the background, or still phoning the person they always phoned? Has it become a daily habit, or is it still something people have to think about and would rather avoid? His three tests are whether confidence is improving, whether behaviour on the floor is changing, and what it is doing to the guest experience.
Dean’s warning is about the timeline from the other direction. Technology contracts are rarely short, so the idea that you will review it properly at six months and change your mind is optimistic. Switching a PMS six months in is not a procurement decision, it is an operational event, and the disruption has to be worth it. His practical answer is a quarterly review: three months of trading with the new system, what has actually changed, where are the holes. And he made the point that gets left out of the business case entirely. Some of the return never shows up as cash. Give your team an easier, better, simpler working life and you become a better place to work, which in this market is worth something.
Where to start
None of this is the full picture, and none of it is a running order. Every property is different, as Michelle pointed out more than once. The answers for a new build are not the answers for a listed building in London carrying twenty years of layered systems.
But if there is a thread running through all of it, it is that the best technology strategy is not a list of systems. It is an operating model where commercial priorities, the technology and the people reinforce one another.
Define the problem before you shop. Walk the building before you sign. Treat resistance as information rather than obstruction. Own the adoption instead of handing it to IT or the supplier. Give it long enough to embed, then measure the things that actually tell you something. And be careful which friction you remove, because some of it is what the guest is paying for.
Get those pulling in the same direction and the investment turns into performance. Leave one of them out and you have bought another system your team will work around.
Carry on the conversation
What made this panel work is the same thing that makes a technology decision work: the right mix of expertise around one hotel’s problem. An operator, a systems specialist and somebody who understands how teams actually adopt change, rather than one firm with one answer.
That is how InnPractice works day to day, with our partners alongside us depending on what a property needs.
These are starting points rather than conclusions, and every hotel we work with has a different version of them. If any of this sounds like a conversation you should be having about your own property, whether that is defining the problem before you invest, working out whether your current systems could do more than they are doing, or getting a stalled implementation moving again, get in touch. We are always happy to have the longer version of this conversation.
Contact us today to explore how we can build a successful partnership together.