Abstract: A method for enhancing telecom support service across one or more functions for a plurality of services is disclosed. The method includes identifying one or more stages of an operational business process for each of the function. The process of identifying one or more operation business process may be helpful for addressing a plurality of issues of customer. 1 he method further includes deriving at least one unified process for each of the identified stages of the operational business process by linking a plurality of stages of the unified process for enhancing the telecom support service. The method of enhancing the customer support in the telecom support service across one or more functions may further include a predictive process.
TECHNICAL FIELD
The present invention relates to a customer support, and more particularly, to a method of optimizing the process of the customer support across one or more functions in an integrated support platform having a plurality of services.
BACKGROUND
In a typical business scenario, improving customer experience is now a broad level agenda. Few of the business scenarios may range from providing non technical customer support to a high end technical support. One of the business scenarios involving high end technical support may include a telecommvinication domain support provided by a communication service provider (CSP).
Generally, one or more key functions for improving customer experience may include, service fulfillment, service assurance and customer support in terms of billing enquiries and profile changes etc. On these steps of providing improved customer support in the telecommunication domain, an operational model employed by the CSP may play a key part in managing end customer experience. The operational model of the current customer support process employees a customer support representative (CSR) to capture/ gather the problem reported by the customer, and to do basic structured questioning and preliminary diagnosis. The trouble ticket is raised by the CSR and it gets passed to a second line support team, who has knowledge and access to detailed diagnostics tools. In a significant number of cases the trouble ticket gets passed to the third level, which has highly skilled resources. In this process, there is a lot of back and fourth interaction between various teams. Also, in a network support process, an alarm generated from a network is picked up by the network management tools and presented to a network team. The network support may result in creation of the trouble ticket. The rest of the process in the network support may be similar to the customer support, till the issue gets resolved. Similarly the customer support function
tends to have multiple input chaimels depending upon the product and the type of function requested by the customer. So there may be multiple teams handling just the customer contact for service fulfillment, assurance and billing, further segmented based on products.
The current operational model may not be sufficient to manage new services and may result in inflated costs and an ordinary customer experience. Also, the processes defined by the operational model are marred by typical characteristics of sudden and fast growth of telecom services or products. The current operational model may be sufficient for traditional services, which may not be adequate to manage customer support for a converged service(s). The converged services may require customer support handling complexities arising out of inter working among diverse networks, applications and multiple access domains or products. As a result, many of the current CSRs have become messengers of faults, adding imwanted delay to the resolution cycle time and increase in operations cost.
Accordingly, these above mentioned problems may be bucketed in two major categories one being a product or function silo-based organizations' customer support leading to multiple process threads, which liniits the uniform customer support experience and also cross-selling or bimdling of offers for customers. The second problem being a customer support process is highly reactive. The CSR handling the customer support operation have little visibility into service/network related issues thereby rendering them handicapped in resolving customer queries/issues. In addition the existing processes may not be efficient enough to cater the usage and management of the common knowledge base, which is essential to improve the overall customer services support function.
Thus, there is a need for a method for enhancing the customer support across one or more functions in an integrated support platform having plurality of services.
SUMMARY OF THE INVENTION
A comprehensive approach for enhancing customer support. The approach detail out a method for optimizing the process of the customer support across one or more functions in an integrated support platform having a plurality of services
In one embodiment of the present invention, a method for enhancing telecom support service across one or more functions for a plurality of services is disclosed. The method includes identifying one or more stages of an operational business process for each of the function. The process of identifying one or more operation business process may be helpful for addressing a plurality of issues of customer. The method further includes deriving at least one unified process for each of the identified stages of the operational business process by linking a plurality of stages of the unified process for enhancing the telecom support service.
In one embodiment of the present invention, the telecom support service may include at least one of a customer support platform or a network support platform or combinations thereof Further, the functions may include at least one of a service fulfillment or a service assurance or combinations thereof The plurality of services may include at least one of a public switched telephone network (PSTN) service or an integrated services digital network (ISDN) service or a broadband service or an internet protocol (IP) TV service or a voice over IP (VoIP) service or a wireless service or a cable service or an internet protocol (IP) multimedia Subsystem (IMS) or combinations thereof
In another embodiment of the present technique, the method of enhancing the customer support in the telecom support service across one or more functions may further include a predictive process. The predictive process may include at least one of an analyzing data stage or a root cause analysis stage or both.
In yet another embodiment of the present technique, the telecom support service may further include at least one customer service representative (CSR) utilizing a knowledge model for resolving one or more problems reported by the customer or from the network.
BRIEF DESCRIPTION OF THE DRAWINGS
The above mentioned features as well other features, aspects, and advantages of the present invention will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:
FIG. 1 is a flow diagram of a method illustrating a common customer contact stage for handling the customer support operation, according to one embodiment of the present technique;
FIG. lA is a flow diagram of an operational business process illustrating a number of stages of a service assurance function, according to one embodiment of the present technique;
FIG. IB is a flow diagram of an operational business process illustrating a number of stages of a service fulfillment function, according to one embodiment of the present technique;
FIG. 2 is a flow diagram of a method illustrating a problem reported stage of the service assurance service function for handling the problem reported from the common customer contact stage, according to one embodiment of the present technique;
FIG. 3 is a flow diagram of a method illustrating a localize & diagnose stage of the service assurance service function for localizing and diagnosing the problem reported from the problem reported stage, according to one embodiment of the present technique;
FIG. 4 is a flow diagram of a method illustrating an allocate fault stage of the service assurance service function for allocating identified fault to find resolution, according to one embodiment of the present technique;
FIG. 5 is a flow diagram of a method illustrating a fix & test stage of the service assurance service function for fixing the problem reported, according to one embodiment of the present technique;
FIG. 6 is a flow diagram of a method illustrating a service test stage of the service assurance service function for conducting test as per the suggestion from the fix & test stage in resolution the problem, according to one embodiment of the present technique;
FIG. 7 is a flow diagram of method illustrating an inform customer stage of the service assurance service function for informing the customer about problem resolution and upgrading the knowledge stage with the resolution related to the problem, according to one embodiment of the present technique;
FIG. 8 is a flow diagram of a method illustrating the plurality of unified process of the service assurance function for enhancing customer support in the telecom support service, according to one embodiment of the present technique;
FIG. 9 is a flow diagram of a predictive process illustrating a number of stages of the predictive process for enhancing the customer support service, according to one embodiment of the present technique;
FIG. 10 is a flow diagram of a method illustrating an analyze data stage of the predictive process for analyzing the data, according to one embodiment of the present technique;
FIG. 11 is a flow diagram of a method illustrating a root cause analysis stage of the predictive process illustrating for analyzing the root cause of the problem reported from the analyze data stage, according to one embodiment of the present technique;
FIG. 12 is a flow diagram of a method illustrating a proactive action stage of the predictive process for taking proactive action in resolving the problem identified from the root cause analysis stage, according to one embodiment of the present technique;
FIG. 13 is a flow diagram of a method illustrating a closure stage of the predictive process deciphering the necessary unified process to fix and close the predicted problem, according to one embodiment of the present technique;
FIG. 14 is a flow diagram of a method illustrating the plurality of unified process of the predictive process for identifying and proactively fixing problems related to the telecom support service, according to one embodiment of the present technique; and
FIG. 15 is a system illustrating a generalized computer network arrangement, in one embodiment of the present technique.
DETAILED DESCRIPTION
The following description is full and informative description of the best method and system presently contemplated for carrying out the present invention, which is known to the inventors at the time of filing the patent application. Of course, many modifications and adaptations will be apparent to those skilled in the relevant arts in view of the following description m view of the accompanying drawings and the appended claims. While the system and method described herein are provided with a certain degree of specificity, the present technique may be implemented with either greater or lesser specificity, depending on the needs of the user. Further, some of the features of the present technique may be used to advantage without the corresponding use of other features described in the following paragraphs. As such, the present description should be considered as merely illustrative of the principles of the present technique and not in limitation thereof, since the present technique is defined solely by the claims.
The present invention relates to a method of enhancing a customer support, and more particularly, to a method of optimizing the process of the customer support across one or more functions in an integrated support platform having a plurality of services. Also, the method further includes a predictive process in addition to a reactive and proactive process to improve predictability in customer support operations. In particular, the predictive process may be able used to predict the number of faults or leam from the historical data / mistakes or for a continuously improve customer support operations or combinations thereof
The following description is presented to enable a person of ordinary skill in the art to make and use the invention and is provided in the context of the requirement for obtaining a patent. The description is the presently best contemplated method for carrying out the present invention. Various modifications to the preferred embodiment will be readily apparent to those skilled in the art and the generic principles of the present invention may be applied to other embodiments, and some features of the present invention may be used without the corresponding use of other features. Accordingly, the present invention is not intended to be limited to the embodiment shown but is to be accorded the widest cope consistent v^th the principles and features described herein.
Referring to the figures, Fig. 1 is a flow diagram of a method illustrating a common customer contact stage 110 for handling the customer support operation. In one embodiment of the present technique, the common customer contact stage 110 detail the unified process (herein also referred as "unified step" or "step") employed in customer support operation to handle the customer. The common customer contact stage 110 may comprise one of a contact group (not shown in figure for clarity purpose) including one or more modes of communication of the plurality of customers. The contact group may include at least one of a portal/ business to business (herein also referred as "B2B") mode 120 or a phone module mode or a fax mode 130 or an e-mail/ SMS mode 135 or an instant messenger (herein also referred as "IM") mode 140 or combinations thereof. Any mode of communication mentioned in the group module may be used customer by the customer to reach the customer service representative (herein referred as "CSR"), to report the problem. The common customer contact stage 110 may further include at least one of a establish contact type step (block 145) or establish customer step (block 150) or a retrieve customer profile step (block 155) or identify and validate step (block 160). The establish contact type step 145 may include building communication with the customer to handle the customer problem. The CSR may open the customer interaction and identify and validate the customer as shown in step 160. In case, if the customer is new, the CSR will establish the customer as shown in step 150 and record the problem. For each new customer the CSR may check the customers' eligibility and may create new account and also create new customer profile. While in case, if it is an existing customer, the customer profile will be retrieved as shown in step 155. For every existing customer, the user and product profiles may be retrieved to see, what product or service the customer is using. The customer contact reason may be evaluated
and accordingly the respective common contact may be routed to one or more functions of the telecom support service for further action. In one embodiment of the present technique, the common customer contact 110 may be routed to handle a service assurance function 170 of the telecom support service. Wherein in other embodiment of the present invention, the common customer contact 110 may be routed to a service fulfillment 180 or a support customer function 190 or both.
In one embodiment of the present invention, the enhancement of the telecom support service across one or functions, to be detailed in subsequent paragraphs, are built over an enhanced telecom operations map (herein referred as "eTOM") level 2 or level 3 process, as detailed in TM forum portal. The eTOM is the ongoing TM forum initiative to deliver a business process stage or framework for use by service providers and others within the telecommunications and related sectors of industry. The TM Forum eTOM describes all the enterprise processes required by a service provider and analyzes them to different levels of detail according to their significance and priority for the business. For such companies, it serves as the blueprint for process direction and provides a neutral reference point for internal process reengineering needs, partnerships, alliances, and general working agreements with other providers.
Referring to the figures, Fig lA is a flow diagram of an operational business process illustrating a number of stages of a service assurance function 170. According to one embodiment of the present technique, the service assurance function 170 may be used resolve the customer problem using one or modules of the service assurance function. The service assurance function 170 may include at least one of a problem reported stage 210 or localize & diagnose stage 310 or a allocate fault stage 410 or a fix & test stage 510 or a service test stage 610 or a inform customer stage 710 or combinations thereof. The service assurance stage 170 may also include the common customer contact stage 110.
Referring to the figure, IB is a flow diagram of an operational business process illustrating a number of stages of a service fulfillment function 180. According to one embodiment of the present technique, the service fulfillment function 180 may be used deliver a service / product to the customer using one or more modules of the service fulfillment function. The service fulfillment function may include at least one of an order
management stage 2100 or a allocate network resource stage 3100 or a build transmission path stage 4100 or a deliver access or deliver CPE stage 5100 or a service configuration stage 6100 or test & turn up service stage 7100 or combinations thereof. The service fulfillment stage 180 may also include the common customer contact stage 110.
In one embodiment of the present invention, the order management stage 2100 of the service fulfillment function 180 is for capturing, validating and management of the customer order. The allocate network resource stage 3100 is for identification and allocation of the network / service resources required for the service. The build / design service 4100 is for implementing the solution identified for the customer on the network and other service related elements including any physical work like cabling etc. The deliver access or deliver CPE stage 5100 deals with providing the last mile connectivity to the customer premises and installing the customer premises equipment. The service configuration stage 6100 is for configuration and activation of the service. The test & turn up service stage 7100 is for performing an end to end test for the service before handing it over to the customer. The inform customer process stage 8100 deals with communication to the customer about the status of the order and confirming that the service has now been provisioned and ready to use.
The support customer function 190 (referring to figure 1) of the telecom support service is for dealing with the generic enquiries from the customer about their service, faults or billing. It may also include dealing with the change of tariff plans and updating of customer related information like contact numbers etc.
Referring to the figures, Fig. 2 is a flow diagram of a method illustrating a problem reported stage 210 of the service assurance service function 170 for handling the problem, which is reported from the common customer contact stage. In one embodiment of the present technique, the problem reported stage 210 may comprise several steps including at least one of a validate service details step (block 220) or a gather problem information step (block 225) or a check service status step (block 230) or a check active orders fault history step (block 235) or conduct initial checks step (block 240) or a pre-classification step (block 245) or a record fault on TT system step (block 250) or a raise TT step (block 255) or combinations thereof The problem reported stage 210 may also include a scenario based knowledge base and information model (block 260) for updating the problem information and
for retrieving the existing solution or approach used to resolve the problem reported from the customer.
In one embodiment of the present technique, the CSR may gather problem information from the customer and conduct a fault pre-classification based on the guidance from the scenario based knowledge base. If a fault is found, it may be recorded in the trouble ticketing systems and then diagnosed and localized. Otherwise it is sent back to the customer for acceptance.
In one embodiment of the present invention, a plurality of business rule may be used to customize the plurality of steps of the problem reported stage 210 as well one or more subsequent step of the other model to follow, to make the service or product specific to the customer usage for resolution. The plurality of business rules and the usage of business rules are detailed in subsequent step to follow.
In validate service details step 220, the service details of the customer is validated to derive information about the authenticity of the product or service the customer is using. In gather problem information step 225, the CSR may gather the product or the service information from a product or service inventory (not shown in figure for clarity purpose) and details of a service level agreement (herein referred as "SLA") happened between the service provider and the customer. This information may be helpful for the CSR to assign weight-age to the customer problem as well check the service or the product information, which the customer is using. In check service status (block 230), the CSR checks the whether the service the customer is operative or in operative, subsequent to which the CSR may check the details of historic alarms (block 235) to determine the similar problem and possible impacts of the problem. In conduct initial checks (block 240) the CSR may use the gathered problem information and later may provide a report to the customer with the most probable cause of the problem. The CSR may check the probable causes of the problem from scenario based knowledge base (block 260) and based on the probable causes, guide the customer by structured questions. On identifying the problem the customer is facing the possible troubleshoot instructions are recorded in the scenario based knowledge base (block 260) may be used. If the trouble shoot information is not available, the CSR may record the fault on the trouble ticket (herein referred as "TT") system (block 250) and then raise the TT (block 255)
for localizing and diagnosing the fault 310. In another embodiment of the present invention, if the fault is found to be associated with an existing major fault, then the CSR may create a child fault to the major fault and associate the child fault with the customer contact report. Otherwise the CSR may directly associate the fault to the customer contact report. After, which the CSR may analyze the impact, assign the priority to the fauh and accordingly raise the fauh on the TT system (block 255) for localizing and diagnosing the fault 310.
In one embodiment of the present technique, the scenario based knowledge base (block 260) may be used by the CSR to identity the most probable cause of the fault or to analyze and identify resolution of the problem or ask structured questions to the customer and trouble shoot the fault accordingly or combinations thereof. The scenario based knowledge base (block 260) may be updated with latest scenarios as well.
Referring to the figures, Fig. 3 is a flow diagram of a method illustrating localize & diagnose stage 310 of the service assurance service function 170 for localizing and diagnosing the problem reported from the problem reported stage. In one embodiment of the present technique, the localize and diagnosing stage 310 may comprise several steps including at least one of a initial diagnostics step (block 320) or a analyse with customer step (block 325) or a trace service step (block 330) or an assign severity & determine SLA step (block 335) or an associate step (block 340) or a analyze dependencies step (block 345) or a perform further diagnostics (if required) step (block 350) or a localize fault step (block 355) or a run diagnostics tree step (block 360) or a no-fault closure rejection step (block 365) or a identify the problem step (block 370) or combinations thereof. The outcome of localize and diagnose stage 310 may lead either to an allocate fault stage 410 or inform customer stage 710 or combinations thereof.
In one embodiment of the present technique, once the problem details have been recorded into the systems, the root cause of the problem may be diagnosed and localized by conducting various tests. A technical support team and suppliers may also be involved in the tests during this task.
In initial diagnostics step 320, the CSR may do some initial diagnosis to prioritize tests and recommend based on a fault codes. The suppliers may also be involved, if required.
to conduct the tests. Later, the CSR may consolidate the results for evaluation. In analyze with customer step 325, the customer may be involved for analysis of the test recommended based on the fault codes assigned either by the suppliers or the technical support team. In trace service step 330, the services are traced either involving the technical team or the supplier to identify the fault. Suppliers may also be involved to conduct tests on there equipments if required to trace fault in the service. The assign severity and determine SLA (block 335) is for assessing and assigning the severity of the problem to the customer and determining the SLA expected by the customer based on the service and the contract. The associate step (block 340) deals with correlating all similar faults of the same / other customers which have the same root cause. The analyze dependencies step (block 345) may involve the technical support team to evaluate the test results and conduct a detailed diagnosis to locate the root cause of the problem. The technical team may be involved only for complex problems, which may not be resolved by the CSR alone. In step 350, the technical team may also conduct additional tests for finding root cause of the fault. Based on the information of the technical team and the supplier, the fault may be localized as shown in step 355. Thus the root cause identified may provide the CSR the possible resolution steps to resolve the fault. The CSR may later consolidate the tasks to be performed and resource requirement for performing the task of resolution.
In one embodiment of the present technique, once the root cause of the problem is diagnosed, the appropriate resolution artifact may be searched in the scenario based knowledge base and the possible resolution plan may be prepared for fixing the problem. The CSR may later run the diagnostics tree (block 360) to resolve the problem. During the analysis, if no fault is found, the CSR may inform the customer 710 and may send a closure request as shown in step 365.
Referring to the figures. Fig. 4 is a fiow diagram of a method illustrating an allocate fault stage 410 of the service assurance service function 170 for allocating identified fault to find resolution. In one embodiment of the present technique, the allocate fault stage 410 may comprise several steps including at least one of an assign to work queue step (block 420) or a content provider step (block 425) or an assign to network step (block 430) or an assign to CPE step (block 435) or an assign to access step (block 440) or a service technical team (block 445) or an application team (block 450) or combinations thereof.
In one embodiment of the present technique, the allocate fault stage 410 may be used to find the resolution, post finding the root cause of the problem. The CSR may prepare a task list and a sequence for resolving the fault. The CSR may assign the fault to one or more team to find the possible resolution. The task of resolving the customer problem may be either assigned to a content provider team (block 425) or to network team (block 430) or to the CPE (block 435) or the accessing team (block 440) or to the services technical team (block 445) or to the application team (block 450). Post obtaining the resolution of the fault from one or more assigned team, the TT is forwarded by the CSR to the fix the fault and test the results, for further actions.
Referring to the figures. Fig. 5 is a flow diagram of a method illustrating a fix & test stage of the service assurance service function 170 for fixing the problem reported. In one embodiment of the present technique, the fix & test stage 510 may comprise several steps including at least one of a plan restoration action step (block 520) or a allocate work schedule step (block 530) or confirm with customer step (block 525) or implement network restoration step (block 535) or an implement CPE implementation step (block 540) or an implement access restoration step (block 545) or an implement services restoration step (block 550) or an implement application restoration step (block 555) or combinations thereof The fix & test stage may further include a return fault clear report step (block 560), test and confirm fix step (block 565). The outcome of fix & test stage 510 may lead to a service test stage 610.
In one embodiment of the present technique, the fix and test stage 510 may use the resolution steps used by the appropriate team to fix the problem. Later, the CSR may even check the resource availability and then initiate the restoration work. The problem is fixed and tested until the problem is resolved. Upon resolution, the resolution is sent to the customer for acceptance.
In step 520, based on the resolution plan, the CSR may finalize one or more restoration task and allocate the resource accordingly. The concerned operational team for restoration may be evaluated and allocated the work. The customer is informed about the restoration action and other necessary information about the restoration and the consent may be sought from the customer to go ahead with the step restoration task, as shown in step 525. Post permission of the customer, the task of restoration is executed by allocating the work
schedule, as shown in step 530 to one or more implementation team. The implementation team may include at least one of a network restoration team (block 535) or a CPE restoration team (block 540) or an access restoration team (block 545) or a services restoration team (block 550) or a application restoration team (block 555) or implement the restoration step as identified in the allocate fault stage (410). On successfully implementing the restoration step to fix the fault, the report raised for the TT is cleared (block 560) and CSR will be informed for conducting the test and confirming (block 565) the clearance of problem, which the customer has faced and reported earlier. In one embodiment of the present technique, in step 565, the CST may use one pr more IT tools to check the implementation efficacy.
Referring to the figures. Fig. 6 is a flow diagram of a method illustrating a service test stage 610 of the service assurance service function 170 for conducting test as per the suggestion fi-om the fix & test stage in resolution the problem. In one embodiment of the present technique, the service test stage 610 may comprise several steps including at least one of a perform end to end service test step (block 620) or a restoration confirmation step (block 625) or update status ticket (block 630) or combinations thereof The outcome of service test stage 610 may lead to an inform customer stage 710.
In one embodiment of the present technique, the service test stage 610 may use involve the CSR conducting the detailed test to find the quality of restoration of fault. The test the CSR performs may include a detailed end to end service test at the service line, as shown in step 620, to check the restoration taken by the implementation team. The CSR may later inform the team about the restoration test and confirm, as shown in step 625, the quality or success of the restoration in fixing the problem, the customer has reported. Later, the CSR may update the status ticket related to the fault, as shown in step 635.
Referring to the figures. Fig. 7 is a flow diagram of method illustrating an inform customer stage 710 of the service assurance service function 170 for informing the customer about problem resolution and upgrading the scenario based knowledge base 260 (refer figure 2) with the resolution related to the problem. In one embodiment of the present technique, the service test stage 710 may comprise several steps including at least one of a confirm resolution with the customer step (block 720) or update the scenario based knowledge base (block 725) or close the trouble ticket step (block 730) or combinations thereof
In one embodiment of the present technique, the inform customer stage 710 may inform the customer about resolution of the problem and confirm with the customer the same, as shown in step 720. Post restoration the entire scenario may be updated in the scenario based knowledge 260 (refer figure 2) as shown in step 725, which may be helpful in future for the CSR to handle and resolve, similar problem, which the customer may face. The trouble ticket raised early for the problem is closed, as shown in step 730, by the CSR to end the customer support operation.
In one embodiment of the present invention, a plurality of primary business rule may be used to customize the unified process or step of one or more stages of each function. The primary business rules may include at least one of a condition or an action or an exception or a data or combinations thereof, as indicated in table 1.
The conditions of the primary business rule may include at least of a customer's service type or a customer situation or a service situation or a test results or combinations thereof The conditions rule may be used to determine the customer service or product. The customer situation may be used to determine the geography of the customer and the service situation may be used to check the situation of the service at that location. The customer situation may also provide information about the reason why the customer is contacting the customer support and etc. The condition rule may also provide with certain test results, which may be used to resolve the customer issue.
The actions rule of the primary business rule may include determining at least one of a product post identifying the condition based on the primary business rule. The
actions rule may also comprise the list of all test result, which the CSR may evaluate to resolve the customer problem.
The exception rule of the primary business rule may include deriving information of the evaluated test result including at least one of a non fault status or a test non running status or combinations thereof
The data rule of the primary business rule may include receiving inputs from the customer and determining the customer contact reason or checking the inventory data or combinations thereof.
In another embodiment of the present technique, the unified process for the respective services may be further customized as per the requirement of a plurality of products using one or more secondary business rules. The secondary business rules may include determining at least one of a product post identifying the condition based on the primary business rule.
In one embodiment of the present technique, the plurality of services may include at least one of a PSTN service or ISDN service or a broadband service or an internet protocol (IP) TV service or a voice over IP (VoIP) service or a wireless service or a cable service or an internet protocol (IP) multimedia Subsystem (IMS) or combinations thereof
In another embodiment of the present technique, one or more unified process may be identified that are common among one or more functions of the telecom support service for enhancing the support service process.
In one embodiment of the present technique, the telecom support services include at least one of a customer support platform or a network support platform or combinations thereof The customer support platform may include at least one of a trouble ticketing or a self care or a help desk or a customer relationship management (CRM) or combinations thereof, wherein the network support platform may include at least one of a network monitoring or an alarm collection and correlation or a network trouble reporting or a network performance monitoring or combinations thereof The present technique, is detailed taking the common customer support platform. However, it will be apparent to one skilled in the art that the network support may also be employed for enhancing the telecom support service.
The techniques detailed for the common network support operation may also be implacable for network support service with or without any significant modifications. The description should not be restrictive from the scope of the present invention.
Referring to the figures, Fig. 8 is a fiow diagram of a method illustrating the plurality of unified process of the service assurance function for enhancing customer support in the telecom support service. The fiow diagram may illustrate the method of enhancing the customer support service operation.
The method comprising: 1) common customer contact to access across various function of telecom domain (block 810), 2) establish customer connection, retrieve customer profile, identify and validate the customer (block 820), 3) determine the functional area the customer is seeking information (block 830), 4) identifying one or more stages of an operational business process for the identified function (block 840), 5) derive at least one unified process for each of the identified operational business stages (block 850), and 6) link each of the derived stages of the unified process for enhancing the telecom support service (block 860). Each of the steps will be explained in greater extent in the subsequent sections as follows.
In step 810, the common customer contact stage may provide the necessary platform for the plurality of customers to reach the CSP. Also, the common customer contact stage may be establish the connection with the customer and establish the customer profile if the customer is new else retrieve the profile of the customer and validate the customer, as shown in step 820.
In step 830, the customer contact reason may be derived and the appropriate functional area of the telecom support services is looked in addressing the customer issue. The function may include at least one of a service assurance or a service fulfillment.
In step 840, one or more stages of the identified function may be used by the CSR to address one or more problem or issue the customer may be facing. In step 850, the CSR may derive at least one unified process or steps for each of the stages of the identified function. The step 850, for a service assurance function may include deriving at least one of more process for each of the problem reported stage, localize & diagnose stage, allocate fault stage, fix & test stage, service test stage, and, inform customer stage. The unified process
derived for each of the stages detailed above may be helpful in identifying the problem the customer is facing and the exact root cause of the problem. Following which, the fault in the service is identified, which might have caused the problem. The resolution team may be formed to resolve the fault, following which; the implementation team may be suggested to fix the fault based on the resolution identified by the resolution team. In step 850, one or more unified process of each stage is linked to generate a effective means to resolve the customer problem. Later, the service test may be performed to determine the accuracy and the efficiency of restoration of fault. Subsequently, the customer may be informed about the changes or resolution used to resolve the problem.
Referring to the figures. Fig. 9 is a flow diagram of a predictive process 900 illustrating a number of stages of the predictive process for enhancing the customer support service. According to one embodiment of the present technique, the predictive process 900 in addition to a reactive and proactive process may be used to improve predictability in customer support operations. In particular, the predictive process may be able used to predict the number of faults or leam from the historical data / mistakes or for a continuously improve customer support operations or combinations thereof
In one embodiment of the present technique, the predictive processes may be initiated through a trigger points including at least one of a customer service related issues or a service / network performance degradation issue or a network alarms threshold breach or a historical data analysis or a usage and effectiveness of knowledge base or combinations thereof.
In one embodiment of the present invention, the predictive process 900 may comprise at lease one of a analyze date stage (block 1010) or a root cause analysis stage (block 1110) or a proactive action stage (block 1210) or a closure stage (1310) or combinations thereof. Each of the stages will be explained in greater extent in the subsequent sections as follows.
The analyze data stage (block 1010) of the predictive process 900 may comprise identify key trends or black spot analysis step (block 1020), compare against the baseline step (block 1030). In step 1020 of the analyze data stage 1010, the service assurance data or the service fulfillment data or a service performance data are analyzed periodically, which
includes analysis of at least one of the historical data or faults or analysis of fault statistics or identifying problematic exchanges or recently closed orders or pattern identifications or a geographical data. As well, the business rules may be analyzed periodically to identify the key trends and sub sequentially conduct the black spot analysis to determine or forecast the types of problems which may occur in future. The compare against the baseline step (block 1030) may be used to compare the analysis result to determine or forecast the period or possibility of problem in the services.
The root cause analysis stage (block 1110) of the predictive process 900 may comprise determining key issue step (block 1120), a categorize step (block 1130). In step 1120, the plurality of key issue are identified among the analysis result obtained after the black spot analysis and the issues are categorized, as shown in step 1130, providing the priority or raking, to be resolved. The categorization step 1130 may also highlight the problem area, which includes at least one of a process area or a service issue or a network area or a systems area or a customer information education area. The categorization steps helps in narrovsdng the problem area to find resolution.
The proactive action stage (block 1210) of the predictive process 900 may comprise plan resolution assignment step (block 1220), assign step (block 1230), a resolution team (not shown in figure for clarity purpose). The resolution team may include assign to network step (block 1240), assign services team (block 1250), upgrade process/ stages step (block 1260), upgrade scenario based knowledge base step (block 1270), customer information step (block 1280). In step 1220, the plan CSR may prepare a task list and a sequence for resolving the fault. The CSR may assign the fault to one or more team to find the possible resolution. In step 1230, the task of finding the resolution is assigned to the resolution team. The resolution team may find the resolution to the key issue that was identified in the earlier stages. The derived resolution is upgraded in the scenario based knowledge base (block 1270) and the customer is informed, as shown in step 1280, in advance about the network or service changes to be taken to avoid the possible problem in future.
The closure stage (block 1310) of the predictive process 900 may comprise plan change (block 1320), roll out step (block 1330), inform and close step (block 1340). In step 1320, alternative action is devised to avoid the possible problem, the customer may face due
to the planned roll out, as shown in step 1330, of the resolution action to avoid the possible problem in future. Post rolling out the restoration action, the customer may be informed about roll out and any necessary steps the customer needs to undertake to avoid the conflict, which might have arise due to the roll out.
Referring to the figures, Fig. 14 is a flow diagram of a method illustrating the plurality of unified process of the predictive process for identifying and proactively fixing problems related to the telecom support service. The flow diagram may illustrate the method of identifying the fault trends and forecast the type of problems, which may occur in future. Also, the necessary action to be taken by technicians to resolve the problem.
The method comprising: 1) analyze the service fulfillment data or service performance data or historical data faults or geography or exchange wise data or information model (block 1410), 2) Identify key trends or black spot based on the analysis (block 1420), 3) compare the identified factor against the baseline (block 1430), 4) identify key issues after comparison and categorize the data (block 1440), 5) prepare resolution plan and assign the task to respective team (block 1450), plan change to rollout the changes/ necessary steps (block 1460), and 6) inform customer and close the task (block 1470). Each of the steps will be explained in greater extent in the subsequent sections as follows.
In step 1410, the data is analyzed to identify any possible failure, or major trend shift happening in the service. The data which may be analyzed includes at least one of a historical data or faults trends or geographical data or an exchange data or data from the information model or business rules. The analyze data step (block 1410), thus may be helpful in identify key trends and subject those key trends to find the possible faults for future, as shown in step 1420.
In step 1430, identified key trends may be compared against the baseline factors to find the exhaustive details of the key trends, to determine whether the key trends are really a possible fault of the future.
In step 1440, identified key trends/ issues are categorized and raked to provide the priority, to resolve the issue. Post identification of the key issue, the resolution plan is prepared by the CSR and assigned to the appropriate team, as shown in step 1450, to resolve
the issue. After finding the resolution, necessary action is taken to roll out the restoration action to avoid the possible fault of future, as shown in step 1460.
In step 1470, the customer is informed about the rollout of restoration action taken to avoid the possible fault in future. Subsequently, the customer may be informed about any necessary steps to undertake to avoid the conflict, which might have arisen due to the roll out.
In one embodiment of the present technique, the exemplary example illustrating the service assurance function detailed through figures 1 to 7 is explained with respect to the customer using a broadband service. The illustration detailed should not be restrictive in light of the novelty of the present invention.
Referring to the figure 1, in the common customer contact stage of the service assurance function, the customer calls up to reports a problem with his broadband service contact type phone is established. The CSR establishes the contact and customer following which the customer details like address etc are checked and validated to confirm he is a valid customer. Since, the contact reason of the customer is a problem in the service the CSR guides or takes the customer with a sequence of stages related to the service assurance function.
Referring to the figure 2, the problem reported by the customer is registered and the appropriate unified process of the each stages of the service assurance function is derived using the business rule. Since, the customer has contacted the customer support service for a broadband issue; the appropriate unified stages for each stages of the service assurance function are derived. The broadband service is validated against broadband business rules. The validation rules for broadband may include at least one of a circuit ID existence or a service features are active or service is not suspended or if it was PSTN, the telephone number is validated or if its IPTV the circuit ID and the throughput are validated or etc. The CSR may later ask the customer with structured set of questions, which reveals that the customer is not able to connect to the intemet. These questions are driven by the business rules for broadband. The broadband service state is later traced through the network and the performance status is checked. The parameters for the performance and service tracing may also be derived from business rules. The CSR may perform few initial checks to revoke the faults, which the customer might have faced. Post initial checks, the potential problems are
identified based on the pre-classification and the CSR may then raise a Trouble ticket capturing the problem details relevant to broadband.
Referring to the figure 3, in localize & diagnose stage, the CSR may use the scenario based knowledge base and information model to trace the broadband service of the customer. This may be helpful to see, whether the customer has earlier reported with same problem in resent time, and if yes, the resolution used to solve the issue. Later, the CSR checks the existing trouble tickets, if already a similar fault exists, which the present customer is facing. If so, the TT raised for the present customer is associated with the older TT and linked for providing the resolution. The CSR checks the scenario based knowledge base to pick one or more diagnostics tree depending upon the potential problem code and run the diagnostics. Post running the diagnostics, the CSR may be able to arrive at the fault, thus able to correlate the problem with the fault. Exemplary sake, the problem is identified based on the diagnostics and it's found that the customer session on the DSLAM needs to be killed/ ended.
Referring to the figure 4, in allocate fault stage; the CSR may assign the problem to a queue for fixing. The CSR prepares the resolution plan and checks the resource to handle the fault. Other important information derived by the business rules are also updated, which may include conditions - problem type and severity, action - assign to relevant queue, exception - escalate to managerial queue, data - problem code. The problem in the queue is later assigned to the appropriate team to find the resolution.
Referring to the figure 5, in fix & test stage, the resolution identified by the team for fixing the fault is validated and the restoration plan is prepared to implement the resolution to fix the fault. The problem is fixed and service restored, the fix specific to the broadband may also be derived from business rules i.e. one or more of the actual steps of the problem fix could also be part of the rules. The CSR informs the customer about the restoration plan and the cost and other factors needed/ incurred for restoration. Post approval of the customer the CSR may assign the appropriate implementation team to fix the fault.
Referring to the figure 6, in service test stage, the CSR may perform end-2-end service test and confirm restoration action. Referring to figure 7, the CSR may later update the trouble ticket and inform customer about the resolution. The CSR may also update the
scenario based knowledge base about the resolution. The trouble ticket is later closed. However, it will be apparent to one skilled in the art that the technique employed for resolving the customer problem may further be optimized using the business rules and other unified steps of each stage, the scope of the present technique should not be restrictive in light of the illustration detailed out.
In another embodiment of the present technique, the exemplary example illustrating the predictive process is detailed. The illustration is detailed through figures 10 to 13. The illustration detailed should not be restrictive in light of the novelty of the present invention.
In one embodiment of the present invention, the trigger point of the predictive process may be assumed for illustrating the example as a historical analysis.
Referring to figure 10, the historical trouble tickets analysis is performed, and the analysis of historical data of trouble ticket may show that the maximum number of faults is resulting from a specific region of the country i.e. southern region is accounting for more than 60% of the problems. Comparison of the faults is performed against the set base line i.e. typically based on the number of customers in this region the baseline was set between 30 to 35 %. Referring to figure 11, the roots cause analysis may be performed to assess why this happens. It may also be found that the key issues are linked to a specific type of exchange used in that region and thus the majority of the issues/ faults linked to the SIEMENS exchanges. After, identifying the issue, the faults determined are categorized. Referring to figure 12, the reason for the fault may be identified and faults are passed on to the technical team for fixing. The fix is performed by the technical team and the predictive team manages the rollout of the change, as shown in figure 13. The problem may be passed onto the network vendor and corrected. The predictive action avoids a lot of customer faults which would have been raised in this region.
In one embodiment of the present technique, the advantage of transforming the customer service support may include simplification of operations, reduction in operations cost, improved ability to handle converged services, improved customer experience and predictability in customer service operations.
In another embodiment of the present technique, the advantage of incorporating the predictive process with in the customer service support may include significant improvement in customer experience and customer service operations teams to plan for the operations.
While the present invention has been related in terms of the foregoing embodiments, those skilled in the art will recognize that the invention is not limited to the embodiments depicted. The present invention can be practiced with modification and alteration within the spirit and scope of the appended claims. Thus, the description is to be regarded as illustrative instead of restrictive on the present invention.
Exemplary Computing Environment
One or more of the above-described techniques can be implemented in or involve one or more computer systems. Figure 15 illustrates a generalized example of a computing environment 1500. The computing environment 1500 is not intended to suggest any limitation as to scope of use or functionality of described embodiments.
With reference to Figure 15, the computing environment 1500 includes at least one processing unit 1510 and memory 1520. In Figure 15, this most basic configuration 1530 is included within a dashed line. The processing unit 1510 executes computer-executable instructions and may be a real or a virtual processor. In a multi-processing system, multiple processing units execute computer-executable instructions to increase processing power. The memory 1520 may be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of the two. In some embodiments, the memory 1520 stores software 1580 implementing described techniques.
A computing environment may have additional features. For example, the computing environment 1500 includes storage 1540, one or more input devices 1550, one or more output devices 1560, and one or more communication connections 1570. An interconnection mechanism (not shown) such as a bus, controller, or network interconnects the components of the computing environment 1500. Typically, operating system software (not shown) provides an operating environment for other software executing in the computing environment 1500, and coordinates activities of the components of the computing environment 1500.
The storage 1540 may be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, CD-RWs, DVDs, or any other medium which can be used to store information and which can be accessed within the computing environment 1500. In some embodiments, the storage 1540 stores instructions for the software 1580.
The input device(s) 1550 may be a touch input device such as a keyboard, mouse, pen, trackball, touch screen, or game controller, a voice input device, a scanning device, a digital camera, or another device that provides input to the computing environment 1500. The output device(s) 1560 may be a display, printer, speaker, or another device that provides output from the computing environment 1500,
The communication connection(s) 1570 enable communication over a communication medium to another computing entity. The communication medium conveys information such as computer-executable instructions, audio or video information, or other data in a modulated data signal. A modulated data signal is a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communications media include wired or wireless techniques implemented with an electrical, optical, RF, infrared, acoustic, or other carrier.
Implementations can be described in the general context of computer-readable media. Computer-readable media are any available media that can be accessed within a computing environment. By way of example, and not limitation, within the computing environment 1500, computer-readable media include memory 1520, storage 1540, communication media, and combinations of any of the above.
Having described and illustrated the principles of our invention with reference to described embodiments, it will be recognized that the described embodiments can be modified in arrangement and detail without departing from such principles. It should be understood that the programs, processes, or methods described herein are not related or limited to any particular type of computing environment, unless indicated otherwise. Various types of general purpose or specialized computing environments may be used with or perform operations in accordance with the teachings described herein. Elements of the described embodiments shown in software may be implemented in hardware and vice versa.
In view of the many possible embodiments to which the principles of our invention may be applied, we claim as our invention all such embodiments as may come within the scope and spirit of the following claims and equivalents thereto.
We Claim:
1. A method of enhancing telecom support service across one or more functions for a plurality of services, the method comprising:
identifying one or more stages of an operational business process for each of the function in the telecom support service for determining at least one operational business process useful for addressing a plurality of issues of customer; and
deriving at least one unified process or step for each of the identified stages of the operational business process by linking a plurality of stages of the unified process for enhancing the telecom support service.
2. The method of claim 1, wherein one or more functions includes at least one of a service fulfillment or a service assurance or combinations thereof.
3. The method of claim 1, wherein operational business process for the service assurance function includes at least one of a common customer contact stage or a problem reported stage or localize and diagnose stage or an allocate fault stage or a fix and test stage or a service test stage or an inform customer stage or combinations thereof
4. The method of claim 1, wherein the operational business process for the service fulfillment function includes at least one of a common customer contact stage or an order management stage or allocate network or service resources stage or build transmission path stage or deliver access stage or deliver CPE stage or a service configuration stage or test and turn up service stage or inform customer stage or combinations thereof
5. The method of claim 1, wherein addressing the customer issue include delivering one or more new service to the customer through the unified stages of the operational business process for the service fulfillment function.
6, The method of claim 1, wherein addressing the customer issue include resolving customer problem using the unified stages of the operation business process for the service assurance function.
7. The method of claim 1, wherein the telecom support services include at least one of a customer support platform or a network support platform or combinations thereof
8. The method of claim 7, wherein the customer support platform includes at least one of a trouble ticketing or a self care or a help desk or a customer relationship management (CRM) or combinations thereof.
9. The method of claim 7, wherein the network support platform includes at least one of a network monitoring or an alarm collection and correlation or a network trouble reporting or a network performance monitoring or combinations thereof.
10. The method of claim 1, wherein the telecom support service across one or more functions further includes a predictive process, wherein the predictive process includes at least one of an analyze data stage or a root cause analysis stage or both.
11. The method of claim 10, wherein analyze data stage includes at least one of identify key trends or black spot analysis step or compare against the baseline step or both.
12. The method of claim 10, wherein root cause analysis includes determining a key issue from the analyzing data stage and categorizing the customer problem for providing a proactive action in resolving the customer problem.
13. The method of claim 1, wherein the unified process for each identified stage of the operational business process is customized as per the requirement of respective services using at least one or more primary business rules.
14. The method of claim 13, wherein the unified process for the respective services is further customized as per the requirement of a plurality of products using one or more secondary business rules.
15. The method of claim 13, wherein the primary business rules include at least one of a condition or an action or an exception or a data or combinations thereof
16. The method of claim 14, wherein the secondary business rules include determining at least one of a product, post identifying the condition based on the primary business rule.
17. The method of claim 15, wherein the condition include determining at least of a customers service type or a customer situation or a service situation or a test results or combinations thereof
18. The method of claim 15, wherein the action include identifying at least one test result and evaluating the identified test result, based on the determined condition of the customer.
19. The method of claim 15, wherein the exception include deriving information of the evaluated test result including at least one of a non fault status or a test non running status or combinations thereof
20. The method of claim 15, wherein the data include at least receiving inputs from the customer and determining the customer contact reason or checking the inventory data or combinations thereof
21. The method of claim 1, wherein the plurality of services includes at least one of a public switched telephone network (PSTN) service or an integrated services digital network (ISDN) service or a broadband service or an internet protocol (IP) TV service or a voice over IP (VoIP) service or a wireless service or a cable service or an internet protocol (IP) multimedia Subsystem (IMS) or combinations thereof
22. The method of claim 1, wherein one or more unified process is identified that are common among one or more functions of the telecom support service for enhancing the support service process.
23. The method of claim 1, wherein the telecom support service further includes at least one customer service representative (CSR) utilizing a scenario based knowledge model for resolving one or more problems reported by the customer or from the network.
24. A computer program product comprising a computer usable medium having a
computer readable program code embodied therein for enhancing telecom support service
across one or more functions for a plurality of services, the method comprising:
program code adapted for identifying one or more stages of an operational business process for each of the function in the telecom support service for determining at least one operational business process useful for addressing a plurality of issues of customer; and
program code adapted for deriving at least one unified process for each of the identified stages of the operational business process by linking a plurality of stages of the unified process for enhancing the telecom support service.
25. The product of claim 24, wherein the telecom support service across one or
more functions further includes the program code adapted for a predictive process, wherein
the predictive process includes at least one of an analyzing data stage or a root cause analysis
stage or both.
| # | Name | Date |
|---|---|---|
| 1 | 384-CHE-2008 FORM-18 06-10-2009.pdf | 2009-10-06 |
| 1 | 384-CHE-2008-Form-13-030615.pdf | 2016-11-15 |
| 2 | 384-CHE-2008_EXAMREPORT.pdf | 2016-07-02 |
| 2 | 384-CHE-2008 FORM-13 28-10-2009.pdf | 2009-10-28 |
| 3 | 384-che-2008-form 5.pdf | 2011-09-02 |
| 3 | 384-CHE-2008 AMENDED PAGES OF SPECIFICATION 03-06-2015.pdf | 2015-06-03 |
| 4 | 384-che-2008-form 3.pdf | 2011-09-02 |
| 4 | 384-CHE-2008 CORRESPONDENCE OTHERS 03-06-2015.pdf | 2015-06-03 |
| 5 | 384-che-2008-form 1.pdf | 2011-09-02 |
| 5 | 384-CHE-2008 FORM-1 03-06-2015.pdf | 2015-06-03 |
| 6 | 384-che-2008-drawings.pdf | 2011-09-02 |
| 6 | 384-CHE-2008 FORM-13 03-06-2015.pdf | 2015-06-03 |
| 7 | 384-che-2008-description(complete).pdf | 2011-09-02 |
| 7 | 384-che-2008-abstract.pdf | 2011-09-02 |
| 8 | 384-che-2008-correspondnece-others.pdf | 2011-09-02 |
| 8 | 384-che-2008-claims.pdf | 2011-09-02 |
| 9 | 384-che-2008-correspondnece-others.pdf | 2011-09-02 |
| 9 | 384-che-2008-claims.pdf | 2011-09-02 |
| 10 | 384-che-2008-abstract.pdf | 2011-09-02 |
| 10 | 384-che-2008-description(complete).pdf | 2011-09-02 |
| 11 | 384-che-2008-drawings.pdf | 2011-09-02 |
| 11 | 384-CHE-2008 FORM-13 03-06-2015.pdf | 2015-06-03 |
| 12 | 384-che-2008-form 1.pdf | 2011-09-02 |
| 12 | 384-CHE-2008 FORM-1 03-06-2015.pdf | 2015-06-03 |
| 13 | 384-che-2008-form 3.pdf | 2011-09-02 |
| 13 | 384-CHE-2008 CORRESPONDENCE OTHERS 03-06-2015.pdf | 2015-06-03 |
| 14 | 384-che-2008-form 5.pdf | 2011-09-02 |
| 14 | 384-CHE-2008 AMENDED PAGES OF SPECIFICATION 03-06-2015.pdf | 2015-06-03 |
| 15 | 384-CHE-2008_EXAMREPORT.pdf | 2016-07-02 |
| 15 | 384-CHE-2008 FORM-13 28-10-2009.pdf | 2009-10-28 |
| 16 | 384-CHE-2008-Form-13-030615.pdf | 2016-11-15 |
| 16 | 384-CHE-2008 FORM-18 06-10-2009.pdf | 2009-10-06 |