Mapping support processes is an important step in creating efficiency n your support environment. Through modeling of the current environment, we can compare what exists today, eliminate any unnecessary steps, and clearly define roles and responsibilities. Once the process is mapped and efficiency achieved, key measurement points within the process help management to measure process adherence.
An error in a process is defined as the number of defective transactions or defective steps in a transaction. Let me give you an example of a recent customer service experience. On a visit to my local copy center, I ordered a repeat order of very expensive, full-color print. I had an arrangement that if I sent the order to the local processing center instead of printing in the local store, I would receive a price break of over 50%. The printing process was simple:
- Bring in original file
- Print a proof copy for review
- Order quantity of over 1000
- Verify bid on file
- Approximate delivery time
- Send to processing center
- Call customer when ready
- Pick up order and pay
In each step in this printing process, errors can occur. In fact, during this recent customer service experience, an error occurred during every step of the process. Possible errors include the following:
- Damaged originals
- Not printing proofs and verifying desired final output
- Incorrect order quantity
- Bid not on file or lost
- Missed delivery projection
- Failure to notify customer
- Product not QA’d or printed to order specifications
My order had to be processed five different times resulting in over $2000 in repeated batch processing. Despite receiving awesome customer service during the printing process, the output was so prone to error that I have lost confidence in the vendor as a supplier of an important component to my manufacturing process.
Related Support Processes
In a support organization, there are numerous processes that directly impact the customer including incident management, request fulfillment, and access management. In addition, many companies offer alternative channels for support such as a self-service portal. In the incident management process, there are six key activities that include:
- Incident detection, avoidance and initiation – this is the detection of an incident, the initial call avoidance through up front messaging, and the routing of the call to the first available analyst.
- Incident recording, validate customer, and log ticket – this is where the analyst validates the customer and logs incident/request.
- Incident classification, prioritization, and matching – the step in the process where the analyst categorizes and prioritizes the incident and searches for related incidents, problems, and workarounds.
- Troubleshoot and resolve – if the analyst can solve the incident, this is the step in the process where the analyst troubleshoots the incident and resolves. If the analyst cannot resolve, then an escalation occurs and another group will complete the troubleshooting and resolve activities.
- Functional escalation – this is when an incident is sent to a different group with advanced technical knowledge required for resolution.
- Hierarchic escalation – this is an escalation when management is notified typically used for a service level breech or high priority incident.
- Update – while the incident is worked on, the service desk is accountable to keep the customer notified of status and provide updates.
- Closure – this is the activity completed when the incident is resolved. The analyst confirms that the customer is satisfied, the incident is documented correctly, and incident is closed.
Each one of these activities should be mapped out in a process flow to ensure that the process is efficient and that roles and responsibilities are defined. Performance metrics related to measuring the processes’ efficiency and outcome are required to manage the process and understand the value it provides to customers. However, process metrics are only one element of ensuring high customer satisfaction. Error rate must also be measured and thresholds of tolerance established.
Each of the incident management process activities has potential associated errors. During the incident detection, avoidance and initiation activities, errors can result from customers entering into the support organization through the wrong channel. For example, the customer called the sales phone number instead of a support phone number. The customer may enter an incident into the self-service request portal. Although human error cannot be prevented, it is important to understand how many times an error occurs and whether action must be taken to more fully communicate the channels and options to the customer via the web, all support documentation, and possibly on product packaging.
Another error can occur be if a customer selects the wrong choice in an upfront IVR (interactive voice response) system and must be immediately transferred to the correct support group. The frequency of this error could be the result of a failure to design an intuitive system with options that the customer understands.
During the incident recording, validate customer, and log ticket activities, potential errors include provisioning service to non-authorized customers, failure to enter appropriate customer details into the incident ticket, or incorrectly documenting the issue the customer is experiencing. In the incident classification, prioritization, and matching activities, an incorrect classification or prioritization will result in reporting problems and missed SLAs. During troubleshoot and resolve, potential errors include not confirming resolution with the customer, inadequate ticket documentation of resolution, or service level breach. Incorrect assignment to the appropriate resolution group is an error within the functional escalation. This error is a common mistake that plagues many service centers. And the greatest potential error for closure is that the customer’s issue was not resolved.
Errors in Incident Management result in lower customer perception of the quality of the services your organization provides. Even with great customer service skills and rapid response to fix the errors for an individual customer, the overall issue may not be addressed, and overall process efficiency decreases with repeated steps or errors in the process.
Using Six Sigma
Six Sigma provides a framework for measuring errors in the process. To achieve Six Sigma, your organization must only have 3.4 defects per million opportunities. Achieving Six Sigma may be too expensive for a service organization and must be weighed against the customer benefits in service to the cost to provide those services. Some organizations have no choice but to deliver services with little or no defects. Usually, these are organizations that are providing a critical service where even one mistake is costly. In most organizations, some error can be tolerated without a loss of customer loyalty.
To determine your organization’s error rate, first you must have the ability to track to the individual activities in the process. Often these metrics are captured within our incident management or telephony systems. These metrics provide us with volume data but may not provide visibility on the number of errors associated with a particular activity. For example, we can easily provide information on how many incidents had to be escalated for technical resolution. This information can be obtained by running a report on the number of incidents assigned to resolution groups from the service center. However, to determine how many of those incidents were assigned to the incorrect resolution group may require modifications such as a tick box within the ticket screen that can be checked by the resolution group before forwarding the ticket to the appropriate group.
Strategic Focus on Errors
Without an adequate understanding of error rates, the incident management process may meet all of its service level targets and key performance indicators but the underlying process is still inefficient and prone to failure. Errors are quite visible to the customer and although the process may result in incident closure and restoration of service, the road to get there is plagued with errors, rework, and failures in the process. A robust reporting system will not only evaluate process effectiveness and efficiency, but it will also measure errors and trend performance over time.
If your organization is meeting its key performance indicators and service level targets and your customers are still complaining, its time to look at errors in the process and develop ways to manage the process with fewer exceptions.