You’re starting to get interest from larger companies in your SaaS product — a deal for a whole business unit, or even a site-wide license is being discussed. This is great news, and you can see those commas in their check already — what else could you possibly need?
Closing big deals with large companies requires more than just a good product. You need to speak their language, consider their unique use cases, and be prepared to do business their way — slow, layered, and expensive.
First, read up on the product features these “enterprise” customers need. EnterpriseReady, by the team at Replicated, is the best guide on building a product ready for the enterprise: EnterpriseReady - Build SaaS Features Enterprises Love Changing the enterprise software narrative from ‘how to SELL to the enterprise’ to ‘how to BUILD for the enterprise.’www.enterpriseready.io
There’s more to it than product features, though. Here’s a hit list of some of the other things you’ll need to consider as you work toward closing those big deals:
🏙 “Enterprise” / “Proof of concept”
You need to develop messaging that speaks to this new audience using their language. I like to refer to these as “honeypot words” — phrases that stand out to the enterprise audience. When people who work in large companies look at startup SaaS products, they’re often wondering if you know how to work with them. Show them that you do.
🔐 Corporate authentication
For broad adoption, supporting corporate authentication (via LDAP, SAML, etc.) is critical. Expecting a company to individually manage on-boarding and off-boarding thousands of accounts in your SaaS product is often a nonstarter.
Similarly, if your product uses OAuth exclusively, say GitHub, Facebook, or Twitter auth, you are making it really difficult for corporate users to sign up. Not only do these services make signing up on mobile extra difficult, it’s also another point of friction for corporate users who may not want to use their social identities for their corporate work.
☎️ Service-level agreements
A service-level agreement is a formal commitment to your customer on the service you are offering. It may spell out specific uptime requirements, support response times, or system performance requirements. These agreements may also include details on what happens if the service does not meet these agreed-upon measures. Having a service-level agreement that matches your customers explicit needs is sometimes all you need to land a much larger contract, so make sure to ask what it is they need.
📜 Custom contract
Just as that SLA might be specific to a particular customer, your overall contract may need to be customized for them as well. This is an expensive route to take, but often essential for large deals.
Almost every company I’ve ever met has a set of contracts that they signed with their first big customers that they wish had better terms. “We won’t do another agreement like that again!”. Having a legal team (in-house or outsourced) manage these custom contracts is expensive — especially if you don’t land the deal — but I wouldn’t recommend signing a custom contract without legal council. Just make sure the contract is worth the additional investment of time and money.
🙎🏻 Account manager
There is an all-too-common idiom here I’m not going to repeat, but large companies often require that there is a single point of contact that manages all key interactions between them and their vendor (that’s you). Some startups will merge the duties of customer success with account management when they first start out, but remember that these are different roles. An account manager is the primary business contact, and ensures the relationship is solid and everyone is happy — not just the people that use your product, but the people that pay for it, too.
If you have a small team, consider involving folks on your product team to manage this role. These interactions make for great product feedback, and they’ll be well positioned to respond to issues.
🛣 Product roadmap
Roadmap? We just ship! 100x a day! If you want to know what we’re shipping next, just wait until tomorrow! — that’s a great list of things not to say when you’re asked what your product roadmap looks like.
You should be able to clearly communicate the general themes you’re working on over the next quarter or two. Don’t commit to dates, and don’t commit to specific features, but develop a clear roadmap that demonstrates your product vision, with areas of focus in the near-t0-mid term.
🤑 Pricing (and discounts)
Nobody pays the full list price for large deals, so make sure you have a solid pricing and discount model to accommodate these deals. Remember those web 1.0 business models — “We lose a little on every order, but we make it up in volume!”? You need to know your cost of goods sold (COGS), along with a cost model for what it takes to close, manage, support, and renew this customer over time, in order to understand what your pricing floor is.
Having high-visibility reference customers is fantastic for business, especially early on. Consider building a model for give-and-take on discounts and marketing value — logo use, co-marketing activities, case study, video interviews.
😂 On-prem (AWS lol)
A few years ago the great divide for “enterprise” software was Cloud vs. On Premise. Today, virtually every company runs the majority of non-core applications in a private cloud environment, so “on-premise” now usually just means AWS. When large companies ask for on-premise software, they’re typically thinking about data isolation, not where the software is running. With such a narrow deployment target (and with products like Replicated), shipping an “on-premise” version of your product is immensely easier than before.
If you dig this post, check out the full talk I gave at Heavybit: Land and Expand Strategies at GitHub and New Relic