Providing an IVR platform with Service Fault Data

Dan Maynard
021 810 814

This presentation is designed to be read stand alone rather than presented. As such there is more text than usual, please persevere.

with the IVR equipping the customer service agent with details of faults affecting the customer before they talk to the customer .Problem Definition To increase the level of knowledge in the IVR platform regarding customer affecting faults. with the aims of:  Dealing with more customers solely within the IVR And / or  Reducing average customer handling times.

Customer ID b. Query ii.Summary Network Faults Load Process Customer Contact: Issue Fault Log i. Customer problem statement c. Known issues effecting that customer Customer Service Agent . before the customer was passed to the CSA ‡ Some issues might then be handled solely by the IVR ‡ Preliminary work shows there is potential value that fault data could bring to the customer fault handling process and would warrant further investigation a. Response IVR Platform ‡ The current network monitoring provides visibility of many of the service effecting issues ‡ This information would provide the IVR and CSA with likely causes for some of the customer¶s stated issues.

In general: there is very little end to end service monitoring in the VF network. an issue with a voice call could be related to the handset. and the nodes themselves. Earlier this year VF Group Procurement ± acting under the VF Purchasing Company (VPC) ± ran an RFP for Next Generation Service Assurance (NGSA). The majority of the monitoring is of the individual links between the network nodes that support a service. There is no deployment date for VF NZ. Faults from these nodes and the links between them need to be correlated in order to answers the simple question of µWhat¶s wrong with my phone service?´ Fault management is now moving from link and node based alarming to service based monitoring. their name for the system that will do this. the core network the party the caller is dialling or billing and credit systems. principally by defining which links and nodes carry which services and then correlating the issues from these components into a single service view. Customers usually experience faults with a service so the data from the individual link and node monitors must be correlated together to provide a service view of any issues present. What¶s Happening Now ? . There were two successful candidates selected but to date these are only deployed in 2 of VF¶s 35 operating companies. the Radio Access Network (RAN). and this was done prior to the RFP. For example.

These two processes are straight forward and are already built into some of the monitoring systems. With intelligent use of the current monitoring data it is likely that significant numbers of faults can be identified without the need to correlate link and node alarms into a service view. . a high proportion of faults within a service will usually be associated with a single link or node. The next slide shows a simple architectural view of VF¶s network and shows what is currently monitored. This raw data would be available to the IVR though a degree of post processing would be required to reduce data volumes (some of the monitoring is at a very low level) and to associate a fault with the customers affected. Although there are few service level views for faults within VF.However Phone networks are awash with 80/20 rules.

nz V.Current Monitoring in VF NZ Radio Network Access Network Core Network Vodafone Gateway for Voice Services SMS Gateway Rest of The world Data Voice Initial Switch SMS Delivery SMS Gateway IP Cloud WWW Gateway For Data Services Full Monitoring Partial Monitoring On Demand Monitoring only Voda. V P N .

However. or has proposals for systems to address the first of these points and VF Group policy is to implement a full service view of their OpCo fault management. the link and node alarms are not yet correlated to provide a full service view.What¶s not Currently Monitored There are two main areas missing from the current network monitoring that may cause customer issues not to be recorded: 1. as previously stated. . Mobile devices Radio Access Network Additionally. 2. VF is currently running trials.

So is this worth doing now?    There is sufficient information available from the current monitoring to provide the IVR with useful information about some faults. The current fault data will need processing to a form usable by the IVR and will need association with customer identifiers These first steps will lead to a more complete solution as VF deploys additional monitoring and alarm correlation systems. Intergration of the monitoring systems into the IVR could help drive this .

Suggested Next Steps     Analysis of the current customer faults to find the most frequently occurring issues Verify these issues would be identified by the current monitoring Provide Solution design to integrate this information into the IVR Decide whether to take this forward to a Proof of Concept .

Thank You .

Sign up to vote on this title
UsefulNot useful