mmitech
Hero illustration for the Resource And Waitlist Yield Recovery solution

The 7pm spin no-show. The 10:05 walk-in. The three brides who all asked for May 18th.

“Tuesday night - 60 covers booked, 11 no-shows by 9pm. Saturday morning workshop - four bookings in the diary, 9:15 a walk-in turns up with a flashing engine light. Saturday May 18th - three brides asked, I can do one. The two I can’t take are the awkward calls I’ve been putting off all week.”

Every resource-constrained UK SME has the same shape of problem. The gym member who books the 7pm spin class and doesn’t show; the table of twelve in the back room who confirmed Monday and showed at three on Tuesday night; the workshop with four bookings in the diary that the walk-in customer with the flashing engine light doesn’t fit into; Bertie’s owner who cancels his Wednesday daycare slot and by Friday afternoon the slot’s still empty; the storage unit that vacated overnight and won’t be relisted until the lettings person gets to it on Tuesday; the aesthetic Saturday slot at £350 that the cancellation didn’t refill before the customer went elsewhere; the three brides who all wanted May 18th and you can take one. Capacity is the bottleneck of the trade, no-shows and cancellations and walk-ins create gaps the staff can’t fill fast enough by hand, and the “sorry, fully booked” customers don’t get a thoughtful alternative - they get a one-line text that reads as a brush-off.

This is the build that turns capacity into a managed object. Bookings + waitlist + no-show recovery + walk-in integration + alternate-date offer-up - running as one engine on top of whichever booking system you already have. The shape is sealed against Iron Institute, the live gym-side class-waitlist auto-promote where the 90-second response window closes empty slots before they leak the day’s margin, and ports cleanly across hospitality cover-yield, clinic and aesthetic no-show recovery, pet-services daycare cascade, self-storage vacate-to-relist, wedding-supplier Saturday-cap triage, driving-instructor DVSA test-slot watching, independent-garage Saturday-morning bay re-shuffle, storm-damage roofing and tree-surgery seasonal capacity, and holiday-let Saturday changeover orchestration.


What gets lost between the slot is open and the slot is filled

The shape repeats; the lost margin is always the same in a different costume. A few moments - pick the ones that sound like your week:

These aren’t problems for a generic booking calendar’s “sorry, fully booked” page. They’re the bit between the slot is open and the slot is filled - which is where the day’s margin actually lives.

The empty spin bike at 7:02 - the offer-up cascade fired at 6:58, the position-1 confirmed at 7:00

What solved looks like

1. The resource is a tracked object, not a calendar slot

The “where do walk-ins sit on this” moment: the calendar shows four bookings in four bays Saturday morning. It doesn’t show that the morning MOT’s about to overrun; it doesn’t show the courtesy car’s at the body shop; it doesn’t show that the apprentice’s on his lunch break at 12:15. The walk-in lands and the front-of-house is the integration layer - until she cries.

Solved looks like: every resource (every slot / table / bay / unit / kennel / chair / room / crew) is a structured object with its capacity, its current booking, its no-show window, its waitlist position, and its dependency on the resources around it. The walk-in lands on the live diary and the re-shuffle adjusts existing bookings with an ETA SMS firing automatically to the affected customer. The kitchen sees the cover load in real time and the front-of-house stops being the manual integration layer. The bay schedule, the courtesy car availability, and the parts-pickup window all live on the same record.

2. The waitlist is a structured priority queue, not a notepad

The “she said she’d come if a slot opened” moment: the wedding venue’s host wrote down the three brides who asked about Saturdays in May. Two of them got “sorry, fully booked” on email. None of them got the alternate-Saturday offer because nobody’s owning the conversation past the first reply. The two awkward calls remain unmade.

Solved looks like: each waitlist is a structured priority queue with the customer’s preferences (date / time / specific resource / specific instructor / specific bay), her contactability window, and her holding-deposit state if she’s paid one to earn the position. Each open slot fires the offer-up cascade through positions 1, 2, 3 with a 60-second / 90-second / 24-hour confirmation window per vertical. The wedding-supplier alternate-Saturday offers ladder out in your voice, not as a generic “sorry” text. The pet-services position-2 customer gets the Wednesday slot in fifteen minutes, not on Tuesday. The storage relist fires the same morning the customer vacated, not the following Tuesday.

3. No-show pre-charging where the T&Cs already cover it

The “the table’s gone, the kitchen’s overstaffed” moment: Tuesday night, 60 covers in, 11 no-shows by 9pm. The booking T&Cs say “a £25 deposit applies for parties of six or more” - but nobody’s actually collecting it. The kitchen ate the cost. The chef did the prep. The waiting staff served three tables of two.

Solved looks like: where the booking T&Cs you already have support it (and the customer accepted them at booking), the no-show window auto-closes against her saved payment method when the no-show fires. The freed slot enters the waitlist offer-up cycle the same moment. No new charge mechanism the customer hasn’t agreed to - we wire to the agreement you already have. For pack-based booking on the PT side, the no-show fires the session-count drawdown the same way the actual attendance would. The cost of no-shows becomes a recovered yield, not an absorbed cost.

4. Walk-in integration writes to the live diary in real time

The “she’s at the counter waiting on a taxi” moment: Saturday morning, walk-in customer with the flashing engine light. The bays are full. The front-of-house is now the manual integration layer between the workshop floor, the courtesy car (which is at the body shop), the parts pickup (which doesn’t arrive until 1pm), and the customer (who needs to be at work by 11am). She’s standing at the counter while the manager rings around.

Solved looks like: the walk-in lands on the live diary the moment it’s logged. The re-shuffle adjusts existing bookings with the ETA SMS firing to the affected customer in your voice. The dependency graph (parts pickup, courtesy car, apprentice break, MOT bay overrun) updates in real time so the “is there a bay free at 14:00” question is answered from the screen. The hand-off to the Booking & Review Loop is automatic - the existing-booking customer who’s slipping to 15:30 gets the same en-route ETA + arrived cascade as if she’d booked for that time originally.

5. The alternate-date offer-up is warm, not a brush-off

The “sorry, fully booked” moment: May 18th is gone. The two brides you can’t take get a one-line “sorry, fully booked, best of luck”. Goodwill that could have stayed warm for a referral, a future booking, a friend’s wedding turns into a customer who’ll talk about you politely but won’t recommend you.

Solved looks like: where the customer can’t be accommodated on the requested date, a thoughtful in-your-voice alternate offer ladders out from the structured availability - “May 18th’s taken; here are the Saturdays I’ve got open that summer; if any of those work I’d be delighted, otherwise the best wedding suppliers in our network for that date are these three, all of whom I’d happily recommend”. The voice is yours; the tone is warm; the alternates are real. Potential future advocates stay advocates rather than turning into the reviewer-with-a-grudge six months later. The same engine handles the “sorry, the 8am yoga is full this week” offer at the gym side and the “my Wednesday’s full this term” offer at the PT side.

6. The dashboard tells you where the day’s yield actually went

The “did we lose money on Tuesday” moment: Tuesday’s gone. The restaurant manager has a sense the no-shows were worse than usual; the gym owner thinks the 7pm class had two empty bikes; the daycare owner thinks Bertie’s cancelled slot didn’t refill. None of them are sure. The variance against capacity for the week is the question the owner wants answered every Sunday evening; currently the answer is a guess.

Solved looks like: every capacity event by current state (booked / confirmed / no-showed / cancelled / walked-in / waitlist-promoted / unfilled / refunded), grouped by resource and by time of day. The variance against full capacity rolls up by day and by week. The Tuesday-night cover yield, the Wednesday spin attendance, the Saturday wedding alternate-date conversion, the daycare-slot refill rate, the storage-unit vacate-to-relist time - all on one screen, sorted by which gap cost the most. Total time on the dashboard: nine minutes. The week’s yield management is on.


The May 18th alternate-date offer-up - three brides, one Saturday, two warm conversations

How the yield-recovery engine runs, by default

The default service-business shape runs:

Per-vertical tuning lives on top - the gym class waitlist runs on a 90-second auto-promote window; the hospitality cover yield runs on a 24-hour pre-charge window where T&Cs cover it; the aesthetic Saturday slot runs on the eleven-minute waitlist cascade with the holding deposit applied; the pet daycare runs on the £50 holding-deposit + position-1 / 2 / 3 cascade; the self-storage relist runs on a same-morning relist trigger; the wedding-supplier Saturday-cap runs on the alternate-Saturday offer-up with the premium-pricing surface on peak Saturdays; the driving-instructor DVSA test-slot watcher runs within DVSA’s terms-of-service as a legitimate alternative to the scraper apps; the storm-damage roofer / tree-surgery capacity model runs on the peak-ramp-up + scale-back curve with the seasonal-crew add and the seasonal-crew release; the holiday-let cleaner cascade runs on the Saturday-changeover WhatsApp confirmation thread.


Who this is for

The shape repeats across every UK SME where capacity is the bottleneck and empty slots cost the day.

Cover and slot yield - hospitality, wedding venues, clinics and aesthetic clinics, dental practices, private GPs, vet practices. Cover-yield waitlist recovery with the “three confirmed of twelve, three on tap water” triage; no-show pre-charging where booking T&Cs cover it; Saturday-slot recovery at the high-margin end.

Class, session and pack businesses - gym and fitness, personal trainers. Class-waitlist auto-promote with the 90-second response window; pack-based booking with session-count drawdown visible per pack; lapsed-member recovery against attendance frequency rather than calendar date.

Inbound-items service with bay scheduling - device repair, independent garages. Saturday-morning bay re-shuffle with the walk-in landing on the live diary; the courtesy-car / parts-pickup dependency graph respected; the existing-booking customer notified before the conflict surfaces at the counter.

Daycare, kennel and one-pet capacity - pet services. Waitlist offer-up cascade for cancelled daycare slots; £50 holding-deposit + position-1 / 2 / 3 cycle.

Unit-based recurring - self-storage. Vacate-to-relist within 24 hours rather than three weeks; same-morning waitlist cascade for the size-band the vacated unit belongs to.

Saturday-cap and peak-season businesses - wedding suppliers, holiday lets, storm-damage roofers, tree-surgery landscapers. Alternate-Saturday offer-up with premium-pricing surface on peak Saturdays; storm-season elasticity with crew ramp-up; holiday-let Saturday-changeover orchestration with the cleaner-confirmation thread.

DVSA test slot watching - driving instructors. Test-slot watcher running within DVSA terms as a legitimate alternative to the unofficial-scraper apps; the customer’s preferred test centre + date window monitored, the earliest matching slot surfaced when it appears.

Same engine; different resource model; different no-show rules; different cascade window.


The closest thing we’ve already built

Iron Institute - live class-waitlist auto-promote running on the gym side. Member books, no-show detected at the 30-minute-before mark, waitlist offer-up to position 1 with a 90-second response window, second-position offer if position 1 doesn’t respond. The build is shaped around closing the empty-slot recovery on the gym’s class diary. See Iron Institute for the build detail.

A private-hire event venue we’ve built end-to-end - venue-side Saturday-cap triage on weddings and event bookings. The three-brides-one-Saturday shape, with the alternate-Saturday offer-up running in the venue manager’s voice and the peak-Saturday pricing surfaced structurally rather than negotiated case-by-case.

mendbuddy is the multi-channel platform behind every offer-up cascade - voice / SMS / WhatsApp / push / web chat carrying the “a Wednesday spin bike just opened, you’re position 1, 90 seconds to confirm” message in the gym’s voice, the “the Saturday slot at 14:30 just opened, can you take it” message at the aesthetic-clinic side, the “Bertie’s slot for Wednesday daycare is yours if you want it” at the pet-services side.

pharmaceutical-analytics.com is the dashboard shape behind the owner / manager view of the week’s yield - every capacity event by state, variance against full capacity rolled up daily / weekly / quarterly, the “which gap cost the most” question answered from one screen.


The Saturday-morning walk-in landing on the live diary - the re-shuffle ETA SMS firing automatically

Tell us what’s empty when it should be full

What you do, what your last week’s no-show count looked like, what last month’s cancelled-slot-that-didn’t-refill count looked like, what the modal “sorry, fully booked” question you get from customers is, where in the operation the walk-in or the cancellation most often becomes a manual scramble. Tell us the highest-margin slot you’ve lost in the last quarter that should have refilled itself and we’ll come back with a sketch of what we’d build so the next one doesn’t. No demo, no calendar widget. Email reply, scoped sketch, you decide.


FAQ

Will it work with our existing booking system (ResDiary / OpenTable / SevenRooms / Cliniko / Dentally / Pabau / RepairMinder / Cal.com / our native gym app / Bookwhen / TeamUp)?

Yes for all the named ones. The waitlist + no-show + alternate-date engine reads booking events from your system, manages the waitlist + offer-up cascade on top, and writes confirmed bookings back. No replacement of the booking surface; we wire the yield-recovery layer on top.

Will the no-show pre-charge work in our consumer-facing business?

Where your booking T&Cs already support it (most clinics and aesthetic clinics; most personal-trainer pack-based businesses; most veterinary practices; most wedding venues with deposit terms; most hospitality bookings for groups of six+ where deposit T&Cs exist) and the customer accepted them at booking, yes. We don’t add a new charge mechanism that the customer didn’t agree to - the build runs against the agreement you already have. Where the T&Cs need updating to support no-show pre-charging, that’s a separate conversation with you and your terms.

Is the alternate-date offer-up actually warm, or does it read as automated?

Warm by training. The voice training is the same shape as the trainable inbound AI agent - your past “sorry I can’t take this one” emails, your past “how about June 25th” offers, your tone of voice for the difficult-but-kind conversation. First ten alternate-offers fire as draft-for-you-to-send-or-edit so the voice has a feedback loop; after that, you keep the send-or-edit slot for the cases the agent flags as needing your eye (the long-relationship customer, the referred-by-a-VIP customer, the unusually-sensitive timing).

Will the DVSA test-slot watcher run within DVSA’s terms of service?

Yes - explicitly. The legitimate route uses the customer’s own DVSA account credentials (with her consent) and operates within the published terms; this is structurally different from the third-party scraper apps that operate in DVSA’s terms-of-service grey area. The customer’s preferred test centre + date window is monitored; the earliest matching slot is surfaced when it appears; she confirms or declines in your branded conversation. No scraping, no terms violation.

Will the storm-season elasticity model actually work for a small roofing or tree-surgery business?

Yes - the build is shaped around the peak / trough pattern that’s structural in those trades. Storm Friday means three crews need to come on within seven days for the pipeline of insurance-pay work; the capacity model surfaces the peak ramp-up requirement before the storm hits, the seasonal-crew adds run on the WhatsApp-based subcontractor network the trade already uses, and the scale-back fires when the weather settles. The owner stops running the ramp curve in his head.

How does the walk-in integration handle the dependency graph - parts, courtesy car, apprentice break?

Each dependency is a structured object on the resource record. The walk-in landing on the live diary triggers the dependency check (is the courtesy car at the body shop? is the parts pickup at 1pm? is the apprentice on his lunch break at 12:15?) and the re-shuffle respects the constraints. Where a re-shuffle isn’t possible without breaking a constraint, the system flags it for the front-of-house to handle rather than committing to something that won’t work.

Can the existing customer who’s been re-shuffled actually see what’s happened?

Yes - the ETA SMS fires automatically in your voice with the new arrival window and a one-tap acknowledge / reply / call me option. The hand-off to the Booking & Review Loop cascade means the re-shuffled customer gets the same en-route ETA + arrived + completed cascade as if she’d booked for the new time originally. The “is he coming” phone call to the front-of-house doesn’t happen because the customer already knows what’s happening.

Does this replace our booking system / our diary / our practice-management software?

No. It sits on top. The booking surface stays where it is - ResDiary, OpenTable, Cliniko, Dentally, your native gym app, your Cal.com setup, your booking widget. The yield-recovery layer wires the waitlist + no-show + walk-in + alternate-date + dashboard pieces those tools don’t fill. We integrate; we don’t replace.

What does it cost?

Every build is scoped per client - depends on your booking system, your resource model, your no-show rules, your waitlist channels, your vertical’s specific cadence. We talk it through, agree the scope and the price in writing, then build. Ongoing hosting + small change requests is monthly and is part of the scope conversation. See pricing for how we work.

Tell us what's slowing the business down

Send an enquiry - what you do, what's slowing you down, what you've already tried. We'll come back with a sketch of what we'd build and what it would cost. No calendar, no demo to sit through.

No calendar widgets. Email reply, scoped sketch.

Tell us what's slowing the business down

Email reply, scoped sketch, you decide. No calendar widgets, no demo to sit through.

No calendar widgets. Email reply, scoped sketch.