Using service design to defeat death

Death maybe certain, but service design has been the key to solving problems for the UK’s largest funeral business.

Some context

For the last 3 years I’ve been leading teams to solve problems for frontline colleagues of Co-op Funeralcare. A national business with over a 1,000 funeral homes, who average around a 100,000 funerals a year. This was a large scale operation that relied on a lot of manual processes.

Arranging a funeral of a loved one is the most emotional purchase any us will have to make. Funerals are also really complicated, iterative and sensitive so using generic software and processes wasn’t the answer.

So we developed software and used service design to make sure we fully understood the problems before jumping into solution mode.

Here are 5 (of many) examples of how service design has made a big difference to our product.


In the early days we were often forced to follow the “HiPPO”. Fortunately it was through great service design that we were able to prove the HiPPO wrong, earn trust and save the day for our users.

We were told to build locked down defined roles for our users. When we put this into our beta trial it failed within 30 minutes when the embalmer called in sick and nobody else could access her workflow.

Fortunately we had already mapped out the user journey and realised that when people were off sick, other people were multi skilled and could step in where needed. This meant we built capabilities, not defined roles, into the service. It also meant it took 20 seconds to solve the problem and prove the HiPPO wrong.


One of the old manual processes was to use an A4 paper diary to schedule funeral events and assign people and vehicles to them. This caused a lack of visibility of availability, lots of phone calls and an obvious area of improvement as times were often double booked.

During the Alpha we researched these diaries and the problems of double booking. So we decided to add some lines to the calendar design to see if they could nudge colleagues to book funerals in defined slots, in order to solve the problem.

A view of our test QA calendar

We were asked to build in complex (and expensive) rules but some red dotted lines were enough to nudge colleagues into spacing funerals. This helps make the operation more efficient, avoids letting clients down and avoids the cost of hiring more people and vehicles.


As well as having lots of manual process the business also had lots of variability — common problems, solved in different ways.

One of the most variable yet critical was the “daily sheet” colleagues were given to let them know where and when they needed to be for the days funeral events.

As we have built cloud based software it would be easy to say job done but by getting into the detail we found out that we still needed to solve this with paper.

Why? Imagine if you were at a funeral and you looked around to see the funeral director looking at their phone. You would probably think they were checking emails or on social media, not making sure the funeral was a fitting send off for your loved one.

View of our QA scheduler

As well as being able to access information from any device we also built a printable daily schedule. We even learnt the perfect design was to have 3 funerals on one page so it could be folded and subtly viewed from inside a jacket.


In the early days we had a lot of time with the central teams who told us how the main paper arrangement form had been design to reflect the way the business arranged funerals.

Seemed fair enough so our early version of the software followed the same flow. We then got front line colleagues to use it for real and they hated it. Instead of doing the service design first we jumped in, which was a big mistake. So we had to move fast to maintain credibility.

When we mapped the flow of an arrangement we quickly learnt there was no such thing as a typical funeral. Clients are emotional, so if they want to talk about flowers then colleagues talk about flowers even though it is near the end of the paper form.

What is great about the paper form is that it is visually very easy to see what you have discussed and what you haven’t. This makes it seamless to jump around the different sections whilst maintaining eye contact with the client.

A prototype dashboard view
A prototype dashboard view

We needed a way to solve this with our software. So we collaborated with frontline colleagues using service design to develop a pattern (colours) that only needed peripheral vision to know what still needed to be discussed.

Roll out

Non of the development team were experts on training so we got help from the HR team. They developed some great training material and had a well organised plan to roll out the new software and processes to colleagues.

We did a trial in 1 region that didn’t go very well, with lots of bad feedback about the software. So we stopped wider roll out and did a service map of the process to identify the pain points.

What it showed is the main problems weren’t the software but the things that enable it. New hardware wasn’t set up properly, user accounts weren’t activated and because the training was done on fixed days some colleagues missed it. All massive learnings that were flushed out by service design.

Naturally we changed the roll out approach for the remaining 36 regions and were so successful colleagues spontaneously started sharing their thoughts on twitter.

Big thanks to the many people who were involved in all this great work.

I'm a Group PM at, ex Head of Product at Co-op. Tackling tough problems, making mistakes, learning and iterating along the way. All views my own.