Hotel technology by size: what 10, 40, 120 and 300 rooms really need
Room count is a proxy, not a standard. Learn what hotel technology is essential for properties of 10, 40, 120, and 300 rooms, and how to judge supplier quotes against your own operation.
Contents
Key takeaways
- Room count is a proxy, not a standard: the real triggers are shift handovers, separate outlets, overnight coverage and how many people touch one booking.
- Below about 10 rooms the essential list is short: one calendar that cannot sell a room twice, a way to take payment and issue a fiscal document, the guest identity notification, and personal data handled on purpose.
- A property usually needs a real hotel operating system when two people work the same booking in one day and hand over by memory.
- Above roughly 120 rooms the constraint moves from features to integration count, training and a named owner of the systems.
- Whatever the size, three things are non-negotiable: a backup you have restored once, two-step sign-in on every admin account, and a second support contact who answers.
Hotel technology is the systems, network and hardware a property runs on. Room count is only a proxy: what changes is how many people touch one booking, how many outlets earn money, and whether anyone covers the night. A 10-room pension needs booking protection and legal basics; a 300-room resort needs integration management and a named IT owner.
A 12-room pension and a 300-room resort both need to stop selling the same room twice. Everything else about their technology differs, and most buying mistakes start with copying the bigger property's list. After reading this page you will be able to place your own property in one of four size bands, know what is essential, what can wait and what is a waste in that band, and judge every supplier quote against your own operation rather than someone else's feature list.
What actually changes when a hotel gets bigger?
Not the list of categories. What changes is how many people touch one booking, how many places earn money, and whether anyone is awake at three in the morning to fix a problem.
Four variables do the work. First, people and shifts: how many colleagues handle the same reservation between arrival and departure. Second, outlets: rooms, restaurant, bar, spa, shop, each one a place that takes money. Third, hours of coverage: a 24-hour desk, a night porter, or nobody. Fourth, volume, which is better measured in bookings per day than in rooms, because a 20-room city hotel can turn more bookings than a 100-room resort.
At small size, a system that records is enough. One person books, checks in and bills, so a single record of the truth covers the whole operation. A system that coordinates becomes necessary when several departments act on the same state at once: the room is clean, the room is blocked for maintenance, the bill is still open. Now the record has to tell three people three different things without them phoning each other.
The cost of a failure also rises with size. A double sale in a 10-room pension is an awkward conversation and a discount. In a 300-room resort it is a walk to another property at midnight, a refund and a review.
Room count is a proxy, and an imperfect one. Two 40-room properties can need different stacks if one runs a restaurant and a 24-hour desk and the other is seasonal with one manager on duty. There is also a threshold where one person still holds the whole picture in their head. While that is true, software is optional. When that person takes leave, the system becomes the memory, and that is the week the property discovers what it actually needs.
The decision rule is simple: write the four variables down before you compare any system, and judge every quote against that page rather than against a competitor's room count.
| Band | Who touches one booking | Money outlets | Overnight coverage and what the software must do |
|---|---|---|---|
| Up to 10 rooms | Owner plus one | Rooms only | Often nobody; must prevent double selling and hold the legal steps |
| Around 40 rooms | Two to four people, two shifts | Rooms plus maybe one outlet | Night person or on-call; must coordinate rate and availability across channels |
| Around 120 rooms | Departments | Rooms plus two or three outlets | Staffed night desk; must hold state several departments act on, report by department |
| 300 rooms and above | Many people | Several outlets and revenue centres | 24-hour; must manage many interfaces and have a named owner |
These bands are illustrative, not standards. Read them as descriptions of pressure, not as thresholds written anywhere.
What does a hotel with up to 10 rooms actually need?
A short list: one calendar that cannot sell the room twice, a way to take payment and issue a fiscal document, the guest identity notification, and personal data handled on purpose. Most of the rest can wait.
The essential items are these. A single booking record that is the truth for every channel, whether that is a spreadsheet, a small cloud system or a paper diary, as long as it is one record. A payment terminal and a fiscal device for the sale. The guest identity notification, KBS in short, prepared from the check-in flow rather than copied by hand into a separate portal. A decision on personal data under KVKK, the Turkish personal data protection law: what consent you take, what you keep and for how long. And a copy of the booking data that does not live on the same laptop as the original.
Channel discipline comes before channel software. Either a channel manager, or a written routine that closes availability on every channel by hand at the same time each day, with one person accountable for it. Half of one is worse than either: a channel manager nobody checks, or a routine nobody follows, both produce the same double sale.
What can wait at this size: a housekeeping module, a restaurant point of sale, a guest app, department reporting, door-lock integration. What is waste: a system whose long report list nobody opens, a server standing in the back office, and a lock system with more integration surface than the property has doors. If you are weighing up the small end of the market, our guide to software for a pension or small hotel goes deeper.
The spreadsheet trap deserves its own warning. A shared file works until two people edit it and one forgets to save. The warning signs are double bookings, a rate that is current on one channel and stale on another, and no record of who changed what. When those signs appear, the property has crossed into the next band; our article on outgrowing the spreadsheet covers that step.
Keep the number of systems small enough that one person can hold them all, because at this size that person is usually the owner or the single front-desk colleague. On regulation, this article describes the duty and stops there: confirm dates, thresholds and penalties for your own case with an accountant or legal adviser.
When does a hotel around 40 rooms need a real PMS?
When two people work the same booking in one day and hand over by memory. That is the trigger, not the room count.
A hotel operating system, or PMS, earns its place when it holds the state three people need at once: availability, the guest's bill, and the room's cleaning status. Until then, the booking record alone does the job. Once the morning shift, the evening shift and the housekeeper all act on the same reservation, the record has to serve all three.
A channel manager stops being optional here, because rates and availability now change more often than one person can push them by hand across every channel. Card locks usually arrive at this size too, and with them the first real interface: the front desk expects a key to be written from the reservation, not typed into a second screen.
Night audit becomes a routine rather than an event. The business day closes, corrections are voided and reversed instead of deleted, and the numbers someone reports upward have a defined source. Groups and corporate accounts also appear: a block of rooms, a company that wants one invoice, an agency that wants its own rate. These need a place in the system, not a note in a book.
The honest test is a bad week: a full house, one colleague sick, and a rate change that has to reach every channel by noon. If that week is survived by memory and phone calls, the property has outgrown its tools.
One warning travels in the other direction: do not buy the 300-room feature list at 40 rooms. Every module you switch on is a routine someone must run, and a routine nobody runs is worse than a missing feature.
ChecklistSigns a property around 40 rooms has outgrown manual tools
- Two people edited the same booking today
- A rate is different on two channels right now
- Nobody can say who changed yesterday's availability
- The night person writes the day's numbers on paper
- A group booking lives in an email thread
- The key card is written on a second screen
- The owner is the only person who knows how the calendar works
What changes at around 120 rooms?
Departments appear, and the software's job shifts from recording to coordinating between them. Interfaces, training and reporting by department matter more than any single feature.
Outlets multiply: restaurant, bar, possibly a spa or a shop. Each one needs a point of sale that posts a charge to the guest's bill, and each one is a place where a charge can go missing. Housekeeping becomes a routing problem: which rooms are due, in what order, by whom, and how the front desk knows a room is ready without walking to it.
Technical and maintenance work needs its own record: a fault, who owns it, when it was closed. Without it, the same broken item is reported three times and fixed once. Reporting splits by department too, because a restaurant that loses money can hide inside a good rooms result. The system must be able to show each outlet's own numbers.
Someone must own the systems. Not a department, a named person with the authority to say no to a new tool that nobody will maintain. Interfaces are now the risk: a fiscal device connected outlet by outlet, a lock system, an e-invoice flow that waits for a person's review before sending. Each one is a place where a quiet failure costs money.
Training and staff turnover become a software requirement in their own right. If a seasonal colleague cannot learn the check-in flow in one shift, the system is wrong for the property, whatever its feature list says.
Watch outUntested interfaces are promises
An interface that has not been tested with your own device, in your own outlet, on your own network is a promise, not a feature. Ask for the test, not the logo.
What does a hotel of 300 rooms and above need that smaller ones do not?
An owner for IT, a network that separates guests from systems, and a plan for the two hours when the software is not there.
The constraint stops being features and becomes integration count: locks, point of sale per outlet, fiscal devices, e-invoice, telephony, Wi-Fi sign-in, payment, access control. Each interface has a failure mode and someone must know it. Someone owns IT: an in-house person, a contracted IT company, or a clear split between the two. The decision is about response time and authority, not headcount, and who runs IT at a hotel is a question worth its own page.
Separate the guest network from the systems network, so that a full house streaming video does not stop the front desk from checking someone in. Change management becomes a real process: a rate change that must reach many places needs an approver, a person who checks it landed, and a record of who asked.
Contracts matter more here, because migration cost grows with integration count. Ask for data export in a usable format, notice periods and exit terms before signing, not after. Write the downtime routine: pre-printed registration cards, a paper room plan, a named person who decides when to switch to paper and when to switch back.
Expect the systems to outlive the staff who chose them. Documentation written by the property, not only by the vendor, is what makes the next handover survivable.
What does every property need, whatever its size?
Three things: a backup you have actually restored, two-step sign-in on every account that can move money or guest data, and a second support contact who answers when the first one does not.
The backup test is a restore, not a schedule. Ask when the last restore was performed, by whom, and how long it took. A backup nobody has restored is a hope. Two-step sign-in belongs on the accounts that can change rates, void a bill or export guest data, because those are the accounts worth stealing. A second line of support means a named person, a number and an escalation path. Ask what happens at 23:00 on a Saturday in August, and write the answer down.
Beyond those three, keep one page saying which system holds the truth for which fact: the rate, the availability, the guest record, the bill. Two systems holding the same truth is how a property ends up with two prices. Insist on a contractual right to take your data out in a usable format, and test that export once before you need it; it is the cheapest insurance against a supplier relationship going wrong. Finally, write the routines for the steps that repeat: night audit, closing channels, checking that guest identity notifications went out, and who reviews e-invoices before they are sent.
ChecklistThe size-independent checklist
- Last restore date known
- Two-step sign-in on every admin account
- A named second support contact with a number
- A one-page map of which system owns which fact
- A tested data export
- Written night audit and channel-closing routines
- One person named as owner of the systems
Where do the rules change: apart hotels, glamping sites and mixed facilities?
Three property types break the size logic: apart hotels bill by the month, glamping sites often lack the power and connectivity a fixed terminal assumes, and Ministry-certified facilities of mixed type are not all hotels.
Apart hotels change shape before they change size. The stay is measured in weeks, the bill includes meter readings and a deposit, and the guest may be a company needing its own invoice. The billing model shapes the stack more than the room count does; software for aparthotels covers this in detail.
Glamping and seasonal sites have a different constraint: connectivity and power. Plan for a check-in that survives a dropped line, and expect fewer fixed devices rather than more. A pension with a restaurant changes more by adding the outlet than by adding rooms: a second cash point, a second place charges can go missing, a second set of daily numbers.
Seasonal properties can accept manual steps in the low season that would break in the peak week. Judge the stack against the peak week, not the average one. Mixed-use properties should describe their own operation first, then choose tools, because a system built for one shape of business will fight the other.
Wording matters when you read public statistics. The Ministry of Culture and Tourism's certified accommodation figures (August 2026) count facilities of several types, including apart hotels, pensions and boutique facilities, not hotels alone, so do not read them as a hotel count for your segment.
What to do next
Write one page about your own property before you talk to any supplier: how many people touch a booking, which outlets take money, who covers the night, who is on call at 23:00, and which system holds which fact. Every quote you receive can then be judged against that page instead of against a bigger hotel's feature list, and the size bands in this article become a way to read your own answers rather than a standard to reach.
Frequently asked questions
Does a small hotel need a channel manager or can it manage channels by hand?
By hand is workable only with a written routine that closes and opens availability on every channel at the same time each day, and one person accountable for it. The moment rates change more often than that routine runs, or two people sell the same room, a channel manager is cheaper than the mistake. The decision is about frequency and ownership, not room count.
How many rooms before a hotel needs a full-time IT person?
There is no threshold in rooms; the question is response time. Below a certain size a contracted IT company plus a named internal owner is enough. What matters is that someone has the authority to refuse a new tool, and that a fault at night has a number to call. Integration count, not room count, is what eventually justifies an in-house role.
Can one hotel operating system run a 10-room pension and a 300-room resort?
The same product can often be configured for both, but the operating routines around it cannot. A small property needs few modules switched on and one person who knows them; a large one needs departments, interfaces and a change process. Buying the large configuration at small size creates routines nobody runs, which is worse than a missing feature.
What should a new hotel buy first?
The system that holds the booking record, because everything else refers back to it. Then the payment and fiscal path, then the guest identity notification, then the channel connections. Personal data decisions, backups and two-step sign-in belong in the first week, not after the first busy month.
Is cloud software or an on-site server better for a hotel?
Cloud moves the maintenance to the supplier and makes the internet line a single point of failure; an on-site server keeps working when the line drops but needs someone to patch, back up and replace it. The honest answer depends on your connectivity, your staff and whether anyone at the property can look after a server. Decide the downtime routine first, then pick the model that fits it.