Revenue Management System Requirements

The goal of an RM system for Kasa is to be able to forecast demand and set price accordingly.
Competition and pricing within our competitive set is a huge part of this equation as well as
interpreting ongoing shopping data and the ability to respond to changes in page and position
rank on OTAs. Growth is also a big part of the Kasa roadmap which means new properties will
continue to be added and must be managed well. Kasa will require the ability to tether (bundle)
properties together for aggregate management and will also require the ability to set
benchmarks for new properties that expire on a chosen schedule. Demand forecasts and
seasons/baseline data must have the ability to be adjusted. Finally, the system will need to
allow for parameter based adjustments or the ability to put adjustments to forecast and/or
pricing in place that allow for specific notes. Finally, any revenue management/pricing system
must have an open API and be able to integrate with Kasa’s proprietary PMS system. Key to all
of this is the ability to optimize revenue on hotel, multi-family, and single family home (SFH) type
properties. Detailed requirements below:

Demand Forecasting

Kasa requires the ability to forecast demand for each property using realized demand that was
booked in prior year and unrealized demand that was not booked due to pricing constraints at
both the top and bottom the price curve. This demand must be broken into segments and
channels. Each forecasted date must have assigned dates that are feeding the forecast with the
flexibility to change the assignment or set a change/blending schedule for this change.

Price bands – Kasa requires a forecast that is broken into price bands and that each price band
would have its own forecasted demand as well as a confidence range or probability that this
forecast is accurate. Bands must have the ability to be aggregated which will adjust the
probability down. Use case: Demand planning, sellup identification, price leveling, elasticity,
dynamic pricing, etc.

Example: Need ability to adjust forecast here or at segment or room type level.
Segmentation

Kasa requires the ability to forecast and price segments separately. This includes pricing and
demand forecast differentiation by demand channel (O&O, OTA, Agency, etc.) and demand
type transient, contract, group, etc. as well as international sourced demand vs domestic by
country point of sale. Use Case: Price differentiation, segmented market share capture,
segmented promotions

Forecast Seed Assignment

Kasa requires the ability to assign specific historical dates to a property date and set the
distribution percentage of these dates to the forecast. We will also need the ability to remove
dates or add them throughout the booking curve. This does not have to be the same property or
room type. Use Case: Football schedule differing Yr/Yr, Easter, superbowl, hurricanes, etc.

Interval and Yr/Yr forecasting and Deseasonalization

Kasa requires the ability to be able to pick up on emerging trends within seasons and adjust
property forecasts up/down by gradually changing seed data to recent seasonal dates versus
yr/yr data. Use case: Emerging trend adjustments, Seasonality refinement

Kasa will need to be able to produce a date level seasonal forecast and be able to subtract the
variance versus the mean to this forecast to identify emerging trends and whether or not we
should be adopting an interval forecast more quickly or staying with a more stable year/year or
seasonal baseline.
Seasonal Assignments

Kasa will need the ability to assign each date and property to up to 8 seasons and identify each
of these seasons as a type high, med, low, shoulder/ramp to high, shoulder/ramp to low. Each
of these seasons will need the ability to compare to dates in the next and previous seasons for
dates that are close and flag if property/date is acting more like the next or previous season
than its current assignment. Use case: Seasonal transition and response, yr/yr comparison,
interval forecasting, dynamic pricing

Date 11/12/2022
PropCode BAS
PropName Base Camp
Season Fall
Season_Type Shoulder
Holiday_Event None
Holiday_Event_Level None
RevPar $XX
Occupancy XX%
ADR $XX
Rooms XX
Booked XX
Revenue $XX
Status Actuals, Forecast, Etc.

GT $1000 % CAP BKD

$750-$1000 % CAP BKD

$600-$750 % CAP BKD

$550-$600 % CAP BKD

$500-$550 % CAP BKD

$450-$500 % CAP BKD

$400-$450 % CAP BKD

$350-$400 % CAP BKD

$300-$350 % CAP BKD

$250-$300 % CAP BKD

$200-$250 % CAP BKD

$150-$200 % CAP BKD

$100-$150 % CAP BKD

$50-$100 % CAP BKD

$0-$50 % CAP BKD

Booking_Curve_Score Bookings X DBA

Long term protection

Kasa requires the ability to put long term protective pricing in place that is released manually by
the RM team and does not decrease until the planning indicator is set to yes for each
property/date. This pricing will be able to increase as bookings are taken to stop large amounts
of run on the bank bookings. (Gradient) Use Case: Compression event management

Loyalty/Non-Revenue Management

Kasa requires the ability to set loyalty currency to USD within the revenue management system
by property. We will need to be able to set availability of loyalty nights as well as any non-
revenue booking. We will need the ability to set minimum exchange values for currency as well.
Kasa will also need to be able to forecast demand for non-revenue/loyalty bookings. Use case:
Loyalty redemption, availability, compression event management.

Holiday/Special Events - Benchmarking

Kasa requires the ability to assign any property date to any other property date for the purposes
of forecasting. Use Case: This will be used to take historical data from an event like superbowl
in one market and assign that history to another market as the seed data.

Pseudo Rooms

Kasa needs the ability to be able to point a room type to another room type for forecasting
purposes and set a schedule for when this forecast baseline will be removed. Use Case: New
room types in existing markets/Properties. New single family home (SFH) added to the bundle.

Tethering to competitors

Kasa needs the ability to adjust dynamic pricing to tether to a group of or a single competitor
and ensure that Kasa’s price is never too far above this rate or too far above this rate. Kasa will
also need the ability to activate and deactivate this and set levels at a system and property
level. We will also be able to set map distances and specific comp sets to follow. Use Case:
ADR improvement, Revenue Share, Dilution reduction

Elasticity/Price Sensitivity/Willingness to pay

Kasa requires the ability to add an elasticity number for each forecast based on probability of
demand in the next price band down and where that will land us in terms of competition. For
example if demand and probability is higher and we go from higher than to lower than
competition then it will drive demand more. Use Case: price adjustments (how much), Price
inflection points, price elasticity, WarRoom historical tracking.

High Value competitor bookings prediction (prime booking window/sweet spot)

Kasa has very many small footprint buildings and can in many cases sell all capacity overnight.
This is okay! However, we must do this at a time when we believe the competitive set or
tethered property is at its crest or has a high probability of being so. At present we are
aggressively undercutting the last minute bookings and sometimes those are high value and
many times they are not. Must be based on market share and other factors. Use Case: ADR
improvement, Revenue Share, Dilution reduction

Revenue management strategy would be set and managed for all properties including, OCC,
Historical curve, Comp set pricing, X-1 compset, Mid-point comp set if…, etc.

Parameter Based Adjustments

Kasa requires the ability to process data in custom tables or include custom tables and to set
demand adjustments and/or out the door pricing levels based on criteria. We will require the
ability to build hierarchical adjustments and to track effectiveness of these automated
adjustments over time and scoring them as effective or not. Use Case: Scalability in monitoring,
effective scalability, dynamic demand adjustments, dynamic pricing, flagging

External data/API/HTTP/ETL

Kasa requires the ability to integrate with Kasa’s internal systems and reporting tools. Reporting:
Kasa will need to be able to extract data from the RM system and for daily storage of pricing
levels, demand forecast, etc. in Big Query. Bulk Actions: Kasa requires the ability to be able to
input adjustments to current forecast or pricing levels via API/Http Post request with no limits on
daily/hourly volume. Kasa requires API documentation to do so. Kasa requires an open API
relationship for our PMS system.The PMS system will constantly update changes to
reservations via API. Use Case: Scalability, Systems integration, Reporting

To be completed by Hernan, Tim G.

Web Data/3rd Party Data

Kasa requires the ability to incorporate 3rd party or 1st party Kasa data into the RM system for
use in parameter based adjustments. Kasa is okay doing this as a user table or simply shipping
pricing & demand forecast changes to the system via API or bulk load. Use Case: Data
integration, Parameter based adjustements

Profit Considerations/Trade-Offs

Kasa requires the ability to differentiate price based on cost related factors including Length of
Stay, Demand Channel, & risk. This would be expressed in terms of minimum pricing by each in
the prior list. Use Case: Gross Profit Management
Bundling

Kasa requires the ability to group any number of properties together for forecasting purposes
and manage these as a collection. Each collection would have an aggregate forecast as if a
single property and would have drillable attributes to price band forecast, season, etc. At the
same time Kasa has room types that must have the ability to be managed separately and
together for the sake of pricing, occupancy management, overbooking, upgrades, etc. Bundled
properties should have the option to update pricing based on changes made to the base
property/room type. Changes to properties in the bundle would be based on predetermined
modifiers/upcharges determined by RM. Use Case: Managing small data, Clustering

Benchmarks

Kasa requires the ability to be able to benchmark a new property to an existing one for any
period of time selected by the user. This will drive the forecast/price. Use Case: Ramp up

PMS integration

To be filled in by Hernan

Allotments/Protection Levels/Hurdle Rates/Displacement Costs

Kasa requires the ability to set allotments/protections of units based on demand. This will only
allow a select number of units to be sold at one price prior to moving to the next price where
there is demand. Use Case: Demand Planning, Mix Management, Price bands

Upgrades

The RM system will have the ability to recognize demand variations between room types and
overbook with automated upgrades to various room types. This feature will be configurable to
allow/disallow relationships between room types. Use case: Inventory Utilization, Loyalty, NQS
maximization, RevPar

Inventory optimization

The RM system will be able to slot reservations in the most optimized room pattern for each
room type. To free up the most room availability and be configurable to optimize number or
rooms, longer LOS, or weekend availability. Use Case: Inventory utilization

This would need to run continuously and be integrated with the PMS system.

Overbooking
The RM system will require the ability to track and predict cancellations and no shows and
recommend overbooking levels for each room type and the property as a whole for each date.
This would be configurable to the risk threshold or can be overridden and a set overbooking rate
achieved. This would adjust for # of bookings checking in per date as well. If only one person is
checking in and the hotel is full then overbooking for that date would be much higher risk. Use
Case: Recapture inventory, Overbooking

RM Metrics

Within the RM system will be performance metrics that measure RM effectiveness. These will
be early sellouts, high yield spill, low yield spill. Empty rooms at day 0. Spoilage (empty rooms
after being booked 100%), and walks (overbooked with no room). Use Case: RM performance,
Opportunity evaluation, Demand planning

Early sellouts - No rooms left to sell prior to 7, 14, 21 days out

High yield spill - Number of rooms expected to be sold after sellout. At highest rate sold.

Low yield spill - Number of rooms expected to be sold when price was too high

Spoilage - Rooms not sold due to cancellation/no show

Overbooked and impacted - Overbooked with more than 100% showing up for room

Unconstrained Demand

Core to our Revenue Management system is the ability to understand booking curves of similar
dates within season and be able to understand the concept of bookings that are taken as well
as bookings that are not taken because of higher priced bookings displacing them. Our
unconstrained demand will not constrain the forecast based on the capacity but rather assume
that our capacity is infinite and therefore predict all demand possible to us. The source of this
will be historical booking patterns and web shopping data and conversion rates. Demand can
only be constrained by price. Use Case: RM basics, Demand Planning, elasticity, pricing
evaluation, etc. RevPar, etc.

Ex.

Capacity = 100 units

Bookings = 96

Occupancy = 96%

Realized Demand = 96

Rejected Demand = 8

Unconstrained Demand = 104

Unconstrained Occupancy = 104%

Demand Adjustments
Within our Revenue Management systems. Kasa requires the ability to be able to adjust the
demand forecast that is generated by this system. The following types of adjustments should be
allowed.

Additive - The ability to add demand at an absolute number level to the forecast. Example would
be to increase the forecast by 2 units.

Additive with reduction - The ability to add demand at an absolute number level to the forecast
but have it decay to nothing over a period of time.

Multiplier - The ability to be able to increase or decrease the system forecast with a multiplier.

Absolute - The ability to set the value of the forecast and override the system forecast number.

Multiplier with reduction - The ability to be able to increase or decrease the system forecast with
a multiplier that will reduce over time.

Demand posting - The ability to move demand from one source to another; See posting.

For all adjustments the RM system will track the adjusted forecast and the system forecast. Use
Case: System forecast, user forecast, demand adjustments, unconstrained forecast, demand
allocations

Demand Posting

Kasa will need the ability to move demand or percentages of demand or duplicate demand from
one room type or price band to another. This demand will retain its booking curve profile and
simply allow for shifting this demand to a higher bucket of price or room type. Use case: Selling
up into higher bands

Nest Influences
For the demand adjustments listed above, Kasa requires the ability to set 100s of these that
could apply to a single date. These shall be hierarchically scored and processed in order.
Highest priority only will apply. Posting will be considered a system level adjustment and will
apply before other adjustments that can be allowed to compound. All manual date level
adjustments will override any parameter based influence. Use case: Hierarchy of adjustments

Exclusions

Kasa will require the ability to exclude data from seasonal forecast due to extraordinary events.
Hurricane, etc.

Star rating

Kasa requires the ability to track star rating with each property and the impact this rating has on
conversion and demand and be able to predict demand impact of moving up or down per 0.25
stars.

Amenities

Kasa requires the ability to differentiate between rooms or SFH (single family homes) that have
amenities that drive demand. Ex. Pool, kitchen, water view, etc.

Ancillary Fees

Kasa requires the ability to track competitor ancillary fee charges and suggest a fee where Kasa
provides the same amenity or amenity structure. Kasa will also need to track this fee structures
impact on star rating.

Market share

Kasa requires the ability to store and track market share by channel, DFA (days from arrival),
price band, and to do so within 1mi, 2mi, 5mi, 10mi, & city wide. This will be on a percentage
and rooms of x rooms basis.

Example: 2% or 20 of 1000 rooms

Loyalty and incentives and promotions

Kasa requires the ability to predict promotional response in a closed and controlled loyalty group
as well as a mass market campaign using reach and conversion rate.

Cancellation Rate and Policies (Forecast)

Kasa requires the ability to be able to set rate plan attributes in the system which will force a
demand adjustment to account for changes in demand, no show rate,cancel rate, etc. Kasa’s
demand will be a summation of the sub rate plans that feed each booking.

Upselling

Kasa requires the ability to set an upsell path for each room type and price differential and
amenity gap callout.

Cross Selling

Kasa requires the ability to sell to room type at similar pricing or lower that would be more
advantageous from a utilization standpoint. Kasa will also need to be able to set cross-sell
ancillary offers or partner offers.

Rate Parity Strategy Management

Kasa receives regular data from a 3rd party that indicates where Kasa.com is in terms of pricing
parity and also indicates each OTAs price point for Kasa. Understanding changes in conversion
rate and demand volume as this occurs should be trackable in the system.

Room Type Differentiation

Kasa requires the ability to set differentiation on room types to ensure that room type pricing
does not become inverted. These relationships would ensure that all room pricing would move
as one. Differentiation on room types should have the capability to be set/vary by season;
values can be set by a fixed amount or as a percentage of the lowest valued room type.
Gradient pricing would also apply here.
Gradient Pricing

Kasa requires the ability to set a gradient for how many rooms can be sold at the current price
level and the increment at which the price will increase as this occurs. This gradient will override
the demand forecast and increase the market rate quicker and put a stop in place at that price
until reviewed by a human who can release back to system level pricing.

Elasticity/Price Sensitivity

Demand probability and unconstrained demand in the demand forecast should satisfy this
requirement.

Variable costs

Ability to set variable cost at a room type & channel level to ensure that all bookings are net
incremental.

Day of week

Forecast would default to the same day of week.

Partner Offers

See Loyalty and incentives and promotions.

Adjacency Pricing

Ability to offer discounts based on room booking overlaps constraining availability.

Example bookings pushing to only offer a 2 night block between them must be discounted to
sell the perfect Tue and Wed 2 night booking.

Customer Segmentation

Need the ability to track historical demand and predict future bookings by transient, contract,
group, etc.

Property Type

Kasa will need the ability to set an RM field of property type for multi-family, Hotel, and single
family homes.

Bulk Load
Kasa requires the ability to bulk load user adjustments to the forecast and or final pricing using
upload CSV or API/HTTP POST request.

Hernan and Jaime to finalize.

Aggregation

Data and room type will be the lowest forecasted atomic level. All forecasts will have the ability
to be aggregated to date, week, month, season, bundle, region, & city levels for the purposes of
forecast review and adjustment.

Map vs List search information

Kasa requires the ability to understand if users' OTA searches are coming from list searches or
map searches. Percent mix would be displayed at a property level.

Undercut alerts (us & them)

Kasa requires the ability to be able to have email, text and in UI level alerts when Kasa is
undercutting the comp set and/or when the comp set is undercutting Kasa. Kasa can provide
the comp set data but will need to be able to act on this data in parameter based adjustments.

Demand indicators

Demand indicators would show that a property is currently in, prior to, exiting, or behind the
booking window based on web search volume, kasa.com volume, pickup trends, etc. Use Case:
Prioritization, Discounting

Pricing channel Differentiation

Kasa would have the ability to differentiate price by channel and OTA. Use case: Distribution
cost management

Promo history and recommendations

Kasa would be able to classify demand as part of a promotion and what percentage was
discounted. Kasa would be able to control the availability of these promotional rates. Use Case:
Promo management; Blackouts, compression event management, transfer pricing,
chargebacks, loyalty

Competitor Price Curve Forecast

Kasa requires the ability to predict competitor pricing over a long time horizon in order to exploit
when competitor pricing is at its 50-75th percentile. Use Case: Predictive price response; Game
Theory
Dynamic Pricing Strategy Setting

Kasa requires the ability to control dynamic pricing and toggle which variables are key for each
property between comp set pricing, occupancy, yr/yr change, etc. Use Case: RM tactical
response, Allocation management, Seasonality, emerging trends, competitive response, etc.,

List and Calendar view

For demand, unc demand, occupancy, bookings, & ADR Kasa requires the ability to see these
in a color coded list or calendar view. Use Case: Calendar View, List view, Compression event
management

QA against out for sale

Kasa requires the ability to click on any rates or rates over any date period and verify that these
rates are available on kasa.com and up to 4 selected OTAs in a real time manner or schedule
as part of a daily check. This would be for a combination of LOS parameters. Use Case:
Price/PMS/OTA quality assurance, Pickup diagnostics

Blackout dates

Kasa requires the ability to black out any dates from a rate plan or price point or promotion.

LOS Pricing
Kasa requires the ability to set pricing by Length of Stay for each date and set holistic LOS
discounts.

Group bookings

The RM system will be able to handle group bookings separately and include/exclude from
forecasting, predict cancellations that are more aligned with groups, predict no-show rates
aligned with groups and calculate spill and recapture impacted by group booking dates.

Empty Compression Response

Ability to respond to competitor changes in pricing and set configurable playbooks that react to
new compression information for each property. Some properties will have compression events
that are driven by adding an event like a concert etc. while others may not be so dependent.
Example actions will be to shut down inventory until RM has reviewed or increase price to
competitor levels until RM review. Etc.

Jaime’s Top 2 Factors

1. Parameter-based Adjustments -
2. Demand allocation - how many rooms are sold at each price band