Product
Redefining Pricing for Support
Youmna Sirgi
Founding Ops
Jun 12, 2023
We deeply believe that support is best when it's a company-wide effort, not just the job of a single person or team – a belief shared by many of our customers. This philosophy not only permeates all our product decisions, but how we think about pricing too.
Most support platforms price their tools based on seats. Companies pay a monthly price for every person given access to the support tool and often pay for enterprise tiers to have access to one or two technical features. This model encourages support siloes and forces companies to choose who they assign licenses.
In developer-focused products, support and engineering are closely intertwined. If a customer reports a bug, multiple engineers may need to collaborate to resolve the issue. It doesn't make sense for companies to pay high monthly fees per person for their whole engineering team when most of them only use the tool every few days, at most.
So they don’t. Instead, companies are forced into recycling licenses, sharing passwords, and trying every trick in the book to avoid cutting off their entire team from support - the direct line to the customer. We want our pricing to make it easy to adopt Plain across the entire company.
We knew that a ‘seat-based’ approach wasn’t going to work… but what would?
Taking advice from Atlassian’s ‘8 principles to guide your SaaS strategy', we identified the following criteria to help us answer this question. We wanted our pricing to be:
Simple. Someone should be able to glance at our pricing and move on to explore our product, without any confusion about what metrics we price on and what they might mean.
Predictable. You shouldn’t be surprised by the bill at the end of the month.
Scalable. What you pay works for you and scales seamlessly, whether you’re a solopreneur, a multi-billion dollar enterprise, or on the journey between the two.
Pricing based on volume made sense. We would give companies an unlimited number of seats with full access to Plain and instead, charge based on the amount of support volume they had. What we quickly discovered is how complex (read: insanely layered, nuanced, and frustrating) usage-based pricing can be.
Our pricing iteration cycle looked something like this:
Team huddle to define how to define and track “usage”.
Tweak lots of numbers on an Excel sheet to make unit economics work.
Hallelujah moment! Feel confident that we’ve finally figured out our pricing structure.
Update pricing page (again).
Receive honest, real, and obvious feedback about why our pricing doesn’t make sense.
Go cry in a corner.
Regroup. Iterate. Repeat.
We published the first version of our pricing structure with the open beta in November 2022. Since then, we’ve tried a few different approaches and learned some valuable lessons each time.
Lesson #1: Align your pricing to your target market.
In our first iteration, we charged companies based on monthly active customers, defined as customers that were sent an outbound chat or email. While the structure worked on principle, we had set our thresholds too high (starting at 250 monthly customers and increasing from there). The model was great for B2C companies who traditionally had a high distinct customer count, but not for B2B – and that’s exactly where we were getting most traction.
Lesson #2: Don’t tax for good practices.
In our next attempt, we changed the definition of usage by counting the number of “events” our customers generated, defining an event as a custom timeline entry, outbound email, or chat. In doing so, we were inadvertently charging customers for good customer service practices: You shouldn’t be charged for sending a “Have a great day!” message at the end of a conversation.
Ultimately, we went back to our original ‘monthly active customer’ approach and lowered the # of customers included in each tier to be more representative of B2B volume. Although it was painful to end up right back where we started, we wouldn’t have confidently returned to this model without the lessons learned along the way.
Lesson #3: Don’t make your customers do math.
We tried various pricing structure combinations to 1) make the numbers ‘look good’ (i.e., you don’t pay $2 per customer), and 2) still be financially viable.
Baseline + per-unit: A monthly fixed fee plus a per-unit cost for every customer ($200 base + $0.70/additional customer).
Per unit: A per-unit price for every monthly customer ($1.5 per customer)
Packaged Users: A monthly fixed fee + a package of 100 users ($200 + 100 users for an additional $50).
Several iterations of these structures resulted in a scary-looking Excel sheet that’s still giving us nightmares.
At this point, one of our engineers stepped in with a much needed reality check, pointing out that “if we strive for simplicity in our product, our pricing model should reflect that as well.” The version we were working on at the time was anything but simple, so we went back to the drawing board.
For now, we’ve landed on a ‘baseline’ fee structure. You pay a fixed fee each month for access to all platform features and an allotted number of monthly customers. The fee is inexpensive at entry and increases as volume increases.
One day, we’d love to follow in the footsteps of Seed (a Plain customer) by introducing add-on features, such as SSO, audit logging, advanced permissions, etc. We’ll get there very soon as we continue to build out our product.
It’s a work in progress.
We still don’t feel like we’ve quite nailed pricing. While I wrote this blog post, 60+ messages had already accumulated in our pricing Slack channel 😅. We’re probably overcharging some prospective customers and undercharging others. We’ve tried to be as transparent about this as possible, especially with our existing customers and those that we’re onboarding in the next few weeks.
Pricing will change a few more times before it feels good… and then it’ll probably change again as we add more features to our product. In the meantime, we’re open to feedback. And learning as we go.
