Reducing call volume by improving self-service, through a strategic roadmap and design ownership across four releases.

Anchoring the work in the data we had.

A trailing-twelve-month inventory of support call topics with transcripts of what customers said when they called. Web analytics across the portal (which pages were used, which were abandoned). A customer survey with the end users. Stakeholder working sessions with AmeriGas's design experience team.

I synthesized all of it into the user model that shaped this strategic roadmap.

The Opportunity Roadmap

The Release 1 deliverable was a phased roadmap, anchored by the call data. Every opportunity was ranked against the research we had and assigned to one of three phases:

The top of the roadmap was where the calls were heaviest: delivery scheduling, billing inquiries, account management. Sequencing came from backend constraints and level of effort. Delivery scheduling and tracking, for example, depended on data the platform couldn't yet surface. Those went into Full Redesign.

Behind the roadmap was a multi-section recommendations document. Every opportunity paired with a Quick Win, a Next Phase, and a Full Redesign option, each carrying the actual design changes worked out for that section. Those designs are covered by NDA. Parts of them are shown as modified examples in the deck below.

DESIGN RECOMMENDATIONS

Three implementation phases for AmeriGas's highest-impact customer experience opportunities.

Quick Wins Next Phase Full Redesign

DESIGN RECOMMENDATIONS · 01 DELIVERY

The highest-volume opportunities.

The design changes we recommended to AmeriGas for the delivery experience.

• Delivery Status Tracking. Dashboard visibility, status tags, FAQ for delay context.
• Delivery Scheduling Process. Tank-low banner, price confirmation in the flow, abandonment safeguards.
• Delivery Method Change. Will Call to Auto-delivery toggle, pause and suspend visibility.
• Delivery Modification & Cancellation. Direct cancel with reason capture, priority alignment.
• Tank Alerts & Communication. Combined tank and delivery interface, notification preferences.

DESIGN EXAMPLE · 01 DELIVERY

What the delivery recommendations looked like.

Screens modified, part of the quick win and full redesign.

Quick Win

Full Redesign · drag to compare

Now Redesign

⇆

DESIGN RECOMMENDATIONS · 02 BILLING & ACCOUNT

Invoice clarity, dispute friction, payment flows.

The design changes we recommended to AmeriGas for billing.

• Billing Disputes. Replace dispute form with chat redirect on the dispute link.
• Billing Inquiries. Regroup billing items for visibility, line-item tooltips for invoice comprehension.
• Payment Rejection & Processing. Updated error messaging, inline guidance on rejection reasons.
• Payment Programs & Methods. Dashboard promotion of payment programs, payment-flow banners.
• Account Profile. Modified account screens for clearer visibility into the user's profile section.

DESIGN EXAMPLE · 02 BILLING

What the billing recommendations looked like.

Screens modified, part of the quick win and full redesign.

Quick Win · redirect to chat

Full Redesign · dispute management

DESIGN EXAMPLE · 03 ACCOUNT SUMMARY

What the account summary redesign looked like.

Screens modified, part of the full redesign.

Full Redesign · account overview

CLIENT FEEDBACK

Recommendation. Feedback. Response.

Client feedback

“We don’t have the data to surface real-time delivery status.”

→

Our response

An FAQ pattern explaining the general reasons for a delay, plus a delivery range drawn from historical data when one happens.

← 1 / 7 →

A section-by-section view of the recommendations deck. Each opportunity carried a Quick Win, Next Phase, and Full Redesign option, paired with user benefit, engineering dependency, and priority rationale. Full deck and the complete client feedback dialog available under NDA.

One login per account.

myamerigas was built on a one-login-per-SAP-account model. For a single home with one person managing it, that's the right model. But plenty of customers don't fit that shape, from a homeowner with a vacation property to a team managing buildings across states.

The product couldn't scale for the different types of users using it.

What I designed.

Three interconnected systems.

A role and location permission model

An Online Account Admin role with the authority to invite child users, assign capabilities, and grant access by location. Five capability roles sit underneath:

Billing users manage invoices. Delivery users request and track. Admin users manage the team. The role structure mirrors how a real account divides the work, whether that's a household with a few properties or an organization with many sites.

An admin interface with two mental models

Operations managers and property managers think about the same data differently. An ops manager thinks "who has access to what." A property manager thinks "who's responsible for this building."

Forcing one mental model on both audiences was the wrong call. I built a toggle: View by User or View by Location. Same underlying permissions data, two different information architectures.

A child-user invite and registration flow

The detail I'm proudest of

An admin can't be deleted while child users exist underneath them. The system requires admin transfer before deletion.

It's the kind of edge case that breaks accounts in production if you skip it.

What shipped

AmeriGas had no native app.

The data showed more of myamerigas's traffic coming from mobile than from desktop. Customers were already managing propane from their phones, tank levels, delivery requests, payments, on a responsive site that worked but was never built for a phone. That gap is what prompted a native app.

Built phone-first for the customers already managing propane on mobile.

Two design decisions worth surfacing

Information density

myamerigas on desktop is a dashboard. Multiple cards, multiple data points, multiple actions visible at once. On mobile, that's not navigable.

I had to decide which data is decision-driving on a phone and which is reference. Tank level and delivery status are decision-driving (do I need to order?). Account activity history is reference (let users dig if they want, but don't make it the first screen).

The state-based CTA

The home screen tied delivery and tank status together, with a dynamic CTA that surfaces the action each state calls for:

• Tank low → "Request a delivery"
• Tank full → "View delivery schedule"
• Auto delivery active → "View next delivery"

Same screen, different priority based on state. The screen earns its place by being predictive, not passive.

In progress.

The current release is the AmeriGas marketing website: the public-facing site that introduces propane services, supports signups, and helps existing customers find the portal.

Different surface from the customer product. Same end users.