Big enterprise customers have been buying software for a long time. Many started long before SaaS emerged as a smarter, better way to build, buy and sell software. That means they’ve got plenty of software they already depend on that needs to work with whatever your SaaS product can do for them.

There’s real payoff from careful attention to the issues that enterprise customers care about. Think about iconic logos for reference customers, certification to IT industry standards like HIPAA or SOC2, even an improved exit valuation.

Still, it also means a lot more scrutiny on how your product works. You likely made time-to-market trade-offs to speed up your roadmap. Now may be the time to turn your eyes to the enterprise readiness horizon. Here are seven things enterprise SaaS customers look for.

#1 Security of Everything

It’s hard to think of a more fundamental question than security. It’s not just that enterprises are rich targets. Risk and flexibility are practically two sides of the same coin.

Optimize cloud economics and drive Business Goals.Proven best practices that help both finance & engineering teams

‍

In fact, it is entirely reasonable to ask about “Security and __________” for almost any aspect of your SaaS application and platform. Nonetheless, there is a broad and deep of security fundamentals that you must address, including but not limited to

  • Identity and Access Management: ensuring only authorized, authenticated users and components can access your resources, and only in a manner that you intend
  • Detection: identify and respond to a potential security threat or incident
  • Infrastructure Protection multiple layers of defense to help protect network and compute resources from external and internal threats.
  • Data Protection Classify, encrypt, manage and monitor data at rest and data in transit
  • Incident Response There will be security incidents you have not anticipated. How do you respond?

Nothing scares an enterprise customer like security risk. Start assessing what you will need to do by reviewing the AWS Well-Architected Security Pillar design principles and Google’s DevOps tech: Shifting left on security.

#2 Change Management

In the eyes of the enterprise customer, change management equals zero surprises. They will of course expect that you have stable mechanisms for ensuring that every new feature and benefit is of top-tier quality’ that’s table stakes. But they also need a way to control how your new features are introduced into their internal user base.

  • Communications: when you have a new release, they want to make sure those changes don’t undermine the productivity of their workforce
  • Support for phased rollout: Depending on the maturity of the customer, they may not want to release changes into their environment as often as you do to the rest of your customer base. Be prepared to support user acceptance testing on their side before they roll it out to all of their users.
  • Integration Dependencies: Embedding your features into their day-to-day business processes can be a good thing. They are more committed and dependent on you. They will want to know if you can give them access to changes in your APIs to validate that your enhancements don’t have downstream effects
  • Well factored changes: Microservice architectures can build confidence that there are fewer unforeseen dependencies in your release train. Being able to make smaller, more frequent releases increase confidence as smaller changes are easier to validate and rollback.

#3 Audit Logging and Compliance

Enterprise customers view the ROI of your solution as more than a great set of features. They need to see that your platform will not expose them to added financial or legal liabilities. They want to have a clear line of sight to both code and data. Be prepared to explain how you handle anything that their users see or touch. They will want:

  • Centralized log storage so they can run audits against your logs to demonstrate you can find and fix problems fast and keep their data out of the wrong hands
  • Update and maintenance traceability proving that you are always on top of any improvements, patches, and releases to underlying components used in your solution
  • Isolated tracking of data and usage information for each feature and each of its users, completely walled off from data and usage traces of every other customer.

Seems like a short list? Not so fast. Refer to the previous two sections on security and change management. Compliance requires that your logging and monitoring infrastructure provide complete, well-organized, retrievable data on all of the above for both (1) security and (2) change management.

#4 Infrastructure Automation

The speed and success of your product releases are a strong indicator to enterprise customers that you have well-defined, mature release trains and solid tooling for CI/CD. Bear in mind that they are not just looking to evaluate the elegance of your software development lifecycle. Key items they will look for

  • Clean code repository setup and maintenance with secure and reliable storage of build artifacts, container images, standardized environments, and release gates, designed for a minimum of human intervention
  • Clear separation between application and infrastructure microservices, to rapidly and reliably deploy and rollback releases across all environments, ensuring saved on operations can focus more on new features
  • Well-specified infrastructure-as-code tooling for deployment orchestration, automation and remediation mapped to business high availability, performance, and scale
  • A development culture aligned on automation of both application and infrastructure codebases: They want to see a strong bias for documentation and minimizing reliance on tribal knowledge.

#5 Application Deployment Options

Almost every B2B SaaS company presents a subscription pricing scheme in a menu with three or four columns. Check the right-most column, and often you’ll see a package called “Enterprise” listing the price as “Call us”.

Why (besides the all reasons listed above and below)? One reason is that many enterprises do not run everything on public clouds. They often rely on software that’s older than your company to run their business. Not all of their people have the same skills; they have different specialties. An enterprise customer wants to control which of your features are available to which of their users. They expect your software to let them do that.

  • Support of multiple releases: Your latest and greatest may be ready before they are. Enterprises need time to train users on what’s new. They expect you to make that easy. Give them control of release timing; provide training documentation; support acceptance testing.
  • Control of role-based feature sets: Allow the customer to easily craft custom permissions sets or turn features on/off. Support tools that enforce all kinds of security policies at any access point, e.g. single-sign-on (SSO), feature flags, Cloud Access Security Brokers (CASBs) among others.
  • Third party integrations: Tying your features and data with all the other software an enterprise customer is both a challenge and opportunity. Building to well-defined 3rd party interfaces gives you new features you can re-use and sell to other customers
  • Isolated/air-gapped data storage options Can you have parts of your software that do not need to run on the public cloud? This can range from air-gapped datacenter platforms (e.g. a remote ocean oil platform) or address country-specific data sovereignty.

Multi-tenancy is a core tenet of building an enterprise ready platform architecture. Read more here.

#6 Business Continuity and Disaster Recovery

While technology options to avoid downtime continue to improve, downtime is still costly. Enterprise customers want to see how both your SaaS architecture and support operations in tandem handle unforeseen events. It does not matter to them whether this results from a malicious hack, natural disaster, or even an outage due to a hardware failure or human error.

Business Continuity refers to how your SaaS architecture and so operations so your downtime risk won’t affect their business. Disaster Recovery describes worst case scenarios when these events are both out of their control and yours. (Industry and vendor lingo often blur the boundaries between the two.) In practice, you will want to show them you understand two parameters of business uptime.

  • Recovery Time Objective (RTO): Amount of time required to recover from a disaster after notification of business disruption
  • Recovery Point Objective (RPO): Threshold of completeness (full or partial) which service or data must reach for a business customer to get back to work

One key indicator of enterprise customer maturity? They know this is not easy. Here are three ways you show them you understand the difficulty at least as well as they do:

Each of these approaches comes with a raft of tools and methodologies. They build on each other. Enterprise customers understand perfection is unattainable. They want evidence that you are working hard and smart to pursue it anyway.

#7 Cloud Cost Optimization

Resource leverage (in the form of reusable software) is at the heart of the SaaS model. Given the speed of SaaS development, you need ways of adhering to both expenditure and architecture goals.

SaaS profitability depends on paying less for cloud resources than you bill your customers. Given how demanding enterprise customers can be, it’s essential to keep a sharp eye on the balancing top and bottom line. There’s a constant tension over-provisioning to meet service levels vs. your own cash flows.

FinOps is a new discipline that defines best practices for closing gaps between feature implementation and the cost of services. Applying these best practices ensures your enterprise customers don’t cost you more than you charge them.

  • Timely, accessible reporting: Use fast, granular feedback loops for more efficient visibility into cloud spend at all levels, for both business and technical management
  • Empowered Technical Team-centric cost ownership:
  • Clear standards embedding resource tagging upstream in development
  • Drive granular resource tagging to 99%+ spend attribution
  • Support for continuous small adjustments in cloud usage/optimization
  • Centralized Cost governance: Empowered teams reduce duplicated effort, aligning executive buy-in for practices & processes that take advantage of the variable cost model of the cloud
  • “Global” rate and discount optimization are centralized & managed
  • Engineers stay focused on usage optimization, agile iterative planning
  • Accountability: Individual feature and product teams have a clear budget to manage their own usage of cloud, decentralize decisions about resource optimization
  • Collaboration: Finance and Technology teams work together in near-real time to match the cloud‘s per-resource per-second operating model
  • Continuously improve for efficiency and innovation
  • Value-based metrics demonstrate business impact better than aggregate spend
  • Conscious trade-off decisions between cost, quality and speed

The most important consumer of this “cost observability” is you. Customers will tell you pretty fast when they’re unsatisfied with the uptime or performance of your SaaS stack (and engineers are accustomed to finding and fixing performance anomalies). But’s all too common that neither engineering nor business management have the same visibility into the details of your cloud spend. Enterprise customers won’t tell you what it costs you to deliver the benefits; that’s on you.