Preventing double-booked coaches when a class moves
Changing a coach and changing a venue look like two small edits. They are the two edits most likely to quietly break a week’s roster — and the conflict usually surfaces when somebody walks into a room that is already in use.
Why rescheduling breaks quietly
The request is almost always reasonable. “Change the coach and venue for Thursday’s class.” Nobody is being careless, and the person asking has no way to see the problem they are about to create.
The difficulty is that the check is combinatorial and invisible. The new coach has to be free at that hour. The new venue has to be free at that hour. Neither can collide with anything else already on the roster — including classes nobody in the conversation is thinking about. Holding a week’s schedule in your head while answering a message is not a reasonable thing to ask of a person, so it does not happen.
Most systems accept the change. They were asked to update a record, so they update the record. The conflict is not detected — it is created.
Three ways it goes wrong
- silent mistakeThe wrong record gets updated. Nothing errors, so nothing gets noticed.
- misroutedA message goes to the wrong place — the previous coach, the wrong venue contact.
- skippedA step is missed entirely. The class moves; the roster never hears about it.
The expensive one is the first. A failure that raises an error gets fixed in ten minutes. A failure that looks like success gets fixed on Thursday, in person, by whoever is standing in the room.
What a real check has to do
Not “update the record.” Four distinct things, in order, before anything is written:
- Identify the correct classMatch the request against the live schedule — not a stale export, not last week’s copy.
- Check availability across coaches and venuesRun the updated schedule against the week’s roster, not just the one class being touched.
- Detect the conflictCoach is double-booked; venue overlaps with another class.
- Decline the change and explain whyStop before anything is modified, and ask for a valid alternative.
The part most automation gets wrong
Automation is generally built to complete. Given an instruction it can technically execute, it executes. That is the whole value proposition of a workflow tool — and it is exactly the behaviour you do not want here, because the instruction is valid. Every individual field is fine. Only the combination is wrong.
The system would have allowed the change — but it creates a hidden conflict even human operators miss. It stops before anything is changed, and asks for a valid alternative.
Declining is not a failure state. It is the only correct answer to a request that cannot be satisfied, and it is the difference between an automation you have to check and one you do not. A system that always says yes has simply moved the error later, to a point where it costs more to fix.
Stopped before it creates a problem — no cleanup, no follow-up fixes.
Four behaviours, not one
Executing is one of four things a task can correctly do. Which one is right depends entirely on what the system finds when it looks:
- clarifieswhen instructions are unclear
- declineswhen actions are risky
- executeswhen conditions are right
- escalateswhen a human should weigh in
Most tools only have the third. That is why they need watching — and why “it works, until reality gets messy” is the normal experience of automating admin. Reality is messy constantly: missing data, half-formed instructions, requests that are reasonable and impossible at the same time.
This is one deployed example. If it sounds like the shape of a problem you have, the fastest way to find out is to describe it.