A hotel IT budget: from a list of devices and licences to a five-year plan

A hotel IT budget starts with one register: every device, licence, subscription and contract, with its renewal or end-of-life date and a named owner. Sort that register by date, split it into running costs and replacement costs, and spread replacements across a five-year calendar that lands in the closed months.

The firewall licence renews in June. The server that runs the property management system is seven years old. Neither appears in the budget, because neither line is called IT. This is the normal state of a hotel IT budget, and it is fixable without a consultant. After reading this you will be able to build one register, split it into running and replacement costs, spread replacements over five years, and take the whole file into the wider budget cycle.

Where do hotel IT costs hide in the budget?#

IT costs hide in five or six lines that are not labelled IT, which is why the first budget draft always looks cheaper than the year turns out to be. A hotel IT budget that starts from the accounting system will therefore always be incomplete. You have to go looking.

The repairs and maintenance line absorbs the failed switch, the dying disk and the emergency call-out. It is the most common hiding place for hardware, because a repair is booked the day it happens and nobody converts it into a replacement plan afterwards. Software subscriptions sit under administration, sales or front office, depending on who signed the contract, so the same vendor can appear three times under three headings. Telecom and internet carry the main line, a backup line and a mobile data plan for the reception tablet, and each renews on its own date.

Capital requests arrive as one-off purchases with no context, so nobody can see that three of them belong to the same five-year cycle. Petty cash and the general manager's card cover cables, printer toner, a card encoder ribbon, and a licence bought late at night on a personal card. The result is that the hotel cannot answer what IT costs per year without a week of work, so it budgets a round number and hopes the year is kind.

The wider budget cycle is described in the guide to building next year's hotel budget month by month; this article builds the IT part that fits inside it.

What goes in a hotel IT asset register?#

One row per thing the hotel depends on, with the same fields every time: what it is, where it is, who owns it, what it costs, when it renews or reaches end of life, and what stops if it fails. Nothing more is needed to start, and nothing less will work.

Five categories cover almost everything: devices, licences, subscriptions, contracts, and the items nobody has claimed yet, such as the Wi-Fi in the staff canteen. The renewal date is the field that earns the register its keep; without it you have an inventory, not a planning tool. The owner is a named person, never a department, because an unowned line is the one that quietly lapses.

Record the contract end date and the notice period separately from the renewal date. A contract that auto-renews on 60 days' notice is a decision with a deadline, and that deadline is earlier than the renewal date. Keep the register in a spreadsheet the financial controller can open, not in a tool only one person can log into, and save a dated copy each quarter. That is enough to show what changed and who changed it.

Add a criticality note in plain words, such as "front desk stops" or "guests notice nothing", because that note drives the replacement year later on.

For the software side of the register, the guide to how hotel software is priced lists the licence and subscription models worth capturing.

Which IT costs are running and which are replacement?#

Running costs repeat every year and are approved once; replacement costs land in one specific year and need their own decision. Sharing a line between them is how replacements get postponed. When the two sit together, the running costs renew on schedule and the replacement is deferred, because deferring it saves money this year and costs nothing visible until the item fails.

The running list holds subscriptions, annually renewed licences, internet and backup lines, support contracts and consumables. The replacement list holds servers, reception PCs at end of life, switches, access points, card encoders, printers, and the software version that needs a newer database underneath it. A subscription priced per room, per user or per channel is a running cost with a trend, so record the unit and the count, not only the total.

Estimate replacements at today's price and mark the figure as an estimate. Do not index it silently, and do not pretend today's price holds in five years; an honest estimate with a label is more useful than a precise number nobody believes.

The test for which list: if stopping it for a year breaks the hotel, it is running; if the hotel survives the year but the item fails later, it is replacement. The controller needs two totals, the yearly running total and the replacement total per year, because the owner approves them differently.

How long does each item last, and how do you build a five-year calendar?#

Give every item in the register a replacement year, then read the years down the page: the calendar is simply the register sorted by that column. No separate tool, no separate truth.

Lifespans are the hotel's own assumptions, not industry norms. Write them down and label them as assumptions so nobody mistakes them for a standard. For example, a hotel might assume five years for a reception PC, seven for a server, a five-year licence cycle for the firewall, and ten years for cabling. These are illustrative, not recommendations; your climate, usage and vendor terms may argue for different numbers.

Spread the load. If four items land in the same year, move the least urgent one a year later and write the reason in the notes column. Add a contingency line for the item that fails early; the calendar plans the expected, the contingency covers the rest. Review the calendar once a year against what actually failed, because the gap between plan and reality is the most useful number in the file. Keep the calendar in the same file as the register so the two cannot drift apart between reviews.

Illustrative example only; the years are the hotel's assumptions, not industry norms.

When in the year should a hotel replace IT equipment?#

In the weeks when the hotel is empty or quiet: the closed months for a seasonal property, the low-occupancy weeks for a city hotel, never the shoulder season. Timing is a budget decision as much as a technical one.

Replacement carries a cost beyond the part. The front desk stops, the card encoder is offline, the channel connection is broken, and that cost is highest at full occupancy. Work backwards from the season: order in the closed month, install before pre-season training, and keep the old device as a spare for two weeks. Some items can be swapped mid-season without a guest noticing, such as a back-office PC; some cannot, such as the PMS server or the network core, and those belong firmly in the quiet weeks.

Align the calendar with the season opening and closing checklists, so one trip covers both the maintenance and the replacement. The IT checklist for season opening and closing shows where the two lists meet. Budget the installation labour and the downtime, not only the hardware; the quiet afternoon still costs wages.

Who signs off on IT spending?#

Three roles: the financial controller builds the numbers, the general manager signs the running costs, and the owner approves anything that lands in the replacement calendar. Making this explicit is what turns the register into a budget.

Write the approval thresholds into the budget document itself, so a June emergency is a procedure rather than a negotiation. Decide in advance who may authorise an emergency purchase and up to what amount, and require the receipt to be added to the register the same week. The person who runs IT day to day should not be the only person who understands the register; if they leave, the calendar leaves with them, and the file has to survive them.

The case for spending before failure is simple. A planned replacement costs a purchase order and a quiet afternoon. An unplanned one costs the same purchase order, an afternoon you did not choose, and whatever the front desk improvised in between. Present the calendar to the owner as a five-year total and a per-year figure, not as a single request, so each year's number is visible before it arrives. How the day-to-day IT work itself is staffed is a separate question, covered in who runs IT at a hotel.

What does the template look like, line by line?#

One file, four sheets: the register, the running costs, the replacement list and the five-year calendar, all reading from the same rows. If the four sheets disagree, one of them was edited by hand, and that is the row to check first.

Sheet one is the register: the columns from the second section, one row per item, nothing else. Sheet two is running costs: filter the register to recurring items, total by category, and show unit and count for anything priced per room or per user. Sheet three is replacement: filter to items with a replacement year, one row per year, with an estimate and the assumption behind it. Sheet four is the calendar: the five-year view, with the assumptions printed at the top of the sheet where a reader cannot miss them.

Add a decision-by column, calculated as renewal date minus notice period, so every renewal has a date attached to it. Keep a short notes column explaining why this item and why this year. Six months later it is the only thing that explains the number.

What to do next#

Open a spreadsheet this week and list the ten items the hotel would stop without. That is the first version of the register, and everything else here, the split into running and replacement, the five-year calendar and the approval route, is built on those rows. Take the finished file into the wider budget cycle described in the month-by-month hotel budget plan.