Shifts per employee
Own start time, grace window and late policy per person, so a rotating roster and a flexible team coexist without a second system.
Two different problems share this name, and both are covered. Assigning shifts answers who works when. Allocating people to projects across the coming months, with over-allocation caught before it is saved, answers what they work on.
Both halves are live. Shift assignment, grace windows, late policy and rotating rosters are in attendance. Shift templates and the day-by-day roster are in Admin → Shifts & Roster. Project allocation across a planning horizon is in Admin → Planning → Scheduling, with over-allocation checked against each person’s approved leave.
| Shift scheduling | Project allocation | |
|---|---|---|
| Answers | When does this person work? | What do they work on? |
| Needed by | Support floors, BPO, manufacturing, retail | Agencies, software firms, consultancies |
| Unit | A shift on a date | Hours on a project over weeks |
| Constraint | Coverage — is the floor staffed? | Capacity — does this person have the hours? |
| In Employee Desk | Live | Live |
If shift scheduling is your problem, it is already solved and you do not need to wait for anything.
Own start time, grace window and late policy per person, so a rotating roster and a flexible team coexist without a second system.
A 22:00 to 07:00 shift is one working day, not two partial ones on separate dates.
Move people between shift patterns as the roster turns, rather than editing company-wide policy.
The approval screen shows who else on the team is already off, so a shift is not approved into being short-staffed.
Full detail on attendance software and in the attendance documentation. The BPO page covers the rotating-roster configuration specifically.
People down one axis, weeks across the other, allocated hours in the cells. The view every agency currently keeps in a spreadsheet that one person owns.
Allocating 50 hours into a 32-hour week should be refused at the point of entry, not discovered in the retrospective.
The allocation grid knows about approved leave, because it is the same system. Most tools do not, which is why plans quietly assume people who are on holiday.
You planned 40 hours on this client, they consumed 61. That comparison is what makes the next plan better.
Spare hours only help if they are the right skill. Grouping comes from department and designation on the employee record.
Allocation is where committed demand comes from, which is why this and forecasting are the same project.
Yes, in both senses. Shift assignment gives each employee their own shift, grace window and late policy, covering rotating rosters and mixed office and remote teams. Project allocation — assigning named people to projects across a planning horizon — is in Admin, Planning, Scheduling, where a week can also be rolled forward in one action.
Shift scheduling answers when somebody works. Project scheduling answers what they work on while they are there. A support floor needs the first; a services team selling hours to clients needs both.
No. Generating optimal shift patterns from predicted footfall or call volume is a different product category and we are not building it. Scheduling here means allocating your people to the work you have.
By showing it before it is saved. A person allocated 50 hours in a week where they have 32 available is the single most common planning error, and it is entirely preventable if the tool knows about their leave — which it does.
A weekly roster showing who is on which shift. Approved leave, holidays and weekly offs appear in the grid, and a one-day swap sits on top of a longer block without editing it.
Hours per person per project per week, with over-allocation flagged against approved leave, and last week’s plan rolled forward in one action.
Start a 7-day trial and build next week’s roster and project plan with your real team.