7.2 Customer Communication

7.2 Customer Communication

Customer communication processes and procedures focus on delivering timely information to the customer. Most discussions on poor customer satisfaction usually lead back to a lack of communication. Customers hate not knowing what is happening in their environment.

We could all probably relate to an experience where some event took place that we had little or no control over. This created frustration and dissatisfaction on our part. It could be as simple as waiting in a checkout line at the supermarket in which the line wasn't moving. Your anxiety grows as you witness the cashier and the customer ahead of you just standing around, seemly waiting for something, and thinking to yourself, should I move to a new line or should I wait it out? You become frustrated, not because you have to wait, but because you do not know what the problem is and how long it might be before it is resolved. If the cashier was able to take a moment and communicate to you why there was a holdup, you would gain that "sense of control" we all seek. Frustration would begin to diminish and you would now be able to make a decision about moving to a new line or waiting it out.

Customers of IT organizations sense that same level of frustration and dissatisfaction when problems occur with their computing environment that they are not informed of. It might not be possible to let each customer know personally what the problems are, but there are several customer communication processes that can be implemented to improve overall communications. These processes are:

• Help Desk Notification

• Customer Escalation

• Customer Contact List

• Exception Reporting

• Schedule Outage Notification

By implementing these customer communication processes, you are one step closer to improving customer satisfaction. However, to fully implement these processes, each one must be reviewed with the customer and, most importantly ”get customer buy-in!

In the ISD organization, the enforcement of team members adhering to the processes and procedures is the responsibility of the ISD management team. The management team must ensure that every person on his or her team understands and follows the processes. One way to ensure processes are followed is to make them part of the employee's performance review. Set goals that key processes in the organization are followed 100 percent of the time. Then review the goals quarterly to reinforce the importance of following processes.

Other methods to enforce the importance of adhering to processes are: post key processes in the office area of employees; have the processes enlarged into poster size; or reduce the processes to credit card size to be carried by employees in their wallet.

7.2.1 Help Desk Notification Procedure

Because of extensive proactive monitoring, the ISD team usually recognizes problems before the customer realizes the same problems. By putting in place an internal help desk notification procedure, the ISD organization is able to communicate the problem to the customer in a timely fashion. Below is an example of an internal ISD help desk notification procedure where an ISD team member (SA, DBA, OSA) notifies the help desk of the problem. The help desk then communicates the problem to the customers. It also prepares the help desk for calls that might be coming in related to the problem.

7.2.1.1 Help Desk Notification

When an infrastructure-related problem occurs, the ISD team (SAs, DBAs, OSAs, etc.) will call the help desk as soon as possible to notify them of the problem. Because of extensive proactive monitoring, the ISD team recognizes problems before the customer is aware of the same problem. The help desk will then call "key" customers and inform them of the problem and probable resolution time. This also gives the help desk advance notice of any new calls that might be received because of the problem. The help desk is then able to properly communicate the problem and estimated resolution time. At the conclusion (resolution) of the problem the ISD team will contact the help desk and request the "key" customer be contacted with the new status. For priority 1 problems, the ISD team will call the help desk every two hours or an agreed upon time frame to update the status of the problem.

There are times when the customer bypasses the help desk and calls the ISD team member directly about a problem with their computing environment. When this occurs, the ISD team member should inform the customer to call the help desk to open a ticket. Even though the ISD team member asked the customer to call the help desk, the ISD team member also needs to call the help desk to inform them of the problem and the estimated resolution time. The customer is responsible for opening the ticket. The ISD team member is responsible for updating the ticket with the current status.

Examples of events in which the help desk should be notified:

• Scheduled maintenance shutdown (planned with customers)

• Scheduled shutdown for hardware replacement (medium urgency)

• Emergency shutdowns

• Downed databases and servers

• Known problems including slowdowns and technical outages

The help desk will open a ticket when a customer has called to report an issue or problem and close the ticket when the ISD team member calls to state the issue has been resolved. The ISD team member is responsible for follow-up written communication on the problem per the exception report process.

7.2.2 Customer Escalation Process

There are certain computing environment problems that require the ISD team to disrupt customers by taking some action to fix the problem. This usually involves bouncing a database, rebooting a server, or taking a server down for an extended period of time to fix a hardware problem. When action is required to fix a problem that will affect the system availability, the customer escalation process needs to be followed. This process gets the customer involved in making the decision. Since the action to fix the problem usually occurs outside the window of allowable system downtime, it is important to get customer buy-in to the action being taken.

An ISD team member initiates this process when he recognizes a system problem that needs attention. The process outlines exactly which customers are the decision makers in the organization. These are the customers that need to be called to get buy-in to the recommended action to be taken. The customer and the ISD team member jointly make a decision on how to resolve the problem. Below is an example of this process.

7.2.2.1 Customer Escalation

The escalation process needs to be followed when a condition occurs with a server and/or database that is outside the LOS agreement. Most production servers have an LOS agreement that requires the server and database to be available seven days a week, 22 hours a day. The operations schedule shows the LOS uptime requirement for each server. The following examples are conditions that follow the escalation process:

• When a server/database needs to be taken down during the LOS uptime, the customer should be informed of the condition and given the options available to correct the problem. The customer has the option to wait until the scheduled downtime to fix the condition.

• When a server/database has come down on its own, the customer should be informed of the condition and the plan for resolution.

Some examples of occurrences that causes escalation conditions:

• Hardware failure and replacement during LOS uptime

• Server hang and reboot during LOS uptime

• Database shutdown and startup to clear locks during LOS uptime

Use the customer contact list to identify who needs to be contacted in the customer escalation process. The customer contacts are bolded, the technical contacts are in italics, and the managerial contacts are printed in normal font.

When a condition occurs that needs to be escalated:

• Call the primary customer contacts. If they are not available, leave a message about the condition and inform them of the actions you will be taking.

• Call the ISD team leaders .

• Call the ISD help desk to inform them of the condition and plan for resolution.

7.2.2.2 Customer Contact List

One of the keys to effective customer communication is knowing who your customers are and how to reach them. The customer contact list provides the ISD team with technical contacts as well as customer contacts. Table 7-1 shows an example of a customer contact list. It lists the customer by server and the application that the customer is associated with. The list is used for several customer communication processes and procedures.

Table  7-1. The Customer Contact List

Server	Application	Customer Notification
UNIX-12 UNX1-3 NT-01	ERP	Nino Thomas 555-1212 Anthony Jones 555-1212 Sally Figure Jane Smith ISD Manager - Joe Good Help Desk 555-1212 SA Team DL
UNIX-A1	Multi National Purchasing (MNP)	Mary Worker - 555-4435 ISD Manager - Joe Good Help Desk 555-1212 SA Team DL
WEB-01 CAL-01 ATL-05		Maura Reilly 555-1211 Jay Hughes 555-1212 Maria Tardugno 555-1181 Deb King Tom Connie Mark Banks ISD Manager - Joe Good Help Desk 555-1212
UNIX-76 NT-12	HR	Steven Jones 555-1212 Albert Tomm 555-1212 Catherine Tardugno 555-9110 ISD Manager - Joe Good Help Desk 555-1212 SA Team DL

Not only is it important to communicate with the customer, it is also important to keep key members of the ISD organization informed. In the example below we have chosen to add the help desk, SA manager, DBA manager, and operations manager to the list in addition to the customer. It is the responsibility of the managers to forward to their team as needed.

Table 7-1 outlines the contact points to be used for escalation, exception, and schedule outage communications. The person(s) in bold are used for escalation processes in which phone calls are made. They are also to be included with the rest of the people in written communication for exception and schedule outage.

7.2.3 Exception Reporting Process

Exception reporting is a formal written notification to the customer informing them of a problem with their computing environment. The exception report is usually after the fact. It has a set format and must be delivered within 24 hours of the problem to provide timely information to the customer. It is the ISD team leader's responsibility to complete and send out the exception report. The customer contact list is used to determine the distribution of the report.

7.2.3.1 Exception Reporting

Customers will be notified via e-mail within 24 hours of a server exception condition. Use Table 7-1 to find the customer notification list based on the server and application that experienced the exception. Be aware that some servers have multiple applications. If the exception is serverwide, send the notification to all application customers on the server.

Server exception notices must be sent under the following conditions:

• Failed production gzips (database backups )

• Failed refreshes of production DSS databases

• Server down outside of LOS agreement

• Equipment failure

• Network outage

• Server down

• User connectivity failure due to server-related issue

Exception Report Format

DATE ”date and time of exception condition.

PROBLEM DEFINITION ”what server, database software, etc., had the condition, along with a short description of the problem?

ROOT CAUSE ”what caused the problem?

RESOLUTION ”how the problem was fixed.

FOLLOW-UP ACTIONS ”what will be done in the future to prevent the problem from reoccuring?

Exception Report Example

DATE ”2/23/96, 6 a.m.

PROBLEM DEFINITION ”Production server UNIX-03 not restoring database correctly.

ROOT CAUSE

1. It was found that the scripts were not working correctly due to a permission problem in the ORACLE and ORAAPPS accounts.

2. The ".rhosts" files in the ORACLE and ORAAPPS home directories were rearranged, with root having the least permissions for equivalency.

RESOLUTION ”Both ".rhosts" files were corrected and the refresh, gzips, and database start/stops were tested manually. All scripts were tested and verified to work correctly.

FOLLOW-UP ACTIONS ”A follow-up note explaining the importance of the file will be distributed.