Pattern vs Catch-all

When designing your Customer Experience Score, you often uncover processes that follow a specific pattern.

For example, you want a client to have a similar experience every time you request information from them – perhaps you send an email, then immediately follow up with a phone call or a text, or both.   Perhaps you call, then follow up with an email. After a while, you might remind the client if they haven’t responded.  There might be a limit to the number of times you do that.

However you want the experience to be, you want that experience to be consistent across all the information requests you might make, so it’s tempting to lump all these different processes intoa single catch-all process.

That’s a mistake.  Although the pattern is the same, each individual process turns out to be slightly different.  The information being requested is different, the purpose is different, the priority, urgency and timescales may be different.  The Roles involved may be different.  The Props will definitely be different.

These differences will out, and somewhere in the depths of what looks like a simple process, you’ll end up having to include some way of spelling out what actually happens in each case.  It usually involves a complicated list of “If you’re dealing with A, do B; if you’re dealing with C, do D;…”

And so on.

The key is to remember why you’re writing your Customers Experience Score, which is to enable someone else in your team to perform the process as well as or better than you.  That is best achieved by making each process self-containedly easy to follow, without cluttering it up with decisions about alternative possibilities.

When Google gives you directions for getting from your house to that beauty spot you love, it gives you full directions for each and every route, even though most will start with the same turn out of your street, and end with the same turn into your destination.    Imagine trying to find your way with directions that say “If you’re following route A, turn right at the next roundabout.  If you’re following Route B proceed straight across.   If you’re following Route C, turn right.”

You’d take longer, annoy fellow drivers along the way, and probably get lost a few times.  You might even give up and go home.  That’s the last thing you want your team to do when they’re delivering your Promise to clients.

A pattern is a pattern, nothing more.  Use it to design in consistency that reinforces your Promise of Value.

A catch-all, on the other hand, makes everyone work harder, for no extra benefit.

How to capture a business process: Step 5

When sketching out a process it helps to start with the most straightforward case.  The one where everything goes right, or at least goes as expected.   Once you have this laid out, you can identify exceptions.

I find it helps to think of the whole process as a river.  The straightforward case is the main, well-worn channel, but there may be parts that break off and loop round before coming back into the main flow.

So, for example, your straightforward case for preparing a set of annual accounts for a client assumes you have all the information already, the client approves your draft immediately and you can go straight on to filing them.  But what happens if you don’t have all the information?  Or the client doesn’t bother to get back to you with approval?  The process needs to deal with these too.  These are alternative routes through the process – loops in your process river if you like.  And that’s exactly how I like to represent them.

Here’s another example.  For a maintenance business, the ‘straightforward’ case is the typical reactive, unscheduled job: