Setting Course for Your Next System: 31 Habits for a Highly-Effective System Purchasing Process

Order a reprint of this story
Close (X)

ORDER A REPRINT

To reprint an article or any part of an article from Hospitality Upgrade please email geneva@hospitalityupgrade.com. Fee is $250 per reprint. One-time reprint. Fee may be waived under certain circumstances.

SEND EMAIL

March 01, 2005
Hotel | Purchasing Process
Jon Inge - jon@joninge.com

View Magazine Version of This Article

© 2005 Hospitality Upgrade. No reproduction without written permission.

Over the past few years the system selection process has become increasingly challenging to both hoteliers and vendors. Well aware of the old saying that “if you don’t know where you’re going, any road will take you there,” most properties lay out the familiar road map: initial research, request for proposal (RFP), bid analysis, scripted demonstrations of selected systems, final arm-twisting – rather, negotiations – and then a contract. But these days the map covers a great deal more territory, and has become both more detailed and more difficult to navigate.

In the past, some properties seemed to be relying on the famously inaccurate Tates compass to get through; now everyone needs a good GPS.

As hoteliers continue to integrate ever more operational areas into one unified information system, the RFP documents become longer and can make it difficult to identify critical functions. The vendor response has been increasingly powerful software products that can be stunning in their breadth and capability. But reviewing any one product in detail could easily take several days, an amount of time no buyer can afford to spend, especially with multiple vendors. It has become a genuinely difficult problem to put together a concise presentation that quickly lets the hotel grasp a system’s essential nature and how it addresses key issues.

The time available to hoteliers has decreased in direct relation to the growing complexity of their environment, especially when assembling multi-department teams to view system presentations. This puts increasing importance on the RFP process. Although the RFP document will often be very detailed team members can review and respond to it as their schedules permit. Gaining as much understanding as possible from the vendors’ RFP responses frees the live presentations to focus on critical issues.

The pressure of squeezing a complex task into a shorter time frame makes it essential to maximize the productivity of both the RFP and demonstration processes. They’ll never be perfect, but as an independent participant I thought it might be useful to document my own observations that can help make the process more effective.

Since both parties in these exercises are equally human—despite what they say about each other -- and equally capable of leading themselves astray, here are some comments and suggestions for each, both for the RFP process and for system presentations. Not every hotel or every vendor falls into each one of these traps. Generally, most companies do a good job, but I’ve seen every one of these issues come up in the past. Anything both sides can do to make the process more effective can only help reach the most desirable objective: more properties finding more systems that match their needs more closely.

The RFP Process: Hoteliers
RFI before RFP
 
As the buyer you need to go into this search armed with at least a requirements checklist, and preferably a fully detailed RFP. There are immediately two difficulties. One is that it’s not always easy to know exactly what you want before you’ve seen what is available in modern systems. The second is that if you have a clear idea of your requirements and can produce a fully detailed RFP document, it takes the vendors a considerable effort to respond to them, and it’s not fair to ask more than the most likely candidates to do so.
Both situations can be helped by starting with a high level request for information (RFI) document describing your property and operation, and listing critical functions and any key systems that will remain in place. Distribute this to an initial selection of vendors, and ask for a one to two hour remote demonstration (using WebEx or some similar program) to gain an overall familiarization with their products.

This achieves two useful goals. It provides a quick overview of the state of modern systems, firing the imagination of your selection team to think about ways they might use these functions to improve operations and in turn helps them prepare an RFP. It also narrows your selection of vendors to those whose systems and general approach to operations match your own, and to those who have a serious chance of landing your business, without wasting the time of those who do not.

Requests for Proposal
A few words about RFPs

Completeness. Make an RFP as detailed and complete as possible. It can be tedious to list all the functions you want the new system to perform, and you certainly won’t have time to check everyone in the product presentation. However, for that very reason you need to have the vendors verify their compliance with each issue and to include the complete document, with the vendors’ responses, as part of any resulting purchase contract.

Include open-ended questions. Ask the question “how” whenever the way a system performs a function is as important to you as that the system even performs that feature at all. Keep a balance though. You’ll get a much better feel during the actual systems presentations and you don’t want to ask questions the vendor needs four paragraphs to answer. It can be helpful to distinguish between different systems. For example, in addition to asking “Does your system include a wait list?” you might also ask “What happens when a reservation is canceled for a day where a wait list exists?”

Prioritize. Weigh each item on a scale from critical to desirable. Be realistic in assessing which issues are truly deal-breakers. Some things really will be critical, but not every item would prevent you from buying the system if the vendor did not comply with it fully. At this stage you don’t necessarily need to advise the vendors how critical each issue is to you.

Look Ahead. Be as forward thinking and you can; what will you really be doing in two years time? It’s much easier just to get a better version of what you’re doing now and remove existing roadblocks (and both are worthy objectives), but try to look further ahead. Make sure you have a strategic operations and technology framework into which the system being reviewed fits logically, and include appropriate development and interface issues in the RFP.

Weigh the Responses. Evaluate each vendor’s response to each issue on a scale from fully compliant through will develop to non compliant. No one issue will have a major effect on the total by itself, but little differences do add up. Comparing the weighted scores for each vendor gives a general rating for each system’s overall capability.

For the Vendors
 
Be Concise. When responding to an RFP, strike a balance by providing enough information to describe your system's compliance with each issue succinctly, without burying the document in excessive sales prose or unrelated text. Quite often the single word compliant is too terse, and a little explanation helps clarify the issue. On the other hand, resist the sales approach of copying excerpts from your brochures. It’s really hard to wade through these when you’re looking for a specific answer.
Address the point, then stop. Many clients will copy your responses into a comparative worksheet; if you’re too wordy your response will be paraphrased, and may lose something in translation. If you truly need to explain a point at length, and some RFP questions can be very general, enter a brief overview and attach a separate document.

Be Honest. If the system doesn’t do something, just say so and don’t claim full compliance on the grounds that you plan to develop it before you think the hotel will need it. It’s likely that every vendor will have to undertake some development, especially for forward-thinking RFPs that include functions a hotel would like to implement over the next couple of years.

Help the Client. Don’t be lazy and send a list of possibilities, such as telling the client for something not listed there is an extra charge for development. This frequently happens with sub-system interfaces, and it’s not always easy for the client to match his system models and version numbers with your list. A few phone calls to verify what is in place will make for a much friendlier quotation.

Provide Useful Samples. If you include screenshots or a sample report manual to illustrate a point, include enough real world data to be useful, with context as to which reports might address a particular question(s) or what they’re intended to report on. A screenshot with no data or a grid of numbers with dates across the top isn’t particularly helpful.

System Presentations
This is where the rubber meets the road. The hotel has used the RFP responses to narrow the choice of systems to those that, theoretically, are a good match with its requirements. Now it needs to see how each actually performs those functions, to pick the one that most closely fits its own character and way of operating.
It is also the one area of the system selection process that can get out of hand the quickest. It is easy for hotel team members to become distracted and pursue anything that catches their interest in the shiny new system. And however professional the vendor might be in demonstrating just the key functions the client has asked about, there will always be other options in their system that will make a difference to the hotel and the vendor will want to present.

This requires a strong commitment to a professional approach on both sides. To stay on track both parties need to pay attention to the questions and answers, be punctual in returning from breaks and keep side conversations to a minimum. And for heaven’s sake, no checking e-mail on Blackberries under the conference table.

For Hoteliers
 
Demonstration Checklist. The absolute minimum requirement is a checklist of the same key functions you need to see demonstrated by each vendor. For all but the most straightforward hotels, it’s preferable to prepare a more specific script covering the following items:

1 The basic daily actions of your staff. Every system makes reservations, sets up group blocks, checks guests in and out and posts folio charges, but you need to see how fast and intuitive each process is. Time saved on the fundamentals adds up during the day.

2 Those more complex situations that come up often and regularly cause grief with your current system. An example might be a businessman is booking a Wednesday arrival as part of a conference block and wants to move to a different room type for the weekend when his wife and children will join him. He also might like to make golf, spa and children’s activities bookings. Be open to suggestions from the vendor; they see many other operations using their systems and may have good suggestions for you to consider.

3 Specific issues from the RFP where the vendors’ responses weren’t clear, where you suspect that they may not have understood the question, or how the system performs a function needs to be demonstrated.

Don’t try to cover every item in the RFP. There won’t be time, and if the response was clear there’s no need. Better to use the limited presentation time to cover the above three areas.

Send your presentation script to the vendors one week before the presentation to give time to prepare their systems, especially if you’ve been particularly detailed in your requirements.

Set an Agenda. Have an agenda listing which areas will be covered when. It’s often difficult for some department managers to attend for a full day, and it’s considerably less disruptive if they can slip in for their section rather than asking for some material to be covered out of sequence, or even repeated.

Start with an overview of the system’s basics. Two examples of good basics are what information is kept in a guest profile or how rates are defined. It’s tempting to jump right in and start making a reservation, but as soon as the first screen pops up people always ask about rates and profile data. Better to start with them, and gain a clearer perspective of how simple it is to make a reservation with fewer distractions.

Allocate some unscripted time at the end of the day for vendors to show and tell key functionality they believe will benefit you but isn’t in the script. This forestalls their desire to bring it up during the scripted sections, and you may learn about something you can really use but hadn’t considered.

Take Notes. Be as meticulous as you can when note taking how well each system meets each checklist item. It’s frustrating during the wrap-up review if you can’t remember which product had that really neat feature, or which didn’t show enough depth for your needs in a critical area.

Manage Expectations. Keep the team’s expectations realistic. Nothing is perfect. They won’t find a system with a 100 percent fit and each one of them will feel that they didn’t get enough time to explore their particular area. What you want is an overall feeling of the comprehensiveness and flexibility of each system, how well they match your style of operating, and which has the best fit with the highest possible number of your original requirements.

Focus on the System. Do your best to separate the system from the salesperson. A brash, wise-cracking extrovert may not be accepted well by a laid back, conservative hotel operator or a trainer brought in at the last minute to replace a sick salesperson may come across as hesitant and unsure. Either of them may be demonstrating the perfect solution for your needs. Be patient with individual characters and focus on the functionality of the system itself.

Stay Focused. Make sure one person on your team acts as timekeeper and overall guide to keep things on track. The perils of exploring minor rabbit trails or one team member’s personal beef are well known, but hotel team members can also spend long minutes venting passionately about their current obstacles without acknowledging that the vendor had just shown a perfect alternative. If you ask the vendor, “Can your system do X?” and he says yes and shows you, quickly and simply, make a note, accept it happily, and move on.

Be Courteous. The vendors have gone through a great deal of trouble to assemble their team and presentation for you. Whether you invited them because their system is a genuine contender, or whether you’re using their lower-cost bid as a lever to pull down another vendor’s price (let’s face it, this happens), if their system wasn’t closer than several other solutions they wouldn’t be there. Even if you have a strong magnetism to one vendor after the RFP process, genuinely try to learn how well the other systems fit your needs. Each has some unique features, and at the very least you may learn a better way of doing something. You’re looking for information, not ammunition.

Isolate Cost from Functionality. Distribute your RFP functional comparisons and conduct the system presentations without letting your team know what each solution costs. One might just be worth its higher price. Conversely, if it’s not obvious to the team from the functionality which one of five systems costs twice as much as any of the four, it’s probably not worth it.

Check the Business Case. Specifically ask each vendor how their solution will improve your revenue and support your business operation. Few hotels do as this question, but isn’t that the reason you’re going through this? Even fewer vendors are capable of answering it without resorting to global generalities and platitudes, but if they’ve done their homework and understood your requirements properly they should be able to focus on the key things that will make a difference to you.

Keep a Sense of Humor. Things will go wrong, there will be misunderstandings, the vendor will try to show you things you didn’t ask for, your own team members will ask about issues they’ve never brought up before, and you’ll probably run out of time. Just steer things gently but firmly back on track, keep a sense of perspective, make sure you see the most critical items on your checklist, and remember you can always set up a remote WebEx demonstration later to clarify specific points.

For the Vendors
 
This is your chance to show how well you’ve listened to the client, understood their specific issues and are fully prepared to show how your system handles their scenarios. You’re never going to get as much time as you’d really like to demonstrate your system thoroughly, so whether on a one hour remote presentation or a full day scripted demonstration, good preparation and a focus on the client’s key issues will always pay off.
Keep Company Overviews Brief. A quick summary is fine, including some reference clients relevant to this particular client, but a 30 minute exposition on the company’s history over the last 20 years and showing a list of chain references to a single property resort show a disregard both for the client’s time and individuality. Your credibility is not in question or you wouldn’t have made it through the RFP round.

Use Real-World Data. Using clean, realistic data, in both content and in quantity, makes a major difference. Don’t re-use the same names over and over without resetting the database. It is really hard to follow which of the 20 identical Bill Smiths is the one you just made a booking for. And use humor with care; Mickey Mouse gets old after awhile.

Pick names from mid-alphabet whenever possible. It’s unrealistic to always pick the first name at the top of every list, and the client will want to see how easily you can get to names further down. They’ll be doing that every day.

Make sure you have enough variety in your data to populate all screens and reports. Time after time I’ve seen a blank screen or report pop up with the embarrassed comment, “Well, if we had any data in here it would show what you asked.”

Spell Check! Even if the meaning is still clear, spelling errors catch the eye and interrupt the client’s attention to your system’s functional brilliance. And they inevitably raise questions about whether that same level of quality control went into the software or goes into support.

Use Trained Presenters. Ensure that your presenters really know the system. They should know how to quickly find and demonstrate the best function to solve a client’s specific need and the best guest profiles and bookings to illustrate it, and have the ability to establish a good rapport with the client. This is very, very difficult, and relies very much on the personalities on both sides. Grace under pressure, a thorough and sound knowledge of the system and the ability to think quickly are tremendous assets.

Start with the Structure. Begin by explaining the philosophy behind your screen layouts, how and why data elements are grouped, how you move within the data, where profile information is kept separate from reservation/visit history and details, and so on. Giving your audience a clear grounding in the system’s basics before you move into its functionality can answer many questions before they even arise.

Be Prepared to Run End of Days (EOD). For many clients it can be important to show how package charges are distributed overnight or how deposit policies are implemented, commissions posted after check-out or pre-defined room moves are notified. Many date-dependent actions are triggered by an EOD, and you have already confirmed that the EOD process is fast and requires no down-time, right?

Stick to the Script. Much as you might like to take a different, more familiar path through the system’s many features, there’s a reason why the client scripted out those specific functions, and in that order. Don’t do as one vendor did in my experience, and start by saying, “You don’t really want us to stick to this, do you?” tossing the script on the table and launching straight into their canned demonstration.

No Comparisons. Don’t tell your client “This next feature is something you won’t see on any other vendor’s system,” or “No one else takes this approach to guest profile data.” Comparisons waste time and imply that you don’t believe your system is good enough to stand on its own without denigrating the opposition. More practically, how do you know? Do you keep up with all your competitors’ updates to their systems? You lose credibility if you make such claims when the client saw that very feature just the day before from another vendor.

Don’t Blame Your Tools. If something’s not working right, please don’t claim it was just loaded on your PC last night, even if it’s true. It just sounds like “the dog ate my homework.” If you’ve got a great, brand-new feature that you know will make an impact on the client but isn’t quite ready for release, say so up front and put it in a separate demo database. Don’t sabotage your presenters in front of the client by making the system they know and rely on unstable.

Have a Back-Up Strategy. Sooner or later, something’s bound to go terribly wrong, like a demo laptop failing during a presentation. You’ll have the sympathy of everyone in the room, but you still have to present your system; the client is unlikely to assemble the same team again without difficulty. Keep a copy of your slideshow on a USB drive, have an identical copy of your demo system on a colleague’s PC if it’s not a solo presentation, or be able to set up an Internet link quickly from a borrowed PC to a back-up demo system at your corporate office, but always have a plan B. A quick recovery is essential to your credibility.

Don’t Over-Staff. Keep a balance between too few or too many people at the presentation. Fewer is better, as long as they are skilled enough to present all the modules the client is interested in. Given the breadth of many modern systems, that’s increasingly difficult for one person to do, though there are a few demonstrators out there with an amazingly wide grasp of their products.

Vendors who send a Mongolian horde imply that they have enough surplus people on staff that they can afford to fly them to presentations where they have almost nothing to contribute beyond their presence. What is worse is if the client is providing board and lodging. Sending fewer people and being more committed to lowering their operating costs is a better message.

Most clients do a good job of summarizing their needs and keeping their teams focused (and in the presentation room). Most vendors are highly professional in their RFP responses and system presentations. But the sheer capability of modern systems makes it a constant struggle to find the best answer to each of the client’s questions quickly and courteously, while also demonstrating how other functionality will help the property’s operation, all without running out of time.

The fundamental keys to staying on course includes a full knowledge of your operational needs and system characteristics with a concise description and demonstration, a sound process, and above all, staying focused on your destination.


Jon Inge is an independent consultant specializing in technology at the property level. He can be reached by e-mail at jon@joninge.com or by phone at (206) 546-0966.

Articles By The Same Author



want to read more articles like this?

want to read more articles like this?

Sign up to receive our twice-a-month Watercooler and Siegel Sez Newsletters and never miss another article or news story.