How much internet does a hotel need? Sizing bandwidth from rooms, guests and peak hours

Size hotel bandwidth from your own peak, not from a per-room rule: rooms × guests per room × occupancy at the evening peak × the share online, multiplied by what each device does, plus staff systems, cameras and headroom. Bandwidth is capacity in megabits per second; coverage is a separate problem.

A guest complains that the internet is slow, so the hotel buys a bigger package. The complaint returns the following weekend, from the same corridor, because the problem was never the size of the line. This guide gives you a way to tell the difference before you spend money: a diagnosis order for complaints, a sizing method built from your own numbers, and a test routine for after installation.

Is your hotel's internet slow, or is it a coverage problem?#

Usually it is coverage: a guest in a far room with a weak signal cannot use the megabits the hotel already pays for. Three ideas get mixed together in every complaint, and separating them is the first step. Speed is how many megabits per second the line delivers. Capacity is how much total traffic the line can carry at once. Coverage is whether the radio signal from an access point reaches the guest's device at a usable strength.

Complaints arrive in the same words, "the internet is slow", whether the cause is a saturated line, a badly placed access point, or a device stuck on a distant access point. The words cannot tell you which it is. The location and the hour can.

There is also a middle case that behaves like both. A device with a weak signal re-transmits constantly, so a handful of badly covered guests can consume the shared airtime of a whole floor and make everyone nearby feel slow. The line itself may be half empty while the floor still complains. If you want the vocabulary for this, read hotel network and Wi-Fi terms explained, from access point to VLAN.

Read the result plainly. If the line sits at 95% at 21:00, you have a capacity problem. If the line sits at 30% and the guest has one bar, you have a coverage problem. Fix coverage first, because it is cheaper than a bigger line, and a bigger line will not fix it.

Why does the evening peak matter more than the average?#

Because a line is sized for its busiest hour, not its daily average, and in a hotel the busiest hour is usually the evening. Hotel traffic has a shape: low overnight and mid-morning, moderate in the afternoon, then a sharp rise as guests return to their rooms between roughly 20:00 and 23:00, with a second, smaller administrative peak around check-out. The evening rise is the one that generates complaints.

A line running at 30% average utilization can be completely saturated for three hours every evening. The average hides exactly the hours that matter. When a line saturates, the package speed on the contract does not change, but queues build, latency rises and video calls stutter. Guests read that as slow internet even though the line is delivering its full rate. For calls, video meetings and card terminals, latency and jitter matter as much as raw megabits; a full line adds delay before it adds packet loss.

Concurrency is the number that matters: not every guest is online at the same moment. The share online at peak is a property of your property type, so a resort, a city business hotel and a hostel will produce different figures. Measure rather than guess. Your router or firewall usually keeps a traffic graph.

How do you calculate hotel bandwidth from your own numbers?#

Multiply the devices online at the evening peak by what each of them is doing, then add staff systems, cameras and headroom. The result is a target to test against, not a guarantee.

Start with the concurrency formula: rooms × average guests per room × occupancy at peak × the share of guests online at peak = devices online at peak. Count devices, not people. Many guests carry a phone and a laptop, and some carry a tablet as well.

Then classify what those devices are doing, because the appetites differ by an order of magnitude. Messaging and email are tiny. Browsing and social media are small. Streaming video is large. A video call is moderate but demands steady upload and low latency.

All rates in the table are illustrative and must be replaced with local measurement.

Add the load that is not guests: staff computers, the cloud property management system, point-of-sale terminals, back-office backups, and IP cameras that upload continuously day and night. Then add headroom above the peak, so the line is not permanently at its ceiling. A common working figure is a third to a half above the measured peak, and it is a judgment call, not a rule.

Remember that the advertised package speed is a maximum, not a floor. What arrives at 21:00 on a Saturday is the number your guests experience.

For example, an illustrative 120-room property: 120 rooms × 1.8 guests × 85% occupancy at peak × 60% online gives about 110 devices online. If 40% of them stream video, 40% browse, 10% are on video calls and 10% are messaging, the guest load lands somewhere near 280 megabits down and 35 up. Add 40 megabits for staff systems and cameras, then headroom, and the target is roughly 450 down and 80 up. Every per-activity rate in that example is illustrative, not a standard and not a survey result. Substitute your own observations, and treat the output as a target to verify with a test, not as a specification.

Why does upload speed matter as much as download?#

Because the things that fail most visibly, video calls, camera streams, card payments and cloud system syncs, all travel upstream. Consumer and many small-business packages are asymmetric: far more download than upload. Hotels often buy on the download number alone and then discover the upload side is the constraint.

A video call needs capacity in both directions and low latency. A line with a large download and a small upload will pass a download test and still fail every business guest who joins a meeting. Cameras are a permanent upload load: they stream continuously, they do not pause at the evening peak, and their count tends to grow quietly over the years.

Cloud systems sync upstream too: report uploads, backups and end-of-day jobs. Schedule the heavy ones outside the peak rather than competing with guests. Guests upload as well; phone photo backups and social posting cluster in exactly the evening hours when the line is already busy.

Should staff systems, payments and cameras share the guest line?#

No. Separate them logically at minimum and physically where you can, so a guest streaming peak cannot starve the front desk. The failure mode is specific: guest traffic fills the line, the card terminal times out during check-in, the cloud property management system stops loading, and the front desk is blind at the worst moment.

Logical separation means separate wireless networks and separate network segments on the same physical line. It gives you priority rules and privacy, but not extra capacity; the same pipe is still shared. Physical separation means a second line dedicated to staff, payments and devices. It gives capacity and a fallback: if the guest line fails, the hotel keeps operating. The design questions are covered in more detail in separating guests, staff, payments and devices on the hotel network.

Two rules hold in either design. Keep card terminals and payment traffic on the staff side, never on the guest network, for both priority and privacy reasons. Give cameras their own budget on the staff side, because they are constant, predictable and easy to forget when the line is sized. Write the design down, with a simple diagram, so the next technician does not merge everything back into one flat network during a quiet afternoon.

Is a second line better than a faster one?#

Often yes: two moderate lines give capacity, a fallback and a clean way to keep the front desk working when one of them fails. One faster line gives more capacity on a single pipe, one contract and one point of failure. When it fails, everything fails at once. A second line gives capacity plus redundancy, and it lets you split guest and staff traffic physically rather than only logically.

Compare the options on peak capacity, upload capacity and behaviour when something breaks, not on the headline download number. Failover can be automatic through a router that switches when the primary drops, or manual with a documented procedure at the front desk. Either way, test it on a quiet morning rather than discovering it during an outage; the front desk side of that is covered in the checklist for when the internet goes down.

Where possible, take the two lines over different physical paths. Two lines entering the building through the same duct fail together when that duct is cut. One large line remains the right answer for small properties, or where a second physical entry into the building is genuinely impossible.

How do you test the internet after installation?#

Test where the guest sits, at the peak hour, with the tools a guest would use, and write the numbers down. Test in layers: at the incoming line first, to see what the provider actually delivers; then at an access point; then in a guest room at the far end of a corridor. A test on an empty afternoon proves nothing about the hour that generates complaints, so test at 21:00, not at 11:00.

Test upload as well as download, and record latency and jitter, because calls and terminals fail on delay before they fail on capacity. Test with several devices connected at once: a single-device test measures the line, not the hotel. Walk the building and repeat the test in the worst rooms on each floor, since coverage problems are local and invisible from the lobby. For the complaint side of this, see the front desk troubleshooting checklist for guest Wi-Fi complaints.

Keep the results as a baseline, so a future complaint can be compared with a known-good measurement instead of argued about. Repeat the test after any change: a new access point, a new line, a new camera, or a new floor of rooms.

What to do next#

Before renewing or upgrading the contract, do two things in the same week: export a week of line utilization and keep the busiest evening hour, and walk the worst rooms on each floor with a signal and speed test. Those two records tell you whether you are buying capacity you need or paying for megabits that a badly covered corridor cannot use, and they give you a baseline to compare against the next complaint.