I must say that Jim Holincheck wrote a quite persuasive piece a couple months ago on why vendor scripted demos will go away. In today’s environment of SaaS applications, it’s so much easier for organizations to set up sandboxes for potential customers to play around in rather than the old model where client server applications forced vendors to show prospects the tools in a demo environment. (wonderful analogy to follow by the way…)
Consider the following scenario. Let’s say you were going to buy a car and you were unsure which car to buy. Maybe there are three or four that are in the size and price range you want (your short list, if you will). You would likely go to dealers for each car and do a test drive. You would get behind the wheel and drive the car and get a feel for how it operates and what you like and do not like (or would like to change depending on the options) about the car.
Now, let’s think about it how it would work if a car test drive was like selecting business applications. In this case, you would have the car salesperson drive (demo) the car for you while you sat in the passenger seat and asked questions. You could have each car salesperson drive the car along the same route (scripted scenarios) to see how each car handles the course you have outlined. You would be able to compare “apples to apples” and probably gain some insight into what differentiates each car in terms of the driving experience. However, you would not really know how well the car you select drives until you actually buy it and drive it home from the lot. ((Holincheck, Jim, December 10, 2009. “The End of the Scripted Demo Era.” Retrieved from http://blogerp.typepad.com/ on December 24, 2009.))
But as is my way, I’m going to play devil’s advocate, and honestly I’m persuaded by my own argument. Giving up the control to the demo is just too risky for an application vendor. The main purpose of the vendor demo is no longer to evaluate feature functionality. Most vendors that get short listed are going to be able to meet 90% of the feature functionality that any customer needs. The remaining 10% is customization, workaround, or just called a loss. It almost does not matter what the feature functionality is anymore, we’ve gotten over the functionality battles and are now in the usability battles. The new purpose of the demo is that potential clients get to see the overall usability of the system and how end user employees and managers would interact with it.
Here is why the pre-contract sandbox is risky. When you put an application in the hands of HR for evaluation, the entire tone of the evaluation shifts. Now, HR practitioners and evaluators are sitting around looking at feature functionality. And they are looking at it with the lens of what breaks and goes wrong without having the vendor SC sitting there telling them how it works or what other clients have done as a workaround. Top it off with the thought that the SaaS system is not sufficiently configured to run through the potential customer’s use cases, and you have functional and process failures galore.
I hate to say it, but I think the proper IT resources get the fact that a sandbox is just a sandbox. But your core HR practitioners don’t have the same application experience and can’t remove themselves from the core of their day to day functional activities. I’ll echo a couple of Jim’s last words in his post: “Am I way off base?”