Pricing and Billing systems
Project #1 : Revising the homegrown billing system
BrowserStack’s business can be split into online vs sales-driven (or inside Sales). I split the whole system into seven main components, and mapped ideal features to each component:
Project #2 : The Big Pricing Migration
What was the problem?
We were maintaining three pricing versions to support 22,000 legacy customers. As we experimented with pricing, and launched plans and products, maintenance got increasingly difficult, feature releases slowed down, and new product adoption suffered because new products/plans were visible only to customers on the latest pricing version - so, legacy customers missed out!
What were the challenges?
- Different value metrics
- Different billing cycles
- a la carte versus bundled/combined plans
- Active, expiring, expired
- Feature access activated by random flags
What were the risks?
- iMRR loss
What were the success metrics?
- Support tickets
- Customer churn (plan cancellations)
- iMRR loss (incremental monthly recurring revenue). Projected iMRR retention: 65%
- New product adoption (% groups that purchased any of the new products)
How did we solve it?
The solution is to force migrate all 11,398 V1 groups to equivalent V3 plans without any price increase. The migration will also apply to expired groups. The migration will be handled in-product for all self-service groups and handled via personal involvement for renewal Ops.
We split the migration into four phases:
- V2 to V3 Migration (Online business)
- V1 to V3 migration (Online business)
- 2Checkout to Stripe Migration
- V1, V2 to V3 Migration (Renewals)
Mapping rules for unlimited licenses and multi-products /add/
The Communication Plan
- Subscriptions page
- Plan details in account summary
- First invoice post migration
- Opt-in email
- Cancellation Modal
Modal triggered on subscriptions page:
One previous plan case
Two previous plans case
Three previous plans case
Project #3 : Single subscription, to Multiple subscriptions
- Pricing page and checkout experience
- Backend changes
- Salesforce changes
Why V1 to combined?
- Multiple product confusion
- Low revenue per customer
- Fewer licenses per customer
Why V2 to V3?
Overall increase in revenue due to increase in revenue of ML : Increased ASP for ML plans with more or less same # of deals sold
Project #4 : Automate Mobile Plans and Pricing
Introduce browser automate on real mobile devices
Real mobile in Browser Automate is a feature within an existing product (browser testing).
Real mobile in Automate was decided to be a new premium plan. It will not only serve more advanced and picky users, but also define the “north star” - a plan or a feature-set that everyone should look up to and desire to have.
We are creating a new plan: Real Mobile in Browser Automate Mobile (real mobile devices in browser automate testing) We are dropping Automate plan.
-evaluation matrix- Even though we see option 3 as more attractive naming version, it would cause potentially high risk of mis-communication issues with existing clients. For example, existing Automate Pro clients would start seeing themselves as Automate account holders and not Pro anymore (even though it’s just the naming). The decision is clarified in the main problem solving table (above).