Phone Plans page revamp

Workiz sells a phone product inside the platform. Businesses get a number, make calls, send messages, and everything stays attached to the job.

The problem was that not enough customers used it.

The ones who bought a phone plan often stopped using it. Many did not understand what the phone actually gave them over the phone already in their pocket. And the page meant to manage all of this, the Phone Plans tab inside Subscription, was static. It did not show how many minutes or messages had been used. Nothing updated. A manager who opened it to answer a simple question, “are we about to run out,” could not find the answer.

So the page existed, but it did not do the two jobs a billing page has to do: tell me where I stand, and tell me what I can do about it.

The revamp came to me from the PM as a roadmap item, and the PRD was thin. I had already seen this page failing before it was assigned, so I went and gathered evidence.

I used FullStory session recordings, support tickets, Amplitude, and the billing and phone pages of Housecall Pro and ServiceTitan for comparison.

Four things came out of it:

The biggest structural decision was to stop designing one page and start designing three entry points into the same page.

The glance question is how much of the month is gone. The follow-up is why.

So the chart shows total minutes and messages used, with the on-demand portion broken out inside the same view. That split matters, because on-demand is the part that costs extra, and a manager needs to see it without doing arithmetic.

Month view is the default. Previous months are there for comparison, and a day-level view for when someone spots a spike and wants to know where it came from.

On-demand billing keeps the product working past your limit, and you pay for the overage. The design problem is that you are asking a business owner to switch on something that spends their money automatically.

So the moment the toggle goes on, the user sets the amount. Workiz cannot charge beyond it.

The warnings come in two steps. One when the balance is running low, so there is time to act. One when it is gone, so nothing fails silently. Both in-product, alongside the existing emails.

The old explanatory modals were inconsistent, visually weak, and did not link anywhere useful. I rebuilt them into a clear features section that explains what the phone product does and routes people to the right page.

Then I proposed offering the phone plan right after a user subscribes to the SaaS plan. There were doubts about the timing, but my read was that someone who just decided to buy is the best person to show their options to. A lot of Workiz features go unused simply because they are offered in the wrong place at the wrong time.

We agreed to test it rather than argue about it.

After launch, 9% of new SaaS subscribers moved to a phone plan within two weeks.

Phone plan upgrades went up after launch, and the upgrade moment turned out to be the highest-leverage change in the project. It was also the smallest.

The page went from something people opened once and closed to something that answers their actual question, which is different depending on who they are.

I would test the usage graph with real users before build.

I designed it from session recordings, support tickets, and competitor patterns, which was enough to make it clearly better than a static block of numbers. But “clearly better” is not the same as “clear.” I do not know whether a manager reads the on-demand split the way I intended, or whether the day-level view gets used at all. Half an hour with five customers would have told me.