Abstract:
A method and system for optimizing dynamic prices of reserved date-constrained services such as airline flight reservations or hotel stay reservations. Comparative trials of complex pricing policies are employed according to an application schedule that has a periodic character with respect to the arrival date of quoting circumstances. On the basis of the comparative trials, some policies are identified as contributing less revenue on average to the system than other policies. The underperforming policies are then eliminated from the application schedule, which increases the expected future revenue of the resulting system.

Description:
CROSS-REFERENCE TO RELATED APPLICATION  
       [0001]    This application claims the benefit under 35 U.S.C. § 119 of commonly owned U.S. Provisional Application Serial No. 60/366,717 entitled “Revenue Management System and Process for Testing Alternative Pricing Policies,” filed Mar. 22, 2002, which is incorporated herein by reference. 
     
    
     
       BACKGROUND OF THE INVENTION  
         [0002]    This invention relates to the practice of revenue management, which is the process of dynamically adjusting prices of goods or services in response to changes in market conditions or changes in supply conditions. Revenue management processes were pioneered by the passenger airline industry and have been imitated by other industries such as cargo airlines, hotels, rentals, shippers, advertisement brokers and others.  
           [0003]    A very common application of revenue management relates to service providers who are taking reservation for “date-constrained services”. By “date-constrained services,” we mean that the provider will impose transaction-specific limits on the date when the buyer may use the service they purchase. Examples of such a restrictions include specified arrival and departure dates for an airline reservation as well as specified check-in and check-out dates for a hotel reservation. Airline and hotel reservations do represent a “date-constrained service” because the customer is required to use their ticket on a specific date, which was selected by the customer at the time of the purchase or transaction or reservation. Hotel reservations, rental reservations and media advertisement slots are also “date-constrained services” for precisely the same reason. In cases where the date constraint is not firm, such as an airline ticket that may be rescheduled with or without penalty, we still consider the purchase to be “date-constrained” if a payment or process, such as rebooking, is needed to alter the date constraint.  
           [0004]    A multitude of processes and methods have been designed to address the problem of optimizing price of buying or reserving a date-constrained service. Some of these are described in the following patents and journal publications, which are believed to be relevant to the present invention:  
                                                 U.S. patents                                    5,918,209   June 1999   Campbell, et al.           5,652,867   July 1997   Barlow, et al.                      
 
         Journal Articles  
         [0005]    Peter P. Belobaba, “Airline Yield Management, An Overview of Seat Inventory Control,”  Transportation Science , Vol. 21, (No. 2), p. 63-73, (May, 1987).  
           [0006]    P. Belobaba, “Application of a Probabilistic Decision Model to Airline Seat Inventory Control,”  Operations Research , Vol. 37, pp. 183-197 (Mar. 4, 1989).  
           [0007]    Garret J. van Ryzin, “Revenue Management Under Consumer-Behaviour Models of Demand,”  IATA Revenue Management and Pricing Conference , Oct. 15, 2002.  
           [0008]    Typically these processes address the problem according to a three-step approach:  
           [0009]    1. fit a mathematical model of demand to historic sales records;  
           [0010]    2. project the demand model into the future; and  
           [0011]    3. use “What-If?” analysis to see which prices would maximize revenue in the future.  
           [0012]    Sometimes the step of fitting a demand model is called “unconstraining demand.” Sometimes the step of projecting the demand model into the future is called “forecasting.” Sometimes the step of applying “What-If?” analysis is called “optimization.”  
           [0013]    Elaborate efforts and investments have been made to develop specific processes to execute these steps in the most accurate possible way. A classic method for optimizing a demand model is described by Belobaba (1987, 1989). More complex methods of optimizing the demand model are described in U.S. Pat. No. 5,652,867 and U.S. Pat. No. 5,918,209. These and many other examples illustrate that revenue management processes have firmly adopted the three-step approach described above.  
           [0014]    However, recent studies have drawn attention to the tremendous difficulty of fitting a demand model accurately. For example, van Ryzin (2002) shows that there is a substantial discrepancy between the fitted mathematical model of demand and the real behavior of a market of customers. His work shows that the discrepancy undermines the validity of the three-step approach and reduces its effectiveness.  
           [0015]    Complex model fitting methods have been proposed in order to reduce the discrepancy. However, there are many reasons why such methods may be impractical. One reason that the data required to fit such models may exceed the data available. Another reason is that the methodology may be too complicated to be understood by a manager who is responsible for supervising this process.  
           [0016]    Consequently, conventional revenue management processes heretofore known are generally limited in application to real markets as follows:  
           [0017]    (a) they require highly complex calculations to be implemented and tested;  
           [0018]    (b) they are not easily supervised because the complex equations involved are confusing to most operations managers; and  
           [0019]    (c) they are inaccurate because they are based on demand models that do not faithfully represent the complex details of consumer behavior.  
         BRIEF SUMMARY OF THE INVENTION  
         [0020]    In view of the foregoing, a need exists for a method of revenue management that robustly incorporates the complex behavior of consumers as well as other complex considerations without involving processes that are too complex to be properly tested by developers or properly supervised by system managers. The present invention satisfies this need through a unique design that incorporates comparative trials of complex pricing policies.  
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0021]    The features and advantages of the present invention will become apparent form the following detailed description of a preferred embodiment thereof, taken in conjunction with the accompanying drawings, in which:  
         [0022]    [0022]FIG. 1 is a schematic diagram of networked computer system that can be employed to implement the preferred embodiment of the present invention;  
         [0023]    [0023]FIG. 2 is an example of a pricing policy table that is employed to illustrate the functionality of the preferred embodiment;  
         [0024]    [0024]FIG. 3 is an example of an application schedule table that is employed to illustrate the functionality of the preferred embodiment; and  
         [0025]    [0025]FIG. 4, FIG. 5 and FIG. 6 are flow charts illustrating the logic used in an exemplary application of the preferred embodiment. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0026]    A pricing policy is defined as a rule for determining the price of a service based on specific measures or statistics that are known to the service provider at the time of the purchase or reservation. For example, a hotel might employ a policy that sets the quote for reserving a room at $50 for any date where 10 or more rooms are still unreserved and also sets the charge at $100 when fewer than 10 rooms are yet unreserved. A pricing policy might also be based on such factors as the price or availability of competitor services. Many other considerations are possible as well.  
         [0027]    It is preferred that each pricing policy should have a name or other unique identifier that may be used to reference it. It is also preferred that the policy should be parameterized by an ordered set of inventory threshold values and an associated ordered set of prices. To illustrate this design, reference is made to FIG. 2, which represents a typical state of the pricing policy table  21 . In this case, the pricing policy table  21  describes just two pricing policies. The first is referenced by the unique identifier “greedy” and represents a policy of quoting a reserved service at $50/day for any reservation period where 10 or more rooms are still unreserved and at $100/day if 1 or more rooms are still unreserved. The second pricing policy is referenced by the unique identifier “generous” and represents a policy of quoting a reserved service at $50/day for any reservation period where 5 or more rooms are still unreserved and at $100/day if 1 or more rooms are still unreserved.  
         [0028]    An application schedule is defined as a rule for determining which policy should be used at various times or circumstances of computing a quote. For example, an application schedule might represent that a pricing policy referenced by the identifier “greedy” is applied under the condition that we are making a quote for a reservation that begins on a Monday, while a pricing policy referenced by the identifier “generous” is applied under all other conditions.  
         [0029]    In the operation of the system  10 , a system operator periodically enters a new policy rule and a unique identifier into one of the computers  12 . The response to this action is illustrated in FIG. 4. In response, the pricing policy server  13  creates a new record in the pricing policy table, which hereafter stores the new policy rule and its associated identifier. In further response, the application schedule server  14  generates a new application schedule. It is preferred that the application schedule is parameterized by the arrival date of the quote condition and that it repeats in a periodic fashion with periodicity  2 ,  3  or  5 . These patterns are desirable because they ensure that the impact of each pricing policy on total system revenue will be more easily assessed and compared.  
         [0030]    [0030]FIG. 3 illustrates one possible state of the application schedule table  31  wherein pricing policies identified by the references “greedy”, “neutral” and “generous” are scheduled to apply to various quote conditions. In this case the represented application schedule has periodicity of 3 because the same pricing policy is applied whenever the arrival date of distinct quote circumstances differs by an integer multiple of 3. Many similar configurations of application schedule table  31  are possible. Such variations could incorporate additional pricing policies.  
         [0031]    In further operation of the system  10 , a system operator periodically enters a request for a price quote for a particular resource on a given set of reservation dates into one of the computers  12 . The response to this action is illustrated in FIG. 5. In response, the computer contacts the application schedule server  14  to access the application schedule table and then contacts the pricing policy server  13  to access the pricing policy table. The control logic for using the tables is that the application schedule table is searched in order to determine which pricing policy is scheduled to apply to the conditions entered by the system operator. Hereafter the found policy is referred to as the “matching policy.” The control logic further dictates that the pricing policy table should be searched to find the definition of the matching policy. The control logic further dictates that the defined rule of the matching policy be applied to the conditions of the quote request to determine the final value that is to be quoted to the customer.  
         [0032]    Additional control logic is executed periodically according to a timer event, which may be configured to occur once per week or on any other periodic basis. The purpose of this additional logic is to identify which if any of the pricing policies represented in the application schedule table may be under-performing in terms of its contribution to the total system profit achieved by the quoting process.  
         [0033]    The response to the timer event is illustrated in FIG. 6. In response to the timer event the control logic executing in computer  12  to access database of historic reservations  15  to retrieve all purchase records that have been created in the time since the application schedule was last modified. The control logic then computes a transaction-level performance metric for each of the sales records and replicates the steps for determining an associated pricing policy (as outlined above) for each such sales record. The preferred method for computing this metric is to subtract the operational costs of servicing the reservation as well as other applicable costs from the total revenue associated with the reservation. A total contribution for each pricing policy is then computed by summing the transaction level performance metric over all transactions associated with said pricing policy. Finally, the control logic proceeds to compare the computed sums and determine which of the active policies has the lowest associated sum and this pricing policy is then removed from the pricing policy table. A new application schedule is then computed in the same manner described previously.  
         [0034]    The benefit of executing this final step derives from the fact that the modified system will tend to achieve greater revenues than the original system due to the increased representation of pricing polices that have higher contribution levels on average and due to the reduced representation of pricing policies that have lower contribution levels on average.  
         [0035]    In conclusion, the present invention, through the use of comparative trials of complex pricing policies which are applied according to an application schedule that has a periodic character with respect to the arrival date of quoting circumstances, provides a vastly improved and robust revenue management system and method that can easily incorporate complex considerations and be easily implemented without requiring complex computer software. Although the present invention has been disclosed in terms of a preferred embodiment and variations thereon, it will be understood that numerous additional variations and modifications could be made thereto without departing from the scope of the invention as set forth in the following claims.