Product design · B2B payments

Airgas Autopay

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

Duration: Oct 2024 – June 2025
My role: Senior Product Designer; sole designer on the feature, owning design end to end from scoping through launch, working with 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.

Context

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.

The real problem

Enrollment had to work for two fundamentally different users: authenticated customers managing many accounts, and guests enrolling a single account without logging in. One flow couldn’t serve both without penalizing one of them: guests would face account-management overhead they didn’t need, or multi-account customers would lose the tools they did.

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

Two experiences, not one

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: customers with many 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.

Living with the feature

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.

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: enrollment as a share of eligible accounts (the eligible base wasn’t available to me at launch), failed-payment and card-decline rates, unenrollment within 90 days, and support contact volume on payment issues: the numbers that would tell us whether enrollment converted into durable self-service.