Case study 01
One click, not ten
Giving Roche Diabetes Care’s support teams one trusted place to find product knowledge
Before
Support advisors at Roche Diabetes Care answered calls about insulin pumps, glucose meters and continuous glucose monitors, from current models to discontinued ones still in use. On a call, they needed a reliable answer fast, whether a device’s technical details, a common procedure or the right fix. With medical devices, an outdated or unchecked answer is a real risk.
There was no single place to find those answers. The official knowledge base sat inside Salesforce. It was text-only, and advisors could reach it only from an open case. Everything else was scattered across Google Sites, Cornerstone, chats, groups and personal notes, unregulated and impossible to version-control. New advisors had to learn where to look before they could learn what to say.
Before
- Salesforce, text-only, inside an open case
- Google Sites
- Cornerstone
- Chats and groups
- Personal notes and PDF copies
8 to 10 clicks to a troubleshooting article
After
One knowledge platform
- Technical information
- Common procedures
- A landing page for every product
1 click from the browser
How I found the gap
Diabetes Care first planned to build its own knowledge tool, but IT stopped it because it was not the right place or time to build one. Roche Diagnostics already ran a proprietary knowledge platform across its whole portfolio, for knowledge management and troubleshooting, and it was later set to become the standard across Roche. Diabetes Care adopted it, and the question became what should go into it first.
To answer that, I went through the full advisor onboarding and complaint handling in Salesforce. I found two things:
- Reaching a troubleshooting article took 8 to 10 clicks, because Salesforce only showed knowledge inside an open case.
- Product technical information and common procedures, which advisors needed constantly, weren’t in Salesforce at all. They lived in PDF guides that advisors downloaded and annotated. Each advisor kept a private copy with notes no one had checked, and no one controlled which version they used.
Decisions
Start with the content used on every call.
Technical information and common procedures were used on almost every call and were already approved as part of the standard product, so they could move without new sign-offs.
Keep the first phase narrow.
Global, approved content only. Troubleshooting and local country procedures, with heavier approval chains, were planned for later.
Build it with the advisors.
I mapped priority devices into the platform and brought advisors in to test them on real tasks. They told me what worked and what didn’t, and I iterated on their feedback until the pages held exactly what they needed. Testing also showed which devices and information mattered most, and it trained the advisors as they went, so the platform was adopted much faster.
What I built
- An AI-assisted workflow that extracted content from the source guides and reformatted it for the new platform.
- A landing page for every product, shaped by advisor testing, with its technical information from day one. English was the working language, and the platform’s machine translation was ready for other languages.
- A migration tracker in Monday.com, product by product, on a quarterly schedule.
Results
Measured
- 1 click instead of 8 to 10. The platform opened from the browser, with favourite products bookmarked.
- 18 products delivered on my own in two quarters.
- 10 advisors trained through testing; two new-hire cohorts of 17 trained with my process.
- After I left, the team that took over copied my process unchanged.
Estimated
- About 19 minutes saved per advisor per day. This is modelled from click and call volumes, not measured.
What I’d do differently
Make the scope visible.
Local procedures were planned for later, but I explained that one conversation at a time. Country experts took “later” to mean “never”, and the project stalled while we sorted it out. Next time I’d publish the roadmap at kickoff, showing what’s in, what’s out and when, and bring a country expert in early to review it.
Measure before launch.
The time saved is an estimate, because no one recorded how long finding an answer took before. Next time I’d agree two or three baseline measures with team leads first, such as time to find an answer and search success.
Recreated for Meridia Health, a fictional medical-device company, with invented data.
Try it
The Flowline P300 product page, recreated in Meridia KMS, with technical information, common procedures with images, a favourite star and a link to the “Air in line” troubleshooting article as the next phase. The migration tracker is recreated too, with invented data.