One thing I did not expect to spend much time on was shift statuses.
At first, I thought this part would be simple.
A shift is either confirmed or not confirmed.
That was the first version in my head.
But once I started thinking through the actual workflow, that felt too flat.
Because in a real schedule, “not confirmed” can mean a few different things.
It can mean the staff member has not seen the shift yet.
It can mean they saw it but have not replied.
It can mean they said they cannot make it.
It can mean someone else needs to cover it.
It can mean someone already took it, but the owner still needs to know what changed.
Those are very different situations.
If the product treats all of them the same, the owner still has to figure out the real story manually.
And that is exactly the kind of mess the tool is supposed to reduce.
A status is not just a label
The first mistake I almost made was thinking of status as a label on a card.
Confirmed.
Unconfirmed.
Cancelled.
That looks fine in a UI mockup.
But a status is not only something the user reads.
It decides what the product does next.
It changes what actions are available.
It changes what the owner needs to see.
It changes what the staff member can do.
It changes whether the shift should appear in an urgent area, an available shifts list, or a normal schedule view.
That made me realize the status model needed more thought than I expected.
Not because the MVP needs to be complicated.
But because even a small workflow can become confusing if the states are too vague.
The first status: assigned
The most basic state is assigned.
Someone has been placed on a shift.
But assigned does not mean confirmed.
This distinction matters.
A schedule can look complete because every shift has a person attached to it.
But if those people have not confirmed, the schedule is still not really settled.
So I started separating these two ideas:
Who is currently assigned?
And has that person confirmed?
Those sound similar, but they answer different questions.
The owner needs both.
Assigned tells you who is supposed to do the job.
Confirmed tells you whether that person has actually acknowledged it.
Without that distinction, the schedule can look cleaner than it really is.
Waiting for confirmation
The next state is waiting for confirmation.
This is probably the quietest state, but it matters a lot.
Nothing dramatic has happened yet.
No one declined.
No one missed the shift.
No one made a mistake.
But the owner still does not have a clear answer.
That is the uncomfortable part.
A shift that is waiting for confirmation is not a crisis.
But it is also not done.
The product should make that visible without making it feel like an emergency too early.
This is where timing matters.
Waiting for confirmation two days before the job is normal.
Waiting for confirmation thirty minutes before the job is very different.
The status might be the same, but the urgency is not.
That is something I think the dashboard should probably care about later.
Confirmed
Confirmed is the easiest state to understand.
The staff member saw the shift and said yes.
The owner can stop worrying about that specific handoff.
But even here, I think the product should be careful.
Confirmed should not mean the shift can never change.
People still get sick.
Plans still change.
Someone can still say they cannot make it later.
So confirmed is not the end of the entire workflow.
It is just the current clear state.
That sounds obvious, but it matters when designing the flow.
A confirmed shift still needs a path into another state if real life changes.
The product should not trap the shift just because it was once confirmed.
Needs cover
This is the state that changed how I thought about the whole product.
When someone says they cannot make it, the shift should not just become unconfirmed again.
That loses important context.
It is not the same as someone who simply has not replied.
The person did reply.
Their answer was no.
So the shift now has a different problem.
It needs cover.
That status is useful because it tells the owner what kind of action is needed.
Not “wait for a reply.”
Not “check if they saw it.”
Find someone else.
This is why I think “needs cover” deserves to be its own state.
It makes the problem more specific.
And specific problems are easier to act on.
Available to cover
Once a shift needs cover, it may become visible to other staff.
But I do not think that should be the same state as “needs cover.”
Needs cover describes the problem.
Available to cover describes who can act on it.
That difference matters.
From the owner’s side, the shift needs attention.
From the staff side, the shift may appear as something they can take.
Same shift.
Different view.
Different meaning.
This is where status and permissions start to overlap.
The owner may see the full story.
The available staff may only see enough information to decide whether they can take it.
The product has to decide what each person sees at each stage.
That is why the status model cannot be separated from the user roles.
Reassigned
If someone else takes the shift, the status should become reassigned or covered.
I am still thinking about the exact wording.
“Covered” sounds simple.
“Reassigned” makes the change more visible.
Either way, the important thing is that the owner should no longer feel like the shift is unresolved.
Someone else has taken responsibility for it.
The schedule has a new assigned person.
The original person should probably no longer see it as their active shift.
The new person should now see the full details.
That means reassignment is not only a label.
It changes visibility.
It changes responsibility.
It changes who gets the next notification.
That is the part I want the system to make clear.
Cancelled should mean something different
I also think cancelled needs to stay separate.
A cancelled shift means the job itself is no longer happening.
That is different from a shift that still exists but needs another person.
This seems like a small distinction, but mixing these two would create confusion fast.
If a staff member cannot make it, the shift is not cancelled.
If the client cancels the job, then the shift is cancelled.
Those are different events.
They should not share the same status.
Otherwise, the owner may not know whether they need to find cover or remove the job completely.
The product should not make that ambiguous.
The simple model I am thinking about
Right now, the basic model in my head looks like this:
Assigned
Waiting for confirmation
Confirmed
Needs cover
Available to cover
Reassigned or covered
Cancelled
Completed
That might still change.
Some of these may become separate fields instead of one status.
For example, assigned person and confirmation status might be better separated.
Cover availability might be more of a visibility rule than a core shift status.
I am not completely sure yet.
But writing the states out has already helped.
It forced me to see where I was using one word to describe multiple situations.
What I learned from this
The biggest lesson is that status design is product design.
It is easy to treat statuses like small UI details.
But they shape the whole workflow.
They decide what users see.
They decide what actions are possible.
They decide what should be urgent.
They decide when information becomes visible.
They decide whether the owner has to keep the real state of the schedule in their head.
For a small MVP, I do not want to overbuild this.
But I also do not want the states to be so vague that the tool creates more confusion.
A good status should make the next step obvious.
That is probably the standard I want to use.
If the status does not help someone understand what should happen next, it probably needs to be clearer.
Top comments (0)