Helping admins see which subscriptions need attention

Admins could view individual subscriptions in a table, but they didn’t have a clear picture of how their subscriptions were doing overall. It was hard to tell how many were processing successfully each cycle, which were running into problems, and what was causing those issues.

They could inspect subscriptions one at a time, but spotting recurring problems and knowing where to focus their attention was more difficult. I wanted to give admins a clearer view of subscription health: not just whether things were going well, but what was going wrong and what they could do to fix it.

The CEO and CPO brought me the need for a better subscription overview. Our VP of Customer Success added insight from working with clients who had struggled with the existing experience.

We looked at other businesses with subscription models and spoke with clients about what was missing. Clients couldn’t get a clear picture of how their subscriptions were performing, so they didn’t know where to focus their efforts to improve them. Without that visibility, they were left hoping things were going well.

Subscription billing dates vary from customer to customer, with renewals happening throughout the month. We landed on a calendar together as a way for admins to see that activity in one place, rather than piece it together from individual subscriptions in a table.

I found smaller calendar features in other subscription products, but none of the examples I reviewed combined the level of detail and actions we were aiming for.

From there, I wanted to connect the overview to actions admins could take. They should be able to spot a problem, understand what was causing it, and follow up from the same view, whether they were addressing a past failure or trying to prevent an upcoming one.

My first version tried to show nearly every piece of subscription data we had. In trying to give admins a complete picture, I had made the overview too crowded.

I pared it back by asking which information would help admins prevent failed payments or recover missed revenue. I kept the information most closely tied to those tasks: what was expected to process each day and what hadn’t been collected.

I removed the large error states that were pulling attention away from the other stats, along with the month-over-month comparisons on individual calendar days. The goal was to make it easier to see what needed attention without having to sort through every available metric.

The handoff separates Renewals and Recovery into two views. Renewals shows scheduled amounts and renewal counts. Recovery shows recoverable revenue and how many subscriptions need action. More detail is available when an admin opens a day, rather than competing for attention in every calendar cell.

Some of the stats I wanted to include relied on data we didn’t have available. I worked with engineers to understand what was feasible and left those stats out of this version to save time. That kept the scope focused instead of holding up the design for additional reporting work.

The design connects the monthly overview to a selected day, the subscriptions behind its numbers, and the actions available for them. These examples show two different situations: following up on a failed payment and asking for updated payment details before an upcoming renewal.

I reviewed the pared-down version mainly with the internal team. They found it easy to use and navigate and felt it would be useful for admins managing subscriptions.

I handed the interface off to engineering with screenshots and a specification. At the time of that handoff, it used sample data and the payment and email actions were not connected to live services. The project is nearing launch as of September 2026, so I don’t have post-launch results yet.

I initially approached the calendar more like an analytics dashboard and spent too much time on stats and data visualizations. Once I took a step back, I realized that admins needed a quick picture of what was happening and a clear way to act on it.

If I started again, I’d begin with the actions admins could take to prevent failed payments or recover missed revenue, then work backward to the information they needed. That would help me spend less time on visualizations that didn’t support those actions.