How to Set Up the 75/55 Rule in PriceLabs Without Inventing a 75/55 Mode

Start With the Translation, Not the Tool

The 75/55 framework belongs to the strategy layer. PriceLabs belongs to the execution layer. Strategy decides the target and the floor. The tool turns those decisions into prices for specific dates.

That order protects you from a common mistake: opening PriceLabs and changing fields before the pricing policy is clear. When the tool becomes the strategy, the host cannot tell whether the target was wrong, a customization was wrong, or an override won.

Write the policy first:

• Target ADR: the working anchor for ordinary nights.
• Framework floor: target ADR multiplied by 0.55.
• Cost floor: the lowest acceptable rate from verified unit economics.
• Effective floor: the higher of the framework and cost floors.
• Discount zone: the limited calendar share where deeper last minute action is permitted.
• Exceptions: named events, gaps, or dates that require a reviewed override.

The effective-floor step comes from combining the 75/55 framework with the cost-floor logic in the canonical Rakidzich pricing guide. It is a practical safety rule. It is not a new PriceLabs feature.

PriceLabs should execute a decision you can explain. It should not make the decision invisible.

Finish Four Inputs Before You Open PriceLabs

Do not configure a dynamic pricing tool with an unfinished worksheet. Four inputs should be written and dated first.

1. A defended target ADR

Use current comparable choices, the listing's condition, the dates in question, and the property's own evidence. Do not use the highest visible competitor or a generic city number. State why the target fits this listing.

2. The 55% framework floor

Multiply target ADR by 0.55. If target ADR is $200, the illustrative framework floor is $110. The arithmetic is computed. The $200 input is not a market fact.

3. A separate cost floor

Use records for fixed costs and variable costs. Use labeled planning assumptions where evidence is incomplete. The 75/55 calculator guide walks through the distinction.

4. A review and rollback point

Choose when you will inspect the pushed rates, how you will identify a bad change, and which prior settings you will restore. A tool change without rollback evidence is a bet you cannot audit.

Step 1: Set a Base Price That Matches the Target Logic

PriceLabs uses the term Base Price for the foundation on which market factors, demand patterns, and customizations act. Its current help article describes Base Price as an average rate across the year rather than a peak price or a floor (PriceLabs pricing-control documentation).

That is close to the job of the target ADR, but do not assume the two fields are always identical. Your target may apply to a date group, a season, or another pricing decision. PriceLabs Base Price supports its own calculation system across the calendar, so map the concepts deliberately (PriceLabs pricing-control documentation).

If one annual Base Price would flatten a highly seasonal listing, use PriceLabs controls supported by current documentation and your account. Do not invent a feature name. If the interface differs from this article, stop and read the current help page before saving.

After setting Base Price, inspect the recommended rate for several ordinary, stronger, and weaker dates. Ask whether the shape makes sense. Do not judge the setup from one Tuesday or one event weekend.

Record the old and new value. If you cannot explain why the Base Price moved, leave it alone until you can.

Step 2: Put the Effective Floor in Minimum Price

PriceLabs says its Minimum Price is the lowest rate it will recommend for a listing when the calculated recommendation would otherwise fall lower. That is the natural home for the effective floor (PriceLabs pricing-control documentation).

If the 55% framework floor is $110 and the cost floor is $96, use $110 as the working minimum. If the framework floor is $110 and the cost floor is $128, use $128. The higher line controls.

This setup does not make the minimum unbreakable. PriceLabs documents exceptions. A fixed Date-Specific Override can take precedence over Minimum Price. Certain fixed customizations can also change the result. That is why the configuration needs an override audit (PriceLabs below-minimum documentation).

Do not set Minimum Price to 55% of an unverified Base Price simply because the fields are close together. Calculate the framework floor from the target ADR you selected in the strategy layer. Then compare it with costs.

Do not accept a PriceLabs safety minimum as a substitute for the 75/55 decision. PriceLabs documents its own safety values when Min and Max are blank. Those defaults belong to PriceLabs, not Sean's framework. Enter the floor you have actually reviewed.

Step 3: Bound the Last Minute Prices Customization

PriceLabs currently documents a customization called Last Minute Prices. Available options include fixed, flat percentage, gradual percentage, no last-minute adjustment, and market-driven variants for eligible listings. Product options can change. Verify the current page before acting (PriceLabs last-minute documentation).

The 75/55 framework does not tell you one universal number of days. It tells you to protect most of the calendar and limit aggressive action to a smaller last-minute zone. Build the timing from your listing's observed booking pace, day type, event context, and economics.

Start with the least aggressive curve that tests the idea. A host with thin evidence should avoid pretending a detailed ladder is proven. Use a bounded setting. Inspect the resulting rates. Record what happens.

Use percentage math against the actual starting rate

A percentage discount acts on a price. It does not know your effective floor unless the surrounding controls enforce it. Before saving, calculate the lowest possible result for several dates. Include any other active pricing rules.

Avoid a fixed last minute price without a floor check

PriceLabs documents fixed last minute pricing as a specific price for the selected time frame. A fixed value can create a blunt result across dates with different demand. It may also have different precedence than percentage adjustments. Use it only when you understand the final rate and the override hierarchy (PriceLabs below-minimum documentation).

Use no adjustment when evidence says hold

A blank calendar is not automatic proof that the rate is wrong. If visibility, listing quality, availability, or restrictions are the problem, a price cut may only make a weak offer cheaper. The 75/55 troubleshooting guide shows how to isolate the symptom.

Step 4: Treat Date-Specific Overrides as Exceptions With Power

PriceLabs describes a Date-Specific Override as a manual change for dates. It can adjust price, minimum stay, and check-in and checkout rules. The product supports different override types and levels (PriceLabs below-minimum documentation).

The important part for 75/55 control is precedence. PriceLabs says a fixed Date-Specific Override can go outside the usual lowest and highest price boundary. Its documentation also says a fixed override can take precedence over the listing Minimum Price (PriceLabs below-minimum documentation).

That means a host can build a correct Minimum Price and then bypass it with one event or gap override. The tool is behaving according to the selected control. The strategy has still failed in execution.

Use a date exception only for a named reason. Record the date range, old price, new logic, override type, owner, expiry. A calendar full of permanent exceptions is not a system. It is a hidden manual spreadsheet.

For a peak event, a fixed higher price may be reasonable if the evidence supports it. For a gap, a percentage move may preserve some dynamic behavior. The correct choice depends on the exact date and current control behavior, not on a universal recipe.

Handle Weekends, Events, and Seasonal Dates Without Breaking the Floor

The 75/55 framework does not say all nights are equal. It says the operator protects the broad calendar anchor and limits the deepest discounting. A Saturday during a major event may sit far above target ADR. A weak midweek date may move closer to the floor. Both can obey the same boundary.

Use date evidence before adding an override. Check the live guest choices, your own pickup, local event dates, restrictions, listing quality. Do not import an event premium or weekday cut from another property.

For each exception, answer three questions:

1. What makes this date different from an ordinary date?
2. Which PriceLabs control expresses that difference?
3. What final rate reaches Airbnb after all active logic?

If the final question cannot be answered, do not save the exception. A sophisticated control stack that nobody can trace is weaker than a simple stack with a clear audit.

Use the 75/55 discount curve guide to design the timing before you touch tool settings.

For a wider tool audit beyond this framework, read the full PriceLabs settings guide.

Check the Airbnb Side of the Connection

Treat PriceLabs as the recommendation layer in this workflow, then inspect the connected channel where the guest sees the result. Confirm the expected dates, currency, minimum stay, and final nightly rate.

Airbnb documents its own pricing tools, including default prices, custom nightly prices, Smart Pricing, discounts, promotions, and rule sets. Those Airbnb controls can interact with or override other settings. Do not assume the number visible in one PriceLabs screen is the final guest-facing number (Airbnb nightly-pricing documentation; Airbnb Smart Pricing documentation; Airbnb rule-set documentation).

Airbnb says discounts can make the guest price fall below the minimum set in Smart Pricing. Airbnb also says Smart Pricing overrides rule sets. These facts concern Airbnb's own controls, not the 75/55 framework. They show why a final-channel check matters (Airbnb Smart Pricing documentation; Airbnb rule-set documentation).

If the final number is wrong, stop changing inputs. Trace the path: strategy value, PriceLabs recommendation, customization, override, sync status, Airbnb control. Find the first point where expected and observed state differ (PriceLabs override documentation).

Run a Seven-Point Audit Before You Trust the Setup

Audit a mix of date types. Use an ordinary weekday, an ordinary weekend, a last-minute date, a far-out date, an event date, and a date with an override. One passing date does not prove the stack.

Keep screenshots or exported settings where policy allows. Record the timestamp. A later rate mismatch is easier to diagnose when the last known good state is visible.

Use a Rollback Plan for Every Pricing Change

A rollback plan is not dramatic. It is a short record of the values you will restore if the change creates a bad rate, breaks a restriction, or sends unexpected prices.

Before editing, save:

• Current Base, Minimum, and Maximum Price values
• Current Last Minute Prices selection and inputs
• Active Date-Specific Overrides and their levels
• Current sync state
• A sample of final Airbnb calendar prices

Define a stop condition. Examples include an observed rate below the effective floor, an override on the wrong dates, a sync that changes more listings than intended, or a restriction that blocks valid demand. These are control failures, not invitations to keep tuning.

Restore the last known good values. Verify PriceLabs. Verify the sync. Verify Airbnb. Then diagnose the cause before trying a second change.

If you cannot restore the prior state, you do not yet have a controlled pricing test.

Walk Through a Sample Configuration Without Treating It as a Recommendation

This example shows the sequence, not the right values for your listing. Every dollar and timing input below is illustrative.

Assume a host has a defended target ADR of $200. The framework floor is $110. The host's cost worksheet produces a $124 cost floor. The effective working floor is $124 because it is higher.

The host reviews the PriceLabs Base Price. The current value is $175. The strategy record supports a $200 annual pricing foundation for the listing. Before changing it, the host saves the old Base Price, takes a settings snapshot, and records which dates will be checked (PriceLabs pricing-control documentation).

The host then sets Minimum Price to the illustrative $124 effective floor. That entry does not end the work. The host lists every fixed Date-Specific Override and every active Last Minute Prices customization.

For the last-minute setting, assume the host chooses a percentage adjustment over a bounded date range. The host calculates the lowest result it could create on an ordinary weekday, a weekend, and an already discounted date. If any result falls below $124, the customization must be changed before it is trusted.

Next, the host finds an event date with a fixed Date-Specific Override. The fixed price is $118. PriceLabs documentation says a fixed override can take precedence over Minimum Price. The host therefore raises, removes, or replaces that override so it no longer breaks the effective floor. The choice depends on the event evidence and current tool options (PriceLabs below-minimum documentation).

After saving, the host waits for the intended sync and opens Airbnb. Six date types are checked: ordinary weekday, ordinary weekend, last-minute weekday, last-minute weekend, event date, and a date with no exception. The final rate for each is recorded.

If all six readbacks match the policy, the host starts a bounded observation period. No other price input changes during that test unless a stop condition fires. If a rate drops below $124, the host restores the saved setting and traces the override path.

This example does not claim that a $200 Base Price, a $124 minimum, or any sample timing will improve revenue. It demonstrates a controlled way to move from policy to tool to channel and back to evidence.

Repeat the readback after any later override change. A setup that passed yesterday can fail after one new fixed exception.

PriceLabs Setup Mistakes That Break the Framework

Calling the Minimum Price the 55 number without checking costs

The framework floor may sit below the cost floor. Use the higher line.

Using Base Price as both target and floor

Base Price and Minimum Price have different jobs in PriceLabs. Do not collapse them.

Leaving default last minute logic unreviewed

A product default belongs to the product. It is not evidence that the setting matches your operator framework.

Using a fixed override below the floor

PriceLabs documents that a fixed Date-Specific Override can take precedence over Minimum Price. Audit every fixed exception (PriceLabs below-minimum documentation).

Changing the account level when one listing was intended

Confirm the level before saving. A narrow property test should not silently become a portfolio change.

Trusting the tool screen without checking Airbnb

The connected channel is the final evidence surface. Inspect the dates after sync.

Read the Setup in Plain Steps

Open one listing. Read its Base Price. Read its Minimum Price. Read the last minute rule. Read each fixed date change. Check for a weekend rule. Check for an event rule. Save the current state. Write the rate you expect on one test date. Push no new rule yet.

Next, check the same date in Airbnb. Read the final rate. Read the full guest cost. Compare the result with your safe floor. If the rate is wrong, trace one layer at a time. Start with the fixed date change. Then read the last minute rule. Then read other discounts. Do not add a new rule to hide a bad old rule.

Make one safe change. Sync it. Read the date again. Keep the change only when the result fits the plan. If it does not, use the saved state. A clean setup is easy to read. It is also easy to undo.

Use one date as a canary

Pick a date with no event, gap, or unusual stay rule. This is the canary date. Write its source rate and the rate you think Airbnb should show. Make the small change on that date or its narrow rule set, wait for the planned sync, and then read both sides again (Airbnb rule-set documentation).

If the canary is wrong, stop the broad change. Trace the field that wrote the bad rate. Check if a fixed date change won. Check if a promo still applies. Check if Airbnb holds its own custom price. Restore the old state if you cannot explain the result (Airbnb nightly-pricing documentation).

Expand only after the canary is clean

A clean canary does not prove all dates are safe. It proves that one plain case acts as planned. Next, check a weekend, a gap, an event date. Keep each check tied to its own class. Read the rate after each step.

Do not copy one result to the whole year. The point of the canary is to catch a bad map with low risk. The point of the next checks is to find where the map must change. Each safe read adds trust to the setup.

Hand the setup to a second reader

Ask them to point to the Base Price. Ask them to point to the safe floor. Ask which rule can cut the rate late. Ask which fixed date can win. Ask where the old state is saved. Do not coach them through the screen.

If they cannot trace the path, the setup may be too hard to own. Use fewer rules. Use plain names in the change log. Keep each date class clear. The tool should aid the plan. The team should not need to guess what the tool did.