Case study 02 / Platform & Operations
TheCrew Platform
The tickets kept repeating.
The problem started before support.
Recurring connection tickets were downstream evidence of friction in setup and validation. Debra investigated the experience with affected users, identified predictable failure points, and collaborated with developers and leadership on a guided launcher that moved diagnosis and resolution upstream. Connection-related tickets disappeared.
- Environment
- Technology-enabled multiplayer and community platform
- Contribution
- Product direction, workflow design, and operationalization
- Focus
- Setup, validation, connection, self-service, and support operations
- Operating scale
- 2,000+ members and approximately 120 concurrent users
- Organization
- Approximately 68 distributed contributors and leaders
- Lifecycle
- Operated through 2023 and sold in 2023
The intended journey / 01
Participation was the destination. Setup was where the journey broke.
People with varied technical experience needed to move through a longer lifecycle. The launcher intervention concentrated on the predictable setup, validation, and connection failures that occurred before participation.
- 01Application
- 02Approval
- 03Technical setup
- 04Validation + connection
- 05Participation
- 06Ongoing support
Intervention zone / setup, validation, and connection
Recurring support signal / 02
The same failures kept arriving as separate tickets.
The intended experience was progression into participation. In reality, predictable setup and connection problems repeatedly reached support after people had already failed.
“9 times out of 10, it’s not the people, it’s the system.”
Investigation / 03
Watch the actual setup experience.
Debra worked directly with people submitting the recurring tickets and observed where their setup and connection experience diverged from the intended journey.
- Observe the actual workflow
- Identify where reality diverges
- Determine why
- Change the appropriate part of the system
Design criterion / 04
If the system can identify what someone needs before they fail, why wait for them to fail?
Predictable setup failures should be identified and resolved before they require specialist support. The criterion shaped the product direction; it was not a measured KPI.
Guided intervention / 05
Move diagnosis and recovery into the experience itself.
Debra developed and pitched the product direction, translated observed friction into functional requirements, and collaborated with developers and organizational leadership on implementation. This was collaborative product and operational work, not a claim that she personally programmed the launcher.
- 01Permission + check
Begin with the user’s permission and inspect prerequisites.
- 02Identify
Make missing requirements visible.
- 03Install
Install required missing components where appropriate.
- 04Configure
Guide the setup and configuration steps.
- 05Test
Validate the connection before participation.
- 06Enter
Move the person into the platform and community hub.

Historical evidence / 06
The launcher became more than a launch button.
Contemporaneous launch communication described prerequisite checking, connection, community news, featured content, server information, and routes to supporting resources. The artifact documents the intended scope without requiring reconstructed documentation.

Supported outcome / 07
Connection-related tickets disappeared.
After deployment, the recurring setup and connection support-ticket category the launcher was designed to address effectively disappeared.
Operational implication / 08
The goal was not to answer the same setup question more efficiently.
The intervention moved recurring diagnosis, guidance, and recovery into the user experience. It removed the recurring reason people needed that specialist support in the first place.
Capability beats dependency.
What this demonstrates / 09
Recurring support is often evidence of a system problem.
The launcher was the intervention. The underlying problem was recurring support demand caused by upstream friction. The work demonstrates how repeated support demand can reveal upstream friction in onboarding, customer enablement, product operations, knowledge, and self-service.
The transferable capability is recognizing the pattern, investigating the actual experience, and moving the appropriate capability into the system people are already trying to use.
All Work