The first agent a staffing firm builds is rarely lost to bad engineering. It is lost in the scoping meeting, where "automate the timesheet chase" turns into a system that approves hours, talks to clients unsupervised, and needs a project manager to run it. This is the scoping method we use, with the timesheet and compliance chase as the worked example because nearly every firm has one and nearly every one is run from a spreadsheet by a person who cannot take a Friday off.
Step one: describe the chase as it actually happens
Sit with the coordinator on a Monday morning and write down what they do, in order, for one pay cycle. It usually looks like this:
- Export the list of contractors expected to submit hours
- Compare it with what has actually been submitted
- Email or text the ones who have not, using a template they have personalized over years
- Chase client approvers for hours that are submitted but unapproved
- Check a separate list for credentials expiring in the next 30 days
- Check the onboarding tracker for new starts blocked on a background check or an I-9
- Escalate a handful to an account manager, usually by walking over
- Update the spreadsheet
Note the systems: the timesheet tool, the ATS, the credentialing spreadsheet, the onboarding vendor's portal, email, SMS, and the coordinator's memory. The agent is going to have to read from most of them and write to at least one.
Step two: count, do not estimate
Three numbers set the payback and they are all countable from last quarter's data:
- Contractor-weeks a month that miss the first submission deadline. This is the volume of the chase.
- Hours per week the coordinator spends on it. Ask them to track it for two weeks; it is always more than they guess.
- Cost of the misses: invoices delayed past terms, starts pushed by a week, credentials that lapsed and took a contractor off a shift.
The third number is the one owners react to. A single delayed start on a high-margin placement often exceeds the coordinator's monthly time cost.
Step three: draw the boundary
This is the step that decides whether the agent works. For each action in the chase, decide: does the agent do it, draft it, or leave it alone?
The agent does: read every system, compute what is outstanding, run reminder sequences that a human wrote and approved, escalate on schedule with the history attached, produce the daily exceptions list, and log every contact.
The agent drafts: anything unusual. A message to a client approver who has complained about tone before. A reminder to a contractor who is also mid-dispute about a rate.
The agent never: approves hours, changes a rate, marks a credential valid, or decides that a start can proceed. These are the coordinator's judgment and, often, the firm's legal exposure. Leaving them with a person is not a limitation of the technology; it is the design.
Write the boundary down as a one-page table and have the coordinator, the owner and the engineer sign it. Every scope argument later comes back to this page.
Step four: specify the rules, not the intelligence
The temptation is to describe the agent as "smart enough to know who to chase." Resist it. Specify:
- Deadlines per client and per pay cycle, and where they are stored
- The reminder sequence: channel, timing, tone escalation, quiet hours, and per-client etiquette ("never text this client's managers")
- Escalation triggers: after how many unanswered reminders, to whom, with what attached
- Expiry windows for each credential type, and who owns each
- What "blocked" means for an onboarding start, and what the exceptions list should show
Where a model helps is in reading messy inputs, such as a contractor replying "sent it Friday, portal was down," and deciding whether that closes the item or needs a human. Where rules help is everywhere else. An agent that is mostly rules with a model at the edges is predictable, cheap to run, and easy to explain to a client.
Step five: define done, then define paid back
"Done" should be observable in a week of parallel running: the agent's exceptions list matches the coordinator's spreadsheet, every reminder it would have sent is one the coordinator would have sent, and escalations arrive with the right history. Only then does it send anything itself.
"Paid back" is the three numbers from step two, re-measured after two pay cycles. If first-deadline misses and delayed invoices have not moved, something in the boundary or the rules is wrong, and that is worth knowing before you sink more hours into it.
The mistakes we see most
Starting with the hardest workflow. Screening is more interesting than chasing timesheets and carries far more regulatory weight. Build the boring one first; it pays back faster and teaches the firm how to work with an agent.
Letting the agent own the data. The agent should read from the timesheet system and the ATS, not become a fourth place where the truth lives. If it needs a field that does not exist, add the field to the system of record.
No named human. Every escalation needs a person's name on it. "The system will handle it" is how a lapsed credential ends up on a shift.
Skipping the parallel run. Two weeks of the agent shadowing the coordinator finds the client with the unusual pay cycle and the contractor who only answers SMS. Skipping it moves those discoveries to the day a pay run is late.
Scoped this way, a chase agent is a few weeks of build with a payback the owner can check on a calendar. Scoped as "automate the back office," it is a six-month project nobody finishes. If you want a second opinion on your own boundary table, that is what the first week of a workflow assessment is for, and the finished version of this agent is described on the Timesheet and Compliance Chaser page.