A multi-product integration strategy for Finity Pay and Bill — eliminating four manual data entry points from the candidate journey and connecting the fragmented recruitment technology stack for the first time.
.timeline
—
.year
2025
.tools
Figma, Jira, Zapier, Confluence, Miro
.role
Product Lead
A recruitment agency's technology stack is deeply fragmented. A single candidate placement touches at least four separate systems before a worker gets paid: an ATS to store CVs and skills, a CRM to manage placements and charge rates, a timesheet and pay and bill system, and a payroll engine to process pay and submit to HMRC. Each system requires the candidate's information to be manually re-entered. Consultants — who are good at placing candidates but not at record keeping — are doing this at high speed, under pressure, across multiple tools simultaneously. Research suggests spreadsheets contain critical errors in up to 84% of cases. In a payroll context, a single mistake cascades: HMRC validation failures, pay errors, incorrect invoices. The candidate journey from being placed to being paid was slower, riskier, and more labour-intensive than it needed to be.
I led the integration strategy for Finity Pay and Bill — connecting the recruitment stack so that candidate data entered once in a CRM flows automatically through to Pay and Bill, then into Finity Pay for payroll. The workflow now runs like this: a candidate is placed and their status updated in the CRM; Zapier detects the trigger and automatically creates the candidate and placement record in Finity Pay and Bill; the worker receives an invite to submit timesheets; the hiring manager approves time worked; an invoice is raised to the client; and the worker's data flows downstream into Finity Pay for payroll processing and RTI submission. Four manual data entry points reduced to one. The operator never re-keys the same information twice.
My goal for Finity Pay and Bill was always straightforward: make payroll beautiful, and make the journey from being placed to being paid as simple as possible. The problem was that the product was entering a market where recruitment agencies were already drowning in disconnected tools — and asking them to add another one without solving the connectivity problem was a hard sell.
The research was clear. Candidate data was being manually re-entered across an ATS, a CRM, a timesheet system, and a payroll engine — four separate entry points for the same information, each one a compounding risk of human error. In an environment where operators are working fast, under pressure, across multiple clients simultaneously, that wasn't just inefficient. It was a structural flaw in how the industry worked.
The integration challenge had a complication though. Research identified four or five front-end CRM systems commonly used across recruitment agencies — Bullhorn, Zoho, Recruitly among them — but no clear dominant winner. For a product in its early stages with limited funding, committing engineering resource to a single native integration before validating which would deliver the most value was the wrong call. We needed a way to get to market with integration capability while the research continued.
The decision I made was to implement Zapier as a deliberate stop-gap. This wasn't the ideal long-term solution — I knew that going in. Zapier opened up connections to over 1,000 applications, which meant we could go to market with genuine integration capability, start validating which CRM connections were most valuable to customers, and build the commercial case for native integrations — all without overcommitting engineering resource prematurely. It was a low-effort, high-optionality decision that gave the product something it needed at the time.
There is one deliberate limitation worth naming. Zapier's terms of use prohibit the transmission of government identification numbers — which means National Insurance numbers can't be synced through the integration. Rather than treating this purely as a constraint, I recognised it as something worth preserving intentionally. Payroll automation is a sensitive area — many operators who've spent years managing candidate data manually are nervous about fully automated flows with no human checkpoint. The NI number entry step gives operators a final review gate before a record goes live in payroll. It's a moment of human control and confidence in an otherwise automated workflow — the operator verifies the record is complete and correct before payroll processes it. A native CRM integration could eventually automate NI number transfer, but the human checkpoint itself is worth keeping in some form. Automation without oversight in payroll isn't a feature — it's a risk.
Two customers are currently live on the integration. The next step is using that live usage data — combined with the broader CRM research — to make the case for the first native integration build.
The candidate journey is no longer a data entry exercise. From placement to payroll, the information flows. Operators who were re-keying the same candidate record across four systems now enter it once. The integration opened up a commercial conversation about connectivity that the product couldn't have before — and it generated the real-world usage data needed to make the right call on which native integration to build first.
Every problem worth solving has a human at the centre of it.