By Dennis D. McDonald

Last week I wrote about my experiences when my main laptop computer died. The bright spot was that I learned about the value of remotely-sourced database access through my use of DabbleDB. The dark side: my experience with my computer vendor’s service plan.

Looking back, I can see advantages and disadvantages of using social media and social networking technologies as components in overall customer and technical support situations.

First, some background. Even though I have a “gold” service plan that includes onsite technical support for my laptop, I found truth to the statement, “There’s many a slip ’twixt the cup and the lip.”

Perhaps if I had had more direct access to the communications and status of my service transaction — this is where “web 2.0” and social media come in — I would have detected earlier where problems might be occurring. And here’s the important part: the overall cost of the transaction to my vendor could have been reduced.

From the time I made the initial report of my problem to its final resolution over a week later I must have spoken by phone or in person to 5 or 6 different people. I had one online “chat” session that lasted 1.5 hours, and I received one automated telephone call.

Here are some of the things I observed:

1. The internal phone directories used by my vendor to provide customers with numbers to call are not up to date.
2. Call transfers do not always work within different departments of my vendor (which is one of the reasons why point number one is significant).
3. Individual details captured by individual employees in the service transaction differ widely. The result is that the customer has to repeat the description of the problem each time a call is made.
4. Details provided by the customer to each representative do not appear to be transferred 100% to the next contact in the chain, probably resulting in variability in diagnosis and resolution methods.
5. Really technical service technicians enjoy diagnosing and solving problems. They go out of their way to help. Unfortunately, they are not always “in charge” of the service situation.
6. In fact, following from the previous point, it is impossible to say who is “in charge” or what single person — or number — can or should be called at any one time to check on the status of the situation.
7. It is clear based on what individual service technicians say that multiple systems are involved in capturing service requirements, ordering parts, and scheduling service calls. It appears that these systems may not “talk to each other” and appear in some cases to rely on human intervention for the transfer of data from one system to another.
8. I do not want to think about the number of times I repeatedly told people my physical home address even after I provided my various service tag numbers and problem codes.
9. When I talked with people I always asked where they were sitting. I had the impression that everyone I spoke with was in a different city.
10. I received one automated call telling me that a part that I had thought had been ordered 4 days before was being delayed in shipping. Based on subsequent conversations I do not believe that the fact that this call was made or received was logged anywhere.

Anyway, my computer is now fixed. I now have a new charger that not only powers my computer but also charges my battery (my old one wouldn’t charge the batteries or the computer), a new motherboard, and a new screen. I have had two in-home service calls. I have two email addresses to contact, one from an individual who called to check on things because an unusual number of contacts had been detected in my service history.

That last item is a good thing; somebody does appear to be looking at the overall process. But borrowing from basic methods of quality control, had a single point of management existed right from the start, downstream problems — and costs — might have been avoided.

Let’s consider the following scenario as an alternative to the sequence of events that I experienced. 

1. Customer calls with computer problem. After a diagnostic session it is determined that physical service and repairs will be necessary. 
2. Company issues a trouble ticket. (Okay, you can call it a “customer care” ticket if you want.)
3. Issuance of a trouble ticket automatically spawns a temporary web site that (a) can be accessed by all authorized service and support staff, and (b) can only be accessed by the customer after appropriate security procedures. (You can call this a “blog” if you want but that’s not the point.)
4. Company uses the web site to coordinate all information. It brings together all threads that deal with the Customer’s problem, whether the information is system generated or manually input.
5. Also accessible are MP3’s of all phone conversations with the customer where the Customer has automated such recordings.
6. Records of any chat sessions are available.
7. When the Customer logs into the problem specific web site the customer sees in read-only form the same data that the customer service reps and the service technicians see.
8. The Customer can append a typed or recorded comment to any item and via email or RSS receives a message when that item is acted on. (If I had had that ability I could have proposed corrections for some of the errors that were introduced into my own transaction that might have doubled the overall length of the entire process of getting my machine back up and running).
9. The Customer can see a profile for all individuals involved in the process - names, locations, email addresses, and phone numbers — even the “secret” phone numbers that reps seem to grudgingly give out when things start to get dicey.
10. Buttons will be available to indicae when staff are availabe for Instant Messaging, which can be used to support customer-to-company or within-company messaging.
11. Instant messages are always recorded and appended to the record.
12. Photographs of all staff on the “team” would be nice, too.
13. Company staff can subscribe to feeds that indicate when a record is changed or a comment is added.
14. The system automatically generates a graphical timeline that shows past and future anticipated events along with critical dependencies or milestones that are known in advance (such as “service technician needs new part in hand before old part can be swapped out”).
15. When the trouble ticket is closed all those who have been involved in the process are informed of that fact and they all receive the customer’s evaluation of the process and their role in satisfying the customer.

I can think of many reasons why this type of system will have difficulties, but let’s list some of the advantages:

1. Instead of passing off responsibility for resolution down the chain, this approach creates a team where members share a common goal in resolving the problem.
2. The customer is actively involved in participating in — and to some extent “managing” — the process.
3. A single system location is created where anyone on the team, on management, or in quality control, can quickly see what is happening and suggest interventions.

Many of these ideas are not new. If you’ve ever worked with dedicated field service repair staff, for example, you’ll know how receptive they are to real tools that help them makeservice calls easier and more successful. And they will be the first to admit how important team-building is in terms of loyalty and dedication, especially when members of the team are spread around the country (or the world). And certainly if you have ever worked in call centers you’ll appreciate how important it is to capture the customer’s problem right the first time without having to make him or her repeat the same story every time a new person is added to the transaction.

What is potentially different about this is that it explicitly includes the customer in the process by providing the customer access to the same systems and information that the service and repair technicians see.  This idea may threaten some people. But thinking back to my recent experience, had I seen some of the information that was in the record near real time, some decisions might have been made that would have resolved my problem sooner while saving the company money in the process.

Copyright (c) 2006 by Dennis D. McDonald