The present invention generally relates to customer support. Specifically, the present invention relates to interaction solutions and problem resolution optimization in the customer care process.
Today, there are essentially two ways to provide customer support: (1) In House Support: Based on a support contract with Service Level Agreements (SLAs) between product producer and product buyer (the customer) with ensured problem resolution times. The product producer therefore has typically a dedicated support organization with paid employees resolving problems reported by customers. An in house support infrastructure can include a typical backend system, an online system or a combination thereof. (2) Online Support: Online forums where problems can be posted and anyone can answer. A typical example is a developer forum where anyone can post a problem message. However, there is no guarantee if and when someone will answer because there are no SLAs based on a support contract in place. Key differences to in-house support include the following: there is no guarantee that the problem will be solved at all; there is no guarantee regarding the timeframe when the problem will be solved.
Many companies have both types of infrastructures today, but separately without any integration in between. This leads to negative consequences such as: a lack of consistent reporting regarding which parts of a product are having the most problems for example which need to be addressed in the next version with major quality improvements; a lack of consistent reporting regarding which people are the most effective problem solvers; a lack of consistent classification of problems and problem priorities is possible; resolved issues in one system are not found in searches in the other system. This causes that a customer might open another problem report for an already solved issue causing a waste of time in the support organizations; reduced customer loyalty; missed cost saving opportunities; the problem is not answered by the best available expert considering in house and online support; and “expert rank” is derived by social computing infrastructure which is not integrated with traditional in house support.
The present invention provides a system, architecture and process to support new interaction paradigms in customer support. Specifically, the approach of the present invention will unify through a new process and innovative system architecture the two basic methods of in house support and online support. To accomplish this unification, the present invention enables customers to work together as peers in problem resolution by exploiting the customer expertise (they work with the products on a daily basis and often have deep understanding what works/does not work). Among other things, the present invention provides: incentives for customers to participate in this new support; a rating infrastructure in which multiple good ratings helps to become “THE EXPERT” by increasing the score; incentives upon receipt of good ratings and or certain score levels; a problem routing mechanism; Master Data Management (MDM) for insights in customers and products. Examples of MDM functions relevant for the present invention include the capability to:
A first aspect of the present invention provides a customer support method, comprising: performing a search for set of possible solutions to a problem, the set of possible solutions comprising online support and in-house support; identifying and notifying a peer to assist with resolution of the problem in response to a notification of the problem; receiving feedback on the set of possible solutions via a ratings system; and monitoring compliance with a Service Level Agreement (SLA) for both the in-house support and the online support in resolving the problem.
A second aspect of the present invention provides a customer support system, comprising: a module for performing a search for set of possible solutions to a problem, the set of possible solutions comprising online support and in-house support; module for identifying and notifying a peer to assist with resolution of the problem in response to a notification of the problem; a module for receiving feedback on the set of possible solutions via a ratings system; and a module for monitoring compliance with a Service Level Agreement (SLA) for both the in-house support and the online support in resolving the problem.
A third aspect of the present invention provides a computer readable medium containing a program product for customer support, the computer readable medium comprising instructions for causing a computer system to: perform a search for set of possible solutions to a problem, the set of possible solutions comprising online support and in-house support; identify and notifying a peer to assist with resolution of the problem in response to a notification of the problem; receive feedback on the set of possible solutions via a ratings system; and monitor compliance with a Service Level Agreement (SLA) for both the in-house support and the online support in resolving the problem.
A fourth aspect of the present invention provides a method for deploying an application for customer support, comprising: providing a computer infrastructure being operable to: perform a search for set of possible solutions to a problem, the set of possible solutions comprising online support and in-house support; identify and notifying a peer to assist with resolution of the problem in response to a notification of the problem; receive feedback on the set of possible solutions via a ratings system; and monitor compliance with a Service Level Agreement (SLA) for both the in-house support and the online support in resolving the problem.
A fifth aspect of the present invention provides a computer-implemented method for providing customer support method, comprising: performing a search for set of possible solutions to a problem, the set of possible solutions comprising online support and in-house support; identifying and notifying a peer to assist with resolution of the problem in response to a notification of the problem; receiving feedback on the set of possible solutions via a ratings system; and monitoring compliance with a Service Level Agreement (SLA) for both the in-house support and the online support in resolving the problem.
A sixth aspect of the present invention provides a data processing system for providing customer support, comprising: a memory medium containing instructions, a bus coupled to the memory medium, and a processor coupled to the bus that when executing the instructions causes to data processing system to: perform a search for set of possible solutions to a problem, the set of possible solutions comprising online support and in-house support; identify and notifying a peer to assist with resolution of the problem in response to a notification of the problem; receive feedback on the set of possible solutions via a ratings system; and monitor compliance with a Service Level Agreement (SLA) for both the in-house support and the online support in resolving the problem.
These and other features of this invention will be more readily understood from the following detailed description of the various aspects of the invention taken in conjunction with the accompanying drawings in which:
The drawings are not necessarily to scale. The drawings are merely schematic representations, not intended to portray specific parameters of the invention. The drawings are intended to depict only typical embodiments of the invention, and therefore should not be considered as limiting the scope of the invention. In the drawings, like numbering represents like elements.
For convenience, the Detailed Description of the Invention has the following Sections:
I. General Description
II. Computerized Implementation
Prior to describing the invention, the following roles are defined:
Solution Searcher means the customer having a problem.
Peer is defined as another customer acting as peer to solve the problem.
Employee or Customer Care representative (CCR) is defined as a member of the customer care/support staff.
The first two actors are peers to each other among the customers themselves. The third actor is regarding the process also just a peer answering problems tearing down the distinction on this platform between employee (internal participant) and customer (external participant) and will be measured with the same metrics regarding rating scores, number of problems solved, etc as the external participants.
As indicated above, present invention provides a system, architecture and process to support new interaction paradigms in customer support. Specifically, the approach of the present invention will unify through a new process and innovative system architecture the two basic methods of in house support and online support. To accomplish this unification, the present invention enables customers to work together as peers in problem resolution by exploiting the customer expertise (they work with the products on a daily basis and often have deep understanding what works/does not work). Among other things, the present invention provides: incentives for customers to participate in this new support; a rating infrastructure in which multiple good ratings helps to become “THE EXPERT” by increasing the score; incentives upon receipt of good ratings and or certain score levels; a problem routing mechanism; Master Data Management (MDM) for insights in customers and products.
A high level system architecture will now be described starting with reference to
An example for the Peer Customer Care 2.0 system (system (3) in
Referring back to
The process flow of the new interaction paradigms in customer support will now be explained. As such, two distinct phases will be described:
The advantage of this distribution rule approach is that it notifies a suitable skilled person for problem solving in the context of the posting priority of the problem and considering cost reduction (e.g. skill is likely good enough in online support). For example, consider the following distribution rule table (note that rules are intended as examples—therefore the list is far from complete and intended as illustration only in Table 1):
Rows 1-3 illustrate for example that as per business decision all very high problem messages should be routed to the in house support organization independent from the expert rank. This becomes particularly obvious in row 2 where the online support team has a higher ranked expert. Rows 4-6 are an example that as per business decision all high priority problems are routed to online support first if an expert of rank “best rank” or “medium rank” exists thus offloading in house support.
Row 7 indicates if the expert rank for online support for problems with high priority falls below medium rank and a better expert is available in the in house organization, the problem will be routed there. This is an example where the distribution rule algorithm routes the problem to a more skilled person.
Row 8 and 9 reflect the idea of cost reduction in the in house support organization. Even if there would be better skills available in the in house support organization compared to online support delivered through customer peers you could route these problems to the online support first.
Row 10 shows a rule ensuring the SLA contract for support with the clients. If the problem message has not been processed at all or only partial solutions have been provided by the Peer Customer 2.0 platform until a certain threshold is reached, then the problem has to be routed to in house support with proper escalation mechanism including notifications, etc. Note that there can be more than one rule of this type (e.g. one per priority of problem message). Furthermore, note that the expiry time threshold has to be checked with a monitoring component illustrated with (14) in
Note that a complete distribution rule table has a complete set of rules for all problem priorities and rank combinations of experts in the in house and online support group with a routing instruction. Therefore, the distribution rule algorithm will always make an assignment of the problem message.
Based on these simple rules leveraging customer expertise in problem solving the Peer Customer Care 2.0 platform computes based on distribution rules (10) to which target the problem is routed (11). Also note that the information from the MDM System is critical to support the Peer Customer Care 2.0 platform here in the support process. The reason for this is that the distribution rules take into consideration the rank of the peers which are managed by the MDM system which stores customer and employee information alike.
For step 10 in
The distribution rule algorithm now described is therefore a more advanced configuration of this invention delivering even more business benefits.
The below sections discusses this in greater detail. Specifically, in this section it is mentioned where the distribution rules algorithm works as part of the overall support process. In addition, the distribution rules algorithm replaces or supplements the logic related to (9) and (10) in
For a Distribution Rules Algorithm, the following is needed:
Input:
Such a message is triggering the Distribution Rules Algorithm in one of the following three cases:
The Distribution Rules Algorithm
It is assumed the program representing the Distribution Rules Algorithm started successfully and has loaded all configuration parameters successfully. At some point in time after start, the first problem message and later on subsequent problem messages will be received. This is the point where we describe how the algorithm works in principal. In
Step 1 in
Step 2 in
Step 2 now matches the incoming list of themes with probabilities against all peer theme lists. Whenever a theme is found on both lists, the peer is added to the peer list which is a result of this processing step. As a result, step 2 delivers to the next step the problem message, a list of peers and a list of themes with probabilities. Thus, from all peers who could work on the problem, the sub-set, which are the suitable candidates for this problem have been selected.
Step 3 in
Step 4 in
Appendix on Escalation Table:
As said, the preferred embodiment of this invention dictates that the initial response and the problem resolution time as agreed with the support contract are satisfied at all times. Let's assume the following for illustration:
So if the company hosting the Support 2.0 Customer Care platform agreed to a support contract with the time schedules as outlined above, then this needs to hold true even if the problem message is routed at some point to a peer in the Peer Customer Care 2.0 platform versus to a peer in the in house support organization. If a problem message is routed to the Peer Customer Care 2.0 platform through a monitoring component the time until the above deadlines are hit are monitored on an ongoing basis. Assume the peer who got the problem message assigned is sick or on vacation or can't look at the problem message for some other reason, there has to be a way to detect this early enough and re-route the problem message to someone else. The detection is possible through the monitoring component. However, the monitoring component needs to have a proper configuration table when the problem message needs to be submitted again to the distribution rules algorithm which then needs to decide how to re-route the message again. Here the company needs the ability to influence when the distribution rules algorithm must route the problem message to the in house support organization so that a peer being an in house employee is taking care of the issue in time. Also the notification representing the escalation if such a re-route is needed needs to be configurable. For example, it could be that SMS and email is used at the same time for peer notification for a high priority message where for a low priority message only email is used. To illustrate these thresholds configuration options, look at the table below:
Note that the re-route thresholds are checked for by the monitoring component.
Once the distribution rules algorithm determined a destination to which the problem is routed as discussed the next part of the invention is the processing involved with arriving at a solution to a problem. This process flow involved with answering a problem is shown in
When a solution searcher submits a problem, there are on a high level two possible destinations:
Note that through the ongoing monitoring through the monitoring component and escalation through this component at all times the support contract response and resolution times for the problems are guaranteed. Therefore, the described system architecture and process unites the in house and online support organizations.
Referring now to
Computer system is intended to represent any type of computer system that may be implemented in deploying/realizing the teachings recited herein. It should be understood that any other computers implemented under the present invention will have similar components, but may perform different functions/have different software. As shown, computer system 104 includes a processing unit 106, a memory 108, a bus 110, and device interfaces 112. Further, computer system 104 is shown communicating with one or more external devices 114 that communicate with bus via device interfaces. In general, processing unit 106 executes computer program code, such customer care platform 124, which is stored in memory 108 and/or storage system 116. While executing computer program code, processing unit 106 can read and/or write data to/from memory 108, storage system 116, and/or device interfaces 112. Bus 110 provides a communication link between each of the components in computer system 104. Although not shown, computer system 104 could also include I/O interfaces that communicate with: one or more external devices such as a kiosk, a checkout station, a keyboard, a pointing device, a display, etc.); one or more devices that enable a user to interact with computer system 104; and/or any devices (e.g., network card, modem, etc.) that enable computer system 104 to communicate with one or more other computing devices. Although not shown, computer system 104 could contain multiple processing units.
Computer infrastructure 102 is only illustrative of various types of computer infrastructures for implementing the invention. For example, in one embodiment, computer infrastructure 102 comprises two or more computing devices (e.g., a server cluster) that communicate over a network to perform the various processes of the invention. Moreover, computer system 104 is only representative of various possible computer systems that can include numerous combinations of hardware. To this extent, in other embodiments, computer system 104 can comprise any specific purpose computing article of manufacture comprising hardware and/or computer program code for performing specific functions, any computing article of manufacture that comprises a combination of specific purpose and general purpose hardware/software, or the like. In each case, the program code and hardware can be created using standard programming and engineering techniques, respectively. Moreover, processing unit 106 may comprise a single processing unit, or be distributed across one or more processing units in one or more locations, e.g., on a client and server. Similarly, memory 108 and/or storage system 116 can comprise any combination of various types of data storage and/or transmission media that reside at one or more physical locations. Further, device interfaces 112 can comprise any module for exchanging information with one or more external devices. Still further, it is understood that one or more additional components (e.g., system software, math co-processing unit, etc.) not shown in
Storage system 116 can be any type of system (e.g., storage units 116 of
Shown in memory 108 of computer system 104 is customer care platform 124, which has a set of modules 126. Set of modules 126 generally provide the functions of the present invention as described herein. For example, (among other things), set of modules 126 is configured to receive problems, determine distribution rules, offer problems to solutions, rate answers, find and communicate with a specialist, etc
While shown and described herein as a framework for customer care/support, it is understood that the invention further provides various alternative embodiments. For example, in one embodiment, the invention provides a computer-readable/useable medium that includes computer program code to enable a computer infrastructure to provide customer care/support as described herein. To this extent, the computer-readable/useable medium contains program code that implements each of the various processes of the invention. It is understood that the terms computer-readable medium or computer useable medium comprises one or more of any type of physical embodiment of the program code. In particular, the computer-readable/useable medium can comprise program code embodied on one or more portable storage articles of manufacture (e.g., a compact disc, a magnetic disk, a tape, etc.), on one or more data storage portions of a computing device, such as memory 108 (
In another embodiment, the invention provides a business method that performs the process of the invention on a subscription, advertising, and/or fee basis. That is, a service provider, such as a Solution Integrator, could offer to provide customer care/support as described herein. In this case, the service provider can create, maintain, support, etc., a computer infrastructure, such as computer infrastructure 102 (
In still another embodiment, the invention provides a computer-implemented method for variable energy pricing. In this case, a computer infrastructure, such as computer infrastructure 102 (
As used herein, it is understood that the terms “program code” and “computer program code” are synonymous and mean any expression, in any language, code or notation, of a set of instructions intended to cause a computing device having an information processing capability to perform a particular function either directly or after either or both of the following: (a) conversion to another language, code or notation; and/or (b) reproduction in a different material form. To this extent, program code can be embodied as one or more of: an application/software program, component software/a library of functions, an operating system, a basic device system/driver for a particular computing and/or device, and the like.
A data processing system suitable for storing and/or executing program code can be provided hereunder and can include at least one processor communicatively coupled, directly or indirectly, to memory elements through a system bus. The memory elements can include, but are not limited to, local memory employed during actual execution of the program code, bulk storage, and cache memories that provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution. Input/output or device devices (including, but not limited to, keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening device controllers. Network adapters also may be coupled to the system to enable the data processing system to become coupled to other data processing systems, remote printers, storage devices, and/or the like, through any combination of intervening private or public networks. Illustrative network adapters include, but are not limited to, modems, cable modems and Ethernet cards.
The foregoing description of various aspects of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed, and obviously, many modifications and variations are possible. Such modifications and variations that may be apparent to a person skilled in the art are intended to be included within the scope of the invention as defined by the accompanying claims.