|
|
article page | 1 | 2 | 3
For example:
Work shedding: In telecommunications, the applications in OSS that traditionally facilitate customer relations and satisfaction are Trouble Ticket systems and, to a lesser extent, Customer Network Management applications. It was not long ago that the communications companies believed the best strategy to accomplish all the work that needed to be done for complex future product systems was to hand that work off to the customer. Really! Let customers do their own data entry for orders; they will make fewer mistakes. Let customers recognize the alarms for their leased circuits; they can decide if the problem is real. And finally, let customers open their own Trouble Ticket systems; they understand their problem best.
Well, customer opened trouble ticket systems for telecoms and enterprise help desks are now standard. And customers do enter their own information into orders. Internet web portals accomplished this data capture reengineering marvel. Sigh! The reasons behind this are mostly incorrect. Customers cannot design their own networks or, at least strategically, it is not always best to ask this of them; for when they can, they do not need service providers. Customers make data entry mistakes also, and even if they have responsibility for the errors, it does not make for an accurately delivered bill. And customers are not best at recognizing significant QoS problems and communicating the nature of their problem. In the future, automation and group intelligence must be applied to this.
|
|
"In truth, getting orders, designs, and trouble reports correct is a partnership activity of service providers and customers." |
|
Engaging the whole team at once: QoS troubleshooting is going to be quite complex. Adding custom policy for individual customer SLA requirements, each negotiated separately in cutthroat competition, will complicate this more. The future trouble correction systems and customer relationship “killer application” will be team collaboration. Upon receipt of an automated QoS threshold event, a network alarm on an access circuit, or a customer visiting a portal (not entering data, but pushing the connect button), the automated collaboration engine will kick into gear. Based on information automatically gleamed from the network or probe, or from directed customer questions via an AJAX (Automated JavaScript and XML) interactive portal, the rapid reaction collaboration system will use policy, availability, experience, skills, job roles, and past positive interaction ratings with the customer to automatically select and assemble the best, available team to solve this issue. Then these experts will get a common view of the problem, all the data gathered at once before them, a menu of potential network commands, and communications tools to interact as a team (wikis, blogs, instant messengers) and automatically set up IP conference calls.
|
|
|
|
|
Handoffs are evil: In truth, getting orders, designs, and trouble reports correct is a partnership activity of service providers and customers. And the best partnership is a team. This is my longstanding gripe with Trouble Ticket systems: the workflow model of information capture, assignment, activity and hand-off does not fit the way NOCs actually operate. Spend time watching a NOC floor and you will see ad hoc teams congregating around problems. They will dial up conference calls with field operatives and domain experts. Then, having jointly decided the best course of action, they must go back to their desks and send the work on to each in succession to access their role-based tools and enter the trouble report information – over and over. Handoffs are evil; they waste time and dollars and interfere with the natural flow of NOC activity. People do better work, finish restorations quicker, and are more satisfied when working these problems in teams.
|
|
These systems, depending on the SLA policy rules, can network in the customer account team and/or the customer contact. Working together, such teams can solve problems more accurately with fewer wasted resources than traditional network managers & trouble ticket systems. Customers get very positive memories from working with the provider to reach common goals. And of course, there are many fewer misunderstandings.
The bottom line: With careful thought, appropriate application of standards and tools, and lots of observation of real people solving real problems, we can perhaps design a balanced system that works efficiently.
|
|
|
|
