Recruiting Agency Software Problems: The 7 That Cost Staffing Firms Real Money, and How to Avoid Them

Why does submission get scoped as a status field?

Every applicant tracking system in this category models submission as a value on a record. Someone sets it. That is the entire mechanism, and because it looks like a workflow, it gets carried into a custom build unchanged.

The scene that costs money: a client calls, annoyed, saying they never received the candidate you have been forecasting for three weeks. The recruiter did send it, to a hiring manager whose mailbox now forwards nowhere. Meanwhile the delivery manager pulls a report showing 62 active submissions, of which 19 went into a portal where the requisition closed days ago, 11 were never acknowledged, and 6 are duplicates.

This is not a discipline problem you can train away. Client Submitted means a dropdown was clicked, and automation that nags the recruiter to update it cannot change what the field is able to know. Once a client mandates their own portal, the state of your most important object lives on somebody else's server.

The fix is to model submission as an event stream rather than a status. Each submission carries a tracked delivery artifact, a unique link to a branded candidate profile rather than an emailed attachment, so you know when the hiring manager opened it and whether they forwarded it internally. Where the client uses a vendor management system, a scheduled agent pulls requisition state back so a closed requisition kills the forecast automatically. Duplicate and ownership checks run at submission time on a fuzzy match across email, phone and a normalised work history rather than on exact candidate identifier. The forecast then reads: 62 submissions, 41 verified opened, 18 with client side activity in 72 hours, 9 with a scheduled interview.

What goes wrong when you migrate ten years of Bullhorn data?

The extraction takes days. The interpretation takes weeks, and agencies consistently budget for the first and not the second.

What is actually in there: a duplicate rate nobody has wanted to measure, because the same candidate registered in 2017 with a personal address and in 2022 through a job board with a different one. Custom fields that three offices used to mean three different things, so a field called Status 4 signals something specific in Chicago and something unrelated in Dallas. Resumes in six formats, some of them scanned. Placement records where the rate was amended by an email nobody attached. Job orders left open for years because closing them was nobody's job, which makes any historical conversion rate meaningless. And an acquired agency still on its own system with its own conventions.

The failure is predictable: the build starts, the data question is deferred, and in month four somebody has to decide what a field means before a report can be trusted. A developer cannot make that decision.

The fix is to appoint a data owner on your side in week one, run the duplicate analysis and the custom field audit before the schema is finalised, and accept a phased position rather than a migration. Bullhorn stays as the candidate and job order store while the new system owns submission and money, with a defined sync between them. That lets you fix the expensive leaks in 12 to 16 weeks without a risky cutover, and you make the full migration decision later with real usage data instead of a guess. Any developer who opens with a big bang migration is optimising for their invoice schedule rather than your risk.

Why do the VMS portal integrations break after launch?

Each portal is its own project, and the ones that hurt are not the ones with documented interfaces.

Fieldglass and Beeline have APIs and partner processes, which means onboarding, credentials and a review, all of which take calendar time rather than engineering time. The regional MSP portals your specific clients use frequently have neither, which means a maintained headless integration and a support burden every time they redesign a login page or add a step to their submission flow. Field mappings change silently: a required field is added, submissions start rejecting, and because the rejection surfaces inside the portal rather than in your system, nobody notices for a day.

The second failure is scope creep by portal count. An agency lists nine portals because nine appear somewhere in the delivery mix, while two carry most of the volume. Budget $12,000 to $30,000 per portal in our delivery experience and start with the two that matter.

The fix operationally is to treat every portal as a monitored feed. Alarm on rejection rates and on requisition state pulls that return nothing, because a silent integration failure here directly costs placements. Keep a logged manual fallback for every portal so a recruiter can still submit when the integration is down, rather than letting people revert to email without a record.

What happens when contract compliance and credentialing is not covered?

On perm desks this barely registers. On contract, and especially in healthcare, it is the difference between a placement and a liability.

The pattern is that compliance is remembered rather than enforced. A coordinator keeps a spreadsheet of licence and certification expiry dates. A nurse's licence expires eleven days into an assignment and nobody catches it until the client does. Right to work documents are collected at onboarding and never revalidated. A client requires a background check before interview and another requires it after offer, and the difference lives in a recruiter's memory. Insurance certificates for corp to corp contractors lapse mid assignment.

The cost is asymmetric. Most of the time nothing happens, and occasionally a client audit finds a gap and you lose the account.

The fix is to model each credential as its own record with an issuing body, an expiry date and a verification source, then block submission automatically when something is missing or expiring inside the assignment window. Per client submission profiles carry the required attachments, so the check happens at the point of submission rather than at onboarding. This is materially more expensive to build than IT contract staffing because of the audit trail expectations, and it belongs at the upper end of the cost band, but the payoff is that compliance becomes a system property rather than a coordinator's vigilance.

Should you build custom or configure what you already own?

Stay on Bullhorn if you are under roughly 25 recruiters, mostly perm, mostly direct clients, without heavy vendor management system exposure. At that scale a seat plus Bullhorn Automation is cheap relative to a build, and your problems are process problems. Building will not fix a desk that does not do business development.

Stay on it also if you are growing by acquisition and the targets are on different systems. Standardise on one commercial platform first, get the data clean, then build on top. Building a custom platform while your data model is still an argument is how these projects die.

And keep the point tools that work. Daxtra and Sovren parse resumes well and integrating with them costs a fraction of building a parser. A firm that says yes to building everything is quoting rather than consulting.

The build case appears when these show up together, and they usually do: more than 150 active contractors with someone whose full time job is timesheet and invoice reconciliation, three or more portals with recruiters double keying into them, and a Monday pipeline meeting that spends more time arguing about what the numbers mean than what to do. The strongest case is the boring one: contract staffing at volume, where recovering two margin points pays for the build several times over.

How do hidden costs get into the quote?

• Portal count. Each vendor management system is its own project at roughly $12,000 to $30,000, plus an ongoing support burden when the portal changes without notice.
• Payroll complexity. Integrating with a back office provider is straightforward. Running multi state payroll with your own burden calculations, per diem and reciprocity rules needs a tax advisor in the room, not just developers.
• Rate agreement volume. Your rate card is really a set of exceptions living in contract documents. Turning executed agreements into versioned, testable rate objects is a data project with a legal review attached.
• Compliance depth. Healthcare credentialing with expiry tracking and audit trails is materially more expensive than IT contract staffing, as is anything touching government contracts.
• Data interpretation, not extraction. Deciding what a custom field meant when three offices used it three ways is 4 to 8 weeks of your people's time.
• Money movement. Invoicing, retries and reconciliation demand careful engineering, and corrections must post as reversals rather than edits if the ledger is to be defensible.

What separates a build that works from one that fails here?

The ones that work get the data model right on a whiteboard before anyone talks about price. Candidate, job order, submission, placement, timesheet, invoice and rate agreement as separate objects with their own lifecycles. Specifically probe how a prospective developer models the same candidate submitted to two clients for two roles at two different pay rates, and what happens when one converts to perm. If they draw submission as a status on a job order, they have never built this and will discover the problem in month four on your budget.

They also encode commercial terms as first class logic. Each client contract becomes a versioned, testable rate agreement: bill rate by role and location, overtime thresholds and multipliers, holiday treatment, expense caps, invoice cadence and effective dates. Every timesheet runs through it and produces an invoice line with an audit trail showing which rule fired. That turns reconciliation from an Excel job into an exception queue, and it is where the margin recovery comes from.

Per client submission profiles are the other quiet win. Template, required fields, redaction rules, attachments with expiry checks, delivery channel and service level clock, so the recruiter clicks submit and the system renders the correct artifact, verifies compliance and delivers it. Twenty minutes of manual reformatting becomes twenty seconds, which across a 40 recruiter agency is thousands of hours a year.

The ones that fail try to replace everything at once and never reach the money. Fix the two worst leaks first, submission verification and the timesheet to invoice chain, run them alongside the incumbent, and settle ownership before kickoff: repository in your organisation, cloud accounts in your name, no runtime licence on software you paid for. In a category where your operational data is the asset, a vendor holding the keys holds your agency.