Tuesday, June 05, 2007

Some thoughts on support

I recently made some notes on customer service/support. Thought I'd share them here too.



The Customer Service function is a public face for the company. Customers need to contact the company when they have a problem that is stopping them from doing their job. At this time the customer will get to see how the company values them. Does the company appreciate the customer’s problem and resolve it as quickly and simply as possible? After all, isn’t this all that the customer is interested in?


Customer Service is an expense. It costs money to perform and doesn’t generate any direct income.


When performed well Customer Service can make money for the company. It does this by helping ensure customer retention and upgrade. It also improves the reputation of the company and product to potential new customers through word of mouth.


The Customer Services department has the opportunity to gather valuable information about customers and their use of a system. This can be invaluable when planning development schedules, particularly with regard to prioritising ‘bug fixes’.


While there is a department given the title of ‘Customer Services’ the responsibilities of serving the customer fall on everyone in the company.

Customer Services are part of a company wide process that seeks (among other things) to achieve the following goals:

1. Customers shouldn't have to make calls to the CS department.

We should aim to avoid the perception that something will go wrong!

While perfect software (that never goes wrong) is not a practical reality, it should be the intention of the company to provide a product with no known issues and is able to work under all conditions. Dealing with support calls costs the company money and creates a bad user experience. It should therefore be avoided, where at all possible.


2. When customers do have to call the CS department, their experience should be positive and more than just satisfactory.

Delighted customers are loyal customers, who talk about how good experiences.

Using a back-tested paper portfolio and an actual case, the authors of a study published in the Journal of Marketing found that companies at the top 20% of the American Customer Satisfaction Index (ACSI) greatly outperformed the stock market, generating a 40% return.
From 1996-2003, the portfolio outperformed the Dow Jones Industrial Average by 93%, the S&P 500 by 201%, and NASDAQ by 335%.”
http://consumerist.com/consumer/personal-finance/how-to-beat-the-stock-market-buy-companies-with-high-customer-satisfaction-scores-261282.php



3. When a customer does have to make a call, it should be as productive as possible.

This is a business. We need to use our time effectively.

The customer should always be left with a positive impression and be satisfied that their issue will be dealt with as quickly as possible.

Because of the effort and cost involved in dealing with a problem, and because we want the customer’s problem resolved as quickly as possible we should aim to obtain all the information we need to resolve the issue, when the issue is first reported. While making multiple calls to the customer to request more information does show to the customer that an issue is being investigated, it can also show a level of disorganisation in not requesting all the information in the first place. It also adds to the total amount to time taken to resolve an issue.


4. Communications between customers and the Customer Service dept should be recorded for two purposes:
i. As part of managing the relationship with the customer.

If it’s a big customer the account manager may want to know about the problems.

If a sales person is going to contact a customer (to try and up-sell or talk about license renewals) they will benefit from knowing if they have had any problems and how they were dealt with.

“I am very sorry for all the problems you have had. We will take this into
account when we look at your license renewal.”

“You’ve seen how valuable
a support contract is and how quickly we were able to deal with the problem you
had.”


ii. To keep track of which areas of the program are having repeated problems/issues.

- Are lots of people having the same problem?
If so, do we need to improve the program/ documentation/ training in light of this?
- Are some customers having more problems than others?
If so, do we need to provide (re)training for them?
- If the first few customers to do something (i.e. upgrade) have a problem?
Do we need to warn other customers who are, shortly, likely to do the same thing?
- Are customers having problems due to a configuration issue that is different to our testing and development environments?
If so, do we need to create suitable test environments? (This might not be financially viable if it was just one customer.)
- If one customer has a problem but finds a work around, do we fix the cause of the problem?
If it’s just that one customer may be not. But if it is lots of customers we will want to fix the problem before other customers become aware of it and have to use the work around. (Remember, it’s not just a case of telling them. Either we tell everyone there is a problem that they may or may not have to deal with – possibly makes us look bad, depending on the circumstances. Or, we wait for them to discover the issue and contact us. While we may be able to provide an immediate solution, the customer has experienced the frustration/ inconvenience/ cost of experiencing the problem.)



Service Level Agreements and Multiple Levels of Support

Service Level Agreements (SLAs) can be formal or informal.

- Formal SLAs are part of a contractual agreement with the customer.

- Informal SLAs are estimated guidelines, either advised to the customer or only used internally.

If neither formal nor informal SLAs exist there is the potential for incidents to be considered unimportant and not be given the attention required.

“I don’t have to do this today, so it can wait for tomorrow.”


Multiple levels of support exist when incidents are handled by different people under different conditions and when a process of escalation exists.

If having service level agreements and/or multi-level support levels, they must be clearly defined so:

- Sales people know what to sell.
- Customers no what to expect.
- Customer Services team members know what the customer expects of them.
- Customer Services team members know what the company expects of them when they are talking with a customer and dealing with an incident.
- Customer Services team members know the conditions under which an incident can or should be escalated. And to whom.
- Developers who have issues escalated to them are aware of expectations and promises that have been set and made.



Incident handling and escalation

At a basic level all calls should be handled in the same way. This includes a taking the call in a professional and courteous manner, but also in gathering some standard information for every incident, regardless of what the incident is.

By ensuring that all calls are handled in the same way:
- The customer knows what to expect, regardless of who answers the phone.
- We know that enough information has been gathered for internal purposes.
- Sufficient information is available for anyone to whom the incident is escalated.

Plenty of customer service people would like to do the right thing. They'd like to fix the problem that's presented to them. But frustration hits when the policies and procedures and metrics they've been given to work with won't let
them.

For a service rep in this particular situation, "doing my job" means making the person go away, while "doing the right thing" means taking initiative and actually solving the problem.

Getting your team in alignment (having their job match their tools match their mission) is perhaps the first job … to do.”
http://sethgodin.typepad.com/seths_blog/2007/05/alignment.html

What information to gather

In addition to the basic information gathered for each call/incident, specific information may be needed for different types of issue or product.
- If an incident relates to installation we need to know X, Y & Z.
- If an incident relates to printing we need to know A & B.
- If an incident relates to … we need to know F, G & H.
- ….

While it is probable that an initial version of the question list could be developed now, it is likely that such a list of questions can only be fully developed over time.

A question list should not be set in stone and is likely to develop over time and in line with enhancements and developments to products.

A question work flow may be an appropriate way of managing which questions should be asked, based on the incident being reported.

In addition to the list of questions, details explaining why each specific question is asked should also be recorded. This aims to remove any doubts as to why the questions should be asked.


Documenting an incident

The most important part of handling a reported incident is to:

WRITE EVERYTHING DOWN!

Or, better still record the call and use a speech to text tool to handle the dictation. Or, even better still apply the text to speech processing to the call as it is happening, so any corrections can be made at the time.

It is important that nothing is assumed. When recording information it is important to record exactly what the problem is, which version of which product it is experienced in and all the steps needed to recreate it.

Specifics are very important.

Without specific details the chances of finding and resolving an incident are greatly reduced. This is due to the fact that most incidents only occur under very specific circumstances.

The only questions a developer handling an escalated support call should be “What is the reference/log number for the call/incident?”

They then need time to read the details documented so far (to get up to speed) before being expected to be able to respond to, discuss or investigate the issue.


Reasons to record everything that happens as part of an incident investigation:
- So not relying on memory to know what happened or has been tried so far. - Saving repetition of asking or attempting possible soultions.
- So the solution can be documented so it is available if needed again.
- So the solution can be used to patch code so it can't/doesn’t happen again.
- So that if another person needs to get involved in solving the problem they know all that has happened so far.


How rest of the company can help the support department/process:

· Provide documentation for all parts of the program.
· Share training/debugging tips and solutions.
· Document solutions and resolutions to problems.
· Any more ideas . . . ?

0 comments:

Post a Comment

I get a lot of comment spam :( - moderation may take a while.