How can you handle difficult questions during an enterprise software demo?

Always with honesty and integrity. Good questions - especially tricky ones - come from a desire to understand the platform better, which is almost always a positive sign. Any untruths in your response - even little ones - will come out in the wash and can derail your proposal completely. If you don't know the answer, own it, and make a promise to find out and get back to them as soon as you are able. And most importantly? Make sure you do get back to them with the answer.

One of the main things to do before going to a demo, that at least works for me, is to prepare it beforehand, not just the product/tech/service demo, but also the pitch, the storytelling and the analysis of the audience. I usually check the background of the attendees and the role within the company, this will give you a better insight of which point they are going to be interested in and which question they are likely to ask; with this you can tailor the presentation to focus on the topics that you know they might be interest in, and also prepare the answers for some of the questions that may rise thus prevent any difficult moment.

As a technical founder, one of the most important elements of a demo that I had to learn was narrative. It's tempting and easier to walk through your technical capabilities and showcase them one their own. However, to truly communicate value, you must weave the features of your demo into a story to which the audience can relate. Pick a use case you know the audience needs, create characters and circumstances to illustrate how your product intersects this use case on a human level, create mock data beforehand specific to the audience, and then tell that story as you click through your solution.

"I'll get back to you" usually shows lack of prep & understanding of your customer’s challenges. They'll see right through the facade of fancy terms & vague answers. Here's what worked for me: 1. Research & understand the challenges that led them to your solution. 2. Know the priorities & inhibitions of each stakeholder (e.g. IT, Biz) wrt to your product/soln. 3. Correlate your response to #1 and #2. 4. If you know it partially, answer that first with relevant examples & case studies. 5. Use a follow-up session or email to respond to the remainder of the question along with your thank you note. 6. Never claim anything that your soln doesn't have. Honesty is key to building trust with your customers. Good luck for your next one!

Too often people demo what they think will work or try to show everything the product can do. While doing your research beforehand is important to speak the customer’s language, it’s far from enough. You need to spend time with the customer before any show and tell. Just because you have an industry related solution doesn’t mean I have a need for it. Don’t guess. I used to do this a lot when I sold enterprise software. It was always a rush to build a custom demo so a lot was built on assumptions. As an exec now, I just want to chat about what you have, tell you my problems, see if you have a good solution, and get a good price relative to the value. Don’t sell, just cut to the chase and help me.

I've come to realize that the best way to answer a difficult question is to empathize for a minute and get to the heart of what the question is trying to achieve. I've found that 50% of the time, a difficult question is actually a misunderstanding or a pre-existing assumption that can be addressed in the moment. By spending a few moments to dig deeper, you can identify unique requirements and put yourself in a position to come back to the table with the best response, even if you need to pull in an expert.

Before answering a question it is critical to understand the root of the question and clarity on what the question really is. Sometimes it is an assumption about how your software works based on prior experience with a limitation. I always recommend answering questions with questions to make sure the ask is fully understood and you are answering the question in the correct context.

When faced with difficult questions, the first thing to do is to realize it’s an opportunity to: - Ask further questions to better understand the why those issues are important to the customer - Further engage with the customer via follow-ups if you don’t know the answer right away - Build trust by honestly answering the question on what the solution can or can not do and offering to bring that back to your product team (using that as an opportunity to maybe invite them to your Customer Council or participating in a VoC program) Above all, this is an opportunity to show that you care deeply about the customer’s needs and that you want to better understand and address them even if that means acknowledging some current gaps in your solution.

The human brain is quite primitive and when we get asked something we think we should know the answer too, the fight or flight response is often triggered, this takes resources like Oxygen and Glucose from the very part of our brain that we need to "manage emotions" and "perform logical thinking and make decisions" so its useful to be aware of what your brain will do when those questions hit you. Understanding your own behaviour and the way our brains are wired is a great way to avoid any awkwardness. Breath and as others have mentioned already, take your time, the question may have been asked to test you but you can, with a calm, centred mind turn that into a positive.

They key is to realise that you do not have to respond immediately. Ask questions to clarify and to know why that question was asked. Once there is clarity, it will be easier to respond.

I think there are two very different approaches to answering hard questions in any sales setting. The first is to bluster and posture and try to put a positive spin on everything; and the second is to just be brutally honest. I always favor the second approach, because the sales cycle is not the last time that you are going to deal with these people. If you are successful in selling them your stuff, you have now kicked off a relationship that is going to last for years. And over those years, things are going to happen. Bugs. Security issues. Disagreements about product roadmap. You want to get that relationship started on the right foot, and that start happens during the sales cycle. So my view is always to be up front and honest.

Several times I addressed disbelief in our product with illustrative cases from our experience. For example, "Could your system process 1 million trades in an hour?" is better addressed with "We never confronted such a high load and will be excited to face it. Our peak load was 200K trades, which we processed in 10 minutes." than with a basic "Yes, of course". Being honest and detailed immediately builds trust with your audience.

Three words: feel - felt - found. One of our old Swiss Army knives for answering difficult questions. Start by empathizing with the question, saying you understand why they feel that doubt, why it is important. The key then is to share a story from another customer who faced the same dilemma, and how they approached their decision making. Then close with the findings of that customer story - their decision and the outcomes they’ve seen since choosing to move forward with your solution.

If you can’t be honest about what the software can and can’t do, you should not be selling it. Before answering any questions, make sure you understand the why and then you can address the how. Because, in a lot of situations they are only asking because that is how they have always done it. Provide clear benefits to any other approach you offer, but don’t ever claim your software can do what it cant..

Always be honest. Find out about the problem they want to solve as sometimes there may be a different way to achieve the same thing. Sometimes they may be using the language of a competitor so keep focusing on the problem and how to solve it as opposed to the features. I often like to say"Good question, may I ask why did you ask it?" Really get to the bottom of it.

I would personally change this point to: Reframe, Refocus & Redirect. In my sales experience where we need to present Demo's to client, usually there is a thin line between "Good to have" & "Need to have". It is imperative that the Salesperson understand the question and reframe it accordingly. It is true that all features and specs cannot be delivered by a single product. Every B2B solutions has its limitation and there is a logical reason behind it. In similar sense, every product has its own USP; We should be able to present this a solution to his requirements.

Once in a while we all get questions during demo which can move us from agenda. Best way is to politely move ahead , offering alternative explanations like we will cover it in another type of meeting , or we have a document or web link explaining this in great length or we can send you a customer case study etc. Customers will also appreciate, specially the senior stakeholders on how you manage the distractions and focus on solving the real pain.

Sometimes you will need to bring the discussions or demo back to the point where you were. If you go into too many tangents and start bragging about your solution you will lose valuable time and might not be able to talk about crucial features, functions or benefits. Don’t let difficult questions lead you to dead ends discussing not that important things.

There will always be detractors in an audience of any size. The guy who is mad cause he likes the other stuff or wants the status quo. They will always throw those questions at you solely to derail you. In fact your competitors may have given them the questions to ask. Best way I have found to handle is to acknowledge how smart they are “that’s a great question” then I throw out the old “to answer this to the level I know you would appreciate, let’s setup a follow up meeting where we can really dive into that together.” 95% of the time it shuts it down.

Preparation with your sales and engineering team, providing a detailed demo criteria and proof of value can assist you with keeping the demo plan in sync, even when questions arise that may take you off course momentarily.

There will be questions that you cannot answer. Definitely admit when you don't know it. We can't know everything. Just organise a time to come back with a response, and then follow it up.

This will create credibility with the prospect as no one will have all the answers irrespective of how well prepared you are. Always leave room for follow up and scheduling a confirmed meeting time to give the response to the question posed. It also allows you to ask additional clarifying questions to support your understanding of the company's requirements.

When you have an unanticipated question, please try to understand the use case or business scenario in more detail, the frequency of such occurrence and its business impact. It will help build more usable software and greatly help the testing team in real-world scenarios.

Certainly you need to be truthful and not behave like you know it all. If you bluff, the other person is most likely to catch it as they are fully aware about the topic they have questioned you on and it will just show your ignorance. Also it does not give a good impression and may reflect as these people just don't seem to understand and are so keen to answer everything, even if they are not aware. This may create a negative impact. People are more than happy to explain their requirement / question in case you have not understood it or talk to someone else who can address it. This gives them confidence on their own ability and they feel good about teaching someone about their business needs, which they often feel are very specific.

Truth is always the best policy, nobody can know everything all of the time, if you don't know the answer, say it, you will earn a lot more respect by taking the point down, going away and clarifying it and coming back with a confident response rather than trying to fluff it on the spot and potentially being caught out.

Always be truthful. Don't oversell and don't undersell. Provide examples/demos. If you don't know let the requestor know you will follow up, then deliver on your commitment.

Have faith in your product, admit any shortcomings, align with the problem statement, refrain from generic demos unless essential. Inquire about the problem statement, constraints, and software coexistence. Align with a business case and understand your audience's needs.

The real key is to meet with customer prior to actual demo to identify the key business drivers. Let them drive what they want to address in the demo. This will help you avoid some difficult questions. In the event one comes up, I have found being up front and honest is the best approach. This may also provide an opportunity to meet again or at least follow up to address.

If you hear your own voices and not that of the customer throughout the meeting, it’s possible to miss the mark as it is then “your story” not theirs. Ensuring pauses and feedback allows us to align or course correct to include the customer in this important part of the journey. Most importantly, seek out those not talking or taking notes, they may be the deciding factor. I’ve learned over the years, every person at the table is important, titles are just that. Key decisions are influenced by the users and leaders of team not just the highest ranking person in the room. Bring them all with you …. You’ll be richly rewarded with partnerships wide and deep.

Be a doctor, invite them in, have your certificates on the wall, then simply ask "where does it hurt and what does good feel like?". Your account management team or you should've established the relationship, the demo is there to 'narrate' what better looks like and how to get there.