Hotel management system in Sri Lanka: what a 40-room property actually needs

A forty-room property in Sri Lanka is a specific kind of business, and most hotel software is not built for it. The international platforms are built for chains that have a revenue manager and a distribution team. The cheap local options are built for guesthouses that need a booking list. Forty rooms with a restaurant, a bar, a couple of vans and eighteen staff sits uncomfortably between the two.

Before we wrote a line of specification for our own hotel product, we documented 202 operational problems across 22 domains of hotel operations, and reviewed five competing systems feature by feature. A large share of those problems came from properties of exactly this size. What follows is what that research says a forty-room hotel actually needs, and, just as importantly, what it can safely skip.

Where a forty-room property actually loses money

Not in one big place. In twenty small invisible ones, each too small to investigate and collectively larger than anyone’s estimate.

The recurring ones:

• A bar tab that never reached the folio. The drink was poured, written on a chit, and the chit did not survive the shift.
• A transfer nobody charged. The van went to the airport as a favour because the paperwork was harder than the trip.
• An upgrade given away with nothing recorded to show for it.
• A supplier invoice paid twice because nobody had a record of the first one.
• A minibar consumed and never posted, because posting it required a walk-through that happened on Thursdays.
• A late check-out argued over at the desk instead of priced by the system.

Each of these is a handful of dollars. There are dozens of them a week. And none of them will ever show up in a report, because the whole nature of the loss is that no record was created.

That is the first thing a forty-room property needs from software: not analysis, but capture. Reporting on revenue you never recorded is not a feature.

The seven-step problem, and why it matters more here than anywhere

Count the hands a drink passes through before it becomes money in a typical independent hotel:

1. Drink poured
2. Written on a chit
3. Waiter phones reception
4. Reception notes it down
5. Chit survives the shift
6. Keyed into the folio
7. Reconciled at month-end

Three of those seven steps are failure points, and all three depend on a person remembering to do something while doing something else. At a five-hundred-room chain property there is a night auditor whose entire job is to catch what fell through. At forty rooms there is not.

The version that works is three steps: drink poured, waiter taps charge to room, guest confirms with a PIN issued at check-in. It is on the folio and in the accounts against the right outlet before the glass is empty.

The PIN matters more than it sounds. Accepting a room charge at a table without verification is how disputes at check-out start, so most independent properties either refuse room charges in the restaurant or accept them and argue later. A PIN handed to the guest at check-in makes the charge safe to accept, which is what actually unlocks the revenue.

This is the single highest-value thing a forty-room property can fix, and it has nothing to do with rooms.

What changes at forty rooms that did not matter at fifteen

Below about twenty-five rooms, one person holds the whole property in their head, and they are usually the owner. The system’s job is mostly to remember things on their behalf.

Past about forty, that stops working, and the failures change character. They stop being about capability and start being about handoff. Everyone knew. Nobody was responsible. The information was retold rather than recorded, and it degraded at every retelling.

Three specific things start to matter at this point, and none of them are in a feature comparison:

Shift handover that is not closed until it is accepted. A handover that is written and filed is a diary entry. A handover that stays open until the incoming manager acknowledges it is a transfer of responsibility, and the difference shows up the first time something goes wrong at 2am.

An incident register that outlives the shift. Logged with a location, an owner, a severity and a status. Otherwise the guest complaint on Tuesday night and the same complaint on Friday night are two unrelated events rather than a pattern with a cause.

Housekeeping with a verification stage. Three departments have to agree on the state of one room: front desk, housekeeping and maintenance. Without an explicit sign-off the room status board becomes an opinion, and the first person to be embarrassed by it is your receptionist, in front of a guest.

What “the rest of the hotel” means

Rooms are about a third of your hotel. Every hotel system handles reservations, room status and billing well enough. That is the easy third, and it is where most of the market stops.

The other two-thirds of a forty-room property:

• A restaurant with a food cost, covers, and a bar with stock in it
• A store holding linen, amenities, dry goods and beverage
• A payroll with shift patterns, overtime and service charge distribution
• A maintenance schedule covering the generator, the pool pump, the lifts and the vehicles
• A fleet doing airport runs and excursions
• A supplier ledger and a purchasing process
• A set of accounts somebody has to file

Software that ignores all of that is not managing your hotel. It is managing your rooms and leaving you to run the business on spreadsheets, WhatsApp and memory, which is exactly what most forty-room properties are doing, and exactly why the answer to “where do your numbers live” takes four sentences.

This is the case for running a property on a hotel ERP rather than a PMS: not because ERP is fashionable, but because a hotel is precisely the shape of business ERPs were designed for, and the front desk is one department in it rather than the entire product.

What the research actually covered

The 22 domains behind those 202 problems are worth listing, because they are a fair map of a hotel that software is expected to touch: reservations, front desk, housekeeping, maintenance, food and beverage service, kitchen and production, stores and inventory, purchasing, supplier management, finance and accounting, payroll, rostering and attendance, transport and fleet, guest care and preferences, security and access, incident management, shift operations, sales and rates, direct distribution, reporting, multi-property administration, and compliance.

Fewer than a quarter of the documented problems sat in the first two. That ratio is the whole argument. A company that only knew front desks would have built another front desk.

Two findings from that work are worth repeating to anyone shopping at this size.

The first is that the most costly problems were almost never technically difficult. They were handoffs: a fact known by one department that needed to reach another, and travelled by memory. An allergy noted at check-in and mentioned at the desk reaches the restaurant only if the person who took it is still on shift.

The second is that properties consistently underestimated how much of their loss was uncaptured rather than unanalysed. Every property we spoke to wanted better reports. Most of them needed better capture first, because the reports they wanted were about revenue that had never been recorded.

The checklist for forty rooms

Weight these in roughly this order.

1. Every charge reaches one folio, without a phone call. Restaurant, bar, minibar, transport, laundry, add-ons. If any of them requires someone to walk a piece of paper to reception, that revenue will leak at a predictable rate.

2. A direct booking engine on your own website. Commission on an OTA booking at a forty-room property is a meaningful share of the margin. A booking engine writing live availability straight into the system, on your own domain, pays for a lot of software.

3. Check-out generates the housekeeping task. Not a board someone updates. Priority, assignment, and a verification step. A room is ready because somebody signed it off, not because somebody said so.

4. Add-ons sold at check-in. The one moment the guest is guaranteed to be standing in front of you is the only reliable upsell window a small property gets. If selling a transfer or an upgrade takes three screens, it will not happen.

5. Accounting in the same database. Room revenue, F&B and ancillary posting to the ledger as they are charged, tagged to the outlet that earned them. The alternative is a month-end reconciliation between a PMS, a till and a spreadsheet, which at this size means the month is understood about three weeks after it ended.

6. Purchasing, stock and supplier bills in the same system. This is where the duplicate payments and the unexplained beverage variance live.

7. Dietary requirements as structured data. Storing an allergy is not the same as acting on one. A defined list captured at check-in and routed to the kitchen and housekeeping is a different thing from a note in a field somebody has to remember to read, and at a property where the chef also does the ordering, the difference is real.

8. Guest history that survives the stay. A returning guest recognised, with their previous room, their preferences and their complaint from last time, costs nothing to keep and is most of what a small hotel has instead of a loyalty programme.

What a forty-room property can skip

Being equally clear about the other side, because these are what the expensive platforms charge for.

Channel management across hundreds of OTAs. If you sell through three or four channels, a three-hundred-channel manager is not solving your problem. It is worth having eventually; it is not worth choosing your entire system around at this size. Be aware this cuts both ways. If distribution is what decides your purchase, the established platforms are ahead of anything built around the back office, ourselves included, and you should hear that before you sign rather than in month three.

Algorithmic pricing. Revenue management systems earn their keep on inventory large enough that a percentage point matters and volatile enough to need daily repricing. Forty rooms with a known season pattern does not qualify yet. Seasonal rate plans configured properly will get you most of the way.

Multi-property consolidation. Unless you are actually planning a second property inside two years, this is a feature you will pay for and not use. Do check it exists, because you may want it later.

A dedicated night audit process. At this size the audit should be a consequence of everything posting as it happens, not a nightly ritual.

What it takes to put in

An honest note on effort, because it is the question that follows every feature list.

A forty-room property with one restaurant, a bar and a small fleet is not a six-week project and it is not a year. The variables that actually move the number are the count of outlets, whether you are migrating booking and guest history from an existing system, how much of your chart of accounts already exists in a usable form, and how many people need training on the front desk across shifts.

The thing that most often overruns is not configuration. It is data: rate plans that exist in three versions, a guest list held in two systems and a spreadsheet, and supplier records nobody has cleaned since 2019. That work is yours, not the vendor’s, and starting it before the project does is the cheapest scheduling decision available to you.

Ask for the timeline in writing as part of the proposal, from every vendor you are talking to, and treat a number given before anyone has looked at your data as a number that will be walked back. The same rule holds for the budget: the things that actually drive what an implementation costs are knowable in advance even when the total is not, and how we run an implementation is a fair guide to where the weeks go.

Two questions to put to every vendor

“Where do my numbers live?” Count the answers. If the reply involves a PMS, plus a till, plus an accounting package, plus a spreadsheet, plus an integration between them, you are being sold four products and a maintenance liability.

“Show me the three things that go wrong most often.” The bar tab that vanished. The transfer nobody charged. The month-end that took three weeks. Ask each vendor to show you, live, what their system does about each one. Not on a slide, on a screen. Thirty minutes is enough, and the demos that cannot survive it are the ones worth knowing about early.

Owning your data

One more, because it is easy to forget when you are comparing features. The database should be yours, exportable in full, at any time, without needing your supplier’s permission or continued goodwill to keep operating.

Ask every vendor on your shortlist that question directly, and notice which ones need a moment before answering.