Scaling pricing to charge for diverse requirements

The Context

What is Airspace?

Airspace is a time-critical logistics company that specializes in shipping goods across various industries like aerospace and hospital/health systems.

For each order, customers are provided an instant quote based on parameters like the package information (such as its weight) or route information (such as the miles driven between pickup and drop-off). This quote is based on pre-agreed rates, which are configured on each customer's account by Airspace's customer success and/or finance members.

Initial Business Problem

While the initial request focused on supporting pricing for European expansion, preliminary research shifted our objective toward scalability

A fellow product designer and I had conducted the following activities to gain more context on what "European pricing" meant:

We concluded that our system needed to handle more than just "European rates," as there were already plans to expand our business beyond Europe. While unclear what exactly that pricing model looked like, we reframed our project to look at the underlying problem of system scale for future business expansion.

Refined Business Problem

Airspace's global expansion and complex, unique shipping requirements increasingly exposed our pricing system's limitations

The volume of incoming requests to integrate new rate updates into upfront quotes exceeded R&D's capacity to implement them.

This created several ripple effects:

These inefficiencies ultimately hindered our revenue growth and profit margin.

The Challenge

How might our pricing system accommodate an assortment of complex customer and business needs?

Defining the Vision

The challenge of addressing new customer requirements extended across multiple departments

When Airspace introduced new services like global shipments, we would often build one-off solutions to address complex needs. However, this approach led to inefficiencies across the company, creating hurdles for internal teams and a disjointed experience for customers.

As a result, the project then evolved even further to be part of an overarching product strategy to address broader organizational challenges affecting our internal teams, customers, and product.

Brainstorm

Design facilitated cross-functional brainstorm sessions to define six ideas to scale

We parsed these solutions down into six major concepts across the different areas of our business. These concepts were centered around the theme of scalability and self-service, as we wanted to create a new system that could empower our internal teams to quickly support new services, without R&D involvement.

For the bulk of this case study, I will focus on two of them:

Paper Prototyping

My team used a low-cost approach to assess how participants interpreted the language and behavior of this new system to validate our solutions

Using paper cutouts to represent concepts, inputs, and actions, participants interacted with the system while we simulated its reactions, enforcing rules, providing context, and adding cutouts where appropriate.

Overall, users understood the general concepts; the only considerable change was renaming "constraints" to "conditions." Given the scale of work involved, the different concepts were to be distributed into different projects across various product teams.

Scoping the Project

To deliver immediate value, we scoped the project to remove dependencies on the other concepts being built

From aligning with my product team, we determined that the various service and charge configurations would still require significant development. Additionally, other product teams that would develop the other features were not yet ready to start designing and developing.

Instead, we decided to model one service to use to build the new features. Over time, we could iterate and expand by adding in more configuration options and retrofitting existing rates, providing us with a clear, future roadmap.

Additional Research

The “Dangerous Goods” service was used as the first model, as there was more nuance to its pricing than the system currently could handle

Through support tickets, documentation, 3 interviews, and 2 shadowing sessions, I discovered that the finance team reactively zeroed out dangerous goods rates only after customer complaints. While the system charged solely based on a "Yes" banner response during order entry, the business also desired to determine whether or not to apply a charge based on the specific category of item (such as an aircraft part or tire) that was being shipped.

Since the logic to charge was straightforward to, widely applicable, and independent of other features, we used dangerous goods as the first case to launch the new pricing system.

Feature Prioritization

I worked with my team to cut scope on ideas from initial brainstorming, but tested as dead weight

For example, we concluded that the different "types" of service ultimately did not have any clear user and business value, so we scoped out developing several of those options.

User Flows

I mapped 6 user flows across multiple user groups, which led to a reassessment of the prioritized features

Upon assessing the flows with my team, the strategist, and design manager, we realized:

I then re-prioritized what features would be built, shelving the ambiguous ones as opportunities for future iterations.

Usability Testing

Two different concepts for customizable rates were tested across 7 users to determine a preferred solution

After narrowing down two concepts to test from four different variations (two were dropped due to technical constraints and usability concerns), I observed any user misclicks and discussed their preference to get a direction of which UI to implement.

Testing results indicated a stronger preference for the second variation, as users indicated they preferred being able to access all the editable properties at once.

Refining Customizable Charges

Scalability also had to be factored into the UI, so the design went through another round of ideation

More display space was needed to accommodate conditions that could expand into long text statements.

From ideating solutions with the design team, I finalized a design that stored the form to create/edit charges in a side panel. This provided a clearer information architecture and would be more suited for scaling conditions.

Final Designs

What shipped: A services library and configurable charge builder

Services Library

Internal users could create services to define customer or business needs. Services could also be used in other system concepts:

Customizable Rate Sheets/Charges

Our finance team could add services onto rate sheets. This segmented any unique services and its pricing to a given customer's rate sheet.

Charges could be configured for a service. How it is charged is defined by the charge type chosen, such as charging it as a flat rate, per piece weight, etc.

Conditions would encompass a variety of order data over time, so that the finance team could be exact in how to charge for a service. In addition, surfacing this logic in the UI would remove any confusion around the logic for a charge, which was a common user challenge I had found early on through interviewing users.

Results & Impact

Billing errors for dangerous goods were cut by 23% with zero manual financial intervention to adjust its charges

Post Release Challenges

Over time, the new pricing system was not adopted as expected due to a number of factors

As a result, additional iterations from our team was deprioritized.

Reflection

Constant collaboration kept the work moving, but it couldn't guarantee the vision stayed connected across teams

While proactively raising risks and running alignment exercises created the impression of a shared vision across teams, the true challenge emerged during the actual build phase. As implementation progressed, new constraints and shifting priorities altered how we could execute that vision. In hindsight, rather than assuming early buy-in would hold through implementation, I would design the initial system to better accommodate a partial rollout from the start.

Next Steps

The spirit of scalability and flexibility was carried onto another project

The adoption gaps directly shaped a follow-up project to simplify the system. The complexity that slowed adoption here, particularly around conditions and interdependent rollout, were factored into a later initiative.