February 10, 2008   Sign In |  About ebizQ |  Contact Us |  Join ebizQ Gold Club
Keith Harrison-Broninski
IT Directions
Keith Harrison-Broninski cuts through the hype in his hands-on guide to where enterprise technology is really going.

« Securing enterprise systems | Main | Complying with rules is not the same as working to rule »

July 11, 2006
Rethinking Customer Service This is the 4th post in a blog series on implementing "distributed" people-oriented business processes - collaborative human work that is carried out in more than one location, involving more than one organization.  As discussed previously, though much (perhaps most) activity carried out in the modern workplace is of this type, and it is becoming the main competitive differentiator in business, such activity is only poorly supported by current IT technology.  This blog series outlines a way forward.

This time I will try and illustrate the proposed approach - process-based tools that are hosted on clients rather than on centralized servers - by means of an example.  And as so often happens, the perfect example dropped into my lap only recently.

Have you ever been driven into a perfect storm of rage by customer "service" from a supplier?  I try to take the long view and stay calm in most situations, but got pretty close to the edge when trying to sort out my personal broadband service during the last few days.  Over a year ago, I signed up for what was, at the time, in the UK, a fast business-grade connection, from the supplier I have used for well over a decade now.  The 12 month lock-in on the contract is now over - and since the company is currently offering a price of about half what I agreed to pay originally, I tried to contact them to sort the matter out.  This is where matters went horribly wrong, the only silver lining (to my raised blood pressure) being that the story is usefully instructive for our purposes here.

As background, the company concerned was one of the first UK ISPs.  In its early days, 1992 onwards, it was a very friendly, knowledgeable outfit with a technically-literate customer base.  The company managed its growth well, and grew rapidly, to the point where at one stage 2% of UK phone calls were to its dial-up service.  Then, after 6 years, they were bought out.  And everything changed.  In particular, the customer service effectively vanished overnight.

Before takeover, even at the height of their popularity, you used to ring their office building in suburban London, and speak to a permanent employee.  It was not unusual to speak to the same person on multiple occasions, and the person you spoke to would be the one that dealt with your case.  Now, if you email them or use their Web site to submit a support request, you are lucky if you get an automated acknowledgement, and even that won't be for a while.  If you dare to ring, on the other hand, you get forwarded from one person to another in a never-ending chain - 6 is not unusual, often not even being transferred, but having to hang up and redial - and at each stage, you must repeat your name, confirm your identity via a sequence of questions, then explain your situation all over again.  At the end of going through this sequence 3 times, all I got each time was a promise of a callback.  And none of these callbacks ever materialized.

What is the root cause of this appalling behaviour?

If we compare the current situation to the early days of this company, and make an analogy with computer systems, at the start a customer like me had what we can think of as a "channel" to the supplier (like a persistent open socket, if you are technically minded).  I could ring them, and know who I was contacting - even where the person was located. This was long before the days of calls being recorded, but the person I spoke to would take responsibility for sorting the matter out, would ring me back once they had done so, and - crucially - if I then got further problems, I could ring the person concerned on their direct line.  I never had to re-explain anything, and always knew exactly how to contact them if necessary.

Effectively, customer and supplier built and shared a "process context" - a mini-workspace, in which lived certain data and activities.  Data included my account details and any problems or issues I was facing, along with any relevant information provided by the supplier.  Activities included efforts on my side to supply additional information or carry out tests, and on their side to sort things out in various ways.

All this was accomplished informally, of course.  They may have used some kind of CRM system, but if so, I was never aware of it in any way.  What I was aware of, to my delight as a satisfied customer, was that we knew each other - "knew" in the very specific sense of understanding that we were engaged in a collaboration, and of what that collaboration consisted.  We were participants in a shared process, participants who had signed up to be involved, had agreed on the nature of the process in question, and each did their bit to ensure the process was carried out successfully.

TAKE AWAY

The functionality required to provide effective customer support is very different from CRM.  Some CRM systems may include the ability to document specific issues raised by a customer, and the actions taken on both sides, but such systems offer no ongoing means to manage that process.  And current Business Process Management or workflow products do not provide sufficient flexibility to support the full range of issues raised by customers, which are generally a highly individual concoction of requirements and problems.

The problem with CRM, BPM, et al is that they assume both customer and supplier will fit naturally into the limited range of functions offered by a pre-configured server system.  And this is so far from business reality that it is almost laughable.  In fact, the true nature of customer service is more like this:

  1. Customer (or sometimes supplier) opens a negotiation - on a number of topics, which may or may not be related.
  2. Supplier and customer exchange information, and agree next actions to be carried out - all this being highly customized to the case in question.
  3. Step 2 is repeated until both parties are satisfied.

What sort of software is required to support this behaviour?  Software that lets both parties define multi-party contracts, replete with custom data items and activities, and each keep a copy of that contract on their own system (since both parties will naturally want a record of the agreement).  Further, the software objects embodying this contract must act not only as a "system of record" but also support active engagement in the collaborative process thus defined - as well as the continual re-negotiation of this process.

It is easy to see that current Web technology does not work anything at all like this - saving or printing a page from a supplier's support Web site, for example, offers nothing like the functionality described above.  What is required is a "rich client" capable of defining, depicting, enacting and revising such collaborative contracts - a client that all parties to a process use to support the work involved.  My own efforts to provide free software of this form are surely only the start of a new wave in technology for customer service.  And for many other fields too.

In the next instalments of this series, I will look at further applications and examples of this approach to collaborative work support.  Stay tuned if you want to see what is round the corner.

And I have changed my broadband supplier, by the way.

Posted by keithhb in Business Process Management • Internet • Management |Digg This|Add to del.icio.us

Comments Post a comment




Remember Me?

(you may use HTML tags for style)

We ask that you type your code (displayed below) in the text box.This code is an image that cannot be read by a machine. It prevents automated programs from submitting comments.


Code:



Most Recent ebizQ Blog Entries
ADVERTISEMENT
RSS Subscription

Blog Roll
This Work
Accountability:The opinions expressed in this blog are solely representative of the blog's author, and not of ebizQ

Subscribe to our Newsletters
ebizQ Weekly Gold Club Update
Live Webinar Updates
Updates from ebizQ Partners
ebizQ SOA Update
ebizQ BPM Update
ebizQ Security Update
ebizQ BI Update
ebizQ Open Source Software Update
Virtual Show Newsletter
Your E-mail Address:
BAM: The Killer App for CEP
Date: Feb 12, 2008
Time: 12:00 PM ET
(17:00 GMT)

I WANT TO ATTEND
Event Processing Market Pulse
Date: Feb 14, 2008
Time: 12:00 PM ET
(17:00 GMT)

I WANT TO ATTEND
Archived Webinars | Upcoming Webinars

Marketing Solutions | Feedback | About ebizQ | Unsubscribe | Privacy Policy | Site Map