Overview
Proposal · interactive sketches · not implemented
The proposed flow is one loop between two people: the manager describes the store and publishes a schedule the agent drafted, the employee asks for changes in plain language, and every change comes back to the manager as a single decision.
Screen sketches
Five exploratory screens: login, sign up, agent chat, my schedule and account. Switch screens and preview desktop or phone layouts. All people, shifts and conversations are fictional; forms and messages only affect this preview. Authentication, invitations and account fields remain proposals. This first pass follows the employee’s path; manager scheduling screens are not included.
Good shifts. Better days.
A schedule that makes space for your team. And everything after work.
Good to have you back.
Your team, your shifts, your next free weekend.
Demo only. Use fictional details; nothing is sent or saved.
For discussion: sign-in method, invitations and account fields are proposals.
The agent does the puzzle; people make the decisions.
Who is involved
| Who | What they would do | What changes |
|---|---|---|
| Manager | Describe the store once, review the draft, publish, approve or reject changes | No longer rebuilds the schedule by hand after every request |
| Employee | See their shifts; ask for a day off, a swap or a later start | No longer has to find a colleague to cover and negotiate it themselves |
| Agent | Draft the schedule, check every change against the rules, explain its choices | Does the checking but decides nothing: in the first version it approves no change on its own |
Both people would use the same application, on a phone or in a browser; what each of them sees depends on their role. See Architecture.
The loop
- Describe the store — the manager, once. Opening hours, roles and rules; the team and its availability; traffic by hour. Updated only when something changes. See Input data.
- Draft — the agent. A schedule for the chosen period that covers the busy hours without breaking a rule. See Schedule generation.
- Review and publish — the manager. The draft shows coverage hour by hour, gaps and overtime, and explains its choices. The manager edits shifts directly or in words, then publishes to the team.
- See your shifts — the employee. The published schedule, and a plain answer to “when am I working next week?”
- Ask for a change — the employee, in plain language: a day off, a swap, a later start.
- Find a way — the assistant. It checks who could take the shift without breaking rest, hours or availability, proposes the least disruptive option, and asks the colleague if one is involved. See Employee assistant.
- Decide — the manager. One ready-made change, approved or rejected in one step.
- Update — the published schedule changes and everyone affected is told.
Steps 4 to 8 repeat until the period ends; then the loop starts again at step 2.
When the path is not straight
- No valid schedule exists. The agent does not hide it. It says which hours are uncovered, which rule blocks them and what would fix it, and the manager decides. See Schedule generation.
- Nobody can cover a shift. The assistant says so and passes the request to the manager with the facts: who was checked and why each option failed. See Employee assistant.
- The manager changes the schedule directly. Possible at any time; the change is checked against the same rules as the original schedule.
Not designed yet
These parts of the flow still need a design decision:
- The final sign-up and invitation flow. The sketches above propose an employee entry screen, not an agreed authentication design.
- What happens after a colleague declines to cover, or after the manager rejects a change.
- How an absence the manager hears about first — a sick call in the morning — enters the flow.
- How people are told that something is waiting for them.
- Whether small changes could later be approved automatically; this is an open question.
Where to go next
- Schedule generation: the manager’s path in detail.
- Employee assistant: the change request in detail.
- Architecture: the application both roles would use.