Lessons learned: raising pricing for legacy customers, pissing off the lowest number possible, and keeping your support team alive.

This year we raised prices for our oldest customers.
- It was really hard (for tech, support, leadership)
- We survived (as teams, as a product)
- It was the right decision
- It was really hard
Choosing to adjust pricing for legacy customers is a hard, and emotional decision. It is one that should never be taken lightly. These people were your original crew — your first allies — and the reason you’re here now. They deserve the upmost respect for this history. You also have to balance this with the future of your product, the support these customers need, and the fact that they’re paying (potentially) way below your now-market value.
When this mismatch occurs, they can be a drain on your resources more than a benefit. Having them pay something closer-to-current value is essential for the growth of your company. While it isn’t an easy transition, the how can make all the difference.
Pricing changes are inevitable. It’s how you do it that’s critical.
I’m not sure there are words to properly explain how much this project changed me — as a Support Professional, and as a human. When we first started, I knew it would be hard, but I didn’t expect to learn as much as we did. Below are some lessons learned, some things we did right, and some things we didn’t think of until way into the process.
My hope is that you learn from this post that pricing changes, while painful, are possible, and can be done with a bit of grace. Less about us, and the fact that we changed prices, and more about the lessons learned, in hopes that they’ll help you on your own product journey. Learn, share, grow.
Start small so you can adapt and change, quickly
We planned for every aspect, down to nit picking every communication word by word, and reviewing and editing the new pricing page UI a dozen times.
And then we rolled it out — to just a small group of customers (50) — and it was all wrong.
The UI and communication wasn’t intuitive, and people weren’t certain what they had to pay. Even the actual amount of the increases each customer was getting weren’t right.
We quickly learned a lot of lessons (through a lot of tickets) and adapted.
Luckily the changes had only gone to a handful of customers, so it was easy to step back, adapt, and do something different right away. We continued with small groups until we were certain on our wording, timing, and all other aspects.
Determine your goal
Every pricing change has a different goal. Are you hoping to get people on to a much higher price? A price that matches current value? A step up, to leverage a further increase later down the road? Or perhaps you’d like to update some dated plans to annual pricing, or to pricing that includes more features.
Whatever the goal of the pricing change is — everyone should agree and strive to that same objective.
For example, if annual payments (over monthly) is the goal, then give your team the leeway to give some discounts for the first year, to help people over the budget-change hump. If revenue increase is more important than annual pricing, then breaking the payments into monthly terms, at a higher rate, could instead be the priority.
In the end — you can’t have more than one of these as the top priority, or it paralyzes your team as to what to focus on.
We struggled with this a bit — and changed our goals a few times. Once we had a solid goal, it was a lot easier to go forward with confidence when working with the customers.
Determine the “end result” and the action-by period
When we first started the pricing change we had vague conversations about what we did if people didn’t move to the new pricing, but we didn’t have a definitive action. This led to a lot of followups for weeks following the “action-by period” for the first group.
After a few rounds we set a definitive result to have happen at the end of each action-by period. Having an “end date” with an automatic action associated with it, should the user not take action on their own, made communication much clearer.
We also gave very clear action-by periods for making the switch, which was communicated through multiple email and in-app notifications. These periods and notifications were also all in line with our terms of use, giving us something easy to reference when questions came up.
This, of course, wasn’t without fallout. Even months later, we still have a small handful of folks who missed the email and in app notifications and are just now discovering the change. It’s still important to give grace where grace is due, and have a solid plan regarding refunds, cancelations, and communication in these cases, too.
Less details and decisions were better
In the beginning we explained everything ad nauseam — this is what’s happening, this is why, this is what the market has seen, this is your historical usage data, and these are the features you’re getting…
It turns out, this gave a lot of ammunition for customers to pick apart your reasoning, finding each piece they disagreed with.
This backlash to details surprised me — as I’m the type who really values the “why” behind a decision. Ultimately, the fact of pricing changes wasn’t a discussion, it was a decision that we had made for the future of our product. While we were happy to answer questions, we weren’t looking to argue about why people didn’t like the change, simply for arguments sake.
When we stripped back the communication to the basics (clearly stating what was happening, and when it was happening), and gave them fewer steps to take from their end, we found the responses we received contained less emotion, and more level headed questions. When the conversation began at a point of lower emotion, it was a more productive conversation for everyone involved.
There were, of course, customers who asked for answers to these “whys” — including why the prices were changing, how we picked the new prices, and what the future looks like with the new price. We gave these details out, freely and willingly.
Empowering your team with all of the details, and the discretion to dole them out as they see fit for the situation empowers everyone to tweak responses to questions to fit the situation. We wrote a lot of canned responses to use for different types of questions, and then edited them for each specific situation.
Document everything. Like. Everything.
When going through this big of a change there will be so many moving pieces that it’s difficult to keep everything straight. Keeping documentation of everything feels pedantic at the time, but it is life saving at the end.
We documented when each email communication went out, who we contacted, as well as a spreadsheet with customer data — importantly, historical usage over the last year, ytd revenue, the pricing plan(s) picked for them (and why), and their response (ticket link, dropdown to fill in their emotion, etc).
This information is vital as you plan future rounds of pricing, and want to make tweaks and adjustments. It also allows you to speak intelligently when someone reaches out about the pricing change, and, gives you reporting to be able to provide to your higher-ups.
Start documenting in the beginning — instead of playing catch up at the end.
Keeping this documentation for the team doing the increases is really important. Remember, though, that it may be overwhelming for the people who aren’t a part of the change every day. For some folks in leadership, a distilled version with “just the facts” can be helpful when talking about the project. We made a second copy of our sheets with a lot of the data stripped out for this purpose.
Concentrate who responds, but watch for burnout
We decided that the best team to answer these questions was our Support Team. Our support team knows usage and history of these customers, while our billing team is less attached to the day-to-day of the system.
We concentrated the answering of these tickets to a couple support folks — to help with consistency in messaging. We also de-prioritized these tickets, making sure we got back to them within a day, but not with our normal SLA of urgency.
If I had to do this again, I’d make the same decision — but, I’d watch better for burnout. These conversations were frequently emotionally fueled, and, during the busier rounds, this was often some of the only interactions these teammates were having with customers. It’s easy to feel major compassion fatigue when these are the tickets you’re writing back to all day. Make sure these people have extra attention, praise, and encourage self care and days off.
Even your most hard-skinned teammates will start to feel the drag of these tickets after a while. You can also consider rotating days — perhaps they only reply to pricing tickets on some days, and work on other projects on other days.
Feel confident in the prices you pick
With our first round, we learned the hard way that a “copy and paste” excel formula applied to all of the customers in the list wasn’t the answer for picking pricing. Usage was dynamic, and a formula wasn’t one-size-fits-all.
From then on, we hand-touched every price, making sure the jump or change amount wasn’t too high, and was in line with other metrics — such as system usage.
Yep, it took time, and yeah — there are certainly some shortcuts that made it faster, but it was worth it.
At the end of the day, you (or your team) are going to have to answer to the prices that were picked. Be realistic and keep in line with your end — goal for the project overall, but make sure you can answer to the choices that you made, too.
Once you know you picked the right pricing, you can speak with confidence when the customer asks the inevitable why questions.
People will leave. And that’s okay, too.
One of the biggest changes in myself in answering pricing change tickets over the course of the project was to eliminate the emotions associated with the change.
I’ve always been good at being a defuser in most support situations…But this was different. They were attacking our core decisions, they were calling out decisions I’d personally made, and decisions I had to defend…and…they were often mean. There’s no sugar coating it. It was hard.
Sometimes I think people forget that it’s fellow humans reading the messages that they write.
The biggest breakthrough for me was actualizing the fact that our system is worth the prices that the new customers are paying. It’s an awesome product, and it deserves respect. One of the ways to show this respect is in the price that we charge, and if some people aren’t ready for that, that’s okay.
Once I came to this realization, I was able to remove the emotion from my responses. I excluded “I’m sorries” (More thoughts on this here), I stuck to the facts, and I didn’t return the emotion that was handed out to me.
We’ve enjoyed managing your hiring thus-far, and would love to continue to down the road. I realize that pricing and budget is highly individual decision, and one you’ll also have to make as to what is best for your team moving forward. If I can answer any other questions, do let me know.
It’s okay to be honest with people, and it’s also okay to give them the permission they may be seeking to move on, should we not be the right fit anymore. It’s even okay to give yourself the permission that this is going to happen, and it’s okay.
I acknowledged that at the end of the day, our product had matured, and may not be the right fit for everyone anymore. Some people may leave, and that’s okay, too.
Obviously, we don’t know everything — but I feel myself (and my team) has grown substantially through this project.
While a long and hard project, it was also the fully correct thing to do for our longevity of our product, and our future as a company.
