Reducing Support Cases by 96% with design
Designing a scalable troubleshooting system for complex hardware–software ecosystems
Role
Lead Product Designer
Timeframe
1 month
Team
Manager, Designer, Developer
Platform
iOS, Android
Discovery
Support requests across Laerdal products were increasing, but volume wasn’t the real issue.
Laerdal’s products form a complex hardware–software ecosystem.
Identifying root causes required repeated back-and-forth across devices, firmware, apps, and permissions, making diagnosis slow and inconsistent.
Problem
The initial top-down suggestion was to create a support page.
I challenged this direction early.
A static support page would:
Require users to self-diagnose complex issues
Force them to search across long, growing documentation
Scale poorly across hardware versions, firmware versions, and app versions
Reduce none of the diagnostic effort for internal teams
The real problem wasn’t missing information.
It was missing diagnosis and missing context.
Users had to diagnose product issues by searching through documentation.
Impact
The initial top-down suggestion was to create a support page.
Certain products required up to 28 days to resolve a single support case
Cases escalated beyond frontline support to hardware teams and managers, one by one
Resolution depended on reconstructing context across hardware, firmware, app version, and permissions
Support teams relied on individual experience rather than a shared framework, creating inconsistency and burnout
As the product ecosystem grew, this approach did not scale.
Each new product or version increased complexity, resolution time, and internal load.
QCPR issues crossed multiple systems, with some cases taking up to 28 days to resolve.
Initiative
I reframed the problem from: “How do we document solutions?” to “How do we identify the problem faster, with full context, without asking users to read?”
The issue was systemic operational drag.
Certain products required up to 28 days to resolve a single support case
Cases escalated beyond frontline support to hardware teams and managers, one by one
Resolution depended on reconstructing context across hardware, firmware, app version, and permissions
Support teams relied on individual experience rather than a shared framework, creating inconsistency and burnout
As the product ecosystem grew, this approach did not scale.
Each new product or version increased complexity, resolution time, and internal load.
Without intervention, support cost and escalation risk would continue to grow linearly with product adoption.
Built and pitched a guided troubleshooting prototype that adapts by context.
Key Decisions
We made four deliberate decisions:
Pilot with QCPR, the highest-complexity product, to validate impact before scaling.
Design a reusable, AI-ready diagnostic framework that could scale across hardware, firmware, and apps.
Pause static support pages, which wouldn’t address root-cause diagnosis or resolution speed.
Standardize frontline diagnosis using the troubleshooting guide, reducing back-and-forth and resolution time.
Together, these decisions prioritized scalability and learning velocity over short-term coverage.
Research
The research goal was to understand how diagnosis actually happens in practice.
Spoke with global support owners, frontline agents, hardware teams, and pilot customers.
Found no formal troubleshooting framework; diagnosis relied on individual experience.
Troubleshooting happened through adaptive question-and-answer loops, not documented playbooks.
Resolution quality varied based on who handled the case, not the issue itself.
Reframed the problem from missing content to missing diagnostic reasoning, externalized expert thinking into a reusable system, and validated it through pilot testing before scale.
Analyzed existing support workflows and distilled them into optimized diagnostic flows.
Design
The solution was designed as a guided diagnostic flow
Instead of asking users to read or search, the system asked the right questions in the right order, using each answer to narrow the possible root cause.
The flow worked bidirectionally:
Questions adapted based on previous answers
Each response either resolved the issue or ruled out an entire class of problems
For example:
Bluetooth connected?
If yes, an entire category of connection issues was eliminated.Location access enabled?
If not, the issue could be resolved immediately without escalation.Firmware version available?
If the user could check it, the system inferred that the product was already connected and functioning at a basic level.
If the issue could not be resolved inline, the system automatically generated a support case with all diagnostic answers pre-filled, removing the need for manual clarification.
The result was a troubleshooting experience that behaved more like assisted diagnosis than traditional support.
Outcome
After launch, the results were shared in a monthly All Hands:
96% reduction in support cases
The remaining 4% arrived with complete context
Those cases were resolved in less than one day
Support, engineering, and management escalations dropped sharply
This was the first time the team saw a reduction of this magnitude across these products.
Reflection
This project reinforced a principle I rely on:
when a solution is proposed early, the highest leverage is to pause and ask what problem it’s solving, not why it was chosen.
Early involvement in context-building allowed us to reframe the problem correctly and design a system that scaled diagnosis, not documentation.