In the past two decades the licensing business model clearly gained a lot in popularity and became the standard way to do business in the B2B world.
There are now more software-as-a-service (SaaS) companies than ever before, be it in HR, marketing, finance, project management, you name it.
Major companies shifted from legacy products generating perpetual revenue to cloud hosted solutions generating recurring revenue (think Pack Office, Sage, Adobe).
It has become so popular that large corporations can use up to 250 different SaaS, and sometimes even more.
The rapid growth in SaaS adoption by big corporations brought some issues along the way.
Firstly, a visibility problem, each business unit or department has its own SaaS and it is difficult for the IT administration of your company to know whether all the licenses the company is paying for are used to their maximum.
Secondly, as access management is often managed within the SaaS, there are lots of shadow licenses, meaning employees that left the company but are still able to access the company’s resources as their access has not been removed. This causes major security threats and is also a waste of money for the company.
Fortunately, over the past few years, SaaS governance companies like Beamy emerged, allowing companies to track all the SaaS they are using, to improve budget allocation and security.
As a founder, your SaaS solution is usually firstly used by a small group of tech savvy early adopters, that allows you to have feedback and iterate on your product.
Hopefully, your users love using your app, and you start having product market fit.
Thanks to word of mouth and sales efforts, you are then starting to have a few paying customers that allow you to fundraise, hire great talents and consolidate your product.
At some point, your product becomes robust enough that it might convince bigger, and Enterprise clients to buy it.
Everything is awesome and so simple, right?
In reality, crossing this border from early adopters to Enterprise customers is no easy task.
In this article we are going to cover why you should do it, what makes crossing this border difficult, and how you can prepare your app to be ready to be sold to Enterprise clients.
Why should you sell to Enterprise clients?
There are many reasons why you should make selling to large companies a priority:
- Product differentiation: building an Enterprise version of your software will enable you to cover more needs and to have a new competitive edge regarding competitors on the market. As your software covers more needs, you will also increase your total addressable markets and the barriers to entry will be higher.
In a global market where more and more SaaS are created each day with similar value propositions, being able to meet the requirements of large corporations will allow you to have a more complete product to be chosen over your competitors’.
- Less churn: Being a SaaS company the churn is one of the key metrics you need to track. Too much churn will eventually kill your SaaS company.
Enterprise customers are less likely to churn and have much better net dollar retention. Once they sign with a particular SaaS vendor, they are much less likely to switch of solution in the future.
- Faster revenue growth: Enterprise deals are much bigger contracts and this will allow you to lengthen your runway, to be cash flow positive quicker, and less dependent on VCs capital.
If you are not ready fast enough to sign Enterprise deals, you will basically educate and evangelize the whole market with an innovative product, but a competitor can appear on the market and capture the lucrative Enterprise segment.
You have done all the work that has made it possible (think Slack vs. Microsoft Teams) but a competitor is getting free lunch.
What makes it hard?
Selling to Enterprise clients is much different than selling to SMBs. Let’s discover the main key challenges you will face when selling to large accounts:
- Longer sales cycles: building an Enterprise feature will likely require your company to do some research with your client to make sure that what you will build corresponds to their needs. This time is likely not invoiced and this feature might be a one-off. SMBs have a buying decision much quicker than enterprises where several individuals are usually involved in the buying process.
- Time consuming: Enterprise features take a lot of time to build. However, they are not part of the core value proposition of your business and fill your developers’ roadmap. This contributes to reducing your runway and increasing your CAC. If you have only a year of runway in front of you, maybe the best idea is not to build this type of feature.
- Developers would rather code something else: Usually when building Enterprise features your developers will have to deal with legacy technology and not the latest technologies that they love.
Enterprise features will also likely be back-end meaning that users won’t be able to see it, it will mainly be seen by your client’s IT Admin. Therefore it may be complicated for your team to stay focused working on old techs for several months (and sometimes much more as maintenance will be needed too).
- Bugs: your Enterprise client will likely require a lot of small details and customization, that will increase the area for bugs therefore maintenance costs.
- Your buyer is no longer the user: selling to Enterprise is basically a shift of paradigm in which the buyer of your solution is no longer the end user (it is now maybe the CISO or the CTO, and this person likely does not care about how good your application looks).
In addition to the above, Enterprise clients typically have several persons involved in the buying decision, with well defined (and slow) buying processes, and are more looking for a long-term fit rather than quick results (unlike SMBs).
How to sell to Enterprise clients?
As we have just seen, by moving upmarket the buyer (which is now the CISO or the CTO) of your solution is no longer the user.
You will have a new mindset that you will have to deal with, and new objections that you and your sales will need to cover.
So what do you need to do to get the approval of this new category of buyer?
CISOs or CTOs generally have the same type of requirements, that is:
- Visibility on your app: one way to give your client’s IT Admin visibility on what is happening within your app is to provide them with audit logs.
Audit logs are basically all the events that are happening in your app: user.created, user.updated, group.removed, user.login_success and so on.
These audit logs are useful for compliance and legal purposes.
- Control: to allow them to have control over what happens on your software, you will need to allow log-ins on your SaaS with the credentials of their Identity Provider (IdP), in other words, single sign-on connection (SSO). The major benefits of allowing SSO connection on your SaaS is that you won’t have to manage a “strong passwords” system or to develop a 2FA authentication system, all the authentication is managed by the SSO provider of your client.
Another way to give control to the IT Admins is to use SCIM (Directory Sync), which allows for automating provisioning and deprovisioning and automatic attributes update (name, phone number, department, etc.).
Let’s say that you are selling an HR software to a big company, if 20 people of the HR department leave the company, as soon as they are deprovisioned in the Azure AD (or Okta, Ping Identity, etc.) of your customer, they will not be able to access your HR software anymore.
IT Admins love this as they will have less shadow licenses (greater security and no money wasted), and it is much more convenient than having to remove each user in each software individually.
- Trust: as every human, CISOs and CTOs need trust to do business with someone. Trust comes in various forms and shapes, of course, but here are a few things to put the odds on your side.
Firstly, they need to be sure that you will answer them promptly when they have a question regarding the functioning of your product (via Slack, like we do at Cryptr with cryptr_community, or via videoconference).
Secondly, they also need to know that you are managing their data in a secure way.
That can mean general technical and organizational measures or/and more standards compliance certifications like ISO27001, SOC2, GDPR. Pen tests are greatly appreciated too.
Finally, they need to trust that your business won’t go down, especially if the task you are performing for them is sensitive: you might need to offer an SLA.
If you are selling an API product, you need to have up-to-date documentation about how your API works and a sandbox mode to allow your client to run tests on his own.
Of course it takes more than this to fully fulfill all the expectations of large accounts, you could also add analytics on the usage of your app (solutions like Cumul.io), a proper invoicing process, integrations (APIs) and so on.
Enterprise sales are challenging as they take time and involve several interlocutors.
However, if you are ready soon enough to sell to them, you will be able to 10x your revenues compared to your self-service application.
Being SSO ready is a good way to start as it will enable you to expand your market quicker and start selling to Enterprise customers by meeting their security requirements.
Moreover, it is a feature that you can upsell (companies like Asana, GitHub or Dropbox typically upsell the SSO connection) as large corporations are ready to pay for this pledge of security, and it enables you to focus on product development to ship exciting features quicker, rather than reinventing the wheel.
The good news is that there is a simple way to be SSO ready: right here, at Cryptr. And don't forget to follow our latest news on Twitter and LinkedIn!
And to chat with our teams, you can book the slot of your choice by clicking here: Meet Cryptr