METHODS AND APPARATUS FOR MANAGING BUSINESS RELATIONSHIPS
Field of the Invention
The present invention relates generally to methods and apparatus for providing business relationship management services, and more specifically to providing services that take advantage of computer networks to provide a service for consolidating information relevant to a business relationship.
Background of the Invention
Relationships are the lifeblood of any businesses. The success or failure of a business often depends on the quality of the relationships it has with its suppliers, dealers, partners, and especially its customers. Unfortunately, even highly successful businesses may have difficulty maintaining healthy business relationships.
According to the Harvard Business Review, U.S. companies typically lose about 1/3 of their customers every five years due to inadequate customer care. Because it can cost six to seven times more to acquire a new customer account than to retain an existing one, losing a customer account can have a significant financial impact. It is equally costly to replace lost suppliers, partners, or dealers. Effective management is critical to keeping and strengthening business relationships.
For any but the smallest organization, business relationships tend to be relatively complex, involving many people, often from different departments within each organization. A typical relationship between a company and its customers may
involve accountants, attorneys, engineers, managers, salesmen, and support technicians. The larger the number of people involved in a relationship, the more complex it becomes, and the harder it becomes to manage and maintain the relationship. Participants in a relationship interact and form ad hoc paths of information flow. For example, an engineer in a customer's company may develop contacts with several engineers in a manufacturing company, each contact being another information pathway. While direct communications may be expedient, the existence of multiple pathways may cause difficulties in managing the overall business relationship.
Having many different pathways results in scattered access to information, a reduction in information reliability, and makes coordination more difficult. Scattered access refers to the difficulty in determining "who to call" to get a specific bit of information. Because there are many sources of information, there is an increased likelihood of inconsistent or conflicting information, making the information is less reliable. As an example, a company trying to coordinate a software release with the release of new hardware by a partner company may discover that a development engineer, production engineer, and sales engineer may have different ideas as to when the hardware will reach the market. Ad hoc interactions may also result in duplication of effort, as when the same task is done more than once. For example, a customer having multiple contacts at a manufacturing company may ask each contact to provide a document, such as a product specification, with the result that contacts end up duplicating each other's efforts in locating, copying, and sending the document to the customer. Alternatively, a single contact may be asked to provide a document on multiple occasions. Not only is such duplicative effort inefficient, the contacts spend significant amounts of time in a reactive mode responding to customer requests, possibly detracting from their own work.
Ad hoc interactions may also result in a loss of information and control when employees leave a company or make promises to customers. For example,
information related to a customer account is maintained by a sales representative or sales engineer assigned responsibility for that customer account. Notes may be kept listing customer points of contact, open action items, anticipated requirements, and the like. However, the notebook entries are often only meant to jog the memory of the sales representative as to the status of each customer account, and are not complete.
As a result, if a sales representative were to leave his employment, his knowledge about the relationship may be effectively lost.
Various tools have been developed to assist in managing customers. For example, Sales Force Automation tools have been developed to improve the productivity of sales staff personnel by providing tools to manage the sales pipeline, track leads, make forecasts, and organize customer contact information. Customer Support tools help manage and track support issues, such as reports of software bugs. Other tools help generate leads, track sales staff efficiency, and marketing effectiveness. However, these tools have generally been narrowly focused on automating internal front office functions and not on managing external relationships.
A few large companies have attempted to develop in-house web based applications to manage their business relationships. However, these applications have been expensive, narrow in scope, and of limited functionality. Building these custom sites and keeping them up-to-date typically requires a professional programming staff making in-house systems expensive to maintain and update. Indeed, in one case development and deployment costs alone reached $50 million or more. Clearly, only the largest companies can afford to develop and use such systems and then only for their best customers.
Therefore, in view of the foregoing, there is a need for a turnkey, commercial relationship management tool that empowers its users to setup and manage sites for their customers. Alternatively, there is a need for a service that provides such a relationship management tool at relatively low cost.
It would therefore be desirable to provide a tool for managing a business relationship. It would also be desirable to consolidate information relevant to a
relationship such that it is accessible to both a company and its customer, thereby reducing the number of information pathways.
It also would be desirable to provide a relationship management tool that may be created and maintained by its users without extensive programming knowledge or expertise.
And, it would be desirable to provide a relationship management tool that may be provided in the form of a service.
Summary of the Invention
In view of the foregoing it is therefore an object of the present invention to provide a tool for managing a business relationship.
It is also an object of the present invention to consolidate information relevant to a relationship such that it is accessible to both a company and its customer, thereby reducing the number of information pathways.
It is also an object of the present invention to provide a relationship management tool that may be created and maintained by its users without extensive programming knowledge or expertise.
And, it is an object of the present invention to provide a relationship management tool that may be provided in the form of a service.
These and other objects of the present invention are achieved by providing a set of one or more computer programs that provide relationship management functions. In a preferred embodiment of the invention, the computer programs take the form of an application that may be accessed over the Internet using the World Wide Web, and related technologies.
Brief Description of the Drawings The above and other objects and advantages of the present invention will be apparent upon consideration of the following detailed description taken in conjunction with the accompanying drawings, in which like characters refer to like parts throughout, and in which:
FIG. 1 is a representation of the information pathways in an exemplary business relationship;
FIG. 2 is a representation of the information pathways of FIG. 1 organized in accordance with the principles of the present invention; FIG. 3 is an illustrative embodiment of a relationship management system;
FIG. 4 is a simplified block diagram of the architecture of a preferred embodiment of the present invention;
FIG. 5 is a screen capture of an illustrative login dialog; FIG. 6 is a screen capture of a dialog for selecting a customer center;
FIG. 7 is an exemplary base page in accordance with the principles of the present invention;
FIG. 8 is a chart showing the types of access to various system features and functions permitted based on a user's role; FIG. 9 is a screen capture of an exemplary dialog for managing a repository;
FIG. 10 is a screen capture of an exemplary form for loading items into a repository;
FIG. 1 1 is a screen shot of an exemplary interface for publishing documents from a repository to a customer center;
FIG. 12 is an illustrative form for entering a customer profile; and
FIG. 13 is an exemplary interface for identifying participants in the relationship and specifying the roles they have with regard to the relationship.
of an exemplary dialog for adding a new user to a customer center.
Detailed Description of the Invention
As shown in FIG. 1 , even a relationship involving only a few employees in two companies can involve many different interactions. For example, in FIG. 1 , sales manager 11 and support engineer 12 of company 13 may interact and
communicate with marketer 15, development engineer 16, and product manager 17 of customer 18. For the five people shown, there are ten potential interactions or information pathways. Adding a sixth participant to the relationship adds five more pathways, a seventh participant adds six more, and so on. At fifteen participants there are over one hundred potential pathways of information flow. Clearly, the number of potential interactions quickly grows out of control.
As discussed in the background of the invention a large number of information pathways may hinder the management of a business relationship. In accordance with the principles of the present invention, the difficulties introduced by a large number of participants are reduced or eliminated by the use of a relationship management tool. The relationship management tool consolidates information pertaining to the relationship, functioning as a single point of contact and a single pathway of information flow between the parties to the relationship.
Referring now to FIG. 2, relationship management tool 20 preferably comprises a network based application accessible to the employees of company 13 and customer 18. In a preferred embodiment, relationship management tool 20 appears as web site 21 hosted by company 13 customized for customer 18. Customer 18 accesses customized web site 21 over network 22, which is preferably a wide area network such as the Internet. Using the Internet ensures that customer 18 are able to access the system from almost anywhere in the world, however, network 22 may also comprise a local area network (LAN), an Intranet, a virtual private network, or even a dedicated line between company 13 and customer 18.
Web site 21 serves as an interface to relationship management tool 20, and is the focal point for information, communication, documentation, and other data related to the relationship between company 13 and customer 18. Internal users, such as sales manager 1 1 and support engineer 12, as well as external users, such as marketer 15, development engineer 16, and product manager 17 may send messages, publish and review documents, establish action items, set up 'to do' lists, and otherwise interact with other members of the relationship. Web site 21 is, therefore, the single point of interaction among the participants and provides a single path for the
flow information pertaining to the relationship.
It should be noted that the present invention is described herein in terms of manipulating documents. For example, the description explains how documents are uploaded to the repository and published to a custom web site. However, this language is used for ease of description only and the skilled artisan will readily understand that 'document' should be understood broadly to include action items, calendars, charts, files, images, schedules, time lines, sounds, 'to do' lists, Uniform Resource Locators (URLs), web pages, and other things that may be stored or processed by a general purpose computer. Referring now to FIG. 3, web site 21 comprises a system of software programs and routines executing on server 31 coupled to network 22. In a preferred embodiment, users access the system from computers 33-35 using web browser software, such as Netscape Navigator available from Netscape Communications Corporation of Mountain View, California. Other web browsers such as Internet Explorer from Microsoft Corporation of Redmond, Washington, may also be used.
Using a web browser, HTTP protocol, and HTML as an interface to the system of the present invention leverages their ubiquity to provide truly global access. However, the system is format-agnostic. That is, the system is not dependent o the use of HTTP and HTML so alternative interfaces may be used. For example, a user may access the relationship management system using Personal Digital Assistant
(PDA) 37 or cellular telephone 38 of FIG. 3.
A simplified block diagram of the architecture of the preferred embodiment of the present invention is shown in FIG. 4, wherein relationship management tool 20 includes web server 41 , application server 42, and database 43. Web server 41, executing on server 31 of FIG. 3, receives a request for a document from another computer over Internet 22 in the form of a URL formatted and transmitted in accordance with the HyperText Transport Protocol (HTTP). Web server 41 responds to the requests by transmitting data in the form of a web page for display by web browser 21, or other interface software, employed by the user. The documents are typically formatted using HyperText Markup Language (HTML) and
transmitted using the HyperText transmission Protocol, but other formats, such as extensible Markup Language (XML), and Wireless Markup Language (WML), and transport protocols, such as Wireless Application Protocol (WAP), may be used. In accordance with the principles of the present invention, the web pages sent by web server 41 are customized according to a number of factors as described below.
There are a number of ways to dynamically create or alter the contents of a web page, including both client-side and server-side processing. In client-side processing program routines are loaded and executed on a user's computer, e.g., computer 35 of FIG. 3. The program routines may be embedded in a web page in the form of scripts using, for example, JavaScript or Visual Basic. Alternatively, Java applets may be used for client-side processing. Java applets comprise compiled routines in the form of byte codes. When a reference to an applet is included in an web page, a user's web browser downloads the applet and begins executing it.
In contrast, server-side processing programmed routines are performed by the web server, e.g., server 31 of FIG. 3. The routines may be external scripts and programs accessed by using Common Gateway Interface (CGI) techniques. Other methods include using server-side include directives, and embedding scripts or calls to Java servlets in the web page. Typically, server-side processing is used are used to access resources such as databases or applications external to the web server. Server-side processing is performed by servlet server 44 in cooperation with web server 41. When web server 41 retrieves a web page to be transmitted to a web browser for display, the contents of the web page is scanned for directives requiring server-side processing. For example a web page may include a reference to a servlet which is processed by servlet server 44. The output of the servlet, if any, is a dynamically customized HTML. In a preferred embodiment of the present invention,
Java Server Page (JSP) technologies are used to simplify the process of creating customized HTML pages based on data retrieved from a back-end server. Apache, an open source program available on the Internet at http://www.apache.org/, is a suitable web server, including a JSP servlet server, for use in the present invention. Web server 41 is coupled to application server 42 which may be located
on server 31 with web server 41 , or may be located on a separate computer connected to server 31 by a communications link such as a network. Application server 42 provides a number of programs or routines that provide system features or perform specific functions. For example, a routine on application server 42 may provide services to authenticate a user's ID and password during login. Suitable application servers for use in the present invention include JOnAS available from BullSoft, of Louveciennes, France, or the Weblogic server from BEA Systems, Inc., of San Jose, California.
The relationship management tool further includes database 43, which may be for example, a database provided by Oracle Corporation of Redwood Shores,
California. Database 43 includes tables describing access permission and authority for users of the system, lists of documents stored on the system, and other information and data that may be relevant to a business relationship. Depending on the needs of a particular relationship, the contents of database 43 may be modified as needed. Access to database 43 is provided by routines on application server 42
In operation, requests are sent to web server 41 by web browser 46 via network 22 in response to a user action such as clicking on a document title displayed on a web page. Web server 41 parses the request and identifies a pair of cooperating servlets to carry out the request. A first servlet, called an application component, contains instructions for responding to the request. For example, an application component may contain instructions for uploading a document from computer 34 to server 31 (FIG. 3) for storage in database 46.
The application component interacts with application server 45 to run software modules, called feature managers, that provide basic system functionality. For example, an ACL (access control list) manager provides basic access control functions which may be used to determine whether a particular user has the authority to access a specific document.
A second servlet, called a presentation component, contains instructions for converting the output of the application component, if any, into a format suitable for displaying to the user. Typically, the output of the presentation component is an
HTML document for display on a user's computer monitor; however, other formats may be used if the request originated from a device such as PDA 37 or cellular telephone 38. For example, a presentation component may provide text-to-voice translation so that responses sent to a cellular telephone may be read aloud to a user. Analogously, foreign language translators may be provided to enable readers or speakers of foreign languages to access the web site.
Although a company may obtain, install, and maintain a relationship management tool such as the tool described herein, in a preferred embodiment of the present invention, the components of the relationship management tool are provided as a service by a third party service provider. The service provider supplies server 31 coupled to Internet 22, along with suitable software for implementing web server 41 , including servlet server 44, application server 45, and database 46. If desired, the service provider may also supply customized browser software to be used for accessing the relationship management tool. Under the service model, client companies lease access to and use of the relationship management tool from the service provider (SP). The client companies then use the tool to create individual web sites for their customers. For example, a disk drive manufacturer may lease relationship management services from a service provider and use the relationship management services to create web sites for customer companies that purchase disk drives. As used herein, client refers to an entity leasing the relationship management services, e.g., the disk drive manufacturer, and the service and resources leased by a client are referred to herein as a domain. Customers or users refer to customers of a client, e.g., disk drive purchasers, and customer centers refers to web sites a client provides for its customer's use. Database 46 includes tables describing the domains and customer centers. In connection with feature managers provided by application server 45 these tables keep customer centers within a domain separate and keep the domains segregated from one another.
In accordance with the principles of the present invention, web pages served by web server 31 are customized according to domain, customer center, and user identity. The domain may be obtained from the Uniform Resource Identifier
(URI) used to access the web site. The URI may be entered directly by a user or may be provided as a link from a client's corporate web site. The latter technique may be used to strengthen the branding of the management tool as discussed below.
A user's identity may be determined by requiring a user name and password, as illustrated by the exemplary login screen shown in FIG. 5. Selecting
"Login" button 53 causes the username and password to be transmitted to server 41 or FIG. 4 for authentication. In a preferred embodiment of the present invention, a secure mechanism such as the secure HTTP protocol (SHTTP) is used to transmit the username and password. A password based system provides a minimum level of access control to a customer center. Other more secure identification methods, such as, for example, the use of hardware tokens or biometric systems, may also be used if additional security is required.
If a user is a participant in only one customer center, then the user name and password serve to identify both the user and the customer center. If, however, a user belongs to more than one customer center, the user is prompted to select from a list of customer centers. For example, in FIG. 6, a user is prompted to select one of two customer centers from a list of customer centers, e.g., the Kovair center via hypertext link 61 and the yourcompanylogo center via hypertext link 62.
After logging into the system of the present invention, and possibly selecting a customer center, a start page, or welcome screen, is displayed to the user.
An exemplary home page is shown in FIG. 7, which shows web page 72 in browser 71. In addition to various site management and navigation tools, web page 72 also shows examples of domain-specific and user-specific customization. Specifically, company logo 73 is a domain specific customization that may be displayed on web page 72. Analogously, the inclusion of user name 74 is a user specific customization. Web page
72 may also be customized as to color selection, page layout, font, and other page attributes. Thus, the company sponsoring the site appears to have provided the user a custom web site. This is referred to as branding and is an important way to build name recognition. As mentioned previously, the content of a web page displayed by the
relationship management tool depends in part on the identity of the user. For example, the content of "what's new" section 75 on web page 72 only includes new documents, communications, and other items that the user is authorized to view. Documents that the user is not authorized to view, for example, private e-mail between two other users or locked documents that the user is not authorized to view, do not show up in what's new section 75 of web page 72.
Associated with each user's identity is a set of one or more domain specific roles. These user roles determines access authorization associated with the user. Exemplary user roles include managers, team members, contributors and viewers. The roles may be further classified as being internal or external to the company hosting the web site. A summary of the roles available in a preferred embodiment of the invention is provided in FIG. 8 along with the actions permitted by users in a particular role. Thus, a domain manager may create new customer centers, an internal manager may manage users of a customer center, and an external contributor is only given limited ability to publish documents to the web site. That is, an external contributor may only publish documents uploaded to the system by an external user.
Access to documents, administration features, and resources on the relationship management tool of the present invention is controlled by an access control list (ACL) associated with each such document, feature, and resource. Access may be granted based on a user's identity or a user's role within a domain. An ACL manager compares a user's identity and role with the authorized identities and roles listed in an ACL attached to a document. If the user is not on the list, the user may not access the item. Furthermore, in accordance with the principles of the present invention, if a user is not on an ACL associated with a document or other item, then the user will also not be provided any references to the document. For example, only those documents having an ACL authorizing access to the user are listed under "What's New" section 75 of FIG. 7.
In addition ACL's determine what actions a user may take. For example, web page 72 includes "admin." button 76 and "new acct" button 77.
"Admin" button 76 is used to add, delete, and otherwise administer users of a customer center, whereas "new acct" button 77 is used to create new customer centers. Only a domain manager is authorized to create new customer centers, so button 77 only appears on web page 72 if the user has a role as a "domain manager." Similarly, "admin." button 76 only appears on web pages served to users having
"internal manager" roles, and "Repository" tab 78 and "Publish" button 79 are only visible to users authorized to publish documents to the web site.
Publishing documents to a customer center is a two step process. First documents are uploaded into a repository from a user's computer. Documents in the repository may then by published to a customer centers. In a first embodiment of the present invention, repositories are domain specific, that is documents may only be published to customer centers with a domain. However, in a preferred embodiment of the present invention, repositories may span multiple domains. A client may, therefore, have multiple domains corresponding to different product lines or corporate departments, for example, and be able to publish a document to the multiple domains with out uploading the document to each domain individually.
Uploading a document begins by selecting repository tab 78 in FIG. 7 to access the repository management system. In response to selecting repository tab 78, web server 31 returns a web page including an applet for managing the repository. The applet creates exemplary repository management dialog 90 including file manager
91. Data about the contents of the repository is downloaded by the applet from web server 31 for display in folder pane 92 of file manager 91. If applicable, drop down pick list 98 enables a user to select from among a number of different repositories.
Folder pane 92 of file manager 91 displays an expandable hierarchy of the folders, or directories, in the selected repository. Selecting a folder in folder pane
92 causes its contents to be displayed in content pane 93. For example, in FIG. 9 the "products" folder in the "yourcompanylogo" repository is shown to contain two documents. Creating new folders is done using button 95. Button 96 invokes a search function to assist the user locate a document. Other controls, such as buttons 97, are for editing, deleting, cutting, copying, and pasting documents.
To upload documents a user selects a destination folder and selecting upload button 94. This causes server 31 to serve a web page including an upload dialog, such as exemplary upload dialog 100 of FIG. 10. Upload dialog 100 includes fields 101 and 102 for specifying, respectively, a document name and document description. These fields correspond to information displayed in "What's New" section 75 of FIG. 7.
Upload dialog 100 also includes keyword field 103 and check boxes 104 and 105. Keyword field 103 is for entering key words which may be used in searching for documents stored by the relationship management tool. Check boxes 104 are used to indicate whether internal and external users should be notified by e- mail when the document is published, whereas check box 105 specifies that internal users are to be notified when the repository item is changed.
The directory path and name of files to be uploaded as part of the document are specified in location field 106. Alternatively, a user may use "browse" button 107 to visually select files to upload in a manner similar to the file manager included with the Windows™ operating system. After selecting one or more files, selecting "upload" button 108 causes the files to be uploaded to the repository and folder selected in repository manager 91 of FIG. 9.
After documents are uploaded to the repository, then they may be published to one or more customer centers by selecting "publish" button 79 of FIG. 7.
This causes a file manager dialog similar to that shown in FIG. 1 1 to be displayed. Unpublished documents are shown in pane 1 12, while published documents are shown in pane 113. A document is published by selecting the unpublished document from pane 1 12 and a destination category in pane 1 13 then activating "Add" button 1 14. Analogously, a document may be unpublished by selecting it in pane 113 and selecting
"remove" button 116. "Done" button 117 commits the selected changes and returns the user to start screen 72 of FIG. 7.
Referring back to FIG. 7, selecting "administer" button 77 brings up a web page for administering a customer center. Exemplary customer center administration page 120 of FIG. 12 includes a set of tabs for selecting from among
several administrative tasks. For example, selecting "profile" tab 121 brings up a web page similar to web page 120 of FIG. 12, including form 126 for providing basic information about a customer relationship. In the illustrative dialog of FIG. 12, a relationship with ValuedCustomer, Inc. is designated as high priority, presumably because of a design in as shown by the "status" and "Description" fields. Similarly,
"Company Info" tab 122 brings up a web based form for entering specific information about the customer, e.g., ValuedCustomer, Inc.
Other administrative tasks include adding participants to the relationship. Internal and external users are added to the relationship by selecting either "Internal Users" tab 123 or "Customer Users" tab 124. Selecting "Internal
Users" tab 123 brings up a web page similar to exemplary web page 130 of FIG. 13 for adding internal users as participants in the customer center. Available users that may be added are listed in list box 131, whereas participating users are listed in list box 132. Drop down list box 133 is used to select a role for the new users. Users are assigned a role by designating the role from list box 133, selecting the user from list box 131 and then activating "Add User" button 134. Analogously, users may be removed by using "Remove User" button 135. A user may be invited, via e-mail, to join a customer center by selecting an appropriate one of radio buttons 136, filling in e-mail address field 137, and selecting "Invite" button 138. "New account access" tab 125 is used to specify the access privileges of users of a customer center. Specifically, selecting new account access tab 125 displays a dialog for managing user roles and ACLs. "Change approval" tab 126 is used to specify whether approval is required before documents may be published to the customer center. For example, the customer center may be set up to require management approval prior to publishing any document to the customer center.
While preferred illustrative embodiments of the present invention are described above, it will be evident to one skilled in the art that various changes and modifications may be made without departing from the invention. It is intended in the appended claims to cover all such changes and modifications which fall within the true spirit and scope of the invention.