Who runs IT at a hotel: an in-house person, an IT company or the software vendors?

Most independent hotels should split the job rather than hand it to one party. Hotel IT outsourcing means buying the technical work from a company under a written contract, while one named staff member keeps the decisions, the accounts and the vendor tickets. Software vendors cover only their own product, and stop at its boundary.

The property management system stops responding at 23:40 on a Saturday in August. Reception calls the front office manager, who calls the IT company, which says the network is fine and the software vendor should look. Nobody is wrong, and nobody is fixing it. This article maps the IT work a hotel actually has, compares the three ways of covering it, and gives you a responsibility table you can fill in with real names before the season starts.

What IT jobs does a hotel actually have?#

Seven jobs, whether or not anyone is named for them: accounts and access, backups, the network, the devices, vendor tickets, out-of-hours incidents, and the records the law expects you to keep.

Accounts and access come first. Someone creates a login for a new receptionist, and someone removes it on their last working day. A shared login, used by the whole desk, destroys the record of who did what, and that record is exactly what you need when a charge is disputed or a rate is changed by mistake.

Backups are second, and the question is not whether they run but whether anyone has restored one. A backup nobody has restored is a hope, not a control. What is copied, where the copy sits, and who has done a restore once, are three separate answers, and the third is the one that matters. We cover this in detail in Backups for hotel systems: what to copy, where to keep it and how to test it.

The network and internet come next: the router, the guest Wi-Fi, the separate path the front desk and card payments should use, and the cabling nobody looks at until it fails. Then the devices: front desk computers, printers, key card encoders, restaurant point-of-sale terminals, the tablet housekeeping carries between rooms. Each one can stop the day.

Vendor tickets are a job of their own. The property management system, the channel manager, the booking engine, the accounting program, the door locks: each has a support desk, and someone has to open the ticket, describe the fault in the vendor's terms and stay with it until it closes. Out-of-hours incidents are the last technical job: the night audit fails at 02:00 and the business day cannot be closed, and someone must be reachable and allowed to act.

Finally there are the records and duties around guest data: requests from guests, retention periods, and who inside the hotel and outside it may see guest data. Describe the duty in general terms for your jurisdiction and confirm your own case with a legal adviser.

The point of the list is that the job exists before anyone is hired or contracted. The only real question is who does it.

Model 1: an in-house IT person: what it buys and what it costs#

It buys presence and context, and it costs a fixed monthly outlay that exists in January as well as August, plus a second person to cover absence.

An in-house person knows the building, the cabling, the staff and the quirks of each device. They can fix small things in minutes instead of days, because they have seen the printer jam before and know which wall socket the router depends on. That context is real value and it is hard to buy from outside.

The cost side is equally real. A permanent salary line exists in the quiet months as well as the busy ones, and in a small property there is rarely enough IT work for a full week. The role absorbs other duties, and IT quietly becomes someone's second job. Then comes the single point of failure: holidays, illness and resignation. When the person leaves, the network map, the account list and the vendor contacts usually leave with them.

Coverage arithmetic matters too. One person cannot be on call seven nights a week for a whole season without a rota that someone else has to run. Documentation is the condition of the model: the hotel must keep its own record of accounts, network layout and vendor contacts, or the value is not the hotel's.

The model makes sense for a large property with many outlets and devices, or a group running several buildings from one technical team. The decision rule is simple: count the devices and the outlets. If the person is also the front office manager, IT is nobody's first job.

Model 2: an IT company on contract: what it buys and where it fails#

It buys breadth and a team instead of one person, and it fails when the contract names working hours instead of outcomes.

This is the core of hotel IT outsourcing: the technical work, bought from a company under a written contract. What it buys is range: network, devices, security and sometimes hosting support, from a team that can escalate internally when one engineer is stuck. A team also covers holidays, which a single person cannot.

The hours trap is the first failure mode. Remote support during business hours is not the same as someone on site at 23:00, and the gap between the two is exactly when hotels break. Read the contract for the hours, not the promise. The second failure mode is the seam: the IT company supports the network, the property management system vendor says the fault is the network, and the hotel sits in the middle holding two tickets. Ask a candidate company directly who diagnoses a fault that sits between two systems.

The third failure mode is knowledge staying outside. If the company holds the passwords, the network map and the administrator accounts, the hotel may own nothing on the day the relationship ends. High season adds a fourth: the same company serves many clients, and August queues are longer than February queues. Ask what changes in the months that matter.

Before signing, check four things: a named engineer, an on-site response commitment, high-season cover, and who holds administrative rights. And keep two clocks separate in your head: response time and resolution time. A reply in fifteen minutes that ends with "we will look tomorrow" is a response, not a resolution. We explain these terms in Support and uptime terms in hotel software contracts: SLA, response time, RTO and RPO.

Model 3: relying on the software vendors#

Each vendor supports its own product and stops at its boundary, and most failures live in the space between two products that nobody owns.

Vendors do their own part well: their own configuration, their own updates, their own known errors, usually through a support desk that knows the product deeply. For a fault inside one product, the vendor is the right call and often the fastest one.

The boundary is the problem. The property management system vendor does not own your internet connection, your printer driver, your shared login, or the export into your accounting program. Typical seam failures look like this: a rate that does not reach the channel manager, a bill that does not reach the accounting program, a key card encoder that stops talking to the front desk system. Each vendor checks its own side, reports it healthy, and closes the ticket.

Six vendors also means six clocks: different support hours, different channels, different languages, and different definitions of what counts as urgent. Nobody owns the whole picture, so nobody can say whether the fault is the network, the device or the software.

This model is not wrong, it is incomplete. It works when one person inside the hotel coordinates the tickets and can describe the fault in each vendor's language, so each support desk gets a precise question instead of "it does not work".

Who answers at 23:00 in August?#

Whoever is named in writing, reachable on a number that is actually answered, and allowed to act without asking permission first.

Start by separating answering from acting. The night receptionist can restart a router and switch to the backup device, but cannot restore a database or reissue a certificate. Build a triage ladder: what the night team may do alone, what waits for the morning, and what wakes the owner. Write it once and keep it at the desk.

The night audit is the pressure point, because it closes the business day. If it fails at 02:00, the next morning starts with the previous day still open, and the front desk has to reconcile two days at once. High season multiplies these incidents: more guests on the Wi-Fi, more devices in use, more seasonal staff who do not know the workarounds.

The rota is a management document: names, numbers, the order of calls, and what each person is permitted to decide at each step. Test it once in low season. Unplug something on a quiet Tuesday and see who answers, how long it takes, and whether they knew they were on the list. And when the internet itself is the failure, the front desk needs a paper procedure that does not depend on any system being reachable; see When the internet goes down: a front desk checklist for cloud-based hotels.

A responsibility table: job, owner, backup, contract#

Fill one row per job with a name, a second name and the document where the duty is written, because a blank row is an unowned risk.

Two names per row: the owner does the work, the backup does it when the owner is on leave, ill or unreachable. The third column matters most, because a duty that exists only in someone's head disappears the day that person leaves the building. Start from the seven jobs above, then add every vendor and every system, and mark honestly which rows are written nowhere.

The table is a management document, not a technical one. The general manager signs it and reviews it at season opening and after any staff change. Keep it short enough to be read in one sitting: a twelve-row table that people use beats a forty-row register that nobody opens. Where a row is owned by a supplier, write the contract name and the clause, not just the company name.

What should be written into an IT company contract?#

Scope in your words, hours, response and resolution times, on-site rules, who holds the passwords, and how the relationship ends.

Describe the scope as the hotel sees it: which devices, which network, which software is inside the contract, and which is explicitly outside. Then set two clocks, not one: a response time and a resolution target, each with the hours it applies to and what happens outside them. Add a high-season clause: what cover applies in the months that matter, and what the queue looks like when several clients call at once.

Administrative rights stay with the hotel. The company works inside accounts the hotel owns, and hands over credentials on request. Data protection comes next: the company will touch guest data, so the contract must say what it may access, who may access it and what happens afterwards. Confirm the wording with a legal adviser familiar with your jurisdiction.

Exit terms are the clause nobody reads until they need it: handover of the network map, the account list and the documentation within a stated period, whether the parting is friendly or not. Finally, cover price review and change: how a new device or a new building is added, so scope does not drift silently in either direction. For the wider contract terms around hotel software, see Hotel software contracts: clauses to read before you sign.

What to do next#

Fill in the responsibility table this week, with real names in the owner and backup columns, and take the rows marked "nowhere" into your next contract conversation. The three models are not rivals: an IT company does the technical work, your staff own the decisions and the tickets, and the vendors stay inside their own products. What makes the arrangement work is that every job has a name against it before the season starts.