Contractual Obligations | Customers, Etc.
Should you reset your entire org chart to sell to the enterprise?
If your company sells business-to-business software-as-a-service (B2B SaaS)1 software and you want to sell to the enterprise—i.e. really large businesses—you’ll inevitably run into the need to support certain “contractual obligations” that had, up to that point, been gleefully absent from your terms of service.
You’ll be asked to adhere to service level agreements (SLAs) for uptime, minimum response times, issue resolution times (based on level of severity), and let’s not forget indemnification2. You had previously been able to grow by selling subscription software on your own terms, but to enter a new phase of growth, you realize that you need to start winning enterprise deals. Hence the contractual obligations.
Should you accept the contractual obligations? Perhaps.
Should you change your organizational structure to meet them? Perhaps, or perhaps not.
Let’s dive in.
To enterprise or not to enterprise
One of my favorite primers on how to think about software pricing is Camels and Rubber Duckies from Joel Spolsky. The article is about a lot more than just selling to the enterprise—it includes a fun intro to basic economic theory on pricing—but it also includes this gem:
The reason I bring this up is because software is priced three ways: free, cheap, and dear.
Free. Open source, etc. Not relevant to the current discussion. Nothing to see here. Move along.
Cheap. $10 – $1000, sold to a very large number of people at a low price without a salesforce. Most shrinkwrapped consumer and small business software falls into this category.
Dear. $75,000 – $1,000,000, sold to a handful of rich big companies using a team of slick salespeople that do six months of intense PowerPoint just to get one goddamn sale. The Oracle model.
All three methods work fine.
Notice the gap? There’s no software priced between $1000 and $75,000. I’ll tell you why. The minute you charge more than $1000 you need to get serious corporate signoffs. You need a line item in their budget. You need purchasing managers and CEO approval and competitive bids and paperwork. So you need to send a salesperson out to the customer to do PowerPoint, with his airfare, golf course memberships, and $19.95 porn movies at the Ritz Carlton. And with all this, the cost of making one successful sale is going to average about $50,000. If you’re sending salespeople out to customers and charging less than $75,000, you’re losing money.
As the cofounder of Fog Creek Software, Stack Overflow, and Trello, you can figure out where Joel stood when it came to pricing:
Now, a quick glance around the Fog Creek website reveals that I’m firmly in camp #2. Why? Selling software at a low price means that I can get thousands of customers right away, some small, some large. And all those customers are going to be out there using my software and recommending it to their friends. When those customers grow, they’ll buy more licenses. When people working at those customers move to new companies, they’ll recommend my software to those new companies. Effectively I am willing to accept a lower price now in exchange for creating grassroots support. I see the low price of FogBugz as being an investment in advertising that I expect will pay off many times over in the long run. So far, it’s working very well: FogBugz sales have grown more than 100% for three years without marketing, solely based on word-of-mouth and existing customers buying additional licenses.
Why even sell to the enterprise and deal with purchasing managers and lawyers and, heck, your own sales team forcing you to live quarter to quarter so you can one day try to beat analyst expectations when you’re listed on the Nasdaq? Surely it’s easier to just list your price on the site, do some simple segmentation, and call it day.
At lot has changed since that post was written. Did you look it up? It was written in 2004. Two thousand and four! Software-as-a-service wasn’t even a thing when that post was written—Salesforce.com had only IPO’d six months prior—and now this post is old enough to vote in the 2024 election. I still think the fundamentals of Joel’s writing are sound, but so much has changed.
Anyway, maybe you decide it makes sense for your business to sell to the enterprise. Now you’ve got to figure out how to deal with the contractual obligations.
To change your org structure, or not
For customer care teams, I think the classic example of a new contractual obligation that gets introduced with enterprise customers is “24/7 support”. The conversation between the COO and customer support manager might sound something like this:
COO: How was your weekend?
Manager: I ate tacos and didn’t check Slack for an entire 18 hour span.
COO: Amazing… hey, did you hear we’re about to close the Acme Co. deal?
Manager: Oh wow! I thought that was a long shot.
COO: It was, but they really love our product. They’re looking to go live in about four weeks.
Manager: Wonderful.
COO: …
Manager: …
COO: So one of the terms of their contract is that they need 24/7 support.
Manager: Oh?
COO: Yeah, I was on the call last week. I tried to explain how our top notch support team is available from 9 AM ET to 9 PM ET, but they insisted on 24/7. I need your help figuring out how we’re going to get there.
Manager: You’re going to have to help me out. I fought tooth and nail just to get one more headcount for my team last quarter. To get to 24/7 from where we’re at with any sort of redundancy, we’re going to need at least six more full time people on my team.
COO: I think with the size of this deal we can certainly get some more folks for your team, but six is going to be a tough sell.
Manager: I figured as much. Plus, I’d have to really think about what we’d have them do. We’ve been running pretty lean and efficient. I’d have to check, but I don’t think we’d even have the inbox volume to justify building out the team that fast.
COO: Let’s think on it and talk again later in the week.
Do you recognize the problem in this fictitious scenario? Nobody is talking about why the customer needs 24/7 support. There are so many different reasons! Maybe they just need a number to call after hours in case of emergencies. Or maybe they have a global team and they want to know there are dedicated teams in their timezones who will get to know the ins and outs of how they work. Or maybe it’s just a thing they have in all their contracts and you don’t get the deal if you can’t meet the SLAs that are written in the contract and you don’t really get to find out why, despite how much you ask.
Your answer to the question about why the customer needs certain contractual obligations is going to change how you approach solving the problem of meeting them. Before you go build out an entire team, do the work to determine what it is you’ll actually be delivering.
For example, let’s say you have a small customer success team that is laser-focused on individual customer relationships. While the enterprise customer might be asking for 24/7 support, what they really want is to know that someone will get back to them with a competent answer the same business day and as long as your CSMs are responsive, they’ll be happy. Every now and then they want to make sure you’re available in case there’s an emergency, but that’s not every day. So perhaps you have an answering service to help make sure you meet your 24/7 obligation when it comes up.
But take a different example. Let’s say you have an efficient customer support engineering team that provides expert product support for a highly technical product. The enterprise customer in question is based in the EU. They expect to be using the product a lot and they really need a response near to real time, not when the team in the US logs on. An answering service isn’t going to cut it.
Don’t manage to the contract
The key takeaway here is that regardless of what you decide you have to do to meet enterprise contractual obligations, you’ll still be wise not to manage to the contract. The contract isn’t the definition of your customer’s journey. It shouldn’t define your org chart. The contract is the escape hatch for when things go south. If your customer starts bringing up contract language in quarterly business reviews, you’ve already messed up. Don’t get there. Exceed expectations. Don’t manage to the contract.
Why do enterprise customers even ask for certain contractual obligations? Because SLAs are a lot easier to measure than the quality of your brand. If you deliver an amazing end-to-end customer experience, the contractual obligations won’t even matter.
Well that’s a mouthful. If you’re reading this newsletter, you probably already know what “B2B SaaS” means. But maybe not! As point of personal editorial policy, I tend to spell out jargon-y acronyms.
via:
What is an Indemnification Clause?
An indemnification clause is a legally binding agreement between two parties specifying that one party (the indemnifying party) will compensate the other party (the indemnified party) for any losses or damages that may arise from a particular event or circumstance.
As a support manager, I would of course spend 100% of my energy toiling about the verbiage of the support SLAs. “Would they be okay with a ‘one business day’ response time instead of ‘24 hours’???” Our legal team practically didn’t care. The other party would almost certainly be fine with tweaks to support SLAs as long as we didn’t touch sacred cows such as indemnification, which is another way of saying, “if things really go sideways, we’re agreeing that we’re going to be the ones that are screwed.”