CX + Systems + UX (Mobile Billing)

AutoPay Flexibility (Choose Your Debit Date)

Mobile customers were pushed into AutoPay, but had no control over when funds were withdrawn. When AutoPay failed, customers were charged an AutoPay failure fee ($5)—even when the failure was triggered by misalignment with paycheck timing. The result: angry complaints, avoidable failures, and a spike in “why can’t I change this?” calls.

This project introduced a guardrailed debit-date selection experience in mobile billing—designed to give customers control without breaking billing-cycle constraints or increasing support volume.

📱 Mobile-first wireframes + edge cases
🧠 Call-driver + complaint-driven design
🛟 Failure recovery + retry clarity
🧩 Constraints made legible
AutoPay Flexibility hero visual
Case study
Debit-Date Choice + Guardrails
What you’ll see
CX context → constraints → journey + comms → wireframes + edge cases → market comparison → solution story. Plug in real metrics later using the placeholders.
Jump to: Context Problem Goals Constraints Journey & Comms Wireframes & Edge Cases Competitive Analysis Solution Results Next steps
Role

CX Analyst / UX Designer (end-to-end story + artifacts)

  • Translated billing rules + constraints into an understandable customer experience.
  • Mapped edge cases + failure modes into mobile wireframes (calendar selection, invalid dates, API failures).
  • Aligned communications + UI states so the story stays consistent across channels.
Customer problem

Customers were expected (and often pressured) to use AutoPay but had no control over debit timing. When AutoPay failed, customers were charged a $5 failure fee. Without flexibility, customers couldn’t align withdrawals to paycheck timing—creating frustration, failures, and complaints.

  • “Why do I have to be on AutoPay?”
  • “Why can’t I choose my own debit date?”
  • “AutoPay failed and you charged me $5?”
Outcomes (placeholders)

Replace these with real numbers later. If you don’t have results yet, keep them as Targets + measurement plan.

AutoPay failures Target: [-X%]
Reduction in payment failures attributable to timing misalignment.
$5 fee complaints Target: [-X%]
Fewer complaints/escalations tied to the AutoPay failure fee.
Self-serve adoption Target: [+X%]
Customers successfully selecting a debit date without calling.
Call driver reduction Target: [-X%]
Reduction in “change AutoPay date” / “when will you debit?” calls.
Tip: if leadership cares about cost, convert call reduction to savings and add a “monthly avoided calls × cost per call” estimate.

Context

AutoPay is a “trust product.” Customers interpret it as a promise: withdraw funds on a predictable date. In mobile billing, customers were frequently driven toward AutoPay, but the system didn’t give them meaningful control over debit timing. When payments failed, customers were charged a $5 AutoPay failure fee. Customers experienced the combination as unfair: forced behavior + punishment + no flexibility.

What customers were experiencing
  • AutoPay expectations without control over withdrawal timing.
  • Payment failures when debit dates didn’t match paycheck cycles.
  • $5 failure fee creating anger, distrust, and escalations.
  • Low confidence in the system (“this will fail again”).
Why this became a CX priority
  • First-bill and early-life billing issues are high churn risk moments.
  • Failure fees intensify negative sentiment and “rip-off” narratives.
  • Support volume increases when rules are invisible and outcomes feel random.
  • Flexibility is a controllable lever that reduces failures without removing AutoPay.
Senior-level framing

This wasn’t a “build a date picker” request. It was a complaint-driven, trust-repair effort: reduce failure-triggered fees and prevent avoidable calls by making debit timing controllable and predictable.

Problem statement

Mobile customers needed a clear way to choose their AutoPay debit date and understand how failures would be handled. Without date flexibility, customers couldn’t align withdrawals to paycheck timing—leading to avoidable failures, $5 failure-fee complaints, and high support contact rates.

Goals

The goal wasn’t simply “more AutoPay.” The goal was more successful AutoPay with fewer fee-trigger events and fewer calls.

Customer goal Align debit timing to paycheck date with clear confirmation and predictable behavior.
Business goal Reduce AutoPay failures and the downstream $5 fee complaint volume.
Operational goal Reduce contact drivers by making constraints, retries, and next steps obvious.
Placeholder: Targets (fill with real numbers later)
Add a simple slide with targets (even if results aren’t available yet):
Target: -X% AutoPay failures
Target: -X% $5 fee complaints
Target: -X% calls for “change date / when will you debit”

Constraints & guardrails

Flexibility must be bounded. The design had to respect billing cycle logic and avoid creating a new class of payment failures. The UX job here is to make those constraints visible and understandable.

Customer-visible guardrails
  • Eligible date range and “why not available” explanations.
  • Invalid dates blocked (e.g., 29/30/31 when not applicable).
  • Clear “when will this take effect?” messaging.
  • Unmissable confirmation: success toast + updated Manage AutoPay screen.
System realities
  • Bill cycle boundaries and statement cut timing.
  • Downstream payment processing dependencies.
  • API failures must fail safe (no partial, confusing states).
  • Communications must match system truth (no “marketing promises”).
Placeholder: BRD / rules screenshot
Add a 1-slide screenshot summarizing the rules and constraints from your BRD.

PASTE_BRD_RULES_IMAGE_URL_HERE

Journey map & communications

This experience lives across touchpoints. The journey map shows where confusion happens, where customers complain, and where proactive communication reduces calls.

What the journey map highlights
  • Moments where customers realize they can’t control debit timing.
  • Failure moments that trigger $5 fee frustration and escalation.
  • Recovery moments: what customers try before contacting support.
  • Messaging opportunities to prevent confusion before it starts.
How comms reduce contacts
  • Explain “what you can change” and “when it takes effect.”
  • Set expectations about retries and next steps after failure.
  • Use consistent language across app + email/SMS/notifications.
  • Tell customers the “why” behind disabled dates (not just “you can’t”).
Placeholder: Journey map image(s)
Add your journey map slides here. Recommended: (1) end-to-end journey, (2) failure/recovery path.

PASTE_JOURNEY_MAP_IMAGE_URL_1
PASTE_JOURNEY_MAP_IMAGE_URL_2
Placeholder: Communications inventory
Add a screenshot/table showing: channel + trigger + timing + message goal + copy summary.

PASTE_COMMS_TABLE_IMAGE_URL
Optional: include 2–3 comms examples:
PASTE_COMMS_EXAMPLE_1 / PASTE_COMMS_EXAMPLE_2 / PASTE_COMMS_EXAMPLE_3

Wireframes & edge cases (mobile)

I designed the flow around the moments that typically break AutoPay experiences: selecting a date with constraints, invalid dates, bill-cycle guardrails, confirmation states, and safe behavior when APIs fail.

Autopay flexibility mobile wireframes and edge cases
Placeholder: Mobile wireframes for Manage AutoPay → Choose Date, including edge cases: default current date, outside bill cycle, invalid dates (29/30/31), API failure, confirmation state. Replace PASTE_MOBILE_WIREFRAMES_IMAGE_URL_HERE with your wireframes image URL.
Placeholder: Calendar close-ups (so people can read the details)
Add 1–2 zoomed screenshots of the calendar state (disabled dates + helper copy).

PASTE_CALENDAR_CLOSEUP_1
PASTE_CALENDAR_CLOSEUP_2

Competitive analysis (market gap: debit-date flexibility)

The competitive question was simple: do they let customers choose the AutoPay debit date? If competitors don’t offer flexibility, that’s a market gap—and a chance to differentiate on trust.

Competitor AutoPay debit-date flexibility? What that means for customers What we do differently (Spectrum advantage)
T-Mobile Not clearly supported (typical self-serve surfaces don’t emphasize debit-date choice) Customers can manage AutoPay, but the debit-date experience is not positioned as flexible control. That can still leave paycheck-misalignment issues unresolved. We treat debit timing as a first-class control: a guardrailed calendar + clear constraints + confirmation + failure-state guidance.
Amex (payments UX lesson) Not applicable (different product), but sets the bar for date clarity If date language is confusing, trust collapses and customers overreact (panic payments / complaints). One clear truth: “We will debit on DATE.” Everything else supports this with consistent language and transparent rules.
Spectrum (this project) Yes — with guardrails Customers can align AutoPay to paycheck timing and reduce avoidable failure events. Market-beating differentiation: flexibility + constraints made legible, not hidden.
Market positioning

If competitors aren’t offering debit-date flexibility, this becomes a trust differentiator: fewer failures, fewer fee-trigger complaints, fewer calls—because customers finally control timing.

Placeholder: competitor screenshots (optional)
Add 1 screenshot of T-Mobile AutoPay management surface (optional) + a date clarity example (optional). Skip if you don’t have them—the story stands without it.

PASTE_TMO_SCREENSHOT_URL
PASTE_AMEX_SCREENSHOT_URL

Solution

The solution makes debit timing controllable and predictable while protecting billing rules: choose a date, see what’s allowed, confirm the change, and understand what happens if AutoPay fails.

Key design moves
  • Guardrailed calendar that prevents invalid selections instead of allowing errors.
  • Transparent constraints: explain why dates are disabled (bill-cycle logic).
  • Unmissable confirmation: success state + updated Manage AutoPay screen.
  • Safe failure states: API failure has a clear recovery path.
Why this reduces complaints
  • Paycheck alignment reduces avoidable failures.
  • Less “forced” feeling because customers control timing.
  • Predictability reduces “gotcha” fee narratives.
  • Clear recovery reduces escalation and repeat contacts.
Placeholder: Final happy-path screenshot strip
Add a 3–5 screenshot strip: Manage AutoPay → Choose Date → Confirm → Success → Updated manage screen.

PASTE_FINAL_FLOW_STRIP_IMAGE_URL

Results (or measurement plan)

If you don’t have post-launch metrics yet, keep this section as a measurement plan. It still reads senior when it’s specific.

What I would measure
  • AutoPay failure rate (before/after) segmented by customers who changed debit date vs not.
  • Volume of $5 failure-fee complaints and escalation rate.
  • Contact drivers: “why autopay / why fee / change date / when will you debit.”
  • Drop-off rate in the date-selection flow and top “blocked selection reasons.”
Instrumentation (placeholders)
  • EVENT_AP_DATE_OPENED
  • EVENT_AP_DATE_SELECTED (include selected day)
  • EVENT_AP_DATE_BLOCKED (reason: invalid day / out of cycle)
  • EVENT_AP_DATE_SAVE_SUCCESS / FAIL (error code)
Placeholder: Impact snapshot slide
Drop one slide here later with: date range + segment definition + before/after metrics.

PASTE_RESULTS_SLIDE_IMAGE_URL

Next steps

This is how I’d evolve the capability into a durable product: reduce failures, reduce fee-trigger events, and expand flexibility safely without breaking billing logic.

1) Failure-proofing Make retry dates visible + add a direct “Fix payment method” path from failure states.
2) Clarity improvements Add a simple “Next debit date” and “Why some dates aren’t available” explainer panel.
3) Comms A/B testing Test copy and placements that reduce “forced autopay” sentiment and increase confidence.
4) Expand safely Roll out to broader segments once failure reduction is proven (guardrails stay the same).
5) CX dashboard Track failures, fees, complaints, and calls weekly to prove impact and catch regressions early.
6) Executive narrative Package the story as: complaint driver → root cause → fix → impact → scale plan.
Want the artifacts?
Placeholder: 30-second interview pitch
Add 3 bullets you can say in an interview:
• Forced AutoPay + $5 fee + no flexibility caused complaints and failures
• Introduced guardrailed debit-date selection with clear constraints + confirmation
• Measured impact via failures, fee complaints, and call-driver reduction
Previous

OneButtonPIN