Portfolio Pricing RACI

Running pricing decisions across more than a handful of listings without a clear ownership map is a reliable way to create expensive contradictions. One co-host drops a floor rate to fill a slow week. A property manager approves a long-stay discount that conflicts with a minimum set by the owner. A virtual assistant updates a base price in the channel manager without knowing that a seasonal floor was already in place. Nobody did anything wrong in isolation. The problem is that nobody knew what the others were doing, because nobody had written down who was allowed to decide what.

The RACI model (Responsible, Accountable, Consulted, Informed) is a standard governance tool that most portfolio operators know by name but rarely apply to pricing specifically. Pricing decisions have a structure that general task management does not capture well: they involve floors that constrain other decisions, overrides that temporarily supersede standing rules, approvals that must happen before a change goes live, and escalations that define what happens when the person who should decide is unavailable or when a situation falls outside the normal range. This guide walks through building a pricing RACI that covers all four of those layers, with a worked example you can adapt to your own portfolio.

Set the boundary before assigning names

A RACI only works if the scope is defined before you start filling in names. In pricing governance, scope means two things: which decisions are inside the RACI, and what authority level each role carries.

Start by writing a one-sentence boundary statement for your portfolio. It should answer: what pricing actions can be taken without any approval, what actions require approval before execution, and what actions are outside the authority of the operating team entirely and require owner sign-off? Until you have written that sentence, any RACI you build will have gaps that people fill with their own assumptions.

Boundary statement template:

"Any rate change within the standing floor and ceiling for a listing's cohort may be made by the rate manager without approval. Any change to a floor, ceiling, or minimum stay that affects a full cohort requires owner approval before execution. Any structural change to pricing strategy (new seasonal model, new long-stay discount policy) requires owner approval and a written record."

Once you have a boundary statement, assign authority levels to each role in your team. A useful set of levels for most portfolios:

• Level 1: Can view pricing data, cannot change anything
• Level 2: Can adjust rates within standing floors and ceilings
• Level 3: Can set or change floors and ceilings within a cohort
• Level 4: Can change cohort definitions, pricing strategy, or policy

Checklist before you proceed:

• Boundary statement written and shared with all team members
• Every person who touches pricing has been assigned a level
• Every person knows what level they hold and what it permits
• The boundary statement is stored somewhere all team members can find it (not just in someone's email)
• You have identified who holds Level 4 authority for each listing or cohort

Do not move to the next step until this checklist is complete. A RACI built on top of undefined authority levels will be ignored the first time a decision feels urgent.

Inventory the decisions that need governance

Before you can assign roles, you need a complete list of the pricing decisions that actually occur in your portfolio. Most operators underestimate this list because they think of pricing as a single decision. It is not. It is a family of related decisions, each with different frequency, different stakes, and different information requirements.

Work through your last three months of pricing activity and write down every type of change that was made. If you do not have records, interview everyone on your team who touches pricing and ask them to describe the last five changes they made or requested. You are looking for decision types, not individual instances.

A typical portfolio will surface most of these:

Rate decisions:

• Setting or updating a base rate for a listing
• Adjusting a nightly rate for a specific date or date range
• Accepting or declining a price suggestion from a dynamic pricing tool
• Setting a minimum rate (floor) for a listing or cohort
• Setting a maximum rate (ceiling) for a listing or cohort

Discount and promotion decisions:

• Enabling or adjusting a last-minute discount
• Enabling or adjusting an early-bird discount
• Setting a weekly or monthly discount
• Applying a one-off promotional rate for a specific event or period

Minimum stay decisions:

• Setting a default minimum stay
• Overriding minimum stay for specific dates
• Setting a minimum stay exception for a gap fill

Override and exception decisions:

• Approving a rate below the standing floor
• Approving a rate above the standing ceiling
• Blocking dates from pricing tool control
• Manually pricing a date that the tool has flagged

Escalation triggers:

• A booking comes in at a rate the team believes was set in error
• A tool applies a rate outside the expected range
• A competitor event or local disruption requires a rapid response
• An owner requests a change that conflicts with the standing policy

Write your own version of this list. Cross off anything that does not apply to your portfolio. Add anything that is missing. The goal is a complete inventory, not a tidy one.

Build a listing-cohort registry

A cohort is a group of listings that share the same pricing rules. Cohorts exist because managing floors, ceilings, and approval thresholds at the individual listing level becomes unworkable once a portfolio grows beyond a small number of properties. Cohorts let you govern a rule once and apply it to a group.

Your cohort structure should reflect the actual pricing logic of your portfolio, not an administrative convenience. Listings belong in the same cohort if they share the same market, the same demand drivers, and the same acceptable rate range. A beachfront property and a city-centre apartment in the same portfolio are almost certainly different cohorts, even if they are priced similarly today.

How to define your cohorts:

1. List every active listing by name or ID
2. For each listing, record: market (city or region), property type, typical demand pattern (leisure, business, mixed), and current floor and ceiling
3. Group listings where all four attributes are similar enough that a single floor and ceiling policy makes sense for all of them
4. Name each cohort with a label that is descriptive and stable (not "Group A")

Listing-cohort registry fields to record:

• Listing ID: your internal identifier or Airbnb listing number
• Listing name: human-readable name
• Cohort name: the cohort this listing belongs to
• Market: city, region, or submarket
• Property type: apartment, house, cabin, etc.
• Demand pattern: leisure, business, mixed, or seasonal
• Standing floor: current minimum nightly rate for this listing
• Standing ceiling: current maximum nightly rate for this listing
• Floor authority: who holds Level 3 authority for this listing
• Override authority: who holds Level 4 authority for this listing
• Last reviewed: date the floor and ceiling were last confirmed

Keep this registry in a shared document that every team member with Level 2 authority or above can read. Update it every time a floor or ceiling changes. If your registry is out of date, your RACI is operating on false information.

A decision rule for cohort assignment: if you would set a different floor for two listings in response to the same market event, they belong in different cohorts. If you would set the same floor, they can share a cohort.

Fill the portfolio pricing RACI

With your decision inventory and your cohort registry in place, you can now build the RACI itself. The table below covers the core decision types from the inventory section and assigns RACI codes to four roles. Adapt the roles to match your actual team structure.

Role definitions for this template:

• Owner: The property owner or the person with final financial authority
• Rate Manager: The person responsible for day-to-day pricing execution
• Co-host / VA: The person handling operational tasks including listing updates
• Revande Strategist: An external rate strategist if you are using a managed service

RACI codes: R = Responsible (does the work), A = Accountable (owns the outcome), C = Consulted (input required before action), I = Informed (notified after action)

How to read this table:

Every row must have exactly one A. If a row has no A, nobody owns the outcome and the decision will be made inconsistently. If a row has two As, you have a conflict that will surface at the worst possible time. Check your completed RACI for both conditions before you use it.

Every row must have at least one R. The R and the A can be the same person, as shown in several rows above. When they are the same person, that person both does the work and owns the result.

C means the person must be consulted before the action is taken, not after. If you find yourself informing someone you marked as C, you have either mislabelled them or you are not following the RACI.

Checklist for a complete RACI:

• Every decision type from your inventory appears in the table
• Every row has exactly one A
• Every row has at least one R
• No person is marked both C and I on the same row (pick one)
• The table has been reviewed by every person named in it
• Each person has confirmed they understand and accept their assignments

Add the approval and escalation record

The RACI table tells you who owns each decision type. The approval and escalation record tells you what happens when a decision requires sign-off or when the normal process breaks down. These are two separate documents, but they live together.

Approval record fields:

For any decision type marked A by someone other than the Rate Manager, you need a written approval process. Record the following for each:

• Decision type requiring approval
• Who must approve (name and role)
• How approval is requested (email, shared document, messaging channel)
• Maximum response time before escalation
• What happens if approval is not received within that time

A practical example: if overriding a rate below the standing floor requires owner approval, the record should state that the Rate Manager sends a written request with the proposed rate, the reason, and the affected dates. The owner has a defined window to respond. If no response is received, the Rate Manager either holds the rate at the floor or escalates to a named backup approver.

Escalation record fields:

An escalation is a situation that falls outside the normal decision tree. Record the following for each escalation type:

• Trigger condition (what makes this an escalation)
• First escalation contact (name and role)
• Second escalation contact if first is unavailable
• Decision authority during escalation (who can act without the normal approval chain)
• Documentation required after escalation resolves

Common escalation triggers to document:

• A booking arrives at a rate that appears to have been set in error
• A dynamic pricing tool applies a rate outside the expected range for a cohort
• A local event or disruption creates demand conditions that the standing floors and ceilings do not account for
• An owner requests a change that conflicts with a standing policy
• A team member with approval authority is unreachable for more than the defined response window

Write the escalation record as a series of "if this, then that" statements. Ambiguity in an escalation record defeats its purpose. The person handling the escalation should be able to read the record and know exactly what to do without making a judgment call about process.

See how one hypothetical row works

Take the row: "Override rate below standing floor."

The RACI assigns A to the Owner, C to the Rate Manager, and R to the Revande Strategist. Here is how that plays out in practice.

A local event is announced with a short lead time. The Rate Manager reviews the cohort and believes the standing floor is too high to capture bookings before competitors fill the demand. The Rate Manager wants to price two listings in the cohort below the floor for a four-night window.

Because the RACI assigns A to the Owner for this decision type, the Rate Manager cannot execute the change unilaterally. The Rate Manager is marked C, meaning their input is required before the action is taken, but they are not the one who takes it.

The process:

1. The Rate Manager documents the proposed change: which listings, which dates, the proposed rate, and the reasoning.
2. The Rate Manager sends the request to the Owner using the channel defined in the approval record.
3. The Owner reviews and approves or declines within the defined response window.
4. If approved, the Revande Strategist (R) executes the change and records it in the approval log.
5. The Owner is the A and therefore owns the outcome, whether the change performs well or not.
6. If the Owner does not respond within the defined window, the escalation record defines what happens next.

This sequence sounds slow when written out. In practice, a well-maintained approval record with a clear response window and a defined escalation path means the decision is made and executed faster than it would be in a team where everyone assumes someone else is handling it. The delay in unstructured teams is not the approval step. It is the time spent figuring out who should be approving.

Decision rule for this row: If the proposed rate is within the standing floor and ceiling, the Rate Manager acts without approval. If it is outside either boundary, the approval record governs. There is no gray area, because the floor and ceiling are written down in the cohort registry.

Review on change, not on an invented schedule

A common mistake in governance documentation is to attach a review schedule to it: "review quarterly," "review annually." That schedule is invented. It has no relationship to when the document actually needs to change.

A pricing RACI needs to be reviewed when something changes that affects who owns a decision or how a decision is made. Reviewing it on a fixed calendar when nothing has changed wastes time and trains your team to treat the document as a formality. Reviewing it only when a conflict has already occurred means you are always reacting.

Triggers that should prompt a RACI review:

• A new person joins the team in a role that touches pricing
• A person leaves the team or changes roles
• You add a new listing or cohort to the portfolio
• You change your pricing tool or channel manager
• You change your pricing strategy (new seasonal model, new discount policy)
• A floor or ceiling is changed for a cohort
• An escalation occurs that the current record did not handle well
• An owner's availability or preferences change in a way that affects approval timelines

Review process checklist:

• Identify which rows in the RACI are affected by the change
• Confirm that the A and R assignments still reflect the actual team structure
• Update the approval record if response windows or contacts have changed
• Update the escalation record if contacts or authority levels have changed
• Update the cohort registry if floors, ceilings, or cohort membership have changed
• Share the updated documents with everyone named in the RACI
• Record the date of the review and the reason for it

A practical way to enforce change-triggered reviews: add a line to your onboarding checklist for new team members that requires them to read the RACI before they make any pricing change. Add a line to your offboarding checklist that requires the RACI to be reviewed before the departing person's access is removed. These two checkpoints catch most of the situations where the document would otherwise drift out of date.

The goal is a RACI that reflects how decisions are actually made, not how they were made when the document was first written. A document that nobody trusts is worse than no document, because it creates the illusion of governance without the substance.

References

The RACI model is a general project management framework. The application here is specific to short-term rental pricing governance and is not derived from any single external source. The decision types, cohort registry fields, and escalation record structure in this guide are based on the operational patterns common to multi-listing Airbnb portfolios.

If you are building this for the first time, the most useful reference material is your own records. Pull your last three months of pricing changes, identify who made each one, and check whether the outcome was what the owner expected. The gaps between what happened and what the owner expected are the rows your RACI most needs to cover.

Airbnb's host resources cover listing management and policies but do not address multi-listing pricing governance in the form described here. Your channel manager's documentation will describe what actions are available through their interface and what permissions their user roles support. Map those permissions to your RACI authority levels when you set up user accounts.

Where this becomes someone else's job

Building and maintaining a pricing RACI is governance work. Executing the daily pricing decisions that the RACI governs is a separate and ongoing operational task. At a certain portfolio size, or when the Rate Manager role is not a full-time position, the execution layer becomes difficult to staff well.

Revande offers two products that take on parts of this work.

Performance provides 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. If your RACI assigns R for day-to-day rate adjustments to a role that is currently understaffed or inconsistently filled, Performance covers that execution layer.

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, works with Airbnb or your channel manager, and ongoing listing refinements. If your RACI has gaps not just in rate execution but in the listing management decisions that affect how your pricing performs, Maestro covers both layers.

In either case, the RACI you build using this guide remains yours. It defines who owns the floors, the ceilings, the approvals, and the escalations. What changes is who holds the R on daily execution.