Rate-Sync Incident Runbook

A rate-sync failure is quiet until it is expensive. The price your guest sees on Airbnb may have stopped reflecting your intended rate hours or days ago, and nothing in your dashboard announces this with a red banner. You find out because a booking comes in at a rate you did not intend, or because you spot a calendar date showing a stale price while doing a routine check, or because a guest screenshots a price discrepancy and asks you to explain it.

The problem compounds because the same symptom, a wrong price on a live listing, can come from several different places in the chain between your rate strategy and the guest-facing calendar. Acting on the wrong diagnosis wastes time and can introduce new errors on top of the original one. This runbook gives you a repeatable sequence: classify first, contain second, escalate with evidence, and verify that every surface has recovered before you close the incident.

Classify the symptom before changing anything

The instinct when you see a wrong price is to correct it immediately. Resist that. A correction made before you understand the source can mask the failure, make it harder to reproduce, and leave the underlying cause intact so it fires again on the next pricing cycle.

Work through this classification before you touch a single rate field.

What you are trying to establish:

1. Is the wrong price live on the guest-facing listing right now, or only in a back-end tool?
2. Is the problem on one date, a range of dates, or every future date?
3. Did the price change recently, or has it been wrong for an unknown period?
4. Is the problem on one listing or multiple listings?

How to check each of these without changing anything:

Search for your listing as a logged-out guest, using a private or incognito browser window, from a device that has never been logged into your Airbnb host account. This removes personalization and host-view overlays. Note the price shown for the affected dates. Screenshot it with a timestamp visible.

Open your channel manager or pricing tool and note the rate it currently holds for those same dates. Screenshot that too.

Open the Airbnb host calendar directly and note what Airbnb is displaying as the nightly rate for those dates. Screenshot that.

You now have three data points: guest-facing price, source tool price, and Airbnb host calendar price. The relationship between them tells you where the break is.

Classification decision rule:

• If the guest-facing price matches the Airbnb host calendar but neither matches your source tool, the sync from source to Airbnb has failed or is delayed.
• If the guest-facing price does not match the Airbnb host calendar, there may be a caching or propagation delay on Airbnb's side, which is outside your control but worth documenting.
• If all three match but the price is still wrong relative to your strategy, the source tool itself is producing an unintended rate, and the sync is working correctly. The problem is upstream.
• If only some dates are affected, note the exact date range. A gap in a range often points to a specific sync event that failed rather than a systemic connection problem.

Do not proceed to any corrective action until you have written down which of these categories applies.

Open one incident record

Every rate-sync failure needs a single written record that travels with the incident from detection to resolution. This is not bureaucracy. It is the thing that prevents two people from making conflicting corrections simultaneously, and it is the evidence packet you will need if you escalate to Airbnb support or to Revande.

Open this record the moment you classify the symptom. It can be a shared document, a task in your property management system, or a plain text file. The format matters less than the discipline of keeping it current and keeping it in one place.

What to record at the moment you open the incident:

• Date and time you detected the problem (include your timezone)
• Who detected it and how (routine check, guest complaint, booking at wrong rate, automated alert)
• The listing or listings affected, identified by their Airbnb listing ID, not just the property name
• The affected date range on the calendar
• The prices you observed on each surface, with timestamps
• The price that should have been showing, and where that intended price is documented
• The classification you reached in the previous step
• The current status: under investigation, contained, escalated, or resolved

What to add as the incident progresses:

Every action you take, every response you receive, and every check you run goes into this record with a timestamp. If you correct a rate, write down what you changed it from and what you changed it to, and when. If you contact Airbnb support, paste the case number into the record. If a sync runs and the problem persists, note that too.

The record closes only when you have completed the verification step at the end of this runbook and written a one-sentence summary of the root cause.

Preserve the last-known-good state

Before you change anything in your pricing tool, your channel manager, or your Airbnb calendar, capture the current state of every affected surface. This is your baseline for verifying recovery later, and it is your evidence if the incident turns out to be caused by a third-party system error that requires a support case.

What to capture and how:

Take full-page screenshots of your pricing tool's rate calendar for the affected date range. If your tool has an export function, export the rate data to a file and save it with the incident record. Note the tool's last-sync timestamp if it displays one.

Take screenshots of the Airbnb host calendar for the affected dates. If Airbnb shows a "last updated" indicator anywhere on those dates, capture that.

Take screenshots of the guest-facing listing for the affected dates, as described in the classification step.

If you use a channel manager that sits between your pricing tool and Airbnb, capture the rate data in the channel manager for the same dates. This is the layer most often overlooked, and it is frequently where the break actually lives.

Save all of these files with filenames that include the listing ID, the date of capture, and the surface name. For example: listing-12345678-airbnb-host-calendar-2025-06-10.png. This makes it possible to reconstruct the timeline later without relying on memory.

Why this step matters even when the fix seems obvious:

If you correct the rate and the problem recurs on the next pricing cycle, you need to be able to show that the rate was correct at a specific point in time and then changed again without your instruction. That demonstration requires dated evidence of the corrected state, not just your recollection of it.

Triage source versus destination

With your classification done and your baseline captured, you can now work out where in the chain the failure originated. The chain has at most four links: your rate strategy, your pricing tool, your channel manager (if you use one), and Airbnb. The failure lives in exactly one of these links, or in the connection between two of them.

The triage table:

Work through the table from the top. The first row that matches your observation tells you where to focus. Do not skip ahead to a fix in a lower layer if the problem is in an upper layer. Fixing Airbnb's calendar manually while leaving a broken sync connection in place means the manual fix will be overwritten the next time the sync runs.

Checking connection status without making changes:

Most channel managers and pricing tools have a connection status page or an API health indicator. Look at this before you attempt any manual push or correction. If the connection shows an error, note the error code or message verbatim in your incident record. Do not attempt to reconnect or re-authenticate without first confirming that the credentials and permissions are still valid, because a failed reconnection attempt can sometimes invalidate a token and extend the outage.

If your tool shows a sync queue with pending items, note how many items are queued and how long the oldest item has been waiting. A queue that is growing but not draining points to a connection problem. A queue that is empty but rates are still wrong points to a configuration problem.

Contain with the least reversible authorized change

Containment means stopping the wrong price from being booked while you continue to investigate. It does not mean resolving the root cause. The goal here is the smallest intervention that prevents further harm, not the most thorough correction you can make.

The containment decision rule:

Ask yourself: what is the minimum change that prevents a guest from booking at the wrong rate right now?

In most cases, the answer is one of three things, in order of preference from least disruptive to most:

1. Block the affected dates temporarily so they cannot be booked while you investigate. This is reversible and does not introduce any new rate data into the system.
2. Manually set the rate on the affected dates in the Airbnb host calendar directly, as a temporary override, if blocking is not appropriate (for example, if the dates are close and you want to remain bookable). Document the override rate and the intended rate in your incident record.
3. Pause the sync connection if your tool allows it, to prevent further automated overwrites while you diagnose. Only do this if you are confident you can monitor and manage rates manually for the duration of the pause, and only if the sync is actively making things worse.

What not to do during containment:

Do not make changes in multiple layers simultaneously. If you manually correct the Airbnb calendar and also push a correction from your pricing tool at the same time, you will not know which action took effect, and you may create a conflict that triggers another sync error.

Do not change rate rules or pricing strategy settings during an active incident. Changes to rules can have effects across many dates and listings, and you need a stable baseline to verify recovery. Save rule changes for after the incident is closed.

Do not close the incident record after containment. Containment is not resolution. The record stays open until the root cause is addressed and recovery is verified on every surface.

Escalate with an evidence packet

Some rate-sync failures are outside your ability to resolve directly. A broken API connection between your channel manager and Airbnb, a bug in your pricing tool's sync logic, or an Airbnb platform issue all require escalation to the relevant party. Escalating without evidence wastes everyone's time and often results in a support agent asking you to reproduce the problem from scratch.

What goes in the evidence packet:

The evidence packet is a subset of your incident record, organized for someone who has no prior context. It should contain:

• A one-paragraph summary: what you observed, when, on which listing, and what the intended rate was
• The screenshots you captured in the preserve-state step, labeled clearly by surface and timestamp
• The triage finding: which link in the chain you believe is broken, and what evidence supports that conclusion
• The containment action you took and when
• Any error codes, sync timestamps, or queue status information you captured
• The Airbnb listing ID and, if relevant, the channel manager connection ID or API key identifier (not the key itself)

Who to escalate to and in what order:

If the break is between your pricing tool and your channel manager, contact your pricing tool's support first. Provide the error code and the last successful sync timestamp.

If the break is between your channel manager and Airbnb, contact your channel manager's support first. Airbnb's connectivity support for channel managers operates through a separate pathway from standard host support, and your channel manager's team will often have a direct contact there.

If the break appears to be on Airbnb's side (the host calendar shows the correct rate but the guest-facing listing does not, and the discrepancy has persisted beyond a reasonable interval), contact Airbnb host support directly. Use the in-platform messaging tool rather than the phone line if you want a written record of the exchange. Paste your case number into the incident record the moment you receive it.

If you are a Revande client, contact your Revande point of contact before escalating externally. Your Revande team may already be aware of a platform-wide issue, may have a faster escalation path, or may be able to identify that the problem is in a layer you have not yet checked.

What to ask for explicitly:

When you escalate, ask for a written confirmation of the root cause once it is identified, and ask for a confirmation that the fix has been applied. Do not accept "it should be working now" as a resolution. Ask the support agent to confirm what specifically was changed and when, and add that information to your incident record.

Verify recovery on every affected surface

Recovery is not complete until you have confirmed the correct rate on every surface in the chain, not just the one you corrected. A fix applied at the source that has not yet propagated to the guest-facing listing is not a recovery. It is a recovery in progress.

The verification sequence:

Run through the surfaces in order from source to destination, using the same method you used during classification: logged-out, incognito browser, timestamped screenshots.

First, confirm the rate in your pricing tool or rate strategy document matches the intended rate for every affected date.

Second, confirm the rate in your channel manager (if applicable) matches the pricing tool.

Third, confirm the rate in the Airbnb host calendar matches the channel manager.

Fourth, confirm the rate on the guest-facing listing matches the Airbnb host calendar.

If any surface does not match the one above it in the chain, the recovery is incomplete. Return to the triage step for that specific gap.

The verification checklist:

• Pricing tool shows intended rate for all affected dates: confirmed with screenshot and timestamp
• Channel manager shows matching rate for all affected dates: confirmed with screenshot and timestamp
• Airbnb host calendar shows matching rate for all affected dates: confirmed with screenshot and timestamp
• Guest-facing listing (logged-out, incognito) shows matching rate for all affected dates: confirmed with screenshot and timestamp
• No new bookings came in at the wrong rate during the incident window: checked against booking history
• If any bookings did come in at the wrong rate: documented separately for commercial review
• Incident record updated with root cause summary and resolution timestamp
• Incident record closed

How long to wait between checks:

Sync propagation times vary by tool and by platform load. They are not published as guarantees by any platform. After applying a fix, wait for at least one full sync cycle as indicated by your tool's sync frequency setting before running the guest-facing verification. If your tool does not display a sync frequency, check its documentation or contact support to find out how often it pushes to Airbnb. Do not assume the guest-facing listing has updated just because the host calendar has updated. They can diverge temporarily.

References

The following resources are referenced in this runbook. They are listed here so you can locate them directly rather than searching for them during an active incident.

Airbnb host resources:

Airbnb's host calendar and pricing settings are accessible from your hosting dashboard under the Calendar tab. Rate overrides for individual dates are applied by selecting the date and editing the price directly in the host calendar.

Airbnb host support can be reached through the Help section of your hosting dashboard. Use the messaging option to create a written record of the support interaction.

Airbnb's connectivity support for channel managers is typically accessed through your channel manager's support team rather than directly. Ask your channel manager's support contact for the appropriate escalation path.

Your own tools:

Your pricing tool's API connection status page and sync log are the primary diagnostic surfaces for source-to-destination triage. Locate these pages before an incident occurs and bookmark them. The same applies to your channel manager's connection health dashboard.

Your channel manager's documentation will specify the sync frequency and the expected propagation time to Airbnb. Read this documentation and note the relevant figures in a reference document you keep alongside this runbook.

Your incident record:

The incident record template described in this runbook should be saved somewhere accessible to everyone who manages your listings. A shared folder, a property management system task template, or a pinned document in your team's communication tool all work. The point is that the person who detects the next incident can open a new record immediately without having to reconstruct the format from memory.

Revande documentation:

If you are a Revande client, your onboarding documentation includes the contact details for your Revande point of contact and the escalation pathway for rate-sync issues. Keep this accessible alongside the runbook.

Where this becomes someone else's job

Running this runbook correctly requires time, attention, and access to every layer of your rate-sync chain. For hosts managing multiple listings, or for anyone who cannot afford to be the person watching for sync failures at all hours, the monitoring and response work can be handed off.

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 issues, along with monthly reports. When an alert fires, you receive it and decide what to do next.

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 directly or with your channel manager, and ongoing listing refinements. When a performance issue is detected, it is addressed without waiting for you to act on an alert.

The distinction matters for rate-sync incidents specifically. An alert tells you something is wrong. A service that handles the issue for you means the wrong rate is less likely to stay live long enough to affect a booking.