top of page

The Basics of System Selection…

…the importance of making the right choices.

Choosing a system for your hotel or hotel company is an important decision for many reasons. These decisions matter to you and your hotel company, and the consequences of a poor choice can be severe, impacting operations, profits and guest service negatively for a long period of time, not to mention impact on your career! And of course, a wise decision has good impacts on all of the above.

Hotels buy things every day, some of low value and short-term impact, like paper towels. Others are costly with a profound long-term effect, such as a Property Management System (PMS). This article will outline most of the basic strategies and tactics in making an informed, traceable and disciplined approach to significant investments in hospitality technology. Not surprisingly, the same strategies and tactics can apply to purchasing almost anything else in the hotel enterprise…such as those paper towels, or cloth towels, or comforters.The simplest definition for the goal of a structured selection process might be “To get the right product with the right services at the right price from the right vendor at the right time.”


Here is a brief summary of some of the core strategies to employ in your selection process.

  • Alignment with Business Strategies – This concept is foundational, and essential to success. If the enterprise is built around centralizing operations and decision-making, you will make different decisions than a decentralized organization, usually built around unit-level autonomy and powerful GMs

  • Buyer Control – The hotel company needs to assert and maintain control of the process. Don’t allow your decision-making to be driven by a vendor, but rather establish your criteria, requirements, timeline, payment model, etc. internally and tell that to the vendors.

  • Standardization – Utilize the selection process to best standardize systems, process, training methods and so on across the enterprise, whether centralized or decentralized, to leverage the investment for maximum benefit to the company.

  • Best-of-Breed vs. Integrated Suite – The hotel company needs to make a strategic decision between committing to a tightly-integrated suite of products versus buying the best system for any given application. And then stick to that decision.

  • Drive Competition – Force the vendor community to compete for your business, a challenge the true sales professional relishes and lives for.

  • Set Expectations – Clearly define your selection criteria, timelines for selection and implementation at the outset of the shopping phase.

  • Communicate Specifics – Perhaps related to the idea of Set Expectations above, ensure that you give the vendors all the information required, whether it is number of rooms, number of employees to train or how many telephones you need for your new PBX

In order to Communicate Specifics, you need to document them. This documentation is at the core of the Needs Analysis process, which is what we will focus on in the next section. In the last section we will cover the Request For Proposal (RFP) process and its various alternatives and variations.

Needs Analysis

In this section we spotlight the Needs Analysis aspect of system selection, in plain English and actionable terminology.

In Needs Analysis, you are simply defining and documenting what your requirements are for the new system (or whatever else you are buying). Some of the “needs”, or requirements you must capture are broad-brush, high-level, macro concepts. Others are low-level, specific functional requirements that you need the system to do for you. Another class of requirements to capture tend toward the quantitative, addressing questions like “How many and how much?” Defining the services required to implement and support your new system are yet another set of needs to define. Let’s examine each of these major categories.

High-Level Conceptual Requirements

This is where you would capture things like “As a company, we have determined to move to true cloud solutions over hosted, and hosted solutions over on-premises.” Another might be “Internet Protocol (IP) interfaces are required for all interface systems except for local PBX and call accounting systems.” An example of an aspirational conceptual requirement might “We require open Application Program Interfaces (APIs) from the new system to any potential interfaced system, such that the API exposes most features of the system to the interfaced systems.”

The point is, these are high-level statements of where you want the new system to be able to take the company. These should generally be suggested, if not required, by a formal corporate IT Strategy Statement that is then used to inform the needs analysis for the current initiative and any others that arise. Many companies will not have a documented IT Strategy, in which case someone will need to work with leadership to elicit the key concepts that the enterprise chooses to operate undergoing forward.

Functional Requirements

These category of needs to document revolve around “What do we need the system to actually do?” For example, an extended-stay hotel will need the ability to present Daily, Weekly and Monthly rates. A convention hotel will need rich group block controls and master billing capabilities. A global brand will need the ability to present a user interface to the hotel employee in multiple languages (you cannot assume that a hotel worker in Shanghai will be able to read English prompts on a PMS or CRS, right?), and also the ability to present guest folio and similar content in the language that the guest prefers.

Determining these functional requirements is typically a holistic exercise, drawing on capabilities of the existing system deemed “must have”, wish-list items for features lacking in the current application contributed by line employees and managers, and features suggested by the specifics of that hotel company’s unique characteristic. Perhaps the richest source of functional requirements will derive from interviews of operating managers and employees and observation in the workplace by skilled individuals with a broad perspective on hotel operations and the technology itself.

Quantitative Requirements

Although in many ways the easiest set of requirements to assemble, gathering the detail for this class of requirements is often tedious and error prone. This is where you capture things like:

  • How many properties, rooms, countries and segments need to be serviced?

  • How many devices, concurrent user seats, rooms or other variables need to be licensed?

  • What interfaces to what other systems are required, down to model and version number?

Existing system inventories, if accurate, are a big help here. However, they often do not exist or are outdated, so at a minimum need to be validated or constructed from scratch.

Service Requirements

These are perhaps the most difficult and yet most crucial set of needs to document. Generally, one would look at services in two phases, Implementation and On-going Support. Implementation services begin with Project Management. Amazingly, many vendors fail to build in a Project Management component to their proposals, so they don’t invest in the service and it lacks in performance. Also, the client needs to be able to specify what Project Management services they require. Other major categories of Implementation Services include Training and Interface Installation. Under Training, address questions like:

  • How many people in each department need to be trained?

  • Will it be instructor-driven classroom training led by vendor personnel, ad-hoc training by hotel personnel after receiving Train-The-Trainer (TTT) instruction from the vendor or on-line training, live or recorded? Or some combination?

  • When relative to go-live or opening will training be conducted?

On-going Support requirements should detail hours of support required, escalation paths, service level agreements and more.

So, once you have documented these requirements, what do you do with them? That will be the subject of the next section, “The Request for Proposal Process”

Request for Proposal (RFP)

In this section we will focus on the Request for Proposal (RFP) and its cousins, the Request for Information (RFI) and Request for Quotation (RFQ), in plain English and actionable terminology.

A proper RFP is the reference standard for a disciplined, documented, traceable and unbiased selection effort. Formal RFPs are generally required by law for substantial expenditures of public monies and most public corporations have a policy requiring an RFP process with at least three bidders for acquisitions over some dollar threshold.

At a minimum, an RFP will include:

  • Background on the purchasing entity and what problems are to be solved with this purchase

  • Rules for the process: Deadlines, contact information, how to submit questions about RFP requirements and how they will be answered and numerous disclaimers

  • A precise definition of the products and services to be purchased

  • This will often include things like specific features that the buyer is looking for, such as a CRS RFP might ask about “Able to book multiple rooms under one name or under multiple names in a single transaction”

  • Also, will include quantitative information such as number of properties and rooms to be serviced, number of employees to train by category; A CRM system RFP might state “The membership database currently holds 1.5 million household-ed records growing at 15-20% annually”

  • The required services will also include Service Level Agreements detailing response times for responding to and resolving defects

  • Delineation of one-time costs (training and installation services for example) and recurring costs (monthly SaaS fees for license, hosting and support)

  • Also, to which incumbent systems the new system will be required to interface, such as a PMS RFP might list the make and version of the property’s existing; Key, Credit Card, Point-of-Sale, etc.

A sophisticated RFP for a major system purchased at the enterprise level will be large and complex document. Buyers should recognize that responding to an RFP is a time-consuming and costly effort for the responding vendors. Therefore, the scale and difficulty of responding to the RFP should be commensurate with the size of the opportunity for the bidders in respect of their time and opportunity costs.

An RFP for a brand-level CRS will be and should be lengthy, detailed and complex. If one is buying an F&B POS for a single hotel with three outlets, you might still use an RFP, but the scale and complexity should be dialed down to match the sales value to the vendors. Keeping the length and difficulty of the RFP to scale benefits the buyer as well: Once you get the proposals in, you have then to evaluate and score them.

We favor a mix of quantitative and qualitative evaluation techniques. On the qualitative side, you can assign point values and weights to requirements in the RFP and calculate a numerical score that will give you a basis to compare the proposals. Qualitative evaluations might include did they adhere to the stated process? Was the proposal clearly written, with basics of careful writing shown? Were images and screenshots clear, legible and fit for purpose?

And of course, there is price. We generally counsel our clients to consider price ‘a’ factor and not ‘the’ factor. A well-constructed RFP will include a worksheet with sufficient detail to estimate all costs of the acquisition, noting that a system purchase with significant custom software development will at best yield a cost-range at this point. However, different vendors, different business models and different applications will oftentimes yield different responses in a pricing worksheet. So, it is the evaluator’s challenge to produce a pricing analysis that truly compares apples to apples instead of okra to apricots. Adjustments, interpolations and calculating the time-value of money are all tools that enable that fair comparison.

The RFP has some close relatives, Request for Information (RFI) and Request for Quotation (RFQ). An RFI will usually not really deal with price and not contain as much detail about the requirements. The RFI is a good tool to use to go learn and understand what is in the marketplace before crafting the full RFP. Another appropriate use of the RFI is to pre-qualify vendors to receive the RFP. A short and simple RFI can ensure that only qualified bidders receive the actual RFP.

The RFQ is appropriate for situations where the requirements are well-known and documentable, and the focus is on the price quote. A bulk keycard purchase for a brand would be a good use for an RFQ.

So, the hotelier has several tools at hand to help them make the right purchase decision. Crafting the right RFP for the purchase at hand goes a long way to making the right decision in a fair and traceable manner. It is a strong tool and a powerful process when well-executed. Given that most system purchases are high-cost, high-impact and you have them for many years, investing in the RFP process appropriately is the right investment.

The Proper Use of References

References are a tricky area to execute adeptly in the system selection process. Oftentimes, a reference interview doesn’t tell you much, it becomes a time-consuming effort for what you get out of it and the hotelier has an obligation to treat the referring hotelier and his relationship with his vendor with respect. Let’s take a moment to look into each of these potential problem areas and how one might mitigate the possible issues.

Value of the Reference Content

This challenge has several sources. A big one, vendors are most unlikely to connect you with an unhappy client that will give a negative interview. Equally important, even an unhappy client is often unwilling to say anything too bad about their vendor to a third party. Although they are usually very glad to speak directly about shortcomings to the vendor. There are three primary strategies to overcoming this problem:

  • You can speak with other users of the subject system in addition to those put forward by the vendor. You may well know other hoteliers using the system from your personal network. Browsing press releases on the vendor’s website or a simple Google search will often identify a neutral reference

  • If you get someone that is overwhelmingly negative or more likely, unbelievably positive, don’t be afraid to discount that reference and move on to the next

  • Listen for strong praise and faint damns, or damnation with faint praise, but don’t buy the extremes

  • Use a structured, consistent, written interview protocol for all reference check interviews

  • Make it long enough to be meaningful, but short enough that the other hotelier does not feel you are presuming upon their time

  • First, qualify that you are speaking to the right person

  • Were they involved in the original selection process?

  • How long have they been working with the subject vendor?

  • Are they the point person on the relationship from their company?

  • At the beginning, focus on facts, not feelings

  • Were any customizations or enhancements committed to during the sales cycle?

  • Were these commitments fulfilled as expected

  • How often do you call for support?

  • What proportion of support issues get resolved on the first call or first day?

  • As you approach the end of the interview then touch on feelings and opinions:

  • Knowing everything you know now, would you choose Vendor X again?

The structured interview form is also an essential tool to address the other challenges with reference checking, how much time and effort it takes and treading carefully on other firms’ business relationships.

Reference Checking is Time-Consuming

Well, it is. Setting up the appointments, conducting the interviews (at least three, likely more) and documenting the interviews all takes time. And sometimes, despite all best efforts, you invest that time and don’t get a great read on what it is like to be a customer of the subject vendor, perhaps it hasn’t been time all that well spent. But the fact is, you have to do it. If the selection committee gets to the CEO and she asks, “What about references?”, you need to have a better answer than “We ran out of budget for that.”

So, what do you do to mitigate this problem?

  • A tight, structured interview form as described above is crucial

  • Be selective:

  • Do reference checks late in the cycle with finalists only, not for all bidders

  • Try to use the least-expensive resource available for scheduling and confirming interviews

  • And yes, confirm them the day before!

  • Capture your interview notes in real time and edit them immediately afterwards, not a couple days later.

  • This practice makes summarizing all of your reference findings into a coherent finished product much more efficient.

Honor the Vendors’ Existing Relationships

It is crucially important to maintain respect for the vendors’ existing business relationships with other hotel companies. By giving out a reference, they are exposing their most important corporate asset, their customers, to you. So, give that it’s due and be on time, use no more than the allotted time and avoid questions about the heart of the client’s business. And of course, be judicious in the questions about the vendor.

In the next section of this series, we will discuss the Evaluation of the proposals, references and everything else one learns during a structured system selection process.

First Published at HNN

Mark Haley and Mark Hoare are Partners at Prism Hospitality Consulting, a boutique firm serving the global hospitality industry in technology and marketing. Managing system selection efforts is a core practice area. For more information, please visit, or call +1 978-521-3600.


Featured Posts
Recent Posts
Search By Tags
bottom of page