The rejection that was not a rejection
A request arrives on Monday: one room, five days, starting next week. You open the calendar. Tuesday, Wednesday and Thursday are free. Monday and Friday are held by a group that booked months ago. The request is one record with one decision attached, and that decision has two values, approve or reject. So you reject it, write a note listing the three free days, and ask the requester to book again. Most do. Some do not, and you never learn why.
Nothing in the system counts this as a failure. The request was processed within the target and the room will probably get used. The only trace that something went wrong is your note, and it lives in an email nobody will ever analyse.
Where the model and the decision came apart
Whoever designed the booking form was not wrong. A requester experiences a five day booking as one thing, so the form captured it as one thing and approval was attached to it. That is the natural first version of most workflows.
The mismatch is between two units that should be the same and are not. The decision unit is the resource on the day: whether this room is free on this Tuesday. The record unit is the whole request. Approval sits on the record, so you can only answer at that resolution, though the honest answer is per day.
Every workaround you have adopted compensates for that gap. A comment field on the rejection is the usual one, and it is the same workaround at lower resolution: the per day decision exists, but only as prose someone must read and retype. It never reaches a status, so it never reaches a report or a backlog.
Splitting the record without splitting the experience
The fix we agreed with a national youth platform, and are building now, changes the record granularity rather than the form. A five day request is stored as five records, one per day, each approvable on its own. The decision unit and the record unit are now the same.
On its own that would make matters worse. Five unrelated rows lose the requester intent, and a form that asks for five bookings instead of one moves the work onto them. So the split stays below the surface: the requester fills in one form and sees one booking in their list, as before. An indicator on each day record marks that it belongs to one multi day request, so the reviewer still sees one intent.
This is a data model change, not a feature request. Live systems accumulate workarounds because nobody wants to touch the model. Decide the granularity deliberately, once, with a plan for existing records, rather than patching around it.
Partial approval as a real outcome
Once each day carries its own decision, a request can end in three states rather than two: approved, rejected, or partly approved. The third needs a status of its own, because in the old model partial fulfilment was never a legitimate outcome, only a failure to fulfil.
It also needs its own notification, because a rejection notice tells the requester the opposite of what happened. Then what they do next is a choice rather than a chore: keep the three days, or ask about alternatives for the other two.
If you expect users to find partial approval confusing, weigh it against what they get now: a rejection they do not understand, followed by an instruction to try again.
What the reviewer sees
In the administration view being built, the days of one request sit together as separate records, each carrying an indicator that they belong to one multi day request. The reviewer opens the request, sees five days with availability against each, and approves three in one pass, rejecting the other two in the same action.
For the system owner, the change is where the decision is kept. Each day carries its own status, so a partly approved request becomes a state the system holds rather than a sentence a reviewer typed into an email. When the decisions sit in the records, the report can start to match what happened.
The same mismatch elsewhere
Booking is the example, but the pattern is general: a request modelled at the resolution the requester experiences, and a decision made at a finer one. A purchase request with eight lines where six should be granted. A week of leave where Thursday clashes. A shift rota where one person can cover half the slots. An order where two items are in stock and one is not.
The tell is the same every time: staff reject and ask for resubmission, or decide in email and type the answer back in. The checklist with this post lists those signs and the modelling decision behind each, so you can name what your team has been absorbing.
