Scheduling: Employee requests
Objective. Review pending time-off, preference and swap requests and see their impact on coverage and rules before approving - treating an approval as a new constraint the schedule must honour.
This screen answers: how do employee requests enter the schedule, and what do they cost in coverage? The key read is that an approved request becomes a constraint the draft must then meet, so approving without checking interval coverage can create a shortage.
See it in the demo
What this screen answers
A Sales or CSM person opens requests to answer: how are time-off, preference and swap requests handled, and what is their effect on the schedule? It is where employee-driven change meets the coverage requirement, and where fairness and service have to be balanced.
The task
Review the pending request queue for the team and period. Before approving, look at the impact on interval coverage and rules: does granting this leave a shortage at a peak, or break a rest rule? Approve, decline or defer with that impact visible, and make sure approvals have a named owner.
How to read it
An approved request is a constraint the schedule must then honour - approving one without checking interval coverage can open a shortage window you will discover later. The queue shows demand for change, not the published outcome: a pending request has changed nothing yet. The misread to avoid: approving on fairness alone without reading the coverage cost, or assuming the queue reflects the live schedule.
Honest limits
This screen shows requests and their planned impact; it does not itself publish the resulting schedule or prove the day will run smoothly. Who may approve, and the policy for balancing fairness against coverage, is an ownership decision. Confirm with product which request types and approval workflows apply for a customer.
Interpretation check
Approving a request changes the constraints the draft must meet - check its coverage impact first; the request queue is demand for change, not the live schedule.
In the field
A contact centre granting a cluster of Friday leave requests: the screen shows they would gut the afternoon peak, so the CSM teaches checking coverage impact before approving, not after.
Practical task
On the demo requests queue, pick one pending request and write a one-line decision that states its coverage impact and whether approving it opens a shortage window.
Self-check
A time-off request looks fair. Is that enough to approve it?
No. Check its impact on interval coverage and rules first. An approval is a constraint the schedule must honour and can open a peak shortage.
Does a pending request change the current schedule?
No. The queue is demand for change. Nothing changes until the request is approved and the resulting schedule is published.
Why should request approvals have a named owner?
Because approvals trade fairness against coverage and cost; unowned approvals create confusion over which version is live and who decided.
Verified vs demo. Screen is live in the demo at /#/requests; exact controls, labels and figures are SME-validation-pending.