DEV Community

Miran
Miran

Posted on

I Didn’t Add “Reminded” to the Shift Status Enum

#webdev #saas #product #buildinpublic

A reminder is something the system did, not an answer from the cleaner, so sending one should not replace the shift’s actual confirmation state.

A cleaning shift remains marked Unconfirmed while a separate reminder slip is timestamped, with Confirmed and Cannot make it cards waiting for the cleaner’s actual response
A cleaner has not replied to tonight’s shift.

The manager sends a reminder at 2:30 PM.

Now I have two facts:

Shift status:
Unconfirmed

Reminder:
Sent at 2:30 PM
Enter fullscreen mode Exit fullscreen mode

There is an easy way to make the interface look more active:

Shift status:
Reminded
Enter fullscreen mode Exit fullscreen mode

I would not do that.

The reminder tells me what the manager did.

It does not tell me what the cleaner decided.

Those two facts belong close together, but they should not compete for the same status field.

A reminder does not resolve the unanswered question

The assigned cleaner still needs to answer one question:

Can you work this specific shift?

Before the reminder:

Cleaner: Jordan
Client: Riverside Office
Start: 7:00 PM
Shift status: Unconfirmed
Enter fullscreen mode Exit fullscreen mode

After the reminder:

Cleaner: Jordan
Client: Riverside Office
Start: 7:00 PM
Shift status: Unconfirmed
Last reminder: 2:30 PM
Enter fullscreen mode Exit fullscreen mode

The operational situation has not changed.

Jordan still has not answered.

Only the communication history changed.

That is why I would resist a transition like:

Unconfirmed
→ Reminded
Enter fullscreen mode Exit fullscreen mode

It gives a messaging event the appearance of progress in the staffing workflow.

The manager did something useful, but the original risk still exists.

The message event deserves its own record

The cleaning shift reminder template makes this distinction visible in the workflow.

Owners or admins can manually send reminders after the schedule is shared. The reminder asks for a clear response, such as confirming the shift or saying the cleaner cannot make it.

That suggests a cleaner model to me:

Current shift state:
Unconfirmed

Communication history:
Reminder sent at 2:30 PM
Enter fullscreen mode Exit fullscreen mode

The exact production fields may be different. I am not describing CleanConfirm’s internal database schema here.

The important part is the relationship.

A reminder can have its own timestamp and sending result without becoming the shift’s current staffing condition.

That also means several reminders do not require several new states:

Unconfirmed
Reminder sent Monday
Reminder sent Tuesday
Reminder sent Wednesday
Enter fullscreen mode Exit fullscreen mode

The history grows.

The unanswered staffing question stays the same.

“Sent” belongs to communication, not confirmation

The same separation becomes useful when the email layer returns a result.

The page distinguishes notification outcomes such as:

Sent
Failed
Skipped
Enter fullscreen mode Exit fullscreen mode

from cleaner responses such as:

Confirmed
Cannot make it
Enter fullscreen mode Exit fullscreen mode

That is a useful boundary.

A successful send attempt can tell me:

The reminder was attempted.
Enter fullscreen mode Exit fullscreen mode

It cannot tell me:

The cleaner accepted the shift.
Enter fullscreen mode Exit fullscreen mode

Even if the notification provider reports Sent, the cleaner may still be Unconfirmed.

I would rather let those facts coexist:

Notification: Sent
Shift: Unconfirmed
Enter fullscreen mode Exit fullscreen mode

than compress them into a reassuring status that implies more than the product actually knows.

The send record answers what happened to the reminder.

The shift state answers what happened to the assignment.

The cleaner’s response is what changes the branch

Eventually Jordan replies.

If the response is:

Confirmed
Enter fullscreen mode Exit fullscreen mode

the workflow now has new information about the assignment.

That is a meaningful state change.

If Jordan instead replies:

Cannot make it
Enter fullscreen mode Exit fullscreen mode

the reminder phase also stops being the relevant workflow.

The page says ordinary confirmation reminders should stop at that point, and the shift moves toward Pending Cover while an owner or admin decides what cover follow-up is needed.

Conceptually:

Unconfirmed
    |
    | cleaner confirms
    v
Confirmed
Enter fullscreen mode Exit fullscreen mode

or:

Unconfirmed
    |
    | cleaner cannot make it
    v
Pending Cover
Enter fullscreen mode Exit fullscreen mode

The transition comes from the cleaner’s response, not from how many messages the manager sent before receiving it.

That keeps the state names tied to the thing the team actually needs to know.

Reassignment starts the confirmation question again

There is another reason I do not want reminder history inside the main state enum.

Suppose the original cleaner cannot make the job.

A Cover Request is reviewed and another cleaner is formally assigned.

The replacement is not automatically Confirmed.

The new cleaner still needs to respond to the new assignment.

So the workflow may arrive at another unanswered question:

Assigned cleaner: Maria
Confirmation: Unconfirmed
Enter fullscreen mode Exit fullscreen mode

The earlier reminder history belonged to Jordan’s assignment.

It should not make Maria look partly confirmed, reminded, or further along in the response process.

The new assignment can start with its own communication history while keeping the staffing state clear.

That becomes much easier when reminders are events instead of states.

Keep activity visible without pretending it is progress

I still want the manager to see that follow-up happened.

A dashboard that only says:

Unconfirmed
Enter fullscreen mode Exit fullscreen mode

can hide useful work.

Something like this is much more useful:

Unconfirmed

Last reminder:
Today, 2:30 PM

Reply deadline:
5:00 PM
Enter fullscreen mode Exit fullscreen mode

Now the manager can see both things:

the cleaner still owes an answer, and
someone already followed up.

Neither fact has to overwrite the other.

That is the distinction I would preserve in the state model.

Unconfirmed, Confirmed, and Pending Cover describe where the assignment stands.

A reminder timestamp describes what the team did while trying to move it forward.

Sending another message can be useful.

It just should not make an unresolved shift look resolved—or even halfway resolved—before the cleaner actually replies.

Top comments (0)