Process Redesign: Problem Prevention or Detection

I recently changed phone networks, and wanted to keep the same phone number. I’ve done this before in the past, and it’s always been a relatively simple process. Usually, a changeover date is agreed, and on that date there’s an hour or so where the phone number is inactive, and then everything works again as usual.

Unfortunately, this time was different. Something went wrong with the ‘porting’ of my number, and days later I was left in a situation where I couldn’t reliably receive calls or texts. Pretty annoying for someone who relies on a phone for work.  It was doubly annoying that I kept getting told “wait another 24 hours to see if it magically corrects itself” and it was only when I made a formal complaint that things got resolved…

Now I’ve no idea how number porting works on UK mobile (cell) phones, but from what I read online it’s more complex than a consumer might imagine, involving lots of interfaces and interactions between the old and new companies, and sometimes problems occur.  This got me thinking about how some processes preempt problems, and others leave the customer high-and-dry…

Predictable Problems: Prevent or Detect

When designing processes, there will be some potential problems that can be predicted. If you were designing the payment processes for an online shop, you can predict that at some point in the future someone will try and use a stolen card to make a transaction.  You can try to prevent that by restricting the shipping address to be the same as the cardholder address, and by processing the card transaction prior to shipping the goods.

Prevention involves use of sensible validation and “guard rails” to ensure that things go as smoothly as possible. Yet there will be some predictable problems that you can’t prevent, but you can still detect as soon as they occur.  Once detected, the process can notify relevant people or systems, so that action is taken to rectify the situation.

An example: “Your bags didn’t make the flight”

A few years ago, I was flying from the USA to the UK, with a flight connection at Dallas Fort Worth. Unfortunately, my initial flight was delayed and I landed at the airport really late. So late that even though I ran as fast as I could, the gate for my transatlantic flight had closed.  However, luckily the plane hadn’t left and the gate staff explained they were holding the flight for passengers like me who were transferring.  Phew!  I boarded the plane, relaxed, and tried to sleep for the flight.

When I landed in London and turned on my phone, I got a notification. It read:

“We’re sorry, but your baggage (1 of 1) for record locator <<Reference number>>  is arriving on a later flight. For help, go to the <<Airline Company Name’s>>  baggage office”

It also had contact details, and a link to track my bags. Now, the fact my bags didn’t make it onto the flight wasn’t really a surprise to me… I nearly didn’t make it onto the flight!  But this preemptive message meant I didn’t have to waste time at the baggage carousel.  I went straight to the baggage counter, they explained it was on a flight about 12 hours later and they’d courier it to my home address.

Advertisement

A Process Design Pattern: Detect, Inform and Solve

A key point here is the process the airline had set up meant that the problem (a delayed bag) was detected by them, they provided relevant information to me and provided a practical solution.  I suspect most customers accept that problems will occur.  But when the customer notices the problem first, surely that indicates an opportunity to improve the process?

This highlights the importance of building in problem detection into manual and automated processes. Going back to my earlier example of a phone number transfer that went wrong, surely there must be some way for the phone company to detect that the process failed? Wouldn’t it be far better for them to ‘notice’ this before the customer does, and either fix it straight away or at least inform the customer so the customer doesn’t have to raise a query?

This might sound like it will add processing cost. Yet, it might actually be cost saving or cost-neutral. When things go wrong, customers often spend an inordinate amount of time navigating helpdesks and eventually making complaints. This is really a type of ‘failure demand’—work that is best avoided. By creating a situation where customers don’t have to raise the query in the first place, it reduces these incoming queries and will also likely increase customer satisfaction. In many cases, this will be a clear win/win!

This pattern of prevent or detect, inform and solve is one well worth remembering for us as BAs.  I hope that you find it useful in your process analysis and definition!