Post to Indeed and get applications back as structured records

An organic posting on Indeed sits in the index and gets whatever visibility it gets. A sponsored posting spends money per click or per application against a budget you set, and it stops when the budget stops. They behave differently, they cost differently, and the applications they produce convert differently.

The connector treats them as different states on the requisition rather than a single posted flag. A job will carry whether it is live, whether it is sponsored, what the budget is and when the campaign ends, so that a recruiter looking at a quiet requisition can see the difference between nobody is applying and the budget ran out on Tuesday.

That distinction also has to survive into reporting. If sponsored and organic applications land in the same undifferentiated bucket, the cost-per-application number you build later is meaningless, and cost-per-application is the only number that tells you whether the spend was worth it.

An application arriving as an email with a PDF attached is where most desks lose time. Somebody opens it, reads it, decides whether it is worth keeping, and either types a few fields into the CRM or leaves it in the inbox. On a requisition pulling two hundred applications, the second option always wins and the database stops reflecting reality.

Ingest through the connector will parse on arrival. The resume becomes normalised fields, current title, years in discipline, tools and frameworks separated from languages, location, notice period and salary expectation where the document states one, with the original file kept alongside the parsed text so a recruiter can always check what the document actually said.

The candidate lands on the requisition already in the applied stage, with the source recorded as Indeed and the sponsored or organic distinction attached. Nobody has to remember to set any of that, which is the only reliable way for it to be set.

High-volume boards are a duplicate engine. The same person applies to three of your requisitions in a fortnight, applies again six months later with an updated resume, and applied through a different board last year under a personal email address instead of a work one. Deduplicating that afterwards is a project. Doing it at ingest is a rule.

The check runs before the record is created, matching on email, on phone in normalised form, and on a fuzzy name plus employment history comparison for the cases where the contact details changed. A confident match updates the existing candidate, attaches the new resume as a version, and adds the new application to the existing person rather than creating a second one.

An uncertain match goes to a review queue with the two records side by side, because a wrong merge is worse than a duplicate. You can see what differs, choose which values survive, and merge or keep separate in one action.

Boards are good at telling you how many applications they delivered. That is the wrong end of the funnel. The question an agency owner needs answered is which source produced submittals, interviews and placements, and at what cost.

Because the source is written at ingest and carried through every stage change, source attribution survives to the placement. You get application counts by source, but also submittal rate by source, interview rate by source, and placements by source over a period you choose, with the sponsored spend sitting next to it.

That is often an uncomfortable report. A board that delivers volume and no placements is easy to keep paying for when the only number you see is applications received.

Post manually and route the applications in. Email ingestion into a requisition inbox is the practical path: applications forwarded or routed to the address land as candidate records with the resume parsed, and you set the source once on the rule rather than on each candidate.

For an existing pile of applications, bulk resume import handles a folder of files in one pass with the same parsing and the same duplicate check. That is usually how a new customer gets their last twelve months of board applications into the database in the first week.

None of this becomes wasted work when the connector lands. The records, the sources, the stages and the dedup history all stay exactly as they are; the ingest path in front of them simply stops being manual.

Very few desks run one board. A US staffing desk typically runs Indeed and ZipRecruiter together, a UK desk runs CV-Library alongside the aggregators, and an Australian desk runs Seek and very little else. The multi-board posting surface is built so a requisition is written once and pushed to the boards you have connected.

Each board connector carries its own state on its own page, because their partner processes are independent of each other. Indeed being confirmed does not make ZipRecruiter confirmed, and we are not going to imply otherwise by putting six logos in a row with no labels.