Purchase Process
The purchase process should adhere to a standard sequence of events. It is anticipated that the purchased system would meet the rigorous demands of business, conform to budgetary constraints, produce cost savings and provide years of reliable service. Throughout the purchase process, management should:

1. Focus on system capabilities that apply directly to transactions representative of current and near future operations. This approach will help ensure that the selected system fits operations; as opposed to the need to modify operations to conform to system requirements.
 
2. Control the purchase process. By preparing detailed specifications and a date-specific timetable, the process can be effectively monitored. Time management is important to the purchase process. It enables management to maintain on-going hospitality operations while testing the responsiveness of the vendor within various constraints.
 
3. Direct vendor presentations so that competing vendor systems process identical data. Differences in processing techniques become more obvious when applied to the same set of transactional data. Avoiding vendor presentations that highlight technological features, not data processing capabilities, often proves highly productive.

4. Involve many personnel in the definition of system needs and application specifications. Typically, the more input the better selection and subsequent acceptance of the solution. The technology project team concept tends to be a sound approach.

Property Profiling
It is important to identify the types of information that various levels of management presently use in the course of normal operations. This can be accomplished by compiling samples of reports presently prepared for management use. Once collected, the reports can be analyzed in relation to such variables as purpose, content, users and frequency of preparation. This approach helps identify the types of information currently used by management, but it does not necessarily reveal the information needs of the business. A survey of managers should be conducted to evaluate the effectiveness of current reports as well as provide a basis upon which to make improvement.
 
Development of a property profile involves the compilation of volumes of business (e.g., total revenues, number of employees or number of guest checks), physical descriptors (e.g., number of guestrooms or number of seats) and statistics (e.g. percent occupancy, average room rate or average guest check) relative to the current information system. A property profile proves useful when communicating information needs of the business to system vendors. The property profile allows vendors to compare the property’s needs to similar properties with installed systems.
 
After creating a property profile, management should collect sales literature on a variety of technology offerings that appear to meet general information needs. Effective ways by which to collect relevant product literature include inquiries to state and national trade associations, attendance at industry trade shows and contact with local system vendors. Once management has analyzed the information needs of the business and collected sales literature, the next step is to establish general system requirements and formulation of a request for proposal.

Request for Proposal
After translating information needs into system requirements, management is ready to request proposals from vendors. A request for proposal (RFP) is typically made up of three major sections. One section orients the vendor toward management’s business operations; a second section establishes bidding requirements for vendor proposals; and a third section describes user application requirements.
 
A RFP should contain an overview of the hospitality business and a list of objectives and broad operational requirements. In addition, a brief explanation of anticipated vendor responsibilities (for example, proposal submission closing date) is often included. Vendors should be encouraged to submit as much information as possible in a variety of relevant areas, including:

• hardware configurations
• software descriptions
• maintenance and support services
• installation and training programs
• guarantees and warranties
• purchase/payment options
• future expansion of the proposed system

The RFP should also establish bidding requirements for vendor proposals. All proposals should be submitted using a standardized response form carefully crafted by the technology project team to facilitate system price and performance comparisons. Vendors should also include a statement of their financial stability.

Vendor Presentations
There’s an old adage that states, “The problem with salespeople isn’t that they’re not knowledgeable. The problem is, most of what they know isn’t true!” Too often, this appears painfully appropriate during vendor product demonstrations. Unless closely monitored, product presentations evolve into an unfocused collection of neat system tricks that bolster the vendor’s confidence while frustrating the client. Such a situation usually necessitates that the vendor return and base his/her presentation on those questions the vendor thought were addressed but the client feels were omitted.

Management assumes that vendors oversell systems since sales agents collect sales commissions. Often the reality is systems are undersold; thereby enabling the vendor to be selected based on low bidding only to later sell additional components the client system might have originally required. How can a manager be expected to review six or more systems and have any comparative benchmark by which to make an intelligent judgment? How can management be assured that a system is capable of addressing its specific needs? The resolution to these and related questions may be the implementation of scripted product presentations.

Scripting Presentations
There are several important factors involved in the scripting of transactional scenarios for vendor product demonstrations. Such factors as:

1. Determine important system capabilities to be demonstrated. Meet with management personnel, clerks, waitstaff, housekeepers, production staff and others to determine potentially problematic areas where technology may be effectively applied.

2. Develop typical transaction scenarios to be scripted. For example, have restaurant waitstaff document actual guest behaviors, preferences, unusual patterns of behavior and methods of settlement. Require participating vendors configure their systems with the restaurant’s menu so as to closely simulate actual order entry, modifications and settlement.

3. Identify near future events that are likely to impact system needs. Consider such things as physical plant expansion, changes in staffing, online applications, satellite interfacing, e-mail, e-procurement, payroll processing, intranet developments, extranet implementation, et cetera.

4. Arrange scenarios in a logical order, but stagger transactional information. The establishment of open guest accounts, followed by other non-related transactions, and then modeling subsequent transactions back to original accounts will simulate the flow of actual business conditions and test the system’s ability to monitor transactions in random fashion [see sample script].
 
5. Stipulate to the vendor the importance of strict adherence to the scenarios as written. Also, limit the vendor’s demonstration time to force the vendor to address things management is most interested in knowing vs. what the vendor is most interested in telling. Experience indicates that a 90-minute vendor presentation period is typically sufficient to accomplish a 15-transaction script. Be sure to inform the vendor that some changes to the script will be made on-the-fly during the demonstration to ensure system flexibility.

NOTE: During a vendor presentation it is advisable to suggest alternative transactions to those scripted. If for no other reason than to prove that the vendor isn’t simply following a preprogrammed simulation of the scenarios. The goal being to witness simulated transaction processing in real time.

Demonstration Requirements
During vendor presentations management must direct and control the sessions. Important points include:
 
1. Require the vendor to employ hardware components and application software referenced in their proposed system configuration throughout the product presentation. All relevant components necessary to track the scripted scenarios should be demonstrated. This is essential. Returning to the restaurant example, if remote kitchen printer output is part of a scenario, then the vendor should include a remote workstation printer in the demonstration. If smartcards, transponder chips, handheld terminals, magnetic stripe readers, bar code devices or other units are included in a vendor proposal, then the vendor is required to demonstrate these capabilities during the 90-minute scripted demonstration session.

2. Emphasize to the vendor that the transaction scenarios are to be demonstrated one at a time, in the sequence presented. Scenarios should not be modified or re-arranged or re-organized by the vendor in any manner. The demonstration process may be interrupted by client comments, but once a question is answered the vendor must proceed to the next transaction as the 90-minute time constraint should be enforced.

3. The vendor’s representative should be technically and operationally competent. The representative must be knowledgeable about system functionality. While scripted scenarios provide insight into client needs, additional questions may require spontaneous application software modification and/or demonstration. For example, suppose the presenter is asked a question on menu item price modification. The representative should be able to demonstrate the simplicity in affecting a price change. When a follow-up question relates to the impact on pre- and post-price changes to end-of-day sales reports, the representative needs to possess sufficient system knowledge to resolve the issue.

4. The vendor should perform a site survey prior to product presentation to ensure familiarity with operations. Too often, vendors tend to perceive potential hospitality users as homogeneous and thereby fail to properly differentiate or customize a product presentation. The use of a scripted demo will also assist vendors in gaining insight into specific operational needs. By formatting client-specific screens, networks, devices and reports, vendors should be much more knowledgeable about the user’s needs. Too often, vendors have concentrated efforts on the development of sales brochures featuring the client’s name in an abstract graphic design, not transactional monitoring.
 
5. Vendors should be informed that finalists who successfully pass the scripted demonstration stage will be invited back for a second product discussion in which the vendor may demonstrate any additional system features the scenarios failed to highlight. A second visit ensures the vendor a more serious and interested audience while providing an opportunity to establish product differentiation and competitive advantage.

Summary
Scripting vendor presentations can be an effective means to control the purchase process while ensuring only qualified applications are considered. Prior to system selection, management should visit installed systems at similar hospitality operations to ensure the operational advantages can be gained. Vendors are usually very cooperative in setting up installed system site visits. Scripted vendor demonstrations are not the end of the purchase process; instead they can bridge system qualification with purchase decision making.

Michael L. Kasavana, Ph.D., CHTP, is NAMA Professor in Hospitality Business, School of Hospitality Business, Michigan State University. He can be reached at kasavana@pilot.msu.edu.