Patent Application
20090276286
Customers buy and use a variety of products, services, and systems from vendors or manufacturers. The commercial success of the product, service or system depends on its consumability characteristics. The consumability characteristics are elements associated with the product that shape the customer's experience with the product throughout the product lifecycle. For example, the customer's experiences in finding, purchasing, installing, operating, and maintaining a product are influenced by the consumability characteristics of the product. The consumability characteristics associated with the operation of a product may include the ability of the product to meet the customer needs, efficiency of the product, and the ease of use of the product. For a company to improve its product by increasing the product's consumability, the company must first have a quantitative and actionable understanding of the consumability areas which need improvement. Particularly in complex products, such as software suites and computer systems, obtaining a quantitative and actionable understanding of product areas which need improvement can be difficult.
A method of analyzing the consumability of a product, service, or system includes obtaining customer support records; mapping the customer support records into consumability categories; and generating a description of a distribution of the customer support records within the consumability categories. A computer program product for analyzing a product's consumability includes computer usable program code which aggregates customer service records that contain customer service data; the computer usable program code then maps the customer service records into consumability characteristics and generates a description of a distribution of the customer service records among the plurality of consumability characteristics.
The accompanying drawings illustrate various embodiments of the principles described herein and are a part of the specification. The illustrated embodiments are merely examples and do not limit the scope of the claims.
Throughout the drawings, identical reference numbers designate similar, but not necessarily identical, elements.
As will be appreciated by one skilled in the art, the present invention may be embodied as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, the present invention may take the form of a computer program product on a computer-usable storage medium having computer-usable program code embodied in the medium.
Any suitable computer usable or computer readable medium may be utilized. The computer-usable or computer-readable medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a non-exhaustive list) of the computer-readable medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a transmission media such as those supporting the Internet or an intranet, or a magnetic storage device. Note that the computer-usable or computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory. In the context of this document, a computer-usable or computer-readable medium may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer-usable medium may include a propagated data signal with the computer-usable program code embodied therewith, either in baseband or as part of a carrier wave. The computer usable program code may be transmitted using any appropriate medium, including but not limited to the Internet, wireline, optical fiber cable, RF, etc.
Computer program code for carrying out operations of the present invention may be written in an object oriented programming language such as Java, Smalltalk, C++ or the like. However, the computer program code for carrying out operations of the present invention may also be written in conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
The present invention is described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks
As noted above, customers buy and use a variety of products. Many of these products are supported by the vendor or manufacturer following the purchase. In such cases, when a customer has an issue with a supported product, the customer can access any one of a variety of support mechanisms provided by the vendor or manufacturer. The support mechanisms may include online diagnostic tools, literature provided with the product, a product support telephone hotline, an online chat with a customer representative, e-mail access to customer representatives, or an on-site technician. As the customer interacts with the support mechanisms, a customer support record can be created, which records a variety of information such as the identity of the customer, the type of products they are using, the event which prompted them to contact customer support, the underlying problem with the product, the resolution of the problem, etc.
For a company to improve a product, for example, by eliminating flaws, improving ease of use, increasing efficient or productivity, and/or reducing support costs, the company must first have a quantitative and actionable understanding of the aspects of the product that need improvement. Particularly in complex products, such as software suites and computer systems, obtaining a quantitative and actionable understanding of aspects or areas of the product that need improvement can be difficult.
As used in the specification and appended claims, the term “product” refers broadly to goods, services, systems, support, or other tangible or intangible goods or materials that are offered by a manufacturer or vendor to a customer or consumer. The term “consumability” will be used throughout the specification and appended claims to refer to how well the product suits the purchaser, for example, how easy the product is to use, at various stages throughout the product lifecycle. The product lifecycle may include stages such as the selection, purchase, installation, operation, maintenance, and upgrading of the product.
If a company wants to improve the consumability of their products, it can be helpful to first measure the product consumability of various components, procedures, or features of the product. Product components, procedures or features that are inefficient, difficult to use, or prone to failure can then be targeted for improvement.
A variety of methods could be used to evaluate various aspects of product consumability, including in-house testing and customer surveys. In-house testing can be useful in some areas, but it may be expensive and difficult to simulate the systems and operator actions of the entire consumer base. Surveys can provide some indication that a product is easy or difficult to use. However, surveys can be expensive and may lack the detail necessary to pinpoint problem aspects of or areas within the product.
Support calls can be a valuable and direct source of information about the consumability of the product. When a customer calls technical support, the representative will record information about the customer's problem, such as what the customer was doing when the problem occurred, what product they were using, and what happened that prompted them to call customer support. Consequently support records are a valuable, but often untapped, resource for quantitatively identifying the current consumability of the product in question and, consequently, potential consumability improvements that could be made to the product. A method is needed to derive quantitative and actionable understanding of the consumability of a product from support records.
As used herein an in the appended claims, a hierarchy of consumability characteristics are defined within which the consumability of a product can be evaluated. Consequently, the term “consumability characteristics” will be used to describe the entire universe of a product's characteristics that bear on its consumability. Within “consumability characteristics,” we may define a number of market drivers. “Market drivers” are major consumability characteristics that tend to have an impact on the market for the product. Examples of market drivers may include a positive first use of the product, that the product meets the consumer's needs, that the product enhances consumer productivity, etc. Within each market driver, we may define specific “consumability attributes” of the product that relate to specific market drivers. Finally, within each consumability attribute, we may define specific “consumability criteria.” Consumability criteria are the most detailed aspects of consumability and may correlated to different stages in the lifecycle of the product. With this hierarchy and the defined taxonomy in place, the following describes a method to derive quantitative and actionable understanding of the consumability of a product from support records.
The customer service records (105) are records generated during the interaction of the customer with the support provider. By way of example and not limitation, the customer service record (105) could be generated as a result of customer interaction with an online diagnostic tool, online chat or e-mail interaction with a support person, or though a support call to a technical support person. During this interaction, the customer may be asked to provide information which is recorded in support data fields (110). These fields including, for example, product identifying information, the activity the customer was performing when the problem occurred, the situation in which the product was being used, that nature of the problem prompting the need for product support and other information necessary to appropriately address the customer's concern. According to one exemplary embodiment, this information is entered into support data fields (110). A variety of other information may be included in the customer service records (105). For example, the ultimate resolution to the problem may also be included in the customer service records (105).
There are a number of ways in which the customer service record may be created. The creation of one exemplary embodiment of a customer service record is further described in
Customer service records (105) for a particular product are aggregated and passed through a market drivers/attribute mapping (120). The market drivers/attribute mapping (120) is further described in
Market drivers describe various areas within the consumer experience throughout the lifecycle of the product. By way of example and not limitation, a first market driver (130) maybe a “positive first use” of the product. A “positive first use” experience by the customer can drive market value or demand for the product because a “positive first use” experience inspires confidence in the product from the beginning. A “positive first use” experience allows the customer to derive value from their investment in the product quickly. For example, in the case of a software package, the product is installed and operational within the customer system rapidly, which leads to buy in from users and smoothes transition and learning periods. Other market drivers, such as “meets customer needs” and “enhances customer productivity” similarly define areas of the customer experience that influence the market and success of the product.
Each market driver is divided into a number of consumability attributes (135). Consumability attributes (135) describe specific customer interactions with the product. A number of consumability attributes represent the range of customer interactions with the product which are related to that market driver. By way of example and not limitation, the “Install” attribute (135) and the “Operate” attribute (137) combine with additional attributes to form the “Positive first use” market driver (130). As will be appreciated by those of skill in the art, the market drivers and attributes are merely illustrative of possible categories which could be selected to describe a customer's experience with the product and the underlying product features.
According to one exemplary embodiment, the market driver/attribute mapping (120) assigns each customer service record (105) to a specific attribute (135) within a market driver category (130). The distribution of the customer service records (105) within the market drivers/attributes (125) categories can be represented by a graph (140). The graph (140) is further illustrated and discussed with respect to
To obtain further insight into the specific weaknesses/strengths of a product, system or organization, the customer service records (105) within a particular attribute may be further mapped to consumability criteria (150) by an attribute to consumability criteria mapping (145). The consumability criteria represent specific sub-categories of the consumer experience which can be directly addressed to improve the consumer experience with a particular consumability attribute. By way of example and not limitation, the “install” attribute (155) may contain a number of consumability criteria (160). These consumability criteria may include “an evaluation/setup,” “ease of installation,” “installation dependencies,” and other criteria. The consumability criterion “evaluation/setup” (160) may refer to the first time a consumer installed and configured the product to evaluate whether it met the consumer's needs. The “ease of installation” consumability criterion refers to the customer experience in installing the product into the customer's system for the first time. The “installation dependencies” consumability criterion may refer to the consumer experience in understanding the prerequisites necessary to select and correctly install the product within the consumer system.
The combination of these consumability criteria (160) directly contribute to the consumers positive or negative experience in installing the product. By further dividing the consumability attribute of “installing” the product into these consumability criteria, specific functionality and design within the product can be pinpointed for improvement. A visual representation of the consumability criteria (160) can be used to inform decision-makers about specific and actionable product features which can be targeted in preventative and improvement efforts. A second graph (165) is one method of visually representing consumer data within the consumability criteria. The second graph (165) is further discussed and illustrated in
In one exemplary embodiment, the customer service record is entered through a software interface. The software interface is configured such that each customer service record follows an exclusive problem classification taxonomy which requires that each customer service record explicitly identify one and only one problem. In alternative embodiments, multiple interrelated problems can be recorded on a single customer service record (105) by making appropriate notations within the service record (105). The exclusive problem classification taxonomy can also be used in this situation by segmenting the individual problems, while maintaining the interrelationship data between the problems.
The customer service record (105) is merely one illustrative example of a customer service record. Customer service records may take a variety of forms and need not follow a strict taxonomy or be software-based. By way of example and not limitation, historical service records could be aggregated and then translated into a given taxonomy or organizational structure prior to mapping the customer service record into market driver/consumability attributes for the given product.
By way of example and not limitation, the attribute mapping rules (315) for the “install” consumability attribute (365) may include a first rule (335), a second rule (345), and a third rule (350). These rules (335, 345, 350) may have either positive or negative subparts; may be exclusive or inclusive rules; and may be combined by a number of logical operators (330, 340). Customer support records (105,
By way of example and not limitation, the customer service record (105;
According to one exemplary embodiment, where the customer service record (105,
For example, about 25 customer service records mapped into the “install” consumability attribute (405), as shown by a first bar (410). In this example, the consumability attribute with the largest number of customer service records is the “administer and maintain” consumability attribute (415). A second bar (420) associated with the “administer and maintain” consumability attribute (115) indicates that slightly more than 300 customer service records addressed a customer problem or issue with administering and maintaining the product.
According to one exemplary embodiment, the results of mapping customer service records into consumability attributes could be weighted by a number of factors to give perspective to the results. By way of example and not limitation, if the chart in
Consumability criteria are defined by a narrower subset of the rules that define the parent attribute. By way of example and not limitation, the “install” attribute (135) is defined by a set of three rules (505) that were described in greater detail above in connection with
By way of example and not limitation, the “evaluation set up” criterion (515) consists of a subset of a first rule that requires that the “customer activity” data field (215,
For example, the “install” attribute (610) consists of a number of consumability criteria including the “evaluation set up” criterion (515). As shown in a first bar (640), approximately 7 of the 20 total customer service reports (105,
According to the illustrative chart in
By mapping the consumability attributes into various consumability criteria, specific elements of the customer experience can be more closely examined. Additionally, because each customer service report requires time and resources to complete, the number of consumability reports directly correlates to the cost to the organization of the particular flaw or weakness in the product which triggered the customer to request additional support. The mapping of customer support records into consumability criteria provides concrete and actionable information which can be used to focus improvement, prevention, and remedial efforts.
In some circumstances, the customer support data may be formatted or extracted into various data fields. According to one exemplary embodiment, the data elements/data fields are formatted into an exclusive problem classification taxonomy (step 710). The data elements are then mapped using rules into various market driver/consumability attributes (step 720). The mapping or post-processing of the mapped data may include a number of weighted leading factors to compensate for various external or internal influences which may skew the results. The various market drivers/consumability attributes can then be visually represented to allow decision-makers to examine the data for areas amendable to potential improvement, cost management, or other goals (step 730).
The customer support data within each market drivers/attribute can then be further categorized by mapping the customer support data and consumability criteria (step 740). In some circumstances, the consumability criteria may provide a more focused target for improvement efforts. By way of example and not limitation, if a large portion of the customer support data indicates that customers are having difficulty with interoperability features of the product, it may be economical to expend engineering time and resources to improve those features.
The method illustrated in
In sum, mapping aggregated customer support data into market drivers, consumability attributes, and consumability criteria provides multiple measures of a product's consumability. By identifying specific consumability attributes or criteria that need improvement, the organization can make the products easier for the customer to find, install, test and deploy to meet their business goals. Further, by relating support incident volumes to consumability characteristics, the cost of product flaws and weakness can be quantified.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a,” “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
Having thus described the invention of the present application in detail and by reference to embodiments thereof, it will be apparent that modifications and variations are possible without departing from the scope of the invention defined in the appended claims.
