Product design · B2B & B2C payments

Airgas Autopay

10,000 accounts enrolled in the first month after launch
90% of customers who initiated enrollment completed sign up

Duration: Oct 2024 – June 2025
My role: Senior Product Designer, owning design end to end from scoping through launch
Team: 1 PM and the dev team
Tools: Figma

Airgas customers could only enroll in autopay through a manual SAP process: printed forms, mailed or faxed. I designed a self-service enrollment experience for two very different user types. In the first month after launch, 10,000 accounts enrolled, and 90% of customers who started enrollment completed it.

The Problem

Autopay enrollment lived entirely outside the product. Customers filled out paper forms and mailed or faxed them to be processed manually in SAP. Every enrollment cost the customer days and cost Airgas manual processing work.

Airgas paper autopay authorization form with checkboxes for invoice types and instructions to return it by U.S. mail or secure fax — The before state: a printed authorization form, returned by mail or fax and processed manually in SAP.

Enrollment had to work for two fundamentally different users: authenticated customers managing many accounts, and guests enrolling a single account without logging in.

During scoping, I used Gemini to synthesize our meeting decisions into a guest-vs-authenticated feature matrix. That matrix became the checklist we scoped v1 against and settled which capabilities each user type actually needed.

Decision 1

Authenticated vs. Guest Users

We split guest and authenticated enrollment into separate experiences. A single flow would have forced a compromise on both sides; splitting let the guest path stay minimal (enter account info, enroll, done) while the authenticated path got real multi-account management.

Two side-by-side flowcharts of Autopay for Airgas.com: the authenticated user flow with enrollment and settings-management branches, and the separate unauthenticated guest flow with account and invoice validation branches — The fork, mapped: authenticated enrollment with settings management on the left, the guest flow with its validation branches on the right: two structures, deliberately.

Decision 2

Full-screen over modals

The initial flow ran entirely in pop-up screens. Two things broke as we tested it against real account structures: the edge case of customers with hundreds of accounts couldn’t see enough account context inside a modal to know what they were enrolling, and the multi-step flow gave no sense of progress; users couldn’t tell where they were or how much was left. I moved enrollment to a full-screen, stepped experience with persistent account context and visible progress.

Early iteration: a Select Accounts pop-up dialog listing ship-to accounts with checkboxes, covering the page behind it — An early modal iteration: account selection in a pop-up, with little room for account context and no sense of progress.

Full-screen autopay enrollment step for selecting a payment method, with a five-step progress bar across the top — The final direction: full-screen enrollment with visible stepped progress.

Decision 3

Losing the dual-table view

I wanted enrolled and unenrolled accounts visible side by side, so customers could compare and act in one view. Engineering found the dual-table design technically infeasible; the way enrollment data lived in SAP couldn’t support the combined view. Rather than ship a degraded version of it, the final design preserves the need with tabbed views: customers switch between Enrolled and Not Enrolled on the same screen, so the compare-and-act loop survives even though the side-by-side layout didn’t.

The switcher itself uses radio buttons rather than literal tabs to maintain consistency: features in the other tabs of the same screen already use radio buttons for this kind of switching.

Killed exploration: one screen stacking an Enrolled in Autopay table above a Not Yet Enrolled in Autopay table — The killed exploration: enrolled and not-yet-enrolled tables in one combined view, which SAP’s enrollment data couldn’t support.

Shipped autopay screen with an Accounts Enrolled / Accounts Not Yet Enrolled toggle above a single account table — What shipped: Enrolled and Not Yet Enrolled as switchable views on the same screen.

Easily Edit Autopay Settings

Enrollment isn’t a one-time event, so the design covers the full lifecycle. Customers can change invoice enrollment type, swap payment methods, and unenroll accounts at any time.

Select Invoice Enrollments dialog with checkboxes for All, Product, Rent, and Lease invoice types over an account management table — Managing enrollment after the fact: changing which invoice types an account has enrolled.

Failure and edge states

Autopay touches saved payment methods on real accounts, so the design covers the states between the happy paths: invalid entries, duplicate enrollments, consequential actions, expiring cards, and the system itself failing. Each state is specific about what went wrong and what happens next.

Guest autopay entry form showing an inline Invalid Account Number error beside the annotated invoice guide — Entry validation, recoverable in place: a specific inline error with the entered values preserved.

Modal stating this account is already enrolled in autopay, asking for an account that has not yet been enrolled — The duplicate-enrollment guard: already-enrolled accounts are stopped before the flow starts.

Confirmation modal asking are you sure you would like to unenroll in autopay, warning that you will have to enroll again — Consequential actions get a deliberate step: unenrolling says what it costs before it happens.

Enrolled accounts table flagging a payment card as expired in red — Cards expire on their own schedule: the enrolled table flags expiry right where the fix lives.

Enter Credit Card modal showing a card-save failure banner and an inline expiration-date-cannot-be-in-the-past error — The card step validates in place: save failures and past expiration dates caught before enrollment.

Autopay management tab showing a banner reading your request could not be processed at this time, please try again later — And when the system itself fails: an honest try-again-later instead of a dead end.

Outcome

10,000 accounts enrolled in the first month after launch.
90% completion rate: of customers who started enrollment, 90% reached the confirmation screen (measured via the enrollment analytics funnel).

What I’d watch next: failed-payment and card-decline rates, unenrollment within 90 days, and support contact volume on payment issues. These are the numbers that would tell us whether enrollment converted into durable self-service.