Weekly Pricing Review Log

Pricing decisions compound. A rate you override on a Tuesday because of a local event, a minimum stay you shorten because a gap looked too long, a discount you applied because a week felt slow: each of these is a small judgment call that feels obvious in the moment and becomes invisible within a fortnight. When you work with a pricing partner, whether that is a service, a co-host, or a property manager, those invisible decisions create friction. Your partner adjusts a date; you adjusted it first for a reason neither of you can now reconstruct. The calendar shows a rate. Neither party knows whose hand set it or why.

That is the problem this guide addresses. Not pricing strategy in the abstract, but the operational record that makes a pricing partnership function without constant back-and-forth. A weekly pricing review log is not a reporting document. It is a decision ledger: a place where every override, every exception, and every deliberate departure from the agreed baseline gets recorded with enough context that either party can read it cold, weeks later, and understand exactly what happened and why.

Why context must come before the rate

When a host or a pricing partner opens a calendar and sees a rate that differs from what the dynamic pricing tool suggested, the instinct is to ask whether the rate is right. That is the wrong first question. The right first question is what situation produced this rate.

A rate without context is just a number. A rate with context is a decision. The difference matters because decisions can be reviewed, improved, and turned into policy. Numbers can only be accepted or changed.

Before you record any override or exception, write down the situation first. What was the original suggested rate? What was the occupancy picture for the surrounding dates? Was there a specific event, a booking inquiry, a competitor observation, or a platform notification that prompted the change? Only after you have written that down does the rate itself become meaningful.

Checklist: what to capture before you record the rate

• The date or date range in question
• The rate the pricing tool or baseline suggested for that date
• The current booking status of the date (open, held, pending inquiry)
• The occupancy status of the nights immediately before and after
• The specific situation or observation that made you consider a change
• Whether any platform setting (minimum stay, gap fill rule, early bird discount) was already affecting the date before you touched it

If you cannot complete that checklist, you do not yet have enough information to make a defensible override. That is not a criticism. It is a signal to gather more before acting.

Record the trigger as evidence, not a conclusion

There is a difference between recording "local event this weekend" and recording "the city marathon is confirmed for the 14th, the finish line is four blocks away, the event page lists expected attendance, and comparable dates last year filled early." The first is a label. The second is evidence.

When you review a log entry weeks later, or when your pricing partner reviews it without you, a label tells them nothing they can act on. Evidence tells them whether the trigger was real, whether it recurred, and whether it should become a standing rule.

Decision rule: If your trigger note could apply to any date on any calendar, it is a label, not evidence. Rewrite it until it could only apply to this specific date.

Worked example:

Weak trigger record: "Demand looked soft, dropped rate."

Strong trigger record: "As of Sunday evening, the date had been open for 19 days with no inquiry. The two nights on either side were also open. The pricing tool had held the rate flat for the previous two weeks. No events are listed for that weekend. The rate was reduced to close the gap between this listing and the next available open weekend, which had already received a booking."

The strong version gives a reviewer everything they need: the duration of exposure, the surrounding context, the tool's prior behavior, and the reasoning. It also gives you something to check against later. Did the date book after the reduction? How quickly? That feedback loop is how you improve your override judgment over time.

Use one detailed record per exception

A common logging failure is batching. A host reviews the calendar, makes five adjustments, and writes a single note: "Adjusted several dates for the upcoming holiday period." That note is useless as a decision record. It cannot be reviewed, reversed, or learned from.

Each exception needs its own entry. This feels like more work. It is more work. It is also the only way to know, three months later, which of those five adjustments was the one that caused a problem or the one that worked well.

What a single exception record should contain:

• Date of the exception: When you made the change, not the date the change applies to
• Affected listing dates: The specific night or nights being changed
• Change type: Rate override, minimum stay change, gap fill, discount toggle, availability block
• Before value: What the setting was before you changed it
• After value: What you changed it to
• Trigger: The evidence, written in full (see previous section)
• Who made the change: You, your pricing partner, or an automated rule
• Expected outcome: What you expect to happen as a result
• Review date: When you plan to check whether the outcome matched the expectation

That last field is the one most logs omit. Without a review date, exceptions accumulate and never get evaluated. With a review date, your weekly review queue has a built-in mechanism for closing the loop.

Make decision rights explicit

A pricing partnership only works if both parties know who is allowed to change what without asking first. Without that clarity, you get either paralysis (your partner waits for approval on every small adjustment) or conflict (you discover a change you did not expect and do not understand).

Decision rights should be documented once, reviewed periodically, and referenced in every exception log entry. They do not need to be complicated. They need to be specific.

Table: example decision rights framework

This table is a starting point, not a finished document. Your version should reflect your actual agreement with your pricing partner. The point is that the table exists, is written down, and is referenced when an exception is logged.

When you log an exception, note which decision rights category it falls under. If it falls outside any existing category, that is itself a signal: your decision rights framework has a gap, and the gap should be filled before the same situation arises again.

Verify which platform setting controls the date

One of the most common sources of confusion in a pricing review is a date that looks wrong but is not wrong in the way either party thinks. The rate may be correct, but a minimum stay rule is preventing the date from being booked. Or the date is available at the right rate, but an early bird discount is applying automatically and neither party set it intentionally.

Before you log an override for a date, verify which platform setting is actually controlling the behavior you are trying to change. On Airbnb, this means checking the calendar view, the pricing settings, the trip length discounts, and any promotions that are currently active. A rate override applied to a date that is already being suppressed by a minimum stay rule will not produce the outcome you expect.

Checklist: platform setting verification before logging an override

• Open the specific date in the Airbnb host calendar, not the pricing tool's calendar
• Confirm the rate shown is the rate a guest would see, including any active discounts
• Check whether a minimum stay rule applies to the date and whether it differs from your default
• Check whether any promotion (weekly discount, monthly discount, early bird, last-minute) is active and affecting the displayed rate
• If you use a channel manager, confirm whether the channel manager or Airbnb is the source of truth for that date
• Record which setting you are changing, not just the outcome you want

This step prevents a specific failure mode: two parties both believe they have addressed a date, neither has addressed the actual controlling setting, and the date continues to behave unexpectedly.

Run the weekly review as a queue

A weekly pricing review is not a freeform conversation about how things are going. It is a structured queue: a list of items that need a decision, a check, or a close. Running it as a queue means it has a defined start, a defined end, and a clear record of what was resolved.

How to build the queue:

Before each weekly review, compile the following into a single list:

1. All exception log entries whose review date falls this week
2. Any dates in the next 30 days that have no booking and no recent pricing action
3. Any dates where the pricing tool's suggestion has changed significantly since the last review
4. Any platform notifications received since the last review (low visibility alerts, booking conversion alerts, policy updates)
5. Any guest inquiries that were declined or that expired without a booking, with the rate that was showing at the time
6. Any new local events or demand signals identified since the last review

Work through the queue in order. For each item, the outcome is one of three things: resolved and logged, deferred with a new review date, or escalated (see the next section). Nothing leaves the queue without one of those three outcomes recorded.

Decision rule: If an item has appeared in the queue three weeks in a row without resolution, it is not a queue item. It is a policy gap. Move it to a policy review and handle it separately.

Worked example of a completed queue item:

Queue item: Exception log entry from 11 days ago. A minimum stay was reduced from three nights to two nights for a specific weekend to fill a gap. Review date was set for this week. Expected outcome was a booking.

Review action: The date booked two days after the change. The booking was for two nights at the adjusted rate. The gap was filled. The exception is closed. Note added to the log: "Outcome matched expectation. Gap fill via minimum stay reduction effective for this date type. Consider adding to standing rules for similar gaps."

That final note is the mechanism by which a one-off exception becomes institutional knowledge.

Hypothetical completed example

The following is a hypothetical log entry showing what a complete, well-formed exception record looks like in practice. The names, dates, and figures are illustrative only.

Exception log entry

Date of entry: A Monday in mid-autumn

Affected listing dates: A Friday and Saturday in the following week

Change type: Rate override (upward) plus minimum stay increase from two nights to three nights

Before values: Rate as suggested by pricing tool; two-night minimum stay

After values: Rate increased to reflect a confirmed large-scale event in the area; minimum stay set to three nights

Trigger (evidence): A regional food and wine festival was confirmed for that weekend via the official event website. The event has run for several years and the listing's booking history shows that the same weekend in prior years filled earlier and at higher rates than surrounding weekends. As of the date of this entry, the listing has one inquiry for a single night on the Friday, which would leave the Saturday open. Increasing the minimum stay to three nights prevents a single-night booking that would block a more valuable two-night or three-night stay. The rate increase reflects the demand signal, not a guess.

Who made the change: Pricing partner, acting within agreed decision rights for rate adjustments within the agreed ceiling. Minimum stay change also within agreed unilateral authority.

Expected outcome: A two-night or three-night booking at the adjusted rate before the event weekend. If no booking by the Wednesday before the weekend, minimum stay to be reduced back to two nights and rate to be reviewed.

Review date: The Wednesday before the affected weekend

Decision rights category: Rate within ceiling (pricing partner, notify host within 24 hours); minimum stay reduction authority (pricing partner, notify host within 24 hours)

Host notified: Yes, same day via agreed channel

That entry can be read by anyone with no additional context. It explains the situation, the evidence, the action, the authority, the expectation, and the next checkpoint. That is what a complete log entry looks like.

Escalate repeated exceptions into a policy review

A single exception is a judgment call. The same exception appearing repeatedly is a signal that your baseline pricing rules do not cover a situation that keeps arising. Logging it the same way each time is not the answer. The answer is a policy review.

A policy review is a separate conversation from the weekly queue. Its purpose is to examine a pattern of exceptions and decide whether the pattern should be codified into a standing rule, a seasonal adjustment, or a change to the agreed decision rights framework.

Triggers for escalating to a policy review:

• The same type of exception has been logged three or more times in a rolling two-month period
• An exception was made, the expected outcome did not occur, and neither party can explain why
• A decision rights gap was identified (an exception fell outside all existing categories)
• A platform change (new Airbnb feature, new discount type, new policy) has created situations your current framework does not address
• A new demand pattern has emerged (a new recurring event, a change in your listing's typical guest profile, a shift in booking lead times) that your baseline rules were not designed for

What a policy review produces:

A policy review should end with a written update to one of three documents: the decision rights table, the standing pricing rules, or the exception log template. If it ends with only a verbal agreement, it has not produced anything durable.

Decision rule: If you cannot write down the outcome of a policy review in one or two sentences that both parties would sign off on, the review is not finished.

References

The following sources are directly verifiable by any host with an active Airbnb account. No third-party data vendors are cited here.

Airbnb Help Center: Airbnb publishes documentation on how pricing tools, discounts, and minimum stay settings interact. Search the Help Center for "smart pricing," "trip length discounts," and "promotions" to find the current descriptions of each setting. These pages change when Airbnb updates its product, so check them periodically rather than relying on a cached version.

Your own Airbnb performance dashboard: The insights tab in the Airbnb host dashboard shows impressions, click-through rates, and booking conversion data for your listing. These are the numbers to reference when logging a trigger related to visibility or conversion. They are your data, not an estimate.

Your booking history export: Airbnb allows hosts to export reservation data. A host who wants to verify whether a pattern of exceptions reflects a real demand pattern (for example, whether event weekends consistently book earlier or at different rates than non-event weekends) should use their own booking history as the evidence base, not a third-party estimate.

Your exception log itself: Over time, the log becomes a reference document. A host who has maintained a detailed log for several months has a record of which triggers led to which outcomes. That record is more reliable for your specific listing than any general market data, because it reflects your actual guests, your actual market, and your actual pricing decisions.

Where this becomes someone else's job

Maintaining a pricing review log is manageable when exceptions are occasional and the weekly queue is short. It becomes a significant time commitment when your listing generates frequent exceptions, when you manage multiple listings, or when the volume of platform notifications and demand signals requires daily attention rather than weekly review.

Revande offers two products for hosts who have reached that point.

Performance gives you a full software stack for dynamic pricing with daily adjustments made by experienced rate strategists, Airbnb listing performance monitoring, and email alerts when visibility or booking conversion drops below expected levels, plus monthly reports. The log discipline described in this guide is built into how Performance operates: decisions are tracked, triggers are recorded, and you receive regular reporting that reflects what was done and why.

Maestro includes everything in Performance and adds done-for-you listing optimization, proactive Airbnb listing performance monitoring with visibility and booking conversion issues handled for you rather than flagged for you to handle, compatibility with Airbnb directly or with your channel manager, and ongoing listing refinements as the platform and your market change. For hosts who want the log maintained and acted on without running the weekly queue themselves, Maestro is the appropriate level of service.

The distinction between the two is not complexity. It is who does the work after the information arrives.