EP1310089A1

EP1310089A1 - Method and apparatus for customer relationship assessment and planning

Info

Publication number: EP1310089A1
Application number: EP01921743A
Authority: EP
Inventors: Sheldon Davis; Daniel Davison
Original assignee: Nortel Networks Ltd
Current assignee: Nortel Networks Ltd
Priority date: 2000-03-27
Filing date: 2001-03-27
Publication date: 2003-05-14
Also published as: AU4870601A; WO2001074054A1

Abstract

A device for customer relationship assessment (100) is provided. The customer relationship assessment device has a customer interaction database (124) that receives a plurality of customer interaction data. The customer interaction data is received by the customer as the customer service-related interactions occur in a manner sufficient to provide a timely representation of customer interactions on request. A processor is programmed to generate a return-on-relationship value that characterizes the plurality of customer interaction data on which to base a relationship response. A method for assessing a customer relationship is provided by storing a plurality of user interaction data in a customer care database. The user interaction data is associated with at least one of a plurality of customers in the customer care database. With user interaction data, a return-on-relationship index is generated.

Description

Method and Apparatus for Customer Relationship Assessment and Planning

Field of the Invention

The present invention relates to customer relationship management technology and, in particular, to customer relationship assessment and planning.

Background of the Invention

Generally, commerce involves the transaction between a customer and a merchant.

The transaction can be based upon goods, services, or a combination of both. To the benefit of the customer and the merchant, an enduring relationship develops. Customers generally seek a relationship with a merchant, and such a relationship generally occurs due to the quality of service and value received in transactions with the merchant.

Development of a customer relationship is desired because the initial attraction of a customer in competitive industries is a time-intensive process. It can be estimated that the cost of attracting a customer is about five times what it takes to retain a customer. Accordingly, retention of existing customers becomes as important, if not more, as compared to developing new customer relationships.

In this regard, a need exists to enable evaluation of customer relationships and to sustain activities relating to maintaining and developing the relationship based on an evaluation.

Brief Summary of the Invention

A device for customer relationship assessment and evaluation is provided. The customer relationship assessment device has a customer interaction database that receives a plurality of customer interaction data. The customer interaction data is received by the customer interaction database as the customer service-related interactions occur in a manner sufficient to provide a timely representation of customer interactions on request. A processor is programmed to generate a return-on-relationship value that characterizes the plurality of customer interaction data on which to base a relationship response. A method for assessing a customer relationship is provided, by storing, in a customer care database, a plurality of user interaction data. The user interaction data is associated with at least one of a plurality of customers in a customer care database. With the user interaction data, assessment is continued by generating a return-on-relationship index that characterizes the plurality of multimedia user interaction data and determining an action in response to the return-on-relationship index.

Brief Description of the Drawings

The accompanying drawings are incorporated into and form a part of the specification to illustrate examples of the present invention. The drawings together with the description serve to explain the principles of the invention. The drawings are included for the purposes of illustrating preferred and alternative examples of how the invention can be made and used and are not to be construed as limiting the invention to only the illustrated and described examples. Various advantages and features of the present invention will be apparent from a consideration of the drawings in which:

FIGURE 1 is a block diagram of a customer care system coupled to a telephony/ data communications system;

FIGURE 2 is a block diagram of customer care services provided through a customer care system,

FIGURE 3 is a block diagram illustrating aspects of service relationships relating to the present invention; FIGURE 4 is a flow chart that illustrates a generation and implementation of a

Return-on-Relationship value engine;

FIGURE 5 is a functional block diagram illustrating a Return-on-Relationship engine;

FIGURE 6 is an illustration of a Graphical User Interface for providing user access to the contents of the customer care database;

FIGURE 7 is a flow chart illustrating relationship management actions taken as a function of the Return-on-Relationship value; and

FIGURE 8 is an illustration of a Graphical User Interface portraying the Return-on- Relationship value information relating to a customer.

Detailed Description

The present invention will be described by referring to drawings showing and describing examples of how the invention can be made and used. In these drawings the same reference characters are used through the several views to indicate like or corresponding parts.

FIGURE 1 is a block diagram of customer care system 100 coupled to a telephony communications system. Customarily, a customer care system is used by the customers to find answers to questions - such as technical support, billing inquiries, or orders.

The customer care system with other customer interaction sources involving marketing, sales, and service, however, can provide additional information that in turn can be used to improve customer service, such as turn-around time, and routing specific questions to designated customer care providers. The information provided is the amount and types of interactions with customers. With this information, trends can be developed as to effectiveness of the resources provided, and the sophistication of the customers. But the amount of information can become overwhelming to develop a useful analysis, and indeed, can take extensive periods of time to arrive at a conclusion that is no longer useful in view of the time delay.

The return-on-relationship ("RoR") metric, or value, discussed below in detail, takes into account the desired customer interaction information in a readily-understandable metric by personnel providing the customer care. Further, this metric provides managerial staff a more illuminating indicator to gauge the effectiveness of the business rules developed for customers or sets of customers.

Referring to FIGURE 1, the customer care system 100 has endpoints, or terminals, 104a through 104« and 106a through lOβn, where n is a value that indicates the upper limit of terminals that can be implemented in view of the particular customer care system hardware-architecture deployed. The customer care system 100 is coupled to a data network 108. In most instances, a communications gateway 110 provides the communications interface between such systems. The data network 108 is coupled to terminals 112a through 112n. Terminals 104a through lO n, 106a through 106n, and 112a through 112n are capable of performing voice or other audio communications over a packet-based or message-based data network 114. As used herein, the term "telephony communications" refers to the transmission and receipt of audio signals, or sounds (for example, voice, DTMF, or other audio signals) between different points in a system. It should be noted that the system can deploy wireline, wireless, optic fiber, or other links permitting such transmission and receipt of audio signals.

Terminals 104a through 104«, 106a through lOβn, and 112a through 112n maybe computer-based systems having speech capability or maybe telephone units having interfaces to the data network 114. Further, as illustrated in FIGURE 1, terminals 106a through 106« are coupled to the data network 114 through a Private Branch Exchange ("PBX") 116 and a PBX gateway 118. Also, terminals 112a through 112n are coupled to the data network 114 by a communications network 108 and communications gateway 110. The communications network can be a Public Switched Telephone Network ("PSTN"), or other types of communications networks.

As shown in FIGURE 1, telephony communications can occur between any two or more terminals over the data network 114. The data network 114 may be provided as, by example, a local area network ("LAN"), metropolitan area network ("MAN"), a wide-area network ("WAN"), a private network such as an Intranet, and public network such as the Internet.

More generally, as used herein, a "data network" is any communications link that utilizes message-based or packet-based communications, hi one embodiment, the data network 114 communicates according to the Internet Protocol ("IP"), which is one of the protocols on which the Internet is based. The IP protocol is a standard describing software that keeps track of the Internet's addresses for different nodes, routes outgoing messages, and recognizes incoming messages. The data network 114 may include a solo network or link, or multiple networks or links, which can be coupled through gateways, routers, and the like. It should be noted that data network 114 could also have several geographically dispersed linked-data networks such as LAN, which are present in a business environment.

As shown in FIGURE 1, a connection manager 120 is coupled to the data network 114. The connection manager acts to manage telephony communications (for example, call setup, processing, and termination) between or among the terminals 104a through 104n, 106a through 106n, and 112a through 112n. Remote gateway 122 provides secure remote access between remote servers to a server/client 124. By example, the remote gateway 122 may allow electronic data interfacing between the server/client 124 and a remote system via the data network 114.

Server/client 124 provides service management support applications accessible over the data network 114. Server/client 124 can be composed of a network of computer platforms tunning systems and business operations. Examples of SMS applications that may be executed, either wholly or in part, on server/client 124 are workflow rules, managing and reporting functions, and metric threshold alarms.

A management system 126 can be accessible by the connection manager 120 through the data network 114 to determine available systems bandwidth, and other usage policy for telephony communications, over the data network 114 to control the quality of service ("QoS") on the data network 114. Additionally, management system 126 maybe coupled to the data network 114 for monitoring desired characteristics and conditions of one or more portions of the data network 114. The characteristics and conditions monitored may include packet delays, jitter, and packet losses. Packet delay refers to a delay experienced in transmission due to high traffic or other conditions. Packet loss refers to the percentage loss of packets. Jitter refers to variations in the delay of different packets in the same transmission. Jitter may contribute to delay on a network link since receiving platforms need to buffer the received data packets to take into account the different delays of packets.

Although only one connection manager 120, management system 126, server/client 124, and remote gateway 122 are illustrated, it should be noted that multiple connection managers, routers and policy servers may be coupled to the data network, as well as additional network resources. In such a configuration, each of the multiple connection managers may be responsible for managing call requests from a predetermined group of terminals, and each policy server may be responsible for maintaining usage policy and available bandwidth for different portions of the data network 114. For example, multiple network monitors may be located to enable monitoring of characteristics and conditions of different portions of the community data network 114. A connection manager, policy server, and network monitor may be implemented on separate platforms or in a platform including some or all of the aforementioned components.

As another example, the customer care system infrastructure may be provided as an Automatic Call Distribution ("ACD") center, described in U.S. Patent No. 5,987,115, issued November 16, 1999, to Petrunka et al., which is incorporated herein by reference. Such infrastructures may be purchased as a Symposium™ Call Center product available from Nortel Networks, Limited, of Ontario, Canada.

FIGURE 2 is a block diagram of customer care services sought to be provided through a customer care system 100 (FIGURE 1). Generally, FIGURE 2 illustrates the variety of "facing" contacts with a customer. As provided herein, facing activity with a customer allows the accumulation of metrics to provide an outward analysis and development aspects of a customer relationship.

As shown in FIGURE 2, customer contact with a customer care system 100 may come through various channels. Customer care system 100 provides customer handling activities such as, but not limited to, provision of products and services, repair, customer support, and billing.

Inquiries can be made by mail 142, voice mail 143, facsimile transmission 144, telephony 146, or videophone 148. Direct access inquiries can be made via a terminal 102 by e-mail, by interaction with a terminal (for example, a browser to access the World Wide Web 149, or to send e-mail 151 messaging through a browser or other terminal application), or by videophone 148. These direct access inquiries are capable of being provided through terminals 104a through 104n, 106a through 106«, and 112a through 112n, as dictated by the technology or technologies deployed in these terminal devices. A component of customer care is monitoring the metrics of the facing with customers. Some of the metrics considered are call statistics, such as how many calls were answered, abandoned or disconnected during a specific time period, as well as the average time it took to answer a call. These statistics are used in managing customer service levels. In general, various components may have been used to provide customer service; however, these components are generally insufficient in themselves to provide the level of service customers expect and demand. That is, sufficiently-comprehensive customer interface data is considered in the analysis of the customer relationship, including service outcomes from the customer care system 100. This customer feedback provides effective customer-care routing decisions, and provides measures for the adequacy of the customer care system staff to effect the quality of service desired by a customer.

For example, by determining when call volume is heaviest, staff can be added for example, by increasing the number of terminals 104 (FIGURE 1), or by adding an overflow group to meet the increase. Another component of customer care is Call Categorization that allows the entry of a numeric code at the completion of a call indicating business referrals, advertising or promotions results, or type of problem reported. This information allows focus on beneficial areas. Also, increasing call handling efficiency and equitable call distribution can have an immediate effect on customer relations and staff productivity. According to industry standards, equitable distribution of calls can increase productivity between 20% and 40%, . which can have an immediate impact on customer relations. And with more calls handled in less time, additional services can be provided and more sales generated with an existing customer care system.

An information component that aids in call handling efficiency is Calling Line ID ("CLID") information, which is passed directly to the person taking the call. CLID information can also be used in conjunction with a "screen pop" application to bring the customer record from your company database right to the computer screen to make order taking and verification faster and easier.

A further component is an Interactive Voice Response ("IVR") system, which may be deployed to aid in routing customer telephony requests. Such routing may be provided by voice menus that aides in determining the skill level of the agent to field the call.

FIGURE 3 is a block diagram illustrating aspects of service relationships. These aspects provide further customer data sources useful in relationship analysis. Customer handling 170 is an important service area in that not only is it the 'lifeline' through which customers order services, raise problems and inquiries, it is also a channel through which customers with some of the more complex services can view the performance of their services. This area is responsible for managing contacts between an organization and customers. This maintains a framework of common dialogues used to handle orders, resolve customer problems and complaints on aspects of service. Many of the processes in this area form a common 'front end' to the underlying areas 172 through 184.

Marketing operations 172 run marketing programs in response to market plans, forecasts or significant events. This is closely related to customer handling, primarily because it forms one of the main channels to the market place. Although other aspects of marketing products and services such as planning, forecasting and market analysis are considered to be part of the business management layer, the resultant outputs from these processes are clearly linked to the service management function. Sales handling 174 manages the proactive selling activities (those activities relating to customer contact) across the broad spectrum of customer segments, from individuals to corporate customers. The function carried out under the banner of 'sales handling' help maximize potential sales by capturing and managing information to ensure that customers who meet promotion criteria are offered appropriate products and services.

Order handling 176 covers aspects of handling an order. An order can be for a product or service. Order handling begins by capturing order details and interpreting customer needs into product and service terms. Call scripts support the customer dialogue and guide the call center agent to provide an appropriate solution, including timescales and cost. A work plan is produced and used to manage order implementation.

Service maintenance 178 controls actions on customer-reported problems and organization-related problems. The main aspects include coordinating the resolution of problems that might arise, for example, due to the organization not being able to provide the product or service to the customer. Interruptions in service or product delivery provision may initially be identified by product or service surveillance, or be reported by a customer. Customers affected by a planned interruption are identified so that service interruptions can be minimized by providing an alternative product or service.

Service monitoring 180 is used to monitor customer performance and provides information to support forecasting activities by monitoring growth and usage patterns. Billing 182 is an important aspect of service management, not only from a commercial perspective of being able to offer innovative product pricing, but also because a 'bill' is one of the few documents that customers read thoroughly. Thus, billing errors have a direct impact on customer perception of the organization. The primary functions of this vital activity are to request payment from all customers and to perform any subsequent payment follow-up actions. The billing cycle includes data collection, charge raising, pricing, invoicing, receipting, credit management and fraud monitoring. It also includes payments to customers in the form of refunds and compensation.

The product and service handling function 184 deals with the introduction, removal and changes to products and services offered by the organization to its customers. This concerns those aspects of product and service management that affect customers and their product or service instances. This function has strong links with marketing and sales since it is through these areas that customers who could benefit from new products and services can be identified and proactively informed. Further, a customer may enhance the handling function by providing input to the merchant or service provider regarding specific handling instructions.

This function also provides the "back end" of the product or service launch process, that is, the part that impacts customers. Other aspects of products and services management, such as planning, portfolio management, and product development that lie within the business management function may be linked to this function.

Providing effective and efficient service management requires access to the correct information at the appropriate time that is contextually relevant to the current customer contact. In this regard, evaluation of the customer relationship is beyond an inward projection, which is a view of the expenses made on the customer compared to the monetary return on that customer associated with those expenses. In this regard, the value of customer relationship would not be considered.

Evaluation of the customer relationship beyond rudimentary profits-to-expense relationships serves to encompass broader business objectives for a customer relationship. For example, it may be more beneficial to maintain a non-profitable, or negative cash flow, customer relationship when other business objectives can be obtained by the associated goodwill received by affiliation or alliances with that customer. -Accordingly, in view of the developmental expense for customer portfolios, other outward, long-term factors are considered for developing the relationship. Accordingly, with respect to FIGURE 3, the basic types of customer facing transactions take place with marketing, sales, service, and support transactions: field marketing, sales, service and support (that is, the organization sends people to the customer premises); face-to-face marketing, sales, service and support (that is, the customer comes to a storefront belonging to the organization); customer care system marketing, sales, service and support (that is, the customer interacts with the organization via inbound or outbound call center); and self-service marketing, sales, service, and support (that is, customer access of published company information, such as through the Internet.

The capability to link activities to transaction outcomes across these customer facing transactions, and provide a total cost-benefit analysis for the customer relationship including hard (money) and soft criteria is provided. An effective relationship measure provides further abilities. First, the ability to apply consistent rules or guidelines based on the cost- benefit analysis to be used by every person and every system that interfaces with the customer. Second, the ability to measure the performance of people and systems in terms of relationship outcomes rather than in terms of activities - for example, rating agents on their success rate in completing upsells rather than on the amount of time they spent with the customer.

FIGURE 4 is a flow chart that illustrates the generation and implementation of the Return-on-Relationship value engine 400. This value takes into consideration the various facing-data components illustrated in FIGURE 2, and provides a numerical representation of this data in an updated-format that does not require the time and expense associated with manually evaluating the volumes of generated data through customer interaction. The RoR value can reside in components of the customer care system 100 (FIGURE 2), which is discussed above in detail.

The term "customer relationship" means a series of interactions, or customer "facings" between Customer Service Representatives (automated or otherwise) and the customers. Objectives for each interaction are determined by a relationship plan for the customer. A relationship plan generally contains expected values for the relationship variables, alarms that will be issued if the relationship goes out of bounds, business rules, which can be implemented as scripts and workflow in the customer care system, routing rules implemented in the call center, service JNR, and self-service Internet applications. The reporting system measures the successful completion and failure to complete relationship objectives (that is, achieving expected values of the relationship variables and completion of business rules). The reporting system provides information used to evaluate either the relationship or the people who work on the relationships. See attached chart. This needs to be incorporated into the description.

Generally, Customer Relationship performance is the sum of the outcomes of the interactions across all the Customer Service Representatives engaged with the customer. On the other hand, Customer Service Representative performance is the sum of outcomes of the interactions across the customers that a Customer Service Representative engages.

Collecting and distilling customer interaction data provides greater adaptation to the measure of the relationship. That is, customer values may not be measured based on the same criteria. For example, non-profit businesses, such as crisis care businesses, do not focus on monetary return from a person seeking assistance, but the effectiveness of the crisis care provided to resolve the crisis. In contrast, for-profit businesses have an emphasis on establishing a revenue stream. Nevertheless, in the for-profit scenario, other criteria are considered for evaluating the value of a customer relationship. Referring to FIGURE 4, the routine 400 for generating and implementing the RoR value is illustrated. For a customer, the RoR variables are designated at 402. In this regard, the RoR is represented as a weighted-variable value as follows:

The RoR Variable, is a field containing a value associated to the variable. The

RoR_Weight_i- is an importance factor associated with the variable. A simplified example of variables applicable to the RoR value is:

Other variables can be provided as information technologies increase the availability of such customer information. The nature of the variables are those quantities that can be captured through telephony and Internet techniques, as well as through computer interaction. For example, Internet web sites serve as information capture tools as well as a service delivery tool. The web site allows customers to purchase new products and services, search for answers to problems, collect information about the current promotions, and dialog with company representatives using email, chat or call-me. The designation of the variables implemented in the RoR value 402 can be provided in a default format, and for selection through a Graphical User Interface ("GUI") by a customer care system administrator.

As a basic example, if the customer care system 100 is to be used by a customer for support purposes, the variables concerning support would be selected:

V₉ = Number_Problems_Solved_Self_Help V₁₀ = Number_Problems_Solved_Agent V_u = Number_Problems_Solved_Field_Visit

With respect to the weighting factor, a customer having the ability to serve itself requires less overhead and cost than one needing greater attention. Similar for Agent solved problems as compared to field visit costs. To capture these values, the weighting factors can be set as follows:

RoR_Weight₉ = 100 RoR_Weight₁₀ = 10 RoR_Weight_π = 1

Suppose two customers have the same type of service plan. Also suppose that each customer reports five (5) problems. Customer A resolved three problems by itself, and two problems with the customer care system agent. Customer B did not solve any problems on the support web site (that is, by itself), two problems were resolved with agent help, and the remaimng three required three field visits. Thus, cumulative RoR indices for each of the customers are:

RoR Value for Customer A = (100)(3) + (10)(2) + (1)(0) = 320 RoR Value for Customer B = (100)(0) + (10)(2) + (1)(3) = 23

In this simple example, the qualitative values for a customer are considered if the user decides that the support for a customer is proportional to the sales revenue provided.

In step 404, business rules are provided for association with the RoR value. Initial business rules can be based upon historical values associated with the customer. Business rules are carried out in various manners such as in scripts and notes to be read by customer service representatives, as well as automated rules carried out by the customer care mechanism, and request routing systems. An example of a business rule is the manner a customer is to be addressed. Business rules concern the specific interactions mandated for a customer, such as addressing individuals of an organization as "Mr. Smith," instead of the more familiar "Mike," in correspondence to be sent via overnight mail instead of first class mail, and the like.

In step 406, workflow rules are associated with the routing and prioritization for customer handling. For example, achievement of a high RoR threshold provides greater attention and privileges as compared to a lower RoR threshold. In this regard, when a request comes in to the customer care system 100 (FIGURE 1), the customer is identified, and the CRM database that contains the workflow rules, and business rules, and the request is routed with the RoR value and specific routing instructions.

In step 408, customer interaction data is captured, and stored in the customer care system 100 {see FIGURE 1) in a customer relationship management ("CRM") database. Again, the storage of these interaction data values can be made locally, in that the access to the database is "direct," or remotely, in that access is made through a communications conduit, such as over a WAN, or the Internet.

At step 410, a decision is made whether to update the RoR value 200 for a customer, a grouping of customers, or the entire database of customers. RoR value updates may be triggered as customer interaction data is received, on the occurrence of specified events, or as a scheduled event. Customer care systems implementing CPUs operating in the Giga-Hertz range have the capacity to update the RoR values for a customer as data is received and stored in the CRM database. Preferably, the RoR values are updated sufficiently frequent to allow sufficient relationship actions to take place. For example, if the amount of change of an RoR value as compared against a Target RoR value is excessive, attention should be provided sooner rather than later to evaluate the cause for the deviation and to take corrective action to maintain the relationship.

As a specified event, upper and lower threshold values can be implemented to base update decisions. For example, upper and lower thresholds can be defined for each variable implemented for the RoR value in step 402, and each relationship plan, that will trigger the workflow rules (alarms and business rules) to execute an update upon the crossing of the upper or lower threshold. Upon deciding to update the RoR at step 410, the RoR value for the customer is updated at step 412. After step 412, or if the RoR is not to be updated as decided at step 410, the routine returns to step 408 to continue capture of customer interaction data.

FIGURE 5 is a functional block diagram illustrating the RoR engine 500. As shown, the RoR engine 500 has customer interfaces provided by customer touchpoints 502. Data coordination for the RoR engine 500 is provided by a workflow module 504. A customer interaction database 506 is coupled to the workflow module 504 and the RoR analytics module 508. As directed, the contents of the customer interaction database 506 are provided through the reporting module 510. The customer touchpoints 502 concern the customer interface, and are provided through a variety of manners. As shown, the customer touchpoints are generally provided by data access touchpoints 502a, front office applications 502b, and back office applications 502c. It should be noted that further touchpoints can be provided as the technology advances and variety of touchpoints increases. As shown, the data access touchpoints 502a can be provided by a contact center, interactive voice response, Internet servers, direct sales, marketing and support, and point- of-sale terminals. With respect to contact centers, a suitable software application tool is the Account Manager application, which works with the ClearSupport® product version 4.5, available from Clarify, Inc., a Nortel Networks Company, of San Jose, California. The Account Manager application, in conjunction with the call center infrastructure {see FIGURE 1), serves as a data collection device for maintaining customer information for analysis access. Another aspect of the data access touchpoints 502a is an Interactive Voice Response ("IVR") structure that provides customer call records such as caller id, call duration, and similar metrics. A suitable IVR system is available from Periphonics Corporation, a Nortel Networks Company, of Bohemia, New York, under the

Periphonics® Voice Processing Series ("VPS") model 7000, 9000, 7500, or 9500. The Internet server of the data access touchpoints 502a provides information to consumers, as well as "chat" or customer interaction capabilities with a customer. Interactions of this nature can be similarly logged for providing comprehensive data for generation of a RoR value.

Another data access touchpoint 502a is provided through the Point-Of-Sale technology generally associated with retail purchasing. That is, data is available at a goods or services site with respect to inventory and general satisfaction by a customer. The opportunity to include this component in the RoR value provides further depth to the interpretation of data associated with a customer.

The front office applications 502b relate to the activity within an organization relating to a customer. A suitable front office application is available as the Clarify® FrontOffice and Clarify® eFrontOffice software application tools, from Clarify, Inc., a Nortel Networks Company, of San Jose, California.

As shown, the data is exchanged between the components 502a, 502b, and 502c to provide consistency for customer data. The back office applications 502c relate to order filling activity, and activities relating to customer satisfaction. Generally, front office processes are communicatively-coupled to back office processes to allow carry over of related data. For example, as customer representatives add a customer site, change a customer's contact information, or install new products, the information is provided to the back office accounting, shipping, and service billing systems. This allows maintenance of customer information across the customer care system of a business. The workflow module 504 provides the coordination of the data flow, and its storage in the Customer Interaction Database 506. From the Customer Interaction database 506, the RoR analytics module 508 generates RoR values associated with the stored customer data, as illustrated in detail in FIGURE 4 and described herein in detail. The RoR values generated by the RoR analytics module are stored in the Customer Interaction Database 506. The contents of the database can be reported through the reporting module 510 in soft- or hard-copy formats for review and decision making as necessary.

The customer interaction database 506 has a general schema structure as follows:

Fields of the Field Type would have the equivalent Data Type and Length. The table layout of the customer database is provided as follows:

Table call_record := A row is inserted into this table for every incoming call, at the time that the Interactive Voice Response ("IVR") passes the call to an agent or the call is abandoned, or completed within the JNR of the data access touchpoints 502a. This table has been created to provide data persistence beyond the time-frame usually associated with data that is stored in the Periphonics database.

call d := A unique identifier of the call passed to the RoR engine 500. This attribute is used as a unique index for the table.

ani :— The identifier of the calling number.

dnis: — The identifier of the called number.

token _ids_list := A list of token names whose values are collected by the JNR script.

token_yalue_list := A list of token values that corresponds to the token names list.

ivrjime := Total IVR time devoted to the call (this data will be ignored in the summarization processing unless the call is either abandoned in the IVR or the transaction is completed within the IVR).

abandoned _in_queuejlag := Flag value is zero if the call was not abandoned in the queue, a value of one is assigned if the call was abandoned in the queue.

abandoned _in_ivrjlag := Flag value is zero if the call was not abandoned in the IVR, a value of one is assigned if the call was abandoned in the JNR.

transaction_completed_in_ivr_flag :== Flag value is zero if the transaction was not completed in the IVR, a value of one is assigned if the transaction was completed in the IVR.

date_time_of_call := This is a date/time stamp that captures the system date/time that the row was inserted into the table.

call_center_id := An identifier that defines a particular customer care system.

pbx_id := An identifier that defines a particular pbx within a call center.

agent _id := The login for the customer care system server. account _id := An identifier of the calling business organization as picked up in the IVR. If this column is not null it should be the same as the bus_org.id within the database.

Table bus_org := This table contains a row for every business organization, or customer, within the database.

id := This is an identifier that defines the business organization; serves as a unique table index.

customer _since_date := The date when the business organization was acknowledged as a customer.

account jngr d := An identifier that defines the particular account manager that is assigned to a particular business organization. Each business organization is assigned to an account manager.

Table ror ier := This table will contain a row for each class of customer value used in the RoR value calculations. This is a constant designating customer service tiers, such as "Gold", "Silver", "Bronze" and "discourage."

id := This is an identifier that defines the business organization, or customer, and is used as a unique table index.

name := A common name for the tier.

ror_index_boundary := A minimum RoR index value that defines a given tier level.

Table agentjype := This table contains a row for each type of agent. Each agentjype represents an intelligent processor. An agentjype may represent automated or human agents.

id '.= This is an identifier that defines a particular agent type, and is used as a unique table index.

description := Descriptive information relating to the agentjype. Table agent := An individual instantiation of an agentjype.

id := This is an identifier that defines the agent. In the case of a human agent, it is the agent login for the customer care system, and is an index for the table.

name := The name of the agent.

Table media Jype := This table contains a row for each media type. A media type is a physical communication channel. Examples are telephony, fax, and Internet.

id := This is an identifier that defines the media type index for the table.

description := Descriptive information relating to the media type.

Table period Jype := This table contains a row for each period type. A period type is an identifier that distinguishes one series of periods from another. The distinction may be based on period length, such as week, month, quarter, and/or may be based on when the series starts.

id := This is an identifier that defines the period type, and is an index for the table.

description := Descriptive information regarding the period type

Table ror alcjperiod := This table identifies the reporting periods that will be used.

period ium := This is an identifier that defines the reporting period for a specific period type. Each period type has its own series of numbers; each series should start with number one.

period_end_date := Date that defines the ending boundary for the period. It is included in the period.

expected _cust ife := Value is initially copied from ror_default.expected_custJife at the time the period summary batch is run. This attribute preserves the then- current value of that attribute for historical purposes. pct_margin_on_sales := Value is initially copied from ror_default.pct_margin_on_sales at the time the period summary batch is run. This attribute preserves the then-current value of that attribute for historical purposes.

ave_cost sales_visit := Value is initially copied from ror_default. ave_cost_salesχyisit at the time the period summary batch is run. This attribute preserves the then-current value of that attribute for historical purposes.

ave_costjperJield_service_yisit := Value is initially copied from ror_default.ave_cost_perJield_service_yisit at the time the period summary batch is run. This attribute preserves the then-current value of that attribute for historical purposes.

num_sales_yisitsjper_period := Value is initially copied from rorjlefault.num_sales !isits_perj)eriod at the time the period summary batch is run. This attribute preserves the then-current value of that attribute for historical purposes.

num_service_yisits_per_period :— Value is initial copied from ror_default.num_service_yisits_per_period at the time the period summary batch is run. This attribute preserves the then-current value of that attribute for historical purposes.

email _cost := Value is initially copied from ror_default.emaϊl_cost at the time the period summary batch is run. This attribute preserves the then-current value of that attribute for historical purposes.

ivr_cost := Value is initially copied from ror_defaults.ivr_cost at the time the period summary batch is run. This attribute preserves the then-current value of that attribute for historical purposes.

webJaq_cost := Value is initially copied from ror_defaults.webJaq_cost determined at the time the period summary batch is run. This attribute preserves the then-current value of that attribute for historical purposes. web_self_serv_cost := Value is initially copied from ror_defaults.web_self_serv_cost at the time the period summary batch is run. This attribute preserves the then-current value of that attribute for historical purposes.

web_eorder_cost := Value is initially copied from ror_defaults.web_eorder_cost at the time the period summary batch is run. This attribute preserves the then-current value of that attribute for historical purposes.

Table ror_default := This table contains values that will be used in the calculation of the RoR Index when flow-of-business data is not available. It contains one row per period type. The period Jype.id is represented as a foreign key in this table and is a unique index.

expected ust Jife := An expression of the length of time a business organization is expected to maintain its relationship as a customer.

pct_margin >n_sales := The ratio of profit on a sale divided by the gross revenue of the sale.

ave ost_sales_visit := The average cost incurred to pay a sales visit to a customer.

ave ost_perJield_service isit := The average cost incurred to pay a service visit to a customer.

num_sales isitsjper >eriod := The typical number of sales visits to each specific customer in a given period.

num_service_yisits_per )eriod := The typical number of service visits to each specific customer in a given period.

email ost := The typical cost to respond to an email.

ivr_cost := The typical cost to process a call through the JNR.

webJaq_cost := The typical cost to process a web frequently asked question ("FAQ").

webjselfjerv ost := The typical cost to process a self-service web application. Table period _summary := The stored data of the customer interaction database 506 is provided in user-readable format through the Reporting Module 510. The reports can be reviewed through a relationship monitor Graphical User Interface ("GUI") such as that illustrated in FIGURE 6. FIGURE 6 is an illustration of a Graphical User Interface 600 for providing user access to the contents of a customer care database, which shows the return-on-relationship view relating to the relationship plan template 602 field, the customer administrator field 604, and the relationship plan description field 606 for the customer. Also shown is the relationship goals field 608 with responsible agent field 610, implementation date field 612, and status field 614. Also shown is the relationship rules field 616 for the customer, which are generally designated by the relationship plan template.

For each reporting period, RoR information is collected and summarized on each customer. The report table portion of the customer interaction database 506 stores summaries, by period and customer, for all elements required for the RoR Index period calculations, except for the actual Agent time and the number of Agent/customer sessions. That information is stored in the agent _cost_summary table. The unique index for this table is constructed from the combination of bus _org.id and ror_calc_period.id, both of which are represented as foreign keys in this table. A relation also exists for ror tier through the presence of ror tier. id as a foreign key to this table. This relationship can be set after the rorjndex alue is computed and resolved to the proper row in the rorjier by comparisons to the values of rorjier. ror Jndex oundary.

The fields provided for the report summaries are:

rorJndexχyalue := The computed value of the RoR Index for a given customer for a given reporting period;

tierjiame := This is initially set to the value of rorjier. tier jiame at the time the period summary row was created. This value provides an historical "snapshot" of the tier to which the bus_org was assigned for the period;

total_period_revenue := The sum of all revenues accruing to the designated period. This value is determined from the orders, contracts, and other revenue-based transactions from the database 506. A customer is permitted to override this value through customization so that revenue determined from an external data source may be used. As an example, the customer may wish to reflect the revenue from a billing/accounting system.

total jion gentjperiod ost := The total sum of expenses - excluding agent costs - accruing to the period. This value is computed from data within the database 506.

ror ndexjoundary := This is set to the value of rorjier. ror Jndexjboundary at the time that the period summary row is created. It provides an historical "snapshot" of the rorjndexjoundary that was in effect for the period.

num_sales_visits :— The number of sales visits that are made to a customer for the reporting period.

num_service_visits := The number of service visits that are made to the customer for the reporting period.

period_sales_goods := The revenue amount generated by sales of goods for the period.

period _sales_services := The revenue amount generated by sales of services for the period.

cost_of_sales isits := The sales visit costs made to a customer for the reporting period.

cost f ervice isits := The service visit costs made to a customer for the reporting period. This information can be collected from Clarify® ClearLogistics and a standardized cost-price listing; otherwise the value can be computed by multiplying ror_default.ave_costj>erJield_serviceχyisit by the number of service visits.

cost_of_goods old := The cost of goods sold to a customer for the reporting period. This information can be collected from Clarify® ClearLogistics and a standardized cost-price listing; otherwise the value can be computed by multiplying ror_default.pctjnargin_on_sales by the value of goods sold for the reporting period.

num_calls_queue_abandoned := Computed from the call ecord rows for this customer for the reporting period, where call ecord.abandonedJn_queueJlag is equal to one.

num_callsJvr_abandoned := Computed from the cάlljrecord rows for this customer for the reporting period, where call ecord.abandonedjnjvr lag is equal to one.

total vrJime_consumed := Computed from the call record rows for this customer for the reporting period.

territory jd := This is the identifier of the sales territory assigned to the customer for the period.

account jngr d := This is the identifier of the management responsibility for the sales team assigned to a customer.

Table agent _cost_summary := For each reporting period, RoR information is collected and summarized for each of the customers. This table stores agent cost information summaries, by period, customer, agent, and media type required for the RoR Index period calculations. It has a unique index that is the composite of bus rg.id, ror alcjperiod.id and agent.id.

agent _cost := Summary of agent time devoted to sales, multiplied by the value of agent Jype_rate.cost_per_unitJime plus agent time devoted to service, and multiplied by the value of agent Jype_rate.cost_per ιnitJime.

num_agent essions := Summary of agent sessions information.

total _sales_agentJimeJor_period := Summary of agent time devoted to sales. In the absence of agent time from the database 506, the value of agent Jype ate.time_spent is used.

total _service ιgentJimeJor_period := Summary of agent time devoted to service. In the absence of agent time, the value of agent Jype_rate.timejspent is used. Table rate Jype := Each rate type defines the activity or service that will be furnished by an agent. As an example, if a human agent provides sales information over the telephone, that would be an instance of the rate type "sales". If the agent provides support, then the rate type would be "support".

id := This is an identifier that defines the rate type, and is an index for the table.

description := Descriptive information regarding the rate type.

Table agent Jype jnedia_r ate := Each agent Jype jnedia ate contains information regarding costs for a given agent type, engaged in a specific type of activity, over a specific medium. Costs are expressed in both currency per unit of time and also the amount of time typically spent by an agent engaged in a specific activity.

cost >er_unit_ofJime := This is the amount or quantity of a given currency that it costs to provide a unit-of-agent time.

default Jime pent := The value assigned to this column represents the number of units of agent time that is typically involved in providing the service using the given medium.

Table agent Jypejnediajeriod rate := This table preserves the agent Jype jnediajrates for a specific RoR calculation period.

cost_perjιnit_ofJime := Value is copied from the agent Jype jnediajate field. The value of this field is determined at the time the period summary batch is run. This attribute preserves the then-current value of that attribute for historical purposes.

default Jime pent := Value is copied from agent Jype jnediajate. The value of this field is determined at the time the period summary batch is run. This attribute preserves the then-current value of that attribute for historical purposes.

Table tier_norm_calc := This table contains a row for each combination of agentjype, rorjier, media Jype, and ror_calc_period: All the values are calculated at the time that the period calculations are performed. threshold Jιigh_sessions := Defines the highest number of sessions that are considered to be normal usage for a customer in a given RoR tier, being serviced by a given agent type, using a given medium, for a given RoR calculation period.

threshold ow essions := Defines the lowest number of sessions that are considered to be normal usage for a customer in a given RoR tier, being serviced by a given agent type, using a given medium, for a given RoR calculation period.

median jsessions ount := Defines the median average number of sessions for a customer in a given RoR tier, being serviced by a given agent type, using a given medium, for a given RoR calculation period.

meanjsessions ount := Defines the mean average number of sessions for a customer in a given RoR tier, being serviced by a given agent type, using a given medium, for a given RoR calculation period.

Table currency := This table contains a row for each currency in which a cost may be denominated. id := This is an identifier that defines the currency, and is an index for the table.

description := Descriptive information regarding the currency.

FIGURE 7 is a flow chart illustrating relationship management actions taken as a function of the RoR value. The database structure 500 of FIGURE 5 provides the progressive analysis and management tools relating to a customer relationship.

The relationship management flow chart 700 begins with the retrieval of an RoR value associated with a customer 701. The RoR value retrieval can occur on a designated event, such as a customer support or sales request, by contact by a customer with the customer care system 100 {see FIGURE 1), or a value determined through the method illustrated in FIGURE 4. The RoR value can also be retrieved, or re-calculated on request of a system user.

In step 702, the retrieved RoR value is compared with a previous RoR value to determine whether a change has occurred. A result of the comparison is a delta change value, Δ_RoR, which provides a change magnitude. As shown, step 704 determines whether the delta change value, Δ_RoR, comes within a specified threshold that precipitates segmentation action in step 706. Otherwise, the process continues to decision step 712. At step 712, a determination is made whether the RoR value retrieval was precipitated by a customer request, such as a sales call, a support inquiry, an Internet web site access, or the like.

It should be noted that the segmentation step 706 can be facilitated as an automatic function, as a system initiated request to a system administrator having the sufficient privilege authority, or as a function that occurs with the report process.

In the event a change in the RoR value did not occur in step 702, then a determination is made at step 714 whether the RoR value has remained unchanged over a predetermined period of time. If the RoR value has remained unchanged over a predetermined time, then at step 708, another determination is made whether to evaluate the effectiveness of the segmentation associated with the customer.

Effectiveness evaluations may not take place in instances where the customer relationship is in a "discourage" segmentation. If so, then no evaluation takes place and a determination whether the RoR value retrieval was precipitated by a customer takes place at step 712. Also, from step 714, if the RoR value has not remained unchanged, then the determination is made whether the RoR value retrieval was precipitated by a customer at step 712. If in step 704 the delta change value, Δ_RoR, has come within a change threshold, that is, has a sufficient magnitude to warrant adjustment to a customer segmentation, then the determination whether to evaluate the effectiveness of the segmentation is made at step 708. In this instance, an example where segmentation effectiveness would be re-considered is if a large number of customers were transitioned into a specific segmentation group. Upon a determination that the effectiveness of a segment is to be evaluated, a transmit review notification is sent at step 710. The notification can be transmitted in numerous methods, such as through an e-mail, "pop-up" window on a monitor screen accessible through the network, or generation of a customer relationship report of customer interaction statistics. A further aspect is retrieval of the RoR value initiated by the service request of a customer. In this regard, the RoR value retrieval is queried at step 712 as whether it was precipitated by a customer request. If so, at step 715, the customer request is prioritized with respect to the RoR value and processed according to customer care system procedures. If not, processing then proceeds to step 716 to exit.

As referred from step 710, FIGURE 8 is an illustration of a GUI 800 portraying the RoR value information relating to a customer. As illustrated, the review notification is provided through the Relationship Alerts window 802, and alert indicator 804 for alerting a user to the existence of a new change in RoR status for prompting review.

The foregoing illustrates techniques for providing a customer care system implementing a customer relationship mechanism, which relates to the development of a return-on-relationship value to characterize the interaction data provided through the course of the customer relationship. It is to be understood, of course, that the foregoing description relates to a preferred embodiment. Numerous modifications and alterations thereof can be made without departing from the scope and spirit of the invention as set forth in the appended claims.

Claims

What is Claimed is: Apparatus for generating an assessment of a customer relationship comprising: a customer interaction database that receives a plurality of customer interaction data as customer service-related interactions occur sufficient to provide a timely representation of customer interactions on request; and a processor programmed to generate a return-on-relationship value characterizing said plurality of customer interaction data to base a relationship response.

2. The apparatus of Claim 1 wherein said relationship response is an announcement of said return-on-relationship value.

3. The apparatus of Claim 2 wherein said announcement is a representation of said return-on-relationship value in a Graphic User Interface.

4. The apparatus of Claim 1 wherein said customer interaction data is a data subset relating to an objective of a business type.

5. The apparatus of Claim 1 further comprising: a report module executable by said processor to issue an alert upon a transition of said return-on-relationship value beyond predetermined thresholds.

6. The apparatus of Claim 5 wherein said relationship response is an announcement of said return-on-relationship value.

7. The apparatus of Claim 6 wherein said announcement is a representation of said return-on-relationship value in a Graphic User Interface.

8. The apparatus of Claim 7 wherein said customer interaction data is a data subset relating to an objective of a business type.

9. AAi method of assessing a customer relationship comprising:

(a) storing a plurality of user interaction data associated with at least one of a plurality of customers in a customer care database;

( ) generating a return-on-relationship index that characterizes the plurality of user interaction data; and

(c) determining an action in response to the return-on-relationship index.

10. The method of Claim 9 further comprises : defining with the at least one of a plurality of customers a workflow rule set associated with the return-on-relationship index.

11. An apparatus for assessing a customer relationship comprising: means for storing a plurality of user interaction data associated with at least one of a plurality of customers in a customer care database; means for generating a return-on-relationship index that characterizes said plurality of user interaction data; and means for determining an action in response to said return-on-relationship index.

12. The method of Claim 9 further comprises: means for generating with said at least one of a plurality of customers a workflow rule set associated with said return-on-relationship index.

13. A machine implemented method for generating an assessment of a customer relationship comprising: creating a customer interaction database for receiving a plurality of customer interaction data as customer service-related interactions occur; receiving a plurality of customer interaction data into the database; generating a return-on-relationship value characterizing the plurality of customer interaction data.

14. A method for maintaining a customer relationship of claim 13, further comprising: generating a response to the customer based at least in part on a return-on- relationship value.

15. A method for maintaining a customer relationship of claim 13 , further comprising: determining a potential response to the customer; generating a predicted return-on-relationship value for the potential response based upon the plurality of customer interaction data.

16. The method of Claim 14 wherein the relationship response is an announcement of the return-on-relationship value.

17. The method of Claim 14 wherein the relationship response is an announcement of the return-on-relationship value through a Graphic User Interface.

18. The method of Claim 13 wherein the customer interaction data is a data subset relating to an objective of a business type.

19. The method of Claim 13 further comprising: generating an alert upon a transition of the return-on-relationship value beyond predetermined thresholds.

20. A customer relationship assessment and planning system comprising: means for creating a customer interaction database for receiving a plurality of customer interaction data as customer service-related interactions occur; means for receiving a plurality of customer interaction data into the database; means for generating a return-on-relationship value characterizing the plurality of customer interaction data.

21. A customer relationship assessment and planning system of claim 22 further comprising: means for generating a response to the customer based at least in part on a return- on-relationship value.

22. A customer relationship assessment and planning system of claim 22 further comprising: means for determining a potential response to the customer; means for predicting a return-on-relationship value for the potential response based upon the plurality of customer interaction data.

23. A customer relationship assessment and planning system of claim 23 wherein the relationship response is an announcement of the return-on-relationship value.

24. A customer relationship assessment and planning system of claim 23 wherein the relationship response is an announcement of the return-on-relationship value in a Graphic User Interface.

25. A customer relationship assessment and planning system of claim 22 wherein the customer interaction data is a data subset relating to an objective of a business type.

26. A customer relationship assessment and planning system of claim 22 further comprising: means for generating an alert upon a transition of the return-on-relationship value beyond predetermined thresholds.

27. A customer relationship assessment and planning system of claim 22 further comprising: a distributed computing system.

28. A program storage device readable by machine, tangibly embodying a program instructions set executable by machine to perform a machine-implemented method for generating an assessment of a customer relationship comprising: creating a customer interaction database for receiving a plurality of customer interaction data as customer service-related interactions occur; receiving a plurality of customer interaction data into the database; and generating a return-on-relationship value characterizing the plurality of customer interaction data.

29. A program storage device of claim 30 further mprising stored instructions for: generating a response to the customer based at least in part on a return-on- relationship value.

30. A program storage device of claim 30 further comprising stored instructions for the additional steps of: determining a potential response to the customer; generating a predicted return-on-relationship value for the potential response based upon the plurality of customer interaction data.

31. A program storage device of claim 31 wherein the relationship response is an announcement of the return-on-relationship value.

32. A program storage device of claim 31 wherein the relationship response is an announcement of the return-on-relationship value in a Graphic User Interface.

33. A program storage device of claim 30 wherein the customer interaction data is a data subset relating to an objective of a business type.

34. A program storage device of claim 30 further comprising stored instructions for: generating an alert upon a transition of the return-on-relationship value beyond predetermined thresholds.