Connection Issues
Live
·
41.22% containment
What is Connection Issues?
Almost every connection issue has the same question with two very different answers. Either the network in the customer's area is down (nothing to do but learn when it'll be fixed and how to stay reachable meanwhile) or it's their device, in which case there's plenty we can do to help them.
Giving the customer the right information is important and we needed to make sure we built a journey that factored in every possibility the customer might be experiencing, without overwhelming the customer.
Connection Issues journey: the card resolves the fork in one view: network fault with a fix time and a workaround, or network clear and on to device steps.
Three journeys, for three levels of certainty
The blocker here wasn’t design, it was access. Whether this journey could work at all depended on which APIs we needed to call, annoyingly we didn't receive access to these APIs for a while.
Waiting would have cost months. So instead of designing one journey and hoping, I picked up the initial exploration already in progress and designed three: one for each realistic outcome of the API conversation.
01
The version worth arguing for
Designed the ambitious case first, with a full set of API calls behind it: saving a MyPlace for customers who didn’t have one, using live location when someone didn’t know their postcode, and richer detail inside the Connection Issues component about what was actually happening on the network near them. It got stripped back on time and cost. But the thinking is done and the case is already built, so revisiting it later is a much shorter conversation.
02
The version that could launch regardless
I also designed a journey with no API dependency at all, enough to launch as an MVP and start moving containment even in the worst case. That turned out to matter more than expected. It’s now built and running as the fallback whenever the API fails, so the worst-case design ended up becoming the resilience layer rather than a contingency we never used.
03
The version that shipped
Once approval came through for the most important API, I designed the journey around it. The containment comes from a card component that gives the customer a real answer inside the conversation, covering every possible state of the network in their area, rather than sending them somewhere else to find out.
Four in ten, resolved in conversation
The journey now contains over 41% of the customers who enter it, answered outright, without an advisor. And because the no-API version was designed alongside it, it degrades gracefully instead of falling over when the data doesn’t come back.
Containment
41.22% resolved in-assistant, without escalation
Designed for
Journeys, one per level of API access
I’m optimising it now: extending into broadband connection issues, which should push containment further still; adding deeplinks where they’d save the customer a step; and going back through the Connection Issues card to see what else it could be doing.
Get in touch
© Harry Thorpe · 2026
DesignED with FRAMER