AutoPay Flexibility
AutoPay failures at Spectrum Mobile were not random. They were systematically created by the product itself.
Customers were assigned fixed debit dates tied to billing cycles, regardless of when they actually got paid. That mismatch caused avoidable payment failures, triggered a $5 failure fee, and drove repeat calls, escalations, and trust erosion.
The business problem was not AutoPay adoption. It was failure rate within AutoPay. This project introduced controlled flexibility into the billing system so customers could align payment timing with their income, without increasing financial risk to the business.
This project shows how I work when customer trust, billing logic, collections risk, and communication systems all collide. What looked like a small feature request was actually a product and operations problem with financial consequences.
AutoPay is supposed to reduce billing friction. Instead, it was creating it.
Spectrum Mobile relied on AutoPay as a core collections mechanism, but the experience was rigid. Once enrolled, customers had no control over when their payment would draft. Debit timing was fixed to the billing cycle, even when it did not align with the customer’s pay schedule.
That rigidity created a predictable failure loop: the system attempted payment before funds were available, the payment failed, a fee was applied, and the customer blamed the company for a problem they did not feel they caused. From the customer’s perspective, the experience felt punitive. From the business perspective, it drove avoidable contact and collections friction.
- AutoPay dates were assigned automatically with no customer input
- Draft timing often did not match paycheck timing
- Customers were hit with a $5 failure fee after an avoidable failure
- No clear self-service path existed to resolve the issue
- Repeated AutoPay complaints became a persistent call driver
- Failure fees created unfairness narratives that damaged trust
- Billing friction early in the customer lifecycle increases churn risk
- Date flexibility was a lower-cost intervention than removing AutoPay requirements
This was not just a UX improvement. It was a failure-reduction initiative inside a billing system, with direct implications for support cost, collections performance, and customer trust.
The system was creating avoidable failures, then charging customers for them.
Customers needed a way to align AutoPay with how they actually manage cash flow. Without that flexibility, even responsible customers could fail simply because the product drafted at the wrong time. The experience broke the basic promise of AutoPay: convenience and predictability.
I didn’t know it would take the money that day. My paycheck comes in two days later.
Why am I getting charged $5 for something I wasn’t allowed to control?
I’ve called multiple times about this and no one can change the date.
- No date-selection UI existed in self-service
- Agent and IVR pathways could not fully resolve the issue
- Business logic was invisible, so customers experienced it as arbitrary
- Communications did not help customers understand what would happen next
- More preventable payment failures
- Higher fee complaints and escalations
- Increased support cost for something self-service should solve
- Greater trust erosion around a financially sensitive moment
There was no single user flow. The experience had to work across multiple account states and channels.
I mapped the problem across five customer scenarios: customers in good standing, customers exploring dates before committing, delinquent customers, customers re-enrolling after hard decline, and customers entering through assisted channels like IVR or chat. The design had to support different needs without weakening billing controls.
- Customers learn date flexibility exists through app, web, IVR, or communications
- The value proposition is simple: choose a date that works for your budget
- Support channels reinforce the same rules customers see digitally
- Customers review available dates in a constrained calendar
- Unavailable dates are disabled and explained
- Current AutoPay setup is visible before the customer makes a change
- Customer selects a date and re-accepts the AutoPay agreement
- The system applies the change next cycle, not immediately
- Confirmation messages reflect the exact chosen or restored date
Delinquent customers were intentionally handled differently. Instead of exposing date flexibility immediately, the experience required past-due balance resolution first. This let the business protect collections while still making flexibility available once the account was current.
Journey map showing the experience across awareness, date selection, confirmation, and downstream billing outcomes, including failure and recovery paths.
Use-case mapping across customer conditions, account states, and service channels including IVR, chat, mobile app, and Spectrum.net.
Flexibility had to be meaningful to customers, but bounded enough to protect the business.
The design challenge was not just exposing options. It was making constraints understandable and fair. Customers needed to know what they could change, when it would take effect, and why some paths were blocked.
| Rule | Customer meaning | Design implication |
|---|---|---|
| Date range: cycle day +1 to +26 | Customers can choose from a limited but meaningful window | Calendar only exposes valid dates; invalid dates are disabled with explanation |
| Changes take effect next billing cycle | Today’s update does not affect the current in-flight payment | In-flow messaging must state exactly when the new date becomes active |
| Account must be current | Past-due customers cannot unlock date changes immediately | Blocked state shifts to a recovery path with clear reason and payment CTA |
| Failure fallback applies a default date | If a request fails, the system still lands on a defined outcome | Customer must be told what date applied and why, instead of experiencing silent failure |
| Hard decline re-enrollment restores prior date | Customers do not lose prior preferences when re-enrolling | Confirmation flow must reinforce restored date clearly |
| Agreement re-acceptance required | Date change is treated as an updated enrollment action | Legal confirmation must feel intentional, not like unnecessary friction |
| Unlimited future changes allowed | Customers can adjust if their circumstances change | No lockout logic; re-entry remains available when eligibility rules are met |
I designed for invalid dates like the 29th–31st, API failures mid-flow, changes attempted during active payment processing, restored dates after hard decline, and retry behavior that shifts relative to a newly chosen AutoPay date.
This was not a UI problem. It was a risk versus flexibility tradeoff.
The core work was deciding how much flexibility the system could safely allow, for whom, and under what conditions. My role was not just translating business requirements. It was helping shape an experience that solved the customer problem without creating new payment risk.
Letting customers choose any date would feel simple, but it would break billing logic and increase failure exposure. I supported a controlled +1 to +26 day window that gave customers meaningful choice without creating operational chaos.
I designed a blocked experience for past-due accounts rather than exposing full date change access. This preserved collections priorities while still making flexibility a reward once the account was brought current.
Immediate application sounds customer-friendly, but it would create reconciliation and downstream support issues. I aligned the experience to next-cycle activation and made that timing explicit before confirmation.
If the system could not apply a requested date, customers needed to know what happened. I designed visible fallback messaging and communications so the experience remained predictable even when the ideal path failed.
The hardest part of this project was not visual design. It was deciding how to balance customer control, billing constraints, legal requirements, collections logic, and communication clarity without undermining trust.
I was not just executing requirements. I was shaping the experience boundaries.
Senior product work is not just about making requirements look clean. It is about knowing where to push back, where to simplify, and where the business needs a more honest experience.
- Rejected the idea of unrestricted date selection because it created too much payment and operational risk
- Supported delinquency gating so collections recovery happened before flexibility was unlocked
- Pushed for explicit fallback communication instead of letting the system fail silently
- Aligned teams around next-cycle enforcement even though immediate change would have been easier to market
- Ensured communication rules were designed alongside product behavior, not treated as an afterthought
The product would fail if the communication system told a different story than the UI.
AutoPay date flexibility did not live on one screen. It affected confirmation flows, billing reminders, one-time payment experiences, IVR messaging, and recovery states after failure. I treated communications as part of the product, not supporting copy.
- Date changed confirmation showing old date and new date side by side
- Fallback/default date notification explaining what date was applied and why
- Hard decline re-enrollment confirmation reinforcing restored AutoPay timing
- Statement-ready messaging to reinforce chosen AutoPay timing
- One-time payment confirmation to reflect upcoming debit expectations
- AutoPay success confirmation aligned to customer-selected date
- Payment method update messaging carrying date logic forward
- IVR language updated so assisted channels did not contradict self-service
Final communication examples showing how the chosen date was carried through confirmations, statement-ready messaging, and follow-up notifications.
I wasn’t designing a feature. I was redesigning a failure loop inside the billing system.
My role was to identify where failures originated, determine which constraints were non-negotiable, and introduce flexibility without creating new financial risk. This work required coordination across billing, digital product, credit services, legal, agent tooling, and communications.
I traced the loop from fixed debit timing to failed payment, fee application, complaint, and escalation. That moved the conversation from “customers want more control” to “the product is creating preventable failure.”
I defined experience branches for current customers, delinquent customers, hard-decline re-enrollment, and assisted channels. This prevented the team from designing only for the happy path.
Each business rule became a specific UI state, message, or recovery path. My focus was making system logic legible so customers felt informed instead of blocked by arbitrary rules.
I mapped what needed to change not only in the app and web experience, but also across confirmations, support touchpoints, and downstream billing communications so the customer always saw one consistent story.
I used journey maps, use-case tables, rule mapping, and flow documentation to align stakeholders across product, billing, communications, credit services, and legal. The goal was not just approval. It was shared understanding of how the system should behave.
A guardrailed date-selection system that made flexibility feel controlled, predictable, and fair.
The final experience gave customers real agency without hiding the rules. Customers could choose from valid dates, understand exactly when the change would take effect, and recover cleanly when the ideal path was not available. The system became more transparent without becoming looser.
Customers choose from valid dates within the allowed range, with invalid or unavailable options clearly disabled and explained.
Before confirming, customers see that the change applies next cycle, reducing the chance of immediate confusion or downstream contact.
Delinquency blocks, fallback dates, and hard-decline re-enrollment all have intentional behaviors and corresponding communication, rather than invisible system logic.
The product moved from a rigid collections mechanism to a controlled flexibility system. Customers gained a sense of agency. The business kept the guardrails it needed.
What this project demonstrates about how I work.
- I work best where customer trust, payment logic, and operational constraints intersect
- I do not treat business rules as copy to surface; I treat them as product behaviors to design intentionally
- I think in systems, not screens, especially when communications and downstream workflows affect the experience
- Measure which dates customers select most often and correlate that with payment success rate
- Track call-driver reduction tied specifically to AutoPay date complaints and fee disputes
- Test which explanation patterns best reduce confusion around “effective next cycle” timing
- Add a persistent “next AutoPay date” surface on billing home to increase visibility after setup
This case study is less about a date picker and more about designing a financial system customers can trust. The UI mattered, but the real work was shaping how billing logic, collections strategy, and communication behavior came together in one coherent experience.
Want to talk through this work?
I’m open to Senior and Principal Product Design roles across FinTech, SaaS, enterprise systems, and complex workflow products.