The messiest service blueprint was the most useful
Updated: 7 hours ago
There's an interesting contrast between large enterprises and startups. When a startup launches an MVP, there's a lot going on under the hood that's more manual than it should be. You're making a bet. You probably haven't had the validation or effort a larger company can afford, so you get it out and test it rather than wait for perfection.
The upshot is that more often than not, it works. Life is great and you move on to the next feature. Meanwhile the manual processes pile up. That means more humans (cost) and more time (efficiency).
Everyone knew it was a growing problem, but nobody knew how big it was or where it was happening. Each team had their own areas of concern, but there was no way of seeing the whole thing.
So I brought in service design blueprints. We mapped the flows for each team and how the different business functions worked together. Each team highlighted where they used a spreadsheet or a manual process, where time disappeared, where customers waited for responses and where escalations happened. It became a visual way to show everyone what was really going on.
HMRC form submissions were a clear example. Fill in a form, download it, email it, have it reviewed, email it back, upload it... just nonsense. When it was shown, the engineers said "but we could automate that". So we did.
The results:
HMRC submissions 200% faster
3+ roles' worth of time freed up
The customer team back to giving advice, not doing admin
I've run blueprints in many places. I've never seen teams engage with them the way these teams did. Everyone got on board because it was for their benefit. Yes, they weren't neat and tidy, and they weren't strictly by the book. But they really helped.
They helped in product development too (obviously). We were launching a new feature and the team had mapped out the journey. Several manual processes had been accepted for the MVP. One day I saw the CTO in the Miro board putting "delete" stickers everywhere. He came back and said automating those bits was only a few story points, and we wouldn't go live until they were in the app.
Tip
Teach them the basics, then let go. Don't get precious about doing it properly. Let teams use techniques however they want to get to the result - that's what matters.
Starter for 10 - some useful links
Good Services by Lou Downe - the go-to book on service design, from the team behind GOV.UK
Mapping Experiences by Jim Kalbach - recently updated. Jim used to work with me, so I'm thoroughly biased - but it's well founded. Check out the reviews.
Nielsen Norman Group: Service Blueprints - a clear, practical guide
Comments