MUST FOLLOW PROCESS...

MUST FOLLOW PROCESS.... MUST FOLLOW PROCESS...

Starting with the premise that we need our customers to be happy with us, what do we need to do as an organisation to keep them that way?

We are working through steps to improve our customer satisfaction at work by carefully considering how our daily work routines, processes and actions impact our customers.

Consider this fairly typical example of how an organisation might respond to a customer request:

[NOTE: This is a little bit (A LOT) satirical and not meant to in anyway be a real representation of an actual process. It's designed to highlight how strict adherence to process can lead to unhappy customers.]

A customer needs a new type of widget. Your organisation sells gadgets that are very similar to widgets so they approach you to design and build one for them. They are willing to pay for the service but they need this new widget to work for them.

Luckily your organisation has a process to handle this type of request. It's called Customer Request Acceptance Process. It is a sequence of actions scraped out of a managerial text book written in the early 1900's.

So the sales rep in your organisation finds the appropriate template and begins...

  1. The sales rep spends 2 hours working out how best to express his customer's requirements on the template. The template is designed to be all encompassing providing options for everything. Clearly (from looking at the template) anything not covered by it's fields are not valid for submission. [Templates have their place but be careful of over detailing them - they get confusing. A good place to start is a subject and details box. Leave the rest to the technical guys to nut out.]
  2. The working group that handle inbound requests receive the completed form and instantly find gaps in information. They make assumptions about some of the more obvious omissions and request clarification from the sales rep on the others. [Leave the mind reading to the professionals]
  3. The sales rep is very confident that he understands 90% of the questions and answers them straight away and on the other 10% he seeks clarification. [More mind reading...]
  4. Finally the requirements are gathered (from the sales rep and via a series of mini assumptions about unimportant details)
  5. A quote is hastily written up and the sales rep informed. The sales rep sells the solution to the customer. [the solution has to be sold??? I thought the customer asked for it in the first place. Be careful! If you have to **sell** the solution to a customer request then it's probably not what they wanted.]
  6. The tech team receive the go-ahead and begin work on the widget. The widget is FANTASTIC. It's so damn clever, some individuals are already talking about it to their contacts in an effort to drum up even more revenue. [Woooah there Silver, Does it work for the customer? Has anyone asked them?]
  7. The widget is delivered more or less on schedule. [Good work guys - go eat pizza and have a celebration.]
  8. The customer finds that it sort-of does what it's supposed to do but they don't complain because they have come to expect this sort of thing from the organisation.[What??? This is acceptable to you Mr. Customer? Find another provider already!]
  9. Your organisation sends the customer a survey asking how happy they are and soon it becomes apparent that they are not. [By sending a survey out you send a message saying that you need to know what's wrong before you can fix it. If you don't fix it your customer will assume your are being cynical about the whole survey thing and not bother answering it.]

My point with this extremely obvious example is that:

a happy customer is very simply a customer that you talk to all the time!

So while your organisation might have a process and tools to manage that process, it's useless if you don't know what your customer really wants.

Some customers are not too good at telling us what they really want.
Most of the time, I suggest that we are not placing the appropriate individuals in our organisations together. IE: Customer end user of WIDGET next to the provider technical person designing the WIDGET. It makes sense that these two should work closely together.

Providers should develop fast prototypes and be less precious about the their solutions in case they end up not being fit for purpose. Every time a mistake is corrected, your product is improved.

It is impossible to gather all the requirements in one go. Requirements have a way of evolving as the design takes shape.

No amount of technology based tools to manage your processes will help you if your processes do not include the customer at every step.

Every step in your process that does not include the customer results in your product diverging further from the customer's requirements.

We should all evaluate all the time how what we do impacts the customer. If you don't know how your job impacts your customers, you should make it your number one concern to find out. Customers pay your salary. Not your boss or your manager.

Comments

Popular posts from this blog

Automatically mount NVME volumes in AWS EC2 on Windows with Cloudformation and Powershell Userdata

Extending the AD Schema on Samba4 - Part 2

Python + inotify = Pyinotify [ how to watch folders for file activity ]