Revenue-operations system for pet hotels

Most pet hotels don't actually have a revenue problem. They have a coordination problem that looks like a revenue problem.

The owner tweaks pricing in the spring. Marketing starts pushing a new channel in the summer. Someone launches a "frequent stayer" package in the fall. Meanwhile, the staffing plan was built back in January and nobody's touched it since. Each decision made sense on its own. Together, they create a facility that's fully booked on the worst-margin nights, understaffed during the surge the package created, and losing money on bookings that come through a channel nobody vetted for profitability.

That's the thing about pet hotel revenue operations—when it breaks, it rarely breaks loudly. It leaks. A few margin points here, a couple of blown turnaround windows there, a staffing scramble that burns out your best kennel tech. By the time it shows up in the P&L, it's hard to trace back to any single cause.

This article is about building the connective tissue: a RevOps system where pricing changes, package rules, channel priorities, and experiments all answer to the same operational reality—your throughput and your staffing capacity.

Why revenue decisions drift apart at pet hotels

In most facilities, four different functions touch revenue, and they almost never talk to each other on the same cadence.

Pricing lives with the owner or GM. Packaging gets invented when someone reads a competitor's website. Channel mix is whatever the booking software and a couple of marketplaces happen to send you. Staffing is built around a headcount budget, not around the demand those first three decisions are generating.

The drift isn't laziness—it's structural. Each function has its own feedback loop and its own timeline. Pricing feedback shows up in weeks. A new package might take a full peak season to prove itself. Channel performance is buried in platform dashboards that don't talk to your occupancy data. And staffing adjustments are slow because you're dealing with real humans, schedules, and training time.

So you end up with four clocks running at four speeds. Revenue operations is the discipline of putting them on one clock—where every pricing or packaging move gets evaluated against the staffing and throughput it requires, before it goes live.

A concrete example: a facility adds a discounted midweek boarding package to fill soft Tuesday–Wednesday nights. Good instinct. But midweek is also when they run reduced staffing and schedule deep-clean rotations. The package works—bookings climb—and now they're short-handed exactly when they planned to be. Cleaning falls behind. The next weekend's turnaround suffers. The pricing decision was fine. The coordination was missing.

The core idea: every revenue lever has an operational cost

The foundation of a working RevOps system is accepting that a booking is not free money. Each one consumes kennel capacity, staff minutes, and cleaning throughput. A revenue decision that ignores those costs isn't really a revenue decision—it's a bet that nobody's tracking.

Before getting into templates, here's the mental model that holds the whole thing together:

Every row in that table should trigger a staffing and throughput check. Not a vague "can we handle it?"—an actual number. If a pricing change is projected to lift Friday occupancy by 15%, someone needs to confirm you have the kennel-tech hours and cleaning capacity to absorb it before the price goes live.

This is also why pricing and packaging can't be treated as marketing exercises. They're capacity-allocation decisions. The pricing, packaging and utilization work you do only pays off if it's tied back to what the floor can actually deliver.

Pricing-change runways: stop launching cold

The single most common mistake is pricing changes that go live with no runway. Someone decides rates are too low, bumps them 12%, and flips the switch on a Monday. Then they spend the next three weeks reacting to whatever happens.

A runway is just a structured window around a pricing change where you watch leading indicators and have pre-agreed actions ready. It turns a guess into a controlled rollout.

1. 1
   T-minus 3 weeks — Baseline capture. Lock your current numbers

   occupancy by day-of-week, average booking lead time, cancellation rate, revenue per occupied kennel, and current staffing hours per occupied night. You can't measure a change without this.

2. 2
   T-minus 2 weeks — Capacity check. Model the expected demand shift. If the change is meant to raise revenue per night, confirm you're not also pushing volume into already-tight periods. If it's meant to fill valleys, confirm you can staff those valleys.
3. 3
   T-minus 1 week — Grandfather and comms rules. Decide how existing bookings and repeat clients are handled. Nothing torches loyalty faster than a surprise rate hike on a client who booked six weeks out.
4. 4
   Launch week — Daily leading-indicator watch. Track booking pace and lead time daily, not weekly. A pricing change that kills your booking velocity shows up in days, not in the monthly report.
5. 5
   T-plus 2 weeks — Decision gate. Hold, roll back, or extend. This is a pre-scheduled meeting with pre-agreed thresholds, not a "let's see how it feels" conversation.

The decision gate matters most. Without a pre-committed threshold—say, "if booking pace drops more than 20% against baseline, we partially roll back"—you'll rationalize whatever happened. Runways force you to set the rules before you're emotionally invested in the outcome.

When a pricing runway is overkill

If you're adjusting a single add-on by a couple dollars, you don't need a three-week runway. Reserve the full process for anything that touches core per-night rates, affects more than one site, or changes the price of your highest-volume service. A small daycare drop-in fee tweak doesn't need a decision gate. Your peak-season boarding rate absolutely does.

Package-gating rules: protect throughput from your own menu

Packages are where good revenue intentions quietly destroy operations. The problem isn't bundles themselves—it's that most packages are designed around price appeal and never gated against capacity.

A package-gating rule is a condition that controls when and how much of a package can be sold based on operational load. Think of it as a valve, not a wall.

Some gating rules worth building in:

1. 1
   Capacity gates

   "Bundle X unlocks only when projected occupancy is below 80% for the target dates." This fills valleys without feeding peaks you can't staff.

2. 2
   Add-on throughput gates

   If a package includes grooming or extended enrichment, cap daily package sales at real service capacity—not the booking system's theoretical capacity.

3. 3
   Lead-time gates

   Require certain packages to be booked a minimum number of days out, so the labor they require can actually be scheduled.

4. 4
   Blackout gates

   Automatically disable discount-heavy packages on known high-demand dates.

The reason gating matters so much at scale is that a package sold without limits becomes a promise your floor has to keep. Facilities sell a "spa + boarding" bundle enthusiastically in November, then realize in December they've committed to more grooming slots than they have groomer-hours in the building. The revenue looked great on the booking screen and terrible on the schedule.

Designing bundles that hold up under real load is its own discipline—the service-design approach to packages that protect throughput goes deeper on building tiers that scale instead of buckling.

Channel-priority decision gates

Not all bookings cost the same to acquire or serve. A direct repeat client who books six weeks out is operationally cheap and predictable. A last-minute marketplace booking with a high cancellation rate is expensive in ways that never show up as a line item—blocked inventory, scramble staffing, support overhead.

A channel-priority decision gate is a rule that decides which channels get priority access to your inventory based on their true cost and reliability, not just their volume.

The way to build these gates is to score each channel on more than revenue. Lead time, cancellation and no-show rate, support load per booking, and repeat conversion all belong in the calculation. A channel that brings volume but cancels 30% of the time is quietly eating your capacity planning alive.

A practical gate structure:

1. 1
   Tier 1 channels (direct, repeat, high-reliability)

   full inventory access, earliest release.

2. 2
   Tier 2 channels (vetted partners, moderate reliability)

   access to a capped share of inventory.

3. 3
   Tier 3 channels (low-margin or high-cancellation)

   access only when occupancy is soft, and often with a deposit requirement to offset cancellation risk.

The gate is the rule that shifts inventory between tiers automatically as your occupancy forecast changes. On a soft week, open the gates wider. During a projected peak, tighten them and protect capacity for your most reliable sources.

Getting the scoring right is foundational—the channel scoring and demand-calendar framework lays out how to rank channels and align them to a demand calendar so these gates have real data behind them.

Who should not over-engineer channel gates

If you're a single site getting 80% or more of your bookings direct, elaborate channel tiers are a waste of time. Track your two or three real sources and protect peak inventory for repeat clients. Channel-priority systems earn their complexity once you're running multiple sites or depending heavily on third-party marketplaces.

Mapping experiments to staffing and throughput KPIs

This is where RevOps becomes a real system instead of a collection of good ideas. Every revenue experiment—a new price, a new package, a new channel push—should be tied to specific operational KPIs before it launches. Otherwise you're measuring success by revenue alone, which is how facilities end up "winning" their way into burnout.

The KPIs that should gate every experiment:

1. 1
   Hours per occupied night — did the experiment increase the labor cost of serving each booking?
2. 2
   Turnaround throughput — can cleaning keep pace with the occupancy the experiment creates?
3. 3
   Overtime rate — is the extra revenue being eaten by overtime you didn't plan for?
4. 4
   Occupancy balance — did it smooth demand or just pile more onto peaks?

An experiment that improves revenue while quietly degrading any of these KPIs is not a win. It's a loan you're taking against your staff and your facility.

A workflow for running experiments this way:

Start by defining the one revenue metric you're trying to move. Then define the two or three operational KPIs that could get hurt. Set a floor on each—"turnaround must stay under X minutes," "overtime must not exceed Y hours." Run the experiment on a limited scope: one site, or a limited date range. Review at a fixed gate. If revenue improved and no operational floor was breached, scale it. If an operational floor broke, you've learned the experiment needs process changes before it rolls out wider—not that it failed entirely.

That last point is the one people miss. A broken throughput KPI doesn't always mean kill the experiment. Sometimes it means this works, but it needs 15 more cleaning minutes per turnover, and you need to staff for that first.

“

Run experiments on a single site or limited date range to limit operational disruption.

The diagram below shows the experiment workflow and where staffing and throughput KPIs fit into the gates.

That workflow makes it clear which team needs to sign off at each gate and which KPI can't be ignored when the revenue metric moves.

Rollout cadence: single-site vs. multi-site

Cadence is where single-site and multi-site operations genuinely diverge.

For a single site, the rhythm can be tight and informal. Weekly review of booking pace and the core operational KPIs. Monthly pricing and package review. Experiments run and gated within a month or two. Decisions can be made and reversed fast because there's one floor, one team, one set of numbers.

For multi-site, cadence becomes the whole game. You can't roll a pricing change or a new package to five sites simultaneously and hope—because each site has different demand patterns, staffing depth, and channel mix. The pattern that works:

1. 1
   Pilot at one representative site with the full runway and KPI gates.
2. 2
   Review against both revenue and operational floors at a fixed gate.
3. 3
   Adjust the playbook based on what broke at the pilot.
4. 4
   Stagger the rollout to remaining sites, two or three at a time, each with its own local capacity check.
5. 5
   Standardize what worked into the shared operating playbook so the next experiment starts from a better baseline.

The multi-site mistake that keeps coming up: a change that worked beautifully at the flagship location gets pushed everywhere at once, then blows up at the two sites that were already running tight on staffing. Staggered cadence with per-site capacity checks prevents that.

A real scenario

A two-site pet hotel—roughly 60 kennels across both locations—was running a classic drifted system. Pricing hadn't changed in over a year, they leaned heavily on two booking marketplaces, and they'd launched a "stay 5, get 1 free" package that was popular but completely ungated.

The symptoms: weekends were slammed and losing money on marketplace bookings after fees, midweek sat half-empty, and their best kennel tech at the smaller site had quit citing constant weekend chaos. Monthly revenue was fine on paper—somewhere in the mid five figures per site—but margin was quietly bleeding.

They rebuilt around RevOps principles over a season. They put a runway around a modest peak-season rate increase, around 9% on weekend boarding. They gated the loyalty package so the free night could only be redeemed midweek, which pulled demand into the empty nights. They scored their channels and dropped one marketplace to Tier 3 with a deposit requirement, which cut their cancellation-driven scrambles noticeably. And they tied each change to turnaround time and overtime hours as the operational check.

The outcome wasn't a dramatic revenue explosion—it was a quality shift. Midweek occupancy climbed enough to matter, weekend overtime dropped, and the chaos that had cost them staff eased. Per-night margin improved by a few points because the worst-margin bookings got deprioritized. Nothing flashy. Just a facility that finally had its four revenue levers pulling in the same direction.

Where software fits—carefully

You can run a lot of this on spreadsheets and discipline, especially at a single site. But the coordination problem is fundamentally a data problem: pricing decisions need to see occupancy, packages need to see service capacity, channels need to see cancellation history, and experiments need to see staffing KPIs—all at once.

An AI-assisted operational platform earns its place by keeping those views connected and the gates enforced automatically. Package capacity gates that actually disable a bundle when occupancy crosses a threshold. Channel inventory that shifts tiers as the forecast changes. Experiment KPIs that flag when a throughput floor breaks instead of waiting for the monthly report. The value isn't the dashboard—it's that the system stops a well-meaning revenue decision from quietly breaking the floor before anyone notices.

The point isn't to automate judgment. It's to make sure your judgment is working from one connected picture instead of four disconnected ones.

Pulling it together

A pet hotel RevOps system isn't a pricing strategy or a packaging strategy or a channel strategy. It's the rule set that forces all of them to answer to the same operational reality—your throughput, your staffing, your real capacity.

The facilities that get this right stop treating revenue as something marketing does and operations cleans up after. They treat every pricing change, every package, every channel decision as a capacity allocation that has to clear a runway and a decision gate first. It's slower to set up. It's dramatically more stable at scale. And it's the difference between a facility that grows revenue and one that grows chaos and calls it growth.

Start with one lever. Put a runway on your next pricing change, tie it to two operational KPIs, and hold the decision gate. Once you've felt how much calmer that one decision becomes, you'll want the rest of the system.