Stop the Blame. Remember the Goal. Be Part of the Solution.
Marty Caise, Jr.
IT Professional and Fiction Author who is always looking for a challenge
I recently read a post by Scott Taschler from McAfee about Sales Engineers and The Demo Blame Game (https://www.dhirubhai.net/pulse/sales-engineer-confessions-demo-blame-game-scott-taschler). While I would admit there are always circumstances that can impact a demo, and as a Sales Engineer, we should always be prepared for different circumstances - whether technical or non-technical, Scott’s viewpoints tend to focus on the negative and where to point the blame. The implication that SE’s tend to deceive customers is - in my opinion - not a fair assessment. Bad SE’s fall into this category, but not all of them.
As a former SE who conducted numerous demonstrations, my approach to handling technical issues is a little bit different.
I completely agree with Scott that SE’s should be prepared. That includes all the information available about the audience in advance. This is generally delivered by the Sales Manager. If it is not, then the first few minutes of the demo is spent gathering this information. The more information an SE has, the better he/she can prepare and even rehearse the key points of interest the customer wants to see.
Next, I tend to give the audience a little more credit when it comes to remote demonstrations. Customers are smart and understand that sometimes things go wrong. Blaming the issue on aspects like the network or the software can give the customer a negative perception of not only you as the technical expert, but also the company you represent. It is important to note something I learned a long time ago when I moved into the sales industry…
Sales and System Engineers are the only “human” component of the sales cycle that can LOSE credibility.
Sales Managers/ Professionals can make mistakes in how they describe features of a product because they are not the technical experts. Customers recognize this, which is why they are more willing to discuss the technical aspects with an SE during a demonstration.
But if an SE makes a mistake (whether by accident or intentionally) – a customer will become confused and may not feel important because they didn’t get the best the company had to offer.
SE’s are the technical expert of every opportunity, but even we have to look up information based on how the question/ request is asked. The important take away here is SE’s don’t have to have ALL of the information stored in their head, but they do need to know where to go find it. Customers are smart and some are patient enough to accept the SE's response to a question that requires the additional research….
“I understand the question and I would like to make sure I get you all the detailed information, so I will pull that up after the call and send it to you.”
Getting back to technical issues during the demonstration; we should consider this and be prepared as Scott mentions. Demonstration environments change everyday… even when they are not in use. The computer clocks on the VM’s can impact your demos (Patch Tuesday, Full Scan Friday, 90 day Password Changes). While we generally adjust these items in our demonstration environment, we can sometimes take some of these issues for granted or downplay their possible impact on a demo, but they are not major issues and we can adjust to them quickly.
A solid engineer can multitask and work on correcting the problem quickly while maintaining a solid dialog with the customer, so they stay focused on the call. The sale is not 100% linked to the technical demonstration – but the SE can be. It should be known that building the relationship and learning everything pertinent to the customer’s environment can be beneficial in recommending the right solution for the customer. When the customer hears the “blame game” as Scott described, it can turn off the customer.
Speaking from experience as a customer, I have seen where an engineer could not deliver on the scheduled demo and blamed all the controllable aspects (the network, the virtual machines, and yes… even the software he was trying to sell). There was no conversation while he was trying to correct the problem and we eventually ended the call and it was to be rescheduled.
I have also seen where an SE was impacted by an outage and adjusted perfectly while he attempted to fix the problem. He continued through the discovery conversation learning more about my environment and where his solutions would fit in the environment. Even when the problem was unable to be corrected, he did not make any excuses. He simply apologized for the inconvenience and immediately attempted to reschedule the demonstration. But the call did not end there…
He made sure I had all the necessary technical literature I needed to further my education on the product solution and even asked about the possibility of setting up a proof of concept where he could re-deliver the demonstration during the POC implementation – in essence killing two birds with one stone. Not once did he blame anyone or anything for the issue and took the responsibility head on while remaining calm throughout and making sure I still had his attention.
This type of attitude shows a level of professionalism that solid SE's have. This professionalism is noticed by customers and builds a bond between the customer and the SE. When the bond is established, the customer is willing to continue to work with and rely on the SE long after the sale.
SE’s are the most valuable tool in the technical sales toolbox. "Polish" them with education and communication and they will perform at peak levels for a long time. Allow them to be technical experts while you focus on your role in the sales cycle. Taking time away from the demo can impact the demo call itself. Remember when an SE schedules a demonstration, the duration they choose is not just to demonstrate aspects the customer needs to see, the time also includes the POSSIBILITY that something can go wrong.
Thanks Scott for giving us something to think about.
Senior Sales Engineer at Armis
7 年Great points Marty!