Automated computer price tracking, evaluation, and negotiation optimization

Abstract

Provided herein are methods, systems, and non-transitory computer-readable media that provide predictive rates based on information about the asset, the customer, and the amenities proposed by the supplier. The rates may be based on many factors that may be extracted or derived from historical bidding data, including, but not limited to, the asset's location and market tier, the length of the relationship with the channel (which may be an account or customer), the amenities included, the cancellation policy, the size of the account's or channel's event, the booking season, and the proximity of the account's or channel's, or channel's, office to the asset. Increasing confidence that the customer is getting a fair rate facilitates negotiations between the parties to a contract.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of priority to U.S. Provisional Patent Application No. 62 / 905,755, filed September 25, 2019, U.S. Provisional Patent Application No. 62 / 907,305, filed September 27, 2019, and U.S. Provisional Patent Application No. 16 / 728,241, filed December 27, 2019, the entire contents of which are incorporated herein by reference.

[0002] This disclosure relates to price tracking, valuation, and negotiation optimization. [Background technology]

[0003] Introduction

[0002] Prices for hospitality products, such as hotel rooms or meeting spaces, can be highly subjective and can fluctuate based on variables that are not directly related to the product, supply, or demand. For example, offered or accepted prices can be based on unpredictable or inconsistent properties, which can undermine customer confidence in the proposed or accepted rates. This can cause consumers to be uncertain about whether they are getting a fair price for the space. Therefore, it can be advantageous to use automated machine learning software to monitor proposed and final negotiated rates for various spaces based on objective information. Thus, a tool is proposed that relates historical pricing points to data points related to negotiations or properties. For example, the desirability of the location, time of year, amenities available in the space, size of the space, services included, cancellation policies, information about the parties to the negotiation (i.e., the parties' location, equity, or size), how long the parties have been negotiating, time of negotiation, size of the account, number of customers that accepted bids in the last period year, or the proximity of customer offices to the asset. A buyer facing tool may give users the ability to forecast pricing to aid potential buyers in their negotiations. Summary of the Invention

[0004]

[0003] Additional features and advantages of the present disclosure will be set forth in the description which follows, and in part will be apparent from the description, or may be learned by practice of the principles disclosed herein. The features and advantages of the present disclosure may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the present disclosure will become more fully apparent from the following description and the appended claims, or may be learned by practice of the principles described herein.

[0005]

[0004] A system, method, and non-transitory computer-readable storage medium, technical solutions to the described technical problems, are disclosed. a data collector configured to collect historical proposed rates, historical accepted rates, historical product characteristics, and historical customer characteristics; and a data cleaner configured to receive the historical proposed rates, historical accepted rates, historical product characteristics, and historical customer characteristics from the data collector, convert the historical proposed rates and historical accepted rates to current currency values, remove outliers from the converted historical proposed rates and converted historical accepted rates, assign the converted historical proposed rates and converted historical accepted rates to clean numeric variables, assign the historical product characteristics and historical customer characteristics to characteristic variables, generate calculated variables, generate numeric rates for the characteristic variables based on the new calculated variables, the characteristic variables, and the numeric variables, split the numeric rates into a first data group, a second data group, and a third data group, perform training on the first data group, perform validation on the second data group, and perform testing on the third data group. and a model builder configured to build a predictive model based on training, validation, and testing. and a rate predictor configured to receive the predictive model, receive input from a user regarding channel characteristics, asset characteristics, and season, input the channel characteristics, asset characteristics, and season to the predictive model, generate predictions from the predictive model, and output the predictions to a user.

[0006]

[0005] A method for collecting historical proposed rates, historical acceptable rates, historical product characteristics, and historical customer characteristics, converting the historical proposed rates and historical acceptable rates to current currency values, removing outliers from the converted historical proposed rates and the converted historical acceptable rates, assigning the converted historical proposed rates and the converted historical acceptable rates to clean numeric variables, assigning the historical product characteristics and the historical customer characteristics to characteristic variables, generating calculated variables, generating numeric rates for the characteristic variables based on the new calculated variables, the characteristic variables, and the numeric variables, and converting the numeric rates into a first data group. 11. A method comprising: splitting data into a loop, a second data group, and a third data group; performing training on the first data group, performing validation on the second data group, performing testing on the third data group; building a predictive model based on the training, validation, and testing; receiving the predictive model; receiving input from a user regarding channel characteristics, asset characteristics, and season; inputting the channel characteristics, asset characteristics, and season into the predictive model; generating a forecast from the predictive model; and outputting the forecast to the user.

[0007]

[0006] A computer readable storage medium configured as disclosed herein may store instructions that, when executed by a computing device, cause the computing device to perform a method, the method including determining an asset characteristic for an asset, assigning a numerical asset value to the asset characteristic using a pricing model, determining a channel characteristic for a channel, and assigning a numerical channel value to the channel characteristic using the pricing model, determining a negotiation characteristic for a negotiation, and assigning a numerical negotiation value to the negotiation characteristic using the pricing model, determining a season characteristic for a season, and assigning a numerical season value to the season characteristic using the pricing model, determining a term characteristic for a term, and assigning a numerical term value to the term characteristic using the pricing model, receiving a paid price from the user device, and the first group, the second group, and the third group; performing training on the first group, performing validation on the second group, and performing testing on the third group; and updating the pricing model based on the training, validation, and testing. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 illustrates an exemplary system embodiment. [Diagram 2] FIG. 1 illustrates an exemplary embodiment configuration. [Diagram 3]

[0009] FIG. [Figure 4]

[0010] FIG. [Diagram 5]

[0011] FIG. 1 illustrates an exemplary user interface. [Figure 6]

[0012] FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009]

[0013] Various embodiments of the present disclosure are described in detail below. While specific implementations are described, it should be understood that this is done for illustrative purposes only. Other components and configurations may be used without departing from the spirit and scope of the present disclosure.

[0010]

[0014] The present disclosure is directed to methods, systems, and non-transitory computer readable media that provide forecasted rates based on information about the asset, the customer, and the amenities proposed by the supplier. The rates may be based on many factors that may be extracted or derived from historical bidding data, including, but not limited to, the location and market tier of the asset, the length of the relationship with the channel (which may be an account or a customer), the amenities included, the cancellation policy, the size of the account's or channel's event, the booking season, and the proximity of the account's or channel's, or the channel's office, to the asset.

[0011]

[0015] An embodiment of the system may build trust in a business community that members of the business community will get a fair rate from the asset, which may be a hotel or meeting space with which the member is interacting. Increasing customer trust in the customer's negotiating position may help reduce the number of negotiations between the customer and the property owner, manager, or negotiating party by giving the customer information on what is the prevailing price for similarly situated customers for the asset and the desired amenities or services. The prevailing price may be determined using machine learning models or algorithms that provide negotiation assistance for the demand based on past negotiations for similar assets (same rate type, room type, tier, location, etc.) for this customer and other customers. Amenities considered may include breakfast, parking, fitness area, internet access, shuttle service, business center, etc. The negotiated rate may further take into account information about the customer that may affect the customer's desirability for the asset or the desirability of the asset to the customer. Customer information may include whether the customer has an account with the asset, the customer's proximity to the asset, or the size of the customer.

[0012]

[0016] The system may include machine learning algorithms to provide pricing based on many different factors, including how long the client has been negotiating, the client's proximity to the asset, the client's size, or the client's net worth. Those data points may be used to train the algorithm. The outcome of the negotiation may then be used to further train the algorithm. Continuous learning by the algorithm may reduce the error rate of predictability over time.

[0013]

[0017] In some embodiments, the user may input information about the expected bid, such as desired season, rate type, room type, and amenities. The user device may inform the user of the price that should be offered, taking into account the amenities that should be offered at the proposed rate (an algorithm may determine the price based on the current amenities offered). This may be in the form of a checkbox displayed next to the rate or a graph. If the user wants to see how the price changes when a different set of amenities is selected, the negotiation assistant must update and reflect the new "suggested price" to the user.

[0014]

[0018] Additionally, the program may present an initial recommended rate range to the customer within which the customer can expect their negotiated rate to fall. This initial rate range may be established based on any default amenities that may be populated in the bid details from the asset profile, or cancellation policies derived from the supplier provided bid rate plan. The recommended rate range may change if the company changes amenities or policies. In other embodiments, amenities may be added if the supplier did not pre-populate its asset profile with default amenities, and thus no pre-population of amenities occurred. A list of specific fields may be provided that, if modified, may change the recommended rate range.

[0015]

[0019] There may be logic that dictates when a recommended rate range appears. For example, when there are not enough data points in a particular market to drive a rate range with an acceptable standard deviation (thus making the range of recommended rates too large). In some embodiments, an asset that does not have enough data points may be compared to other, similar assets (as well as similar markets, room types, etc.) if the standard deviation is such that the recommended rate range would be too large to give value in providing a range; for example, if the recommended rate range is between $100 and $300, this would not be worthwhile for the customer. Thus, inappropriate ranges may be prevented by performing a check on the size of the range based on a comparison of the range size to the median price. Additionally, "outliers" may be cleaned from the data to prevent bad data from affecting the algorithm.

[0016]

[0020] There may also be logic that will allow interpretation of the results of the recommendations. For example, a customer may get a notification if the initial rate of the property was greater than the upper limit of the suggested rate range. The notification may indicate to the customer that the data suggests that the customer should expect a better rate than what is being offered, given the offered amenities, policies, etc. in the bid rate. Conversely, if the initial rate of the property fell below the recommended rate range lower limit, the notification may indicate that the data suggests that the customer is getting a better offer, given the expected rate range calculated by the system. Additionally, there may be logic that compares the offered price to the suggested value. If the offered price is better, the user may be prompted to select the offered rate over the suggested rate.

[0017]

[0021] With reference to FIG. 1, an exemplary system includes a general-purpose computing device 100 including a processing unit (CPU or processor) 120 and a system bus 110 that couples various system components, including a system memory 130, such as a read-only memory (ROM) 140 and a random access memory (RAM) 150, to the processor 120. The computing device 100 may include a cache of high-speed memory directly connected to the processor 120, in close proximity to the processor 120, or integrated as part of the processor 120. The computing device 100 copies data from the memory 130 and / or storage device 160 to the cache for quick access by the processor 120. In this manner, the cache provides a performance boost that avoids delays in the processor 120 while waiting for data. These and other modules may control or be configured to control the processor 120 to perform various actions. Other system memories 130 may also be available for use. The memory 130 may include multiple different types of memory with different performance characteristics. It may be appreciated that the present disclosure may operate on a computing device 100 with more than one processor 120, or on a group or cluster of computing devices networked together to provide greater processing power. The processor 120 may include any general-purpose processor and hardware or software modules, such as module 1 162, module 2 164, and module 3 166 stored in storage device 160, configured to control the processor 120 as well as special-purpose processors, where software instructions are incorporated into the actual processor design. The processor 120 may essentially be a fully self-contained computing system, including multiple cores or processors, buses, memory controllers, caches, etc. Multi-core processors may be symmetric or asymmetric.

[0018]

[0022] The system bus 110 may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. A basic input / output (BIOS), stored in ROM 140 or the like, may provide basic routines that help transfer information between elements within the computing device 100, such as during start-up. The computing device 100 further includes a storage device 160, such as a hard disk drive, a magnetic disk drive, an optical disk drive, a tape drive, or the like. The storage device 160 may include software modules 162, 164, 166 for controlling the processor 120. Other hardware or software modules are contemplated. The storage device 160 is connected to the system bus 110 by a drive interface. The drives and associated computer-readable storage media provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computing device 100. In one aspect, a hardware module that performs a particular function includes software components stored on a tangible computer-readable storage medium in association with the necessary hardware components, such as the processor 120, the system bus 110, the output device 170, which may be a display, to perform that function. In another aspect, the system may employ a processor and a computer-readable storage medium for storing instructions that, when executed by the processor, cause the processor to perform a method or other particular action. The basic components and suitable variations are contemplated depending on the type of device, such as whether the computing device 100 is a small handheld computing device, a desktop computer, a computer server, etc.

[0019]

[0023] The exemplary embodiment described herein employs storage device 160, which may be a hard disk, although other types of computer-readable media capable of storing data that is accessible by a computer may also be used in the exemplary operating environment, such as magnetic cassettes, flash memory cards, digital versatile disks, cartridges, random access memory (RAM) 150, and read-only memory (ROM) 140. Tangible computer-readable storage medium, computer-readable storage device, or computer-readable memory device specifically excludes media such as ephemeral waves, energy, carrier signals, electromagnetic waves, and the signals themselves.

[0020]

[0024] To enable user interaction with computing device 100, input device 190 represents any number of input mechanisms, such as a microphone for voice, a touch-sensitive screen for gesture or graphical input, a keyboard, a mouse, motion input, voice, etc. Output device 170 may also be one or more of several output mechanisms known to those skilled in the art. In some cases, a multimodal system allows a user to provide multiple types of input to communicate with computing device 100. Communication interface 180 generally governs and manages user input and system output. There is no restriction to operating on any particular hardware configuration, and thus the basic features herein may be readily substituted with improved hardware or firmware configurations as they are developed.

[0021]

[0025] Use of language such as "at least one of X, Y, and Z," "at least one of X, Y, or Z," "at least one or more of X, Y, and Z," "at least one or more of X, Y, or Z," "at least one or more of X, Y, and / or Z," or "at least one of X, Y, and / or Z" is intended to include both a single item (e.g., only X, or only Y, or only Z) and multiple items (e.g., {X and Y}, {X and Z}, {Y and Z}, or {X, Y, and Z}). The phrase "at least one of" and similar phrases does not convey a requirement that each possible item must be present, although each possible item may be present.

[0022]

[0026] 2 is a block diagram of an exemplary embodiment. The system may be divided into three stages, a data collection stage 202, a data manipulation and cleaning stage 204, and a data refinement stage 206 for model building. The data collection stage 202 may collect data including a proposed rate for an asset 208, which may be a hotel, and a currency daily conversion chart 210, and an acceptable rate 212 may include any amenities. The proposed rate, currency daily conversion chart 210, and acceptable rate 212 for the asset 208 may be provided for currency conversion 220, which may be performed in the data manipulation and cleaning stage 204. The proposed rate and acceptable rate 212 may be converted to a corresponding rate at the time at 220. The conversion may be for inflation or for the type of currency, for example, it may be converted from Euros to US Dollars. At 222, the converted proposed rate for the asset 208 and the converted acceptable rate 212 may be cleaned to remove outliers. The outliers may be the highest and lowest few data points. In other embodiments, the outliers may be data points that deviate from the other data points by some amount, for example, outside the standard deviation. At 224, the remaining converted proposed rates for the assets 208 and the converted accepted rates 212 may be allocated to seasons of the event, which may be divided by days, weeks, months, or seasons.

[0023]

[0027] The data collection stage 202 may further include channels 214, channel locations 216, and assets 218. The channels 214 may be companies, individuals, or entities that may be sponsoring, hosting, or organizing an event. The channel locations 216 may be geographic locations where the channels are located or headquartered. The assets 218 may be locations where the channels are going to host an event. The assets 218 may include several variables specific to the assets, which may be represented by numerical values. The channels 214, channel locations 216, assets 218, and allowable rates 212 may be provided to 226, where calculated variables may be added. The calculated variables may include the distance between the channel's office and the assets, the number of offices the channel has, if the channel has a contract that applies to the booking, whether there is a cancellation fee or includes the terms of the fee. At 228, outliers may be removed from the data points using methods described herein. In some embodiments, room-related variables relating to capacity or occupancy may be set at 228 to match the capacity or occupancy of the asset.

[0024]

[0028] The data refinement stage 206 for model building may be at 230. At 230, the remaining variables may be received and assigned numerical values. For example, if the asset 218 has a characteristic indicating that the asset is four stars, the star value may be set to 100. If the asset 218 has a characteristic indicating that the asset is two stars, the star value may be set to 50. The category value may be a value that is not defined as a numerical value. For example, the accepted rate 212 may not be considered a category value, and market may be a category value. The final data set may be sent to 232 and stored in a data bucket that may be identified as S3. The data set may be used to train a machine learning algorithm. In one embodiment, a portion of the data may be used to train an algorithm that may use the data to make correlations between different categories, for example, prices associated with a particular channel. A portion of the data may be used for validation, which may determine how accurately the algorithm works, and may create a standard deviation or error range. Another portion of the data may be used for testing to ensure that the algorithm predictions are within a standard deviation. In some embodiments, training may be performed on 72% of the data, validation may be performed on 18% of the data, and testing may be performed on the remaining 10% of the data.

[0025]

[0029] FIG. 3 is an embodiment of a method 300 that may be employed when a request for a forecast is provided by a user. At 302, asset variables may be set. The asset variables may include information about the asset that is the subject of the negotiation. For example, the variables may include whether there are amenities such as breakfast included, fitness center, free parking, transportation to the airport, business center, wireless Internet, etc. The variables may further include information about the asset, such as room size, bed type, star rating, location, cancellation policy, etc. The variables may hold strings, vectors, Boolean objects, or numeric values. Information about channels that may be clients or customers may be assigned to the variables 304. These variables may include the desirability of the asset to the client, or the desirability of the client to the asset, for example, whether the asset has a business relationship with the client, or whether the client is large and can generate additional business. The client variables may also indicate the bargaining power of the client. The variable values ​​may be entered by the user or may be set automatically based on information known or obtained by the system. At 306, it may be determined if any of the variables of 302 and 304 were not available and / or were not set. If any of the variables are not set, equal to 0, or are empty, a false flag may be returned at 308. At 310, the distance between the channel or client's corporate office and the location of the asset may be determined. This may be based on the geographic coordinates of the corporate office and the asset.

[0026]

[0030] The set variables may be input into a prediction algorithm at 312 and based on the variables a predicted price may be output at 314. The prediction may include a range with upper or lower limits or median values, as well as a predicted value. At 316, the algorithm may request data from the user, which may include the final details and amenities agreed upon by the customer and the supplier in the final agreement. At 318, a final acceptable price may be input. Steps 316 and 318 may be performed in the same session as the previous steps or the information may be obtained later after the final agreement has been reached. The method may prompt the user to input this information at a later time. At 320, the accuracy of the initial prediction may be determined based on the information input at 316 and 318. In some embodiments, a value may be given indicating how accurate the prediction was. In other embodiments, the prediction may be considered accurate or inaccurate based on whether the prediction was within an error limit or standard deviation.

[0027]

[0031] The accuracy of the prediction may be determined at 320. If the prediction is found to be accurate at 322, the confidence of the prediction model may be increased at 322 and the prediction model algorithm may be trained using information from the acceptable prices and conditions. In other embodiments, the accuracy marker may be set to a first value. If the prediction is not determined to be accurate at 322, the method may determine if the prediction was made using the correct variables by comparing the final variables at 324 with the variables entered at 302 and 304. If the variables were incorrect, the method may end at 322. In other embodiments, the accuracy value may be set to a second value. If the variables were accurate, the confidence of the model may be decreased at 328. In other embodiments, the accuracy marker may be set to a third value. At 330, the acceptable rates and variables may be used to train the algorithm at 330.

[0028]

[0032] FIG. 4 is an embodiment of a method that begins at 400 and is implemented on a computing environment using a software program designed to implement the method. At 402, the program may receive details that may include an offer price. The bids may be generated by third parties, such as hotels, event spaces, or event planning companies. The bids may be received in response to inquiries made by clients or customers and may be made through the software program. The inquiries may include details such as desired amenities, desired room type or number, desired location, dates and length of stay, desired hotel, etc. One or more bids received at 402 may satisfy all or part of the details requested in the inquiry. At 404, the program may inquire about details of the bid, such as hotel amenities. At 406, the program may inquire about the type of room included in the bid. At 408, the program may inquire about the terms of the bid, such as the length of stay or use of the hotel or property, the dates of use or stay, or whether there is a cancellation policy.

[0029]

[0033] At 410, information about the bid may be compared to historical information gathered about similar agreements that have been reached. At 412, the queried information about the bid may be used to generate a predicted rate for similar rentals or agreements. A confidence rating may be determined for the prediction, which may be provided to the user along with the prediction. In other embodiments, the prediction may be flagged if the confidence level is below a threshold. At 414, the predicted rate may be compared to the bid rate. The difference between the predicted rate and the bid rate may be used to determine a suggested counter offer, which may be output to the user at 416. The software program may provide a prompt to submit a suggested counter offer or to the original offeree. In other embodiments, the user may manually submit or communicate a suggested offer or counter offer. The counter offer may include price, amenities, room type, or any other terms of the agreement. In other embodiments, one or more of the terms of the agreement may be set by the user as non-negotiable, and other terms of the agreement may be changed to form a suitable counter offer. For example, a user may set a price as non-negotiable and a counter offer may suggest a smaller room for that price point. In other embodiments, a user may enter a counter offer and the forecast generator may determine the probability that the offer will be accepted. In still further embodiments, a user may edit desired amenities to generate a new bid and / or forecast. At 418, the software may determine whether the counter offer was accepted. The acceptance or rejection of the counter offer may be automatic or determined by communicating through the software, or it may be entered by the user. In some embodiments, the counter offer and acceptance may occur at a later time or in a different user session. In further embodiments, the software may prompt the user to enter the counter offer that was made and whether it was accepted.The software may also receive information regarding the final contract, amenities, room types, or other information regarding the final negotiated agreement. At 420, the information entered regarding the acceptable agreement may be used to train a predictive algorithm. The method may end at 422.

[0030]

[0034] FIG. 5 illustrates an exemplary user interface 500 for one embodiment of the present invention. Bid details, such as the property name hotel, may be displayed at 502. Possible booking dates at 504 may be displayed at 504. Rate groups may be displayed at 508. The rate groups may identify the type of rate the customer will receive. For example, the customer may be a member of a rewards program or the customer may be a company with applicable corporate discounts. The rate group 508 may identify the group to which the customer belongs, and the rate plan 506 may identify the type of plan to which members of the group are entitled. A selectable box may be displayed at 510, which may allow the user to determine whether to activate a program for generating offer suggestions and evaluating bids based on historical data, as described herein. Various bid details may be displayed at 512, 514, and 516. For example, room type and price may be displayed. If the negotiation assistant option is selected, 512, 514, and 516 may further display suggested counter offers that may be generated using the methods and systems described herein. Selecting or hovering over a bid may cause a window 518 to pop up. The window 518 may show a range of rates secured for the room type in the property. This may further be based on the season or time the room is booked. Suggested rates within that range may further be displayed. The suggested rates may be determined based on any of the historical factors described herein. Additionally, amenities that may be available at that rate may be displayed. This may also be based on historical variables. The pop-up window 518 may have selectable options 520 that, when selected, may cause a suggested bid to be sent to the party offering the property.

[0031]

[0035] FIG. 6 illustrates a method 600 that may be employed by a software program to implement embodiments of the methods described herein. At 602, the program may receive historical information regarding agreements to book various hospitality spaces, such as hotel rooms. The historical information may include historical proposed rates, historical accepted rates, historical product characteristics, such as room type, property or hotel, amenities, star rating, location, and historical customer characteristics. The customer characteristics may include a particular customer, the size of the customer, the relationship between the customer and the company providing the bid, whether the customer is an individual or a company, and the like. At 604, the historical proposed rates and historical accepted rates may be given a currency value. The currency value may be determined based on the type of currency or the inflation rate from time of the historical proposed rates and historical accepted rates. At 606, historical outliers may be removed from the data, which may create a more accurate data set. The outliers may be determined based on the room type. At 608, additional variables may be calculated. For example, the distance between the customer office and the asset may be determined, the rate at which the proposed rate is acceptable to the customer, whether there is a cancellation policy, the difference between the amenities in the proposed bid and the amenities in the rejected bid, etc. The variables may then be cleaned at 610. Clean numeric values ​​may be assigned based on the characteristics, and certain variables, such as amenities, may be changed to a Boolean format. Numeric variables may be rounded to a set size or changed to a range. At 612, the historical product characteristic variables and the historical customer characteristic variables are converted to a consistent format. At 614, the historical customer characteristic and the historical product characteristic are assigned numeric values. For example, if one of the historical product characteristics is a month, the month may be converted to a numeric value based on the demand during the associated month. This may be done using a LabelEncoder application.

[0032]

[0036] At 616, the cleaned and transformed data may be split into three data groups. The breakdown of the data groups may be, in some embodiments, 72% for training, 18% for validation, and 10% for testing. At 618, the training data may be used to train a model using any of the machine learning training methods known in the art, such as using an xgboost model. At 620, validation may be performed on the dataset using any of the methods known in the art, for example, using a mean absolute error metric. The model may then be tested against the remaining data at 622. A final model may then be selected and built at 624. The generated model may then be received in a rate predictor module at 626. In some embodiments, the validation and testing results may be used to provide a confidence level of the model's predictions.

[0033]

[0037] The rate predictor may then be accessed by a user at 628. The user may input information about the request, such as parameters of the event or rental desired by the user, customer information, desired location, etc. The information entered by the user may be used to perform a rate prediction at 630. In some embodiments, the user may receive bids and the rate prediction may be performed using information specific to the bid that may not be specified by the user. The prediction may then be provided to the user at 632. The prediction may then be compared to one or more bids at 634. The comparison may be output to the user at 636. The comparison may include additional information, such as amenities that may be expected or included at a given bid price. The model may continue to be updated as additional data is received.

[0034]

[0038] The various embodiments described above are provided merely as examples and should not be construed as limiting the scope of the present disclosure. Various modifications and changes may be made to the principles described herein without following the exemplary embodiments and applications illustrated and described herein and without departing from the spirit and scope of the present disclosure. The invention as described in the claims of the original application is set forth below. [C1] a data collector configured to collect historical offered rates, historical accepted rates, historical product characteristics, and historical customer characteristics; receiving from the data collector the historical offered rates, the historical accepted rates, the historical product characteristics, and the historical customer characteristics; converting the historical proposed rate and the historical acceptable rate into a current currency value; removing outliers from the converted historical proposed rate and the converted historical acceptable rate; assigning the converted historical proposed rates and the converted historical acceptance rates to clean numeric variables; assigning historical product characteristics and historical customer characteristics to characteristic variables; generating a computed variable; generating a numerical rate for the characteristic variable based on the new calculated variable, the characteristic variable, and the numerical variable; dividing the numerical rate into a first data group, a second data group, and a third data group; performing training on the first group of data; performing a verification on the second group of data; performing a test on the third group of data; A data cleaner configured to: a model builder configured to build a predictive model based on the training, validation, and testing; receiving the predictive model; receiving input from a user regarding channel characteristics, asset characteristics, and season; inputting the channel characteristics, asset characteristics, and season into the forecasting model; generating a prediction from the predictive model; and outputting the prediction to the user; a rate predictor configured to: A system comprising: [C2] The system of C1, further comprising a negotiation assistant that receives a bid rate from a third party. [C3] The system of C2, wherein the negotiation assistant compares the bid rates to the forecast. [C4] The system of C3, wherein the negotiation assistant outputs a suggested counter offer if the bid rate is greater than the forecast. [C5] The system of C3, wherein the negotiation assistant provides a likelihood of acceptance based on a proposed rate provided by the user. [C6] The system of C1, wherein an acceptable rate is input into the data collector by a user. [C7] The system of C1, wherein an allowable rate is used to determine the historical allowable rate. [C8] The system of C1, wherein the historical product characteristic is a hotel amenity. [C9] The system of C1, wherein the historical product characteristic is a room type. [C10] Collecting historical offered rates, historical accepted rates, historical product characteristics, and historical customer characteristics; converting the historical offered rates and the historical accepted rates into current currency values; removing outliers from the converted historical proposed rates and the converted historical accepted rates; assigning the converted historical proposed rates and the converted historical acceptance rates to clean numeric variables; assigning the historical product characteristics and historical customer characteristics to characteristic variables; generating a computed variable; generating a numerical rate for the characteristic variable based on the new calculated variable, the characteristic variable, and the numerical variable; dividing the numerical rate into a first data group, a second data group, and a third data group; performing training on the first group of data; performing a verification on the second group of data; performing a test on the third group of data; and building a predictive model based on the training, validation, and testing; receiving the predictive model; receiving input from a user regarding channel characteristics, asset characteristics, and season; inputting the channel characteristics, asset characteristics, and season into the forecasting model; generating a prediction from the predictive model; and outputting the prediction to the user; A method comprising: [C11] The method of C10, wherein the prediction is a range of rates. [C12] receiving an edited property value; generating a second prediction from the predictive model; and The method of C10, further comprising: [C13] generating a reliability metric based on said verification of said second group. The method of C10, further comprising: [C14] providing said confidence metric to said user along with said prediction The method of C13, further comprising: [C15] providing a warning to the user when the reliability metric falls below a threshold; The method of C13, further comprising: [C16] receiving an allowed rate from the user; updating at least one of the first data group, the second data group, or the third data group based on the allowable rate, the channel characteristics, the asset characteristics, and the season; The method of C10, further comprising: [C17] 16. A computer-readable storage medium storing instructions that, when executed by a computing device, cause the computing device to perform a method, the method comprising: determining asset characteristics for an asset; assigning numerical asset values ​​to said asset characteristics using a pricing model; determining a channel characteristic for the channel; assigning numerical channel values ​​to the channel characteristics using the pricing model; Determining negotiation characteristics for the negotiation; assigning numerical negotiated values ​​to the negotiated characteristics using the pricing model; Determining a season characteristic for a season; assigning a numerical seasonal value to the seasonal characteristic using the pricing model; Determining a condition characteristic for the condition; assigning numerical condition values ​​to said condition characteristics using said pricing model; receiving a paid price from the user device; assigning the price paid to the asset characteristic, the channel characteristic, the negotiation characteristic, the season characteristic, and the condition characteristic; removing outliers from the asset characteristics, the channel characteristics, the negotiation characteristics, the season characteristics, and the condition characteristics; Dividing the asset characteristic, the channel characteristic, the negotiation characteristic, the season characteristic, and the condition characteristic into a first group, a second group, and a third group; administering training to the first group; performing a verification on the second group; and conducting a test on the third group; and updating said pricing model based on said training, said validation, and said testing; A computer-readable storage medium comprising: [C18] and further storing instructions, which when executed by a computing device, cause the computing device to perform a method, the instructions comprising: the seasonal characteristic is based on demand for the asset; A computer-readable storage medium as described in C17. [C19] and further storing instructions, which when executed by a computing device, cause the computing device to perform a method, the instructions comprising: The channel is customer-based; A computer-readable storage medium as described in C17. [C20] and further storing instructions that, when executed by a computing device, cause the computing device to perform a method, the method comprising: setting a flag when said test outputs a confidence level that is less than a threshold confidence level. 18. The computer-readable storage medium of claim 17, further comprising:

Claims

1. a data collector for collecting historical offered rates, historical acceptable rates, historical product characteristics, and historical customer characteristics, where the historical offered rates are a history of hotel room prices offered by a hotel, the historical acceptable rates are a history of the hotel room prices accepted by a customer, the historical product characteristics are a history of hotel room characteristics, and the historical customer characteristics are a history of characteristics of the customer; receiving from the data collector the historical offered rates, the historical accepted rates, the historical product characteristics, and the historical customer characteristics; converting the historical proposed rate and the historical accepted rate into a current currency value; removing outliers in a statistical process from the converted historical proposed rate and the converted historical acceptable rate; assigning the scaled historical proposed rate after removing the outliers and the scaled historical accepted rate after removing the outliers to a numerical variable; assigning the historical product characteristics and the historical customer characteristics to characteristic variables; generating additional variables based on characteristics related to the customer and / or the hotel; generating a data set based on the additional variables, the characteristic variables, and the numerical variables; dividing the data set into a first data group, a second data group, and a third data group; performing training on the first group of data; performing a verification on the second group of data; performing a test on the third group of data; A data cleaner that performs the above steps. a model builder that builds a predictive model based on the training, validation, and testing of a machine learning algorithm; receiving the predictive model from the model builder; receiving input from a user regarding channel characteristics, asset characteristics, and a desired season for the hotel room, where the channel is a company, individual, or organization that may be sponsoring, hosting, or organizing an event, and the asset is a location where the channel intends to host the event; inputting the channel characteristics, the asset characteristics, and the season in which the hotel rooms are desired into the forecasting model; generating a forecast from the forecast model, wherein the forecast includes at least the hotel room price; and presenting the prediction to the user; and a rate predictor for a negotiation assistant means for receiving bid rates from a third party, wherein said negotiation assistant means determines a suggested counter-offer to output to a user based on a difference between said forecast and said bid rates; A system comprising:

2. The system of claim 1 , wherein the historical product characteristic is a hotel amenity.

3. The system of claim 1 , wherein the historical product characteristic is a room type.

4. collecting historical offered rates, historical acceptable rates, historical product characteristics, and historical customer characteristics, where the historical offered rates are a history of hotel room prices offered by a hotel, the historical acceptable rates are a history of the hotel room prices accepted by a customer, the historical product characteristics are a history of hotel room characteristics, and the historical customer characteristics are a history of characteristics of the customer; converting the historical proposed rate and the historical accepted rate into a current currency value; removing outliers in a statistical process from the converted historical proposed rate and the converted historical acceptable rate; assigning the scaled historical proposed rate after removing the outliers and the scaled historical accepted rate after removing the outliers to a numerical variable; assigning the historical product characteristics and the historical customer characteristics to characteristic variables; generating additional variables based on characteristics related to the customer and / or the hotel; generating a data set based on the additional variables, the characteristic variables, and the numerical variables; dividing the data set into a first data group, a second data group, and a third data group; performing training on the first group of data; performing a verification on the second group of data; performing a test on the third group of data; building a predictive model based on the training, validation, and testing of a machine learning algorithm; receiving the predictive model; receiving input from a user regarding channel characteristics, asset characteristics, and a desired season for the hotel room, where the channel is a company, individual, or organization that may be sponsoring, hosting, or organizing an event, and the asset is a location where the channel intends to host the event; inputting the channel characteristics, the asset characteristics, and the season in which the hotel rooms are desired into the forecasting model; generating a forecast from the forecast model, wherein the forecast includes at least the hotel room price; and presenting the prediction to the user; and receiving bid rates from third parties; and determining a suggested counter offer to output to a user based on a difference between the prediction and the bid rate; A method comprising:

5. generating a confidence level for the prediction based on the validation of the second group of data. The method of claim 4 further comprising:

6. and providing said prediction to said user along with a confidence level of said prediction. The method of claim 5 further comprising:

7. A computer readable storage medium storing instructions which, when executed by a computing device, cause the computing device to perform the method of any one of claims 4 to 6.

Images