Hotel and restaurant software for small properties in Bangladesh: a buyer's checklist

Most small hotels, guesthouses and restaurants in Bangladesh still run on a register, a diary, a spike of chits and a calculator. That's not backwardness — for a ten-room property with one owner-operator, paper is genuinely fine. The trouble starts a bit past that size: multiple staff taking bookings, a restaurant attached to the rooms, payments split across cash and mobile banking, and an owner who can no longer hold the whole operation in their head.

That's the point where software gets evaluated, and it's also the point where a bad purchase does real damage — not just wasted money, but a few weeks of a confused front desk, an owner who loses trust in the new system after the first mistake, and a quiet reversion to the register that never needed a signal.

This is the checklist we'd want a property owner to run through before signing anything, regardless of which vendor is in the room.

The eight things to check

1. Does it actually work with no internet?

Not "it has an offline mode" — ask the salesperson to turn on airplane mode on the demo device, in front of you, and complete a booking. A front desk that depends on a live connection to check a guest in will eventually fail at the worst possible moment: during a storm, during peak-season network congestion, in a location the mobile operators have simply never prioritised.

2. Do rooms and the restaurant share one bill?

This is the single biggest source of lost revenue we see in combined properties. If a guest can eat at the attached restaurant and ask for it to go on the room bill, that charge needs to land on the same running total as the room charge — automatically, not via a chit someone has to remember to find at checkout. Ask to see it happen live: order a meal, tag it to a room, and look at the room's bill immediately afterward.

3. Can your actual staff read the interface?

An English-only interface quietly punishes whoever on your staff is least comfortable in English — usually the person who's been there longest and knows the operation best. If the software supports your staff's working language, confirm it's a full translation, not a handful of menu labels with everything important still in English.

4. Where does your data go if you stop paying?

Ask this directly, and listen for a vague answer. Some systems lock you out of your own historical records the moment a subscription lapses. Ask specifically: can you export your guest history, your financial records and your bookings in a usable format at any time, with or without an active subscription?

5. Is there a real backup, and have you seen it restore?

Nearly every vendor says "we have backups." Fewer can show you a restore actually happening. Ask for a live demonstration — back up a test record, delete it, restore it — before you trust a property's entire guest history to the system.

6. Does it print a receipt your guests will accept?

Guests increasingly expect a printed or shareable receipt, and some jurisdictions and corporate guests require one for expense claims. Confirm thermal printer support if you already own one, and check what a digital receipt actually looks like — some "PDF export" features are barely readable on a phone screen.

7. Can you limit who sees what?

Staff turnover in hospitality is high. A config-level PIN or equivalent access control means a new hire can take bookings and record payments without being able to quietly change prices, delete records, or export your entire guest list on their way out.

8. What does the pricing actually depend on?

Per-device, per-property, per-room, per-month, one-time — get the exact model in writing, and ask what happens as you grow: a second branch, a few more rooms, a busier season. Growth-triggered price jumps are common and rarely volunteered up front.

The 15-minute demo script

Instead of letting a vendor run their own prepared demo, ask them to follow this sequence on the actual device you'd buy:

1. Check in a walk-in guest and assign a room.
2. Open a restaurant order for a table, and tag it to that guest's room.
3. Record a partial payment — not the full amount.
4. Generate or print a receipt for what's been paid so far.
5. Turn on airplane mode, then repeat steps 1–4 with a second guest.
6. Reconnect and confirm both guests' records are intact and, if the product syncs anywhere, that they've synced.

If every step works without anyone needing to explain an exception, you've seen the product. If step 5 breaks something, you've also seen the product — just earlier and more cheaply than finding out during your first power cut.

A vendor who's eager to demo everything except step 5 has just told you where the product's limit is.

Red flags

• "It needs internet for the core features, but we're adding offline soon." Soon rarely arrives, and your front desk needs today's answer.
• Separate modules for rooms and restaurant that don't share a bill. You've bought two systems that happen to share a login screen.
• No visible backup or export option in the interface itself. If it's not a button you can press, it's a promise, not a feature.
• Pricing that's "custom" until after the demo. Usually means the number depends on how committed you sound.
• No local-language option, when half your staff would use one. This predicts staff resistance months before it predicts anything in a spec sheet.

What this looks like once it's working

The properties that get the most value out of this kind of software aren't the ones with the fanciest dashboards — they're the ones where the front desk stopped thinking about the software entirely. A booking goes in once. A meal tagged to a room shows up on that room's bill without anyone remembering to add it. A storm knocks out signal for six hours and nobody at the counter notices. That's the actual bar, and it's a fair one to hold any vendor to, including us.