Self-Service Workflow Redesign

The challenge

Peloton's international support organization was growing faster than its self-service surface could absorb. Members were bouncing out of help articles into live agent queues for issues that were, on inspection, already answered in content that nobody could find. Each of the 8 markets had its own localization requirements, its own ticket mix, and its own expectations about what self-service should feel like. The help surface had been built for a smaller, simpler Peloton. It had not kept up with the product.

The symptom the business named was rising support cost. The real problem was a self-service experience that had been accumulated rather than designed. Navigation fought with search. Procedural content sat in the middle of conceptual content. The same member question had three competing answers depending on which article they landed on first. None of these were agent problems. They were design problems that had compounded.

Constraints

• Eight markets, one voice. Global consistency was a brand requirement. Local relevance was a usability requirement. Every design decision had to reconcile both.
• No support downtime. Members could not feel the rebuild. All redesign work landed behind feature flags or in phased rollouts.
• Regional teams, not a central team. Decisions had to be made collaboratively with market leads who owned their local content and tone.
• Evidence over opinion. Every redesign claim had to be defensible against real ticket data, usability observations, or both. No we think.

My approach

I led the redesign as a two-track program. One track rebuilt the self-service surface itself. The other track mined what members asked and fed product-gap recommendations back into the core roadmap. Both tracks ran continuously for two years, with improvements shipped in phases by market.

1. Support-ticket mining. I built a ticket analysis pipeline that classified inbound volume by intent, market, and resolution path. The top quintile of intents accounted for a disproportionate share of volume. That quintile became the first redesign target.
2. Conversation analysis. Beyond ticket classification, I read. Actual transcripts. What members said when the automated path failed. Where the vocabulary mismatch lived. Which questions had an obvious product-level answer that was not documented anywhere self-service could reach.
3. Information architecture rebuild. I redesigned the self-service IA around member-facing tasks rather than internal product structure. Procedural content and conceptual content got separated. Titles became informational. Canonical answers replaced the three-competing-answers problem.
4. Decision-tree redesign. For the automated paths, I rebuilt the decision trees based on the ticket mining classification. Branches that never fired were pruned. Branches that misrouted were rewritten. Fallbacks were made explicit rather than implicit.
5. Regional rollout. I partnered with market leads across the 8 regions on localization decisions that balanced global consistency with cultural and linguistic specificity. Each region tested a candidate redesign with a sample of members before promotion.
6. Product-gap loop. The support-ticket mining pipeline also produced a product-gap backlog: questions that no amount of content design could answer, because the answer required a product change. That backlog was sent to product management and drove the 20% support-volume reduction we eventually attributed to core product improvements.

Artifacts I authored or led

• Support-ticket taxonomy classifying inbound volume across all 8 markets
• Information architecture for the redesigned self-service surface
• Decision-tree workflows covering the top quintile of support intents
• Localization decision framework (global consistency vs local relevance)
• Product-gap backlog with prioritization framework, integrated into the product roadmap
• Usability-testing protocols and member-research reports used to validate each redesign phase

Results

The member-facing redesign drove the three direct CX metrics. The product-gap feedback loop drove the fourth and arguably most durable outcome: a 20% reduction in total support volume, because the product itself got better at the most common failure points. Support became a better source of product signal, not just a place where signal went to die.

What I would do differently

Invest in the product-gap pipeline on day one, not in month six. Every week the loop went uninstrumented was a week of member friction that could have been captured as product signal instead. The second lesson was about pacing the rollout: I learned to promote per market rather than per feature. Market by market isolated the variables; feature by feature entangled them.

Collaborators

Worked with market leads across 8 international regions on localization decisions and regional rollouts. Partnered with engineering on the decision-tree infrastructure and the product-gap pipeline. Partnered with product management on roadmap prioritization of gap-derived features. Partnered with research on the usability protocols that validated each phase.

Skills demonstrated

• Workflow optimization
• Information architecture
• Decision-tree design
• Support-ticket mining and classification
• Conversation analysis
• International localization
• Product-gap feedback loops
• Usability testing and member research
• Cross-regional stakeholder alignment