Communicating is not enough: housekeeping, front desk and maintenance in the management system
The way this subject is usually framed is wrong from the opening premise. Software vendors tell it like this: the departments of a hotel do not communicate, communication has to happen in real time, therefore you need a module that makes it possible. It is a story built on a hotel that barely exists in Italy.
According to Federalberghi’s tenth report on the Italian hotel system, the country has 32,943 hotels, and average size has risen to 69.3 beds per property, against 37.6 in 1980. Translated: the typical Italian hotel has just over thirty rooms. It does not have three departments, it has three people. The head housekeeper is also a room attendant, the maintenance engineer is an outside plumber called when needed or the owner with a wrench, and the front desk is one person who at eleven in the morning is simultaneously handling check-outs, breakfast and the phone.
In a property like that real-time communication already exists. It happens on the stairs, on the internal phone, in a WhatsApp group that costs nothing and is faster than any software ever written. A vendor claiming to introduce a capability the staff do not possess is describing a problem the hotelier does not recognise, and that is exactly why those modules get bought and then never used.
The problem is a different one, and it is subtler.
A message is not a state
A message is read and then it disappears. A state persists, it has an owner, a timestamp and a history attached to the object it describes.
When the room attendant writes «204 is ready» in the group, that information lives in the head of whoever read it. If the front desk is on the phone at that moment, if the shift changes, if the message scrolls under twenty lines of something else, the information has technically been transmitted and is operationally lost. Three days later nobody can say what time 204 was ready. Nobody knows how many times that month 204 was flagged as late.
The difference between a chat and a management module is not speed: it is persistence. The module is not there to make people communicate who already communicate; it is there to turn a communication into shared, queryable data. That is an entirely different function, and it should be bought for that one, not for the first.
This distinction has three precise economic consequences, and they are worth taking one at a time.
The room that does not exist
The first cost is the most immediate and the least perceived: the hotel sells, or fails to sell, on the basis of a false state.
Room status is not a binary between dirty and clean. A correct cycle distinguishes at least the room to be made up, the room made up but not yet inspected, and the room inspected and sellable. Above all, it distinguishes two conditions that Italian practice constantly conflates: the room out of service — temporarily unsellable, but still part of inventory — and the room out of inventory, removed from the count because it is unavailable for an extended period. It sounds like a bureaucratic nicety. It is not: the first reduces the rooms sellable tonight, the second changes the denominator used to calculate occupancy and RevPAR. Treating them the same way produces KPIs that describe a different property from the real one. The labels vary from system to system, and arguing about them is a waste of time; the only question that matters is which of the two things the flag actually does to the denominator — and it is worth checking in your own system rather than assuming.
When status lives in a chat rather than in the management system, the errors are systematic and always in the same direction. The room ready at eleven is recorded at three, and in the meantime an early arrival has been turned away or left waiting in the lobby. The room with the broken air conditioning stays sellable because the report was only verbal, and it gets assigned. The room blocked «to be safe» by the front desk stays blocked for days because nobody remembers why.
Each of these errors propagates downstream. Anyone running automated pricing should bear in mind that the algorithm prices on the availability it is told about: if the genuinely sellable rooms are three and the system sees five, the price for the last night is calculated on a scarcity that does not exist, and the error is invisible because it leaves no trace. It is the clearest case of a general principle: automation does not create data quality, it amplifies it — for better and for worse.
The fault nobody closed
The second cost concerns maintenance, and it concerns recurrence more than repair.
Reporting a fault, in a small hotel, almost always works. The room attendant finds a slow drain, mentions it, somebody deals with it. What does not work is everything else: knowing whether the work was actually done, by whom, when, and above all how many times the same fault has come back in the same room.
A corrective ticket handled as data has a life cycle: opened, assigned, closed, with a photograph attached where relevant. If that cycle exists, at the end of the season the hotelier can read something they would otherwise never know: that seventy per cent of reports concentrate in twelve rooms, that the problem with that riser has returned five times, that the cheap repeated intervention has cost more than the replacement that kept being postponed. Without that cycle, every fault is the first fault, and the investment decision is taken from memory.
There is also a less visible consequence. With no record, an unclosed report becomes a risk the hotel does not know it is carrying: nobody can demonstrate that a reported problem was dealt with, and in a seasonal operation, where the person who reported it in July is gone by September, the information cannot be recovered at all.
What goes unmeasured
The third cost is the largest and almost always invisible, because it concerns a line the hotel pays every month without measuring it.
Housekeeping is, after the front desk, the main operating payroll line in a hotel. And yet the overwhelming majority of independent properties do not know their own cost per cleaned room, do not know how many minutes a departure takes on average against a stayover, do not know whether the productivity gap between two attendants is ten minutes or thirty, and have no idea what percentage of rooms fail inspection on the first pass.
These numbers are not obtained by running a survey: they are obtained as a by-product. If opening and closing each room leaves a timestamp, the average minutes by room type, the cost per occupied room and the re-clean rate emerge on their own, with nobody having to fill anything in. This is why the value of a housekeeping module is measurement more than coordination: it improves coordination a little, and it creates visibility out of nothing. And once those minutes exist, housekeeping payroll stops being an undifferentiated line in the P&L and becomes a line you can govern, comparable across months and across properties.
A necessary word about the numbers
A great many figures circulate on this subject and almost none of them is verifiable. Anyone looking for data will find widely quoted percentages — twenty-five per cent more productivity, thirty per cent faster room turnaround, twelve minutes saved per room — that all share the same characteristic: they come from a single vendor’s customers, with no stated sample, no control group, no published methodology. Others, such as the average cost of a communication error or the uplift in guest satisfaction associated with structured protocols, appear on content sites with no upstream reference of any kind and are then copied along a chain until they look established.
There are, at present, no independent benchmarks on the economic return of a PMS’s operational modules. That is why the analysis above and the analysis that follows reason from mechanisms — what concretely happens when a piece of information is not recorded — and not from percentages. Anyone being offered a quantified return should ask across how many properties it was measured, and against what baseline; the answer is usually instructive.
The real obstacle is the housekeeping team
It is worth clearing away a convenient explanation here. In the large majority of management systems in use in Italy the housekeeping module is already included in the subscription: the hotelier bought it without knowing and in many cases has never switched it on. Cost, therefore, is not the barrier. Blaming non-adoption on the price of the software means looking for an external cause for a problem that is internal to the organisation.
The real obstacle is training the housekeeping team, and the reason it is so hard to overcome is structural, not temperamental.
The starting point is an asymmetry almost nobody names: the person entering the data is not the person who benefits from it. The module gives visibility to management, confidence to the front desk, history to maintenance. Of the room attendant it asks two extra taps per room, and it gives her nothing back. In any organisation, an activity that costs effort at one level and produces value at another is abandoned the moment it stops being supervised. This is not resistance to change, it is arithmetic.
On top of that sits the calendar. In seasonal properties, housekeeping training happens in the two or three days before opening, when the building is a work site, half the supplies have not arrived and the owner is doing something else. The procedure is explained once, in a hurry, to people who at that moment have twenty more urgent things to learn. Twelve months later, at the next season, a good part of those people are gone and it starts again from scratch: turnover in the department is such that training is not an event but a recurring cost, and it belongs in the budget as one.
Then there is language, which Italian vendors rarely confront. In many properties a significant share of the housekeeping team does not speak Italian, or speaks it at an elementary level. An interface available only in Italian is not simply used less: it transfers onto the head housekeeper all the interpreting work the module was supposed to eliminate, and the head housekeeper becomes once again the bottleneck every piece of information has to pass through. A multilingual interface, or one built around icons rather than text, is not a cosmetic detail: it is the difference between a tool usable by the people who have to use it and a tool usable only by management.
That leaves the physical conditions, which sound trivial until you try. The tool is used in a corridor, with wet hands or gloves on, with the phone in a uniform that often has no pockets, in stairwells and basements where coverage on the guest floors is almost always worse than the owner believes. If changing a status takes three steps and a keyboard, or if the app freezes in the lift without saving, the operation will be put off to the end of the shift and real time is lost all over again. It is also worth asking which device you are asking people to work on: if it is the attendant’s personal phone, on her own data plan, you are asking a favour — and you will get it with the reliability of a favour.
Finally, there is a threshold beyond which the system collapses within days, and it should be understood before starting. If room status is not reliable nearly all of the time, the front desk goes back to phoning. And the moment the front desk phones to check, the module has lost its only function: the data stops being the source of truth and becomes a duplicate to be verified. Partial adoption does not deliver half the benefit, it delivers none of it — plus the irritation of one more thing to do. This is why these projects should start on a narrow perimeter — one floor, one team, one status — and widen when the proportion of timely updates is close to total, not when management has grown tired of insisting.
Technical obstacles, by comparison, matter less than the telling suggests, and they mostly concern those who decide to sit a specialised third-party application alongside the management system. In that case two questions remain decisive. The first is whether writing is bidirectional and immediate: many applications read room status from the management system but write it back late, or not at all, and the result is two systems saying different things about the same room — a situation worse than the starting point, with an extra subscription attached. The second concerns the cost of the connection: international analyses put the interfaces of previous-generation systems in the order of a few thousand euros each, plus a connectivity fee, and while commercial practice in the Italian market is uneven, the logic is the same, because the interface is treated as a revenue stream rather than as a basic function. A vendor that exposes documented APIs is structurally cheaper to integrate with than one with a proprietary, unpublished interface: that is a question to ask before signing.
Conclusions
The value of a management system’s operational modules does not lie in making people communicate who already communicate. It lies in turning a conversation into a shared state: information attached to the room rather than to the memory of whoever was on shift, with a timestamp and an author, and therefore consultable, aggregable and measurable.
Everything else follows from there. Reliable room status is what makes any downstream automation sensible, starting with price: a system deciding on false data decides badly and does not announce it. A ticket with a life cycle is what turns maintenance from a recurring expense into a historical record on which to base a replacement decision. And the timestamps the module collects without asking anyone for them are the only realistic way, for an independent property, to know what cleaning a room actually costs.
For anyone about to start, though, the right question is not about the software. The module is, in all probability, already included in the subscription the hotel is paying. The question is how much training time you are willing to put into the housekeeping team at the start of every season, in which language, and who has the authority to insist that the procedure is followed even in the busiest week of August. It is an organisational question dressed as a technological one, and it has to be addressed as such: if the answer is that training will happen the day before opening along with everything else, the module will stay switched off exactly as it has been until now.
Frequently asked questions
Does a thirty-room hotel really need a housekeeping module? Not to coordinate staff, who at that size already coordinate themselves. It needs one to have reliable room status in the management system, and to generate the productivity and cost data nobody would otherwise collect. If the benefit the vendor leads with is the first one, the investment will disappoint.
What is the difference between an out-of-service room and an out-of-inventory room? An out-of-service room is temporarily unsellable but remains part of inventory and therefore of the occupancy calculation. An out-of-inventory room is excluded from the count of available rooms, which changes the denominator of the performance indicators. Conflating the two produces occupancy and RevPAR figures that are not comparable over time.
Why is a WhatsApp group not enough? Because it transmits information without preserving it in a usable form. A message is not tied to the room, has no progress state, cannot be queried weeks later and produces no aggregable data. It works as a reporting channel and fails as an operational record.
How much does wrong room status cost in revenue? There are no reliable independent estimates. The mechanisms, however, are identifiable: early arrivals turned away for rooms that were in fact ready, rooms not put on sale because the status was never updated, and prices calculated by automated systems on a declared availability different from the real one. The last effect is the most insidious because it leaves no trace in the reports.
What separates a real integration from a declared one? The direction and the timeliness of the write. An integration that reads status from the management system without writing it back, or that writes it back late, creates two divergent sources of information about the same room. At that point staff pick one to trust, and the integration delivers no operational benefit.
What are the main obstacles to adopting these tools? They are neither technical nor economic: in most management systems in use in Italy the housekeeping module is already included in the subscription. The obstacle is training the housekeeping team, made difficult by seasonal turnover, by concentrating the training into the days around opening, by language barriers among staff, and by the fact that the person entering the data is not the person who benefits from it. To those add underrated practical conditions, such as network coverage on the guest floors and the device people are asked to work on.
Why does partial adoption of the module not work? Because the value of room status depends on its overall reliability. If updates are only partly timely, the front desk goes back to checking by phone and the data stops being the source of truth, becoming a duplicate to be verified. It is therefore better to start on a narrow perimeter and widen it only once the timeliness of updates is close to total.
A note on sources. The figures on the size and composition of the Italian hotel stock are taken from Federalberghi’s tenth report on the Italian hotel system, compiled on ISTAT data. The order of magnitude given for the cost of previous-generation system interfaces comes from the international literature on PMS integration and has not been verified against the Italian market, where commercial practice is uneven. The productivity and saving percentages that circulate on this subject have not been reported here: the reason for excluding them is set out in the body of the article.