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: Weekly disconnection tickets fell 80%, and 52% of all disconnection errors now resolve with zero human involvement. What still comes in are genuine replacement requests, exactly what support should be handling.

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 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 a : 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 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 : 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 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.

The old error screen: a red “Not Receiving Data” card with a single Contact Support link — The old error state. One error message, one CTA, straight to support.

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 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 new error card: softer copy, a green “Fix this instantly” button, and a small “Reach out to us” link below it

the detour

Still tap “Reach out to us”? We show the honest math first, 5 minutes vs 3 to 4 working hours. Their call.

“Are you sure?” bottom sheet comparing support’s 3 to 4 working hours with the 5-minute self fix

It starts with why: four plain-language reasons, no error codes.

“Let me tell you why this happens” screen listing the four common causes with small illustrations

Then the two don’ts that make things worse, with real photos.

“Before you start” sheet with real photos of the two don’ts: don’t place the transmitter back in the charging pod, don’t remove the sensor patch

The fix itself: three short steps, each with its own video.

Step 1: gently remove the transmitter, with an embedded video

Step 2: clean the transmitter contacts, with an embedded video

Step 3: click the transmitter back into place, with an embedded video

One small check before finishing.

“Before we finish” sheet asking: have you completed all 3 steps?

Then an honest wait: readings take about 15 minutes, and raising a ticket stays locked until the countdown ends.

“Great, you’re all set” screen setting the 15-minute expectation

Metrics screen with a live countdown and the “Raise a ticket” button disabled until it 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.”

After the timer: still no readings, and the “Raise a ticket” button is now active

Ticket form with the issue pre-filled as “Readings not showing up” under the header “We’ll take it from here. Promise.”

Honest to the end: the 3 to 4 hour wait stated upfront, phone and email as backup.

Ticket submitted screen repeating the 3 to 4 working hour expectation, with phone and email as backup

Metrics screen after raising a ticket: “We’ll contact you soon”

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.

Detective Pikachu inspecting through a magnifying glass

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, 1 in every 2, now end without a human involved, up from zero, because earlier the app offered no other path.

As per the data: 1 in 2 disconnection errors, ~52%, now resolves with zero human involvement.

Six user calls. We deliberately sampled : 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.

Before

Reading out the same troubleshooting steps, call after call, hours after the error.

Now

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

Error 15 · 263 totalIncorrect / abnormal readingsNo readings / not updatingError 103

Support tickets per week by category, June weeks 23 to 27
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

Weekly Error 15 tickets, from launch to measurement. 118 a week fell to 24, an 80% drop. Other categories held their usual range, so this wasn't a general decline.

Data, then users, then the frontline team. The same loop that found the problem checked the fix.

Impact

−80%tickets

Weekly disconnection tickets fell 80%, from 118 a week at launch to 24 by week five. And 52% of all disconnection errors now resolve with zero human involvement; both numbers trace to the same dataset as the funnel. 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

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.