Technology for glamping and bungalow sites: weak internet, power and bookings

Glamping booking software is a light reservation system that keeps one calendar for every tent, bungalow and pitch, takes bookings from the channels you sell on, and records the guest, the payment and the bill in one place. On a remote site it must run from a phone over a weak connection and survive a power cut.

A guest books a bungalow from the road, arrives at dusk, and the owner's phone shows one bar. The booking is real, the payment is real, and the guest identity notification still has to be sent. Remote sites get no exemption from the steps a hotel follows, only a harder place to do them. This article walks through the lean setup: what the software must do, how to get a connection to a site far from fiber, how to run check-in without a reception desk, and what to keep alive when the power fails.

What is different about a glamping or bungalow site?#

The steps are the same as in a hotel; the conditions are not. Units are separate buildings, staff are few, the connection is weak and the power may come from panels.

Each bungalow, tent or caravan pitch is its own building, so connectivity, locks and lighting are per-unit problems, not one lobby problem. The person who checks the guest in may also cook, clean and drive the shuttle, so any system has to be usable by whoever is on shift, on a phone, without training days. Bookings arrive from the site's own website, travel agencies and the large booking sites at the same time, and each of them can sell the same unit.

The legal steps do not shrink with the size of the site. In Türkiye every stay involves a payment, a fiscal document (an invoice or e-document), a guest identity notification (KBS) and personal data (KVKK). Many sites also close for the low season and reopen with new staff, so the setup must be simple enough to restart without a technician on site. Power is shared with pumps, fridges and lighting, which changes what you can keep running when the supply fails.

If you are weighing how much technology a property of your size really needs, the same logic applies across the scale, see hotel technology by size: what 10, 40, 120 and 300 rooms really need.

What should glamping booking software actually do?#

It should hold one calendar for every unit, take bookings from every channel you sell on, and keep the guest, the payment and the bill in the same record.

One inventory comes first. A tent, a bungalow and a caravan pitch are different products with different prices, minimum stays and seasons, but they must sit in a single calendar that shows what is free. Channel connections come second: a channel manager sends availability and rates to the booking sites and brings reservations back, while a linked calendar only copies a block of dates and can arrive late, which is exactly how a unit gets sold twice. The difference between the two is explained in calendar sync (iCal) or a channel manager.

Fewer channels done properly beat many half-configured ones. A site with clean photos, correct unit types and honest rules converts better than one listed everywhere, and if you are just starting to sell online, which channels to open first for a small property is the order that matters.

Then test the phone. Check that the calendar and the check-in screen work one-handed, in daylight, on a mid-range phone, not on a laptop in the office. Ask what the system loads before it shows the calendar, and test it on site at the hour when everyone is online. Some things can wait offline: noting a guest and handing over a key can happen locally. A card payment cannot, because the terminal needs authorization from its provider, so keep cash or a terminal on mobile data as the fallback. Promising a unit to a booking site also needs the connection, so availability cannot be handled locally. Finally, leave out what you will not use in low season; every unused feature is training time you pay for twice.

Questions to ask before you sign#

How do you get internet to a site far from fiber?#

Usually with a radio link to a nearby point that has fiber, or with a mobile router placed where the signal is strongest. Cabling a whole site is rarely the cheapest answer.

A radio (point-to-point) link uses a small antenna on a mast aimed at a partner point with a clear line of sight. It needs a mast, a clear view and someone local who can align it and come back when a storm moves it. A mobile router belongs where the signal is best, not where the office is; a short mast and a directional antenna often beat a phone lying on a table.

Before agreeing to anything, ask for measured download and upload at the office and at the furthest unit, at the busiest hour, plus the latency and what happens in heavy rain. Ask who fixes it and how fast, in writing; a link that takes four days to repair is a four-day outage in high season. If bookings depend on the connection, a second path on a different mobile network is cheaper than a lost weekend.

Test with the real system. A speed figure on a phone tells you less than opening the booking calendar and saving a test booking from the furthest unit. When the link does fail at the front desk, when the internet goes down: a front desk checklist gives the steps that keep arrivals moving.

Should the office, the units and the guests share one network?#

No. Keep at least two: one for the office and the booking device, one for guests, so that a guest streaming a film cannot stop a check-in.

The office network carries the router, the booking device and the card terminal; it is the one that must stay usable when the site is full. The guest network gets its own name and password, changed between seasons, and must not reach the office devices or the booking system. Plan the cable route to the units before the season: where the cable runs, where each small access point sits, and who can reach it without entering an occupied unit.

Limit the guest network so the office keeps a working share of the bandwidth, and move backups and updates to the quiet hours. Walk the site with a phone and mark where calls drop and where the guest network fades; that map serves staff and guests alike. Keep a paper fallback: a printed arrival list and a card terminal that works on its own mobile connection.

How does check-in work without a reception desk?#

The same three things happen, identity, payment and the key; they just happen where the guest is, and the record must be saved before the guest walks to the unit.

Identity first. The KBS notification (guest identity notification) is prepared from the check-in flow, so the document is read and the notification sent while the guest is still there; how that works in practice is covered in how KBS notification works: the web screen or your hotel software. Payment comes before or at arrival, and you should check whether the card terminal can work on mobile data; a terminal that needs the office network turns every arrival into a walk.

Keys are a per-unit decision. Mechanical keys on a tagged board are honest and cheap; a keypad or card lock removes the walk to open a door but adds batteries and a new failure mode. For late arrivals, send the unit number and a code in advance, and leave a number the guest can call if the code does not work. Whatever happens at the door must end in the same calendar and the same bill; a charge written on paper and never entered is money lost quietly. When two staff are on, agree who does what: one confirms the payment, one hands over the key, and both see the same booking.

What must stay on when the power fails?#

The router, the booking device, the card terminal and one light per unit. Everything else can wait until the supply returns.

Draw the load before buying anything: list what runs on backup and add up the watts, including the fridge if it holds food for guests. On a solar site the panels charge by day, so heavy loads such as pumps, washing and air conditioning belong in daylight, while the router and the booking phone sit on the battery circuit. A small uninterruptible supply on the router buys the minutes needed to save a booking and send a notification; check what it actually powers before you trust it.

A generator should be started before guests arrive, not after, and fuel, torch and the start procedure should be somewhere staff can find them in the dark. Write the failure plan on one page: printed arrival list, charged power bank, a phone already logged in to the booking system, and a number for the guest to call. Then test it once before the season by switching the mains off and watching what stops.

What should you tell guests about the signal before they book?#

Tell them what the signal is like where they will sleep and what it is good for, before they pay. A stated limit is a promise you can keep; a surprise is a complaint.

Put it on the booking page and in the confirmation: where the signal works, where it does not, and whether calls over the internet are reliable. Be specific about the guest network: messages and maps yes, streaming in the evening probably not, and say which areas are covered. Offer the alternative: a landline number, a meeting point, and the hours when someone is at the office.

Give whoever meets the guest the same sentence to say, so the answer does not change with the shift. Guests forgive a weak signal they were warned about and rarely forgive one they were not, so the sentence protects the review as much as the stay. Update the wording when you add an access point or a mast, and when the coverage map changes.

What to do next#

Walk the site with a phone, write down where the signal holds and where it fails, then test one booking system on that weakest spot before the season starts. One calendar for all units, a network split between office and guests, a short backup plan and one honest sentence to guests are the whole setup; each of them is cheap now and expensive to add in July.