The People Tech Problem Nobody in Hospitality Wants to Talk About

Walk into almost any hospitality business and ask a simple question: how many separate systems does a new starter have to be set up on before they can do their job? Then ask how many of those systems they will ever log into willingly.

The honest answers tend to be uncomfortable. Eight, ten, twelve systems. And of those, maybe two that anyone touches without being chased.

We have spent a decade telling ourselves that hospitality has a technology problem. It does not, really. The booking systems work. The POS works. The rota tools work. What we actually have is a people technology problem, and it is a different beast entirely. It is the gap between the tools we have bought and the people we expected to use them, and almost nobody wants to look at it directly because the answer implicates a lot of decisions made in a lot of head offices.

The stack was built for the wrong person

Here is the root of it. Most of the people technology in hospitality was designed, bought, and configured by people who sit at a desk, have a company email address, and log into a laptop every morning. It was then handed to people who do none of those things.

Your floor team does not start the day at a desk. A large share of them have never been issued a work email. They are moving between sites, picking up shifts, coming back after six months away, working their first ever job, or working their fifth job this year. The systems they are expected to use, the learning platform, the comms app, the onboarding flow, the engagement survey, the rota, the payslip portal, were never really built with that person in mind. They were built for HQ and then pointed at the floor and we acted surprised when adoption was poor.

This produces three failures that look like separate problems but are actually the same problem wearing different clothes.

Failure one: too many disconnected tools. Every function bought its own best of breed solution. L&D bought a learning platform. Internal comms bought an app. HR bought an onboarding tool and a survey tool. Ops bought scheduling. None of them talk to each other, none of them share a login, and the frontline worker is left holding a fistful of usernames they will never remember for products they were never trained on.

Failure two: the frontline is locked out. No email often means no clean way to provision access, so people either never get set up or get set up weeks late by a manager doing it manually, badly, at 11pm. The tools exist. The person simply cannot get into them. We bought the software and then built a moat around it by accident.

Failure three: tech built for the office, used by nobody on the floor. When a tool finally is accessible, it still feels like office software. It assumes a desk, a quiet moment, a keyboard, a tolerance for friction that a section waiter mid service does not have. So it gets ignored, and then the platform's own analytics get used to argue that frontline teams "don't engage with technology," which is one of the great self fulfilling prophecies of our industry.

These are not three problems. They are one problem: people technology in hospitality was built for the wrong person, and the symptoms just show up in three different places.

What the fix actually looks like

If the problem is that the stack was built for HQ, the fix is not another point solution. We do not need a thirteenth tool. We need the existing stack to behave as though the person on the floor matters, and that splits into two distinct jobs.

The first job is getting people in. The second is giving them something worth logging into once they are.

Getting people in

This is the unglamorous one, and it is the one almost everyone underinvests in. It does not matter how good your learning content or your comms or your recognition programme is if a meaningful chunk of your workforce cannot reliably get through the front door in the first place.

This is the layer that Connect by Cocentric is built to solve, and it is worth understanding as a category rather than a product. Think of it as the digital front door: an identity and access layer that sits in front of everything else. The premise is that a frontline worker, even one without a company email address, gets a single login that takes them into every system they need, and that the provisioning of that access is automated rather than done by hand by an exhausted manager.

The Wahaca deployment is the proof point worth citing here, because the number is genuinely unusual: a 91% frontline activation rate, achieved in three months. Anyone who has run a frontline rollout knows what activation rates normally look like, and it is not that. The interesting thing is not the figure on its own, it is what it implies. When you remove the access barrier rather than nagging people to climb over it, the engagement problem we have spent years blaming on frontline workers largely stops being a problem. It was never that they would not. It was that they could not, and we kept building tools that assumed otherwise.

Giving them something worth logging into

Solving access is necessary but not sufficient. Once someone is in, the thing they land in has to be coherent, in their language, and built for the way they actually work, otherwise you have just made it easier to reach software nobody wants.

This is the job a branded employee app like Monotree is doing: collapsing the scattered functions into one place that belongs to the operator's brand rather than feeling like a vendor's product. Learning, internal comms, onboarding, surveys, a social layer so teams across sites actually feel like one company, and AI generated quizzes so training is something other than a video nobody finishes. The point is not the feature list. The point is that it is one destination instead of eight, and it is designed to feel like somewhere a hospitality worker would actually go, not somewhere they are sent.

It is telling which operators are leaning into this. Ennismore, Pizza Pilgrims, Madklubben: these are not businesses with a reputation for tolerating clunky internal tooling, and they are not deploying this kind of platform because it is fashionable. They are doing it because the alternative, the disconnected pile of logins, has a measurable cost in turnover, in slow onboarding, in training that does not land, and in a frontline that quietly concluded years ago that none of this was built for them.

The uncomfortable conclusion

The reason nobody in hospitality wants to talk about this honestly is that it is not a vendor's fault and it is not the frontline's fault. It is an accumulation of locally sensible decisions, each function buying the best tool for its own narrow job, that added up to a people technology estate that works beautifully for everyone except the people it was supposedly for.

Fixing it does not start with a procurement exercise. It starts with admitting who the stack was actually built for, and then doing the genuinely harder work of rebuilding it around the person on the floor: first by getting them through the door without friction, then by giving them one place worth walking into. Treat those as two halves of the same job, because they are. Solve one without the other and you have either a beautiful app nobody can reach or a wide open door into a mess.

The technology to do both already exists. The harder question, and the one worth sitting with, is whether we are willing to admit the problem was never the technology in the first place. It was who we were building it for.