Home · Solutions · HR & people
Solution · HR & peopleTwo operators call in sick and the roster is whole again before the shift starts
Shift cover filled in minutes, with the rules checked
Every absence opens a cover search against your own qualification, working-time and cost rules; eligible people are offered the shift in Microsoft Teams and a supervisor confirms who takes it.
Executive summary
A sick call should not cost a supervisor an hour of phone tag and a payroll correction.
The rule set is not ours, and that matters more than any part of the architecture.
Shifts are filled from people who are genuinely eligible, so nobody discovers an unqualified choice after the shift has run.
the roster in Microsoft Teams Shifts or your workforce management system; the time and attendance system; the payroll input
Business problem
Frontline workforce
Frontline rosters are built weeks ahead against forecast volume. Then reality arrives one absence at a time, and each one is a planning problem to be solved in twenty minutes by the person with the least information and the least time.
What the supervisor cannot see is most of what matters: who is qualified for that position on that date, who is near a weekly limit, who has not had the rest the agreement requires, what each option costs. All of it exists, across four systems, and none of it opens on a phone in a cold store.
The consequences land later, on other people. The change is agreed by phone and typed into the time system days later, so the roster shows one name and the clock another, and premium hours reach payroll separately to be corrected next period. Across six sites the company pays twice: in premium and agency hours nobody planned, and in the supervision spent arranging them.
How it works today
Whatever the industry, this routine is recognisable on most frontline sites.
- PersonA supervisor learns of an absence from a message or an empty position and opens the roster workbook
- PersonCalls and texts go out one at a time, from a printed list or a group chat on personal phones
- Risk of errorQualifications, hours already worked and rest position are checked afterwards, if at all
- WaitingThe shift goes to whoever was reachable first, not to whoever was eligible and cheapest
- SystemThe administrator retypes the change into the time and attendance system days later, from a handwritten note
- Risk of errorPremium and night hours reach payroll separately and are corrected next period, after the employee complains
- PersonGaps that stay open are closed with overtime or an agency call, without comparing what either costs
Why the current process costs more than it appears
The budget shows headcount, not what it is spent on.
- Calling is the visible cost and the smaller one. The expensive part is the choice made under pressure: the fourth person who answered, at a premium nobody compared.
- Whoever says yes most often becomes the person the operation depends on, and the one most likely to leave. Cover is distributed by who answers.
- Corrections travel far. A cover change that misses the time system becomes a wrong payslip, a query and an adjustment a month later.
- Compliance rests on memory. Asked how a shift was covered and on what basis, a supervisor can offer only a recollection of a call.
- Absence never becomes management information. Nobody can say which sites cover themselves, which lean on agency hours, or how much overtime was planned.
Cost of inaction
Absence does not grow, but the roster around it does. Every new site, shift pattern and seasonal peak lands on the same routine, and the routine has no capacity left. What the arithmetic cannot price is the choice itself: the person who says yes because they were the fourth call, and the colleague who was cheaper, qualified and never asked.
The other thing that accumulates is silence. Cover arranged by phone leaves nothing behind, so a question from a works council or a labour inspector is answered from memory. A company that can show, shift by shift, who was eligible and who confirmed stands somewhere quite different from one that cannot.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A logistics operator, 1,900 shift workers, six sites: three distribution centres, two cross-docks and a cold store. Microsoft 365 with Microsoft Teams on shared frontline devices, an HR system holding absences and contracts, a separate time and attendance system, payroll with an external provider.
About 1,250 cover events a month: same-day sickness, unplanned leave, medical appointments, training released late, swaps that failed. Volumes rise by roughly a third in winter.
Six local routines: a roster workbook per site, a printed contact list, group chats on personal phones, and a handwritten note that reaches the administrator days later.
Around seventeen minutes per cover event of calling, retyping and correcting, spread across the supervisor, the administrator and payroll. None of it leaves a record anyone can query.
Each absence opens a cover event. Robots build the eligible list against the rules HR configured, rank it by cost and by distance from a limit, and offer the shift to everyone eligible at once in Microsoft Teams. The first acceptance closes the offer, a supervisor confirms, and the three systems are updated together.
In the modelled case the supervisor's morning returns to the operation, cover reaches the eligible group in one pass instead of four calls, and every shift carries a record of who was asked. Illustrative, not a client result.
Proposed solution
The rule set is not ours, and that matters more than any part of the architecture. Before anything is built, HR writes down what applies to whom: daily and weekly rest, limits on consecutive and night shifts, the qualification each position requires, the premium bands. Each rule is traced to a clause of your collective agreement or to the working-time law in force at that site. We configure what HR states, version it, and interpret nothing; where a clause calls for judgement, the rule excludes the candidate and the case goes to a person.
The system proposes and a supervisor decides. Robots read the shift's requirements and build a list of eligible people, ranked by the cost band each would trigger and by how far each sits from a limit. Beside it sits the excluded list, with the rule and the reason for every name, which is what makes the proposal auditable rather than opaque. The supervisor widens the offer, picks another name, or confirms whoever accepted.
People meet the process in Microsoft Teams. The open shift appears in Teams Shifts and the offer arrives as an Adaptive Card showing site, times, position and premium band. It runs as a first-to-respond approval, so the first acceptance closes it. On confirmation, one transaction updates the roster, the time and attendance record and the payroll input, with the rule trail attached.
Microsoft Teams Shifts with open shifts and open-shift requests; Microsoft Graph Shifts APIs and change notifications; Power Automate first-to-respond approvals with Adaptive Cards in Microsoft Teams; Microsoft Teams Approvals app; UiPath Orchestrator queues, triggers, credential stores and audit; Power BI in Teams
The cover event model, the eligibility engine over the rule set HR configures, candidate ranking and exclusion reasons, the offer and escalation windows, the write-back to roster, time and payroll, the reporting model and the supervisor runbook
The absence and contract feed from your HR system and the write-back to time and attendance by API, or UI automation where none exists; the qualification register that says who may work which position; the payroll input in your provider's format
How the automated process works
- AutomationAn absence in the HR system, or a supervisor's entry on a shared device, opens a cover event carrying site, shift, position and required qualification
- SystemRobots build the eligible list: qualification, contracted availability, hours and rest position under the configured rules, plus each candidate's cost band
- AutomationThe shift is published as an open shift in Microsoft Teams Shifts and as an Adaptive Card to the eligible group
- AutomationThe first acceptance closes the offer; later responders see the shift is taken
- PersonThe supervisor confirms the person and settles what the rules flagged: restricted duties, a premium above the band, a name they prefer
- AutomationRoster, time and attendance record and payroll input are updated together, carrying the event reference and the rules applied
- AutomationIf nobody accepts inside the window, the event escalates to the shift manager with the shortlist, the agency option and each cost
- AutomationFill rate, time to fill, premium share and agency hours flow into a Power BI model read inside Teams
Human-in-the-loop model
Automation handles
- Turning every recorded absence into a cover event with the shift's requirements attached
- Building the eligible and excluded lists, and recording which rule excluded whom
- Publishing the offer, closing it on the first acceptance, running the escalation window
- Writing the confirmed change to roster, time system and payroll input with the evidence
People decide
- The supervisor confirms who takes the shift; the ranked list is a proposal, never a decision
- HR owns the rule set: which clause applies to which group, and what the system may offer
- What happens when nobody eligible accepts: a premium, the agency, or running short
- Exceptions no rule can settle: restricted duties, a pending clearance, an employee on notice
Before and after
Systems and integrations
Where a rule suffices we do not use a model. Where judgement is needed, a person decides.
Inputs
- absences and leave from the HR system
- the published roster
- the qualification register
- contracted hours and availability
- clock records from time and attendance
- agency framework rates
Automation layer
- UiPath Orchestrator
- UiPath Robots
- Power Automate
- Microsoft Graph
Target systems
- the roster in Microsoft Teams Shifts or your workforce management system
- the time and attendance system
- the payroll input
- the Power BI model
Human touchpoints: the open shift and offer card in Microsoft Teams; supervisor confirmation in Teams; escalation to the shift manager with the shortlist
Technologies used
where frontline staff see and accept an open shift
Apublishes open shifts and reads acceptances back into the roster
Asends the offer card, runs the first-to-respond approval, drives the escalation window
Aqueue each cover event, evaluate the rules, write back to source systems, retry and log
Asupervisor confirmation of the person and of any premium above the band
Afill rate, time to fill, premium and agency cost by site and week
Asource of absences, contracts and hours; target of the confirmed change
CIllustrative economic model
Start by questioning the assumptions.
Two things sit deliberately outside this model: the overtime premium itself and the agency hours, because both depend on your agreement and would flatter the arithmetic. What is priced is coordination, seventeen minutes per cover event across the supervisor who calls, the administrator who retypes and the payroll clerk who corrects, at €25 fully loaded. Nothing was measured at a client; all three inputs are yours to replace.
Run the numbers on your data
An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.
Business benefits
- Shifts are filled from people who are genuinely eligible, so nobody discovers an unqualified choice after the shift has run
- The morning that went on phone calls returns to the operation; cover is arranged while the supervisor works
- Offers reach everyone eligible at once, so a shift goes to the first person willing rather than the fourth person reachable
- Employees see site, hours and premium before accepting, and stop being called on rest days
- Roster, clock and payroll input carry the same version of the change, so next period's correction does not happen
- Cover cost is visible before it is committed, so expensive options are chosen deliberately or not at all
The management view
- Cover becomes a measured process instead of six local habits: fill rate, time to fill, cost per covered shift
- Premium and agency spend can be steered, because the data shows which sites reach for the expensive option and when
- Every decision leaves a record: who was eligible, who was excluded and on which rule, who accepted, who confirmed
- The routine outlives the supervisor who invented it, which matters most where turnover is highest
Board-level KPIs
Security and governance
Where the data sits and who can see it.
- Robots sign in with their own accounts, scoped to the absence, roster and payroll operations they need; no supervisor shares a login with an automation
- Absence reasons stay out of the offer: a candidate sees a shift that needs covering, never who is ill or why
- Secrets live in the credential store behind Orchestrator, and every job, rule evaluation and write-back is logged with a timestamp and an identity
- The cover conversation moves off personal phones and into Teams, where employee data stays in your Microsoft 365 tenant and the automation behind it works from the EU region of UiPath Automation Cloud
- The rule set is versioned like code: each change names the clause, the author and the date, and every event keeps the version that produced it
Why now
Frontline labour is the cost line under most pressure, and cover is where it is spent least deliberately: premium hours go to whoever answers, not to whoever is eligible and cheapest. The modelled €8,854 a month of coordination sits on top.
Minimum daily and weekly rest are a European floor set by Directive 2003/88/EC, while derogations and reference periods are left to national law and collective agreements. What binds a given site is your own agreement, which is why the rule set is configured with HR rather than inherited.
Microsoft Teams Shifts, the Microsoft Graph Shifts APIs and first-to-respond approvals are standard parts of Microsoft 365 that frontline staff already carry, so what used to be a project is now configuration.
Relevant executive roles
Shifts are covered the same morning, and six sites stop competing by telephone for the few people who always say yes
The rules HR wrote are the rules that run, and every cover decision can be shown to a works council or an inspector
Premium and agency hours become a steered cost with a visible cause, not a line that explains itself at month end
Roster changes stop travelling through personal phones and private spreadsheets and start moving between systems with accounts and logs
Common questions and objections
Then it gets written down, clause by clause, before anything is built. HR states which clause applies to which group; we configure that, version it and prove each rule against real historical cases. Where a clause needs judgement, the rule excludes the candidate and sends the case to a person.
Acceptance depends on whether the offer is worth taking, which is why the card carries the site, the hours and the premium band before anyone commits. If nobody accepts inside the window, the event escalates with the shortlist and its costs.
Then most of this sits on top of it. Where that system is UKG Pro Workforce Management or Reflexis WFM, Microsoft Teams Shifts connects to it natively; otherwise the roster syncs through the Microsoft Graph Shifts APIs. We add the eligibility check, the offer and the write-back.
When this is not the right solution
- Sites with a few dozen cover events a month, where a supervisor who knows every name and permit is faster than any rule engine
- No reliable record of qualifications or contracted hours; the eligible list is only as good as the data behind it, so that register comes first
- Rosters still built and changed only on paper, with no system to write back to; digitising the roster is the prior step
A question for the next management meeting
Could we produce, for any shift covered last month, the people the rules made eligible, the reason each excluded name was excluded, and who confirmed the choice?
Implementation approach
We start with one slice of the process and extend only once it is proven.
We deliver
- Analysis of two sites' cover history: volumes, patterns, who covered, how long it took, what it cost
- The rule set built as versioned, testable conditions from the clauses HR supplies, with a reason behind every exclusion
- Candidate ranking by cost band and distance from a limit, agreed with operations before go-live
- The Teams flow: open shift, offer card, first-to-respond acceptance, supervisor confirmation, escalation
- Write-back to roster, time and attendance and payroll input, with reconciliation and the Power BI model
We need from you
- Three months of absence, roster and cover history, and the premium rules that were applied
- The clauses HR wants configured, plus the position-to-qualification matrix
- Technical accounts for the HR, time and roster systems, and a process owner in operations
Stages
Discovery
Cover history from two sites, the rule sources HR names, and how each system can be reached
Rule configuration
HR states the clauses; we build them as versioned conditions and prove each on real cases
Build
Cover events, ranking, the Teams offer and escalation, the write-back to roster, time and payroll
Validation
Rules replayed against last quarter's cover events, reviewed with HR and employee representatives
Go-live
One site and one shift pattern with the phone as fallback, then the remaining sites and hypercare
Departmental. Effort is driven by the number of rule variants across sites and agreements, the quality of qualification and contracted-hours data, and whether the HR and time systems offer an API.
Two sick calls before the shift starts, and one phone list taped inside a cupboard door.
Send us one month of absence and cover records from two sites: what was covered, by whom, how long it took and what it cost. We come back with the eligibility rules that would have applied and an hour to walk through the exclusions they produced.
Test the rules on one month of coverThe neighbouring process usually has the same problem
Payroll errors are found by the employee on payday, not by the team that built the file.
View solution HR & peopleQualifications and training tracked before they expireYour training register is only as current as the last time someone remembered to update it.
View solution HR & peopleEvery application answered, every interview bookedApplications wait days for an answer while recruiters match a panel's calendars by email.
View solution Operations & qualityPreventive maintenance that runs to planStop releasing work orders by printer and typing the completion reports back a week later.
View solution Case studyEmployee data mass updateHundreds of data changes done quickly, safely and error-free.
View case study Case studyDriver settlementNo more manual document collection and spreadsheets.
View case studyIndustries we deliver this in most oftenManufacturing & industryTransport & logisticsRetail & e‑commercePublic sector