Billing System Locked Accounts
The cable company referenced in this example used AMDOCs as its primary CRM/Billing system. This system was accessed thousands of times per day by customers and field techs. Accounts which users were logged into were locked after 15 minutes of non-use. The system was designed to reset these locked accounts after an additional five minutes, but periodically failed to do so. When an account failed to reset, the customer or the field tech who was unable to get into the system contacted the call center. The call center staff then opened a service ticket that got assigned to the production support staff for the CRM/Billing system. To resolve the issue, a member of the production support staff logged into the appropriate domain, verified some information, manually reset the account, updated the service ticket, and finally closed the ticket. This process took about thirty minutes from the time the call center was initially contacted.
The process itself was not terribly costly, if it happened only once. The problem was, this issue occurred nearly 8,000 times per month. As a result, four full-time equivalent staff (FTE) were dedicated to this process in the call center ($200K annual cost), eight FTEs in production support ($800K annually), and almost 24,000 hours of field tech time were wasted every year ($960K annually). All in all, this anomaly in the CRM/Billing system cost the company almost $2 million annually – not to mention the thousands of disgruntled customers impacted by these lockouts.
The company attacked this problem by using Optinuity Oasis™ to implement an Autonomic Policy for this system. This Autonomic Policy continuously cycled through the various domains in the CRM/Billing system, looking for locked accounts and verifying the duration that the account had been locked. The Autonomic Policy automatically reset accounts that had been locked for five minutes or more. Furthermore, the Autonomic Policy was built to compare daily account resets with a predefined baseline and alert the production support staff only if the issue was trending significantly from the baseline. The result with this self-correcting approach was that the problem of inappropriately locked accounts completely disappeared. No more service tickets on this issue, no more call center staff initiating tickets on this issue, no more production support staff spending time resetting accounts, and no more time wasted by customers and field techs who were inappropriately locked out of their accounts.
Results: