Staffing agency software that knows who is allowed to work the shift
Client bookings, shift posting, worker matching, right-to-work and document checks, check-in, pay and client paperwork in one system, with the rules that decide who may work a shift held in the database rather than in somebody's head.
Staffing agency software is the system that takes a client's booking, turns it into shifts, finds workers who are allowed and available to fill them, records when they arrived and left, and turns those hours into pay for the worker and an invoice for the client. For most agencies the right first move is an off-the-shelf staffing or shift-booking product. Custom staffing software is worth building when your rules are the hard part: visa hour limits, travel gaps between venues, client-specific approved lists, and a client who must never see what a worker is paid. That is where products bend and spreadsheets break.
Our evidence is one build. For a UK event-staffing agency that runs many events a day in season from a large pool of zero-hours workers, we built recruitment, right-to-work, rostering, check-in, pay and client paperwork as three front ends over one Postgres database: a back-office portal, an installable staff app and a read-only client portal. It is live with the agency's office, its workers and the hotels and venues it supplies, and before go-live it was audited for about 1,000 workers and 10 to 15 events a day. Where this page describes something that build does not, it says it is the design we would use.
Beyond that published case study, we have built CRM, ERP and project-management systems for hospitality and events businesses. Those are not written up here, so this page names no clients and gives no figures for them.
Five questions every shift has to answer, at volume, every day
Each is easy to state and easy to get wrong when there are hundreds of shifts a week. Event staffing software earns its keep by answering them the same way every time.
Is this person allowed to work?
Right to work checked and recorded before the first shift, documents in date, any role-specific requirement met, and nobody on the client's do-not-return list. On the staffing platform the right-to-work result is a hard stop: a worker without it cannot be assigned, and a database test fails the build if that ever stops being true.
Have they hit their hours?
A weekly cap that depends on the person: term time against holidays for students on a visa, a completion-letter date that changes the limit, and whether they have opted out of the 48-hour average. On the staffing platform the cap is calculated on demand rather than stored as a number that can go stale.
Can they get there in time?
Two shifts on the same day at different venues are not a double booking until they are too close together. The staffing platform's matcher requires a two-hour gap between venues before it will put one person on both.
What are they owed?
Not the booked hours. On the staffing platform pay is the overlap of check-in to check-out with the booked shift, with a grace period, a minimum paid length and unpaid breaks taken off. The rule is written in TypeScript and in SQL and both are held to the same test vectors, so they cannot drift.
What does the client see, and pay?
The client sees who is coming, when, and the paperwork for the event. It never sees what the worker is paid or anything personal about them. That is a database rule on the staffing platform, proved on every merge, and it is the subject of the panel further down this page.
The records an agency's system is built on, and the rule each one carries
Get these right and the screens are straightforward. Get them wrong and every screen has to compensate.
| Record | What it holds | The rule that lives on it |
|---|---|---|
| Client and venue | The business that books, and each venue it books for, with contacts, site notes and its own approved and blocked workers | Workers qualified for that client are considered before anyone else, and a do-not-return entry is absolute |
| Booking (event) | One client request: date, venue, times, roles and headcount, and the charge rates agreed for it | Moves through states such as requested, confirmed, staffed and completed, and cannot skip one |
| Shift and role requirement | A slot to fill: role, start and end, break, and any language, gender or qualification requirement the booking carries | A requirement is a filter applied before any scoring, never a preference |
| Worker | Identity, contact, documents, right-to-work result, visa conditions, opt-out status, ratings and show-up history | Personal fields are readable by office staff with a reason, never by a client |
| Compliance document | Each document with its type, expiry and who verified it, plus the stored check result and photograph | An expired or unverified document blocks assignment; software can propose a date, only a person verifies |
| Assignment | A worker on a shift, with how they were chosen and who confirmed it | No overlap, and no second venue inside the travel gap |
| Check-in and check-out | When the worker actually arrived and left, and who recorded or corrected it | Corrections are recorded with the person and the reason, not overwritten |
| Pay line and charge line | What the worker is owed and what the client is billed for the same hours, kept as separate records | Computed from the times and the rules, not typed in; the charge line never exposes the pay line |
Matching workers to shifts: hard gates first, then a score
Shift booking software for agencies usually gets judged on its auto-fill. What decides whether auto-fill can be trusted is the order it does things in.
- 01
Hard gates remove anyone who may not work it
On the staffing platform, filling an event first applies the gates: role, any language or gender requirement, blocked workers, double bookings including the two-hour gap between venues, the weekly hours cap and do-not-return lists. Nobody who fails a gate is scored, so no weighting can promote an ineligible worker to the top of a list.
- 02
Client-qualified workers go first, by design
Workers already qualified for that client are exhausted before anyone else is considered. That is an ordering, not a weight. A weight can be outvoted by a high enough rating elsewhere; an ordering cannot, which is what a client who has trained or approved specific people expects.
- 03
Then a score, with weights the office can change
Whoever is left is scored on show-up rate, rating, proximity, fair rotation and venue history, with the weights editable in settings rather than in code. Fair rotation matters more than it looks: without it, the same reliable people get every shift and the rest of the pool drifts away.
- 04
Posting shifts to workers who could take them
A shift offered to the pool should only reach people who pass the gates, so nobody accepts a shift the system will then refuse. On the staffing platform, notifications go through an outbox with unique keys and row locking, so a retry never sends the same offer twice. Email and push there wait on the client's keys and sender domain.
- 05
Deadlines that survive the clocks changing
Agencies run on cut-offs, such as confirming tomorrow's shifts by a set time. On the staffing platform the 12:05 cut-off is a row in a schedule table, run by pg_cron in UTC and gated on UK time inside the function, so it fires at the right local time on both sides of a daylight-saving change.
Right-to-work checks and compliance documents: the software proposes, a person verifies
This is the part where staffing software has to be most careful about what it claims to do. In the UK, the Home Office's employer's guide to right to work checks says the check must be completed before employment starts. Where a temporary worker is supplied by an employment business, the guide treats the employment business as the employer and makes it responsible for the check. Technology can support the check, but the guide is explicit that responsibility stays with the employer, and that the Home Office does not endorse technology for online checks. The illegal-working code of practice sets civil penalty starting points of £45,000 per illegal worker for a first breach and £60,000 for a repeat breach, before reductions.
So the software's job is to make the check easy to do properly and impossible to skip, not to do it on the agency's behalf. On the staffing platform:
- The Home Office online check is driven by a headless browser that stores the result and the photograph. It never marks anyone verified: an administrator compares the photograph with the worker's selfie and presses Verify or Reject.
- Document reading by a language model pre-fills dates with a confidence score, flags doubtful reads, never overwrites what the worker typed and never verifies.
- Both are built and switched off until the client has signed off the legal and data-processing position.
- Without a verified right-to-work result, a worker cannot be assigned. That hard stop is enforced in the database and has a test that fails the build.
Other rules feed the hours cap rather than the check. Home Office guidance limits Student visa holders on full-time degree-level courses to 20 hours of work a week in term time, and 10 below degree level. Working time guidance sets a 48-hour average week, normally averaged over 17 weeks, which a worker can opt out of voluntarily and in writing. The staffing platform's cap takes term time, student-visa limits, a completion-letter date and the 48-hour opt-out into account, and calculates the result when it is needed.
If you are not in the UK, the pattern holds and the rules do not. In the US, for example, employers complete Form I-9 to verify identity and employment authorisation for each person they hire. We would build the same separation there: software collects, stores and reminds, and a named person makes the decision.
From check-in to payroll and the client invoice, without retyping hours
The hours a worker actually worked are the one number both sides of the business depend on. Payroll needs them to pay the worker; the client invoice needs them to bill the client. If they are typed twice, they will disagree, and the person who finds out is usually a worker whose pay is short.
On the staffing platform the hours come from check-in and check-out against the booked shift, with a grace period, a minimum paid length and unpaid breaks removed. Pay is computed, never stored as a typed figure, and the same rules exist in TypeScript and SQL, tested against shared vectors. The write-up does not describe location-checked clock-in, so we do not claim it.
From there, two outputs. These are the design we would use; the case study mentions a payroll CSV but not an export in a payroll provider's format, and it does not describe invoices posted to an accounting package:
- A payroll export per pay period in the format your payroll provider imports, with every line traceable back to a check-in and check-out and any correction a person made.
- Charge lines for the same hours at the client's agreed rates, handed to client invoicing. Rate cards, PO numbers and the finance hand-off are covered on our hospitality CRM page; the rule that matters here is that invoice and payroll read the same hours.
- A lock on a pay period once it has been exported. A late correction becomes an adjustment in the next period, not a silent edit to one already paid.
Pay rules for zero-hours and agency workers are not static, which is another reason to hold them as data. Government guidance says that for irregular-hours workers, in leave years starting on or after 1 April 2024, holiday accrues at 12.07% of hours worked in each pay period, and holiday pay may be rolled up into the hourly rate. Agency workers become entitled to the same basic pay and conditions as the hirer's own staff after 12 calendar weeks in the same role with the same hirer, which means counting weeks per worker per client. The government has also consulted on applying its zero-hours contract measures to agency workers. None of these is described in the staffing platform's write-up; they are what we would scope with your accountant and adviser.
Worker pay and personal data never reach the client, and the build proves it on every merge
Hospitality staffing software has three audiences: office staff, workers on their phones, and the hotels and venues that hire them. The third must never see what a worker is paid or anything personal about them. Most systems enforce that by hiding fields on a screen. A screen is the weakest place to enforce it, because the next feature, report or export does not know the rule exists.
On the staffing platform, the client role has no table policy at all. It reads only through views that filter themselves to what that client is entitled to see. A test pins the exact set of policies, views and privileged functions, so adding one without review fails the build, and a second check fails if an app writes to an admin-only table directly. The client cannot see pay because the database will not return it, not because a page leaves it out.
The same principle runs through the rest of the build: the hours cap, the right-to-work hard stop and the state machines are checked in the database, with thousands of database assertions in continuous integration. That is what lets three front ends share one database without any of them being able to let a rule through.
Where staffing systems fail, and the guard against each
Each of these is a way an agency's system goes quietly wrong. The first five come from the staffing platform's build; the last is the design we would add.
A rule that lives in one screen
The office app checks the hours cap; the staff app's accept button does not. Rules enforced only in an interface are bypassed by the next interface. On the staffing platform, business rules are Postgres functions, triggers and policies, and state transitions are enforced in code and again by a trigger that rejects illegal moves.
A stored number that goes stale
Hours this week, kept as a field and updated by whatever remembers to update it, will eventually be wrong. On the staffing platform the cap and pay are computed when needed, from the shifts and the rules, so there is nothing to drift.
Notifications sent twice, or not at all
A retry after a timeout sends the same shift offer twice, or a missing key makes a send fail silently. On the staffing platform notifications go through an outbox with unique keys and row locking, copy lives in a register as data, and anything not yet configured waits in the queue rather than failing quietly.
Scheduled jobs that fail the same way every night
In testing, every scheduled job on the staffing platform returned 401 because the key stored in the vault and the key the function held differed byte for byte while both were valid. The fix was to confirm the key with Supabase Auth instead of comparing strings, and a test now pins it.
An erasure request that gets lost
Removing a worker has to keep the history and paperwork already issued while deleting what should go. On the staffing platform removal anonymises the worker, keeps the issued paperwork and queues storage deletion, so an erasure request is never dropped.
The no-show at seven in the evening
Design, not in the write-up: a worker cancels or fails to check in shortly before a shift. The guard is a late-cancellation state that reopens the slot to the next eligible workers through the same gates, and an alert to whoever is on call, with show-up rate updated so the matcher learns from it.
Where the workforce system meets the CRM side of an events business
An event staffing agency is also a sales business: an enquiry from a hotel, venue or event organiser becomes a quote, a confirmed booking and an invoice. That client side (accounts, venues, rate cards, event and PO numbers, the client portal, feedback and the hand-off to finance) is covered on our hospitality CRM page. This page owns the workforce side. The point where the two meet is the one that matters here: a confirmed booking should create the shifts, carrying date, times, roles, headcount and requirements across, because retyping a booking into a rota is where headcounts and times first go wrong.
We have built CRM and project-management systems for hospitality and events businesses beyond the case study on this page; they are not published, so we give no detail. Separately, our Make automation for a regional workforce-development programme keeps event registrations on their trackers exactly once in monday.com. It is not a staffing build, but it is the same problem of event-time volume landing on records that must not duplicate.
Off-the-shelf staffing software or custom: decide on your rules, not your features
There is a whole category of staffing and shift-booking products for agencies, with worker apps, availability, timesheets and invoicing. Start there. This table is for checking whether you are one of the agencies they do not fit.
| If your agency | Usually | Why |
|---|---|---|
| Supplies standard roles to many clients on standard terms | Buy | The products are built for exactly this, and a build would reproduce their features at a higher cost |
| Has a few hundred shifts a month and one office | Buy, or a configured tool such as Airtable or monday.com | The rules fit in a person's head and a product's settings; the system will not repay a build |
| Places students on visas, or workers with individual hour limits | Test the product hard first | Ask how it computes a cap that changes with term dates and opt-outs, and whether it blocks the assignment or only warns |
| Has clients with their own approved lists, travel gaps between venues, or do-not-return rules | Build, or extend a product with an API | These are orderings and hard gates; products tend to offer them as tags and filters a person must remember to apply |
| Must give clients a portal that can never show pay or personal data | Build, unless a product can prove it | Ask the vendor how the restriction is enforced. A hidden column and a database that will not return the data are different promises |
| Has outgrown a product and is running the exceptions in spreadsheets | Build the part the product cannot do | Often the right answer is a matcher, a compliance layer or a client portal beside the product, not a replacement for all of it |
A build also means owning the rules when they change. With a product, the vendor updates for new guidance; with custom staffing software, someone has to. That is why rules such as caps, cut-offs and visa limits belong in data the office can edit, with tests that fail if the code and the rule disagree.
What we cannot show you yet, and what a build costs
The staffing platform is live, but it is new and has not yet run a full season. Before go-live it was audited for about 1,000 workers and 10 to 15 events a day; that is the capacity it was tested for, not traffic it has served, and we make no claim about time saved or shifts filled. What we can show is the part that is hardest to retrofit: rules enforced below the interface, a test suite that fails the build when one breaks, and a list of the client's remaining decisions and inputs that is documented rather than hidden in the code.
Most of our projects land between $5,000 and $10,000 (US dollars); larger systems cost more; that is a typical range, not a quote. A platform covering everything on this page is at the larger end. A single piece, such as a matcher in front of an existing product or a client portal, can sit inside the typical range. What moves the number is how many audiences need their own front end, how many rules are conditional on the person or the client, whether payroll and invoicing have to be connected, and how much history has to come across from the current system.
Where it has shipped
The disciplines behind it
Platforms that bear on it
Related reading
Neighbouring solutions
Staffing agency software, specifically
The system an agency runs on: client bookings, shifts, a worker pool with availability and documents, matching workers to shifts, right-to-work and compliance records, check-in and check-out, and the hours turned into pay for the worker and an invoice for the client. Event staffing software is the same thing tuned for short, many-venue bookings and a large pool of casual workers.
Buy first if a product handles your rules. Build, or build beside a product, when the hard part is rules a product treats as tags: visa hour limits that change with term dates, client approved lists that must be exhausted first, travel gaps between venues, or a client portal that must never return pay. We will say which side you are on in the first conversation.
It can make them easy to do properly and impossible to skip, but in the UK the Home Office guidance is clear that responsibility for the check stays with the employer, and for supplied temporary workers that is the agency. On the staffing platform we built, an automated online check stores the result and photograph, and an administrator decides Verify or Reject. Check the current employer's guide and your own adviser before relying on any process.
In two stages. Hard gates remove anyone who may not work it: role, language or gender requirement, blocked workers, double bookings and travel gaps, the weekly hours cap and do-not-return lists. Then the remaining workers are scored on things like show-up rate, rating, proximity, fair rotation and venue history, with weights the office can change. Client-qualified workers are considered first as an ordering, not a weight.
As a hard gate on assignment, calculated when it is needed rather than stored. On the staffing platform the weekly cap takes term time, student-visa limits, a completion-letter date and the 48-hour opt-out into account, and the same rule exists in TypeScript and SQL against shared test vectors. The limits themselves come from current Home Office and working-time guidance, which your adviser should confirm.
In the database, not the screen. On the staffing platform the client role has no direct table access and reads only through views filtered to what that client may see, and a test fails the build if anyone adds a policy, view or function without review. The client-facing portal itself is covered on our hospitality CRM page.
That is the point of recording check-in and check-out against the booked shift: one set of hours drives both. The staffing platform computes pay from those times with grace periods, minimum lengths and unpaid breaks. The case study mentions a payroll CSV; an export in your payroll provider's format and invoices posted to an accounting package are the design we would add, and the case study does not describe them.
Yes. It is live with the agency's office, its workers and the hotels and venues it supplies. Before go-live, six read-only audits were run against the live project, sized for about 1,000 workers and 10 to 15 events a day; those figures are the capacity it was tested for, not traffic it has served. We make no claims about usage or time saved.
Most of our projects land between $5,000 and $10,000 (US dollars); larger systems cost more; that is a typical range, not a quote. A full platform with office, worker and client front ends is at the larger end. A single piece, such as a matcher or a client portal beside an existing product, can sit within the typical range.
Sources
Statements about what a platform, regulator or provider says come from their own pages. Rules and limits change, so check the current page before you rely on one.
- Employer's guide to right to work checks · Home Office (GOV.UK)
- Code of practice on preventing illegal working: Right to Work Scheme for employers, 13 February 2024 · Home Office (GOV.UK)
- Student and Child Student (caseworker guidance) · Home Office (GOV.UK)
- Maximum weekly working hours · GOV.UK
- Holiday pay and entitlement reforms from 1 January 2024 · Department for Business and Trade (GOV.UK)
- Your rights as an agency worker: equal treatment · GOV.UK
- Consultation on the application of zero-hours contracts measures to agency workers · Department for Business and Trade (GOV.UK)
- I-9, Employment Eligibility Verification · U.S. Citizenship and Immigration Services
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Tell us about the process that keeps costing you.
A 15-minute call is usually enough to say whether this is an automation, an integration, or something that should be built, and whether we are the right people for it.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no