|
|
article
page | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
correcting any misplaced information on the ticket. No matter how complex the form, these tickets cannot capture the tone and attitude of the customer. Service issues appear in the NOC with little detail on the true experience of the customer.
Enter the Service Management applications introduced around the turn of the last century, that attempted to bridge the gap between the Customer Service Representative and the NOC Technician, by creating a customer facing NOC role; a sort of technician-in-the-middle that could review the information provided by the CSR, determine if it could be passed directly to the NOC technician for resolution, or if they should
|
|
|
“One of the reasons they put in the SOC and then reinstalled the call center as intermediaries is that it seems technical expertise and customer interface skills can’t coexist.” |
|
|
customer.” Network facing engineers in the NOC began to concentrate on network health – responding only to specific queries from the SOC, and as a result, lost the big-picture, end-to-end view. Because of the multitude of networks affected by the newer services, frequently there were many NOC groups, each watching a type of network technology, or a geographical segment of the
|
|
|
|
keep the ticket and first perform some additional investigation. This Service Management (SM) application was initially just another terminal in the already cluttered NOC environment. Data and event integration from the element and network management applications into the SM was not easy, often involving complex logic, queries, and aggregation of information. This was never plug-and-play software. Often the integration remained mostly swivel chair. As the SM was not pre-integrated the way element Managers were to Network Managers, it was easier to train up a subgroup of the NOC as exclusive users of these new tools. Soon these engineers became a group into themselves; developing special and unique skills that were not immediately interchangeable with the network facing engineers. The Service Operations Center (SOC) evolved into place; and once established, spread as a pattern from operator to operator.
Jacqui Namsoo, Senior Business Analyst at LTC International explains: “So the Call Centre takes the call and logs the ticket, the SOC then takes it over from there and performs the different levels of diagnostics through to resolution and the call center calls back to confirm resolution with the
|
|
network. It was the role of the SOC to determine who to contact and what to do with the answer. Only the SOC engineer had an end-to-end view of the service and could isolate the cause of the problem - if they received sufficient starting information from the Contact Center.
On the other hand, positioning the NOC or SOC to talk directly to the customer can cause its own problems. Jacqui Namsoo explains with an example from a service provider with whom she recently worked: “One of the reasons they put in the SOC and then reinstalled the call center as intermediaries is that it seems technical expertise and customer interface skills can’t coexist. The NOC and SOC staffs were often rude to the customers so the company put in a “concerned voice” to take the initial contact.”
This is not an ideal solution either, because customers want quick and certain resolution. Customers are unhappy when the call center cannot answer the question and have to wait for an answer from another department – the knowledge levels are spread thin and are diluted among more people. Ms. Namsoo continues: “The communication chain is itself
|
article
page | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
|
|
