Why a new tool gets used or worked around

At seasonal properties, the right question about a new system isn't whether it works, but whether it will be used in the third week of July, when nobody has time to learn anything.

The context: a new team every year

The starting point isn't an opinion. The Italian tourism and hotel sector employs almost 245,000 seasonal workers, with more than 430,000 people employed at the summer peak (Federalberghi, research on seasonal work, May 2025).

On top of this comes a declared shortage: for 2026, an estimated 275,000 workers are missing in the services sector, of whom more than 200,000 in services and tourism, and according to Unioncamere's Excelsior information system the tourist season could be short of at least 500,000 workers; the difficulties concern kitchen and front of house, kitchen assistants and waiting staff, particularly in four-star properties and above (CentroPagina / Federalberghi, Money.it).

Nothing about any software can be deduced from these numbers. What can be deduced is a working condition: whoever opens a season does so, to a large extent, with people who weren't there the year before, and who will stay only a few months.

The real consequence: every tool is decided in five days

A team that changes every year means training isn't a one-off event: it is a recurring cost, and it has to be spent at a precise moment — the days before opening, while it is still calm, or never.

It also means a system has no time to be learnt slowly. At seasonal properties, adoption is decided in the first full services: if, in those days, the tool slows someone down, it gets worked around, and from then on it can't be won back in the same season. Not out of hostility: because on a Saturday in July nobody experiments.

Why tools get worked around

In the sector literature, the main obstacle is placed not in the technology but in change management: the category guide to hotel mobile ordering from Hotel Tech Report treats staff adoption and the operational challenges after launch as the critical issue, more than the choice of product.

In practice, working around a tool always takes the same three forms.

The double track. The staff use the tool when it's quiet and go back to paper slips when there's a queue. The result: the data is incomplete precisely in the hours that matter, and therefore unusable.

Handing it to a single person. One member of staff becomes “the one who knows how to use it”. It works until their day off.

Filling it in out of duty. The information is entered afterwards, at the end of the shift, to make the till balance. At that point the tool no longer serves the service: it serves the accounts.

The three conditions that make the difference

It takes a job away rather than adding one. An adopted tool is almost always one that replaces an existing gesture — the paper slip, repeating the order at the bar, looking for the guest. A tool that asks for an extra gesture is used only while someone is watching.

It works at the worst moment. Not on a Tuesday trial in May: on a packed Saturday, with a weak network and two people short. A system assessed only in good conditions is a system that hasn't been assessed.

Someone is there for the team when it opens. The difference between a configuration handed over and a system that actually goes into service is made by support for your team in the first services: not to teach, but to correct the things nobody had foreseen. It is the part that can't be done by sending an email.

What to ask a supplier, in practice

“Who supports us, and when?” A precise answer is a good sign. A vague answer is a cost that will land on your head of department.

“What do I take away from the people working, rather than add?”

“What happens if something stops working on a Saturday in August?”

These are three questions that aren't about features. They are about whether the tool will still be alive at the end of the season, which is the only thing that counts at a property that opens for four months.