Pricing Exception Log

Dynamic pricing tools make hundreds of decisions you never see. Most of those decisions are fine. A small number are not, and the ones that are not tend to cluster around the same conditions: a calendar sync failure, a minimum-price floor set too low before a major local event, a rate rule that fires on the wrong date range, or a base-price change that propagates to a channel you forgot was connected. None of these are catastrophic on their own. They become costly when nobody notices them until a guest has already booked at the wrong rate, or until a week of high-demand nights has been sitting at a price that undercuts your own floor.

The problem is not that automation fails. The problem is that most hosts have no structured way to catch the failure, record what actually happened, scope how far the damage ran, and confirm that the fix held. Without that structure, the same failure recurs, and each recurrence is harder to diagnose because the history has been overwritten by the correction. This guide gives you a repeatable process: a register to maintain, a severity framework to apply, a containment method that preserves evidence, and a recovery checklist you can run against every surface the failure touched.

Record the trigger without diagnosing by assumption

The first thing you write down is what you observed, not what you think caused it. This distinction matters because the same symptom can have several causes, and if you write down a cause before you have confirmed it, you will investigate the cause you assumed and miss the one that actually fired.

A trigger record has four fields and nothing else at this stage:

What you saw. Describe the observable state. "Nightly rate on the listing showed lower than the floor I set" is a trigger. "The pricing tool glitched" is a diagnosis. Write the first kind.

When you saw it. Record the date and time you noticed it, not the date you think it started. Those are different things and both matter.

Where you saw it. Name the surface: the Airbnb calendar, the channel manager rate grid, the pricing tool's own dashboard, a guest inquiry that quoted a rate back to you. If you saw it in more than one place, list each one separately.

What state the calendar or rate was in. Screenshot this immediately. Do not adjust anything yet. The original state is evidence. Once you change it, it is gone.

Worked example. You open your pricing tool on a Tuesday morning and notice that the upcoming Saturday night is priced well below what you expected given a local festival that weekend. You write: "Observed: Saturday night rate lower than expected floor. Noticed: Tuesday 9:14 am. Surface: pricing tool dashboard. Calendar state: screenshot taken, saved to exception folder." You do not write "the tool ignored the event" because you have not confirmed that yet. The event detection feature may have worked correctly and a minimum price override may have failed. You do not know yet.

Checklist before you move on:

• Observable state described without a cause attached
• Exact time of observation recorded
• Every surface where the anomaly appeared listed
• Screenshot or export of the current state saved before any change is made
• No adjustment made to the live calendar yet

Assign severity from approved criteria

Not every pricing anomaly warrants the same response speed. A rate that is slightly above your target on a low-demand night is worth noting but not worth dropping everything. A rate that is below your floor on a sold-out weekend with a non-refundable booking already confirmed is a different category entirely.

Severity assignment is not a judgment call made in the moment. It is a lookup against criteria you set in advance. Here is a framework you can adapt:

Severity 1: Booking already confirmed at the wrong rate. A guest has booked and the booking is confirmed. The rate cannot be changed without cancellation. The exposure is locked. This requires immediate escalation and a decision about whether to honour, negotiate, or cancel (with full awareness of the cancellation policy consequences).

Severity 2: Wrong rate is live and the affected dates are within a booking window where a reservation is likely. No booking yet, but the rate is visible to guests right now and the dates are close enough or desirable enough that a booking could arrive at any time. This requires correction within the hour.

Severity 3: Wrong rate is live but the affected dates are far out or low-demand. The exposure exists but the probability of a booking arriving in the next few hours is low. This requires correction within the day and a root-cause note.

Severity 4: Wrong rate appeared and was already corrected by the tool before any booking. The anomaly is historical. No live exposure. This still requires a log entry because recurrence patterns are only visible if you record every instance.

Decision rule: Assign severity before you investigate cause. Severity determines how fast you act. Cause investigation happens in parallel for Severity 1 and 2, and after correction for Severity 3 and 4. If you are unsure between two severity levels, assign the higher one.

Worked example. You find the festival-Saturday anomaly from the earlier example. No booking has arrived yet. The festival is four days away and your market historically books that weekend well in advance. You assign Severity 2. You do not wait to finish your root-cause investigation before correcting the live rate.

Scope exposure before choosing an action

Scoping means answering: how many nights are affected, across how many channels, and is any booking already confirmed at the wrong rate? You do this before you touch anything, because the scope determines what you need to fix and in what order.

A single rate rule misconfiguration rarely affects one night. It usually affects a date range, and that date range may have propagated to every connected channel. If you correct the rate on Airbnb but forget that the same rule pushed a wrong rate to a direct booking site or a second channel, you have a partial fix that will confuse your recovery check later.

How to scope:

1. In your pricing tool, pull the rate calendar for the full date range you suspect is affected. Do not assume the anomaly is limited to the night you first noticed.
2. Check every connected channel separately. Do not rely on the pricing tool's "sent to channel" log as confirmation that the channel received and applied the rate correctly. Check the channel's own calendar.
3. Check for confirmed bookings across the entire affected date range on every channel. A booking confirmed at the wrong rate is a different problem from a wrong rate with no booking, and you need to know which situation you are in before you act.
4. Record the scope: number of affected nights, channels affected, bookings confirmed (if any) and at what rate.

Worked example, continued. You check the pricing tool and find that the same low rate applied to Friday, Saturday, and Sunday of the festival weekend, not just Saturday. You check Airbnb directly and confirm the rates match the tool. You check your second channel and find the rates there are different because that channel has a separate minimum price setting that overrode the tool's output. You record: "Three nights affected on Airbnb. Second channel unaffected due to separate floor. No confirmed bookings on any affected night as of scoping time."

Checklist before choosing an action:

• Full affected date range identified, not just the night first noticed
• Every connected channel checked independently
• Confirmed bookings on affected dates identified and rates recorded
• Scope written down before any correction is made

Contain without erasing the original state

Containment means stopping the exposure from growing while preserving the evidence of what happened. These two goals are in tension. The fastest way to stop the exposure is to overwrite the wrong rate with the correct one. But overwriting destroys the evidence you need for root-cause analysis and for any guest dispute that might follow.

The resolution is to save the state before you correct it, and to save it in a form that cannot be accidentally overwritten later.

What to save:

• Screenshots of the pricing tool's rate calendar for the affected date range, timestamped by your device or camera roll
• Screenshots of each affected channel's rate display for the same dates
• An export of the pricing tool's rate history for those dates if the tool offers one
• Any booking confirmation that references a rate, saved as a PDF

Where to save it: A dedicated folder, named by date and listing, outside the pricing tool itself. Cloud storage with version history is preferable to a local folder. The point is that the evidence exists somewhere the correction cannot touch.

Then correct the rate. Once the state is saved, make the correction. For Severity 1 (booking already confirmed), correction of the live rate is still worth doing to prevent additional bookings at the wrong rate, but the confirmed booking is a separate problem that requires a separate decision.

Worked example, continued. You take screenshots of the pricing tool showing Friday, Saturday, and Sunday at the wrong rate. You take screenshots of the Airbnb calendar for the same three nights. You save both sets to a folder named with the listing ID and the date. Then you correct the minimum price floor in the pricing tool and verify that the corrected rates have pushed to Airbnb. You do not delete the screenshots.

Decision rule: If you cannot save the state before correcting, record in writing what you observed (rate shown, date, channel) and timestamp that note. A written record is weaker than a screenshot but better than nothing.

Copy-ready pricing exception register

A register is only useful if every entry follows the same format. Inconsistent entries make it impossible to spot patterns across incidents. The table below is the format to use. Copy it into a spreadsheet and add one row per incident.

How to use this register. Fill in every field at the time of the incident, not retrospectively. The fields you cannot fill in immediately (root cause, recovery confirmed) stay as "under investigation" or blank until you can complete them. A register with honest blanks is more useful than one filled in from memory a week later.

Pattern review. Once a quarter, scan the register for repeated root causes, repeated channels, or repeated date-range types (weekends, holidays, far-out dates). A pattern that appears more than twice is a process problem, not a one-off failure.

Prove recovery across the affected surfaces

Correcting the rate is not the same as confirming the correction held. Pricing tools push rates to channels on a schedule, and that schedule is not always immediate. A correction made in the tool at noon may not appear on the channel until the next sync, which could be hours later. If you check recovery only in the tool and not on the channel, you may be looking at the corrected rate in one place while the wrong rate is still live where guests can see it.

Recovery confirmation is a separate step from correction, and it happens on every surface that was affected.

How to confirm recovery:

1. Check the pricing tool's rate display for the affected dates. Confirm the correct rate is showing.
2. Check each affected channel's own calendar or rate display for the same dates. Do not rely on the tool's sync log. Look at the channel directly.
3. If the channel has a public-facing listing, check the rate as a guest would see it. On Airbnb, you can do this by opening the listing in a private browser window and entering the affected dates in the search.
4. Record the time you confirmed recovery on each surface.
5. If a booking arrived at the wrong rate before recovery, confirm that the booking record shows the rate the guest was charged, and note whether any action was taken on that booking.

Worked example, continued. You corrected the minimum price floor at 9:47 am. At 10:30 am you check the pricing tool and the three nights now show the correct rate. You open Airbnb in a private browser, enter the festival weekend dates, and confirm the rate shown to a prospective guest matches your corrected floor. You check your second channel (which was unaffected) as a control. You record: "Recovery confirmed on Airbnb at 10:31 am via private browser check. Second channel unaffected, no action required. Pricing tool confirmed at 10:30 am. Root cause: minimum price floor was set before the event was added to the local calendar and was not updated when the event was entered."

Checklist for recovery confirmation:

• Pricing tool rate display checked for all affected dates
• Each affected channel checked independently, not via sync log
• Public-facing listing checked as a guest would see it
• Time of each confirmation recorded
• Register updated with recovery confirmed and method

References

The processes in this guide are built on what is directly observable in the tools a host already has access to. No external data source is required to run this process. The following are the primary sources you will use.

Your pricing tool's rate calendar and history log. Most tools show a per-night rate view and a log of when rates were last pushed. Use both. The history log tells you when a rate was set; the calendar tells you what rate is currently queued.

Each channel's own calendar view. Airbnb's host calendar shows the rate per night as the channel will display it to guests. This is the authoritative source for what a guest on Airbnb will see, not the pricing tool's representation of what it sent.

The public listing as a guest sees it. A private browser window with no logged-in session removes any host-side view adjustments. Entering specific dates in the search gives you the rate a guest would be quoted at that moment. This is the final confirmation surface and the one most hosts skip.

Your own exception register. Over time, your register becomes a reference in its own right. A root cause that appears repeatedly is a configuration problem that the register will surface before it becomes a pattern you notice only after the fact.

Airbnb's Help Centre. For questions about how rate changes propagate, how sync timing works, and what a guest sees at booking versus at confirmation, Airbnb's own documentation is the appropriate source. Plausible explanations from forums or third parties are not substitutes for checking the platform's stated behaviour directly, and even the platform's stated behaviour should be verified against what you observe, because the two do not always match.

A note on unknown mechanisms. How Airbnb's search ranking responds to pricing changes, rate history, or booking conversion patterns is not publicly documented in a way that allows precise claims. It is plausible that a listing with a history of rate anomalies or booking cancellations is treated differently by the ranking system, but the mechanism is unknown. This guide does not make claims about ranking effects. It focuses on what you can observe and verify: the rate shown, the booking confirmed, the recovery completed.

Where this becomes someone else's job

Running a pricing exception log manually is feasible when you have one or two listings and the time to check calendars daily. As the portfolio grows, or as the gap between what the tool is doing and what you can monitor widens, the process described in this guide becomes a significant time commitment on top of everything else a host manages.

Revande's Performance service includes a full software stack for dynamic pricing with daily adjustments made by experienced rate strategists, Airbnb listing performance monitoring, and email alerts for low visibility or booking conversion, along with monthly reports. The exception log process described here is handled within that workflow rather than sitting with you.

Revande's Maestro service 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, compatibility with Airbnb or your channel manager, and ongoing listing refinements. At that level, the monitoring, the exception identification, and the recovery confirmation are all handled without requiring you to run the checklist yourself.

The decision point is straightforward. If you find yourself running this log consistently and catching issues before they result in confirmed bookings at the wrong rate, the process is working and you may be comfortable continuing it yourself. If you are finding issues only after a booking has already confirmed, or if you are not running the log at all because there is not enough time, that is the point at which the process belongs with someone whose job it is to watch it every day.