Have You Experienced Your Customer’s Perspective on Your Business Processes?

Stop Sign

Strict and rigid processes and rules may lead to customers/users submitting incorrect data to get the outcomes they need

As a Business Analyst, I tend to see processes everywhere I go.  Whether I’m queuing in a coffee shop or making a hotel reservation on a website, I can’t help but draw a process diagram in my head to understand the “logic” which is hidden into the process, and the business rules that are being enforced.  Often it seems that there is significant room for improving the process.  “Why don’t they put the sugar next to the coffee cups to prevent a bottleneck” I ask myself, as I see a queue forming….

These kinds of observations highlight an important aspect to processes. Whenever “real” users and customers are involved we tend to get variation.  This might be a variation in the volume of demand (e.g. the number of customers at a given time), or the type of demand (e.g. people are asking for something that the organisation wasn’t expecting).  There might also be variation due to differences in how individual users or operators work the processes, perhaps by staff using unofficial ‘shortcuts’.

Process variation is usually seen as undesirable.  Accordingly, processes are normally locked-down and are designed so that they enforce a strict set of business rules to prevent any exceptions from occurring.

However, if a process (and its accompanying business rules) are too strict, there is a significant chance that the process won’t meet its designed objectives. There are many dimensions to this, of which I will discuss just one in this article – the reduction in the reliability of data collected during the process.

The reduction in data quality can be illustrated by a real-life example.  If you’ve tried to contact a company by phone recently, you may have experienced an Interactive Voice Response (IVR) system… “Press 1 for sales, Press 2 for service” etc.

Whenever a system like this is implemented, there will be some customers who just don’t know (or don’t care about) which option to pick. Their query is unique, and they can’t shoe-horn it into one of the 4 options on the menu. If customers find that they get the fastest response by selecting option ‘2’, they may well do so next time, irrespective of which option the organisation expects them to select. Customers are certainly not interested that organisation is collecting call statistics and management information – they just want to speak to someone that can help!

The issue exposed in this example is that the customer is deliberately giving the data (answers) that he/she thinks will get them closer to their desired outcome, rather than directly responding to the question that they are asked.  The customer is aware of the process, is familiar with it, and is trying to find the quickest possible route through it.  Who can blame them?

This phenomena isn’t unique to call centres, and it highlights some important considerations which should be considered when designing or redesigning processes:

  • Processes are rarely invisible to customers and users: As much as we’d like them to be, the chances are that the customers will see and experience the process.  Their perception of the process might be very different to the organisation’s intention.
  • Customers want service, not processes: If a customer is in a hurry, they’ll try to find better routes through your process.  And this is likely to lead to “unclean” and unreliable data and management information (MI).
  • Understanding processes outside-in is invaluable: There is huge value in observing a process “inside-out”, understanding how customers actually experience it, and what they are actually trying to achieve. User experience is of utmost importance.
  • The people that know the answers are on the front line, not the boardroom: There is a good chance that the people who know what customers really ask for are on the front line.  Executive stakeholders may be far removed from this view, and as Business Analysts we have a great opportunity to bridge this gap.

Having adaptable, responsive and efficient processes will help an organisation gain significant competitive advantage.  As Business Analysts, we have a significant part to play in this by ensuring we question current processes, and ensuring that we empathise with processes from the perspective of the organisation, the user as well as the customer.

>>Learn to Map Out End-to-End Business Processes

In Business Process Analysis, we’ll walk through a step-by-step process for mapping and documenting a business process. You’ll also have the option to receive individual instructor feedback on your model and 8 PDs or CDUs towards your IIBA certification or re-certification, and/or 8 PDUs or Contact Hours towards PMI certification or re-certification.

Click here to learn more about Business Process Analysis

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.


  1. Hi James,

    Thanks for your comment. The hotel example you give is a good one, and I totally agree with you. Often the cause of poor customer service is the system and/or measurements that staff are subjected to, rather than being the fault of the staff themselves. There is an old cliché that states “you get what you measure”, but I believe it is very true. I remember hearing a story about a call centre where agents would deliberately get customers to fax or write in to confirm their instructions, even though they could easily process the transaction over the phone. The reason? An easy piece of work to count towards their “stats”. The system was actually rewarding them for inconveniencing the customer. And worse still, all the SLAs would show as “green” so the problem was very hard to detect (and those that knew about it had little incentive to resolve it).

    You also raise a very valid point regarding usability. It’s interesting that the term usability and user-experience is often applied to a user interface, but you are absolutely right that it should actually apply to the end-to-end process. At every step, the project team should ask “Why are we asking the customer to do this, what value does it to the process, how will the customer perceive this, what is the customer trying to achieve?”

    The final point about usability is to make sure the process delivers what the customer *actually* wants/needs, rather than what the organisation wants to provide. However, that opens up a much wider debate!

    Thanks again for your thought provoking comment!


  2. I share your habit of seeing processes everywhere and getting frustrated at those that don’t really work for the customer. My most recent gripe is with a hotel chain whose process for cleaners making up rooms often results in no towels or soap being left. It’s easy to blame the individual cleaners, but it happens consistently with this chain (ok, it’s Travelodge) and I’ve not noticed it happening with other hotels. Something isn’t quite right with the process that the cleaners are following. Anyway, that’s digressing.

    I’m a tester and I’m very interested in usability. I think your concern is related. It’s not enough to define processes that can work. They have to work for the users and, so far as possible, they should go with the grain of how the users (or customers) expect to work.

    Usability testing isn’t about testing that the interface looks nice, or testing that the users can get the job done quickly enough. It should also be about evaluating the whole user interaction with the application, including the processes, so that the final product and process can be as efficient and pleasant to use as possible.

    The processes tend to be neglected. Testing focusses on the IT stuff, and can skip over the processes and the business context. The only testing technique I’m aware of that specifically looks at processes is Process Cycle Testing, See http://wawewi.com/cover/usecasetesting2en.html

    However, that is a very mechanical way of checking that the processes hang together and fit the IT applciation. I’ve found it useful when the processes have got complex, but it’s limited. To be fair, it doesn’t claim to be any more than it is.

    Testers need to work with BA’s to ensure that there is realistic testing of the users’ interaction with the whole application, and it should be based on what users can and will do, not what they should do if they acting like predefined clones.

    The subject of process variation strays over into security. I’ve seen security exposures caused by users discovering that they can adapt and subvert the official procsess in damaging ways. I blogged about this last year, discussing the link between usability and security.

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)


Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.