Case Study

Volt Billing Portal

Supporting existing customers by displaying what they owe and why they owe it, all in one place

Supporting your business needs with text messaging requires jumping through a lot of hoops and understanding opaque policies. Volt made huge strides in helping its customers, but the billing process needed a second look to keep pace

Table of Contents

Part 1

Targeting Big Problems

Volt logo

About Volt

Volt (textvolt.com) is an SMS/MMS solution in the brand new space of Messaging Ops, where U.S. companies, large and small, can manage their texting providers in one place, have phone numbers automatically registered for compliance, and get insights on how often and how reliably their text messages get delivered.

Volt had gained and retained customers through several product evolutions, and as in every agile start-up, parts of the experience began to get strained when growth spiked. We had recently finished streamlining the onboarding to the core Connect and Insights products when we discovered that one of our teams was under too much pressure.

A billing problem

The customer success team told us that they received daily questions about how to pay a bill to Volt, how to change how they paid, and how to check on their bills. On top of that, they also had a few clients asking for weekly breakdowns of their SMS/MMS usage and related costs, which were being generated manually. Our large customers requested an alternative to once-a-month invoices in their email, instead wanting something that showed them everything they needed to know to make good financial decisions. We had plenty of data to confirm what we needed to focus on:

New and existing Volt users want to know what they’re being charged for text messaging and Volt’s apps, why those charges occur, and how their usage is impacting the charges—all without needing to ask Volt’s team for that information.

Part 2

Understanding the Customers

Billing Overview page for a new, trial Twilio account

Adjacent competitors

Volt’s status as a “middleman” solution puts it in a unique place in the industry, but we could easily compare the billing process for Volt to other SMS/MMS-centric communication companies like Twilio and Telnyx. As the team’s only UI/UX and product designer, I worked with the head of engineering and CEO to identify how our competitors shared billing information.

For example, Twilio’s billing dashboard provides ways to manage billing and view usage through its Billing portal. Telnyx did the same, in addition to providing PDF invoices in exhaustive detail, starting with high-level costs and proceeding to list every fee over tens of pages. Our customers had referenced these approaches to billing to us before, with the caveat that they still weren’t quite what they were looking for in terms of quick views, a legible split of high level charges from detailed charges, and usage statistics.

Pains & goals

With a preexisting database of customer meetings and emails at hand, I built an affinity map in Miro, collecting the key pains and goals of Volt’s customers. They all had similar goals, but our customers roughly broke into budget-first users (small-medium customers, valued managing and reducing costs) and efficiency-first users (large customers, valued quick insights into costs). There was a lot of overlap, but I extracted goals and pains for each user type:

Volt Customer Pains

Difficult to Manage: All users struggled to find and remember where the current billing options were located and how they worked—or if they worked at all.

Opaque Charges: Budget-first users couldn’t see how much they were paying per provider, per carrier, or per service without Volt doing a deep dive to collect the data.

Manual Requests: Efficiency-first users needed to request manually-generated usage cost views from Volt, which became delayed when customer success had higher priority tasks to address.

Volt Customer Goals

High-Level View: All users want to see what the totals of what they owed, up to the current day in a month, rather than getting a single, monthly invoice, so that they don’t need to guess at budgeting for Volt services.

The Deep View: Our many budget-first users want to see every cost incurred—all 50+ of the fees that occur when texting—so that they have control over their budget.

Smart Usage: Our efficiency-first users want to monitor daily and weekly text sending rates relative to cost, so that they can predict spikes in spending.

Part 3

Rapid Design & Prototyping

Planning document for key screens

Low-fidelity designs

We could see that our billing MVP needed to progress to meet our customers where they were at. I started by developing a quick Figjam planning document to share with the team that described, in the most general way, what we needed to show to make the front page of the billing portal come to life.

The low-fidelity mockups started on paper, then moved to Figma so my team could see what I had in mind for the design. I echoed the design of our Insights product, which has cards featuring key tables and graphs that re-flow based on the viewport. Based on internal feedback and customer insights, I kept a hierarchy in mind:

  1. Total Due & Payment Method: I ensured that what our users owed and how they were paying was immediately apparent on the billing landing page to address the most common pain cited by our users and this project’s stakeholders

  2. Next Bill: I implemented a card that shows information for the next bill cycle, including what they owed up to the current date and what they’re likely to owe based on their current usage patterns

    1. I also connected the “Daily Usage” modal to this card to break down costs by major category per day for the next bill

  3. Billing History: Our stakeholders determined that displaying the billing history would ensure users could reference old invoices for budgeting and predicting costs based on high-level spending patterns

Lo-fi Billing landing page

Lo-fi Daily Usage modal

Shift to high-fidelity

I spoke to anyone at Volt who had the time to look at the lo-fi designs. Their feedback was largely positive, with a focus tweaking what was visible in the daily usage modal and wanting to see the other screens (“Change Plan” and “View Charge Summary”) come to life, rather than cutting either or both for speed. Consequently, I opted to push into hi-fi designs so we could expedite building the core features with the design in mind. A few points of note during the shift to hi-fi include:

  • Since the designs were based on our Insights products, I designed new variants of the custom-styled card component we already built for the PrimeFaces UI framework

  • More data had come in showing that our users couldn’t identify what plan they were on, so I added a custom header with their plan’s name

  • We decided to place the landing page in the area users were most likely to expect it: the Connect product, linked in the side navigation

“Billing” landing page

Active state (existing payment/usage data)

“Daily SMS/MMS Usage” modal

Daily SMS/MMS Usage modal for the dates of April 1–15, 2023

“Charge Summary” page

Charge Summary, scrolled to top of page

“Change Plan” page

Change Plan, displaying open dropdown for plan change reasons

Delivering to engineering

The engineering team was familiar with the macro-level systems we’d need to make the new billing portal work, but it was my job to ensure the details of how our users experienced it. I annotated the designs with requirements and specifications, focusing primarily on how each section should behave based whether payment or usage data is present. Some of the annotations highlighted:

  • The “Update Payment Method” button needing to lead to a Stripe overlay with certain requirements

  • What calendar, scheduling, and email tools needed to connect to the “Change Plan” page

  • How and when to paginate the billing history card and usage modal data

Additionally, the prototype focused on navigating the screens and microinteractions between pages and views, since most features required minimal user input to function as intended.

Part 4

Future Considerations

Goals

Building a billing page is a common need for SaaS products of all kinds, but the SMS/MMS space sits at an intersection of government compliance, carrier requirements, and communication provider management. There will never be a perfect billing portal, but expanding key billing features will ensure Volt’s customers are happy with their relationship to Volt and the SMS/MMS industry. Here are the first two goals, beyond maintenance, to keep in mind:

Goal 1: Charge Summary Revisions. The charge summary should contain a lot of data displayed as well as possible, which means the final version should include filters, search, and smart loading.

Goal 2: Change Plans Autonomously. Users, especially those with low-rate plans, will feel significant friction when they need to make contact with a Volt employee to cancel their plan.

Challenges

Agile thinking requires frequent releases happening fast, and the billing portal didn’t get a chance for extended usability testing outside of the company itself and select individuals close to Volt. While the designs are founded on Nielsen Norman’s 10 usability heuristics and built with extensive knowledge of the customers, it will likely need several iterations to meet—and exceed—Volt’s users’ expectations. I look forward to seeing what future UI/UX designers will do with my last completed project at Volt.

In conclusion:

The foundation of the new billing portal combines Volt’s specialized knowledge of its customers, ability to rapidly implement new features, and understanding of commonly-understood functions for billing.

This case study was generated by me—Taylor B. Dallas—for my website, taylorbdallas.com. The research data was collected by Volt and synthesized by Taylor B. Dallas for Volt. The designs featured in this case study were created by Taylor B. Dallas for Volt.

Base UI Kit: PrimeOne UI Kit for Figma

UI Component Framework: PrimeFaces (PrimeNG and PrimeReact)

Volt Brand: Volt