Technology timeline for a new hotel: what to choose and install, and when

A hotel pre opening technology checklist works backwards from opening day. Decide cabling, room numbering and the internet line about twelve months out; choose the property management system (PMS), locks and point of sale together nine to six months out; configure codes and interfaces three months out; train and rehearse in the final four weeks. Month marks are an example, not a rule.

The locks are already in the doors when someone finally asks which property management system the hotel will run. The answer arrives months late, and the link between the two systems is now a project of its own, with its own cost and its own delay. This guide gives you the working order: what must be decided while the walls are open, which systems are chosen as one set, how codes and interfaces are configured, when rooms can go on sale, and what the final rehearsal week actually tests. It belongs beside the wider month-by-month pre-opening plan for a new property, where technology is one line among many.

Why does the order of technology decisions matter more than the brands?#

Because each choice consumes the one before it: a system can only be configured from decisions that already exist, and a decision taken late forces work that would have been free earlier.

Work backwards from opening day, not forwards from the contract signature. Ask of every item: what must already be true for this to be installed, and what breaks if it arrives late. This single question turns a shopping list into a schedule.

Separate the decision date from the installation date. The room-numbering scheme is decided early and costs nothing; the locks that read it are installed late and cost a lot. Configuration sits between the two, and it is where most of the calendar actually goes.

Name the long-lead items first: cabling inside walls, the internet line and its backup, door locks with their key-card encoder, and the room list itself. These depend on the building, not on the software, so they cannot be accelerated by anyone in the project team.

A wrong order produces a retrofit, not a mistake you can undo. A PMS bought after the locks means an interface negotiated under time pressure; a channel opened before rates exist publishes prices nobody checked. Give one person the decision: a pre-opening team with three people choosing software produces three half-decisions that the configuration team has to reconcile later. And write each decision down with its date and its reason, so that when a supplier changes or a manager leaves, the next step is not re-litigated from memory.

The dependency chain in one table#

The months are an example of a sequence, not a standard. A smaller property compresses them; a large one stretches them. What must not change is the order of the dependencies.

Twelve months out: what has to be decided while the walls are still open?#

Cabling, outlet positions, room numbering and the internet line: the four things that become expensive or impossible once the building is finished.

Cabling is one of the few decisions that get dramatically more expensive later. Conduit and outlets at reception, in the back office, at each floor's housekeeping point, in the restaurant, the bar and the spa cost little during construction and a great deal after the plaster.

Plan three networks, not one: guest Wi-Fi, staff devices, and the equipment that must always be reachable, such as locks, point-of-sale terminals and printers. Separating them at design costs a switch; separating them afterwards costs a weekend of downtime.

Order the internet line early. Physical installation depends on the building being ready and on the provider's own schedule, and a backup line on a different medium is a design decision, not an emergency purchase. Ask the provider in writing what the connection requires: a fixed address for systems that must be reachable from outside, a contract term, a lead time. Do not assume; ask, and keep the answer.

Decide the room-numbering scheme now. Locks, the PMS, telephones, signage and the fire plan all read the same numbers, and changing them after the locks are encoded means re-encoding every door. Finally, plan power for the front desk and the network cabinet: what runs when the power fails, for how long, and who is told when it does.

Nine to six months out: why should the PMS, the locks and the point of sale be chosen together?#

Because they all write to the same guest bill and the same room list, and a system chosen alone has to be joined to the others after the fact.

The PMS is the record: reservations, rooms, the guest bill, the night audit that closes the business day. Locks, point of sale, payment and invoicing all have to agree with that record, so they are one decision, not four. A hotel operating system that already holds reservations, billing and compliance in one place removes some of these joins; a set of separate systems has to build each one.

Ask each supplier what it connects to today and by what method: a live interface, a scheduled file, or a person retyping. The word "connects" without a named method is not an answer. Get the interface list in writing, with who supplies it, who pays for it and who tests it. Interfaces that nobody owns are the ones that fail on opening week.

Ask what leaves with you. Reservations, guest records and folios should be exportable in a readable format, and the contract should say so before you sign, not after. Check the contract's edges: notice period, what support hours include, what counts as a change request, and what happens to your data at the end.

Compliance is part of the choice, not an afterthought. 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). Confirm with your accountant and your legal adviser which duties apply to your property and from which date; do not take a supplier's word as the legal position.

What to ask before signing#

Three questions cover most of the risk. What does your system connect to, by what method, and who owns that connection? What can we export, in what format, and does the contract say so? And what exactly do the support hours cover, and what counts as urgent? A supplier who answers these in writing has done it before.

Three months out: in what order are room types, rate codes and interfaces set up?#

Room types first, then rooms, then rate codes, then revenue codes, then users and roles, and only then the interfaces, because every interface and every report reads the codes created in the earlier steps.

The order inside the setup is not cosmetic. A rate code points at a room type; a revenue code decides which line of the report a charge lands on; a channel mapping points at both. Renaming a code after the mapping exists breaks the mapping silently, and the breakage appears as a missing rate or a charge on the wrong report line weeks later.

Name codes so that a stranger can read them. An abbreviation that only the person who created it understands becomes a training problem and a reporting error six months later. The full setup sequence, with the codes and their order, is covered in the guide to setting up a new PMS: room types, rate codes, revenue codes and users in the right order.

Test each interface with a real transaction, not a screenshot of a settings page: a booking that arrives, a charge that posts to the right revenue code, a lock that opens for the right room. Decide who signs off each interface; a test that nobody formally accepts is a test that gets repeated during opening week. If the property is a takeover or a rebrand, decide what migrates: guest history, corporate accounts, rate agreements. Migrating everything is rarely right; migrating nothing is rarely right either.

Can a hotel sell rooms before it opens, and what has to work first?#

Yes, and most new properties should, but only after four things are true: the property may legally take the booking, the rate is loaded from one source, the confirmation reaches the guest, and someone answers when the guest replies.

Selling early is a business decision with prerequisites, not a switch. The certificate and permits, the agency contracts and the rate structure all have to exist before a rate is published anywhere. The wider order of those steps is covered in the guide to selling rooms before a hotel opens: certificate, contracts and booking sites in the right order.

One inventory, one truth. If the hotel's own website and a travel agency both hold rooms from different lists, the first double sale happens before opening day, when there is no experienced team to absorb it. A single room inventory feeding the hotel's own site, agencies and booking sites at once is the structural fix; two lists reconciled by hand is a countdown to the first apology call.

Test the full loop before the first real guest: make a booking, confirm it, change it, cancel it, refund it, and read the report afterwards. If any step needs a person to repair it by hand, that step is not ready. Open with fewer rooms than you have: a soft opening with a partial inventory leaves room to fix what the first guests find. And decide who is on the phone and by when. A booking channel that confirms at two in the morning needs someone to answer at nine.

The last four weeks: what does a dress rehearsal actually test?#

It tests the hotel's own routines against the systems, with the people who will do the work, on a day that is not opening day.

Create accounts per person, not per department. A shared login erases the record of who did what, and the record is the reason the system exists. Limit each role to what the person actually does: a housekeeping account does not need to void a folio, and the person who can void a folio should be named.

Train by role, not in one session for everyone: front desk, housekeeping, restaurant and bar, night audit, and the manager who reads the reports. Each group needs its own hour with its own screens. Then run a full simulated day and write down every failure. A rehearsal that produces no list produced no information. Rehearse the awkward cases too: a guest who disputes a charge, a lock that will not read a card, an interface message that arrives twice.

First week after opening: what should the support plan contain?#

A named contact, stated hours, an agreed definition of urgent, and a daily check of the numbers that would reveal a silent failure.

Agree the escalation path in writing before opening: who is called first, at what hour, and what response time applies. A support line that only answers email is not a support plan for a hotel with guests in it. Define urgent together with the supplier: a lock that will not open and a report that is one column wrong are not the same emergency, and treating them the same means neither is handled well.

Check the same few numbers every morning of the first week: arrivals against rooms occupied, charges that never reached a bill, interface messages that failed and were not retried. Keep an issue log with the date, the symptom, who fixed it and how; in the first month it is a support tool, after that it is the training material for every new hire. The pattern of the first weeks is covered in more detail in the first 30 days after a PMS go-live: daily and weekly checks.

Expect the first week to be about routines, not software. Most of what goes wrong is a step nobody had done before, and the fix is usually a written procedure rather than a setting.

What to do next#

Take the dependency table from the first section and turn it into your own dated list: for each line, write the decision, the person who owns it and the date it must be locked, then work backwards from opening day. The sequence is what protects the budget; the brands are a later and smaller question. If you are planning a property now, the next step is to fix the room-numbering scheme and the cabling plan this month, because those two are the only decisions that cannot be revisited cheaply.