How to Build an Effective Demo Script

Enterprise software buyers give up much of their buying power the moment they let a vendor run a product demo. Why? Because allowed to do so, a vendor will demonstrate only the cool-bang features they want you to see and quietly sidestep their GUI gaffs they’d rather you not know about.

The purpose of a demo is not to prove that a vendor solution has certain features; that’s what your Requirements List should do. Instead, it’s to show how the solution performs your most frequently repeated tasks and how those tasks sequence together into your most frequently repeated business processes.

It’s the operational efficiencies you’ll gain in this sweet spot that will justify the expense and disruption of a new solution. While you don’t want to ignore less frequently performed tasks, users will typically tolerate greater solution complexity if it’s for something they don’t have to do very often.

So how do you build an effective functional demo script that gives you full control of what you’ll be seeing? Here are my Top 7 recommendations:

1.      Separate technical, functional and business discussions. This shows respect to your various stakeholders, keeps everyone awake and the demo on track.

2.      Give your vendor and team time to prepare. You are asking the vendor to prepare a custom software demo, so give him your script several days in advance. Also share the script with demo attendees so that everyone is aligned with the meeting’s objectives. You should plan on spending some time talking to your vendor while he prepares, to go over any points that need clarification, time available, list of attendees, etc. Set up your vendor to win: the better prepared and more professional his delivery, the better your team’s time is spent.

3.      Start with a high-level overview of the application. Include a navigational overview as a point of reference the vendor can go back to in case users lose context during the demo. Be sure the vendor also briefly explains the solution’s competitive positioning and target market.

4.      Organize features around the top few business processes the solution is expected to optimize. Insist that features are shown in sequence as they would actually be performed in your operation. You are looking for seamless segways from one task to the next, not just the ability to complete each task. Do this well and you will greatly increase user acceptance later on.

5.      Defer user-specific or very detailed questions to the end of the demo. Demo at an even level of depth into the application for each business process. This will help prevent users from getting lost in detail and keep the demo on schedule, while still ensuring everyone’s questions are answered.

6.      End the demo with a discussion of the product’s roadmap and release history. A solution that falls short of your expectations in social networking features may not be a good match if the vendor is planning to spend the next year on a migration to .NET. Similarly, a company culture focused on rapid development techniques may never be satisfied with a vendor that releases product updates only twice a year.

7.      Get feedback from attendees within 48 hours. Use the demo script itself as a starting point for a quick and painless feedback questionnaire. If you present questions in the same sequence as the demo was given, allow attendees to rate each conversation point or feature on a scale of 1-5 and make comments optional, you will very likely receive a high response rate from attendees and high quality feedback.