Turning Support data into Product action
Users who had already paid for Sheyda VOD were calling support because their subscription never activated. The calls were logged by hand and filed away, and engineering never saw one. I analyzed a quarter of support calls, measured what the gap was costing, and designed a three-phase system to close it. My responsibility was the research, the analysis, and the strategy, from problem framing to recommendations for engineering and support.
Evidence from about 7,000 calls in one quarter:
Payment Dominates: More than 60% of calls were about buying, paying, or activating a subscription.
Paid, Not Activated: Users completed payment, nothing unlocked, and a happy buyer became a frustrated caller at the moment of highest intent.
Unusable Data: In an audit of 42 logged calls, 37 (88%) were mislabelled or too thin to use.
Zero Escalation: The official escalation rate was 0%. That didn’t mean no bugs. It meant no channel existed for bugs to travel through.
No Self-Service: No ticketing, no chatbot, and no help center turned every small question into a phone call.
Turning Raw Support Data into Evidence-Based Product Decisions
Re-structure: I re-categorized the quarter’s calls into six themes, because the original labels couldn’t be trusted.
Audit: I checked 42 logged calls against what actually happened.
Follow the User: I sampled from the full three-month ticket set, spoke directly with users, and checked each account’s real renewal status. About half of users with an unresolved problem did not renew: 50% in a first sample and 54% in a second, random sample of calls.
Stress-test at Peak Demand: In the first week of a major series launch, I analyzed all 855 calls and validated 20 critical cases in depth.
Launch-week call distribution (855 calls):
- Purchase and activation: 36%
- Platform and TV: 27%
- Partner bundles: 16%
- Nuisance and dropped calls: 13%
- Discount codes: 6%
- Business enquiries: 2%
Of the 20 validated cases, 10 were paid but not activated, 7 were telecom-bundle users shown a “buy a subscription” prompt despite free access, and 3 hit a black screen on the TV app. Logging accuracy had improved, but escalation was still zero.
What I Decided and What It Cost
Capture context automatically
Decision: Record device, OS, and app version from the system, not from an agent’s memory.
Why: Incomplete details were the main reason bugs couldn't be reproduced.
Trade-off: It needs engineering work upfront, but it removes a whole class of human error.
Quick wins first, automation last
Decision: Ship an in-product FAQ first, then ticketing, then a triage chatbot.
Why: The FAQ needs no new infrastructure and removes about a third of repeat calls. A chatbot trained on bad data would automate the wrong answers.
Trade-off: The biggest saving, about 60% of repeat calls, arrives last.
The Support-to-Product Loop
Three Phases, Sequenced by Speed to Value
Phase 1, Immediate: An in-product FAQ and help center answer repeat questions about TV setup and discount codes.
Phase 2, Foundation: A ticketing system with mandatory categories, auto-captured device and app version, and a direct link to engineering's issue tracker. It breaks the 0% esclation rate and creates an audit trail.
Phase 3, Optimization: A triage chatbot classifies the issue before a human joins and resolves common cases, targeting about 60% of repeat calls.
Root Cause Covered: The failure sat on four layers: process, tooling, product, and organization. The three phases address all four together.
The plan is proposed, so these are targets, not results:
For Users: Fewer failed purchases, faster answers, and no phone call for simple questions.
For Support: About 60% of repeat calls automated and clearer, structured tickets.
For Engineering: A real escalation path, with label accuracy rising from about 12% to near 100%.
For the Business: Protection of revenue currently exposed to the paid-but-inactive failure.
Lessons That guided the work
Operational data is design material: The most useful research was reading what users already told us and checking whether they stayed.
Zero escalations didn’t mean zero bugs: It meant there was no reliable process to identify, communicate, and route product issues to the teams responsible for fixing them.
Sampling was the weakest link: Two estimates of 50% and 54% agree, but the margin of error is wide, so I recommended a control group of users who never called.
Correlation is not cause: Tracing each case to a specific failed flow narrowed the gap but didn’t close it.
Next time, I’d instrument first: Shipping ticketing earlier would have produced harder numbers sooner.
Service Design · Data-Driven Design · Qualitative & Quantitative Research · Root Cause Analysis · Product Strategy · Process Design · Cross-Team Alignment
I focus on designing system-driven experiences that align with business goals.
If this approach resonates with your product, feel free to get in touch.
