JO-ANN DEASIS
Group 14.png

Subscription edits

 

Subscription edits

Orb
July - Sep 2024


Summary

  • Sole designer working with a PM and 2 engineers

  • A new flow for non-API users to edit existing customer subscriptions without having to delete and re-create subscriptions or requiring developer time

  • The workflow improves the parity between the API and web app UI and empowers finance and revenue operation personas by providing the flexibility and visibility to confidently make changes to live subscriptions.

  • The new flow branches from existing core pathways such as plan and subscription creation, using new interactions patterns tested with users to improve usability and clarity.

  • Implementation began but was paused due to competing business priorities.

Partial GIF of the final design

 
 

Background

Customer detail page with an ongoing subscription

Orb is a financial platform for SaaS businesses enabling flexible usage-based pricing. With Orb, customers are able to accurately bill their customers, rapidly iterate on their pricing strategy, and reduce the number of engineers dedicated to in-house billing systems.

Customers manage subscriptions in Orb via the API or the web application. Because Orb has generally been a developer-first platform, the API tends to have more functionality than the web app. For example, the ability to edit ongoing subscriptions by adding or removing prices is limited to the API, so when an end customer requests an add-on feature for their subscription, the finance team has 2 options:

1) In the web app, end the current subscription and create a new subscription with the change they wanted to make as a very manual, error-prone workaround.
2) Ask their engineering counterpart to make the change, but then the customer has to wait for the new feature to be enabled, and Orb’s value prop of pricing with no added engineering time feels less convincing.

 

Problems

Editing requires new date fields per price which can be difficult to conceptualize and manage in the current interface

  • In the API, editing a subscription in place requires each price to have an effective start and end date. In the web app, creation and deletion of subscriptions have implied start and end dates, so currently, the user hasn’t had to think about setting dates per price.

  • In the web app, prices are configured in cards that are shown in a list. With 10+ prices, it can be difficult to navigate to the prices that need editing and confirm the changes you’ve made.

A long list of prices in the current implementation

 

Editing mid-subscription can have unintended invoicing consequences for end users. Editing effective dates may produce new invoices, void invoices, or create credit notes. These consequences are unclear, and users want to fully understand how their change will affect what an end user sees.

 

There’s a growing divide between API and web app functionality. It’s unclear to users what’s available in the API versus the UI. Long-term we’d like to develop features in tandem so that we have less disparity between the two interfaces and so that UI features aren’t limited by the constraints built into the API.

Goals and metrics

If we can provide a way for finance teams to independently edit subscriptions in the web app, they will be able to make timely changes for their customers without engineering help, which would grow their end customer satisfaction and increase their usage of the Orb platform.

Success metrics

  • Reduced time to edit a subscription price

  • Less team touch points required for editing

  • Parity with API editing functionality

Business goals

  • Increase usage for the non-developer audience

  • Customer retention

 
 
 

Solution

 
 

As a team we went through multiple rounds of iteration and feedback among our internal stakeholders, as well as concept testing with users.

Concept pivots:

  • Focus on adding and removing prices to introduce powerful functionality to the UI and to get parity with the API, rather than creating a net new feature, the “price catalog”

  • Lessen the emphasis on the timeline as an anchoring visual and interactive piece

User feedback

  • Flipped our assumptions that the timeline was very important to orient the entire flow around and that our users are very risk-averse

  • The timeline is a clear visualization to more easily grasp how a price change will be enacted, but it doesn’t need to be in every step

  • Some users use plan templates as a superset of potential prices and can more easily remove prices what their customer does not need, rather than the current workaround of entering a zero quantity for prices

Exploration sketch

 

solution to add and remove prices

Figma demo of our solution’s key frames (with some pre-filled states for presentation purposes)

Web app users can edit subscriptions in a flow similar to existing core paths.

  • Users can edit subscriptions in place rather than ending a subscription and creating a replacement. This reduces the time it takes to make an edit and allows finance teams to do this independently of their engineering team.

  • Users get feedback and confirmations of changes along the way to help them confidently make this change without surprise invoices.

  • The new sidebar navigation lets users more clearly see an overview with action items in each step without needing to scroll through long lists or prices. This pattern can be extended to all creation flows.

  • Web app and API users now have the same functionality, helping to create a shared vocabulary and visuals for the team.

 
 
 

Results and next steps

MVP implementation began in Sep 2024 but was paused due to competing business priorities. However, our user testing findings influence our assumptions moving forward and what the future vision looks like.

Future

  • Add more detailed editing functionality like changing price rates

  • Consider bulk changes like raising rates across all subscriptions