A real-world event does not automatically deserve a place in the product state machine, especially when it answers a different operational question.
A cleaner confirms a 6:00 PM shift.
At 5:50 PM, they message the manager:
Running about 15 minutes late. ETA 6:15.
My first product instinct could have been:
Confirmed
→ Late
It sounds reasonable. “Late” is clearly something the manager cares about.
But once I tried to fit it into the same status model as shift confirmation and replacement coverage, it started creating more questions than it answered.
Was the cleaner no longer confirmed?
Should Late replace Confirmed, or should both exist at once?
Does a late cleaner automatically need cover?
What happens when a cleaner is late but the client has already approved the new arrival time?
I decided not to make Late another confirmation status.
The status was already answering a specific question
Before a cleaning shift starts, the confirmation part of the product is trying to answer something fairly narrow:
Is this assigned shift settled?
For that part of the workflow, values like these are useful:
Unconfirmed
Confirmed
Pending Cover
They tell the owner whether the assigned cleaner has explicitly accepted the work or whether coverage still needs attention.
A cleaner arriving 15 minutes late is a different kind of information.
The cleaner may still be the assigned person.
They may still intend to work the shift.
No replacement may be necessary.
Changing the shift from Confirmed to Late would throw away one answer in order to store another.
I didn't like that trade.
The attendance guidance I ended up using on the cleaning employee attendance policy template keeps those concerns separate: lateness and other company-policy incidents can be documented by the manager without turning every incident label into a CleanConfirm system status.
Status explosion happens quickly
Adding one extra value rarely stays at one extra value.
If I add:
Late
the next reasonable requests might be:
Called out
Left early
Missed shift
Policy violation
Emergency
Client excused
Then combinations start appearing.
A cleaner could be:
Confirmed + Late
or:
Confirmed + Left early
or perhaps:
Unconfirmed + Called out
At that point, one status field is trying to represent several dimensions at once:
- whether the assignment was confirmed
- whether the cleaner expects to work
- whether replacement coverage is needed
- what happened around attendance
- whether a company policy was triggered
Those aren't necessarily one lifecycle.
Making the list longer wouldn't make the model clearer.
It would make the status label responsible for questions it was never designed to answer.
A note can be more accurate than a state
For a late arrival, the operational detail I would rather preserve is closer to:
Manager note
Cleaner reported running late at 5:50 PM.
Updated ETA: 6:15 PM.
Client notified: Yes.
Cover needed: No.
That tells the manager what actually happened.
It doesn't pretend lateness changed the underlying confirmation automatically.
If the cleaner instead says they cannot work the shift, that is different. Now the response can affect the staffing workflow: Cannot make it can move the shift toward Pending Cover, and a Cover Request can be reviewed before reassignment.
There is an actual workflow transition there.
“I'm 15 minutes late” does not always create one.
That became a useful test for whether something belongs in the main state model.
Does this value change what the product needs to do next, or is it context about what happened?
Sometimes it is both.
But I don't want to assume that by default.
Product states should stay tied to product actions
This also helps keep buttons predictable.
Imagine the UI sees:
Status: Pending Cover
There are fairly clear next questions:
Is there a Cover Request?
Who submitted it?
Has an owner or admin reviewed it?
Was another cleaner assigned?
Has that cleaner confirmed?
The state connects to actions the product actually supports.
Now imagine:
Status: Late
What is the next product action?
Send a warning?
Notify the client?
Start payroll penalties?
Record disciplinary points?
Automatically find cover?
Every cleaning company may answer those differently, and some of those decisions belong to company policy rather than a shift-confirmation tool.
I would rather not create a system status that implies the product owns those decisions when it doesn't.
A manager can document the attendance incident and follow the company's own policy.
CleanConfirm can keep doing the smaller job it can represent clearly.
The same event can matter without owning the workflow
Keeping Late out of the main status list doesn't mean lateness is unimportant.
The attendance policy still needs to say what cleaners should do when they are running late.
Managers may need the reason, notice time, updated arrival estimate, client impact, contact attempts, and any follow-up action.
Repeated lateness may matter when the company plans future schedules.
All of that information can be operationally important without becoming the current state of the assigned shift.
That distinction has been useful while building small tools.
Users describe the real world with dozens of words.
A product does not need an enum for every one of them.
Sometimes the cleaner thing to model is:
Workflow state:
Confirmed
Operational note:
Running 15 minutes late
ETA 6:15 PM
Both facts survive.
Neither has to distort the other.
I want fewer states with stronger meanings
A short status list isn't automatically better.
But every status should earn its place.
For this product, I want a shift state to tell the owner something they can reliably interpret in the confirmation and coverage process.
I don't want the list to become a compressed employee handbook.
So Late stayed outside the core confirmation state model.
The manager can still record it.
The company can still act on it.
The shift can remain confirmed if that is still the truth.
Sometimes keeping one word out of a status dropdown preserves more information than adding it.
Top comments (0)