A recruitment lead engine that watches who is hiring, nationally, every night
Written by Raghav Chegu, founder at Odyssey, who built the system described here. Client anonymised pending their approval to be named.
Summary. A national Australian recruitment group was finding new employer clients by hand. Odyssey built a company based lead engine that watches job boards nightly, keeps a registry of every employer it has ever seen, and surfaces a timed follow up list at the moment a role has been open long enough to be causing pain. One scheduled run pulled 698 job postings and produced 95 follow up leads.
The problem
Recruiters compete on being early. The signal that an employer needs help is that they have posted a role and have not filled it. That signal is public, sitting on job boards, and nobody in the business had time to watch it systematically.
What existed was a person searching a job board, copying names into a spreadsheet, and losing track of which employers had already been contacted. The result was duplicated outreach to the same companies, gaps where obvious targets were missed entirely, and no memory of what had happened before.
The deeper problem is that a job listing is the wrong unit. One employer posting fifteen roles is one relationship, not fifteen leads. Any system built around listings produces a list that is mostly noise.
The decision that shaped the build
We built the registry around companies, not postings.
Every employer gets one record that persists. Postings attach to it. Contacts attach to it. Every event attaches to it. When the same employer appears again next month under a slightly different trading name, it resolves to the existing record rather than creating a second one. This is the difference between a lead list that decays and a database that appreciates.
The second decision was a day seven rule. A role posted today is not a lead. A role still open on day seven is an employer with a problem. The system tracks the age of every posting and raises a follow up task at the point where the conversation actually lands.
What we built
- A national scraper covering the major Australian job board, plus a second adapter for the government jobs platform, both running from a scheduler with a watchdog behind them.
- A registry holding companies, postings, contacts and events, seeded with 1,026 companies carried over from the client's existing records and archives.
- Company resolution and deduplication on a normalised company key, so repeat postings and name variants collapse into one relationship.
- A day seven lifecycle that ages every posting and generates the follow up task at the right moment.
- A CRM adapter that provisions the required fields and pushes leads, tasks and job activity across. Without a live API key it writes every intended action to a dry run file instead, so the whole pipeline can be exercised and inspected before it touches a production CRM.
- Coverage in code for all eight states and territories. The live schedule runs one state while the engagement is in sandbox, by choice, not by limitation.
The numbers from a real scheduled run
These are from one overnight run, confirmed in the scheduler log rather than a manual invocation.
- 698 job postings fetched
- 95 day seven employer leads produced
- 5 additional agency leads identified
- 1,026 companies already seeded in the registry before that run
- 10 of 10 tests green at first build, 23 of 23 after the second board adapter landed, including deduplication tests across multiple states
What we deliberately did not do
We did not add a third job board that sits behind a bot wall. An adapter for it was scoped and parked. Fighting that wall costs real engineering time and the coverage gap it would close has not been demonstrated yet. It stays parked until the data says it matters.
We also did not connect the engine to an automated outreach sequence. Outreach in this business runs through a named person on a professional network, by design. The engine produces the list and the timing. A human sends the message.
Why this is repeatable
The pattern is general: a public signal that a business has a problem, a registry that remembers every entity you have ever seen, a rule about when a signal becomes worth acting on, and a human at the end. Recruitment uses job postings. Commercial property uses permits and licences. Trades use council approvals. The engine underneath is the same one.
Have a version of this problem?
Odyssey builds AI-powered automation for Australian businesses. We map the workflow, build the system, and keep it running.
GET A FREE AUDIT →