Fixing Cloud Invoicing

image

Company IBM Cloud (Billing & Cost Management)

Timeline Dec 2019 - Feb 2021

My Role Project Design Lead

Collaborators Justin Kruger, Hannah Moyers, Kristin Holifield, Tracey King, Mahendra Pingale

Expand section to see my roles and responsibilities
  • Lead project design processes, including sprint planning, roadmap creation, regular alignment presentations, work sizing, and more.
  • Collaborate with stakeholders across disciplines (PM, Engineering, Research) to drive alignment around user needs, identify user stories and Jobs to Be Done.
  • Collaborate with research to conduct user-interviews, audit data, and synthesize into actionable design tasks.
  • Create and test invoice and invoice page concepts.
  • Deliver final high-fidelity invoice and invoice page designs.

Project Background

The IBM Cloud Billing & Cost Management team had just completed our State of Billing UX Research project (view case study); a design-led effort to build an understanding of our Cloud billing users, their needs, goals and biggest pain points.

Alongside a deep-dive audit of the as-is experience we:

  • Held 63 customer interviews.
  • Held sessions with 6 Support & Client Success reps.
  • Gathered feedback from 54 survey respondents.
  • Gathered feedback from 80 Usabilla & NPS comments.

Among the many issues we uncovered, the Cloud Invoicing experience was top of the list.

  • 3/5 overarching billing pain point themes relate directly to the invoice experience.
  • 22% of negative NPS comments from IBM IaaS products directly reference invoicing.
  • Support team fielding 1000-1600 billing-related of tickets per month.
  • ~1M/month in support costs related to billing issues.

Project Overview

Directly related to identifying the invoice experience as a primary source of pain for users was a platform-wide technical effort to unify our different cloud billing systems; a direct result of a platform built on multiple acquisitions. Because of this and the business impact we were able to demonstrate, getting stakeholder buy-in to fix the invoicing experience wasn’t a challenge.

Team Goal

Improve our NPS score and lower support costs by addressing key gaps in our cloud invoicing experience.

Design Objectives

🔍
Understand the problem Understand the root causes of the low NPS and high support costs.
🤝
Drive alignment around user outcomes Drive alignment around user needs and outcomes with collaborators across 3 distinct stakeholder organizations.
📐
Design a solution Design a unified invoice reconciliation experience that addresses the billing user’s core needs and pain points.

Understanding the User

As part of the initial research we were able to refine our billing archetypes into a specific target user, identify their core use cases as it relates to invoicing, and map them back to our previously identified Jobs to Be Done.

Who is the user?

In collaboration with our UX researcher we identified 3 core billing personas that work in the Cost Management space.

While the responsibilities of each persona varies, there’s a good chance that all of the personas listed below engage with the invoice depending on the size of their company and the breadth of their responsibilities.

Cloud Cost Leaders

Leaders  often manage entire organizations dedicated to optimizing cloud spend, which usually consist of analysts, developers, and finance experts.

“My focus is on helping our organization: - Manage their current cloud spend - Plan for future cloud spend - Proactively identify ways to optimize our cloud portfolio by using only what we need” Cloud Optimization Lead, Enterprise, Utility

They are involved in the following Jobs…

  • Report spend for regular reports
  • Maintain app availability (optimize costs)
  • Send payments from the right place(s)
  • Educate teams on new processes (cost management focused processes only)

Cloud Cost Analysts

Analysts either work in teams focused on optimizing cloud costs, or are lone wolves. They frequently have a development background, and coordinate with dev teams to analyze their costs and make cuts.

“Their [AWS] cloud explorer gives us recommendations on what our users usage and computation behavior is. From there, we define our automated budget policies.” Data Science Manager, Enterprise, Technology

They are involved in the following Jobs…

  • Report spend for regular reports
  • Maintain app availability (optimize costs)

Cloud Cost Advocates

Advocates often have a day job as a developer focused on managing resources for themselves or others in their organization. They alone are not responsible for costs, but will often take it upon themselves to alert others when they are spending money on things they’re no longer using (like ‘orphan drives’, for example).

“I look up the owner and say, hey, over the last three months, this high compute device which you requested is not being used as expected. Then they can make the decision about what they're going to do about it.” Network Engineer, Enterprise, Technology

They are involved in the following Jobs…

  • Maintain app availability (optimize costs)

What are they trying to do?

Quote to cash journey

The Quote to Cash journey is a reflection of the many stages our developers and billing users go through when paying for their usage. It starts with locating a service and ends with paying for their usage of the service, and ultimately how they manage their payment methods.

This project focused on improving a few specific stages in the overarching Quote to Cash journey: Reconciling an invoice (primary goal) and Monitor usage (related goal).

To help the team better understand the needs of our end-users I created a few ideal flows for each of these stages; marrying what I knew to be true about our technical requirements with the needs of the end user. These flows acted as a Northstar for the remainder of the effort.

image

Quote to Cash Journey. Focus: Reconcile invoice & Monitor usage.

Expand to view ideal Monitoring usage flow exploration
image
Expand to view ideal Reconcile invoice flow exploration
image

Use cases

Alongside the journey mapping, I worked with our Researcher and Product Manager to synthesize the findings from our interviews into specific use cases and validate them with our customers, ultimately connecting them back to our Job to be Done statements.

image

Reconcile invoice use cases.

Similar to the ideal journey diagrams, these use cases would act as a critical measuring stick for the design work moving forward.

Understanding the Problem

With a better understanding the user’s goals, we were also able to identify a handful of experience breaking pain points they faced on a regular basis.

Here’s what we found...

10+ Different invoice variations

Due to a variety of back-end factors out of a user’s control, they could end-up receiving one of over 10 different invoices when they’re billed for their usage. Most of the invoice layouts are difficult to parse visually and do not follow brand guidelines.

image

Example: A few of the many different potential invoices a customer might receive.

💬
“The invoices don’t make sense. I have no clue what I’m paying for!” NPS, 0 + 25 others like this

Recommendations

  • Unify the 10+ different layouts/designs into a single invoice.
  • Create a consistent invoice template to be used across regions and account types.
  • Lay out invoice hierarchy in a way that works for both normal and enterprise customers.
  • Update the invoice to follow latest IBM Cloud branding guidelines.

Charges on dashboard do not match invoice

Service names listed in our online usage reports do not match item names on the invoice (often rolled into a single overarching reference name), making it difficult to optimize spending, and rendering it impossible to check if the charges on your invoice accurately map to your usage.

image

Example: Service groupings in the Cloud UI do not match the invoice.

💬
“You have an identifier for Storage. You also have a second identifier for Storage called a Mount Point. But nowhere on the invoice does that align to anything. You could be billing me for something that I shouldn't be billed for or not billing me for something I should be billed for, but I can't possibly cross reference this because there's no way for me to figure it out.” Cloud Operations Coordinator, Enterprise Client + 13 others like this

Recommendations

  • Work with development to ensure content naming & groupings are consistent between the invoice and the UI.
  • Provide a 1:1 reference between invoice and usage details, utilizing deep links to usage in the Cloud UI and a reference-able Invoice number.

Incomprehensible invoice UI pages

Enterprise clients often tally up invoices to send final spend reports to their finance teams. Today they’re required to click into each individual invoice (for large clients this can be upwards of 75 invoices) to confirm the total because our overview table is broken and all invoices read as $0. The invoice page itself is an unstylable iFrame with many content and usability issues.

image

Example: Invoice page in the Cloud UI. $0 line items actually contain charges.

💬
“The invoice amount specifically being zero is really frustrating… Every month I have 30 lines. I now need to click on each individual item to figure out what the invoice amount is. This is really time consuming.”  Cloud Operations Coordinator, Enterprise client +4 others like this

Recommendations

  • Address the bug that causes line items to display as $0.
  • Rework the hierarchy of the invoice page to maximize legibility and follow latest brand guidelines and design patterns.
  • Provide users with a way to search by Invoice # for their detailed usage.

Billing periods inconsistent with industry standards

Billing periods are inconsistent with the industry (every 30 days) and how we allow users to view usage online, making it hard to match charges 1:1 with usage. Alongside that, invoices can also be delayed by 60-90 days. This makes it difficult to predict when a payment will need to be made or stick a budget.

image

Example: Cannot match billing period on the invoice to usage breakdowns in the Cloud UI.

💬
“IBM invoices for VPC usage 60-90 days in the past. This makes it extremely difficult to plan and manage my cloud expenses in a timely manner. With every other cloud vendor I’ve worked with, we normally are billed at the end of the month (or first of the next month), for usage from the previous 30 days. The way IBM does it is super confusing. The billing usage dashboard is for the current month, but invoices for VPC usage are for 60+ days ago.” Chief Innovation Officer, NPS 3 + 8 others like this

Recommendations

  • Lorem

⚠️
Expand sections above for more detail.

Design Explorations

Equipped with an understanding of a billing user’s goals, use cases and pain points, I spent early phases of design exploration mapping out flow concepts for the Reconcile an Invoice job. I focused initially on ways we might minimize the overall number of steps required by the user, while making improvements to things like the page naming and content hierarchy.

image

Final selected flow concept.

Once the flows had been mapped, I shifted my attention to improving the invoice and invoices page. To do this, I needed to gain a better understanding of the common attributes that make up an invoice, as well as how users expected to see their charges grouped.

How should we organize the invoice?

I started by identifying the content that had to be on the invoice.

At a base level, a cloud invoice can roughly be broken out into 3 sections:

  • header
  • body
  • footer

Content in the header and footer is mostly straightforward, things like: billing period, account info and invoice details.

image

The real challenge lies in ensuring charges on the invoice are grouped in a way that makes sense to the user (body section).

How are users actually billed?

During our interviews we learned that most users expect the charges on their invoice to map to their understanding of our billing model. Unfortunately, this often is not the case. Unbeknownst to users there are multiple factors that go into the final charge they see on their invoice beyond the plan they’ve selected for a given service. To better understand this, I created a diagram that illustrates the factors that go into IBM Cloud’s billing model.

image

How services are billed on IBM Cloud.

How can we simplify this on the invoice?

After understanding the billing model, my next step was to determine the best way to group a user’s charges in a way that meets their expectations. To accomplish this, I mapped out various approaches we could take ranging from most granular to least granular.

image

Exploring how to group charges on the invoice.

With an initial perspective on the potential approaches to organizing the charges on the invoice I started creating different explorations based on each one.

Sketches & Design Iterations

Over the course of 6 months I went through 20+ iterations, making adjustments based on scope changes, feedback from Support Reps, feedback from the brand team and users.

image

Invoice evolution based on continuous feedback loop.

Outside of the initial recommendations I captured above in the Understanding the Problem section, a few additional improvements were identified in the sketching phase:

  • Making the invoice number more prominent could help both users and support reps more quickly identify their invoice in a sea of numbers.
  • The final invoice charge should be noticeable at a glance.
  • Users really care about seeing their discounts.
  • Charges from multiple months can appear on an invoice as an adjustment - this is a point of confusion for users as adjustments are currently grouped with all other charges.

Elephant in the room: Scoping

Before diving into the usability tests it’s important to note that a few key features from our initial designs had to be cut due to scoping issues, this includes:

  • Surfacing discounts at a service level
  • Surfacing individual discount totals on the invoice summary
  • Surfacing charges for a specific instance of a service
  • Separating the Plan from the Service name
  • Allow users to customize the granularity of their invoice

These items would be prioritized for a future iteration.

Usability Testing

After months of back and forth with our localization teams, developers and support, we were able to put together an invoice + invoice page prototype worthy of testing.

The concept tested ultimately grouped content by Service + Plan and then by Metric since providing Instance specific details would be out of scope, and separating the Plan from the service name was not possible for MVP.

image

Example above shows charges grouped by Service + Plan and then by Metric.

Test goals

  • Can a user identify the total cost of the invoice?
  • Can a user identify the cost of a specific service or metric?
  • Can a user identify the billing period for a given invoice?
  • Can a user locate an invoice in the Cloud UI for a specific billing period?
  • Can a user identify an adjustment vs a charge in their current billing period?
  • Can a user match charges on their invoice to the charges they see on the Cloud Usage dashboard for the same billing period?

Test learnings

  • 30/30 participants were able to identify the total cost of the invoice.
  • 30/30 participants were able to identify the cost of a specific service using the invoice.
  • 27/30 participants were able to identify the invoice billing period.
  • 25/30 participants understood the invoice was organized by service and plan.
  • 23/30 participants understood the “Adjustments” section, recognizing those charges as usage that accrued in prior months.
  • 30/30 participants were able to match charges on their invoice to charges seen on the Cloud Usage dashboard for the same billing period.
  • 30/30 participants expected to see discounts broken out by service or metric.

Finalizing Designs

I worked with our researcher to synthesize the feedback from the user feedback sessions and translate into a final invoice template design and updated invoice page. Due to some technical scoping issues we were not able to address feedback related to line-item discounts and showing service instances; to be addressed in a future iteration.

Final invoice template design

Pictured below is an example of my final invoice template adopted for a US customer paying by Purchase Order. Worth noting, I worked extensively with the CIO office to ensure the template could be adapted to 18 different regions (and languages), any desired currency, and support both Purchase Order and Credit Card scenarios.

image

Invoice improvement notes

  • Single invoice template with consistent IBM Cloud branding.
  • Template easily adjusted for any geo, currency, or payment type.
  • Invoice number prominent at the top of every page for quick reference.
  • Direct link from invoice to the IBM Cloud Usage dashboard, filtered for the same billing period. Ensures users can explore charges in greater detail if desired.
  • Improvements to invoice content hierarchy. Specific sections for: invoice details, personal details, payment details, charges, adjustments, summary, and remittance details.
  • Billing periods shifted to calendar months to match industry standards, clearly called out at the top of the invoice. Charges section also broken out by month.
  • Total due and payment methods (PO info / Credit Card due date) front and center of page one, not to be easily confused with individual charges.
  • Charges grouped by Service, Plan and then Metric to help users better understand how they’re being billed and where a usage spike occurred (ideally we could show instance).
  • Services show pre-tax, tax, and total charges (Discounts to follow shortly).
  • Footer on each page with quick access to support and the user’s Cloud account ID.
  • Separate section for adjustments to illustrate when a user is being refunded for a charge and the original invoice the charge originated from.
  • Summary section that outlines the totals and taxes that result in the final charge.
  • Common terms & conditions section that can be tweaked to surface remittance details, bank info, or any other legal information related to making a payment.

Final invoices page design

Along with the new invoice templates, I worked on delivering an over of the Invoices page in the IBM Cloud Billing experience. Outside of the updated visuals and layout improvements, we were able to fix bugs with the existing page and implement a number of quality of life improvements.

image

Invoice page improvement notes

  • Fixed the $0.00 invoice bug. All totals reflect the actual amount a user will be charged.
  • Page no longer an iframe, allowing us to make layout and visual improvements.
  • Page updated to use IBM Cloud components, updated to meet brand standards.
  • Invoice number easily referenceable between the UI and invoice.
  • Billing period clearly called out for each line item. Invoices sorted by billing period.
  • Introduction of an “Invoice Type” attribute so users can more easily identify an invoice that is a monthly charge, one-time charge, or an adjustment.
  • Improved and consolidated “Invoice Status” attribute. Clearly calls out which invoices have been paid and which ones are awaiting payment.
  • New search and filter options let a user search for a specific invoice by invoice number, filter by invoice type and invoice status.
  • Columns are sortable so that users can skim invoices by different attributes.
  • Introduction of a “View usage” link that lets users view their usage dashboard and analyze charges in as much granularity as they might want.

Impact

“I can see everything (invoice totals) in one place now? Holy crap on a cracker, I’m a happy girl! Wow!” Cloud Operations Lead Enterprise Client

Outcomes

⚠️
For specific experience improvements see Finalizing Designs section above

Negative NPS comments directly referencing invoicing reduced by 18% (From 22% to 4%).

Support tickets related to invoicing reduced by ~72% (From 1000-1600 tickets per month to 250-450 tickets per month).

Support costs related to invoicing reduced by ~70% (From ~1M/month to ~300k/month).

New single, scalable invoice template, to replace the 10+ existing invoice variations that exist across the platform and in countries IBM does business with (From 10+ to 1).

97% of users stick with the new Invoices page as opposed to reverting to the old one.

~37% decrease in visits to the invoice detail pages (a sign the new invoice works!).

2nd Place winner of the IBM Finance and Operations Client Advocacy Award.

What I would do different

[Coming soon]