The product roadmap for staffing companies in the age of agents

There’s a conversation many of us in staffing, from CIOs to operators, have been having for months now: building software has never been easier. And that leaves us with a question we are all wrestling with: what should actually be on the roadmap?

More staffing firms are writing their own software this year than at any point I can remember, and I think they are right to. This is the era of flexible software. You can build something shaped around how your company actually runs, instead of bending your operation around a vendor's idea of how it should run. That is a real gain.

The awkward part is what arrived alongside it.

Software got easier to build. And less valuable to own.

Software used to be slow and expensive to build, which is why building it counted as strategy. You shipped a candidate portal in 2019 and you had two or three years of lead on the firms that did not.

That clock has shortened. The feature your team is scoping this quarter is the one your ATS vendor demos at the next conference, as a checkbox, in the seat price. Your competitor never builds it. They subscribe to it.

“

The same technology that made software cheap for us to build made it cheap for everyone else to buy. What we can build, someone else can subscribe to.

So build the portal. Build the internal tools. Book them as maintenance rather than competitive advantage, and keep your best engineers off them.

So what is worth building?

A staffing leader put that question to me directly a few weeks ago: in the era of agents, what is actually worth putting on the roadmap if we want to build a lasting competitive advantage?

What I told her was that I don’t think the answer is another feature. I think there is something much bigger happening here, something that could actually change what our businesses are. And strangely, I don’t see it on many roadmaps yet.

I initially called it a once-in-a-decade opportunity. The more I think about it, the more I wonder whether even that undersells it.

We are not really in the staffing business

Think about what a temporary staffing company really does.

A client needs work done. We find someone who can do it, place them into the client’s operation, and take a share of the hourly rate. That person plugs in and performs the service.

Most successful staffing companies have become very good at doing this within a narrow domain. We tend to specialise: one role, one credential type, one setting, sold to the same group of clients again and again.

And when you look at it that way, we are already sitting on something rather interesting: standing demand for a particular kind of work, from clients who have already decided to buy that work from us.

Read that again with the word "staff" removed. You own the demand for the work.

The client never wanted the person. They wanted the chart transcribed, the shift covered, the file cleared, the claim processed. There was work that needed doing, and the person was simply the only delivery mechanism available.

That stopped being true about eighteen months ago. This is the once in a century part, and it is open to you before it is open to anyone else.

The reframe is simple, but it changes how we think about the business. You are not in the business of supplying temporary staff. You are in the business of delivering the service that staff performs, and you can now deliver it with agents. Same clients, same work, same hard-won knowledge, different delivery mechanism. For a firm with real volume in a niche, that difference is measured in millions.

You already own the two hard parts

Every startup selling agents is missing what you have.

They have to buy demand. You have signed contracts and clients who send you the same work every month.

They have to learn the work. You have done it ten thousand times. You know the exceptions, the edge cases, when something that technically meets the requirement still gets rejected, and when someone should stop trusting the system and pick up the phone. None of that is in your process documentation. It lives in your escalation logs and in the heads of your best people, which is exactly why nobody has copied it.

The missing piece is the agents. That is the smallest piece, and the one you can build or buy this year.

“

A copilot makes your best person faster. An agent makes your median file look like your best one.

Take transcription

You place transcriptionists into clinics and earn a spread on their hours. That business is capped by how many people you can recruit, and the spread thins a little every year.

Now suppose an agent does most of the transcription and a human reviews the exceptions. You are no longer supplying labor. You are delivering finished charts, and you are accountable for them, which is a heavier promise and a much better business. Your cost per chart falls as the system learns. Your revenue stops being a function of how many people you can hire.

Credentialing works the same way, which is why we started there. What "complete" means is not a matter of taste. The client's requirement list says it, the accrediting body says it, and the state board either confirms the license or it does not. When the definition of done is written down by somebody else, an agent can be measured honestly, corrected by a human on the exceptions, and trusted with volume. The file is either primary-source verified or it is not.

Look down your own service lines for that property. Repeated work, a rubric somebody else already wrote, and thousands of your own prior examples to learn from.

What it does to the P&L

Say this part plainly, because your clients will work it out anyway. Today you sell hours. If agents do the work, hours compress, and efficiency turns into a haircut on your own revenue unless you change what you sell.

So change what you sell. Price the outcome: per chart, per file cleared, per shift covered. Cost per unit falls as the system improves, and that gap belongs to you instead of leaking back as a rate reduction.

The question for our next planning meeting

Not "where do we add AI to the roadmap." That question reliably produces copilots.

Ask this one instead. What work do we understand so well that we could stop staffing it and start delivering it?

Whatever answers that is the part of the roadmap that matters. The rest is maintenance, and it is fine to call it that.