Grooming Salon

SCRATCH — Booking Targets vs. Grooming Targets

14 min read

Booking Targets vs. Grooming Targets (working doc)

Ongoing exploration, not a finalized model. Nothing here has been folded into revenue-projections or business-goals-and-milestones yet, and it may take a while before we know where it belongs. Keeping this file around across sessions rather than deleting it — expect it to keep changing.

There are two distinct gaps between “booked” and “groomed,” operating on completely different timescales. Both matter, but they’re separate problems:

  1. Same-period leak — a slot booked for today that doesn’t turn into a finished groom today (no-shows, unfilled last-minute cancellations). Short horizon, mostly a policy/waitlist problem.
  2. Forward pipeline — how many new bookings need to be acquired each period to hit a future grooms target, once you account for existing clients rebooking on their own cadence. Long horizon, mostly a marketing/admin-capacity problem. This is the part we’ve actually started modeling (see Part 2) — it’s the one that determines staffing/workload for booking and client acquisition.

Part 1 — Same-period leak (booked today ≠ groomed today)

Every target we’ve set so far (8/day at Day 60, 12/day at Month 6, 18/day at Year 1…) is stated as grooms completed. But the salon doesn’t directly control grooms completed — it controls appointments booked. Those two numbers diverge because some booked slots never turn into a finished groom:

  • No-shows — per cancellation-and-no-show-policy, the client is charged the full fee, but the chair sits empty. Revenue-neutral, but it doesn’t count toward the grooms/day number, and the slot is wasted since no notice was given to backfill it.
  • 48+ hour cancellations — free rebook eventually, but today’s slot still goes empty unless the waitlist catches it same-day.
  • The gap between 48-hr and no-show — worth flagging: the current policy only defines “48+ hours” and “no-show (no contact).” There’s no defined tier for “client calls with 3 hours’ notice.” That middle case is probably the single biggest source of unrecoverable slot loss, and it’s currently undefined (this overlaps with follow-up question #1 in kendra-followup-questions.md).
  • Rebooking friction on a fully-curated book — once the schedule is mostly recurring regulars, a cancellation may not have a same-week replacement dog waiting (this is follow-up question #2).

So, informally:

Grooms/day (actual) = Bookings/day (on the calendar)
                       − no-shows
                       − cancellations not backfilled
                       + waitlist backfills

The waitlist’s entire job is to push that last term up and close the gap — booking-target math and waitlist health are really the same lever, not two separate ones.

Illustrative, not a real number: if 18/day is genuinely on the calendar but ~8% of slots leak, actual output is ~16.6/day, not 18. We have no real leak rate yet — there’s no booking history to measure it from.

Open questions:

  1. Realistic no-show / late-cancel rate for a premium, appointment-scarce salon — Kendra’s experience at All Dogs Gym and Inn might give a real anchor point.
  2. Does the undefined middle tier (cancel with some notice, but under 48 hrs) need its own policy rung?
  3. Is a “forward-booked %” (how much of next week’s capacity is already on the calendar, as of today) a better leading-indicator KPI than a raw daily booking count?

Part 2 — Forward pipeline (new bookings needed to hit a future target)

This is the piece we built out in detail and want to keep iterating on. It answers: given a grooms target for a future period, how many of those slots will already be filled by existing clients rebooking on their own, and how many new bookings have to be actively acquired to make up the rest?

The algorithm

Inputs:

  • G(t) — grooms target for week t. (Weekly is the native unit here because rebooking cadence is naturally stated in weeks; roll up to monthly for reporting against the rest of the vault’s monthly-cadence docs.)
  • r — rebook rate: probability a groomed dog books a future appointment before/at the time of their visit. Working assumption: 80%. (Real behavior is probably higher, but 80% is being used deliberately as the planning number — see rationale below.)
  • p_c — share of rebooking dogs on cadence c, for c ∈ {6, 12, 18} weeks, shares summing to 1. Working split: 25% / 50% / 25%, favoring 12 weeks as the largest bucket per Kendra’s expected norm. This is a placeholder — real breed-by-breed minimum rebooking intervals are still an open question for Kendra (related to follow-up question #4 on acceptable drift).

The recurrence:

Returning(t)  = Σ over c of  [ p_c × r × Completed(t − c) ]
New_Needed(t) = G(t) − Returning(t)
Completed(t)  = G(t)     ← as long as the target is actually being hit

Returning(t) is a convolution: for week t, look back 6, 12, and 18 weeks, take how many grooms were completed in each of those weeks, apply the rebook rate and that cadence’s share, and sum. New_Needed(t) — the actual KPI — is the target minus whatever’s already covered by returning clients.

Why this generalizes: G(t) is just an input series, not hardcoded to any particular staffing scenario. Right now we’ve only run it against the Kendra-solo target (a two-step function: 20/wk for weeks 1–4, then 40/wk). Later, the same algorithm can take the full multi-groomer trajectory from revenue-projections (converted to weekly) without changing the math — only G(t) changes.

Real constraint: the model needs 18 weeks of prior G(t)/Completed(t) history to compute Returning(t) correctly. Early weeks necessarily show 100% new because there’s no prior cohort to return yet.

Reference implementation

The recurrence above is implemented as a small, parameterized script: scratch-booking-pipeline-model.js (same folder as this note). Edit the parameters at the top (WEEKS, REBOOK_RATE, CADENCE_DIST, the target(week) function) and run node scratch-booking-pipeline-model.js to regenerate the table below — no need to redo the math by hand each time an assumption changes.

First run — Kendra solo, weeks 1–30

Using r = 0.80, cadence split 25/50/25, target = 20/wk (weeks 1–4) then 40/wk (week 5 on, holding the solo ceiling flat past Month 3 purely to isolate the solo dynamics — not a claim that a 2nd groomer isn’t hired):

WeekTargetReturningNew NeededNew as % of targetBooking hrs/wk
1–420020100%4.7
5–640040100%9.3
7–104043690%8.6
11–124083280%7.9
13–1640162460%6.4
17–1840241640%4.9
19–2240281230%4.2
23+ (steady state)4032820%3.5

(Booking-hours column explained in Part 3 below.)

What this shows:

  • Two bolus moments, not one — launch (weeks 1–4, 100% new) and the month-2 capacity jump (weeks 5–6, back to 100% new), because a higher target always arrives before any rebookings have matured to cover it.
  • The taper is lumpy, not smooth — it steps down as each cadence cohort matures (6-wk returners ~week 7, 12-wk ~week 13, 18-wk ~week 19).
  • It floors at exactly the non-rebook rate (20%) once the pipeline fully matures (8 new bookings/wk) — this isn’t a coincidence, it’s a structural property: at steady state, returning clients cover exactly r × target regardless of how the cadence buckets are split, so the new-booking floor is always (1 − r) × target. New-client acquisition never goes to zero as long as r < 100%.

Known simplifications to fix later:

  • Used 5 days/week × 4 weeks = 20 operating days for “Month 1,” vs. the 22-day/month figure used elsewhere in the vault — small mismatch against the real 88-dogs/month-1 number, not yet reconciled.
  • Assumes Completed(t) = G(t) always — i.e., assumes enough new clients are actually found to fill New_Needed(t) every week. The algorithm produces the demand for new bookings; it says nothing yet about whether that many can realistically be acquired. That capacity question is exactly why this is becoming a KPI (see Next Layer below).
  • Only modeled the Kendra-solo phase. Extending to the multi-groomer trajectory is deliberately deferred — next step, not done yet.

Why this matters as a KPI (not just a model)

New_Needed(t) is the number of new client bookings that must be actively generated — through marketing, referrals, social media outreach, cold conversion of leads — every week, on top of whatever recurring clients rebook on their own. The value of formalizing the algorithm is that any time the grooms target shifts (up or down, at any staffing level), this recomputes the required booking-acquisition rate automatically — it’s the number that tells us how much of a job “filling the calendar” actually is, separate from the number that tells us how much money comes in.

Part 3 — Booking workload (time cost, not just headcount)

New_Needed(t) and Returning(t) are counts of phone calls, not hours. Converting to a workload needed a time-per-call estimate — and new vs. returning calls take very different amounts of time, per the actual 7-step checklist in scheduling-procedures:

  • New client call — ~14 min. Full client record + full dog profile (breed, coat, temperament, vaccine record intake), breed/coat pricing lookup, groomer assignment, and payment info collection. This is the part that makes our booking calls longer than a standard salon’s.
  • Returning client rebooking — ~3 min (revised down from an initial 6-min estimate). The intent is that returning clients rebook their next visit in person, at the end of their current appointment — it’s built into the visit itself, not a separate phone call. So this isn’t really “call time” at all, it’s the incremental few minutes of checking the calendar and confirming a date/groomer while the client is already there. Kept nonzero (rather than 0) as a buffer, not because we expect a real standalone call.

Both numbers are placeholders pending real call-time data once the salon is operating — not measured yet.

Formula: BookingMinutes(t) = New_Needed(t) × 14 + Returning(t) × 3, computed automatically by the reference script alongside the rest of the table (see the BookingHrs column above).

What the numbers show:

  • Weeks 5–6 are the single worst booking-admin weeks in the whole solo phase: 9.3 hrs/week, just from new-client calls — because that’s exactly when the target jumps to 8/day with zero returning-client cushion yet. (This week’s number is unaffected by the returning-call-time revision, since Returning(t) = 0 that early.)
  • That 9.3 hrs/week lands in the same weeks Kendra is also hitting her personal grooming ceiling (8 dogs/day solo, ~40 hrs/week of chair time). Stacking a full extra workday of phone/admin work onto an already-maxed grooming week is a real risk point — dropped calls, slower callbacks, or burnout — not just a scheduling curiosity.
  • It settles to ~3.5 hrs/week once the pipeline matures (week 23+) — noticeably lighter than the ~5.1 hrs/week the 6-min estimate implied, since at steady state most of the weekly booking volume (32 of 40) is now the cheap in-visit rebooking rather than a full call.

Why this matters: this is the first concrete evidence that Kendra may need phone/booking help before the 2nd-groomer hire (currently triggered by waitlist depth, per scheduling-procedures → Waitlist Management) — the bottleneck in weeks 5–6 isn’t chair capacity, it’s Kendra’s own hours in the day to both groom and answer the phone.

Open questions for this section

  1. Confirm or adjust the 25/50/25 cadence split — currently a placeholder favoring 12 weeks per your steer, not yet validated against Kendra’s real breed-by-breed rebooking minimums.
  2. Confirm or adjust the 80% rebook-rate planning assumption — deliberately conservative vs. likely real-world behavior; worth being explicit that this is a choice, not a measurement.
  3. Reconcile the 20-operating-day vs. 22-operating-day mismatch for Month 1.
  4. Extend G(t) to the full multi-groomer trajectory once the solo case is fully settled.
  5. Validate the 14-min / 3-min call-time estimates once real bookings exist — the 3-min figure in particular assumes in-visit rebooking works smoothly in practice (no callback needed, client is ready to commit to a date on the spot).
  6. Does the weeks 5–6 admin-time spike (9.3 hrs/wk on top of a maxed grooming schedule) change the hiring-trigger conversation — e.g. part-time phone/booking help before a 2nd groomer, not instead of one?

Part 4 — 24-month trajectory (using revenue-projections.md’s monthly targets)

Scenario 1 above (Kendra solo, weeks 1–30) is left exactly as it was — this is a second, separate scenario run in the same script, not a replacement. It swaps in the real monthly Dogs/Day trajectory from revenue-projections — the full 24-month path, Month 1 through Month 24 (Year-1 close at 18/day, Year-2 close at 30/day): 4, 8, 8, 9, 10, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30 — converted to a weekly target (dogs/day × 5), same 80% rebook rate and 25/50/25 cadence split as Scenario 1.

Month-end snapshot (last week of each calendar month; the full 104-week table is in the script output — every month-transition week shows a short-lived spike back toward 100% new, same mechanism as the month-2 jump in Scenario 1):

Month end (week)Target/wkNew Needed/wkNew as % of targetBooking hrs/wk
M1 (wk 4)2020100%4.7
M2 (wk 9)403690%8.6
M3 (wk 13)402460%6.4
M4 (wk 17)452146.7%6.1
M5 (wk 22)502142.0%6.3
M6 (wk 26)602440.0%7.4
M7 (wk 30)652538.5%7.8
M8 (wk 35)702434.3%7.9
M9 (wk 39)752533.3%8.3
M10 (wk 43)802531.3%8.6
M11 (wk 48)852630.6%9.0
M12 (wk 52) — Year-1 close902730.0%9.4
M13 (wk 56)952829.5%9.9
M14 (wk 61)1002929.0%10.3
M15 (wk 65)1053028.6%10.8
M16 (wk 69)1103128.2%11.2
M17 (wk 74)1153227.8%11.6
M18 (wk 78)1203327.5%12.1
M19 (wk 82)1253427.2%12.5
M20 (wk 87)1303526.9%12.9
M21 (wk 91)1353626.7%13.3
M22 (wk 95)1403726.4%13.8
M23 (wk 100)1453826.2%14.2
M24 (wk 104) — Year-2 close1503926.0%14.7

What’s different from Scenario 1 — this never reaches a floor. In Scenario 1 the target was flat (40/wk) after week 6, so the new-booking requirement had room to fully mature down to the hard 20% floor. Here, the target keeps climbing every single month (per the real growth plan), so the returning-client base is always chasing a moving goalpost. The %-new curve does keep decaying (100% → 30% by Year-1 close → 26% by Year-2 close) because Year 2’s month-over-month target increments are smaller and steadier (+5/wk each month) than Year 1’s early jumps, so the returning-client base gets closer to catching up — but it’s still asymptotically approaching the 20% floor from above, never actually reaching it within the 24-month window.

Booking admin hours climb the whole way — 4.7 hrs/wk at launch to 14.7 hrs/wk by Month 24. By the time the salon is closing in on the 4-groomer ceiling, someone is spending over a third of a full 40-hour workweek purely on booking-related admin (new-client calls plus the smaller incremental time for in-visit rebookings) — not grooming, not marketing, not anything else. That’s a real staffing question in its own right, separate from and in addition to the grooming payroll already modeled in ongoing-expenses. (This number dropped from an earlier ~20.2 hrs/wk estimate once the returning-client time was revised from 6 min to 3 min to reflect that rebooking is meant to happen in-visit, not as a separate call — see Part 3.)

Important caveat this scenario introduces that Scenario 1 didn’t have: by Month 4, revenue-projections has a 2nd groomer on board, a 3rd by Month 9, a 4th by Month 15. Scenario 1’s booking-admin hours were unambiguously Kendra’s own time (she was the only groomer). Here, it’s not clear whose time the 20.2 hrs/wk by Month 24 represents — Kendra’s, split across staff, or a signal that a dedicated front-desk/booking role is justified well before Year 2 ends. Not resolved — flagged as an open question below, not modeled yet (this scenario only reuses G(t), it doesn’t yet know who’s answering the phone).

Known simplifications (same category as Scenario 1’s, not yet reconciled):

  • Each month approximated as 52/12 ≈ 4.33 weeks; real operating-day counts (22/month) aren’t reconciled against this week-based model yet.
  • Same 14-min/3-min call-time and 80%/25-50-25 rebooking assumptions carried over unchanged for all 24 months — no reason yet to think they’d differ once staff are added or the client base matures, but untested.

Open questions for this section

  1. Who actually absorbs the growing booking-admin hours as the team grows (Kendra vs. staff vs. a dedicated booking/front-desk hire) — worth modeling staffing capacity for booking/admin the same way ongoing-expenses models grooming payroll. The ~14.7 hrs/wk by Month 24 (over a third of an FTE) makes this feel less optional than it did at Year-1’s 9.4 hrs/wk.
  2. Does each hiring transition (Month 4, 9, 15 per revenue-projections) also cause a booking-admin spike the same way the Month-2 solo jump did in Scenario 1 — new groomer capacity arrives before any of their own clients are on a rebooking cadence yet.
  3. At what point in this curve does the booking-admin workload alone (independent of grooming capacity) become the actual hiring trigger, rather than the waitlist-depth trigger currently defined in scheduling-procedures?

Not doing yet

  • Not touching the Dogs/Day numbers in revenue-projections.md.
  • Not adding a fill-rate or booking-KPI assumption anywhere permanent.
  • Not writing new followup questions for Kendra yet — want to keep iterating on the framing here first.
  • Not yet decided where this ultimately lives in the vault structure (Operations? Financial? A new section?) — flagged in the title, revisit once the model stabilizes.

Graph View

Backlinks