A hotel IT inventory and network map: the two pages that save the night of an outage

A hotel IT inventory is a device list: what each piece of equipment is, where it sits, which port it uses and who looks after it. A network map is a one-page drawing of the lines, router, switches and access points. With a contacts page kept offline, they turn a night-time outage into a short, ordered call.

The front desk calls at 02:40: the card terminal will not connect and the guest Wi-Fi is down on the third floor. Someone asks which switch feeds that floor, and nobody in the building knows. Two pages would have answered it in thirty seconds. After reading this, you will know exactly what goes on those pages, where to keep them, when to update them and how to use them during the fault itself.

Why do two pages beat a long manual?#

Because during an outage you need three facts in under a minute, and a long manual cannot be read at 02:40. The two-page limit forces the writer to keep only what is used under pressure.

Documentation usually fails in one of three ways: it was written once and never updated, it lives on the server that is currently down, or it is so detailed that finding one switch port takes ten minutes. The device list answers what and who. The network map answers where and how it connects. The contacts page answers who to call. Nothing else survives the two-page test.

Write for the person who has never worked in this building: a night auditor, a relief technician, a fire warden. If they cannot follow it, it is not finished. Keep the language operational, not architectural. "Switch B, port 14, third floor corridor" is useful; a diagram of the whole topology is not.

Before writing anything, decide who owns the pages. A document with two owners has none. The same question applies to the wider setup: whether who runs IT at a hotel is an in-house person, an IT company or the software vendors shapes who that owner is.

What to leave out on purpose#

Leave out cable schedules, rack elevations, IP addressing plans and vendor manuals. They belong in the IT company's own documentation, not in the pages you read during a fault. Leave out anything you would have to look up to explain: if the row needs a paragraph of context, it is too detailed. Test the result once: hand both pages to someone who does not know the property and ask them to find the device feeding the third-floor corridor. The time they take is the real quality score.

What goes in a hotel IT inventory?#

One row per device that someone might have to touch during a fault: its name, type, location, network point, address, owner and support cover. A spreadsheet is enough; the discipline is in the columns.

Start with the devices that stop the hotel: the property management system (PMS) terminals, the card terminal, the key card encoder, the switch cabinet, the router, the access points, the door-lock controller, the point-of-sale terminals in restaurant and bar, and the camera recorder. Record the physical location in words a stranger can follow: building, floor, room, cabinet, rack position. "Server room" is not a location if there are two server rooms.

Record the network point: which switch, which port, and whether the address is fixed or handed out automatically. This single column is what turns a guess into a five-minute fix. Record the owner: hotel, IT company, software vendor, internet provider, or the company that installed the cameras. Ownership decides who pays and who answers the phone.

Record the support cover: contract number, end date, response hours. A device out of cover is a decision waiting to be made, and the inventory is where you see it coming. Add a criticality mark, for example a simple high, medium, low, so a reader knows what to fix first when three things fail at once.

The columns that earn their place#

Devices people forget#

The door-lock controller, the camera recorder, the telephone system, the mini-bar or vending controllers, the elevator or boiler monitoring kit, and the backup internet line. None of them is glamorous, and all of them generate a 02:40 call eventually. Never add a password column. Credentials belong in a separate routine with its own rules, not in a document that gets printed and handed around.

What does a one-page network diagram need to show?#

The path from the internet line to the device, at the level of detail a technician needs to isolate a fault. That means lines, router, switches, access points, the names of the separated networks, and the port numbers that connect them.

Draw from the outside in: the incoming line or lines, the router or modem, the firewall if there is one, then the core switch, then the floor switches, then the access points and end devices. Label each incoming line with its provider, its circuit or account reference and its speed. That label is what you read out on the phone when you open a fault ticket.

Show switch port numbers on the connections. "Switch B port 14 to AP-3F-02" is the difference between a ten-minute check and an hour of unplugging cables. Name the separated networks in plain words as well as by their technical label: guest Wi-Fi, office, PMS and payment terminals, cameras, door locks. A reader needs to know which network a device sits on before touching anything.

What to draw and what to summarise#

Sketch wireless coverage roughly per floor, with the access point positions marked. It does not need to be a survey; it needs to show which access point serves which corridor. Keep the whole thing to one page, printed at A3 if the property is large. If it does not fit, the diagram has become a cable schedule and will stop being updated. Use the same shape for the same kind of device throughout, and put a small legend in the corner.

Naming the separated networks#

Give each network a plain name and keep it consistent across the inventory, the diagram and the Wi-Fi settings. If the line itself is the weak point, the diagram is also the starting point for deciding how much internet a hotel needs, sized from rooms, guests and peak hours.

Who do you call when a line goes down?#

The contacts page lists, for each service, the company, the contract or account reference, the support number and the hours it is answered. It is the page that turns a fault into a ticket number.

Cover every dependency, not just the internet: internet provider, IT company, PMS and software vendors, card terminal provider, key card and door-lock supplier, camera installer, telephone operator, and the electrician who knows the server room. For each one record the account or circuit reference, the contract number and its end date, the support hours, and whether support is included or charged per call.

Add the escalation step: the named contact when the first line does not answer, and the internal person who is allowed to approve an emergency call-out. Record who holds each set of credentials and where they are kept, by role rather than by value. The page says "held by the technical manager in the sealed envelope"; it never says what the password is.

Keep the page ordered the way an outage unfolds: line first, then network equipment, then the systems that run on it. Check the numbers twice a year. Providers merge, support lines change, and a dead number is worse than a blank one because it looks like an answer.

Where should you keep the documents?#

In two places at once: a printed copy in a known, sealed place, and a digital copy on a device that does not depend on the hotel network. The printed copy is the one that works when everything else does not.

Choose the physical place deliberately and tell three people: the technical manager, the front office manager and the duty manager. A safe place nobody knows about is a lost document. Keep the digital copy on an offline device or a phone, and treat it as a document that must be readable without a login to the hotel systems.

Mark every version with a date and a version number on the page itself, so a reader can tell instantly whether they are holding the current one. Keep guest data out of both copies: the inventory names devices and suppliers, never guests, and personal data has its own rules under KVKK (kişisel verilerin korunması kanunu). Decide who may read the pages. They describe how the building is wired, so the circle should be wider than one person and narrower than the whole staff.

When do you update them?#

After every change, at the moment of the change, by the person who made it. A monthly review then catches whatever slipped through.

Name the triggers that always require an edit: a new access point, a device moved to another port, a new line or a provider change, a replaced switch, a new terminal, a contract renewal, a change of support company. Make the edit part of the job, not a separate task. The technician who installs the access point writes the row before leaving the building.

The change triggers#

Keep a short change log on the last page: date, what changed, who changed it. It answers the question "when did this start?" during the next fault. Run a ten-minute monthly check: read the pages against the cabinet and the contract dates, and correct what has drifted. Review the contacts page whenever a person leaves or a supplier changes, because access and ownership move at the same time as people do, as covered in the routine for closing a leaver's access on the same day. Give one person the final word on the document. Shared editing without an owner produces two versions and no truth.

How do you use the map during an outage?#

In a fixed order: establish the scope, find the affected devices on the diagram, check the port and the line, then call with the reference in hand. The pages turn a panic into a sequence.

First establish the scope with one question: is it one room, one floor, one building or everything? The answer points to a device, a switch, a line or a supplier. Find the affected devices in the inventory, read their switch and port, and check whether anything else on the same switch is also failing.

Work outward along the diagram from the device to the line, not inward from the internet. It stops you from restarting the router for a fault that sits in one access point. Call the provider or vendor with the circuit or contract reference from the contacts page, and write down the ticket number and the time.

Record what you did and what you found on the change log page while it is fresh, then correct the inventory and the diagram before the next shift. Keep the backup question separate: restoring data is a different procedure from restoring connectivity, and it needs its own written test, as covered in the guide to backups for hotel systems.

What to do next#

Block one working day this week, open a spreadsheet and a drawing tool, and fill in what you already know; mark the gaps in red rather than guessing. Print both pages, add the contacts page, seal them, and hand them to one person who has never worked in the building to test. The two pages are not a project, they are a habit: the value comes from the version dated after the last change, not from the first one.