DESC:TECHNICAL FIELD
[0001]
The embodiments of the present disclosure generally relate to the field of communication networks and systems. More particularly, the present disclosure relates to a system and a method for managing mean holding time for a user device 5 to process service requests.
BACKGROUND OF THE INVENTION
[0002]
The subject matter disclosed in the background section should not be 10 assumed or construed to be prior art merely due to its mention in the background section. Similarly, any problem statement mentioned in the background section or its association with the subject matter of the background section should not be assumed or construed to have been previously recognized in the prior art.
15
[0003]
In recent years, with development and expansion of service-based industries, issues or complaints raised by customers for a specific service needs immediate attention and minimal redressal time to enhance service efficiency and prompt resolution of service requests. To resolve a service request, a customer care representative or care agent needs to perform a plurality of steps which require 20 extensive manual interventions required during customer interactions.
[0004]
Heretofore, traditional customer care centers suffered from several challenges while processing the service requests. A major challenge while processing the service requests is prolonged call holding time particularly while 25 collecting and collating details manually during the customer interactions such as customer location, other information and details pertaining to the issues faced by the customer. Further, the customer care representative fills out a complaint form
3
based on information from the collected details manually, which again adds to call
holding time and operational costs thereto.
[0005]
Moreover, manual entry of information of a customer such as personal details and complaint specific details increases the chances of errors and 5 inaccuracies leading to potential delays and customer dissatisfaction. A cumulative effect of prolonged call holding time may extend beyond immediate operational inefficiencies impacting overall quality of service and loyalty of the customer.
[0006]
Therefore, to overcome the aforementioned challenges and limitations 10 associated with the conventional methods, there lies a need for a system and a method for minimizing a call mean holding time to enhance the user experience.
SUMMARY
15
[0007]
The following embodiments present a simplified summary in order to provide a basic understanding of some aspects of the disclosed invention. This summary is not an extensive overview, and it is not intended to identify key/critical elements or to delineate the scope thereof. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is 20 presented later.
[0008]
According to an embodiment, a method for managing mean holding time for a user device in a communication network is disclosed. The method includes receiving, by a data exchange engine from the user device, an Application 25 Programming Interface (API) request to report an anomaly associated with the user device. The API request comprises information of a geographical location corresponding to the user device. The method further includes retrieving, by an
4
event detection engine from a database, parametric data associated with the
geographical location. Furthermore, the method includes determining, by the event detection engine based on the parametric data, at least one communication error event corresponding to the geographical location. Furthermore, the method includes generating, by a ticket generation engine, a service request ticket for the 5 user device based on the at least one communication error event.
[0009]
In some aspects of the present disclosure, the method further includes determining, by a smart code engine, a smart code associated with the at least one communication error event from a plurality of predefined smart codes. The service 10 request ticket for the user device is generated using the smart code.
[0010]
In some aspects of the present disclosure, for retrieving the parametric data associated with the geographical location from the database, the method includes identifying, by the event detection engine, a data-tag corresponding to the 15 geographical location. Moreover, the method includes determining, by the event detection engine, a data entry corresponding to the data-tag from the database. The data entry comprises the parametric data associated with the geographical location.
[0011]
In some aspects of the present disclosure, the parametric data comprises 20 a set of communication parameters fetched at the geographical location. The set of communication parameters comprises at least one outage alarm value associated with the geographical location, a signal congestion value at the geographical location, an interference value at the geographical location, a barring status value at the geographical location, at least one service affecting alarm value, and a 25 network coverage value at the geographical location.
[0012]
In some aspects of the present disclosure, for determining the at least one communication error event corresponding to the geographical location, the
5
method comprises comparing, by the event detection engine, each communication
parameter of the set of communication parameters with a corresponding threshold range.
[0013]
According to another embodiment, a system to manage mean handling 5 time associated with a user device in a communication network is provided. The system includes a data exchange engine, an event detection engine, and a ticket generation engine communicatively coupled to each other. The data exchange engine is configured to receive, from the user device, an Application Programming Interface (API) request to report an anomaly associated with the user device. The 10 API request comprises information of a geographical location corresponding to the user device. The event detection engine is configured to retrieve parametric data associated with the geographical location from the database. Moreover, the event detection engine is configured to determine at least one communication error event corresponding to the geographical location based on the parametric data. The ticket 15 generation engine is configured to generate a service request ticket for the user device based on the at least one communication error event.
BRIEF DESCRIPTION OF DRAWINGS
20
[0014]
Various embodiments disclosed herein will become better understood from the following detailed description when read with the accompanying drawings. The accompanying drawings constitute a part of the present disclosure and illustrate certain non-limiting embodiments of inventive concepts. Further, components and elements shown in the drawings are not necessarily to scale, 25 emphasis instead being placed upon clearly illustrating the principles of the present disclosure. For the purpose of consistency and ease of understanding, similar
6
components and elements are annotated by reference numerals in the exemplary
drawings.
FIG. 1 presents a block diagram depicting exemplary components of a system to manage an average call holding time to process service requests, in accordance with 5 an exemplary aspect of the present disclosure.
FIG. 2 illustrates a block diagram depicting exemplary components of a server, in accordance with an exemplary embodiment of the present disclosure.
10
FIG. 3 is a flow chart that depicts a method for managing the average call holding time to process service requests, in accordance with an exemplary aspect of the present disclosure.
LIST OF REFERENCE NUMERALS 15
110 – User Device
120 - Network
130 – Load Balancer 20
140 – Server
142 – Call Management Platform
142-1 – Call Queue Module
144 – Processor(s)
146 – Memory 25
148 – Communication Interface
150 – Database(s)
7
160 – Gateway Server
170 – Service Entity Device
202 – Console Host
203 – First Communication Bus
204 – Data Exchange Engine 5
206 – Event Detection Engine
208 – Ticket Generation Engine
210 – Smart Code Engine
212 – Script Generation Engine
214 – Notification Engine 10
216 - Instructions Repository
218 - Location Data Repository
220 - Error Data Repository
222 - Template Repository
224 – Smart Code Repository 15
226 - Second Communication Bus
DETAILED DESCRIPTION OF THE INVENTION
[0015]
Inventive concepts of the present disclosure will now be described more 20 fully hereinafter with reference to the accompanying drawings, in which examples of one or more embodiments of inventive concepts are shown. Inventive concepts may, however, be embodied in different forms and should not be construed as
8
limited to the embodiments set forth herein. Further, the one or more embodiments
disclosed herein are provided to describe the inventive concept thoroughly and completely, and to fully convey the scope of each of the present inventive concepts to those skilled in the art. Furthermore, it should be noted that the embodiments disclosed herein are not mutually exclusive concepts. Accordingly, one or more 5 components from one embodiment may be tacitly assumed to be present or used in any other embodiment.
[0016]
The following description presents various embodiments of the present disclosure. The embodiments disclosed herein are presented as teaching examples 10 and are not to be construed as limiting the scope of the present disclosure. The present disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary design and implementation illustrated and described herein, but may be modified, omitted, or expanded upon without departing from the scope of the present disclosure. 15
[0017]
The following description contains specific information pertaining to embodiments in the present disclosure. The detailed description uses the phrases “in some embodiments” which may each refer to one or more or all of the same or different embodiments. The term “some” as used herein is defined as “one, or more 20 than one, or all.” Accordingly, the terms “one,” “more than one,” “more than one, but not all” or “all” would all fall under the definition of “some.” In view of the same, the terms, for example, “in an embodiment” refers to one embodiment and the term, for example, “in one or more embodiments” refers to “at least one embodiment, or more than one embodiment, or all embodiments.” 25
[0018]
The term “comprising,” when utilized, means “including, but not necessarily limited to;” it specifically indicates open-ended inclusion in the so-described one or more listed features, elements in a combination, unless otherwise
9
stated with limiting language. Furthermore, to the extent that the terms “includes,”
“has,” “have,” “contains,” and other similar words are used in either the detailed description, such terms are intended to be inclusive in a manner similar to the term “comprising.”
5
[0019]
In the following description, for the purposes of explanation, various specific details are set forth to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any 10 combination of other features.
[0020]
The description provided herein discloses exemplary embodiments only and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, the foregoing description of the exemplary embodiments will 15 provide those skilled in the art with an enabling description for implementing any of the exemplary embodiments. Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it may be understood by one of the ordinary skilled in the art that the embodiments disclosed herein may be practiced without these specific details. 20
[0021]
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein the description, the singular forms "a", "an", and "the" include plural forms unless the context of the invention indicates otherwise. 25
[0022]
The terminology and structure employed herein are for describing, teaching, and illuminating some embodiments and their specific features and
10
elements and do not limit, restrict, or reduce the scope of the present disclosure.
Accordingly, unless otherwise defined, all terms, and especially any technical and/or scientific terms, used herein may be taken to have the same meaning as commonly understood by one having ordinary skill in the art.
5
[0023]
In the present disclosure, various embodiments are described using terms such as extensible radio access network (xRAN), and open-radio access network (O-RAN)) that are commonly used in communication standards (e.g., 3rd generation partnership project (3GPP), but these are merely examples for description. Various embodiments of the disclosure may also be easily modified 10 and applied to other communication systems.
[0024]
The following description provides specific details of certain aspects of the disclosure illustrated in the drawings to provide a thorough understanding of those aspects. It should be recognized, however, that the present disclosure can be 15 reflected in additional aspects and the disclosure may be practiced without some of the details in the following description.
[0025]
Various aspects of the present disclosure provide a system and a method for managing mean holding time (hereinafter interchangeably referred to as 20 ‘average call holding time’) to process service requests from user device(s) in a communication network. In some aspects of the present disclosure, the system and the method alleviate a burden of manual data entry by automating collection of customer details and populating complaint forms, thereby expediting call resolution and minimizing operational costs of a company. In some other aspects of the 25 present disclosure, the system and the method accelerate call handling processes while enhancing data accuracy and completeness thereby facilitating more informed decision making and improved customer interactions.
11
[0026]
In some embodiments, the method comprises fetching location information including a user location where one or more events indicating a degradation in performance of a network serving a user device have occurred and executing a network analysis operation to check a configurability of a plurality of 5 parameters associated with the performance of the network. Furthermore, the method comprises determining one or more probable root causes associated with the occurrence of the one or more events based on the executed network analysis operation.
10
[0027]
In some embodiments, the method comprises populating a script on a display screen of a device associated with the service entity based on the determined one or more probable root causes and generating a service ticket based on the populated script.
15
[0028]
Embodiments of the present disclosure will be described below in detail with reference to the accompanying drawings. FIG. 1 through FIG. 3, discussed below, and the embodiments used to describe the principles of the present disclosure are by way of illustration only and should not be construed in any way to limit the scope of the present disclosure. Those skilled in the art will understand 20 that the principles of the present disclosure may be implemented in any suitably arranged system or device.
[0029]
Various aspects and embodiments including the example embodiments are now described more fully with reference to the accompanying drawings, in 25 which the various aspects and embodiments of the disclosure are shown. The disclosure may, however, be embodied in different forms and should not be construed as limited to the aspects set forth herein. Rather, these aspects are provided so that this disclosure is thorough and complete, and fully conveys the
12
scope of the disclosure to those skilled in the art. In the drawings, the sizes of
components may be exaggerated for clarity.
[0030]
FIG. 1 presents a block diagram depicting a system 100 to manage mean holding time (i.e., average call holding time of a user device to process 5 service requests), in accordance with an exemplary aspect of the present disclosure. The embodiment of the system 100 shown in FIG. 1 is for illustration only. Other embodiments of the system 100 may be used without departing from the scope of this disclosure.
10
[0031]
As shown in FIG. 1, the system 100 may include a user device 110, a communication network 120 (hereinafter interchangeably referred to and designated as ‘network 120’), a load balancer 130, a server 140, a first database 150-1, a second database 150-2, a gateway server 160, and a service entity device 170. 15
[0032]
The user device 110 communicates with the server 140 via the network 120. Examples of the user device 110 may include smartphones, tablets, laptops, desktop computers, personal digital assistants (PDAs), smartwatches, and the like. The user device 110 may include a communication unit (not shown) for 20 transmission of a service request to the server 140. The communication unit may include a plurality of antennas, a plurality of Radio Frequency (RF) transceivers, a transmit processing circuitry, and a receive processing circuitry. Additionally, the user device 110 may further include circuitry, programing, applications, logic, codes, or a combination thereof. 25
[0033]
The communication network 120 enables transmission of service requests from the user device 110 to the server 140. The network 120 may also act
13
as a
communication medium between components of the system 100. The network 120 may correspond to one of an Internet, a proprietary Internet Protocol (IP) network, or other data network.
[0034]
The load balancer 130 is intermediary between the network 120 and the 5 server 140. The load balancer 130 is configured to distribute incoming service requests from the user device 110 to the server 140. In some embodiments, the incoming service requests may be received from a plurality of user devices (not shown in FIG. 1).
10
[0035]
The server 140 may include a call management platform 142 comprising a call queue module 142-1, at least one processor 144 (hereinafter also referred to as the “processor 144”), a memory 146 (hereinafter interchangeably referred to and designated as ‘database 146’), and a communication interface 148. The server 140 communicates with the user device 110 via the network 120 15 followed by the load balancer 130.
[0036]
The call management platform 142 is configured to receive incoming Application Programming Interface (API) call(s) from the load balancer 130 as the service request(s). The call management platform 142 adds the received API calls 20 to the call queue module 142-1. The call queue module 142-1 is configured to process the received API calls in a sequential manner.
[0037]
The processor 144 may include data processing engine(s) or other processing device(s) that controls the overall operation of the server 140. For 25 example, the processor 144 is configured to execute programs and other processes stored in the memory 146. The processor 144 is further configured to move data into or out of the memory 146 as required by an execution process.
14
[0038]
The processor 144 may include various processing circuitry and communicates with the memory 146 and the communication interface 148. The processor 144 may include the plurality of processors, including a general-purpose processor, such as, for example, and without limitation, a Central Processing Unit 5 (CPU), an Application Processor (AP), a dedicated processor, or the like, a graphics-only processing unit such as a Graphics Processing Unit (GPU).
[0039]
The processor 144 is configured to control the call management platform 142 to fetch location information from the incoming API call including 10 the user location where the one or more events indicating the degradation in performance of the network serving the user device 110 have occurred. The processor 144 is further configured to execute, based on information corresponding to network configurations, the network analysis operation to check the configurability of the plurality of parameters associated with the performance of 15 the network. Further, the processor 144 is configured to determine, corresponding to the user location, possible root cause(s) associated with the occurrence of the events based on the executed network analysis operation. The processor 144 is configured to populate the script on the display screen of the service entity device 170 based on the determined one or more probable root causes. The processor 144 20 is further configured to generate the service ticket based on the populated script.
[0040]
The database 146 is configured to store a set of instructions required by the processor 144 for controlling overall operations of the server 140. A part of the memory 146 may include a RAM, a Cache memory, or a ROM. The database 146 25 may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of Electrically Programmable Memories (EPROM) or
15
Electrically Erasable and Programmable (EEPROM) memories. In addition, the
memory 146 may, in some examples, be considered a non-transitory storage medium. The "non-transitory" storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be interpreted that the database 146 is non-movable. In some examples, the database 5 146 can be configured to store larger amounts of information. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache). The database 146 can be an internal storage unit or it can be an external storage unit of the server 140, cloud storage, or any other type of external storage. 10
[0041]
The communication interface 148 includes an electronic circuit specific to a standard that enables wired or wireless communication. The communication interface 148 is configured for communicating internally between internal hardware components and with external devices via one or more networks. 15 Examples of the communication interface 148 may include, but are not limited to, a MODEM, a network interface such as an Ethernet card, a communication port, and/or a Personal Computer Memory Card International Association (PCMCIA) slot and card, an antenna, a radio frequency (RF) transceiver, amplifier(s), a tuner, oscillator(s), a digital signal processor, a coder-decoder (CODEC) chipset, a 20 Subscriber Identity Module (SIM) card, and a local buffer circuit. It will be apparent to a person of ordinary skill in the art that the communication interface 148 may include any device and/or apparatus capable of providing wireless or wired communications between the server 140 and various other entities of the system 100. 25
[0042]
The first database 150-1 is configured to store information related to each of the processed service requests and associated complaint forms populated
16
by the server 140.
The second database 150-2 is configured to store real-time information required to process the incoming service requests. Further, the second database 150-2 may also store a time stamp associated with the received service requests. Examples of the first and second databases 150 may include but are not limited to, a ROM, a RAM, a flash memory, a removable storage drive, a HDD, a 5 solid-state memory, a magnetic storage drive, a PROM, an EPROM, and/or an EEPROM. In some aspects of the present disclosure, service(s) of the first and second databases 150 may be served through external databases. Examples of the external data center(s) may include, but are not limited to Oracle Database, Amazon Web Services (AWS) Database, and the like. In such a scenario, the memory 146 10 may be configured to temporarily store data from the external the data center(s).
[0043]
The gateway server 160 manages and processes data transferred by the call management platform 142 and stores the processed data into the second database 150-2. Further, the gateway server 160 may fetch any requisite data stored 15 in the second database 150-2 and transfer the fetched requisite data to the call management platform 142 for processing the incoming service requests.
[0044]
The service entity device 170 corresponds to a device used by a representative of the service entity responsible for resolving or processing the 20 incoming service requests. The service entity device 170 may correspond to smartphones, tablets, laptops, desktop computers, and the like. Aspects of the present disclosure are intended to include or otherwise cover any user device operated by a service providing entity (such as a service provider) that may be utilized to provide input(s) to manage the average call holding time to process 25 service requests as the service entity device 170, without deviating from the scope of the present disclosure.
17
[0045]
Although FIG. 1 illustrates one example of the system for managing (or reducing) the mean holding time of the call between the user and the service entity, various changes may be made to FIG. 1. For example, the system 100 may include any number of user devices and servers in any suitable arrangement. Further, in another example, the system 100 may include any number of components in 5 addition to the components shown in FIG. 1. Further, various components in FIG. 1 may be combined, further subdivided, or omitted and additional components may be added according to particular needs.
[0046]
FIG. 2 illustrates a block diagram depicting exemplary components of 10 the server 140, in accordance with an exemplary embodiment of the present disclosure. The embodiments of the server 140 shown in FIG. 2 are for illustration only. Other embodiments of the server 140 may be used without departing from the scope of this disclosure.
15
[0047]
According to the exemplary embodiment presented through FIG. 2, the server 140 may include the call management platform 142 comprising the call queue module 142-1, the processor(s) 144, the memory 146, the communication interface 148, and a console host 202 communicatively coupled to each other by way of a first communication bus 203. 20
[0048]
The console host 202 may include suitable logic, circuitry, interfaces, and/or codes that may be configured to enable the communication interface 148 to receive input(s) and/or present output(s) from a user. The user may correspond to an operator of the user device 110 and/or the service entity device 170 exchanging 25 data and/or instructions with the server 140 for management of the average call holding time to process the service requests. In some aspects of the present disclosure, the console host 202 may include suitable logic, instructions, and/or
18
codes for executing various operations of computer executable applications to host
an application running via an application console (not shown) on the user device 110 and/or the service entity device 170, by way of which the user can trigger the server 140 to manage the average call holding time to process the service requests. In some other aspects of the present disclosure, the console host 202 may provide 5 a Graphical User Interface (GUI) for the server 140 for user interaction.
[0049]
The processor(s) 144 may include data transfer engine(s) and/or data processing engine(s) configured with suitable logic, instructions, circuitry, interfaces, and/or codes for executing operations of various operations performed 10 by the server 140 for computations and data processing related to management of the average call holding time to process service requests associated with the user device 110. Particularly, the processor(s) 144 may include a data exchange engine 204, an event detection engine 206, a ticket generation engine 208, a smart code engine 210, a script generation engine 212, and a notification engine 214. Various 15 engines in the processor(s) 144 may be coupled to each other by way of a second communication bus 226.
[0050]
The data exchange engine 204 may be configured to enable transfer of data from the memory 146 to various engines of the processor(s) 144. The data 20 exchange engine 204 may further be configured to enable a transfer of data and/or instructions (by way of signal(s)) between various other engines of the processor(s) 144. Furthermore, the data exchange engine 204 may be configured to enable the server 140 to receive input(s) from the user device 110 and/or the service entry device 170 and provide output(s) to the user device 110 and/or the service entry 25 device 170. Particularly, the data exchange engine 204 may be configured to receive an Application Programming Interface (API) request to report anomaly associated with the user device 110. The API request may be generated by the user
19
device 110 and may be transmitted to the server 140 via the service entity device
170. The API request may include information of the geographical location corresponding to the user device 110. In some aspects of the present disclosure, the anomaly may be associated with an abnormality of the user device 110 such as, but not limited to, at least one outage associated with the geographical location of the 5 user device 110, a signal congestion at the geographical location of the user device 110, a signal interference at the geographical location of the user device 110, affected communication service(s) received by the user device 110, and poor network coverage at the geographical location of the user device 110.
10
[0051]
The event detection engine 206 may be configured to receive the API request from the data exchange engine 204 and extract the information of the geographical location of the user device 110 from the API request. Moreover, the event detection engine 206 may be configured to retrieve parametric data associated with the geographical location from the memory 146 based on the information of 15 the geographical location. The parametric data includes a set of communication parameters fetched at the geographical location. In some aspects of the present disclosure, the set of communication parameters comprises at least one outage alarms associated with the geographical location, a signal congestion value at the geographical location, an interference value at the geographical location, a barring 20 status at the geographical location, at least one service affecting alarms, and a network coverage value at the geographical location.
[0052]
Specifically, the parametric data may be attached with an identifier (e.g., a label) corresponding to the geographical location and may be stored in the 25 memory 146. The event detection engine 206 may further be configured to extract value(s) of the set of communication parameters from the parametric data and determine communication error event(s) corresponding to the geographical location. The communication error event(s) may correspond to a presence of the
20
anomaly
in communication service(s) of the user device 110 as presented hereinabove. In some aspects of the present disclosure, the event detection engine 206 may match the parametric data with a set of predefined error configurations and generate a matching score for the parametric data corresponding to each pre-defined error configuration. The error detection engine 206 may identify event(s) 5 having the matching score higher than a predefined score threshold value as communication error event(s). In some aspects of the present disclosure, the event detection engine 206 may determine sources (e.g., root causes) for deviation of the set of communication parameters from a regular communication parameter configuration (without any error) in each communication error event. 10
[0053]
In some aspects of the present disclosure, for retrieving the parametric data associated with the geographical location from the database 146, the event detection engine 206 may identify the data-tag corresponding to the geographical location. The data-tag may be associated with each database entry corresponding 15 to the geographical location. In some aspects of the present disclosure, the event detection engine 206 may fetch the data entry corresponding to the geographical location based on a look-up table stored in the database. The look-up table may map the data-tags with the data entries for different geographical locations serviced through the communication network. Moreover, the event detection engine 206 20 may determine the data entry corresponding to the data-tag from the database. The data entry comprises the parametric data associated with the geographical location.
[0054]
In some aspects of the present disclosure, for determining the at least one communication error event corresponding to the geographical location, the 25 event detection engine 206 may compare each communication parameter of the set of communication parameters with a corresponding threshold range.
21
[0055]
The smart code engine 210 may be configured to determine a smart code associated with the communication error event(s) from multiple predefined smart codes stored in the memory 146. In some aspects of the present disclosure, each combination of the communication error event(s) may be assigned a predefined smart code, that may be stored in the memory 146 as a look-up table. The smart 5 code engine 210 may be configured to extract the smart code for the communication error events from the look-up table using matrix matching technique. Each smart code is predefined based on a combination of the determined communication error event(s). For example, a combination of outage associated with the geographical location, a signal congestion at the geographical location may be assigned a smart 10 code ‘AA2’, a combination of outage associated with the geographical location, a signal congestion at the geographical location, and poor network coverage may be assigned the smart code ‘AB1’, and an interference in the communication may be assigned the smart code ‘B1’.
15
[0056]
The ticket generation engine 208 may be configured to generate a service request ticket for the user device 110 based on the communication error event(s). In some aspects of the present disclosure, the service request ticket for the user device is generated by the ticket generation engine 208 using the smart code extracted from the memory 114 based on the communication error event(s). 20
[0057]
The script generation engine 212 may be configured to retrieve an information template for the communication error event(s) from the memory 146. The script generation engine 212 may further be configured to generate a communication script for the user device 110 and/or the service entity device 170 25 using the information template, the parametric data, the service request ticket, or a combination thereof. The notification engine 214 may be configured to generate notification(s) corresponding to various operations of the processor(s) 140.
22
Moreover, the notification engine 214 may be configured to generate a complaint
summary based on the determined communication error event(s) and enable the communication script and/or the complaint summary to be rendered on the user device 110 and/or the service entity device 170.
5
[0058]
Various engines of the processor(s) 144 are presented to illustrate the functionality driven by the server 140. It will be apparent to a person having ordinary skill in the art that various engines in the processor(s) 144 are for illustrative purposes and not limited to any specific combination of hardware circuitry and/or software. 10
[0059]
The memory 146 may be configured to store data corresponding to system 100. In some aspects of the present disclosure, the memory 146 may be segregated into multiple repositories that may be configured to store a specific type of data. In the exemplary embodiment as presented through FIG. 2, the memory 15 146 includes an instructions repository 216, a location data repository 218, an error data repository 220, a template repository 222, and a smart code repository 224.
[0060]
The instructions repository 216 may be configured to store instructions and/or codes for operation(s) to be performed by various components of server 140. 20 The location data repository 218 may be configured to store parametric data associated with various geographical locations operational for the system 100. The error data repository 220 may be configured to store data corresponding to various communication error events. The template repository 222 may be configured to store communication templates associated with the communication error events. 25 The smart code repository 224 may be configured to store the smart codes corresponding to various combinations of the communication error events.
23
[0061]
According to an embodiment of the present disclosure, the instructions repository 216 may be configured as a non-transitory storage medium particularly configured to store instructions and/or codes for operation(s) to be performed by various engines of the processor(s) 144 for managing the average call holding time associated with the user device 110. Examples of the instructions repository 216 5 configured as the non-transitory storage medium includes hard drives, solid-state drives, flash drives, Compact Disk (CD), Digital Video Disk (DVD), and the like. Aspects of the present disclosure are intended to include or otherwise cover any type of non-transitory storage medium as the instructions repository 216, without deviating from the scope of the present disclosure. 10
[0062]
It will be apparent to a person of ordinary skill in the art that the repositories in the memory 146 are presented based on the functionality of the server 140 and are not limited to those disclosed. The memory 146 may have any configuration, combination and/or count of repositories without deviating from the 15 scope of the present disclosure. Although FIG. 2 illustrates one example of the server 140, various changes may be made to FIG. 2. Further, the server 140 may include any number of components in addition to those shown in FIG. 2, without deviating from the scope of the present disclosure. Further, various components in FIG. 2 may be combined, further subdivided, or omitted and additional components 20 may be added according to particular needs.
[0063]
FIG. 3 illustrates a flow chart for a method 300 for managing the mean holding time (i.e., the average call holding time of the user device) to process service requests, in accordance with an exemplary embodiment of the present 25 disclosure.
24
[0064]
At block 302, the server 140 may receive the API request to report the anomaly associated with the user device 110 (directly from the user device 110 or via the service entity device 170). The API request comprises information of the geographical location corresponding to the user device 110.
5
[0065]
At block 304, the server 140 may retrieve the parametric data associated with the geographical location. The parametric data comprises the set of communication parameters fetched at the geographical location. In some aspects of the present disclosure, the set of communication parameters comprises at least one outage alarms associated with the geographical location, the signal congestion 10 value at the geographical location, the interference value at the geographical location, the barring status at the geographical location, at least one service affecting alarms, and the network coverage value at the geographical location.
[0066]
In some aspects of the present disclosure, for retrieving the parametric 15 data associated with the geographical location from the database 146, the server 140 may identify the data-tag corresponding to the geographical location. The server 140 may further determine the data entry corresponding to the data-tag from the database 146, where the data entry includes the parametric data associated with the geographical location. 20
[0067]
At block 306, the server 140 may determine the communication error event(s) corresponding to the geographical location based on the parametric data. In some aspects of the present disclosure, for determining the communication error event(s) corresponding to the geographical location, the server 140 may compare 25 each communication parameter of the set of communication parameters with a corresponding threshold range.
25
[0068]
At block 308, the server 140 may generate the service request ticket for the user device 110 based on the communication error event(s). In some aspects of the present disclosure, the server 140 may determine the smart code associated with the communication error event(s) and generate the service request ticket for the user device 110 using the determined smart code. 5
[0069]
At block 310, the server 140 may retrieve the information template for the communication error event(s).
[0070]
At block 312, the server 140 may generate the communication script for 10 the user device 110 using the information template, the parametric data, the service request ticket, or a combination thereof.
[0071]
Referring to the technical abilities and advantageous effect of the present disclosure, operational advantages that may be provided by one or more 15 embodiments may include providing the system and the method for alleviating the burden of the manual data entry by automating the collection of the customer details and populating the complaint forms, thereby expediting the call resolution, and minimizing the operational costs of the company. A further potential advantage of the one or more embodiments disclosed herein include accelerating the call 20 handling processes while enhancing the data accuracy and completeness, thereby facilitating more informed decision making and improved customer interactions. Additionally, the method facilitates alleviating a burden of manual data entry by automating collection of customer details and populating complaint forms, thereby expediting call resolution, and minimizing operational costs for an infrastructure. 25 The method results in an effective reduction in a mean holding time of the calls at customer care center, thereby results in reduction of expenses.
26
[0072]
Those skilled in the art will appreciate that the methodology described herein in the present disclosure may be carried out in other specific ways than those set forth herein in the above disclosed embodiments without departing from essential characteristics and features of the present invention. The above-described embodiments are therefore to be construed in all aspects as illustrative and not 5 restrictive.
[0073]
The drawings and the forgoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. 10 Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, orders of processes described herein may be changed and are not limited to the manner described herein. Any combination of the above features and functionalities may be used in accordance with one or more embodiments. 15
[0074]
In the present disclosure, each of the embodiments has been described with reference to numerous specific details which may vary from embodiment to embodiment. The foregoing description of the specific embodiments disclosed herein may reveal the general nature of the embodiments herein that others may, by 20 applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications are intended to be comprehended within the meaning of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and 25 is not limited in scope. ,CLAIMS:We Claim:
1.
A method (300) for managing mean holding time for a user device (110) in a communication network (120), the method (300) comprising:
receiving, by a data exchange engine (204) from the user device (110), an Application Programming Interface (API) request to report an anomaly 5 associated with the user device (110), wherein the API request comprises information of a geographical location corresponding to the user device (110);
retrieving, by an event detection engine (206) from a database (146), parametric data associated with the geographical location;
determining, by the event detection engine (206) based on the 10 parametric data, at least one communication error event corresponding to the geographical location; and
generating, by a ticket generation engine (208), a service request ticket for the user device (110) based on the at least one communication error event.
15
2.
The method (300) as claimed in claim 1, further comprises determining, by a smart code engine (210), a smart code associated with the at least one communication error event from a plurality of predefined smart codes, wherein the service request ticket for the user device (110) is generated using the smart code. 20
3.
The method (300) as claimed in claim 1, further comprising:
retrieving, by a script generation engine (212) from the database (146), an information template for the at least one communication error event; and
generating, by the script generation engine (212), a communication 25 script for the user device (110) using the information template, the parametric data, the service request ticket, or a combination thereof.
28
4.
The method (300) as claimed in claim 1, wherein for retrieving the parametric data associated with the geographical location from the database (146), the method (300) comprising:
identifying, by the event detection engine (206), a data-tag corresponding to the geographical location; and 5
determining, by the event detection engine (206), a data entry corresponding to the data-tag from the database (146), wherein the data entry comprises the parametric data associated with the geographical location.
5.
The method (300) as claimed in claim 1, wherein the parametric data comprises 10 a set of communication parameters fetched at the geographical location, and wherein the set of communication parameters comprises at least one outage alarm value associated with the geographical location, a signal congestion value at the geographical location, an interference value at the geographical location, a barring status value at the geographical location, at least one service affecting 15 alarm value, and a network coverage value at the geographical location.
6.
The method (300) as claimed in claim 5, wherein for determining the at least one communication error event corresponding to the geographical location, the method (300) comprises comparing, by the event detection engine (206), each 20 communication parameter of the set of communication parameters with a corresponding threshold range.
7.
A system (100) to manage mean holding time associated with a user device (110) in a communication network (120), the system (100) comprising: 25
a data exchange engine (204) configured to receive, from the user device (110), an Application Programming Interface (API) request to report an anomaly associated with the user device (110), wherein the
29
API request comprises information of a geographical location corresponding to the user device (110);
an event detection engine (206) configured to:
retrieve parametric data associated with the geographical location from the database (146); and 5
determine, based on the parametric data, at least one communication error event corresponding to the geographical location; and
a ticket generation engine (208) configured to generate a service request ticket for the user device (110) based on the at least one 10 communication error event.
8.
The system (100) as claimed in claim 7, further comprising a smart code engine (210) configured to determine a smart code associated with the at least one communication error event from a plurality of predefined smart codes, wherein 15 the service request ticket for the user device (110) is generated using the smart code.
9.
The system (100) as claimed in claim 7, further comprises a script generation engine (212) configured to: 20
retrieve, from the database (146), an information template for the at least one communication error event; and
generate a communication script for the user device (110) using the information template, the parametric data, the service request ticket, or a combination thereof. 25
30
10.
The system (100) as claimed in claim 7, wherein for retrieving the parametric data associated with the geographical location from the database (146), the event detection engine (206) is configured to:
identify a data-tag corresponding to the geographical location; and
determine a data entry corresponding to the data-tag from the database 5 (146), wherein the data entry comprises the parametric data associated with the geographical location.
11.
The system (100) as claimed in claim 7, wherein the parametric data comprises a set of communication parameters fetched at the geographical location, and 10 wherein the set of communication parameters comprises at least one outage alarm value associated with the geographical location, a signal congestion value at the geographical location, an interference value at the geographical location, a barring status value at the geographical location, at least one service affecting alarm value, and a network coverage value at the geographical location. 15
12.
The system (100) as claimed in claim 11, wherein for determining the at least one communication error event corresponding to the geographical location, the event detection engine (206) is configured to compare each communication parameter of the set of communication parameters with a corresponding 20 threshold range.