I've been attending a lot of vendor demonstrations on behalf of clients recently. These are in-person demos, typically following a tight script, after a set of vendors has been selected following written proposals. More often than not, the demos don't turn out very well. Sometimes the customer is ill-prepared. But more frequently, the vendor just flubs it. Demos are important for vetting finalists for any proof-of-concept, and customers could really benefit from better ones.

Tony Byrne, Contributor

May 25, 2007

6 Min Read

I've been attending a lot of vendor demonstrations on behalf of clients recently. These are in-person demos, typically following a tight script, after a set of vendors has been down-selected following written proposals. More often than not, the demos don't turn out very well. To be sure, sometimes the customer is ill-prepared. But more frequently, the vendor just flubs it. I think that's avoidable.

As a rule CMS Watch does not give advice to vendors. Moreover, we stress the decisive importance of more advanced, proof-of-concept test phases as the real measure of suitability. But demos are important for vetting finalists for any proof-of-concept, and I've come to believe that customers could really benefit from better ones.So we'll break with tradition and offer ten pieces of advice for you the technology vendor when pitching your wares to prospective customers.

1. Show up early. I'm amazed at how many vendors show up late for demos. Yes, I know the industry is hot and you are busy, but why did you bid at all if you weren't going to treat your customer's time with respect?

2. Find out how many people will be attending, and create hand-outs for everyone. If you are going to give some sort of corporate overview (and we usually recommend that this constitute the first 15-30 minutes of the demo), then bring a printed copy for attendees to take notes. Just make sure to have a copy for everyone. Don't bring long narratives. Bring a summary of your talking points.

3. Figure out the connectivity situation in advance. If you need an Internet connection, find out in advance how it will work (especially if it's wireless), and then test it beforehand (remember, you came early). Otherwise, fiddling with the network drains energy from the beginning of your demo.

4. Invest in a decent laptop. How many times have we heard the Sales Engineer (SE) explain in the face of an inconvenient hourglass, "you see, I have so much running on this little machine..." Well, I have news: the SE who came before you ran through her use cases without a pause. She probably had a better laptop, or one optimized for the environment she was demonstrating. If you want to simulate a server, invest in a laptop that at least tries to act like one.

5. Don't ignore bugs. As every SE will confess, bugs are part of demos, especially when the customer (as we would advise) creates a custom script. If attendees are paying attention as closely as you would like, they will notice even little bugs -- so don't ignore them or bull-shit your way around them. Acknowledge the bug, take a stab at explaining it, and try to fix it at the break. Note to buyers: always schedule a mid-demo break so your team can caucus and the vendor can re-group as necessary.

6. Test your demo that day. Every now and then something goes really, really wrong; there's a conflict with VMWare or a key service won't start up. Then the poor SE is left to exclaim, "but it worked last night in my hotel room!" Your best prevention here is to test your machine and the use-cases just before your demo begins (remember, you came early). 7. Don't argue among yourselves. In my experience, vendors who bring knowledgeable consulting partners or their own professional services staff to a more complex sales engagement tend to perform better than the simple salesperson+SE combo. Of course, orchestrating a team gets tricky. You need to carefully work out roles in advance. Just know that if you haven't figured out the functional, financial, or business division of labor, it will surely come out in the demo. You do yourself and the customer a favor by sorting all that out in advance. You should also assume that any consultant you bring to the table may be specifically requested by the customer in any final contract.

8. Pay attention to what the customer actually requested. Vendors tend to over-expend energy trying to figure out "what the customer really wants." Well, if customer has scripted some use cases, you should assume they have put some good thought into this. I find that vendors often try to circumvent certain difficult scenarios and instead demo what they think is cool or useful. A good script will allow them some extra time to do that, but if it comes at the expense of demonstrating something essential, it can backfire.

Here's what happens. The SE shows some nifty capability outside the scope of the use cases. The customer responds enthusiastically. The sales team leaves thinking they won a great coup. But then later -- always later -- calmer heads prevail and someone reminds their fellow selection team members, "hey, they never showed us X, or Y, or Z!" Suspicions arise and you're not around to allay them. You get zapped. Sometimes this might require you to... 9. ...Stifle the remote blabbermouth. Very often the bidding team needs to rely on a remote specialist patching in by phone and/or Web conference. No problem. But in the absence of visual cues and feedback, this person needs to carefully focus and stay on track. Beware in particular the phoned-in senior vendor executive with an unnatural affection for PowerPointed case studies, or the remote SE who doesn't leave his basement office enough, prattling on about "just one more portlet you have to see," despite drooping heads and snores among the selection team. Of course, sometimes the blabbermouth is the actually present in the room. Here's where the salesperson should earn her commission, even at the expense of violating tenet #7, above.

10. Confirm a list of questions to answer at the end. I've never seen a bidder successfully and fully answer all the customer's questions in one sitting. So someone on your team needs to track open issues for follow-up, confirm them at the end, and indicate a reasonable date for addressing them.

However, vendors should be careful on that last one. There's always the temptation to "park" weak or uncomfortable topics, hoping the customer won't actually ever return to them. Remember, though, that customers frequently want to decide who moves on to the next round immediately after the final vendor demo, while all the screens and faces remain fresh in their minds. If you really care about winning the business, get the right team into the room the first time, because you may not get another chance.

Finally, let's turn the table and look at this from the perspective of the buyer. How should you the customer run your demos? You could start by internalizing the 10 steps above (many of them apply to you as well). For more detailed guides to running a selection process from start to finish, consult one of our technology evaluation reports.

Here's to good communication!I've been attending a lot of vendor demonstrations on behalf of clients recently. These are in-person demos, typically following a tight script, after a set of vendors has been selected following written proposals. More often than not, the demos don't turn out very well. Sometimes the customer is ill-prepared. But more frequently, the vendor just flubs it. Demos are important for vetting finalists for any proof-of-concept, and customers could really benefit from better ones.

About the Author(s)

Tony Byrne

Contributor

Tony Byrne is the president of research firm Real Story Group and a 20-year technology industry veteran. In 2001, Tony founded CMS Watch as a vendor-independent analyst firm that evaluates content technologies and publishes research comparing different solutions. Over time, CMS Watch evolved into a multichannel research and advisory organization, spinning off similar product evaluation research in areas such as enterprise collaboration and social software. In 2010, CMS Watch became the Real Story Group, which focuses primarily on research on enterprise collaboration software, SharePoint, and Web content management.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights