Pricing and “Fair Billing Policy”
Diving deeper on Slack’s two levers of growth. Learning principles about pricing. Selling through objections. Inventing the “Fair Billing Policy”.
By the middle of 2014, as we saw the numbers continue to roll up, as we watched the growth rate continue hovering at around 5% week-over-week, we thought we knew one big thing: once a team started using Slack, short of going out of business, they never stopped. 🚀🚀🚀
Really? This may sound a bit preposterous, and it’s probably not absolutely true. Somewhere, a team must have stopped using Slack.
But for our decision making purposes and in the law of large numbers, it was practically true. Once teams started using Slack, they always kept using it.
And so we started to see two distinct types of growth fuelling our business.
Source 1: New Customers
The first source of Slack’s growth proved pretty simple to understand: new customers.
Someone at Company XYZ hears about Slack, goes to slack.com, signs up to try out the product, invites some teammates and starts using Slack. No one before at Company XYZ had been using Slack. They’re totally new to the product.
These folks have a good experience. Slack’s a pretty good product and so much better than how they had been communicating before.
Slack becomes the main way they work together. Company XYZ upgrades for the team to get access to the full message history or unlimited integrations. Job done, huzzah: growth!
Source 2: Expansion of Existing Customers
Remember that first team from Company XYZ that started using Slack and upgraded? Right. Eventually, they also needed to work with their wider teammates internally.
That first team we might have described as a ‘tool chooser’ — developers, IT administrators, engineers, project managers. Slack could expand among ‘tool choosers’ pretty easily. These folks had administration rights on their computers and could install new software. They felt comfortable downloading applications and they felt ownership choosing how they worked.
But then they needed to launch a product with marketing. They needed to triage an issue with customer service. They needed to coordinate a reporting cycle with HR. They didn’t want to revert back to how they had worked. (Unthinkable!) So what did they do?
Those teams of ‘tool choosers’ did some of our work for us. They started to get their wider teammates in marketing, customer service and HR onto Slack. We came to think of these second-order users as ‘tool users’ when they started using Slack too. They didn’t necessarily install software. They used what the company used. So they started using Slack.
But no matter what we called the group of customers, Slack use pretty much always expanded at Company XYZ. And since our business model billed on a per-user basis, our revenue expanded at Company XYZ.
Tensions in Expansion
The way I’ve portrayed Slack’s growth above is a clean model that makes good sense and in a broad and general way is accurate. But it also created two kinds of tension for us and our customers.
The first kind of tension was typical of any change at an organization — it can happen unevenly and feel ungainly. Company XYZ might have a hybrid communication system with Slack and a few other communication tools in tandem use for a period of time.
We called this first tension the ‘one foot on the dock and one foot in the canoe’ time, because it was impossible to maintain for very long.
Customers disliked this stage and asked us what we recommended as a remedy. They felt the tension and didn’t like it.
We could see the tension but we didn’t really have much to suggest apart from an obvious strategy of waiting, trusting our product, and encouraging them to, you know, just use Slack. That was the business we were in, after all.
To help, we did build a pretty lightweight integration for folks to send emails into Slack, but we didn’t do too much to support the ‘one foot on the dock and one foot in the canoe’ period. We let the tension linger and assumed it was only temporary and only moving towards Slack as the universal solution for Company XYZ.
Want to import your Skype or HipChat or Campfire archives into Slack? Yes, we had easy ways for customers to do that. And you could export your Slack archives too, should you ever want to. But no one did that and very few companies lasted too long with one foot on the dock and one foot in the canoe.
The second kind of tension came from our billing model. Stepping fully into Slack meant more users on Slack and, as a result, a bigger bill for using Slack because we billed per-user. For our customers moving fully to Slack, it solved their first tension and created a second tension.
Let’s call that second tension ‘I don’t want to pay more.’ It’s so basic we didn’t have a name for it. Sure, our customers acknowledged, the more people who used Slack, the more value we get from it. But, still, someone had to make the case to the enemy in finance who signs the cheques.
Principles About Pricing
So we knew our customers pretty well and we knew the dynamics of Slack adoption pretty well — ‘land and expand,’ as the model got called in the software industry.
But still, amazingly, very few folks were queued up asking: how can I pay more?
We wanted to make our pricing work for them and for us. We wanted to resolve their tension. In our loftier moments we may have even articulated our pricing principles with the phrase ‘aligned incentives’.
Here are 3 principles we followed, and then 3 tactics that came from the principles.
Principle One — Make it simple. For new customers, we wanted to make our pricing simple to understand so they could share it internally, and low enough that it didn’t raise too many objections. A Director of IT at Company XYZ could put a few hundred dollars a month on their credit card and get reimbursed without a significant internal approval process. Easy peasy.
Principle Two — Make it fair. For expansion in existing customers we wanted to make our pricing feel fair and not act as a barrier to expansion. We didn’t want that same Director of IT to avoid inviting teammates in marketing to use Slack because they would incur large, upfront charges. (More about what came from making our pricing feel fair, below in the “Fair Billing Policy” section.)
Principle Three — Make it fast. We knew we were early in our customers adoption, and had limited resources for selling. The greenfield opportunity in front of us dictated that we had to keep moving fast. So we optimized for speed with new customers, and flexibility and ease for expansion customers.
For some brief fractions of time we did think about how much money we could yield in total from each customer. But that never drove decisions. We wanted to minimize friction. Higher revenue per customer would come. We wanted to avoid an internal approval process, or a contract renegotiation, or trigger a meeting with finance.
Each of these principles worked making sure we delivered far more value for Company XYZ than we asked to be paid. We believed that taking the long-run view would prove to be an asset, and it did.
Zoom forward 5 years to 2019 and that long-run view we took eventually yielded layer-cake graphs like this, showing each year of revenue from new customers continuing to grow over years of product use.
Tactic 1: Start High
So how did our pricing principles show up for our customers in action? Zoom back in time and we had a very specific problem to solve: what would Slack actually cost?
We talked about it. Stewart asked for inputs from lots of people. Then we simply made our best guess — $8 / user / month. A stake in the ground.
We played with other numbers but nothing else felt as right. It was less than $10, so didn’t incur the resistance of double digits. It differentiated us from an existing product in the market called HipChat that had some adoption at $2 / user / month. It meant a nice symmetry between the monthly cost of $8 / month and the annual cost of $80 / year. But it sure seemed high. Could we start there?
We could. But we also got some pushback that I remember as, “I’ll never pay that. Robbery!” That certainly showed up as a response before we got working on our story. Just think of the blasts I got from The Cannon when negotiating a deal.
But once we played it out a bit and worked on our value story — how much time could be saved by Slack, how reliability and performance were worth it, that Slack was a full-featured product that worked on all devices, that everyone at the company could actually use it, that it integrated with all the other products they already used — then resistance wavered. Slack was different and people believed that, mostly.
And in case they didn’t, we still wanted to help them and show them what they might be missing. If they were old-school Internet Relay Chat (IRC) devotees, we built a gateway to connect them to Slack. If they weren’t convinced, they could export their archives to another product. The message we wanted to convey: get started using Slack and see how much better it is before you say it’s expensive.
Tactic 2: Never say unlimited
One idea we played with early on was giving customers the option of signing up for an unlimited number of users for a fixed price.
For new customers, a fixed price seemed attractive and a way to ease the tension of paying for expanded use. It was like an all-you-can eat buffet: one price, no limits. Bottomless refills.
To make that more specific, let’s go back to our Director of IT at Company XYZ. They actually manage 500 employees, about a midsized organization. That first group of employees at Company XYZ who used Slack was 60 people. Then they added an additional 25 people from marketing and HR for cross-functional work.
So now they’re 85 people humming along using Slack. They have the classic ‘one foot on the dock and one foot in the canoe’ problem, and the Director of IT gets more requests to use Slack every week. Then someone finally asks: maybe we could use Slack for all 500 employees rather than just 85?
Oh, hey! Since they’re good at their job, our Director of IT has some solid knowledge of the software that Company XYZ employees use. They’ve got a frame of reference for what other products cost per user. But they don’t have very precise knowledge.
They can audit logs to get precise knowledge, but it’s always for the past and it’s a hard thing to do. In addition, it’s always looking back in time whereas contracting software deals and finding budget to pay for software is always looking forward in time.
So asking them to tell us how many users they would have in the future presented them with a difficult problem to solve and asked them to answer an unanswerable question. Couldn’t they just pay a fixed price and the problem goes away?
Well, yes, except. Except it was a terrible idea for our business and for their business.
First off, and most importantly and universally, no one knows the value of unlimited anything. And then its value decreases with use. One coffee is nice. Two coffees I can appreciate. Three coffees I can maybe carry around and share. Unlimited coffees overwhelms me. What would I do with them? How could I even carry them? I’d have to pee all the time. I can’t even consider it and I lose the connection of value to the original coffee.
Second, the connection of value to use was valuable to our customers, not just us. If they could light up as many users on Slack as they had, why should they invest in training or guidelines for using Slack? Why should they care how Slack was used if it was incrementally free?
We knew that was how so much corporate software ended up on end users’ computers — why not add it by default? — and it was a road to a terrible place we didn’t want to go that looked a lot like email and its cousin Skype. No one paid for those tools so no one invested in using them well.
Additionally, there were real costs for every user on Slack. Costs for our customers (more users, more noise, more administration of the product, etc.) and costs for us (bandwidth, storage, customer support, etc.). We didn’t need to model out any kind of growth numbers to know that unlimited users was not a path we wanted to go down.
So what, then?
Tactic 3: Credits, not discounts
One decision we made that I believe held a huge upside was to offers credits to our customers instead of discounts. Credits were a one-time bonus for signing up.
Credits lowered the initial price of Slack by changing the up front total owed, a win for our customers to get started, without changing the base per-user price, a win for us longer term at renewal. In contrast, discounts to the per-user price were an in-perpetuity decrease in the cost of Slack.
That difference may seem small or semantic but proved to be important over time, as customers renewed and as they added additional users. In short, because the product was so sticky to users and attracted additional users over time, credits acted as deferred revenue. Discounts acted as lost revenue. We would give away many credits to close a deal and smooth the adoption process but we would never change the base per-user price.
The additional benefit of using credits is that it provided something that seemed valuable to customers at pretty much zero cost to us. It meant we could offer a Give 100 / Get 100 referral program that gained the referrer $100 of credits and the referree $100 of credits. If we made a mistake with anything we could offer credits as compensation. It meant that when Slack went down in an outage and stranded our customers a few months after launching our paid product, we pushed credits to our customers worth 10 times what they paid for Slack during the down time.
Credits acted like our own internal Slack-specific currency, orchestrated by our accounts team (which was me until October, 2014) and administered by our Fair Billing Policy. Which brings us to.
The “Fair Billing Policy” Story
Remember the unanswerable question of how many Slack users at Company XYZ the Director of IT had to pay for? The second tension felt by teams upgrading to Slack?
Right, so: we knew the answer wouldn’t be 'Unlimited’. So what would it be and how could we make sure it aligned with our principles?
We decided to go around that unanswerable question (how many users in the future?) to pose a different and easier question to answer: how many users at Company XYZ are actually using Slack? And so, how about: we’ll just charge you for those users?
If in the future your number of users ticks above what you’re paying, we’ll charge you more for those incremental users on a pro-rated basis. If it’s fewer users, we’ll add credits to your account on a pro-rated basis and then use those credits before we charge you again.
This may all sound intelligent and reasonable in the abstract, and — warm up the back patter, it was — but it all ended up actually being driven by a real world example.
Leading up to the launch of our paid product on Feb 12, 2014, some large teams had already started using Slack. One of the features we’d let administrators enable when they signed up was for everyone with an @companyname.com email address who joined Slack to be added to their instance of Slack. It worked to increased virality and decrease friction — yay.
But it also caused a problem we didn’t foresee. Once you play it out and see that, oh my, everyone with an @walmart.com email address will get added to the walmart.slack.com instance, you can see the problem because that Slack instance wasn’t really meant for all 300,000 plus Walmart employees. It had been started by Walmart Labs as their own private space. It made it easy for their teammates to find them. But the @walmart.com domain also served the largest corporate workforce on the planet. It was just a matter of time before some of them stumbled on Slack and signed up and ended up in there. Derp!
But that original Walmart Labs team? We knew them pretty well and had worked with them pretty closely leading up to the launch of paid Slack. They were fans and wanted to upgrade for ~1200 people. That was a Big Number for us and we wanted to help them.
Unfortunately, they had 3,000+ people who had been routed into walmart.slack.com. They didn’t know many of them. So, now what?
We teased out the options. Option 1: do nothing and let them figure it out. If the Walmart Labs team didn’t want to get charged for all 3,000+ users, some poor administrator would have to go through their user list one-by-one to decide if each user was in or out — a boring and rote job to do. Exactly the kind of job computer programmers hated.
Or, option 2: we at Slack could do something to fix the problem that our feature had created. This seemed far preferable.
In the 48 hours prior to launching paid Slack our team built the rules and computer logic that detected whether a user was active (or not) and then only charged a customer for their active users.
That simple and specific fix for that one Walmart team rolled out to all of Slack and gave us a way to help our customers answer the unanswerable question. It changed the question from how many users does an organization need to upgrade for on Slack? To, how many users are actually using Slack? Then we’ll only charge you for those ones using the product.
Our precisely metered billing became a selling point. People loved it because it removed the risk of guessing. But it was a mouthful to explain. So I gave it a name: at first, the “fair billing policy” and later, the Fair Billing Policy. We’ll only ever charge you for the number of people actually using Slack.
It felt good to say and customers responded well to it. When I told folks about the Fair Billing Policy I also shared a link to a web page in our Help Centre that explained it all in detail, along with providing the rules of what constituted an Active User. Sometimes people even clicked that linked to go deeper. Mostly they just liked to hear about the Fair Billing Policy, and trusted us to have implemented it correctly.
On the Same Side as Customers
In looking back, the Fair Billing Policy was a huge hit. It made what had previously been a low value, low upside, inaccurate and painful human job — estimating the number of users that would need to be paid for to upgrade a software product — into a precise, logical computer job — telling a customer how many people actually used a software product, then adjusting as needed. It also acted like a time machine, deferring the decision on billing to the future when it could be answered by the computer rather than making it an up-front decision that stopped progression.
Lastly, it felt fair. It lived up to our overall promise of only charging for use. If they used Slack, they paid for it in the exact number of days they used it. If they didn’t, then they didn’t pay for it. It said that we were on the same side as our customers.
That first version had, as many of our features had, some unintended consequences. Paying teams started seeing it as a bit too precise, charging a credit card daily, calculating on a pro-rated basis usage per month. It proved to be too much administrative burden, the daily updates. As a quick iteration we rolled the charges up into a single monthly statement and that system stayed in place for many years and hundreds of millions of dollars.
So many things at Slack started this way — with an observation of what was happening, then a connection to how we wanted to run our business, then an ownership that it’s something we all work on. The Slack Wall of Love started this way. The Fair Billing Policy started this way. Who knew simply paying attention and noticing things could take you so far?
A single fix for a single team became a foundational way we billed customers and ran our business. People have dressed it up with terms like Product-Led Growth and End User Led Licensing, but really we were just trying to make it as easy as possible for our customers to avoid unanswerable questions and help them use Slack. We were trying to live our mission: To make your working life simpler, more pleasant and more productive.
So thanks to the Walmart Labs team for bearing with us and giving us the chance to find a better solution, and to computer programmers for being lazy and hating rote, repetitive work.
Up next: So Yeah, We Tried Slack — Introducing Slack to the world, in video. Peeking behind the scenes. Finding a title that fit.