When the support tags were wrong
While mapping where support was failing premium riders, I noticed the ticket tags didn't match what riders were writing. A clustering pass and a hand-coded sample showed four contact drivers were systematically mislabeled.
- Organization
- Uber
- My role
- Program Manager MBA Intern
- When
- Summer 2026
- Result
- 4 contact drivers misclassified in over 10% of sampled tickets
The problem
I was building the current-state view of where support was failing premium riders, and the ticket tags looked wrong in ways that mattered. If contact reasons were consistently landing in the wrong buckets, any priorities I recommended would be built on a distorted picture of why riders were reaching out.
What I did
I pulled roughly 6,000 Uber Black and Elite tickets, embedded the rider comments and agent notes, and clustered them on what the tickets said rather than how they were tagged.
Clustering was a way to find the problem, not proof of it. So I hand-coded a 100-ticket sample and had an Ops partner review it independently. Around 10% carried a tag neither of us agreed with, concentrated in four contact drivers. The clearest was cancellations: a big share were really wait-time complaints from riders who waited too long and then cancelled. The tags captured what the rider did last instead of why, so a failure that’s disqualifying for a premium product looked like ordinary rider behavior.
Result
I stopped using tag-level volume and worked from the clustered categories instead, and documented the gap for the team that owns the taxonomy. I wasn’t going to get a taxonomy rewritten in twelve weeks, so the value was in not building on data I didn’t trust.
What I took from it
A category system inherited from an old process carries that process’s assumptions, and volume numbers built on it look authoritative even when they’re wrong.