Pet Boarding Software: Can AI Forecast Holiday Demand and Staffing?

Coding Liquids tutorial cover featuring Sagnik Bhattacharya for Pet Boarding Software: Can AI Forecast Holiday Demand and Staffing?
Coding Liquids tutorial cover featuring Sagnik Bhattacharya for Pet Boarding Software: Can AI Forecast Holiday Demand and Staffing?

Yes, for the shape and size of the rush, if you can export three years of bookings with check-in, check-out and booking-created dates. AI turns them into a night-by-night occupancy table, a booking-pace comparison and a staffing sum, then gives a range, not a promise. You still supply the calendar knowledge.

Two things catch most owners out. Boarding software mostly reports what already happened, so the forecast is something you build from its export. And a sold-out holiday hides real demand, because the people you turned away never appear in a booking report. Both are fixable with a spreadsheet, a chat assistant and about three hours.

Follow me on Instagram@sagnikteaches

What your boarding software can export, and what it cannot tell you

Boarding software holds the raw material: every stay with its dates, run, status and price. What it rarely holds is a forecast you can inspect. As of October 2026, Gingr's pricing page lists business analytics on every plan and a live occupancy grid on its boarding plan (Stay: $154 a month billed annually or $179 billed monthly, both with its integrated payments active, and $179 or $209 without them), but it does not describe a forecast report or a booking export. Goose's site talks about pricing from "projected demand and real-time signals" without saying how the projection is built, so you cannot check it. For plans and prices side by side, see the dog boarding software comparison and the Gingr and MoeGo cost comparison. Here the only question is whether you can get a plain spreadsheet out.

Connect on LinkedInSagnik Bhattacharya

Ask your vendor for a CSV (a plain spreadsheet file) of every booking from the last three years, with these columns:

Subscribe on YouTube@sagnikteaches
ColumnWhy the forecast needs it
Check-in date and check-out dateBuilds the night-by-night count of dogs in the building
Booking-created dateShows how early each booking arrived, which is the booking pace
Status and cancellation dateSeparates stays that happened from bookings that dropped out, and shows when they dropped out
Run type and number of petsKeeps small and large runs apart if they sell at different speeds
Waitlist entries: date, nights wanted, outcomeReveals demand you could not serve
Deposit paid: yes or no, and whenExplains a change in pace when your deposit rules changed

Two questions are worth asking in the same email. Does the software keep the original check-out date when a stay is extended, or overwrite it? An overwrite quietly inflates what looks like early demand in past years. And does it record the date each booking was created? Without it you can still count nights, but you cannot compare pace.

Strip owner names, phone numbers, email addresses and pet names before you upload anything, and keep the booking number instead. On a personal ChatGPT or Claude plan, switch off the model-training setting in privacy settings first; business plans do not train on your content by default. OpenAI's help text gives ChatGPT's free plan three file uploads a day, so a paid plan at about $20 a month list price is more comfortable, and Claude reads both CSV and XLSX files.

Step 1: turn bookings into a night-by-night count

The forecast starts from one row per night for three years: the date, dogs in the building, arrivals and departures. A night counts when the dog checks in on or before it and checks out after it, and only for stays that took place. Ask the AI for the table and for the formulas behind it, so that you can read them.

I run a 40-run dog boarding business. The attached CSV has one row per booking:
booking_id, created_date, check_in, check_out, status, cancelled_date, run_type.
Dates are in day/month/year order.

Build a table with one row per night from 1 Jan 2023 to 31 Dec 2025 showing:
- dogs in the building that night (check_in on or before the night, check_out after it, status Completed)
- arrivals that day
- departures that day

Before you start, tell me how many rows have a check_out earlier than check_in
and how many have no status. Show the first 10 rows and the total per year
so I can check them. Use ordinary spreadsheet formulas, not an AI function.

Insist on ordinary formulas. A typical one is =COUNTIFS(Bookings!C:C,"<="&A2,Bookings!D:D,">"&A2,Bookings!E:E,"Completed"), which counts bookings checking in on or before the date in A2, checking out after it, and marked Completed. A formula you can read keeps working whatever happens to your AI plan, and Excel's own COPILOT() worksheet function was retired in September 2026, so a sheet that leans on it will not recalculate.

Then check three nights by hand: a quiet one, a busy one and a changeover day. Count the dogs from your diary and compare. If the AI says 38 dogs on 14 August and your diary says 36, ask it to list the bookings behind its 38. The usual culprits are cancelled bookings still counted, and dates read the wrong way round when a CSV is opened directly in Excel. A stay that appears to end before it starts is the giveaway. Import the date columns as text and convert them afterwards, because Excel cannot repair a date it has already misread.

Step 2: line up the holidays that move

A forecast compares like with like, and holiday dates drift. Christmas and New Year stay put, but Easter moves by weeks, school breaks follow each school's published calendar, and public-holiday weekends shift between years. Compare each holiday on its own window, not on calendar dates. A small table keeps the AI honest:

Window2023202420252026
Easter Sunday9 Apr31 Mar20 Apr5 Apr
Compare window: Good Friday to the Tuesday after7 to 11 Apr29 Mar to 2 Apr18 to 22 Apr3 to 7 Apr
Year-end window: ten nights from 23 Dec23 Dec to 1 Jan23 Dec to 1 Jan23 Dec to 1 Jan23 Dec to 1 Jan

Let the AI draft the table, then check every moving date against a printed calendar and your local school calendar; AI tools can miscalculate moving dates. Add a column for one-offs: a storm closure, a week of building work, a festival nearby, a month when you added or removed runs. A past year with a one-off needs a note, or the forecast will treat it as normal.

Step 3: compare booking pace, not just last year's total

Last year's total tells you where the season ended. Booking pace tells you where this year is heading while there is still time to act. Pace means: how many pet-nights for the window were already on the books the same number of days before it opened. A pet-night is one dog for one night, so a five-night stay is five.

Take a 40-run business and its ten-night year-end window. Capacity is 40 runs times 10 nights, or 400 pet-nights. These figures are illustrative, but the columns are exactly what your sheet should hold, counted 60 days before the first night (23 December, so around 24 October):

YearOn the books at 60 daysFinal bookedTurned awayTotal wantedShare on the books at 60 days
2023171352035249%
20241923682138949%
20252143863742351%
2026241to cometo comeforecastto come

This year is 12.6% ahead of last year at the same point (241 divided by 214 is 1.126). Three ways of turning that into a forecast, each with its arithmetic visible, give a range:

  • Growth ratio. Last year's total wanted, 423, times 1.126 gives 476 pet-nights.
  • Ratio trimmed by last year's overshoot. In 2025, on-the-books growth at 60 days was 11.5% (214 over 192) but total wanted grew only 8.7% (423 over 389), so early pace overstated growth by 2.7 points. Trim this year's 12.6% to 9.9% and the forecast becomes 423 times 1.099, or 465.
  • Pace share. If about half of demand is on the books by day 60, as in 2025 (50.6%), then 241 divided by 0.506 gives 476. If the share keeps creeping up, as it has each year, 241 divided by 0.515 gives 468.

The defensible answer is a range: about 465 to 476 pet-nights wanted against 400 available, which is 116% to 119% of capacity. That is the number worth acting on. You will sell out, so the useful questions become how early, which nights go first, and what your rules are when the phone keeps ringing.

The prompt that gets you there is short, because the table already exists:

Using the night-by-night table and the booking CSV, for the window 23 Dec to 1 Jan
in each year, give me:
1) pet-nights on the books 60, 45, 30 and 14 days before 23 Dec
   (bookings created on or before that day and not cancelled on or before it)
2) final pet-nights completed, and pet-nights wanted on the waitlist sheet
3) the share of final demand on the books at each lead time

For 2026 I have 241 pet-nights on the books at 60 days. Give me three forecasts
of total demand (growth ratio, ratio trimmed by last year's overshoot, pace share)
with every step of the arithmetic shown. Do not round until the final answer.

Expect the method to come back right and check the numbers, because the pace table is where mistakes hide. A first reply might look like this (illustrative, abridged):

Window 23 Dec to 1 Jan   on books at 60 days   final completed   waitlist nights
2023                     171                    352               0
2024                     192                    368               21
2025                     224                    386               37
Forecast 2026: 241 / 224 = 1.076, so total wanted is about 455 (growth ratio)

Can you spot the problem? A hand count of the 2025 bookings created before 24 October gives 214, not 224. The AI measured stays by their final check-out dates, so ten pet-nights from extensions added after day 60 slipped in. Ask it to use the original dates where your export keeps them, and to list the 2025 stays that were extended. The row returns to 214 and the growth ratio moves from 1.076 to 1.126. A ten-night slip changed the forecast by about 20 pet-nights, which is why the hand check matters. Bookings that were later cancelled but still active on that day belong in the count, because they really were on the books then.

Why a sold-out holiday hides real demand

The 2025 row above has 386 pet-nights booked but 423 wanted. The 37 difference is the waitlist and the "sorry, we are full" replies, and it sits mostly on six full nights: 23, 24, 25, 26, 30 and 31 December. A booking report would show 386 and tell you demand topped out at 96.5% of capacity. In truth six nights were over-demanded, and a forecast built on bookings alone would have you staffing and pricing for a season smaller than the one that happened.

Put the turned-away demand into the sheet by hand. For past years, search your inbox and message history for the replies that said you were full, note the date and nights wanted, and add them to a second tab. A few minutes with an AI helps here: paste anonymised enquiry subjects and dates, and ask it to list every request that mentions the window and was declined. Going forward, make the log part of the waitlist form, with three fields: date, nights wanted and outcome.

From pet-nights to staff hours

Capacity caps what you serve, so staffing follows the capped number: full house on the nights the forecast says are over-subscribed, and the forecast figure on the rest. For the example above, 8 or 9 of the 10 nights come out at 40 dogs, and the other one or two at 38 or 39. What varies is the handover work, because arrivals and departures take staff time that a headcount ignores.

Two methods are worth using together. The quick one is a ratio. Gingr's guide to structuring playgroups advises one staff member for every 10 to 15 dogs in supervised group play, and licence conditions or your insurer may be stricter, so check yours. At 40 dogs that is three or four attendants in the play yards at once. The better one counts minutes. Time one ordinary week: have each member of staff note how long feeding, outdoor breaks, cleaning, medication, enrichment and owner updates take, then divide by dogs. The figures below are assumptions for illustration; replace them with your own:

AssumptionValue used here
Care minutes per dog per day (feeding, breaks, cleaning, medication, enrichment, updates)45
Minutes per arrival or departure15
Fixed daily tasks (laundry, dishes, opening and closing, phones)3 hours
Productive hours in an 8-hour shift7
Day typeDogsArrivals plus departuresCare hoursHandover hoursTotal hours with fixed tasksStaff needed
Steady full house40430.01.034.04.9, so 5
Changeover day402030.05.038.05.4, so 6
Heavy departure day401630.04.037.05.3, so 6
Shoulder day outside the window31623.31.527.84.0, so 4

The result is more useful than a single average. The yards need three or four people, but the changeover days need a sixth because of the handovers, and a rota built on dogs alone would be one person short on exactly the days owners are queuing at the door. Because the sheet already holds arrivals and departures per day from Step 1, ask the AI to apply the four assumptions to every night of the window and list the nights where your drafted rota has fewer staff than the sum says. The model covers daytime only: your licence conditions and insurer may set a minimum for overnight cover, and the AI cannot know that.

The forecast also tells you when to act on staffing, which matters more than the exact count. If the range says a sell-out, block staff leave for the window at least 90 days out, ask part-timers for extra shifts at 60, and decide at 45 whether you need temporary cover. For shift planning basics, see AI shift scheduling versus a rota spreadsheet for small teams.

Waitlist rules to write before the first cancellation

When demand runs at 116% to 119% of capacity, the waitlist becomes part of the product. Decide the rules now, in writing, so that nobody invents them at the door on 22 December. A workable set for the 40-run example:

  • Open the list when any night in the window reaches 38 of 40 runs booked.
  • Order: by the date and time the request arrived, with no exceptions for favourites unless you state a rule, for example regulars with three stays in twelve months get a four-hour head start. Whichever you choose, put it on the form.
  • Offers: a cancelled run is offered to the first waitlisted person whose full stay fits, by text, with a four-hour hold. After that it goes to the next person.
  • Partial stays: offer them only if the customer ticked "partial dates are fine" when joining.
  • Confirmation: a space is theirs once the deposit is paid, not once they reply yes.
  • Hold-back: keep 2 of the 40 runs free until seven days before the window for stays that owners extend. Release them to the list at that point.
  • Cap: stop adding names when the list is about twice the cancellations you expect. If about 8% of booked pet-nights cancel in a typical year (roughly 31 in the example), a list much beyond 60 pet-nights is giving people false hope.

Your own history sets the numbers. In the example year, nine waitlist requests came in and four turned into stays after cancellations, a conversion of 44%. Check what yours is, because it tells you how many names to take for each cancellation you expect. A text that follows these rules and fits one message:

[first name], a run is free at [business] for [dates]. Pay the deposit within
4 hours to keep it: [link]. Reply STOP to leave the list.

Plain text keeps costs predictable. On most SMS services a plain-text message of up to 160 characters is one segment, longer ones are split and billed per segment, and a single emoji or curly quote cuts the limit to 70 characters. For the matching refund and deposit wording, see peak-season cancellation wording for dog boarding.

The AI's job here is drafting and checking: ask it to turn your rules into a one-page policy for the booking form, then to play awkward customers against it. "I was told I was next on the list." "I only need three of those five nights." "The deposit page failed." Each answer either follows your policy or shows you a gap.

Back-test it on last year before you trust it

Forecast 2025 as if it were 24 October 2025, using only 2023 and 2024. On-the-books growth at day 60 from 2024 to 2025 was 11.5% (192 to 214), and the previous year's early pace had overshot final growth by 1.8 points (12.3% against 10.5%). Trim 11.5% to 9.7%, apply it to 2024's total wanted of 389, and the forecast is 427 pet-nights. The real figure was 423, an error of under 1%. Without the trim the forecast would have been 434, still within 3%.

Set the standard before you look: an error inside 5% of total wanted is about 20 pet-nights, or two dogs a night across the window, which a rota can absorb. If the back-test misses by more, look for the reason before you blame the method. Usually a rule changed that year: deposits were introduced, bookings opened earlier, runs were added, or one customer booked a block for twelve dogs. Note it in the one-offs column.

Six ways a booking forecast goes wrong

  1. Cancelled bookings counted as stays. Symptom: occupancy above 100% on some nights. Fix: filter on status and test a night you know.
  2. A moving holiday treated as fixed. Symptom: a spring forecast that is 30% out. Fix: build the window table in Step 2 and check the dates by hand.
  3. Overwritten check-out dates. Symptom: early pace in past years looks stronger than your memory says. Fix: ask the vendor whether extensions overwrite, and if they do, treat past pace as slightly flattered.
  4. Averages that hide the peak. Symptom: the AI says "average occupancy 84%" while six nights were full. Fix: ask for the nightly table, not a summary, and read the peak nights first.
  5. A policy change mistaken for demand. Symptom: pace jumps the year you started taking deposits at booking. Fix: write the change in the one-offs column and discount that year's pace.
  6. Confident prose over thin data. Symptom: a paragraph about "strong growth" with no sums. Fix: require every forecast to show the three-line arithmetic from Step 3, and rerun any figure you cannot reproduce on a calculator.

For wider reasons stock and demand forecasts fail, why AI stock forecasts go wrong covers the general patterns, and a simple seasonal forecast from sales history shows the same idea on retail data if you want a second worked example.

A decision calendar for each holiday window

A forecast matters only when it changes what you do on a particular date. Here is the schedule I would run for the year-end window, with a short list of what each run of the sheet should settle:

Days before the windowRerun the sheet and decide
120Open bookings for the window if they are not open. Block staff leave. Decide whether deposits are due at booking.
90First pace comparison. If this year is ahead of last, set a minimum stay for the peak nights and tell regulars before the public.
60Full three-method forecast. Offer extra shifts. Decide the waitlist rules and publish them on the form.
45Draft the rota from the day-type sums. Decide whether you need temporary cover for the changeover days.
30Check which nights have sold out and open the waitlist for any night at 38 of 40 (earlier if that happens earlier). Tell staff which changeover days need the sixth person.
14Final rota. Order food and supplies from the confirmed headcount. Chase missing vaccination records.
7Release the 2 hold-back runs. Confirm deposits on the waitlist offers made so far.

Start with the export request, because it is the only step that depends on someone else. Once the CSV arrives, Steps 1 to 3 take an afternoon, the staffing table another hour, and the whole thing then refreshes in twenty minutes each time. If the first forecast changes one decision, such as blocking leave a month earlier than last year, the afternoon has paid for itself.

Questions owners ask before building the forecast

How many years of bookings do I need?

Three works best, because the third year lets you measure how far early booking pace overstated final growth in the year before. Two years works with a wider range. One year gives you the shape of a season but no way to test the method. With less than a year, use the sheet to sanity-check last year's rota and start logging every turned-away enquiry today.

Should I overbook to cover cancellations?

I would not overbook living spaces. A waitlist with fast offers fills most cancelled runs, and a small hold-back of runs covers owners who extend a stay. Overbooking risks a dog without a bed on the busiest night of the year. If you ever consider it, set the limit from your own cancellation history and check your licence conditions and insurer first.

Does my boarding software forecast this itself?

Some products claim demand-based pricing, and Gingr lists analytics and an occupancy grid, but none of the pages I checked described a forecast report you could inspect. Ask for a demonstration on your own data, and keep your own export so you can test anything the software shows you against numbers you can see.

How often should I re-run the forecast?

At 90, 60, 30 and 14 days before each holiday window. Once the sheet exists that takes about twenty minutes. Each run adds a row to your pace table, so you can see whether this year is running ahead of or behind last year, and you change rota offers and waitlist rules while there is still time.

Further reads

Sources: Gingr pricing page and its guide to structuring playgroups, and the Goose product page, checked October 2026; OpenAI and Anthropic help and plan pages for file uploads and list prices. Time and ratio figures in the examples are illustrative assumptions.

Want your holiday forecast built from your own bookings?

On a 1:1 call we can look at what your boarding software exports, build the first night-by-night table together, and decide which staffing and waitlist rules are worth setting before the next peak.

Book a 1:1 call with me