Hotel management software: the room sold twice, channels updated by hand and the empty nights nobody sees

It is ten o'clock on a Saturday night in June, in a forty-room hotel on a lake, and at the front desk two couples with suitcases in hand are showing the same confirmation for room 12 on their phones. One booked on the website at seven, the other on Expedia at nine. The availability was right in the receptionist's head, right on the sheet, right on Booking and wrong on Expedia, because at three in the afternoon a cancellation had freed the room and someone had reopened it in one place only. One couple sleeps elsewhere at the hotel's expense, and tomorrow writes a review.

Hotel management software exists to take that Saturday away, but not every hotel needs it, and those that do often buy the booking engine first and only then find the problem was behind it. Here is what the term really means, the number that says whether you need it, what it costs not to have it, how channels are kept aligned, how guests are registered without retyping, and when a ready-made product is enough and when to build something.

An honest preface: since 1999 I have been building software for companies, and I built and sold LegalDesk, a program for law firms where a missed deadline is damage. A hotel has the same problem with a different raw material: a room not sold tonight cannot be sold again. The case I use throughout is a typical forty-room hotel, built from orders of magnitude I have seen in similar projects and from sector averages: they are not a client's data and I do not want them taken as such. They show the method, and you can redo the method with your own numbers in an afternoon.

What is hotel management software, and what is it not?

Hotel management software is a system that keeps in one place the things a lodging business touches every day: room availability, the record of each booking, guest registration, the bill with deposits and extras, the invoice and the legal obligations. In the trade the central part is called a PMS, a property management system, and the piece that keeps sales channels aligned is called a channel manager. The value is in none of these functions alone; it is in the fact that each one reads what the other has written.

It is not the website with a booking engine. That collects a direct booking, which is useful, but on its own it does not know that room 12 was sold half an hour ago on another channel. It is not the invoicing program: it issues electronic invoices and nothing else, and it usually ignores the tourist tax, the deposit and the restaurant bill. It is not the spreadsheet with the room chart, which works very well as long as one person writes in it, and stops working the day there are two.

The difference shows with one question: "which rooms are free tonight, on every channel, right now?". If the answer means opening three pages and trusting what the receptionist remembers, what you have is a set of tools, not a management system. That is not necessarily bad: an eight-room hotel with a single channel can live perfectly well with a shared calendar, and further on you will find the threshold below which nothing else pays.

For a more complex property the definition widens: groups and agencies with their own rates, packages with half board, the restaurant and the conference room that charge to the room bill, and several properties under one owner with different price lists. The wider it gets, the less a standard product looks like you, and that is where the question of what to build comes from.

What if the hotel already has a system?

It is the most frequent case, and the answer is almost never "throw it away". Before changing, measure what it does and what it does not: if your system updates the channels by itself, prepares guests for the police and works out the tourist tax, the problem is not the tool but how it is used. If instead every answer needs an export and a sheet, you have an archive, not a management system. In that case the cheapest road is often a small piece next to what you have, which reads the data and produces the day's list, without touching cash and accounting.

One last cost, which sellers do not work out: the cost of changing your mind. A product is left with a data export and a month of annoyance; a custom piece has an owner, and it is you. Before signing any contract, ask how guest records, booking history and rates are exported, and in what format. It is the question that separates those who treat you as a customer from those who treat you as a hostage.

Why does a hotel sell the same room twice?

It happens because availability lives in several places and each place is updated by hand or with a delay. No single step is a mistake: the cancellation is recorded, the room is reopened, the customer books. The damage is in the space between one channel and another, in those minutes or hours when the same room shows as free in one place and sold in another.

The first gap is between the cancellation and the reopening. Whoever takes the cancellation writes it wherever they happen to be, and then has to remember to reopen the room on every channel. Someone who does it on four out of five leaves the fifth closed, and the room stays unsold for a reason nobody will ever see. In the typical case that is 160 nights a year, about one room empty every other night in rotation, idle because somewhere it showed as full.

The second gap is the opposite, and the most visible: the room reopened too early, or sold twice. Here the hotel has to relocate the guest to another property, usually of equal or higher category, pay the difference, often refund, and almost always collect a review under four stars. In the typical case a relocation costs about 210 euros between a night elsewhere, transport and refund, and with twelve episodes a year that is 2,520 euros. It is the smallest item, and the one remembered most, because it has a face and a specific evening.

The third gap is in rates: each channel has its own price list and its own rules, and every time a price changes it has to be changed five times. The fourth is in special requests: the extra bed, the quiet room, the breakfast intolerance, which arrive by email and phone and end up on a sticky note. The fifth is arrival: whoever arrives after eight in the evening finds a different receptionist from the one who took the booking, and has to explain everything again.

None of these errors has a culprit, and that is why they cost. A system that just shows a chart does not see them; one that keeps a single record for each booking and a single availability brings them out one by one, with a room and an amount. The rule I use with clients is simple: if answering "which room is free tonight" takes more than ten seconds and more than one person, availability is not under control.

How much does it cost every year to run the hotel with sheets and unconnected channels?

It is worked out in six items, each measurable with data the hotel already has. The typical case is a property with 40 rooms, 62 per cent occupancy and an average rate of 112 euros a night. That makes 9,052 nights sold a year, about 1,014,000 euros of rooms and, with breakfasts, bar and extras of about 186,000, 1.2 million euros of revenue. Bookings are about 4,100, with an average stay of 2.2 nights, and arrive from five channels: two booking portals, the website, phone and email, agencies and groups.

The first item is rooms left empty because availability is not aligned: 160 nights a year when a room was empty and showed as closed on some channel. At 112 euros that is 17,920 euros, 35 per cent of the total. It is the item nobody sees, because it leaves no trace: a room nobody booked does not complain.

The second is front desk time: each booking takes on average nine minutes of retyping between the guest record, the police communication, the internal register and the invoice data. For 4,100 bookings that is 615 hours, at 19 euros an hour 11,685 euros. The third is avoidable commissions: portals usually keep between fifteen and eighteen per cent, and if a hotel without a booking engine on its website brings direct sales five points below what it could, that is 450 nights, and the sum is 450 times 112 times 17 per cent, 8,568 euros.

The fourth is bookkeeping, invoices and the tourist tax reconciled by hand: six hours a week for 52 weeks, at 22 euros an hour, 6,864 euros. The fifth is rates left unchanged on nights that are nearly full: 22 nights a year when the hotel was full three days ahead and the last ten rooms were sold at base price when fifteen per cent more could have been asked, for 3,696 euros. The sixth is double bookings, already seen: 2,520 euros.

The total is about 51,250 euros a year, 4.3 per cent of revenue. The first three items alone weigh 74 per cent. A practical rule: below 2 per cent of revenue the problem is not a priority and it is better to look elsewhere; above 4 it almost certainly is. Between 2 and 4 it depends on how much you are growing and how much you work in high season, where the items weigh double.

Which of these items are estimates and which are measurements?

I say it plainly because it is where quotes get rigged. Nights sold, front desk hours and commissions are measurements: you find them in the system you already have or in the portal statements. Nights closed in error and rates not raised are estimates, and estimates can be checked: for the first, compare the chart with the portals every morning for a month; for the second, look at the last ten rooms sold on full nights. If you do not have the time to measure them, take those two items out: the total drops to about 30,000 euros, and the conclusion usually stays the same.

What is the number that decides whether you need hotel management software?

It is not the number of rooms, nor the season. It is how many channels you update by hand: in how many different places you have to write the same availability or the same price every time something changes. You count it in five minutes: booking portals, website, phone and email, agencies, any restaurant or room that sells together with the rooms. Each extra place multiplies the chances of error, and the growth is not linear, because each pair of channels can drift out of sync.

The thresholds I use are these. With one channel or none the problem does not exist: a shared calendar or a sheet is enough, and anyone proposing a ten-thousand-euro system is selling you a problem you do not have. With two or three channels and fewer than twenty rooms a channel manager is enough, usually costing between thirty and sixty euros a month and keeping almost everything aligned. From four channels up, or above twenty-five rooms, a complete system with the channel manager inside pays for itself, because besides alignment it takes charge of guests, bill and legal obligations.

The typical case has five channels updated by hand and forty rooms, so it sits in the third band. Alongside this, two checks that cost nothing. The first: how many times a year you have had to relocate a guest; above six is a strong signal, above twelve is an emergency. The second: how long passes between a cancellation and the reopening of the room on every channel. If the answer is "it depends who is on duty", the average time is much longer than you think.

For the number to be honest it must be measured in high season, not in November. In November almost nobody makes mistakes, because there are few bookings; in June and September the number of events multiplies and so do the errors. It is better to calculate it by band too: the full weekend and the empty midweek have different stories. And if you have more than one property, count the channels of each: the complexity is the sum, not the maximum.

How do you keep availability aligned across portals, website and phone?

You keep it with a single source of truth and a piece that copies it to the other channels every time it changes. The source is the management system: every sale, cancellation or block is recorded there, however it was born, and the channel manager carries it to each portal within seconds. Where reopening is automatic, nobody has to remember anything, and that is the real gain.

The details that decide whether it works are few. The first is the direction of the flow: a booking arriving from a portal must go down into the system and from there close the room on the other channels, not the other way round. The second is the room type: if you sell "standard double" and have fifteen identical rooms, the system must count, not assign; assigning the right room is done at arrival, and an assignment made too early removes flexibility. The third is closures: a room under maintenance or held for the owner must close in one place only.

Then there is the topic almost nobody considers: what happens when the connection stops. A channel manager can be down for an hour, and in that hour the portals sell with the last availability they have. A serious system has a safety margin, that is it always shows one room fewer than are free on the portals on full nights, and has an alarm that warns the front desk if the last update is older than fifteen minutes. These are two rules that cost nothing and save the June Saturday.

For direct bookings the reasoning is the opposite: the hotel's website must be able to sell the same availability, with a slightly lower rate or a concrete advantage such as breakfast included or parking. The booking engine on the website, connected to the system, is the cheapest way to reduce commissions, and in the typical case it is worth 8,568 euros a year with only five points of share moved. It is not obtained with the website alone: the price on the site must really be better and the page must load fast on a phone.

And for phone and email it remains a human task, but with help: whoever answers must see the same availability as the website, at the same instant, and be able to hold the room for fifteen or twenty minutes while the guest decides. Without that hold, the room you offer on the phone is the same one the website is selling. Nothing sophisticated is needed: there must be a single table of rooms.

How do you register guests, police notifications and tourist tax without retyping?

You register them once, at booking or arrival, and the data flows down on its own to where it is needed. In Italy every lodging business must communicate guests' details to the police within twenty-four hours of arrival, through the Alloggiati Web portal; it must then report movements to the regional statistics office and, where one exists, collect and pass on the tourist tax to the municipality. These are three obligations asking for the same data: name, date of birth, nationality, document, arrival and departure dates.

The classic defect is that this data is written three times: on the paper form at arrival, on the police portal in the evening, in the tax sheet at month end. The time is what weighs in the typical case, 11,685 euros a year, but the risk is elsewhere: a transcription error in a document, a communication forgotten on a very busy day, a tax miscalculated for a group with exemptions. These are the points where a check goes wrong, and where an automatic check does not get distracted.

Good software lets you collect data before arrival: the guest fills in a form from their phone with the booking confirmation, uploads the document, and at the front desk all that is left is to verify and hand over the key. This alone removes the queue at the desk at six in the evening, which is where most time is lost. The data goes into the format required by the police portal and the statistics, and the system works out the tax by municipality, days, age and exemptions.

Mind the two limits. The first is data protection: guests' documents are personal data, and whoever collects them online must say how long they are kept and who they are passed to, deleting them when the reason is over. A system that keeps them forever on a service from a supplier you do not know is a risk to decide on coldly, before buying. The second is responsibility: the communication to the police remains with the operator, even if the system prepares it. The system must warn when a submission is missing, not hide it.

The list of obligations also includes the national identification code, the CIN, which properties must display and show in their listings. A well-made system keeps it on the property record and carries it onto the website and portals, so it is not forgotten in any of the places where it must be written. It is a small example of a general rule: every piece of data that goes into several places must live in only one.

How do you invoice and collect stays, deposits and restaurant bills?

You invoice and collect starting from the same record the booking was born in. The deposit paid, the balance on arrival, breakfast, bar, parking and the restaurant bill are charged to the room and closed in a single electronic invoice, with the tourist tax separate from the price. When things sit in one place, the bill at departure prints in a minute instead of twenty.

There are three points where a hotel loses money. The deposit: asked for by phone and collected with a transfer nobody matches to the booking, or forgotten altogether, and the next day the room sits blocked for a guest who does not show up. A serious system records the deposit on the booking, deducts it from the balance and, where applicable, keeps it in case of no-show under the written rule. The restaurant bill: the charge to the room made verbally or on a sheet, which cannot be found the next morning. The extras: the minibar, parking, excursions that are forgotten at billing, and that in a year are worth more than you would think.

Then there is invoicing proper, with its rules: private customers, companies with a VAT number asking for an invoice on arrival, groups with a single invoice made out to the agency, vouchers and agreements. Here the ability to split the bill counts: the room charged to the company and the extras to the guest, two invoices from the same record, without retyping. A system that cannot do it forces you to rewrite, and when you rewrite you make mistakes.

A figure the hotelier never works out is the bookkeeping. If every payment, by cash, card, transfer or portal, ends up on the right record, the daybook generates itself and the accountant receives a file instead of a bundle of receipts. In the typical case the six weekly hours of reconciliation drop to one, and the saving is not in the hours but in the absence of errors at month end, when it turns out that a portal's payment does not match the invoice.

One point needs clarifying about portals: many collect from the guest themselves and pass the money to the hotel with the commission already deducted, others let the hotel collect on arrival. These are two different flows, with different deadlines, and must be treated as two different flows. Useful software can say how much the portals still owe at the end of each month, and does not leave it to be discovered from the bank statement.

How do you price rooms without guessing?

You price by looking at three numbers every day: how long before arrival, how many rooms are left and what price the same nights made last year. With these three you know whether to keep the base price, raise it or lower it, without guessing. A system that shows them together does in two minutes what by hand takes an hour, and above all does it every day instead of three times a season.

In the typical case there are 22 nights a year when the hotel was full three days ahead and the last ten rooms were sold at base price. If on those nights fifteen per cent more had been asked on the last ten rooms, as almost all the more attentive competitors do, revenue would have been 3,696 euros higher. It is not an enormous figure: it is the most uncertain item in the account, and for that reason it must never be sold as the reason to buy anything. But it is a figure that repeats every year, and grows with the size of the hotel.

Work on rates has an honest limit: raising prices is not enough if demand is not there. A hotel at sixty per cent occupancy in low season does not have a dynamic pricing problem, it has a demand problem, and no system solves it. Here the software serves something else: saying which days are really empty and which segments to offer them to, for example groups, companies or long stays with a dedicated rate.

It is better that a person writes the price rules, and that the system applies them. A concrete example: "if fewer than three days remain and fewer than five rooms are left, base rate plus fifteen per cent, never above the maximum written on the price list". A rule like that can be checked, changed and explained to a partner. A system that proposes a price without saying why, and applies it by itself, is a risk: the first time it gets it wrong on an Easter weekend, the hotel finds out from the reviews.

A last point concerns rate parity: portals usually ask that the price on the website is not higher than theirs, and some contracts impose it. Before giving the website a discount to move direct bookings, check what your contract says; many properties offer an advantage that is not a price, such as breakfast, parking or late check-out, which gets around the problem.

How much does hotel management software cost: product, PMS with modules or custom?

It depends on the road, and there are three. A ready-made product for hotels, with channel manager and booking engine, usually costs between 1,500 and 4,800 euros a year for a property of this size, with a setup between 500 and 2,000 euros. A system with extra modules, for example restaurant, conference room and wellness centre, sits between 4,000 and 9,000 euros a year. A piece built around your way of working, next to a product that already handles the till, costs between 25,000 and 60,000 euros in the first year.

In the typical case, a ready-made product at about 2,400 euros a year and 1,200 of setup recovers, conservatively, 60 per cent of the first three items, about 22,900 euros a year, and pays for itself in under two months. The custom piece costs about 58,000 euros more over five years than a product, and in the 40-room case brings an extra benefit of about 17,000: it does not pay. The sum flips higher up: the extra benefit grows with rooms, about 85 euros a year per room, and crosses the cost at about 136 rooms, or at a network of six or seven properties with rules no product knows.

When does building make sense? In three cases. The first is when you have several properties with their own rules: rates that pass from one to another, guests who stay in two places with a single bill, a single linen store. The second is when you sell something no product knows how to sell: packages with excursions, transfers, experiences with outside suppliers, where the room is a part and not the whole. The third is when your advantage lies in the process: if your property stands out for how it welcomes guests, a program that forces you to do it like everyone else is a hidden cost.

The rest of the time a product is better, and it is worth saying honestly: I build custom software for a living, and the most useful advice I give a forty-room hotel is almost always "buy one". Where I come in is when the product does not talk to the rest, for example to the accounting program or to the restaurant booking system: a small bridge, well built, can cost 5,000 euros and take five hours a week away.

How much does it cost to move from one system to another?

The real cost is not the licence, it is the change of habits. Changing system in mid-season is the surest way to have three wrong Saturdays in a row. The right moment is November or January, with future bookings imported from the old system, checked one by one in the first two weeks. The import of historic guests also counts, useful for anyone who wants to run a return campaign: clean data, without duplicates and with consent to receive messages where it is missing.

Where artificial intelligence helps in hotel management software, and where it does not

It helps where it prepares work for a person who then checks, and it must never decide alone where the hotel's money or the guests' data are involved. In a lodging business the line is clear, and it is worth drawing before buying anything that promises miracles.

It can write replies to guests' emails, in the guest's language and in the tone chosen by the hotel, starting from the booking record: a draft for each, which the receptionist reads and sends. It can summarise in three lines how the week went, how many arrivals, how many cancellations, which nights remain empty. It can suggest a price for nights still free by looking at dates, demand and the rules written by the owner, as a suggestion to approve. And it can answer the most common questions on the website, such as breakfast times and parking rules, with the information the hotel has written.

It must not set rates by itself or apply them on the portals without a limit written by a person. It must not decide a refund, a room change for an angry guest or the outcome of a complaint: these are decisions with a face, which need someone to answer for them. It must not even read guests' documents on an outside service unless the supplier has been appointed and regulated, because an identity document is data you do not send around for convenience.

The criterion for every "intelligent" function is only one: who answers for the error? If the answer is "a person who checked", it is fine. If it is "nobody, the system decided", it is not. It is the same criterion applied to any personal data: the less you put in the hands of an outside tool, the less you have to explain. An artificial intelligence service that receives guests' names, emails and stay dates is a supplier processing personal data, and must be regulated as such.

Which mistakes should you avoid, and where do you start in thirty days?

There are six mistakes, and I have seen almost all of them more than once. The first is buying the booking engine before measuring: you choose the most beautiful website and find out later it is not connected to availability. The second is importing everything as it is: duplicate guests, past bookings still open and old rates enter the new system and make it unreliable from day one. The third is not naming a person: a management system without someone who updates it and checks the channels ages in three months.

The fourth is not training the front desk. The system is as good as the person who enters the cancellation: if at the desk the cancellation is taken "verbally, I'll enter it later", the data does not exist and the room stays closed. The fifth is starting in the worst month: the first week of June or August, with the breakfast room full, is not the moment to try a new system. The sixth is not rehearsing plan B: what does the front desk do if the system does not answer for an hour? A printed page with the next three days' rooms and a written rule on the safety margin are worth more than a support contract.

Where you start, in thirty days, is this. In the first seven you count the channels updated by hand and calculate the six cost items with last year's data, marking which are measurements and which estimates. In the second week you compare the chart with the portals every morning, to discover how many nights show as closed by mistake. In the third you ask for two or three demonstrations from products that connect to your portals, bringing real bookings and a cancellation case. In the fourth you choose, ask how the data is exported, and set the start for a quiet month.

If after six months nights closed in error and relocations have not dropped, the fault is not the program's, or not only: someone is still writing availability outside the system. That is why the measurement is repeated, with the same method, and written where everyone sees it. A system that costs three thousand euros a year and returns twenty thousand in rooms sold and hours saved is a result you can see, and one that whoever obtained it shows with pride to the accountant.

What if the number says it is not your problem?

It may be that, once measured, the channels updated by hand are one or two, relocations zero and nights closed in error almost none. It is good news, and worth saying clearly: in that case hotel management software is not for you, or you need a channel manager at forty euros a month, and anyone telling you otherwise is selling you something.

In that case the bottleneck, if there is one, is almost always elsewhere. If rooms are full but profits do not grow, the problem is staff costs, energy or restaurant margins, and a program does not solve them. If the property is empty in November and full in August, the problem is seasonality, and it is solved with an offer for another kind of guest, not with software. If you have eight rooms and are always at the front desk, you do not need a system: you need a person who keeps knowing guests by name and a notebook to remember who comes back.

And there is a case where software is not the answer even with ugly numbers: when guests choose elsewhere because the property is no longer what they were looking for. A hotel with dated rooms, a disappointing breakfast and a front desk that does not answer does not have a management software problem, it has a product problem, and double bookings are only the thermometer that signals it.

If you have read this far, you probably have your own June Saturday in mind. Before watching any demonstration, count the channels you update by hand and the times last year you relocated a guest. Then look at how long passes between a cancellation and the reopening of the room on every channel. If the channels are four or more, if you relocated more than six guests or if reopening depends on who is on shift, you already have the answer. The rest is a project, not a product choice.

If you want a second look at your case, the road is software consulting. And when the right solution is a piece built around your way of working, for a network of properties, a group with several brands or an offer no product knows how to sell, it is explained on the page about custom software. For the pieces around a hotel, you will also find the restaurant management software article, the staff scheduling software one, the time and attendance software one and the CRM software one for those who want guests to come back.