Why our most common support ticket shouldn't have existed
The most raised ticket had a 5-minute fix. We designed it into the app and retired the 4-hour support queue.
tl;dr
- What
- A self-serve fix inside the GoodFlip app for the most common CGM error: the sensor and transmitter losing connection.
- Why
- It was our biggest driver of support tickets. People waited 3 to 4 working hours for a fix that takes about 5 minutes.
- My role
- End to end. The research, the pitch, the design, then the code and the PR that got merged.
- Result
- Disconnection tickets fell by ~52%. What still comes in are genuine replacement requests, exactly what support should be handling.
Context
GoodFlip sells a CGM, a continuous glucose monitor: a sensor patch that sits on your arm for 14 days, and a transmitter that clips onto it and sends readings to the app.
People plan their day around those readings, what to eat, when to walk. When they stop, it feels like flying blind.
The problem I started with was bigger than tickets: repurchase was low, negative reviews were piling up, app store ratings were falling.
My job was to figure out why.
Reading everything, calling everyone
Instead of starting with a hypothesis, I started with every data source I could get my hands on:
- Inside sales call data, to understand why people weren't repurchasing CGM
- User interviews with people who hadn't repurchased
- Every Play Store and App Store review
- Social media comments
- Interviews with the support team, plus the entire support ticket data
Two problems came up again and again:
1. The sensor and transmitter keep disconnecting, and support is slow. When the transmitter loses connection, readings stop. The user sees an error, raises a ticket, and then waits 3 to 4 working hours for someone to respond. For a person tracking their glucose, that wait feels endless.
2. Users compare CGM readings with their BGM and call it inaccurate. A separate problem, and a separate case study.
I focused on the first one, because the ticket data made one thing obvious: most of these tickets ended with support walking the user through the same simple fix, over a call, hours later.
Sitting with the people who take the calls
So I booked one long session with the Product Specialist and the support team together, and asked them to walk me through error 15 end to end: what actually causes the sensor and transmitter to lose connection, how they troubleshoot it over a call, and when a sensor genuinely earns a replacement.
By the end, everything sat in one documented user interview: the exact script support reads out, the four common causes behind the error, and the replacement criteria. The fix was almost never the hardware. It was a 5-minute physical routine.
The reframe
That was the insight I took to the team: if support solves most of these tickets by reading out the same troubleshooting steps, why is a ticket involved at all?
So the pitch was simple. Let users fix it themselves inside the app. If the fix doesn't work, the sensor is probably genuinely faulty, and that ticket now comes in with context, so support can approve a replacement faster instead of starting from zero.
Self-servable issues get solved in minutes. Real hardware failures get faster replacements. Support volume drops. Everyone wins.
What the old experience looked like
A red banner, clinical copy, and one way out: Contact Support. Every disconnection, including the 5-minute fixable ones, went straight into a 3 to 4 hour queue.
Your health data just went dark, and all the app offers you is a wait. The whole redesign started from that feeling.
A working prototype in days
I didn't jump into polished mockups. Working from our user archetypes and the usability heuristics, I rapidly vibe coded a working prototype with Claude.
A few days later, we took it back to the same room and asked one question: is this how you actually troubleshoot when someone calls? It was, almost exactly. We weren't inventing a fix, just moving it from a phone call to the moment of the error. Go-ahead, secured.
The new experience, step by step
Less talk. Here’s the journey the way a user walks it.
Readings stop. Instead of a raise a ticket, the error now leads with a fix.
the detour
Still tap “Reach out to us”? We show the honest math first, 5 minutes vs 3 to 4 working hours. Their call.
It starts with why: four plain-language reasons, no error codes.
Then the two don’ts that make things worse, with real photos.
The fix itself: three short steps, each with its own video.
One small check before finishing.
Then an honest wait: readings take about 15 minutes, and raising a ticket stays locked until the countdown ends.
for 65%, it ends here
Readings return and the error simply disappears. The working product is the reward.
Now a ticket deserves to exist. Pre-filled and warm: “We’ll take it from here. Promise.”
Honest to the end: the 3 to 4 hour wait stated upfront, phone and email as backup.
Shipping it
The prototype didn't stay a prototype. I refined it into production code, raised a PR, and got it merged into the app.
We didn't stop at the launch
Shipping was the halfway point. We wanted to know if the flow was actually working the way we imagined, so we checked from three angles.
The MoEngage data. We tracked every step of the flow, from hitting the error to readings coming back.
What people tapped on the error screen
How far people got in the fix
Six user calls. We spoke to 3 users whose troubleshooting worked and 3 whose didn't.
3 calls · the fix worked
They were surprised how simple it was. Most didn't even remember it as a “problem” anymore.
3 calls · the fix didn’t
Their sensors were genuinely faulty, and their tickets went straight into replacement. The escalation path doing its job.
Back to the support team. The same team that helped shape the flow told us how their day looks now.
Reading out the same troubleshooting steps, call after call, hours after the error.
Disconnection calls have mostly disappeared. Tickets arrive with context, so replacements get approved faster.
Data, then users, then the frontline team. The same loop that found the problem checked the fix.
Impact
After launch, error 15 tickets fell by ~52%. More importantly, the nature of tickets changed: what still comes in are direct replacement requests from users whose troubleshooting genuinely failed. The system now correctly separates “fixable in 5 minutes” from “needs a new sensor”, which is what it should have done all along.
What I learned
- Recurring support tickets are a design failure surface. Each one is the product telling you where it's incomplete.
- Honesty persuades. We never blocked the support path, we just showed the real numbers and let people choose. Nobody resists friction when the trade-off is stated plainly.
- Shipping the code myself changed the conversation with engineering from “can we build this” to “let's review this”.
Credits
This shipped because a lot of people outside design gave it their time.
- VB
Vishal Bansal
Design Manager
Guidance throughout, and helped record the videos for the educational flows.
- RP
Ravi Purohit
Customer Support Manager
Opened up the support world and validated every step of the fix.
- AV
Abhay Verma
Product Specialist
Opened up the support world and validated every step of the fix.
- NP
Nilesh Patel
Product Support
Opened up the support world and validated every step of the fix.
- NG
Nikhil Ganji
Business Operations
The data, the context, and getting this through to production.
- SS
Shanta S
Inside Sales Lead
The data, the context, and getting this through to production.
- AC
Ankur Chatter
Tech Lead
The data, the context, and getting this through to production.
And one credit that goes beyond the team: Jakob Nielsen's 10 usability heuristics were the guiding principles behind most of the decisions here. Written in 1994, still doing the heavy lifting in 2026.