Sales Qualification for SaaS: ask these questions

A truly successful relationship between a customer and a software company starts before a customer has used or even seen the product. A key stage of this journey is the Sales qualification. It has a great impact on the experience a customer will have with your product and it will also influence how various teams work together internally.

By setting up a robust qualification process, you can save a lot of time and effort for your Sales and Customer Success teams on one side and customers on the other. It will allow you to determine early whether the product purchase will result in a successful, mutually beneficial relationship or not. If kept consistent, Sales qualification process will reduce operational friction between Sales and CS teams, allowing everyone to stay aligned and work faster and better.

The purpose of this article is to outline the basics of how to get this right. Below is by no means an expansive qualification process as it will look different for different companies. Instead, I’d like to outline the key criterias for building a Sales Qualification Framework.

SaaS Sales professionals can use these areas in their discovery process with a prospect. Customer Success Managers can validate these points at handover, when they receive a deal from their Sales rep.

Here it is at a glance.

Now let’s dig in.

Customer Problem vs Proven Use Case

Customer Problem is why your product exists in the first place. Everyone in the company should know this very well — this is the reason your founder started the company. He was right about it and that’s why you found the Product Market Fit. Chances are this is written on your office wall somewhere, so look around!

The product Use Cases are different ways of how your software can be used to solve a particular challenge the customer is facing. This should be really easy to qualify. Does the problem a customer is trying to solve match your company’s purpose and mission? Can your product genuinely solve customer’s issue? If so, can it continue to do so in 6–12 months time? If the answer is “not sure” , then you’ll need to seriously validate the use case with the customer and discuss all the “what if’s” before progressing the deal any further.

Question to ask: does our software provide a solution to the customer’s problem?

Customer Outcome vs Value Delivered

Once you have a match between Customer / Problem = Your Software / Solution equation, you need to look closely at specific outcomes. What does a customer want to achieve from using your software? Do they want to generate revenue, or do things faster, cheaper, smarter etc.

Typically, this criteria can be measured by ROI. If they invest in your product, how much would they get back, in what form and how fast? Are they making money? Are they saving money? Are they saving time? Are they making better informed decisions? Where is the value: money, time, or quality?

You’ll need to validate or, even better quantify, their desired outcome into some form of ROI to ensure your software delivers real value for its price.

Question to ask: what is the outcome needed to achieve a real ROI?

Customer Budget vs Product Price

Extracting information around budgets and paying capability from prospects can be challenging. The validity of the answers can be hard to verify too — no matter how big or small the customer is, unlikely they would fully disclose their buying ability to the Sales person. I’ve learnt this from being on a vendor side and a customer’s side. They might have the budget now, but won’t have it in future or it’s not fully approved internally and so on. That’s why establishing ROI and value delivery is so crucial as it will influence the longevity of the deal. Again, it comes down to this simple rule: if the customer has achieved real value from your product, they will continue to pay for it.

Question to ask: can the customer afford our product now and justify paying for it later?

Customer Timeline vs Product Deployment Time

Finally, what’s the timeline that can be achieved on both sides? The customer might ask:

How FAST can you deploy?

How LONG does it take?

These are 2 ways of asking the same question. In the first instance, the customer has real urgency — so you need to ask yourself if you can deliver this their timeline. In the second, they enquire about your normal operation process and see how it suits them. Whichever way you come at it, the alignment and correct expectations need to be set. It’s absolutely crucial to check whether the timeline can be delivered internally as successful onboarding is everything.

I’d argue that aligned timeline is possibly a less weighted qualification criteria as chances are for the right customer and the right price, your team would be willing to go the extra mile to deliver the appropriate onboarding experience. Shifting operation timelines is easy to do in the early days of start-up or even scale up. However, it would become an expensive measure and cause operational issues in a more established SaaS environment.

It’s also worth checking the customer’s readiness for onboarding. I’d be wary of the “buy now / use later” scenarios as that would not set a solid foundation for a successful partnership and healthy engagement.

Question to ask: does the implementation timeline fit the customer’s expectations? Is the customer ready to begin onboarding once the sales process is done?

Final thought:

Sometimes Sales quotas and the pressure from the targets can influence how flexible the qualification process can be. Be very mindful of that tendency, as chances are you’ll still pay the price of letting the bad-fit customer through. It will much likely result in customer churn and low morale internally, so avoid that and stay firm on what you know and believe in.

Know your product. Know your customer.

Get both sides aligned for a mutually beneficial relationship.

Want to chat all things SaaS and Customer Success? Connect with me here