A requirements document for hotel software: a template that makes vendor offers comparable

A hotel software RFP is a written requirements document every vendor answers in the same order and format, so offers can be scored side by side instead of compared from memories of demos. This hotel software RFP template has five sections, a scoring table and one scripted demo.

Three vendors demo three polished products, and the notes come back as three impressions rather than three offers. The reason is rarely the vendors: no two of them were asked the same question in the same words. After reading this you will be able to send one document to every vendor, receive answers in the same rows, and score them before anyone books a flight.

Why does a written requirements document beat a demo?#

Because a demo shows what a vendor chooses to show, while a written document forces every vendor to answer the same questions in the same order.

A demo is a performance. The vendor picks the flows its product handles well, and the awkward ones, such as group blocks, split bills or a correction after night audit, appear only if someone asks for them by name. The document also settles internal disagreement before the vendor arrives: each department writes down what it actually does, and the general manager sees where two departments describe the same step differently.

Same numbering, same order means answers arrive as rows you can compare, not as paragraphs you have to remember. Keep it short enough to be answered: forty numbered requirements that every vendor must answer beat two hundred lines nobody reads. The document is the scoring table in disguise, because every requirement becomes a row with a weight, and the weights are agreed before the offers arrive. Later it becomes the annex to the contract, so the promise made during the sale has a written form.

The questions themselves are half the work; they are collected in our guide to the questions to ask hotel PMS vendors in Türkiye. This document is what turns those questions into comparable answers.

Section 1: what goes into the property profile and current systems?#

Enough about the property that a vendor can scope and price the work without guessing: size, outlets, structure, guest mix and the systems already in the building.

Write rooms by type and the outlets: restaurant, bar, spa, meeting rooms. State whether the property is seasonal or year-round, and whether several properties must run from one login. Guest mix decides languages: which languages the front desk, the bill and any guest-facing page must work in, and who writes the content.

List today's systems, one line each: reservations, restaurant and bar sales, accounting, door locks, channel connections, the e-invoice integrator, with who holds each contract and when it ends. Then say where the truth sits today: which system owns the room inventory, where the guest bill is closed, where the fiscal document is issued, and which spreadsheet quietly holds a copy of all three. Name who will use the new system and how many accounts: front desk, housekeeping, management, accounting, group office, and whether any of them work from a phone. Finally, list equipment that cannot be replaced this year, such as locks, key card encoders, printers and tills, because every one of them becomes an interface requirement in section 3.

If you are unsure how these systems relate to each other, read how the core hotel systems fit together first.

Section 2: how do you describe the processes the system must support?#

Write each requirement as a process: who starts it, what triggers it, what the system must produce, and what has to happen when it goes wrong.

Go department by department: reservations and groups; front desk (check-in, check-out, early departure, a guest who cannot be accommodated); housekeeping (room status, minibar, maintenance); billing and night audit (voids, reversals, transfers between accounts, split bills); restaurant and bar sales; and reports. Write the exceptions next to the normal path. A system that handles check-in but not a bill split between a guest and a company account will be discovered in week one, at the worst possible moment.

Describe the outcome, not the screen: "the bill closes with the correct fiscal document and the room returns to inventory" rather than "a folio screen with three tabs". Mark every line must-have, important or nice-to-have, and tell vendors to answer must-haves in detail and the rest in one word. List the reports the property uses today, by name and by who reads them, and require each one to exist or to be quoted separately as custom work. Add a one-line example under anything ambiguous, because two vendors will otherwise read the same sentence in two profitable ways.

Section 3: how do you write compliance and interface requirements in general terms?#

State the step that must happen, not the product that performs it, and ask each vendor to describe how its system carries that step and who reviews it.

In Türkiye, every stay involves a payment, a fiscal document (an invoice or e-document), a guest identity notification (KBS, the misafir kimlik bildirimi) and personal data (KVKK, the personal data protection law). Ask for each step: where it happens, who confirms it, what is recorded and how it can be corrected. Keep dates, turnover thresholds and fine amounts out of the document. They depend on the taxpayer's own scope and are re-valued, so the document asks what the vendor supports and your accountant confirms the duty.

Ask whether a document waits for a person before it is sent, what happens when it is rejected, and whether the rejection is visible to the person who issued it. One regulatory line belongs in writing: the Ministry circular 2026/1 (16.04.2026) obliges accommodation facilities and their software providers to send data to the central tourism database through a web-service connection (reported by alomaliye.com, 6 May 2026). Ask each vendor to describe its position in writing rather than in conversation.

Interfaces get one row each: door locks, restaurant and bar tills, accounting, channel connections, the e-invoice integrator. For every row ask for the status, a named property where it runs, who pays for it and who to call when it stops. Never accept a certification acronym as an answer to a security question. Ask what is logged, who can read it, how access is removed when a receptionist leaves, and where the data is stored.

Section 4: what should the data, access and exit section ask for?#

The right to take your data out in a usable format, on a stated timeline, at a stated cost, plus the rules for who can see and change it while you are still a customer.

Start with one sentence on ownership: the hotel's data belongs to the hotel, including guest history and the reports built from it. Then the export: a spreadsheet-readable file rather than a printed report, on request or on a schedule, how long it takes, and what it costs. State what the export contains: reservations, guest profiles, bills, rates, restrictions, attachments and the report definitions.

Access rules come next: named roles, who may void a bill, who may change a rate, what is logged, and how long the log is kept. Exit terms close the section: notice period, a parallel-running window with the old system, what happens to the data after the contract ends, and written confirmation of deletion. "We will help you migrate" is not an answer. Ask for the format, the person and the date.

These questions work best alongside the contract clauses to read before signing hotel software.

Section 5: how do you ask for support, training, feature status and price in one format?#

Give every vendor the same table and refuse free-form proposals: same rows, same units, same currency, same tax treatment, three-year total.

Support: hours and time zone, channels, who actually answers, response and resolution targets, what is included and what is charged, and the name of the person who escalates. Training: how many sessions, for which roles, on site or remote, who writes the material, and what happens when a new receptionist joins in month six.

Feature status gets one column per line: built, tested with real data, running at a named property, or planned with a date. A vendor that cannot name a property for a must-have line is answering honestly, and you can price that risk. Ask about the upgrade policy: whether new versions are included, who decides when to upgrade, and what happens to custom reports after an upgrade.

Ask for a three-year total, because a low first year with paid interfaces and paid training is a different offer from a flat one. The costs around the subscription are covered in how hotel software is priced beyond the subscription.

How do you turn the answers into a score, and what does the scripted demo look like?#

Score the written answers first, use a pass or fail gate for must-haves, and only then run one demo written by the hotel and given to every vendor unchanged.

Gate first: an unanswered must-have line is a fail, not a low score. Averaging an empty answer into a total hides exactly the risk you are buying. Weight the rest before the offers arrive: process fit, compliance handling, interfaces, support, three-year price and exit terms, with the weights written down and agreed by the owner and the general manager. Score independently and in writing before the meeting, then reconcile; a single scorer drifts towards the last demo seen.

The demo script is five or six scenarios taken from the hotel's own week, in the hotel's order, with the hotel's data shape: a group block that only partly picks up, a guest leaving a day early, a bill split between a guest and a company. Time-box each scenario, ask the vendor to use its own product rather than slides, and stop the clock when the answer becomes a promise. Ask for a reference property that runs the same modules and the same interfaces, and ask what broke in the first month and how it was fixed.

What to do next#

Write the document this week: one page per section, numbered requirements, one price table and one demo script, then send it to three vendors with the same deadline. The questions themselves are the other half of the work, collected in our guide to choosing a hotel PMS in Türkiye; the document is what turns those questions into answers you can score, contract and hold a vendor to.