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.

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.

Orb customers manage their end customer subscriptions in Orb via the API or the web application. Because Orb started as 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 (Orb’s label for the pricing configuration of a feature) is only available in the API. A common reason to add a new price mid-subscription is when an end customer purchases an add-on feature that is separate from the core plan. The finance team has 2 options to do this:

1) In the web app, end the current subscription and re-create a new subscription that includes the change they wanted to make. This is a very manual, error-prone workaround.
2) Ask their engineering counterpart to make the change via API, though the end customer will likely have to wait for feature access. This also diminishes Orb’s value proposition of pricing management with significantly less engineering time.

If the finance team chooses to take action in the UI, they encounter additional challenges:

• When creating a new subscription, each price has to be created from scratch as there’s no centralized repository for re-usable prices.

• A user cannot truly “edit” a price’s configuration in either the UI or API. In the current data model, to edit an existing price’s rate, billing cycle, price model, etc. they must set the current price’s end date to today and create a brand new price with the updated configuration, with a start day of tomorrow. This order of operations is not clear and also has many downstream consequences users may not be aware of until an end customer complains about an incorrect invoice.

After exploring these problem spaces, we concluded these required separate solutions and chose to focus on the immediate use case of upselling customers and adding a new price into a subscription.

Editing an ongoing subscription requires new date fields per price which can be difficult to conceptualize and manage in the UI.

• 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. With an already bloated price configuration, this is one more thing they need to consider.

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

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. Moving forward, 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

• Retain customers

• Scale the product for upmarket customers with a larger number of prices to manage

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 introducing a “true edit” or creating a net new feature, the “price catalog”

• Lessen the emphasis on the visual 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

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 rates

• Consider bulk changes like raising rates across all subscriptions

• Based on execution and feedback of this feature, extend the new layout and interactions to other key creation flows and price displays in the web app