I started working on the cover flow for missed shifts, and it became more interesting than I expected.
At first, I treated it like a simple status change.
Someone cannot make a shift.
They tap a button.
The shift becomes available for someone else.
That was the clean version in my head.
But once I tried to turn it into an actual product flow, I realized there are a few small decisions hiding inside that button.
It is not really a cancelled shift
This was the first thing I had to separate.
If a staff member says they cannot make it, the job itself is not gone.
The client still expects someone to show up.
The time is still on the schedule.
The owner still needs someone assigned to it.
So I did not want to treat it like a cancellation.
It is more like:
This shift still exists, but the current person is no longer covering it.
That sounds small, but it changes the whole flow.
The shift is not confirmed anymore.
It is not completed.
It is not cancelled.
It needs cover.
That one state became the center of the feature.
The owner needs to see the problem quickly
Once a shift needs cover, the owner should not have to dig through the full schedule to find it.
That is something I keep noticing while building this MVP.
A tool can technically show all the information and still fail at the important part.
If something needs attention, it should be hard to miss.
So the owner view should probably not start with the question:
What shifts exist?
A better question is:
Which shifts need a decision right now?
A missed shift should move into a visible place.
Not hidden inside a calendar.
Not treated like a normal upcoming shift.
Not buried under confirmed jobs.
It needs to stand out because someone still has to solve it.
The staff side should stay simple
The staff side is different.
A staff member should not need to understand the whole scheduling system.
They just need a clear action.
For the person who cannot make it, the action is simple:
I can’t make it
For someone who might cover the shift, the action is also simple:
I can cover this
That sounds obvious, but I think it matters.
If the staff view starts feeling like an admin dashboard, the product is probably doing too much.
Most people do not want another system to manage.
They just want to know what they need to respond to.
So the staff flow needs to stay narrow.
Here is the shift.
Here is what you can do.
Here is what happens next.
That is enough.
The available shift should not show everything
This was the part I almost skipped.
When a shift needs cover, other staff may need to see it.
But how much should they see before accepting it?
At first, I imagined showing the full job details.
That would be easy to build.
But then I thought about it more.
Before someone accepts the shift, do they really need the full address?
Do they need entry notes?
Do they need client contact information?
Probably not.
They need enough information to decide whether they can take the job.
The date.
The time.
The rough area.
The type of work.
After they accept it, the full details can appear.
That feels like a better default.
The available shift page is not just displaying work.
It is also deciding when certain information should become visible.
That is a small product decision, but it changes the feeling of the feature.
The flow needs a clean ending
Another detail I had to think through was the ending.
If someone takes the open shift, what happens next?
Does the original staff member still see it?
Does the new person become assigned immediately?
Does the owner need to approve it first?
Should the shift keep a small history of what happened?
I do not think every MVP needs a full audit log on day one.
That would probably be too much.
But the product should at least make the current state clear.
Who is assigned now?
Is the shift covered?
Does the owner still need to do anything?
That is the real purpose of the flow.
Not just to let someone click a button.
The goal is to remove uncertainty.
The version I am thinking about now
Right now, the simple version looks something like this:
Assigned
↓
Staff says they cannot make it
↓
Shift needs cover
↓
Other staff can see limited details
↓
Someone accepts the shift
↓
Shift becomes reassigned
↓
Owner sees it as covered
This is not complicated.
But writing it out helped me see the product more clearly.
The important part is not the number of steps.
The important part is making sure each person sees the right thing at the right time.
What I learned from this
The cover flow reminded me that small products still need careful state design.
Not enterprise-level complexity.
Just enough structure so the product does not become confusing when real life gets messy.
A missed shift is not just one event.
It affects the owner.
It affects the original staff member.
It affects the person who might cover it.
It affects what information should be visible.
It affects whether the schedule can still be trusted.
That is why I like building this kind of small workflow.
The feature looks simple from the outside.
But once you build it, you start seeing the decisions that were hiding underneath.