SaaS Customer Life cycle - Pre-sales

Let me start by saying sales is certainly not my area of expertise. I couldn't do what sales does. I couldn't convert a lead to a prospect if my job depended on it, and I am certainly not the person who is going to come in and make sure a deal is closed.

I have spent plenty of time doing pre-sales support, and that is what I will focus on in this post.

I am going to state what seems like it should be obvious:

The sales team should understand what SaaS means. The sales team should be able to not only understand what it means but also how to communicate the value proposition to prospective clients, at least at a high level.

The technical sales support is crucial. Enterprise clients are becoming increasingly familiar with SaaS. This increase in familiarity is both good and bad. The good news is that as the SaaS delivery method matures prospects are not in the situation of needing to be convinced SaaS is valuable or viable. The bad news is that the types of questions that you are likely to face seem to be more focused.

Any technical pre-sales support should be ready to explain basic architecture (both network and application) as well as security and privacy issues. It would be helpful to be able to explain how the upgrade or migration process works once a client is up and running. This may go hand in hand with questions about product road map and the methodology your organization uses to develop and share that road map.

A mature SaaS organization can use the pre-sales period to distance themselves from less mature competition. This can be a significant differentiation point. An important part of Software as a Service is the service part. If an organization has an advantage in that area it should be something that prospects understand.

This period is also the time to set expectations with a prospect. This can make all the difference for the relationship and the teams that follow after signature.

Things to be clear about during the sales cycle should include implementations (how long, what is required from client, cost, etc) as well as how migrations or upgrades will work moving forward.

Any ambiguities about implementation and/or future upgrades will likely lead to incorrect expectations. This can damage a relationship right from the start if there are significant relationship challenges around deployment.

If both of these issues can be clearly communicated and expectations set correctly then the relationship has a much better chance of turning into a positive long term relationship.