Nobody should wait hours to feel safe again
When a CGM stops sending readings, people are left guessing about their glucose for hours. We put the 5-minute fix inside the app, right where the worry starts.
tl;dr
- What
- A self-serve fix inside the GoodFlip app for the most common CGM error: the sensor and transmitter losing connection.
- Why
- When readings stop, people are left guessing about their glucose until support calls back, 3 to 4 working hours later, for a fix that takes about 5 minutes. It was also our most common support ticket.
- My role
- End to end. The research, the pitch, the design, then the code and the PR that got merged.
- Result
- 52% of disconnection errors are now fixed by people themselves, in minutes, with no one to wait for. Weekly disconnection tickets fell 80%, and the ones that still arrive carry the context support needs.
before we start, a quick question
Do you know what a CGM is?
Context
GoodFlip sells a CGM, a continuous glucose monitor: a sensor patch that sits on your shoulder 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 signs that people were struggling were everywhere: 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 a stakeholder map: every function that touches a disconnection holds a piece of the answer. Then I went to all of them:
- 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.
That gave me a problem statement worth pinning up: people buy a CGM to see their glucose around the clock, but when it disconnects they fly blind for hours, waiting for support to read out a fix that takes minutes.
Sitting with the people who take the calls
So I booked one long session with the Product Specialist and the support team together. I structured the session on 5 WH questions: what fails, why it fails, when it happens, how they fix it over a call, and who 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?
That became the how-might-we: how might we move the fix from a phone call to the moment of the error?
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 card, 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.
And think about when it strikes: right before a meal, after a walk, around a dose. The exact moments people bought a CGM for are the moments it went silent, leaving them to manage their glucose from memory for the next 4 hours.
Worse, the card never said why. So people assumed the worst: the sensor is faulty, the product is unreliable, my money is wasted. Every fixable disconnection quietly cost us trust, reviews, and repurchases.
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, built to test, not to impress.
A few days later, we ran a solution interview with the same room that gave us the diagnosis: 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 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 1 in 2, 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 user who hit the error across five weeks, end to end.
1,310 people saw the disconnection error. At the fork, 1,040, nearly 4 out of 5, chose “Fix this instantly” over contacting support. That alone validated the flipped hierarchy.
Of those 1,040: 920 completed all three steps, 780 started the 15-minute wait, and 680 watched their readings come back. No ticket, no call, no waiting on us.
That left 100 people who did everything right and still had no readings, exactly who the escalation path was built for. 78 of them raised a ticket, pre-filled with full context: troubleshooting done, didn't work.
Two numbers told us the design was working. 87% of people who completed the wait got their readings back, so the troubleshooting content holds up. And ~52% of all disconnection errors now end without a human involved, up from zero, because earlier the app offered no other path.
The two datasets agree. Adding the 190 who went straight to support and the 78 who ticketed after the fix failed gives 268 people asking for help, out of 1,310 errors. The support team logged 263 tickets in those same five weeks.
As per the data: 1 in 2 disconnection errors, ~52%, now resolves with zero human involvement.
Six user calls. We deliberately sampled both extremes: 3 users whose troubleshooting worked and 3 for whom it 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.
Their ticket data says the same thing:
Tickets per week, top 4 categories · launch (Wk23) to Wk27
| Category | Wk23 | Wk24 | Wk25 | Wk26 | Wk27 |
|---|---|---|---|---|---|
| Error 15 | 118 | 72 | 28 | 21 | 24 |
| Incorrect / abnormal readings | 45 | 55 | 40 | 60 | 48 |
| No readings / not updating | 25 | 31 | 28 | 25 | 30 |
| Error 103 | 18 | 22 | 15 | 22 | 21 |
Data, then users, then the frontline team. The same loop that found the problem checked the fix.
Impact
Weekly disconnection tickets fell 80%, from 118 a week at launch to 24 by week five, in the support team's own ticket sheet. That drop is the funnel in the app showing up on their desk: before this, every disconnection error had one way out, a ticket. Now about 1 in 5 does, because 52% resolve with no human involvedand most of the rest never reach for support at all. More importantly, the tickets changed shape. Some are from people who chose to skip the fix, which stays their call. The rest arrive after the fix failed, pre-filled with “troubleshooting done, didn't work”, which is the replacement signal support could never get before. The system now separates “fixable in 5 minutes” from “needs a new sensor”, which is what it should have done all along.
What I learned
- 1
Close the loop. This problem only survived because nobody traced why the error fired and fed the answer back into the product. Leaving a user with zero readings and a ticket flow with a 4-hour turnaround isn't user obsession; sitting with the data and the people on the calls is what makes a product mature.
- 2
Designing solves the problem. Shipping it teaches you. Carrying the design to a merged PR taught me what a handoff never could: the constraints developers actually live with. With AI that's finally practical for a designer, and I'll keep shipping experiments, because that's where you truly learn user behaviour.
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: the ticket queues, the calls, the data.
- AV
Abhay Verma
Product Specialist
Walked me through the causes behind error 15 and the replacement criteria.
- NP
Nilesh Patel
Product Support
Validated every troubleshooting step against how the calls actually go.
- NG
Nikhil Ganji
Business Operations
Pulled the ticket data and the business context that made the case.
- SS
Shanta S
Inside Sales Lead
The sales call data on why people weren't repurchasing.
- AC
Ankur Chatter
Tech Lead
Reviewed the PR and got the flow safely into 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.