Tempo

Before a first shift, the agency has to check the worker's identity, right to work and tickets, which expire. On the day, somebody needs to know they arrived, and at the end of the week the hours have to be agreed before anyone is paid. Each of those lives somewhere different: a scan in an inbox, a consultant's phone, a timesheet that turns up on a Friday.

Tempo puts all of it on one record that the worker, the agency and the client all read. The worker's side has to be quick and forgiving, because it is used in a car park at seven in the morning. The agency's side has to be dense and exact, because that is where money and compliance get decided.

That experience set the direction, but one agency's habits are not a whole industry. So we ran several interview sessions with other people in recruitment, agency owners and the consultants who place temporary workers every week, to understand what they needed, what they wanted, and most of all where the work hurts.

The candidate app, the agency portal, the client side and Tempo's operations team are views of the same bookings, documents and hours. A field left off the candidate's onboarding is a column the agency can never fill, and a status the agency can set is a state the candidate's phone has to show. So the first deliverable was a dependency map, not a screen.

Take documents. A candidate uploads a passport on the phone and the agency reviews it in the portal. Candidates can belong to several agencies, so the reviewer is warned when another agency has already rejected the same document.

For the candidate app I wrote every screen, field, popup and error out as user stories before drawing any of it. Nearly every empty state and failure screen in the file exists because a story asked what happens when this goes wrong.

The agency portal was broken into epics instead, which caught things the requirements never spelled out, like several consultants on one agency account with different roles. Rules that could not be drawn went onto the canvas as notes for engineering, such as “Should auto check in candidate if network fails.”

An upcoming job shows the site, the time and a countdown, and the check-in button only appears a few minutes before the start, so it cannot be pressed from the sofa. During a shift the card shows the hours worked and a check-out. Compliance breaks in above everything: a passport expiring in three days can wait, but an expired one blocks the job until it is updated.

Location confirms the worker is on site and, where the job asks for it, a selfie confirms it is the right person. A pass lands them on that day's timesheet.

Sites do not always have signal. If the network fails, the worker is checked in anyway and the day is marked as filled in by the system, so nobody loses a morning's pay to a dead spot and the agency can see how the time was recorded.

The form covers schedule, pay with a margin calculator, compliance requirements, and whether the job refills itself if somebody drops out. While you write it, it shows how much of your candidate pool is already booked, so you know before posting whether you can fill it. Applicants arrive with their re-hire rating and non-attendance record.

Cancellation started out as something that happened to a whole booking. That breaks the first time a worker booked for a month misses a Tuesday: cancelling the booking punishes a day with a month, and ignoring it leaves the client with a gap. So a booking became a set of days, and attendance, absence and replacement happen to a day while the booking carries on.

For the last two, the worker has twelve hours to give a reason and fifty-six days to add evidence, and the agency only rules once that window closes. It is deliberately slow, because the result follows a worker onto every job page an agency opens. Reinstating a worker never rewrites the day they missed.

What I would keep from Tempo is the order of work: the dependency map before the candidate app, the stories before the screens, the epics before the portal. Most questions got asked on paper, where they were cheap to answer.

An operational product earns trust by being plain. The screens I would point to are a timesheet row that says where its hours came from, and an attendance decision that cannot be made too early. Those are the ones people argue about.

The screens on this page are 4x exports of the working Figma file. Names, agencies, clients and sites in them are placeholder data.