So, you’re the guy/gal who’s been put to the task of choosing your companies next enterprise software solution? Well, if you’re reading this, you’re most probably well on your way to choosing that software by now. You’ve made your proposal to your stakeholders; you’ve gathered your requirements and prioritized them; you’ve gotten a handful of software vendors to complete your RFI. So now what? Well, there’s still one very important step that needs to be taken: seeing the shortlisted products in action!
There are five important steps to successfully conducting and rating on-site software demos.
1. It’s All in the Script: Developing a Demo Script
2. Requesting a Product Demonstration
3. Inviting Vendors On-site to Show Them Your Environment
4. The Demo: Lights, Camera, Action!
5. Rating the Demonstration, the Vendor, and the Product
General Information about On-site Demos
The on-site software demo is the ultimate opportunity for vendors to demonstrate the capabilities of their product(s) to potential clients—and let’s face it; one of the last things they’ll do to either make or break the deal (apart from the pricing proposal). A demo gives perspective software buyers—like you—a chance to see if your impression of what the vendor says it provides will hold true to its claims—and if the reality of those claims will be satisfactory for the needs you’ve outlined.
Vendors will demonstrate real-life scripted scenarios as described in your demonstration script and are usually presented over a span of several days (usually half a day to one full day per vendor).
#1 It’s All in the Script: Developing a Demo Script
Every great performance starts with a great script. A scripted demonstration is an essential part of your selection process, and providing vendors with your own unique demonstration script will help ensure that the vendor addresses every factor that is important to you, including
The demo script should cover the following areas:
If you request a demonstration but do not provide a script to follow, there’s no guarantee that the vendors will show you parallel functionality to compare. They may show you what they think are the most impressive features—which don’t necessarily cover the requirements that are most important to you. Ultimately, the demo script should be designed in such a way that enables vendors to show you how the software will increase your organization’s performance—in some visual and measurable way.
The script should be presented to only the top two or three vendors on your shortlist. Too many product demonstrations can lead to confusion—and leave your software selection team wondering which vendor had which features.
In order to give each vendor equal opportunity at the demonstration stage, it’s important to provide every vendor with the same detailed demonstration script. The script should be given to them at least 2 weeks prior to their scheduled demonstration date. This will allow them more than enough time to prepare.
Professionally written demonstration scripts can also be purchased online. They cover a variety of software systems and often focus on industry specific solutions. They provide an apples-to-apples comparison of criteria, which ensures consistency. A scoring system is already defined for you, which can save you time during the rating process.
#2 Requesting a Product Demonstration
To ensure the product demo goes as smoothly as possible, you’ll want to be sure that the shortlist of vendors are informed well in advance. The way to do is by
Each vendor will be given the opportunity to clarify any terms that might seem ambiguous, or examples of business rules with your selection team prior to the demonstration.
Your selection team should not ask the vendor to customize the software any more than is necessary to demonstrate the real-life situations described in your scripted scenarios. However, to limit follow-up questions and subsequent demonstrations, each vendor should be encouraged to demonstrate all the items that you have listed.
#3 Inviting Vendors On-site to Show Them Your Environment
While it’s important for your company to see what a vendor’s product can do, it’s equally important for the vendor to know what type of environment it will be working with—if its software is chosen. Inviting vendors on-site to see your environment will give them a better understanding of what to prepare for the demo, as well as enable them to provide you with a more accurate proposal at the end.
This will also be the opportunity for the vendor to ask you specific questions about your current system, as well as the functional areas of the company. Having key staff present during these visits is recommended (thus, you may want to include staff from your IT department). Your public relations (PR) staff may also want to arrange a tour of the facilities so that the vendor can meet with the key users who will actually be using the system.
You have provided them with your demonstration script, and you’ve allowed them to see your environment. Now it’s up to them to wow you!
#4 The Demo: Lights, Camera, Action!
It’s show time! The time for the vendors to make their product(s) shine. Vendors often have very different ways of conducting their product demos. Some design theirs using PowerPoint slides with lots of bullet points and fancy fly-ins. They’ll often start by going over their company’s details, strategies, and future goals. Then, they’ll move on to discussing specific problems companies—like yours—may be having, and finally they’ll show you how their software can solve them all. Right!
This, my friend, is not a product demo. It’s a marketing piece—and it’s not showing you much of anything!
You shouldn’t have to endure a software demo. It should be conducted by the vendor in a way that makes it exciting for the audience. Using real data (preferably yours)—along with your demo script, the vendor must walk you through the demo like a finely crafted play. They’ll show you some fluff (they always do!), as well as a few of the cool and unique features. However, it’s important that they stick to your script. You’re the director, and they’re the actors—with a fine support cast (and a big bag of props!).
Crashes during the demo should be unacceptable. Think about it; if the software doesn’t work well in a demo environment, how’s it going to work in your real life environment? There may be a good reason why something went wrong during a demo; so don’t be afraid to ask.
You’ve put a lot of time and money into your software selection project already, so make sure that your selection team sees everything they need to during the on-site demo, in order to help you make an informed decision.
# 5 Rating the Demonstration, the Vendor, and the Product
Each person from your software selection team attending the on-site demo should participate in scoring the vendor’s scripted performance—for each factor demonstrated.
Breaking down the vendor’s demonstration into different sections (each of which represents a percentage of the overall evaluation score) will facilitate the scoring process.
The bidders are evaluated based on product functionality, ease of use, and process fit.
Product Functionality
The product functionality section is a list of features and functions for which the selection team would like a detailed product demonstration. Over and above these features and functions, vendors should provide a detailed description of the hardware, software, and networking configuration used during the demonstration.
Vendors should also provide a statement regarding the amount of effort and skills required to set up the demo as presented. Each member of the selection team should score the vendors’ script execution performance for each factor demonstrated. This can be done using a rating scale.
Sample rating scale

Ease of Use
For each process demonstrated, the selection team must rate the user friendliness of the software product.
Process Fit
Members of the selection team will rate the way they see the process demonstrated according to how it fits their business processes and whether that can be considered an improvement or not.
After all the demonstrations are completed, the scores from all members of the selection team will be consolidated as a single score for the performance of each vendor.
Conclusion
So, was it all that it was cracked up to be? Did the vendor’s performance and its product blow you away; or did they fail miserably? The fate of this sales opportunity now lies in the hands of you and your software selection team. Given all the information you have received from the vendor until now, including their RFI responses and the demo, are you confident that you can make a better informed decision about the software you want and need?
FYI
Great Article
F.Y.I.
Do you not think that all the above comparisons can be done with a sim^ple spreadsheet, and only requires fewer then 25 essential requirements for the client?
I say essential, because today every ERP vendor has the mature sales, finance, accounting, HR, and manufacturing facilites software.
Again, my view is that vendor comparison exercise should amount to comparing fewer then 100 items, including the 25 essential specific to the business requirements.
I certainly agree with the script and the fact that the software guys need to WOW the prospect. I would also add a criteria I call “Ideal customer” which means :-
1. can the vendor and customer work together
2. what other customers does the vendor have and what industries are they in
3. Do you like the vendors staff
I always use a 3-pronged rating system: Functionality; Technology; and Vendor Viability.
Functionality: how well does the app meet our required capabilities? (which is what the author describes).
Technology: how will the app fit into our physical environment? how is it architected?
Vendor Stability: partnership & financial viability.
I typically focus on about 20-25 items in each category, and I have a canned list of questions/attributes that I start my investigation with.
For the first elimination round I might use a rating scale of 1-3; then in the finalist pool the more granular 1-5.
For a tool, Excel rocks.
The division of duties for the discovery process is typically business and architecture for function; architecture for technology; and procurement/contracts for vendor viability. Smaller organizations would obviously combine these.
This is an excellent article. Can the person who entered a comment named “Barb” please contact me? I would like to discuss the spreadsheet you have and wonder if you would share it with me? Thank you!
Barb - email is pat.mcdougall@crhs.net Thx
Great info- Please rate our new software; eProposal.
eProposal is a Flex based tool that allows you to create custom business proposals quickly and easily. eProposal is the flagship application of eIntelli, currently in beta. To view the application, login to eintelli.com/eproposal for a free 3 month trial.
I totally agree that having a scripted demo with associated sample data where software solutions and vendors can be compared in a quantitative, apples-to-apples manner is a critical element to successful software selection. Without this, software selection will turn into a beauty contest.