Support Signal → Roadmap Pipeline
Important user pain used to die in the ticket queue. Support fielded roughly 1,300 tickets a month across the Provider and Patient Portals, and the recurring, high-impact issues got escalated to me. I built the pipeline that carried them to product decisions: I triaged each one on a consistent scoring rubric, diagnosed the underlying problem rather than the symptom, clustered the patterns hiding across individual tickets, and turned them into structured roadmap items engineering could pick up cold. The result was a repeatable intake-to-roadmap pipeline, so user pain consistently reached the people who could fix it for good.
Figures on this page are illustrative, modeled on a provider and patient portal of this scale, and example artifacts tagged Illustrative are recreated to show the approach. No proprietary or real ticket data is included.
Signals were routed, not resolved
The IT and support team owned the Zendesk queue and the direct user contacts across both portals: clinicians and clinic staff on the Provider Portal, and patients on the Patient Portal. They were the front line for every bug, confusing flow, and "this keeps happening" complaint, and they escalated the recurring, high-impact, clearly-product problems to me. That part worked. What did not exist was a reliable path from that raw signal to a product decision.
So important pain got handled one ticket at a time and then disappeared. A workaround closed the ticket; the underlying cause stayed. And because each ticket was its own island, the patterns that should have driven the roadmap, the same issue reported twenty different ways, were invisible. The job was to turn a noisy stream of individual complaints into structured product input that did not get lost.
A scoring rubric, not a gut call
The loudest ticket was rarely the most important one, so I did not prioritize on volume or vibes. Every escalation was triaged within two business days against a shared rubric, scored on reach, frequency, and severity, which produced a priority and a clear disposition: resolve in support, monitor, or promote to the roadmap. I also tagged each ticket to a product area in Zendesk (Provider Portal, Patient Portal, auth, lab results, billing), which turned the queue into a measurable, trendable signal instead of a pile of anecdotes.
Reach
How many users it touched, and which portal.
Frequency
How often it recurred across the queue over time.
Severity
How badly it blocked the job the user came to do.
Priority score
reach × frequency × severity
Resolve in support
one-off with a workaround
Monitor
watch for a pattern
Promote to roadmap
recurring, high-impact
scheduleTriage SLA: every escalation scored and dispositioned within two business days.
Diagnose the system, not the ticket
IllustrativeThe real value was in the aggregate. I clustered tickets that looked different on the surface but shared a root cause, then named the underlying problem instead of the symptom each user happened to describe. That reframing is what turned a pile of complaints into a single, fixable product issue.
| Symptom cluster (how users described it) | Portal | Tickets (90d) | Underlying problem |
|---|---|---|---|
| "It logged me out" / "lost my work" / "had to start over" | Provider | ~140 | Session expiry mid-task with no autosave |
| "Can't find X" / "where did it go" / "the button is gone" | Patient | ~95 | A relabeled flow broke the mental model |
| "It says error" / "nothing happened" / "stuck on loading" | Both | ~70 | One failing state with no actionable message |
The shift: three different "complaints" were often one product defect wearing three costumes. The dozen or so recurring patterns like these drove the majority of repeat contacts, so engineering out a handful of root causes cleared a disproportionate slice of the queue, and stopped the same issue from being re-triaged a dozen times.
Turn a raw signal into work engineering can pick up cold
IllustrativeA ticket says "it's broken." A roadmap item has to say what, for whom, with what evidence, and toward what outcome. I wrote each one so an engineer who had never seen the support thread could understand the problem, the impact, and the intended direction without a meeting.
Raw support signal
"User says the app keeps logging them out and they lose everything. Really frustrated, third time contacting us. Can someone look?"
Structured roadmap item
- Portal: Provider Portal, lab-order flow.
- Problem: sessions expire mid-task and unsaved work is lost.
- Evidence: ~140 tickets in 90 days, ~45 repeat contacts.
- Priority: high reach × high frequency × high severity.
- Proposed direction: autosave drafts + a clear re-auth prompt.
- Success: repeat contacts on this issue drop to near zero.
A repeatable intake-to-roadmap pipeline
Doing this once is triage. Doing it the same way every time is a system. I made the path from a support signal to a prioritized roadmap item repeatable, so it ran whether or not I was the one pushing it, and user pain stopped depending on luck to reach the roadmap.
Signal
Triage
Diagnose
Cluster
Structure
Roadmap
The link between support, product, and engineering
A pipeline only works if the people on both ends trust it. I was the connective tissue: close enough to support to know what was actually hurting users, and close enough to product and engineering to get it acted on and to close the loop back.
With support
Gave them a clear escalation path and the confidence that what they raised would not vanish, plus the resolution to relay back to users.
With product
Brought evidence-backed problems, not anecdotes, so support data earned a real seat in roadmap prioritization.
With engineering
Handed over context-complete tickets, so work started on the problem instead of on a round of "what did the user actually mean?"
The operating cadence: a weekly triage pass on new escalations, a biweekly roadmap review where support-sourced items were prioritized alongside everything else, and a loop back to support macros and user-facing comms whenever a fix shipped, so the people who raised an issue heard how it ended.
User pain, consistently reaching product decisions
~1,300/mo
tickets triaged · both portals
18
roadmap items from support
~70%
fewer repeat contacts on fixed issues
~35%
faster time-to-resolution
The lasting result was the pipeline itself: support signals stopped being one-off fixes and started becoming product decisions. Eighteen roadmap items shipped from support evidence, the top recurring patterns got engineered out instead of re-answered (the autosave fix alone cut "lost work" contacts by roughly 80%), and the loop from user pain to roadmap to shipped fix actually closed.
What I would carry forward
Diagnose the system, not the ticket
The fix that matters is for the cause every user is bumping into, not the one symptom in front of you.
Recurring patterns are roadmap gold
Support data is the cheapest, most honest product research there is, once you read it in aggregate.
A process beats heroics
Making the intake-to-roadmap path repeatable meant user pain reached product whether or not I chased it.