Every cancelled placement call, timed against the moment it was booked and the moment it was due. This page shows what gets counted, what the timings actually mean, and where the numbers stop being trustworthy.
The report starts from every LUFT call ever booked, and keeps only the ones whose status ended up cancelled. Every table on the screen is a different slice of those same rows.
Every placement call booked into the calendar since Feb 2025: 2,445 completed, 1,010 no-shows, 50 still to happen.
26% of every call booked. This is the only set of rows the screen ever counts.
522 were cancelled by a logged-in member of staff; 705 by the client themselves.
The monthly table groups by the month the call was booked for, not the month it was cancelled in. A call due in August that gets cancelled in July sits in August. That's deliberate: it keeps the row comparable with every other LUFT report, which all count against the scheduled call date.
A cancellation sits between two fixed points: the moment the call was booked, and the moment it was due to happen. The report measures the gap to each one, and every timing column on the screen is one of those two gaps.
"Cancel → call" counts down to the call. A positive number means the cancellation came that long before the call. A negative number means the start time had already gone by. So −7m is not seven minutes of notice; it's seven minutes too late.
"Booked → cancel" is how long the booking survived. It's never negative. The "within 1h of booking" column counts people who booked and then cancelled inside the hour — 202 of them all-time. That's usually a mis-click, a duplicate booking, or someone changing their mind before they've left the page.
460 rows were cancelled after the start time had passed. That reads like carnage. Split it by who pressed the button and it turns into two completely different stories.
Average: 7 minutes past the start. Not one host cancel landed more than 60 minutes late.
Average 4.3 hours past the start, and 11 of them more than three hours late. These are people who never showed and cancelled afterwards.
A host cancelling seven minutes into a call isn't ducking it — they're in it. The call connected, something came up that meant it couldn't go ahead as a placement, and they closed the booking out there and then. Here's a real row:
The booking system records a user id when a logged-in person cancels, and nothing when the client does it from their confirmation email. No id means the client did it, and those all pool into a single Guest row. Last 12 months:
| Cancelled by | Total | After start | Within 1h | Earlier | Avg notice | Reason given |
|---|---|---|---|---|---|---|
| Guest the clients themselves | 666 | 67 | 167 | 432 | 1.3d | 82% |
| Muskaan Ahmed | 126 | 98 | 11 | 17 | 3.0h | 1% |
| Millie Martelli | 94 | 79 | 11 | 4 | 2.3h | 79% |
| Reanna Small | 69 | 62 | 6 | 1 | −3m | 100% |
| Alex Sarkizova | 58 | 47 | 10 | 1 | 1.4h | 97% |
| Rachel Jones | 54 | 33 | 1 | 20 | 11.5h | 94% |
| Nicole Hayward | 50 | 30 | 7 | 13 | 17.8h | 46% |
| Patrycja Janik | 35 | 16 | 9 | 10 | 11.4h | 11% |
| Mkaya Carrigan | 30 | 28 | 2 | 0 | −10m | 7% |
| All cancellations in range | 1,186 | 460 | 224 | 502 | — | 70% |
Rows with fewer than three cancellations are omitted here; the live screen shows them all. "Avg notice" is the average cancel → call gap, so a negative figure means that person's cancellations were typically after the start.
It's a data-quality reading, not a performance one. It says how often that person typed anything into the cancel box. A host at 100% is filling the box in every time; a host at 1% is skipping it. That matters because the breakdown in the next section can only see what was typed — a blank row is invisible to it.
The booking system has no "reason" field. What it has is an activity log: when someone cancels with a note, it writes "Meeting has been cancelled by …" and keeps the note in the description. When they skip the box it writes a bare "Meeting Cancelled". The report reads that log, so a blank is a real, countable fact — not a gap.
Each note is matched against a list of patterns, most specific first, and lands in one theme. The themes then roll into four kinds, which is the split the table is really built for: did we fail to place them, or did they walk away?
| Theme | Kind | Total | By host | By guest |
|---|---|---|---|---|
| No reason recorded the box was skipped | Not stated | 315 | 235 | 80 |
| Other (free text) matched no pattern | Not stated | 245 | 65 | 180 |
| Wanted in person — none available "In person preferred" | Couldn't place them | 159 | 134 | 25 |
| No longer needed / changed mind "Not ready" · "Unsure" | Client withdrew | 110 | 1 | 109 |
| Couldn't make the time "Work" · "Busy" | Client withdrew | 90 | 3 | 87 |
| Found help elsewhere "Found a local" | Client withdrew | 78 | 7 | 71 |
| Budget — too expensive "Price" · "Afford" | Couldn't place them | 49 | 23 | 26 |
| No real answer given "." · "NA" · "-" | Not stated | 43 | 1 | 42 |
| Rebooked or reassigned "Will rebook" | Admin | 41 | 31 | 10 |
| Test, mistake or wrong contact | Admin | 21 | 3 | 18 |
| No therapist in catchment | Couldn't place them | 19 | 17 | 2 |
| Illness or emergency | Client withdrew | 16 | 0 | 16 |
| Last 12 months | 1,186 | 520 | 666 |
The live screen shows real examples of the raw text under each theme, so you can always check the sorting yourself.
Add the three Couldn't place them themes together and you get demand we won and then lost on supply — a client who wanted therapy, sat through the process, and left because we didn't have the right therapist at the right price in the right place.
Order matters when a note names two things. "Wanted in-person, no one in the catchment" is filed under catchment, because catchment is the binding constraint. "Rebooked due to finances" is filed as a rebook, because the client was kept. The specific pattern always beats the generic one.
A cancellation isn't always a loss. 56 people whose call was cancelled later completed a different LUFT call.
The rule is deliberately strict: the same email address appears on a completed LUFT call scheduled after the cancelled one. No fuzzy matching, no name matching, no manual list.
"Right" means: open the booking system, look at the same booking, and get the same answer. Four things stand behind this screen.
A booking row's "last updated" stamp moves every time anything touches it, sometimes days later. Using it would drag cancellations forward and invent late cancels that never happened. The report uses the moment the system wrote "cancelled" in its activity log, which never changes.
1,147 of the 1,227 rows have a logged cancel event. The other 80 fall back to the booking's last update, and the screen prints that count in its own footer rather than burying it. Those are the only rows whose bucket could be wrong.
The monthly table and the who-cancelled table share the same code for every bucket boundary, and it's covered by tests. They can't drift apart — which they once did, when an after-start cancellation was quietly being counted as "within the hour".
No cancellation is ever assigned a reason it wasn't given. A blank stays a blank and is counted as one, which is why the capture rate is a number on the screen rather than a footnote.
Rows are grouped by the month the call was due, so the current month keeps growing all month and future months already have a few rows in them. Compare finished months.
All 393 of them landed within an hour of the start, averaging seven minutes past. Treat that column as "closed out at the slot", and read the client's 67 separately — those are the genuinely late ones.
Half the rows say nothing usable. Every share in that table is therefore a floor, and comparing two hosts' reason mixes is meaningless when one fills the box every time and the other almost never does.
Where no cancel event was logged, the booking's last-update stamp stands in. That stamp can be later than the real cancellation, so a handful of rows may sit in a later bucket than they deserve.