DEAL MANAGEMENT IN A CUSTOMER RELATIONSHIP MANAGEMENT ENVIRONMENT

FIELD OF THE INVENTION

The present invention relates to deal management in a customer relationship management environment, and, more particularly, providing decision support tools integrated into a deal negotiation process to aid in achievement of profit and revenue objectives.

BACKGROUND OF THE INVENTION

Business entities interact with customers, potential customers and other contacts through a wide variety of different communication channels. Such communication channels include face-to-face, telephone, fax, email, voicemail, wireless communication, Internet sessions, and the like. With all these various communication channels, business entities are faced with managing each customer interaction while meeting service levels and maximizing customer satisfaction. In addition, business entities are faced with staffing and training a workforce to interact with customers through these communication channels through, for example, customer support centers, telebusiness organizations, or sales, marketing and service professionals. Customer relationship management (CRM) applications enable business entities to more effectively sell to, market to, and serve their customers across multiple channels in any industry.

In a competitive marketing environment, business entities have historically strived to increase profits by reducing costs and increasing sales volumes. But there is a limit to the effectiveness of cost cutting initiatives to improve corporate revenues. Once cost cutting initiatives have been in place, a business entity tends to focus on improving pricing performance in order to maximize profitability. One such focus relates to pricing initiatives that can more fully capture value of a business entity's product offerings to their customers. As a result, price management solutions are desired by business entities in helping to achieve profit and revenue objectives. Enabling an organization to enhance margin and revenue by delivering value-driven prices to value-conscious customers throughout the business entity, while employing industry best practices is desirable.

A deal management solution that provides a mechanism for creation of price policies and enforcement of those price policies throughout a business entity is desired. Tying such a deal management solution to a customer relationship management environment will enable dissemination of price policies throughout the business entity through the CRM environment. Thus, price policies can be quickly instituted at every level impacted by the CRM solution. Typical deal management solutions are not integrated and therefore fail to provide real-time feedback at the quote stage. Instead, such typical systems require separate data stores and involve asynchronous updating of those separate data stores, along with additional management overhead such as security and database management. An integrated solution that eliminates this separate and parallel management of resources is desired to reduce resource expenditure of the business entity.

SUMMARY OF THE INVENTION

The present invention facilitates consistent application of price polices on every sales transaction supported through a customer relationship management system, in order to identify price exceptions in violation of stated corporate pricing objectives. Having such capabilities coupled with a customer relationship management system enables embodiments of the present invention to reduce the time to identify and evaluate price exceptions that impact revenue and margin. Agents responsible for sales interaction with customers can immediately identify violations of price policies. Those responsible for authorizing exceptions can easily determine the effect of those exceptions upon impacted markets.

Embodiments of the present invention provide a customer relationship management system that includes an opportunity management subsystem, a quote management subsystem, a deal management subsystem, and a database storing deal management tables associated with the deal management subsystem and accessible by the other subsystems of the customer relationship management system. In aspects of the above embodiments, the deal management tables include one or more guideline tables that define pricing criteria and guideline plans. In additional aspects of the above embodiments, the pricing criteria tables can include pricing segment definition tables and pricing strategy tables.

In a further aspect of the above embodiments, the deal management subsystem evaluates parameters of a quote entered in the quote management subsystem and returns results of the evaluation to the quote management subsystem. The evaluation is performed on the quote as the quote is entered and uses data stored in the deal management tables. The data can include customer-related information provided by the opportunity management subsystem. The quote parameters include line items of the quote and characteristics of the quote. In aspects of the above embodiment, the evaluation includes comparing prices in the quote with limits of a pricing segment associated with the quote customer.

The foregoing is a summary and thus contains, by necessity, simplifications, generalizations and omission of detail; consequently those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the present invention, as defined solely by the claims, will become apparent in the non-limiting detailed description set forth below.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention may be better understood, and its numerous objects, features and advantages made apparent to those skilled in the art by referencing the accompanying drawings.

FIG. 1 is a simplified block diagram illustrating a customer relationship management system architecture usable in conjunction with embodiments of the present invention.

FIG. 2 is a simplified block diagram illustrating a logical configuration of a customer relationship management system 200, incorporating embodiments of the present invention.

FIG. 3 is a simplified flow diagram illustrating a process for creating a pricing strategy, in accord with embodiments of the present invention.

FIG. 4 is a simplified block diagram illustrating one example of a deal management data model usable to implement embodiments of the present invention.

FIG. 5 illustrates a user interface screen providing an example of definitions of pricing segments with primary pricing criteria.

FIG. 6 illustrates a user interface providing an example of an association between customer accounts and pricing segments.

FIG. 7 illustrates a user interface providing an example of guideline terms associated with one of a set of guideline plans.

FIG. 8 illustrates a user interface displaying an example of data that can be found in a pricing strategy table, in accord with one embodiment of the present invention.

FIG. 9A illustrates an example of a user interface that can be provided by embodiments of the present invention and used to enter a quote or order by a sales person.

FIG. 9B illustrates an example of a user interface that can be provided by embodiments of the present invention to select an appropriate deal management pricing strategy.

FIG. 9C illustrates an example of a user interface that can be provided by embodiments of the present invention for entering line items associated with a quote or order.

FIG. 10 is a simplified flow diagram illustrating an example of a process that can be followed for entry and analysis of a customer quote, in accord with embodiments of the present invention.

FIG. 11 is a simplified flow diagram illustrating an example of a process for gathering item terms associated with a quote or order, in accord with embodiments of the present invention.

FIG. 13 is a simplified block diagram of a computer system suitable for implementing aspects of the present invention.

FIG. 14 is a simplified block diagram illustrating a network architecture suitable for implementing aspects of the present invention.

DETAILED DESCRIPTION

The present invention provides a method, system and computer-readable storage medium storing instructions for facilitating consistent application of price polices on every sales transaction supported through a customer relationship management system, in order to identify price exceptions in violation of stated corporate pricing objectives. Embodiments of the present invention further enable analysis of an impact of a given price exception against a relevant market segment to aid in identifying revenue and margin impact. Embodiments of the present invention also enable understanding of price erosion, discount effectiveness and margin impact for price exceptions. Having such deal management capabilities coupled with a customer relationship management system enables embodiments of the present invention to reduce the time to identify and evaluate price exceptions that impact revenue and margin. Agents responsible for sales interaction with customers can immediately identify violations of price policies. Those responsible for authorizing exceptions can easily determine the effect of those exceptions upon impacted markets.

An Example Architecture for Deal Management in a Customer Relationship Management Environment

FIG. 1 is a simplified block diagram illustrating a customer relationship management architecture usable in conjunction with embodiments of the present invention. The illustrated customer relationship management environment includes an enterprise server 110 that is a logical grouping of one or more servers 120 that support a group of clients (160,165) accessing a common database 130. An enterprise server can be configured, managed and monitored as a single logical group, allowing an administrator to start, stop, monitor or set parameters for servers 120 within enterprise server 110. In such a configuration, parameters for the customer relationship management system can be set at the enterprise server level, and these parameters can apply to every server operating within the enterprise server. In addition, other parameters can be adjusted at a server (120) level to support fine tuning of those parameters. In this hierarchical parameter context, if a parameter is set at a server level, then the server-specific value for the parameter can override an enterprise server-level setting for the parameter. Further, parameter settings at a component level (processes executed on servers 120) will override those set at the server level.

Servers 120 can support back-end and interactive processes for each client accessing the server. These processes are illustrated as one or more components 125 within each server. A server 120 can support, for example, multiprocess and multithreaded components, and can operate components in background, batch, and interactive modes. A server component can also operate on multiple servers 120 simultaneously to support an increased number of users or larger batched workloads. Examples of component processes include, for example, mobile web client synchronization, operation of business logic for web clients, connectivity and access to database and file system for clients, integration with legacy or third-party data (e.g., data not native to the CRM system), automatic assignment of new accounts, opportunities, service requests, and other records, and workflow management. Embodiments of the deal management processes of the present invention can also be implemented to execute on one or more of servers 120 as components.

Servers 120 are coupled to a gateway server 150, illustrated as part of enterprise server 110. Gateway server 150 can coordinate the operations of enterprise server 110 and servers 120. A gateway server can provide persistent storage of enterprise server configuration information, including, for example, definitions and assignments of component groups and components, operational parameters, and connectivity information. A gateway server can also serve as a registry for server and component availability information. For example, a server 120 within enterprise server 110 can notify gateway server 150 of availability. Connectivity information such as network addresses can be stored in a storage accessed by gateway server 150. If a server 120 shuts down or otherwise becomes unavailable, connectivity information related to that server can be cleared from gateway server 150.

Through their relationship in enterprise server 110, servers 120 and their components 125 can access one or more databases 130 and/or file systems 140. Database 130 can store, for example, RDBMS client software and tables, indexes, and data related to all operations impacted by the CRM system. Database information can include, for example, customer information, market data, historical pricing information, current pricing information, contact information, and the like. Similarly, file system 140 can store data and physical files used by clients 160 and 165 and enterprise server 110. File system 140 can be a shared directory, or set of directories on different devices, which is network-accessible to all servers 120 in enterprise server 110. In order for a client to gain access to files in file system 140, a client can connect to an appropriate server 120 to request file uploads or downloads. Server 120 can then access file system 140 using, for example, a file system management component.

As stated above, embodiments of the deal management processes of the present invention can be implemented to execute as components on one or more of servers 120, accessing database 130 to store and retrieve data. An alternative embodiment provides a separate server accessible by the same or different web server. The separate server can provide access to database 120, and thereby providing access to deal management information to other component processes through enterprise server 110.

Clients 160 and 165 provide access to enterprise server 110 for agents using the customer relationship management system. Clients communicate to enterprise server 110 through gateway server 150 either directly (e.g., client 160) or via a web server 170 (e.g., clients 165). A web server 170 can provide a mechanism by which enterprise server 110 can respond to web-based requests (e.g., HTML, XML, and the like). Web clients 165 can include clients coupled to web server 170 via a local area network, metro-area network or wide area network and propagated over a variety of communications media, as discussed above. Further, web clients 165 can include mobile clients accessing web server 170 through wireless communications means. Users of clients 160 and web clients 165 can include, for example, sales agents, service agents, customer representatives, managers of the business entity using the CRM, and the like. Users have access to all information accessible to enterprise server 110 in database 130, as controlled by a user's secured access rights.

Specifically, users of embodiments of the present invention include, for example, price administrators who create pricing strategies that can influence price negotiation processes, sales representatives who can select a pricing strategy previously provided by a price administrator that satisfies an account and conditional-deal specific designations and who can quote and negotiate a quote with an entity corresponding to the account, and price approvers who review price exceptions generated during the deal process and detected and displayed by embodiments of the present invention.

FIG. 2 is a simplified block diagram illustrating a logical configuration of a customer relationship management system 200 incorporating embodiments of the present invention. As discussed above, embodiments of customer relationship management system 200 can be implemented by enterprise server 110 described in FIG. 1. Customer relationship management system 200 is illustrated as including subsystems that provide functionality for opportunity management (210), quote management (220), and deal management (230). Customer relationship management system 200, including all integrated subsystems, can access and store data in a customer relationship management database 240, corresponding to one or more of database 130 and file system 140. It should be noted that although FIG. 2 illustrates the customer relationship management system as including the three subsystems discussed above, additional subsystems providing additional functionality can also be incorporated in the customer relationship management system. Further, the described capabilities of the subsystems can be combined into one or the other of the individual subsystems. Each subsystem of the customer relationship management system can be implemented as one or more components 125, as discussed above with regard to FIG. 1.

Opportunity management subsystem 210 provides a user of customer relationship management system 200 a mechanism for entering and accessing information related to a customer opportunity. The opportunity management subsystem can provide, for example, user interface screens that lead a user through a workflow allowing input of all data necessary to identify a customer and the nature of an opportunity associated with that customer. In addition, the opportunity management subsystem can provide a user with the opportunity to associate the customer related to the opportunity with similar customers serviced by the entity using the customer relationship management system. As will be discussed in greater detail below, associating a customer with such a segment of the customer population of the entity can aid in analyzing deals for particular items in light of similarly situated customers. A user interface associated with the opportunity management subsystem can provide, for example, access to pre-defined segment descriptors to be associated with a customer (e.g., through the use of drop-down menus). These pre-defined customer segments can be created and maintained, for example, by an administrative subsystem of deal management subsystem 230, as will be discussed in greater detail below. Tables and other data associated with customer segments are stored in customer relationship management database 240 and are accessible by each subsystem of customer relationship management system 200.

Quote management subsystem 220 can provide a mechanism by which a user (e.g., a sales representative) can enter parameters of a proposed quote for a customer. In addition, quote management subsystem 220 can provide real-time analysis of the proposed quote parameters in light of information associated with the customer segment associated with the customer, showing whether the proposed quote is acceptable in light of those customer parameters. For example, a customer segment can have an acceptable range of prices for a particular product represented as a line item in a quote. If the proposed quote parameters (e.g., a discount) result in a quoted price for a line item outside the acceptable range for the customer segment, the quote management subsystem can flag that line item. In addition, an overall analysis of the quote itself, encompassing all the line items, can also be performed and result in a flag. Embodiments of the quote management subsystem can also provide for a user to select a pricing segment for the customer based upon whether there are multiple pricing segments associated with the customer segment. In order to perform such real-time analysis of proposed quotes, quote management subsystem 220 has access to tables created by deal management subsystem 230 stored in customer relationship management database 240. These tables include relationships between a customer and customer segments and further details related to those customer segments, as will be discussed more fully below.

Deal management subsystem 230 can provide for maintaining and administrating various tables and data associated with deal management stored in customer relationship management database 240. These tables and data can include definitions of customer segments, pricing guidelines and terms associated with such guidelines, and pricing strategy. In addition, deal management subsystem 230 can provide a mechanism for pricing administrators to review, authorize and modify proposed quotes falling outside of a pricing strategy associated with a customer's segment. Deal management subsystem 230 can provide this functionality through, for example, a workbench utility displaying information such as pricing waterfalls, comparison quotes, and the like. Deal management subsystem 230 can provide such functionality through access to not only deal management data stored in customer relationship management database 240, but also by accessing opportunity and quote information stored in database tables by opportunity management subsystem 210 and quote management subsystem 220. Integration of the data from all the customer relationship management system subsystems in customer relationship management database 240 enables, in part, the real-time analysis provided by embodiments of the present invention.

Creating Pricing Strategies

Pricing strategies are pricing policies for a business entity. Pricing strategies influence price negotiation processes conducted by sales representatives and can determine the latitude for action that a sales representative has when negotiating prices for a quote or order. Should a sales representative enter a negotiated price that is lower than or equal to a price associated with a pricing strategy, a price exception will result. To create a pricing strategy, price administrators first create the pricing strategy elements, such as pricing criteria, pricing segments, guideline plans, and price lists, and then use these elements to define a pricing strategy. Embodiments of the present invention enable a pricing administrator to create, configure and define a pricing strategy using all these elements.

FIG. 3 is a simplified flow diagram illustrating a process for creating a pricing strategy, in accord with embodiments of the present invention (e.g., using deal management subsystem 230). As an initial step, price administrators create a pricing criterion that represents characteristics of a customer or a deal (310). Pricing criteria are key factors in determining pricing strategy for a business entity. Values for the pricing criteria are used in the subsequent steps related to defining pricing segments and pricing strategy. Embodiments of the present invention can use, for example, two categories to define pricing criteria: primary and conditional-deal specific. A primary category can represent characteristics of a customer account, including, for example, customer value, pricing criteria industry, geography, channel (e.g., consumer, distributor, OEM, retailer, systems integrator), and cost-to-service (e.g., the cost to service the customer account). A conditional-deal specific criteria can represent the characteristics of a deal, which can be used to define pricing strategies. Examples of conditional-deal specific criteria include, for example, deal type (e.g., quote and order) and competitor. Embodiments of the present invention can provide an interface by which a pricing administrator can review currently entered pricing criteria and to create new criteria, as appropriate. New criteria can then be stored in an appropriate database table.

Once a pricing criterion has been created, embodiments of the present invention can then enable a pricing administrator to configure the pricing criterion (320). Embodiments of the present invention provide a pricing administrator tools by which tables stored in CRM database 240 (discussed below) can be modified to reflect new primary criteria and conditional-deal specific criteria associated with the pricing criterion.

Embodiments of the present invention further provide a mechanism for defining a pricing segment (330) which represents groups of customer accounts. Such groups can be based upon common buying and purchasing behavior of customers in the group. Therefore, similar pricing policies can apply to customer accounts in a pricing segment. Pricing segment definitions designate a unique set of customer accounts. Pricing segments can be defined by selecting an available value for each of the primary criteria. Embodiments of the present invention enable such defining of a pricing segment by enabling a pricing administrator to name a pricing segment and to select a value for each of the primary criterion fields and then storing that information in database 130. As new customer opportunities are added to the customer relationship management system (e.g., using opportunity management subsystem 210), the customer can be associated with an appropriate pricing segment. This customer-segment association can be made by the person originating the opportunity, a sales administrator, or deal management administrator, as appropriate in light of the security needs of the system and business needs of the entity.

Guideline plans determine pricing adjustments that sales representatives are allowed to negotiate when creating quotes and orders. Pricing for a guideline plan can apply to a line item in a quote, to a line item in an order, or to the entire quote or order (e.g., a deal). Embodiments of the present invention enable a pricing administrator to create a guideline plan when creating a pricing strategy (340). Embodiments of the present invention can provide for a pricing administrator selecting a type of guideline plan (e.g., product type or deal type), a sequence number for the line item term, a role of a user who can negotiate pricing for a quote and order, a geographic area for a customer account on a quote or order (restricting areas in which the guideline plan is effective), constraints, products, product lines, product classes, and date restrictions for line item type guideline plans. For deal-type guideline plans, terms can include, for example, the role of a user who can negotiate pricing for a quote and order, geographic territory restrictions, constraints, date restrictions, minimum and maximum deal values and a percentage associated with a deal value. Guideline plan terms can also relate to a list of adjustments used to calculate the final price for a quote or an order line item (e.g., a waterfall). These waterfall adjustments can consist of adjustments that the pricing engine calculates and adjustments that the sales representative enters. Waterfall segments can include, a ceiling (highest published price for a quote, order, or line item), segment (price that a company offers to customers in a pricing segment for a quote, order, or line item), invoice (price that the customer pays for a quote, order, or line item calculated by subtracting negotiated discounts, volume discounts, and other on-invoice discounts from the segment price), pocket price (final price that a company realizes for a quote, order, or line item calculated by subtracting off-invoice adjustments from the invoice price), and pocket margin (price associated with the profit that the company realizes for a quote, order, or line item calculated by subtracting the cost from the pocket price).

Finally a pricing strategy can be defined (350) using the pricing strategy elements of pricing criteria, pricing segments, guideline plans and price lists. Embodiments of the present invention provide a mechanism by which a pricing administrator can select the criterion, pricing segments, guideline plans, and price lists for the pricing strategy that are then stored by database 130.

Once the pricing strategies have been entered using embodiments of the present invention, embodiments of the present invention further allow the business entity to define and administer pricing strategies in a single location allowing for dissemination of these pricing strategies throughout the CRM environment. Embodiments of the present invention reduce the need to integrate data across disparate systems and allow for a consistent user experience. A business entity can define and administer price policies, price lists, product/service offerings, and sales workflow inclusive of pricing approval within the same solution.

Deal Management Data Model

Embodiments of the present invention provide for a customer relationship management system having a set of deal management data tables and storage that is integrated with tables and storage used by other CRM subsystems. In this manner, not only can each subsystem of the customer relationship management system access deal management data, but also user security and other management tasks can be centralized and coordinated within the CRM system.

FIG. 4 is a simplified block diagram illustrating one example of a deal management data model usable by embodiments of the present invention. FIG. 4 illustrates not only connectivity of the various deal management tables, including foreign keys from one table to another, but also an example relationship between the deal management tables and non-deal management tables (as illustrated by hatched shading on the table names (e.g., S_PARTY, S_DOC_QUOTE, and S_QUOTE_ITEM)).

As discussed above, tables provided by a deal management subsystem 230 define elements of pricing strategies that influence price negotiation processes. Elements of such pricing strategies include pricing criteria, pricing segments, guideline terms and guideline plans. Tables illustrated in FIG. 4 provide storage and relationships between that storage for the pricing strategy elements. It should be understood that embodiments of the present invention are not limited to the tables, relationships, or the data definitions illustrated in FIG. 4 and that these tables are provided for illustrative purposes. Data stored in the deal management tables can be provided, as discussed above, by a pricing administrator and is intended to be consistent across an enterprise as disseminated by the customer relationship management system.

As discussed above, in order to apply consistent pricing for customers having similar characteristics, a pricing segment can be created that associates desired characteristics with a segment that can then be associated with a group of customers having those characteristics. Primary pricing criteria aid in the definition of pricing segments. As illustrated in FIG. 4, S_PRICESEGDEF table 410 stores these primary pricing criteria as tabular columns. Each row of S_PRICESEGDEF 410 is a defined segment. A deal management system can have several pre-defined pricing criteria that are commonly used by business entities (e.g., industry type and geography) and can also provide for customization of primary pricing criteria through the addition of columns to table S_PRICESEGDEF 410.

FIG. 5 illustrates a user interface screen providing an example of definitions of pricing segments (listed as rows) with primary pricing criteria (illustrated as columns) FIG. 5 illustrates pricing criteria including “Industry,” “Customer Value,” “Geography,” “Channel,” and Cost-to-Serve (“CTS”). The various pricing segments (listed under “Name”) are defined by various values of the listed pricing criteria. For example, the pricing segment “Distributors-Tier Two” is defined by having a customer value of “high” and a channel type of “distributor.” As another example, the pricing segment “Strategics-Commercial” is defined by an industry type of “commercial,” a customer value of “very high,” a channel type of “direct,” and a cost-to-serve of “low.”

Once the pricing segments have been defined in table S_PRICESEGDEF 410, those pricing segments can then be associated with customers that are either already stored in the customer relationship management system or those who are subsequently introduced into the customer relationship management system (e.g., via an opportunity management subsystem 210). Information relating customers with segment types is provided in table S_ORG_EXT_DM 415. Table S_PARTY 417 can provide the customer list used by all subsystems of the customer relationship management system.

FIG. 6 illustrates a user interface providing an example of an association between customer accounts and pricing segments. Columns 610, 615, 620, 630 and 640 correspond to similarly identified columns from FIG. 5 (e.g., Geography, Channel, Customer Value, CTS, and Industry). These are the identified pricing segments. In addition, identifiers are associated with the various accounts defined in the customer relationship management system. Accounts (listed under “Name”) can be associated with a pricing segment (listed under “Segment Name”). Accounts can be associated within the customer relationship management system with other accounts in a parent-child relationship, as indicated by the “Parent Account” column in FIG. 6. Child accounts can have their own segment identification or can inherit their parent's segment association, as indicated in FIG. 6 by a checkmark in the “deal negotiation eligible” column. Thus, a child account can be defined to have different deal negotiation characteristics as defined by a different associated price segment.

In addition to providing pricing segments to associate various customers with one another for similar treatment, a deal management subsystem can also provide for guideline plans that determine pricing adjustments sales representatives are allowed to negotiate when creating quotes and orders. These guideline plans can apply to line items in a quote or to an entire quote or order. Data associated with such guideline plans can also be stored in deal management tables illustrated in FIG. 4. Table S_DM_GLTERM 420 can store the guideline terms associated with each guideline plan. Those terms can then be associated with a defined plan in Table S_DM_GLPLAN 425.

FIG. 7 illustrates a user interface providing an example of guideline terms 710 associated with one of a set of guideline plans 720 (“line item GLPLAN II”). The information illustrated in section 710 of FIG. 7 is provided from a guideline term table (e.g., table S_DM_GLTERM 420). The columns represent fields associated with, in this case, a line item guideline plan. The following table provides an example of fields that can be used to define a guideline term.

Field
Description

Role
The role of the user who can negotiate pricing for a quote and order. If no

value is selected, the pricing term for the line item applies to all users.

Territory
The geographic area for the customer account on the quote or order. The

values selectable for this field are the same as those selected for the region

field in the S_PRICESEGDEF Table. If no value is selected, the pricing

term for the line item applies to all territories.

Constraint Type
The nature of a price exception for the pricing term:

Constraining: a sales representative will see a red square in a

guideline field after entering a price for a quote or order that is lower

than or equal to the minimum price associated with the pricing term

for the line item.

Recommended: sales representative sees a yellow square in the

guideline field after entering a price break quote or an order that is

lower than or equal to the minimum price associated with the pricing

term for the line item.

In the quote management subsystem, if a quote line item is flagged red, the

sales representative cannot convert the quote to an order until a price

approver handles the price exception. A red flag indicates that the sales

representative violated a pricing policy. A yellow flag is a cautionary

indicator and does not prevent the sales representative from further

processing the quote or order.

Product
The product for the pricing term. If no product value is selected, the pricing

term for the line item applies to all products.

Product Line
The product line for the product. If no value is selected, the pricing term for

the line item applies to all product lines.

Product Class
The product class for the product. If no value is selected, the pricing term

for the line item applies to all product classes.

Reference Waterfall
The waterfall segment to which the pricing term applies. The price that is

Segment
associated with the pricing term for this waterfall segment is compared to

the price for the impacted waterfall segment on a quote or an order. If the

price that is associated with the pricing term for this waterfall segment is

higher than or equal to the price for the impacted waterfall segment, a price

exception results.

Values in this field can include ceiling and segment. When a price

administrator configures waterfall segments, the price administrator can

configure other values.

Impacted Waterfall
The price on this waterfall segment on a quote or an order price is compared

Segment
to the price that is associated with the pricing term for the reference

waterfall segment. Values for this field can include invoice, pocket, and

pocket margin. When a price administrator configures waterfall segments,

the price administrator can configure other values.

Start Date
The date and time the pricing term begins.

End Date
The date and time the pricing term ends.

Adjustment Type
The nature of the adjustment for the pricing term. Values include percent

discount and price override.

Term
The value that is associated with the adjustment. For example, for a percent

discount adjustment type, term will be the percentage of the percent

discount.

Section 710 of FIG. 7 illustrates values that can be associated with a product type guideline plan. As discussed above, guideline plans can also include deal-type guideline plans wherein the guideline plan is associated with the entirety of a deal rather than just an individual product within the deal. Deal type guideline plans can include many fields similar to those described above with regard to product-type guideline plans. In addition, deal-type guideline plans can include a lowest value in a deal value range (“deal min”) and a highest value in the deal value range (“deal max”). A term can be provided that is a percentage associated with the deal value range. As discussed above, table S_DM_GLPLAN 425 can include associations of various guideline terms for a plan. Various plans are listed in section 720 of FIG. 7.

Once pricing strategy elements such as pricing criteria, pricing segments, line item guideline plans, deal guideline plans and price lists have been created, as discussed above, or defined elsewhere within a customer relationship management system (as in the case of price lists), those pricing strategy elements can be used to define a pricing strategy. Table S_DM_STRATEGY 430 can contain the relationships between the various pricing strategy elements that define the pricing strategies of the enterprise.

FIG. 8 illustrates a user interface displaying an example of data that can be found in table S_DM_STRATEGY 430. As shown in FIG. 8, several defined strategies are listed under a variety of strategy names (e.g., “Improve Margin Strategics-Commercial,” “Harvest Strategics-Commercial,” and “Share Protect Strategics-Retail”). Some of the fields illustrated in the pricing strategy definition view of FIG. 8 are defined by the following table.

Field
Description

Active
If this field is checked for a pricing strategy, sales representatives can select

that strategy when creating quotes and orders. A deal management

administrator cannot change the data in the fields for that strategy once the

strategy is active.

Revision
This is the version number that is populated automatically for the defined

pricing strategy. Newly defined pricing strategies are populated with a

version number of 1. The first pricing strategy created by revising a pre-

existing pricing strategy is populated with a version number of 2.

Subsequent pricing strategies that can be created by revising pre-existing

strategies can be populated with a version number of 3, 4, and so on.

Segment Name
The name of the pricing segment for the pricing strategy.

Start Date
The date and time the pricing strategy begins.

End Date
The date and time the pricing strategy ends.

Price List Name
The identifying name of a price list for the pricing strategy. If this price list

contains ceiling prices, this list designates ceiling prices. If this price list

does not contain ceiling prices, this list designates segment prices.

Deal Guideline
The name of the deal guideline plan for the pricing strategy.

Name

Product Guideline
The name of the line item guideline plan for the pricing strategy.

Name

As illustrated in FIG. 8, additional fields can be defined and used in a pricing strategy definition table including, for example, associating a particular strategy definition with a particular type of deal (e.g., quote or order) and associating a strategy with a named competitor of the enterprise. As with other tables described herein, embodiments of the present invention are not limited to tables including the terms or items illustrated, but instead the tables are provided as examples of types of values and their interrelationships.

The deal management data model illustrated in FIG. 4 also provides for tables that define those fields which are displayed to a user when generating a quote or order, for example. For example, if additional pricing segments or pricing strategies are added, the ability to provide those segments or strategies to a user generating a quote or order can be provided by modifying Tables S_DOC_QUOTE_DM 440 and S_ORDER_DM 450 for a quote or order, respectively. Similarly, Tables S_QUOTE_ITEM_DM 445 and S_ORDER_ITEM_DM 455 define those fields that can be displayed for individual line items within a quote or an order, respectively.

Price Enforcement

One advantage embodiments of the present invention exhibit by combining a deal management data model, such as described above, with a data model already present in a CRM system (e.g., 200) is that analysis of a quote or order can be provided to a sales representative as the sales representative is entering criteria related to the quote or order. In this manner, price enforcement in line with pricing criteria can be provided throughout an enterprise, as defined by pricing administrators. In addition, should a quote or order stray from a defined pricing strategy associated with a customer, that quote or order can be flagged for follow up by a price approver who can review those price exceptions and provide feedback to the sales representative or customer regarding the pricing exception.

Price enforcement analysis begins with entry of a quote or order by the sales representative. An assumption is made that a particular customer has already been defined within an opportunity management subsystem 210 and information related to that customer is available to the sales representative.

FIG. 9A illustrates an example of a user interface that can be provided by embodiments of the present invention and used to enter a quote or order by a sales person. The view illustrated by FIG. 9A is a quote header showing information such as an account name (e.g., “Marriott International”) a name of the quote (e.g., “751A-62HMC”) and a quote number. Much of the information displayed in the quote header of FIG. 9A is the same as would normally be displayed by a customer relationship management system during the quote phase. In addition, as defined by tables such as S_DOC_QUOTE_DM 440, other fields such as “pricing segment” and “strategy” are provided. In the example provided by FIG. 9A, pricing segment field 910 shows that the account “Marriott International” is associated with pricing segment “Strategics-Commercial.” Such an association can be made by a deal management administrator when defining the various accounts in the account pricing segment profile illustrated in FIG. 6, for example. In general, a sales representative handling entry of a quote or order would not be able to change the pricing segment provided in field 910.

FIG. 9B illustrates an example of a user interface that can be provided by embodiments of the present invention to select an appropriate deal management pricing strategy. As discussed above, pricing segments and pricing lists can be associated with more than one pricing strategy. By selecting the “Strategy” field 920 of FIG. 9A, an applet can be activated which displays those pricing strategies available for the order being entered. A sales representative can use a variety of criteria associated with the customer and the nature of the deal (e.g., whether a competitor is involved) in selecting an appropriate deal strategy.

FIG. 9C illustrates an example of a user interface that can be provided by embodiments of the present invention to a sales person for entering line items associated with a quote or order. Once a pricing strategy has been selected for a particular deal or order, the sales person can enter the line items associated with the deal or order. As shown in FIG. 9C, for each entered line item, information related to that item can be displayed. In the example provided by FIG. 9C, waterfall price point information is displayed for each item. For example, ceiling price (e.g., the highest published price), segment price (e.g., a starting price offered to customers in the pricing segment), invoice price (e.g., a price minus all discounts on invoice), pocket price (e.g., invoice price minus off-invoice adjustments), and pocket margin (e.g., realized profit of the enterprise for the particular line item) are displayed.

In addition to the information related to the customer and pricing strategy and the various line items, the user interface display illustrated by FIG. 9C includes a guideline indicator (“GL”) that graphically flags whether the invoice price for the item is within the discounting policy set up in the deal management subsystem. The guideline indicator provides the sales representative immediate feedback as to whether the parameters proposed for the deal are acceptable in light of the defined pricing strategies associated with the deal.

FIG. 10 is a simplified flow diagram illustrating an example of a process that can be followed for entry and analysis of a customer quote, in accord with embodiments of the present invention. In response to a request to provide a quote, a sales representative can create a quote (1010). As discussed above, the sales representative can use an interface such as that provided in FIG. 9A to perform quote creation. Quote creation can involve associating an account with the quote (1015). By such account association, the pricing segment previously associated with the account will automatically be associated with the quote. The automatically associated Pricing Segment can be displayed, for example, in the quote header in a pricing segment field 910. The sales representative can then pick a strategy from the available strategies for the pricing segment and the customer in light of pricing lists and the like (1020).

As illustrated in FIG. 9C, the sales representative can then add line items to the quote for the various items desired by the customer (1025). To the extent that additional discounts are proposed during the course of negotiating the quote, the sales representative can add those discounts to the various line items listed (1030). At this point, the quote management subsystem, through interaction with the deal management subsystem, can gather all item and deal pricing terms associated with the quote or order based on the selected pricing strategy (1035).

FIG. 11 is a simplified flow diagram illustrating an example of a process for gathering item terms associated with a quote or order, in accord with embodiments of the present invention. As discussed above with regard to steps 1010-1030, the various parameters for the quote or order can be input (1110). A process then begins to review each line item in the quote or order (1115). A determination can then be made as to whether any product terms defined in table S_DM_GLTERM 420 have a product that is the same as an item product (1120). If this is the case, then all product terms having a same product as that of the item are selected (1125). If no product term has a product equal to the product of the item, then a determination is made as to whether any product terms have a product line equal to the item's product line (1130). If so, then all terms having the same product line as that of the item are selected (1135). If no product terms have a matching product line as that of the item, then a determination is made as to whether any product terms have a product class equal to that of the item's product class (1140). If so, then all terms having the same product class as that of the item are selected (1145). If no product term has a product class equal to the product class of the item, then a determination is made as to whether the item being analyzed is the last item of the quote or order (1150). If the present item is not the last item then the process returns to selecting the next line item for analysis (1115) and the process continues until the last item has been analyzed. If the present item is the last item, then the process can continue to selecting an appropriate deal term associated with the order, as will be discussed more fully with regard to FIG. 12 (1157).

Since more than one pricing term can be selected for a particular item, a process for selecting the best term to use in determining whether a quoted price is in alignment with a pricing strategy is used. The selection process can begin, for example, by making a determination as to whether the pricing term has a start date prior to the effective date of the quote or order (1155). If there is no pricing term with a start date before the effective date, then the process can determine whether or not this is the last item in the list (1150) and return to selecting a next line item for analysis or to go to a deal term selection logic illustrated in FIG. 12 (1157). If there are terms having a start date prior to the effective date, those items are selected for further analysis, then a determination can be made as to whether a defined role associated with those terms is the same as that associated with the quote or order (1160). The role, as discussed above, is associated with the user who is performing the entry or analysis of the quote or order. If there are no pricing terms having the same role as that of the user who is performing the analysis, then a determination can be made, for example, as to whether a pricing term having an appropriate effective date also has the same territory as that of the quote or order (1165). The territory can relate to the geographic limitations of particular pricing terms, for example. If there is no pricing term having a matching territory (or role), then terms can be selected having just the start date before the effective date (1170). If there are terms having a territory the same as that associated with the quote or order, then those terms having the matching territory as well as the start date before the effective date of the quote or order can be selected (1175).

If there are selected pricing terms having a role the same as that of the person performing the analysis as well as an appropriate effective date (1160), then a determination can be made as to whether there are also selected pricing terms having a role and territory the same as the quote or order (1180). If not, then a selection can be made of terms having a matching role along with a start date prior to the effective date (1185). If there are terms having a role and territory the same as those associated with the quote or order along with a start date prior to the effective date, then a selection can be made of those matching terms (1190).

Once this analysis of a matching of term parameters has been made, there may still be more than one term selected for a particular line item. In this case, a determination can be made of relative prioritization of guideline terms that has been predetermined by the deal management administrator when entering those guideline terms. This can be performed by a deal management administrator, for example, by having a sequence number associated with guideline terms and those terms with higher priority having a lower sequence number. Thus, selection of an appropriate guideline term in an event of more than one guideline term being available can be made by choosing the guideline term with the lowest sequence number or highest priority.

The above describes an example of criteria that can be used to select a particular guideline pricing term for a line item in a quote. Depending upon the nature of defined guideline pricing terms for an enterprise, different criteria can be used to select an appropriate guideline term from among many guideline terms available for a particular line item. Once a pricing term has been selected for a line item, that selected term identifier can be stored for use in analysis that will follow for that line item. A determination can also be made as to whether this is the last line item to be analyzed (1150), and if not then a selection can be made of the next line item and the process can continue for that line item (1115). If the last line item has been analyzed, then the process can continue to selection of an appropriate deal term to be associated with the order or quote (1157).

FIG. 12 is a simplified flow diagram illustrating a process for selecting an appropriate deal guideline term to be associated with a quote or order, in accord with embodiments of the present invention. FIG. 12 continues the process started by FIG. 11 and is entered from step 1157 (1210). A determination can be made as to whether a deal guideline term has a term value range that includes a deal value of the quote or order (1215). If there is no such deal term then there is no deal term applicable (1220) and the process can continue to step 1040 of FIG. 10 as will be described below (1275). If a deal term having a term value range including a deal value of the quote or order does exist, then the process can select deal guideline terms with a term value range including the deal value of the quote or order (1225).

Since there can be more than one deal guideline term matching the above criteria, as discussed above with regard to line item guideline terms, a selection process can be performed for determining an appropriate deal term. For example, a determination can be made as to whether a deal term has a start date prior to the effective date of the quote or order (1230). If there is no such deal term then there are no deal terms applicable to the current deal (1220) and the process can continue by returning to the flow of FIG. 10 (1275).

If a deal term has a start date prior to the effective date, then a determination can be made as to whether a role associated with the deal term is the same as that of the person performing the analysis of the quote or order (1235). If not, then a determination can be made as to whether a deal term has an associated territory the same as that associated with the quote or order (1240). If not, then the process can select those deal terms just having a start date prior to the effective date of the deal or order (1245). If there are deal terms having the same territory as that of the quote or order as well as a start date prior to the effective date of the quote or order (1240), then a selection can be made of those deal terms having the appropriate territory and starting date prior to the effective date of the quote or order (1250).

If there are deal terms having a start date prior to the effective date as well as a role matching that of the person performing the analysis (1235), then a determination can be made as to whether any of those deal terms also have an associated territory that is the same as that associated with the quote or order (1255). If not, then the process can select deal terms having an associated role corresponding to that of the person performing the analysis and an associated start date prior to the effective date of the quote or order (1260). If there are deal terms having an associated start date prior to the effective date and an associated role matching that of the person performing the analysis and a territory corresponding to that of the quote or order (1255), then a selection can be made of deal terms having matched all those parameters (1265).

As with the selection process for line item guideline terms, there can be more than one deal term that matches the various parameters of the quote or order. Selection can then be made of the deal term having the highest priority, for example, having the lowest sequence number as described above (1270). Once a deal term has been selected to be associated with the quote or order, that deal guideline term can be stored for use in further analysis. The process can then return to the analysis flow of FIG. 10 (1275).

Once the item and deal guideline terms have been selected for each line item and the overall deal, each quoted line item can be matched to its appropriate price in the price list associated with the deal (1040). A determination can then be made as to whether the deal itself is outside of the deal guideline term associated with the deal (1045). If the deal is outside of the guideline then a guideline violation can be stored and a guideline flag associated with the deal can be set for display to the user (1050). A variety of thresholds can be associated with a deal violation such that flagged information can be more than just binary. For example, a merely cautionary flag can be provided (yellow) if the deal parameters are within a certain range and then to a fatal flag (red) if the deal parameters exceed a particular threshold. A determination can then be made as to whether any line item is outside of the associated item guideline term determined above (1055). If so, then the item guideline violation can be stored and an informative flag can be set for display to the user (1060). The item flags can then be displayed to the user (e.g., red/yellow/green) for each item (1065) and the deal flag can be set as appropriate (1070) and all determined information can then be displayed to the user (1080).

The process illustrated by FIGS. 10, 11 and 12, as well as shown in FIGS. 9A-C, shows the advantages of having the integrated system of the present invention. By integrating the deal management tables with those of the customer relationship management system, customer relationship to the pricing segment is already present through the opportunity management entry of the customers and the administrative coding of the pricing segments. Further, rules regarding the pricing of various line items are already present through the coding of pricing criteria and a single version of an appropriate price list is provided across the enterprise through the customer relationship management system. Through this integration, flagging of items and deals that are out of guideline becomes a quick calculation in real-time and is provided in a screen that is already familiar to the user performing the quote or order entry.

An Example Computing and Network Environment

As shown above, the present invention can be implemented using a variety of computer systems and networks. An example of one such computing and network environment is described below with reference to FIGS. 13 and 14.

FIG. 13 depicts a block diagram of a computer system 1310 suitable for implementing aspects of the present invention (e.g., servers 120, gateway server 150, clients 160 and web clients 165). Computer system 1310 includes a bus 1312 which interconnects major subsystems of computer system 1310, such as a central processor 1314, a system memory 1317 (typically RAM, but which may also include ROM, flash RAM, or the like), an input/output controller 1318, an external audio device, such as a speaker system 1320 via an audio output interface 1322, an external device, such as a display screen 1324 via display adapter 1326, serial ports 1328 and 1330, a keyboard 1332 (interfaced with a keyboard controller 1333), a storage interface 1334, a floppy disk drive 1337 operative to receive a floppy disk 1338, a host bus adapter (HBA) interface card 1335A operative to connect with a Fibre Channel network 1390, a host bus adapter (HBA) interface card 1335B operative to connect to a SCSI bus 1339, and an optical disk drive 1340 operative to receive an optical disk 1342. Also included are a mouse 1346 (or other point-and-click device, coupled to bus 1312 via serial port 1328), a modem 1347 (coupled to bus 1312 via serial port 1330), and a network interface 1348 (coupled directly to bus 1312).

Bus 1312 allows data communication between central processor 1314 and system memory 1317, which may include read-only memory (ROM) or flash memory (neither shown), and random access memory (RAM) (not shown), as previously noted. The RAM is generally the main memory into which the operating system and application programs are loaded. The ROM or flash memory can contain, among other code, the Basic Input-Output system (BIOS) which controls basic hardware operation such as the interaction with peripheral components. Applications resident with computer system 1310 are generally stored on and accessed via a computer-readable medium, such as a hard disk drive (e.g., fixed disk 1344), an optical drive (e.g., optical drive 1340), a floppy disk unit 1337, or other storage medium. Additionally, applications can be in the form of electronic signals modulated in accordance with the application and data communication technology when accessed via network modem 1347 or interface 1348.

Storage interface 1334, as with the other storage interfaces of computer system 1310, can connect to a standard computer-readable medium for storage and/or retrieval of information, such as a fixed disk drive 1344. Fixed disk drive 1344 may be a part of computer system 1310 or may be separate and accessed through other interface systems. Modem 1347 may provide a direct connection to a remote server via a telephone link or to the Internet via an internet service provider (ISP). Network interface 1348 may provide a direct connection to a remote server via a direct network link to the Internet via a POP (point of presence). Network interface 1348 may provide such connection using wireless techniques, including digital cellular telephone connection, Cellular Digital Packet Data (CDPD) connection, digital satellite data connection or the like.

Many other devices or subsystems (not shown) may be connected in a similar manner (e.g., document scanners, digital cameras and so on). Conversely, all of the devices shown in FIG. 13 need not be present to practice the present invention. The devices and subsystems can be interconnected in different ways from that shown in FIG. 13. The operation of a computer system such as that shown in FIG. 13 is readily known in the art and is not discussed in detail in this application. Code to implement the present invention can be stored in computer-readable storage media such as one or more of system memory 1317, fixed disk 1344, optical disk 1342, or floppy disk 1338. The operating system provided on computer system 1310 may be MS-DOS®, MS-WINDOWS®, OS/2®, UNIX®, Linux®, or another known operating system.

Moreover, regarding the signals described herein, those skilled in the art will recognize that a signal can be directly transmitted from a first block to a second block, or a signal can be modified (e.g., amplified, attenuated, delayed, latched, buffered, inverted, filtered, or otherwise modified) between the blocks. Although the signals of the above described embodiment are characterized as transmitted from one block to the next, other embodiments of the present invention may include modified signals in place of such directly transmitted signals as long as the informational and/or functional aspect of the signal is transmitted between blocks. To some extent, a signal input at a second block can be conceptualized as a second signal derived from a first signal output from a first block due to physical limitations of the circuitry involved (e.g., there will inevitably be some attenuation and delay). Therefore, as used herein, a second signal derived from a first signal includes the first signal or any modifications to the first signal, whether due to circuit limitations or due to passage through other circuit elements which do not change the informational and/or final functional aspect of the first signal.

FIG. 14 is a block diagram depicting a network architecture 1400 in which client systems 1410, 1420 and 1430, as well as storage servers 1440A and 1440B (any of which can be implemented using computer system 1310), are coupled to a network 1450. Storage server 1440A is further depicted as having storage devices 1460A(1)-(N) directly attached, and storage server 1440B is depicted with storage devices 1460B(1)-(N) directly attached. Storage servers 1440A and 1440B are also connected to a SAN fabric 1470, although connection to a storage area network is not required for operation of the invention. SAN fabric 1470 supports access to storage devices 1480(1)-(N) by storage servers 1440A and 1440B, and so by client systems 1410, 1420 and 1430 via network 1450. Intelligent storage array 1490 is also shown as an example of a specific storage device accessible via SAN fabric 1470.

With reference to computer system 1310, modem 1347, network interface 1348 or some other method can be used to provide connectivity from each of client computer systems 1410, 1420 and 1430 to network 1450. Client systems 1410, 1420 and 1430 are able to access information on storage server 1440A or 1440B using, for example, a web browser or other client software (not shown). Such a client allows client systems 1410, 1420 and 1430 to access data hosted by storage server 1440A or 1440B or one of storage devices 1460A(1)-(N), 1460B(1)-(N), 1480(1)-(N) or intelligent storage array 1490. FIG. 14 depicts the use of a network such as the Internet for exchanging data, but the present invention is not limited to the Internet or any particular network-based environment.

Other Embodiments

The present invention is well adapted to attain the advantages mentioned as well as others inherent therein. While the present invention has been depicted, described, and is defined by reference to particular embodiments of the invention, such references do not imply a limitation on the invention, and no such limitation is to be inferred. The invention is capable of considerable modification, alteration, and equivalents in form and function, as will occur to those ordinarily skilled in the pertinent arts. The depicted and described embodiments are examples only, and are not exhaustive of the scope of the invention.

The foregoing describes embodiments including components contained within other components (e.g., the various elements shown as components of computer system 1310). Such architectures are merely examples, and, in fact, many other architectures can be implemented which achieve the same functionality. In an abstract but still definite sense, any arrangement of components to achieve the same functionality is effectively “associated” such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as “associated with” each other such that the desired functionality is achieved, irrespective of architectures or intermediate components. Likewise, any two components so associated can also be viewed as being “operably connected,” or “operably coupled,” to each other to achieve the desired functionality.

The foregoing detailed description has set forth various embodiments of the present invention via the use of block diagrams, flowcharts, and examples. It will be understood by those within the art that each block diagram component, flowchart step, operation and/or component illustrated by the use of examples can be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or any combination thereof, including the specialized system illustrated in FIG. 1.

The present invention has been described in the context of fully functional computer systems; however, those skilled in the art will appreciate that the present invention is capable of being distributed as a program product in a variety of forms, and that the present invention applies equally regardless of the particular type of computer-readable media used to actually carry out the distribution. Examples of computer-readable media include computer-readable storage media, as well as media storage and distribution systems developed in the future.

The above-discussed embodiments can be implemented by software modules that perform one or more tasks associated with the embodiments. The software modules discussed herein may include script, batch, or other executable files. The software modules may be stored on a machine-readable or computer-readable storage media such as magnetic floppy disks, hard disks, semiconductor memory (e.g., RAM, ROM, and flash-type media), optical discs (e.g., CD-ROMs, CD-Rs, and DVDs), or other types of memory modules. A storage device used for storing firmware or hardware modules in accordance with an embodiment of the invention can also include a semiconductor-based memory, which may be permanently, removably or remotely coupled to a microprocessor/memory system. Thus, the modules can be stored within a computer system memory to configure the computer system to perform the functions of the module. Other new and various types of computer-readable storage media may be used to store the modules discussed herein.

The above description is intended to be illustrative of the invention and should not be taken to be limiting. Other embodiments within the scope of the present invention are possible. Those skilled in the art will readily implement the steps necessary to provide the structures and the methods disclosed herein, and will understand that the process parameters and sequence of steps are given by way of example only and can be varied to achieve the desired structure as well as modifications that are within the scope of the invention. Variations and modifications of the embodiments disclosed herein can be made based on the description set forth herein, without departing from the scope of the invention.

Consequently, the invention is intended to be limited only by the scope of the appended claims, giving full cognizance to equivalents in all respects.

Although the present invention has been described in connection with several embodiments, the invention is not intended to be limited to the specific forms set forth herein. On the contrary, it is intended to cover such alternatives, modifications, and equivalents as can be reasonably included within the scope of the invention as defined by the appended claims.

DEAL MANAGEMENT IN A CUSTOMER RELATIONSHIP MANAGEMENT ENVIRONMENT

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

US Classifications

International Classifications

Abstract

Description

Claims

CROSS REFERENCE TO RELATED APPLICATIONS

Provisional Applications (1)