Build a Demand Calendar

Most hosts who try to build a demand calendar start in the wrong place. They open a spreadsheet, write down a few events they already know about, and treat the result as a finished document. The problem is not the spreadsheet. The problem is that the calendar now contains a mix of things that are almost certainly true, things that might be true, and things that were true last year but have not been checked this year, and nothing in the document tells you which is which.

The second problem follows from the first. When a calendar with no confidence labels sits next to a pricing tool, the pricing tool treats every row as equally reliable. You end up with rate adjustments driven by a festival that was cancelled, a conference that moved venues, or a school holiday that applies to a different catchment area than your property. The fix is not more data. The fix is a structured process that keeps the signal separate from the decision until the signal has been tested.

Keep the signal separate from the decision

A demand signal is a fact about the world. A pricing decision is a judgment about how your listing should respond to that fact. These are two different activities, and mixing them in the same step is where most calendar-building goes wrong.

When you record a signal, your only job is to capture what you observed, where you observed it, and when you captured it. You are not yet asking whether it matters to your listing, whether it will fill your market, or what rate you should charge. That question comes later, and it comes after the signal has been labelled for confidence.

Why the separation matters in practice

Suppose you read a local news article saying a regional sporting event will bring several thousand visitors to your city. If you immediately jump to a pricing decision, you are treating an unverified news article as a confirmed demand driver. The article may be accurate. The event may also be smaller than reported, held in a suburb that does not overlap with your guest profile, or cancelled after the article was published. None of that is knowable at the moment you read the article.

The separation rule forces you to write down: "Regional sporting event reported in local news, date of article, event dates, source URL." Then you stop. The confidence label and the pricing decision happen in separate steps, on a separate review pass.

Checklist: signal capture only

• Record the raw fact as stated by the source, not your interpretation of it.
• Record the source name, source type, and the date you captured it.
• Leave the confidence field blank until the review step.
• Leave the pricing action field blank until after confidence is assigned.
• Do not delete a signal because it seems irrelevant. Record it and label it later.

Use sources that have authority over the fact

Not all sources are equally positioned to know what they are reporting. A local council website has authority over the dates of a public event it is organising. A travel blog republishing that information does not. The distinction matters because secondary sources introduce a lag and an error rate that primary sources do not.

Authority means the source is the entity that controls or directly observes the fact in question. The council controls the event dates. The venue controls the capacity and the booking status. The school district controls the term dates. A news article, a social media post, or a tourism aggregator may be accurate, but they are downstream of the authority source and should be treated as lower confidence until confirmed against the primary.

Decision rule: authority test

Before recording a source, ask: is this the entity that controls or directly observes this fact, or is this entity reporting something it learned from somewhere else? If the answer is "reporting from somewhere else," record it as a secondary source and flag it for primary confirmation before use.

Sources by authority level

• Government and council websites: high authority for public events, road closures, and school terms they administer.
• Venue websites and official event pages: high authority for event dates, capacity, and cancellation notices.
• Tourism board calendars: medium authority, often accurate but sometimes slow to update cancellations.
• Local news outlets: medium authority for initial reporting, lower authority for confirming that an event is still proceeding.
• Social media and community forums: low authority, useful for discovering signals you had not found elsewhere, not useful for confirming them.
• Your own booking history: high authority for what happened at your property, not authority for what will happen in the market.

Record the source before judging relevance

There is a strong temptation to filter as you go. You find a source, decide it probably does not apply to your listing, and move on without recording it. This is a mistake for two reasons.

First, relevance is a judgment you are making without complete information. A corporate conference that seems unrelated to your leisure-focused listing may still affect your market if it fills the hotels and pushes corporate overflow guests toward short-term rentals. You do not know that at the moment of capture.

Second, a source you record today and mark as low relevance may become high relevance next month when circumstances change. A source you never recorded cannot be revisited.

Worked example

You are building a calendar for a two-bedroom apartment in a mid-sized city. You find a reference to an annual trade show that attracts business travellers. Your listing is marketed toward families and leisure guests. You might be tempted to skip it.

Instead, record it: "Annual trade show, city convention centre, dates, source URL, captured date." In the relevance column, write "low, business-focused event, leisure listing." In the confidence column, write "pending." Three months later, you notice an unusual booking pattern during those dates. You return to the source log, find the trade show entry, and now have a starting point for investigation. If you had not recorded it, you would be starting from nothing.

Checklist: source recording discipline

• Record every signal you encounter during a research session, regardless of apparent relevance.
• Record the URL or document reference so you can return to the primary source.
• Record the date you captured it, not the date of the event.
• Write a one-line description of why you initially judged it low relevance, if you did. This note is useful when you revisit.
• Never delete a row. Mark it as superseded or cancelled instead.

Add property relevance without calling it demand

Once a signal is recorded, you need to assess whether it is likely to affect your specific property. This is not the same as assessing demand. Demand is a market-level concept. Property relevance is a narrower question: given what this event or period is, is it plausible that it would affect the type of guest who books my listing?

The reason to keep this separate from the word "demand" is that "demand" implies a magnitude. You do not know the magnitude. You are only assessing whether the signal is in the right category to be relevant to your listing.

Factors to assess for property relevance

• Guest profile match: does the event attract the type of guest who typically books your listing (families, couples, business travellers, groups)?
• Geographic proximity: is the event close enough that guests attending it would plausibly stay at your location rather than somewhere closer to the venue?
• Accommodation type match: does your property suit the accommodation needs of event attendees (number of bedrooms, amenities, price range)?
• Duration match: does the event duration align with the stay lengths your listing typically attracts?

Decision rule: relevance scoring

Score each signal on three levels only. High relevance means the signal matches on at least three of the four factors above. Medium relevance means it matches on two. Low relevance means it matches on one or fewer. Do not invent a numerical scale. Three levels is enough to make a decision, and a finer scale implies a precision you do not have.

Apply confidence labels with evidence rules

Confidence is not a feeling. It is a label that reflects the quality of the evidence behind a signal. If you cannot state the evidence rule that justifies a confidence label, the label is not valid.

The three confidence levels and their evidence rules

Confirmed: The signal has been verified against a primary authority source within the last review cycle, and the primary source shows the event or period as proceeding as described. A confirmed label expires at the next review cycle and must be re-verified to remain confirmed.

Plausible: The signal comes from a credible secondary source, or from a primary source that has not been checked in the current review cycle. The event or period is consistent with patterns you have observed in your own booking history. A plausible label is sufficient to flag a period for monitoring but is not sufficient to drive a pricing action on its own.

Unverified: The signal comes from a single secondary source, a social media post, or word of mouth. The primary source has not been located or has not confirmed the information. An unverified label means the signal stays in the log but does not influence any pricing decision until it is upgraded.

Worked example

You find a reference to a music festival on a tourism blog. You record it as unverified. You then find the festival's official website, which lists the dates and confirms ticket sales are open. You upgrade the label to plausible. You then check the local council's events calendar, which also lists the festival with the same dates. You upgrade to confirmed. At your next review cycle, you return to the festival's official website and confirm the dates have not changed. The confirmed label holds.

If at any point the official website shows the event as cancelled or postponed, you update the label to unverified and add a note: "Cancellation noted on official site, date of check." You do not delete the row.

Set review ownership and invalidation before use

A demand calendar that is not reviewed on a schedule is a historical document, not a planning tool. The review cadence and the rules for invalidating stale signals must be decided before the calendar is used for any pricing decision.

Review ownership

Assign one person as the owner of each review cycle. If you manage your listing alone, that person is you. If you work with a co-host or a management team, the owner is named explicitly. Ownership means: this person is responsible for checking every confirmed and plausible signal against its primary source before the calendar is used in the next pricing cycle.

Invalidation rules

A signal is invalidated when any of the following occur:

• The primary source shows the event as cancelled, postponed, or changed in a way that affects the relevance assessment.
• The signal has not been re-verified within the agreed review cycle and the event date is within a threshold period you define (for example, within the next ninety days).
• New information from a primary source contradicts the original signal.

An invalidated signal is not deleted. It is marked as invalidated with the date and reason. This record is useful for understanding why a pricing decision was or was not made in a given period.

Review cadence decision rule

Set your review cycle based on how far ahead you are pricing. If you are managing rates more than ninety days out, review the full calendar monthly. If you are managing rates within a ninety-day window, review weekly for any signals in that window. Any signal that has not been reviewed within its cycle reverts to plausible regardless of its previous label.

Copy-ready local demand source log

The table below is a template you can copy into a spreadsheet. Each column has a defined purpose. Do not add columns without defining what evidence rule governs them.

Keep this log in a shared location if more than one person touches your pricing. A log that only one person can access is a single point of failure.

A fictional format example

The following is a fictional example showing how a completed row might look. The event, location, and dates are invented for illustration only.

Signal ID: SIG-012 Signal description: Lakeside Half Marathon, annual running event, start and finish at Lakeside Park, attracts participants from outside the region. Event dates: 7 June to 8 June. Source name: Lakeside Half Marathon official website. Source type: Primary. Source URL: lakehalfmarathon.example.com/2025. Capture date: 15 February 2025. Confidence label: Confirmed. Evidence rule met: Primary authority source, event listed as open for registration, dates confirmed on official site within current review cycle. Property relevance: Medium. Running events attract active travellers, but the listing is a three-bedroom family home. Participants are more likely to book smaller or closer properties. Worth monitoring for spillover if nearby accommodation fills. Last review date: 1 April 2025. Review owner: Host. Status: Active. Invalidation note: (blank).

This row does not contain a pricing decision. It contains a signal, a confidence label with its evidence rule, a relevance judgment with its reasoning, and a review record. The pricing decision happens in a separate step, after a firewall check.

Put a firewall before any pricing action

The firewall is a mandatory pause between the demand calendar and any change to your rates or minimum stay settings. Its purpose is to prevent a single unverified or plausible signal from driving a pricing action without a second check.

The firewall has three gates

Gate one: confidence check. Is the signal that is driving the proposed action labelled as confirmed? If it is plausible or unverified, the action does not proceed until the label is upgraded or the action is explicitly approved by the review owner with a written note explaining why a lower-confidence signal is being acted on.

Gate two: relevance check. Is the property relevance rated as medium or high? A low-relevance signal does not drive a pricing action. It may be promoted to medium if new information supports that, but the promotion must be recorded in the log before the action proceeds.

Gate three: recency check. Has the signal been reviewed within the current review cycle? A confirmed label from three months ago on a signal that has not been re-verified is not a current confirmed label. It is a stale confirmed label, and a stale confirmed label does not pass the firewall.

Decision rule: firewall passage

A signal passes the firewall only when all three gates are cleared. If any gate fails, the action is paused, the log is updated, and the signal is re-evaluated before any pricing change is made.

This rule will feel slow the first time you apply it. That is the point. A pricing action taken on a stale or unverified signal can result in rates that are misaligned with actual conditions in your market, either too high for a period that turns out to be quiet, or too low for a period that turns out to be in high demand. The firewall does not eliminate that risk, but it reduces the number of times you act on bad information.

References

The sources you use to build your calendar should themselves be recorded in a reference list separate from the signal log. The signal log records individual signals. The reference list records the standing sources you check on each review cycle.

What belongs in the reference list

• Official government and council event calendars for your area.
• School term date publications from the relevant education authority.
• Venue websites for major venues within a plausible travel radius of your listing.
• Tourism board event listings for your region.
• Your own listing's booking history, exported at each review cycle and stored with a date stamp.

What does not belong in the reference list

• Sources you checked once and found nothing. These do not need to be standing references unless they are authoritative for a category of signal you want to monitor regularly.
• Social media accounts or community forums. These are discovery tools, not standing references. When a social media post leads you to a signal, record the signal and then verify it against a primary source. The social media post is not the reference.

Maintaining the reference list

Review the reference list itself at least once per quarter. Sources go offline, councils change their website structures, and venues close or change ownership. A reference that returns a 404 error is not a valid reference. Replace it or remove it and note the date.

Worked example: reference list entry

Source name: Riverside City Council Community Events Calendar. URL: council.riversidecity.example.gov/events. Check frequency: monthly. Last checked: 1 April 2025. Notes: Calendar updates approximately two weeks before each month. Check in the first week of each month for the following month's additions.

That entry tells you what the source is, where to find it, how often to check it, when you last checked it, and one practical note about its update pattern. A reference list entry without a last-checked date is not a maintained reference.

Where this becomes someone else's job

If the process described in this guide is the right one but the time it requires is not available to you, that is a resourcing question, not a methodology question. The methodology does not get simpler by skipping steps. It gets less reliable.

Revande offers two services that address this directly.

Performance provides a full software stack for dynamic pricing, with daily adjustments made by experienced rate strategists. It includes Airbnb listing performance monitoring and email alerts for low visibility or booking conversion, along with monthly reports. If you want the pricing decisions handled by people who do this work daily, and you want to be notified when something in your listing's performance changes, Performance is the starting point.

Maestro includes everything in Performance and adds done-for-you listing optimization. It provides proactive Airbnb listing performance monitoring, with visibility and booking conversion issues handled for you rather than flagged for you to act on. Maestro works with Airbnb directly or with your channel manager, and it includes ongoing listing refinements as conditions change. If the demand calendar process, the listing work, and the performance monitoring all need to sit with someone else, Maestro covers that scope.

The difference between the two is not the quality of the monitoring. It is who does the work after the monitoring surfaces something.