Large Enterprises behave very differently from SMBs and Startups. The way they operate, the way they measure product value, the way they purchase — all are quite different from how smaller companies work. Therefore, the way products are built for Large Enterprises is also different. Every Enterprise SaaS Founder should know this clearly.
I recently wrote about how startups can sell their products to Large Enterprises. In this post, I will focus on the other side of the story — how to build products for Large Enterprises?
When selling to a Large Enterprise client, there are typically 6 different buyers:
- Business
- Information Technology
- Information Security
- Legal
- Compliance
- Procurement
The “Product” you offer them would not only be the Software but also what comes along with it. For instance, things like a Service Level Agreement, or a SOC2 Compliance — would be a part of your “Product”. Because there are several “buyers” within the Enterprise, your product must solve the problem for each of them.
Apart from the Software, which is often made for the Business Team, here is what the other buyers look for, in your Product:
Product Variants
Product variants essentially mean — do you have a separate “Enterprise Plan” where you provide a lot more than just the normal features? Business Teams would want to see that you are not an SMB startup trying to forcefully sell to them just because you got a meeting with them. They would want to see that you are willing to support Enterprise clients.
Take a “non-software” example to understand this better. Let’s say have a well-known Laptop Shop. Now, Acme Inc., a Large Enterprise gets to know about you and they reach out to you. They’d want to know that do you have processes in place to cater to Large Enterprises?
Do you also have Service Professionals who can visit on-site and service the laptop in case something goes wrong? This is important because like small businesses, they can’t run to your shop for service. They need your professionals to visit them.
SSO Authentication
Can the employees, who are using your Product, log in with their Company’s employee ID and Password? For Enterprises, managing credentials is a big deal because there are often so many employees to take care of. Generally, each employee is given an employee ID and password by the company. It is, then expected that your application should support login using these credentials rather than providing them new credentials.
This way, if the employee leaves the company, they can deactivate their employee ID, and automatically, the employee login to your Product would also get restricted. So, for the company, it just becomes easier to manage. This is mostly required by the IT Team.
If you don’t know what SSO is, read more on Wikipedia.
Audit Trail
Does your application provide detailed audit logs of who did what? Tomorrow if something goes wrong, an investigation would be required and therefore, these logs would prove to be of help. Some examples of audit logs that your application should provide include:
- Who logged in and at what time?
- Who logged out and at what time?
- Who created something?
- Who deleted something?
- Who modified something?
- Who added another user?
- Who shared something with someone else?
These are just some of the most generic things. Depending on what problem your product solves, you may have to add a lot more other types of Audit logs. These logs would typically be asked by the Compliance and Information Security Teams.
Access Management
Can new users be given access to your solution easily? Can existing users be deactivated? Most problems of Access Management will be solved if you have SSO Authentication in place. However, your client may need some specific access management processes. For instance:
- Provide access to multiple users at once
- Revoke access of multiple users at once
- Provide access to a certain designation of all users. For instance, all the VP-level employees of the company.
Access Management would mostly be asked by the IT Team.
Data Security
This is often a critical requirement in all Products. Your Product should be safe and secure. Typical requirements are:
- Vulnerability Assessment (VA)
- Penetration Testing (PT)
- Source Code Review
- Application Security (AppSec)
Your Client will typically appoint a third-party Auditor who will perform comprehensive testing of your application from an IT Security perspective. They will share a list of “Open” findings and categorize them as “Low, Medium, and High”. You will then have to “Close” all of these vulnerabilities.
Depending on what stage you are in your Enterprise journey, don’t be surprised to see thousands of observations. Our first Enterprise client pointed out ~4,500 security observations. Without closing all of these Security observations, your product cannot be moved to Production.
The observations/findings could be of different types:
- XSS Scripting Attack
- SQL Injection Attack
- DDoS Prevention
- Requirement of an Antivirus System
There is a framework called OWASP which is most commonly used by large organizations. If your Product complies with OWASP guidelines, you should not face too many challenges.
Apart from the usual IT Security audit, you may also have to manage a general compliance audit. Some large companies will ask you a lot more things about your company:
- What is your company’s leave policy?
- Code of Conduct Policy
- Remote Access Policy
- Incident Management Policy
- Access Control Policy
Some may even ask you — how do you store employee biometric data?
IT Security teams may not be a decision-maker, but they definitely can be a show-stopper. With the huge list of requirements they may come up with, you might feel frustrated. An IT Audit and certification might sometimes take 3 months. Be patient, especially during your early days.
A good approach would be that whenever an enterprise client points out some “Open” findings, you should incorporate them into your product so that future customers won’t point that out again. This will drastically save your time because more or less, each Enterprise has a similar audit process. Don’t be surprised if you meet the same auditor again for some other client of yours.
Deployment Options
If the application has some critical data, the client may ask you to deploy the Product on their premise or on their cloud. Critical data could include stuff like their customer data, or their internal employee data which they may not be comfortable sharing with you.
On-premise deployments are often quite painful and therefore, it is highly recommended that you avoid that. On-client-cloud deployment might sound like a good idea, but we’ve seen that it is no better than on-premise. This is because all the compliance and restrictions are often the same.
I’d highly recommend building your Product in such a way that you don’t have to store any customer or PII (Personally Identifiable Information) Data. This way, the client would be comfortable deploying the application on your cloud.
Integration Support
Enterprises would want your application to be integrated with their Systems. For instance, transactional software for a bank might require integration with Core Banking. Further, SSO authentication is almost always required.
When selling to Enterprises, more often than not, these integrations would be different for each client. Therefore, it is better that you maintain a separate Operations/Delivery Team whose sole responsibility is to integrate your Product with the client’s systems.
You may be tempted to outsource this to a System Integrator. I’d highly not recommend that, especially during the early stages of the company because working with clients teaches you a lot of stuff which can help you build a better product.
A simple example would be that if you work with 10 clients, you’d be able to see a pattern with respect to most common integrations or types of integrations and you may want to build that as a standard integration in your product. Not only will that save your time during the implementation, but also it will be a selling point for your 11th client.
Comprehensive Analytics and Reports
Your Product should be able to demonstrate its ROI (Return on Investment) right from the Analytics Dashboard itself. The key metrics which your Sales Team promised the customer, should be visible in the Analytics dashboard.
When building an Analytics Dashboard, think this — “Which needle would my customer want to see moving, when purchasing my product?”.
- Does your product improve the employee experience? Show the change in eNPS
- Does your product reduce application downtime? Show the reduction in downtime
- Does your product improve Customer experience? Show the increase in NPS or CSAT
By showing the right Analytics and Reports, you would be able to save a ton of time for your Customer Success Team. A great idea would also be to share the report on your key stakeholder’s email once a week. It’s a great way to keep them excited about your product.
SLA and Support
The impact of your product on your Enterprise client might be quite high. Therefore, if your application goes down, they may face a huge loss. Therefore, they may ask you to sign tight SLAs (Service Level Agreement) wherein, you should provide them certain uptime guarantees — 99.99% or whatever. To be able to provide that kind of SLA, your product should be stable, or else, be ready for heavy penalties.
Further, you should have a Support Team in place who should be able to manage a crisis situation when an application goes down or faces some issues. If the Product is critical, your client would expect the support team to even provide weekend support. Be ready for that.
Now, what does that mean for your Product Development Team? Well, they should build the product in such a way that the level-1 issues are easily handled by the Support Teams. For instance, basic debugging, restarting the application, etc. The Product should be designed in such a way that the relatively “low-cost” Support Team is able to provide the support as against a “high-cost” Engineering team having to intervene every time something goes wrong.
Remember, Engineering Team is a high-cost resource. They should not be wasting time on routine client activities just because the support team is not able to resolve the issue due to product complexity.
Compliance with Regulators
Does your product process sensitive/PII data? If the answer is yes, be ready for a lot of grilling from the compliance team. Compliance Teams are the ones who have to answer to regulatory bodies and therefore, they will enforce those compliances on you. You should be aware of local laws and the Product and the overall offering should reflect that.
Take a simple example — in India, there is a law that Financial Institutions have to store Customer data within Indian Boundaries. What does that mean? If you are a US company trying to sell to Financial Institutions in India, you need to ensure that the Product has a deployment option in Indian data centers.
Doesn’t matter how good your product is. If it doesn’t comply with the local laws, you aren’t getting a deal.
Enterprise Pricing
This is the last and most important point — you can’t provide the same pricing to Enterprises, which you’re using for your SMB clients. Your $50 per user per month pricing, may not work for a company that is signing up for 100k employees. You’d have to give discounts — heavy discounts, just because this one large company is as good as a thousand SMB clients of 100 employees each.
These discounts may be as high as 50–70% or sometimes even more. The best way to structure your pricing is to put it in slabs based on employee count or some other usage metrics. Remember, pricing is a part of your “Product offering”.
So, here we are, towards the end of this article. The key takeaway is that in an Enterprise product, there are multiple buyers, and therefore, the product should provide something for each of the buyers. As an entrepreneur, your job is to have a thorough understanding of what each buyer wants, and build the Product and the overall offering accordingly.
