Redesigning the Subscription Change Flow
Established a solid base for future scaling by reworking a rigid subscription flow.
As Webex expanded its online offerings, I led the design of a new framework to support flexible plan changes and eCommerce growth.
MY ROLE
Led UX design
Set design strategy
Drove interaction & visual design
OUTCOMES
Paved way for flexible plans
Simplified change logic
Aligned product, eng, & business
Certain details in this case study may have been omitted or altered to comply with my non-disclosure agreement.
NEW DEMANDS
From One Plan to a Whole Suite
In 2022, Cisco began offering Webex Calling on webex.com. The team soon planned to bring more collaboration services online. I worked with PMs and engineers to update the platform to support a broader range of plans and tiers.
The early offerings were basic, with just one plan, one add-on, and a few tiers. Webinars, Events, and other products had launched for enterprise customers but weren’t yet available on webex.com. It felt like we had a warehouse full of products but nothing on the shelf.
The new suite brought together a full set of collaboration services, including Meetings, Calling, Webinars, Events, Contact Center, and a range of related add-ons.
It was clear to me early on that both the purchase and change platforms would need to evolve to support what was coming.
Direct Buy
The platform where new and free users buy service subscriptions.
Change Orders
The platform where paying customers update their existing subscriptions.
We saw the opportunity, but real change meant addressing structural problems beneath the surface.
To keep things focused, this article covers only the change platform. The purchase side is not included.
CHALLENGES
Three Walls to Tear Down
The door was open, but not without hurdles. I brought up a view I felt strongly about: to move forward, we had to break through 3 major walls.
1 - The Old Framework Couldn’t Keep Up
The early framework bundled license and user in one flow, which worked fine for a single product. But it couldn’t scale with the growing lineup.
Non-scalable Framework
The framework bundled license purchase and user invite to keep things simple, but it limited flexibility.
It worked fine at first, but couldn’t handle the complexity that came with Calling.
Struggled to Support Calling
Calling introduced assets like phone numbers and extensions, along with different provisioning steps. Assigning a license could no longer be directly tied to inviting a user.
2 - No Mix-and-Match
Before Calling launched, I learned about a major limitation. Customers couldn’t enable Calling for only some users in an org. They couldn’t mix and match plans within one subscription.
Ahead of the Calling launch, we tested a few purchase flows to see if users wanted to buy different plans together.
Adding Cart to Plans & Pricing
We added a cart to see if users actually needed to pick multiple plans.
Removing the Cart
Backend limits blocked some plans from being in the same org. Frequent recommendations confused users, so we removed the cart before launch. Still, the need was clear.
After Calling went live, I kept tracking this with PMs and engineers, digging into Hotjar and LogRocket data.
We saw a pattern. Users adding Calling or Meetings to the cart often stalled at checkout, flipping between tabs, likely trying to build a mix we didn’t support.
3 - Simple Plans, Complicated Rules
The real question wasn’t just what to sell, but how to sell it. Each change had to follow rules that made sense to users while protecting business goals.
Take a common case, for example:
Upgrading to a Higher Tier Plan
For mid-cycle upgrades, users paid for the rest of the new plan minus what was left of the old one.
Canceling a Subscription
When users canceled mid-cycle, the service stayed active until the end of the billing period, but wouldn’t auto-renew.
The rules made sense. Then things got complicated. We had to test if the old logic still worked.
THE HYPOTHESIS
When Clear Needs Meet Complex Systems
Instead of getting stuck in the system’s limitations, I decided to zoom out and start from a real user need.
I started with Dana, a typical online customer, and explored how the system could better support the needs of her small business.
Dana had been using Webex Meetings for years. As her business grew, she needed to add a phone system, while still relying on Meetings to collaborate with her team and clients.
After a few staffing changes, she also wanted to trim down her Meet plan licenses to save on cost.
Here’s what she was trying to do:
Dana’s Needs
Company main number
Suite Plan for Sale
Call Plan for Support
Remove 1 Meet Plan license
Dana wasn’t asking for anything unusual. She just needed a setup that fit her growing team and shrinking budget. Technically, her needs fell into two flows: upgrade and downgrade.
Upgrade
If the current limits stayed in place, and she couldn’t enable Calling for just part of her team, Dana would have to spend $150 a month. Removing that barrier would lower her monthly cost by 33%.
Downgrade
The current upgrade and downgrade rules were tailored for the early offerings. But as we expand the product lineup, do they still hold up? Let’s first take a look at how they work today.
All upgrades take effect right away.
If Dana has one license and adds another mid-cycle, the change happens immediately.
All downgrades are aligned to the billing cycle.
If Dana removes a license mid-cycle, the request is queued and takes effect at the end of the current billing period.
Only one downgrade can be scheduled per billing cycle.
If Dana already has a pending downgrade and tries to remove an add-on, the system will prompt her to contact support.
Upgrading would cancel any scheduled downgrade.
If Dana schedules a downgrade and then adds an add-on, the system will warn her that continuing will cancel the scheduled downgrade.
Dana was likely to hit a few snags.
If she downgraded first by removing a Meet Plan license, then later upgraded, the downgrade would be canceled.
If she tried to downgrade again after noticing it was canceled, she’d get a message telling her to contact support. Only one downgrade is allowed per billing cycle.
Clearly, the system wasn’t working for her.How could we make it easy for Dana to tailor her subscription on her own?
THE NORTH STAR
Building a Framework That Scales with the Business
A platform can’t scale just by adding new features. It needs a solid foundation. We defined what’s essential to support modern plans, real-time changes, and user control.
1 - Redesigning the Billing Experience
I began thinking about how to redesign the billing experience, starting with the interface for managing subscription changes. It has to be clear and easy to understand.
From a user’s point of view, it needed to answer 3 basic questions:
paying for?
paying for it?
changes?
In the “Your Plans” tab, Dana could easily see what she was paying for. The “Other Plans and Add-ons” section surfaced more advanced plans and related features. Clear button labels like “Edit” and “Add” made it obvious where to make changes.
The Billing tab made it easy for Dana to see how she was paying for her plans.
2 - Supporting Mix & Match Plans
After Calling went live, the data showed something clear. Users wanted to buy more than one type of plan. The first step was making that easy.
I looked into a common scenario where a user wants to add a Suite plan and a Call plan at the same time.
To make the flow easier to understand, I used a common eCommerce pattern: a cart with a sidebar. This gave users a simple way to add different plans and add-ons, while keeping everything in view.
In Dana’s case, adding the Suite and Call Plan triggered a special offer: two or more Calling licenses came with a free main number. We needed to highlight this clearly so users would notice it at the right time and understand it was applied.
3 - Making the Rules Works
Dana needed to reduce some Meet Plan licenses after a staffing change. But the outcome could be different depending on whether she downgraded first or upgraded first. It sounds a bit tricky, so let me explain.
Back when we only had one plan type, things were simple. The system treated upgrades and downgrades separately, and each followed its own rules.
At this stage, the mapping was simple, and the rules felt logical.
Once we had more plan types with different prices, things got tricky. Whether a change counted as an upgrade or downgrade depended on the situation, and users couldn’t always tell what the system would do.
Upgrade or Downgrade? Hard to Tell.
Figuring out whether a second change was an upgrade or a downgrade became much harder for the system to handle.
Was there a way to separate upgrades from downgrades, so they wouldn’t interfere with each other? Something easy for both the system to process and the user to understand?
I chose to separate upgrades and downgrades into different flows. On the interface, users were guided through clear buttons. Additions went into the cart. Removals and cancellations followed a separate downgrade path, keeping both flows clean and conflict-free.
As shown here, downgrades and upgrades are completely separated. Changes to the number of Meet Plan licenses take effect in the next billing cycle, without blocking users from adding other plans or add-ons.
The split made things clearer. But should we revisit how downgrades take effect?
In the example above, Dana removed one license, and the flow clearly showed the effective date.
But here’s the problem: she could still use that license until the current billing cycle ended. When the new cycle began, Webex couldn’t just randomly pick someone in the org and remove their license. That had already caused serious revenue leaks in the past. Some were significant.
So how do we fix this? There are two options:
Downgrade Without Unassigning a License
Users could keep using the license until the end of the cycle, but they had to take action. If no license was unassigned by then, the downgrade request would be canceled.
Unassigning Before Downgrade
Users had to unassign the license before submitting the downgrade. This ensured accuracy but could lead to financial loss if we didn’t offer service credit or a prorated refund.
Each method had its trade-offs. Before deciding, I also considered the special case of Calling plans. Unlike others, Calling downgrades already took effect right away.
In a mix-and-match setup, should we support both models or treat all downgrades the same way?
Here’s what happened to Dana:
Last time, she forgot to unassign a Meet Plan license before the downgrade deadline. The downgrade failed, and she paid for an extra month.
This time, she needed to remove a Call Plan license. Remembering her last experience, she thought she had time to unassign it later. But Calling downgrades took effect immediately. The number was shut off, and the business took a hit.
Since all plans were prepaid, I proposed a new direction: make all downgrades immediate. If needed, we could offer service credit or a prorated refund for any unused portion.
Different Plans. Same Rules.
As more plans became available, it became critical to apply consistent rules across the board. In eCommerce, users need to clearly understand what will happen when they take action, especially when payments are involved.
VALIDATION & ALIGNMENT
Turning Insights into Action
To break through those walls, we needed to test the ideas and designs. I teamed up with the user research team and set a clear direction with tasks to evaluate how usable the new framework really was.
Was the billing page clear and intuitive?
Could users complete key actions like adding a Suite Plan and Call Plan, or removing a Meet Plan license?
Key Findings
- The billing page was well received. Users found the layout clear and the information easy to navigate. Some suggested linking it to Webex.com pricing for added context.
- All tasks had a 100% success rate, with participants completing them independently. Most appreciated the free Main Number offer, though some wished they could choose the number.
- Users understood that licenses must be unassigned before downgrading, though many still expected prorated refunds.
- Participants appreciated the flexibility to mix and match plans — it felt like a significant step forward.
Core Insights
- Integration between the Subscription Change flow and the Webex.com Plans & Pricing page was already in our backlog. User feedback confirmed it should be a higher priority.
- Business rules must adapt to support more product types. PMs and teams need to rebalance logic between business needs and user expectations.
- We were behind on number selection for Calling users. Many expected to choose their own numbers, and we needed to catch up.
- Most importantly, users clearly wanted to mix different plans. This reinforced the need to improve backend logic and lift existing limitations.
Alignment Across Teams
After sharing the research findings and design proposals with PMs and engineering leads, we aligned on the next steps. The product team began exploring how to evolve the business logic, while engineering prioritized backend changes to support flexible plan combinations across all offerings.
But these changes required support from our eCommerce and payment partner, Digital River, which was facing severe financial trouble. As their platform began to collapse, our efforts were put on hold.
Still, aligning user experience, business logic, and technical feasibility gave us a shared direction and helped shape a clearer path forward once the constraints are lifted.
