[#13] Slack's fair billing policy

A simple product hack that eventually helped Slack w/ customer $$$s

Author’s note

I describe myself as a student of technology - I study technology companies and digital products. And I’ve seen that documenting my observations/learnings in public domains like LinkedIn & Twitter have been positive reinforcement loops. Substack is another interesting medium for me to have meaningful conversations w/ all of you.

Let’s dive deeper into a short piece today into something that I felt was a very powerful idea in enterprise software.

Source

The readers of this space might know that Slack is my favorite enterprise software IPO of the past decade. It’s an iconic example of a “try & buy” SaaS company, I love the product as a user/customer and continue to learn from their journey as a product enthusiast. Interestingly, the most viewed Bizit piece was also about Slack.

This piece is another attempt at sharing my observations and learnings from Slack’s product journey that I believe founders and builders of modern-day enterprise software can internalize: packaging & pricing of the product go hand in hand w/ product development itself when building for the end-user-focused era.

Didn’t mean it to be wordful - let me try to break it down. I’ve had the fortune of working w/ many early-stage builders as they bring new products to the market. It is very common for me to sense/hear the sentiment of treating Product Development (building the product) and Go-To-Market (taking the product to the market) functions separately. I, however, disagree and believe the two re-enforce each other - especially if we’re building for the end-users.

And I might just have the perfect case study for you this weekend to make my point.

The Slack Fair Billing case study

Slack was one of the first few companies to deploy a successful Try & Buy strategy which as per my mental model is about using a set of successful consumer tactics in the world of enterprise software.

A core tenet of their product strategy was about letting multiple teams inside an organization use Slack. This helped them achieve two things: getting a team lead to swipe their credit card for collaborative business software was an easier self-service sale and it also helped bake in network effects into the product.

This had an interesting implication for large organizations. It also meant after a point in time, most large companies will have multiple teams using the product at the company. Once there are enough teams inside the organization using the product, the administrators wanted to consolidate and have control over.

This was all context build up and now we are going to the key takeaway for the piece.

This was 48 hours before Slack was officially launched (Feb ‘14). There was an entire team huddle to go over the billing flow before the official launch and realized that it has a flaw.

Walmart Labs was Slack’s single biggest customer then and had set it up in a way that let anyone w/ a “walmart.com” corporate email ID sign up. Since Slack was a product for teams (and not individuals), you’d have people working in other functions of Walmart across the world also show up in the company workspace.

Walmart had ~800 people in their Slack workspace of which only 400 odd were relevant. The others had signed up because they saw the product somewhere, tried their corporate email ID, were in the process of getting their team to adopt the product or something else.

Consequently, the corporate buyer had 2 painful options:

• buy 400 additional seats for the rest of the team or;

• manually deactivate those 400 people from the corporate plan

If you think of it, both were very high friction points at possibly the most important part of their conversion funnel. This is something people would give a lot of thought to and potentially end up not buying at all.

This was the catalyst for Slack to come up w/ their fair billing policy where Slack would scan every single account every night and make pro-rated refunds every 10 days for all the inactive accounts they find for their customers.

If the user was active but isn’t currently using the product, they’d be marked inactive. If they were inactive and started using the product, they’d be marked active. And the customer only paid for the ones who are active. This is incredibly useful in situations where an employee leaves the company, takes parental leave, or is fired.

I love it for the following reasons:

• It frees the admin from the burden of scanning and removing inactive users from the workspace and absorbs it into the product as a feature

• It removes the friction from the point of purchase decision

• It removes any perverse incentive on the vendor side for selling shelfware - charging for active users helps correlate the value they’re providing to their customers to the price they’re charging

“I’m a huge believer in less friction. Of all the places you can remove the friction, the purchase decision would be a big one.” — Stewart Butterfield

It was a disruptive idea at the time and one could argue that it did play a pivotal role in getting the company to $100M in ARR without a sales team. Despite the success of Slack, it is still rare to find a SaaS company that has a per-seat pricing model but only charges for active users. Interestingly, Slack still continues to have it on its website.

However, all said and done, it is important to keep the following in mind:

• The need for the model came up because of the nature of the product. Slack was aimed at teams and it was possible for users to enter their corporate email ID to see their company workspaces. This dynamic inherently meant that many workspaces using the product will have inactive users and a pricing model that doesn’t make it a frictionless experience for the admin might struggle to scale.

• Slack also operated w/o an outbound sales team for long. This model meant that the sales reps were not fighting it out on the ground to hit their quotas w/ a pricing model that had cannibalizing effects on their operations. I’d guess that things could have been very different if Slack had an enterprise sales team.

• At the core, Slack is a messaging product. Thus, it is very easy to define and measure product engagement and activity. And a few users need to use the product to find value in it. This might not as simply and effectively apply itself to other companies thereby requiring a deeper introspection before implementing a similar model.

But in any case, we can clearly see how product development goes hand in hand w/ the GTM strategy.

---

That’s all for now. If you have a question, comment or suggestion, do send an email to pratyushchry@gmail.com and if you liked this or any of the previous editions, I’d appreciate any and all shares on Twitter, LinkedIn, and WhatsApp. That’s how I measure if and what I should be doing with this space.

Acknowledgement/References/Further Reading:

• A Business Insider Piece that covers why people love Slack

• A SaaStr conversation w/ Stewart Butterfield (Founder/CEO of Slack)