AI Adoption GuideHRSource
Conversational career site agent
Chatbot answers candidate questions, captures applications, and pre-screens via web chat or messaging apps.
HR processPlanSourceSelectHireOnboardDevelopRewardExit
By Don, DoneThat’s AI coach · updated
Load the live posting and policy before anyone chats
A conversational career site agent earns its place only when every reply can point to a specific passage in the current job posting or a named policy. If the posting is stale, the policy pack is missing, or the agent answers from generic hiring folklore, the chat is not a source of truth. Treat it as a grounded Q&A surface on the requisition the visitor is already viewing, not as a recruiter substitute.
Talent-attraction leads should bind the agent to that requisition plus a small, versioned policy set: work-authorization language you are willing to publish, shift and overtime rules for that site, relocation or remote eligibility, benefits headlines that already appear on the posting, and the official application path. Do not load interview scorecards, unpublished compensation bands, or internal notes about how you really hire that a candidate should never see.
Career-site products and applicant tracking systems (Phenom, Greenhouse, Lever, Ashby, and peers) sit in this stack as a class. They host the widget or messaging thread, they hold the requisition, and they receive applications. None of that changes the operating rule. The model must read the posting and the policy pack for that req before the first candidate message, and it must re-read if either document changes.
If the posting is vague on hours, location, or who can apply, fix the posting. Run it through an inclusive job description optimizer before you expose chat. The agent should not invent clarity the requisition does not contain.
On session start, fetch the requisition ID from the page or campaign link, retrieve the current posting text, retrieve the policy pack keyed to that requisition or location, and freeze those versions for the thread. If retrieval fails, the agent should not chat from a previous requisition's cache. It should say the posting is unavailable and point to the apply path or a human.
Cite the passage or return a blank
Quality here is a cited answer. The candidate sees a reply that restates only what the posting or policy already says, with a pointer to that passage: section heading, bullet, or policy name and clause. If no passage supports the claim, the answer field stays empty. Empty is a successful outcome. A guess is a failed one.
That rule blocks the most common failure mode: an answer with no posting cite. Claims such as sponsorship when the posting is silent, optional nights when the posting lists a rotating roster, or "send your resume here and you are in" all fail the same test. Those replies feel helpful in the widget and become disputes later. Require the cite in the same turn as the answer. If retrieval returns nothing on-policy, render a blank plus a short redirect: this is not in the posting; use the official apply path, or ask a recruiter after you apply.
Pre-screen questions follow the same cite rule. You may ask only what the posting already requires (license, shift, location, work-authorization language that is already public). You may record the candidate's typed reply. You may not score them into a reject. You may not fill an application on their behalf.
Leave structured fields blank when the candidate did not answer, when the answer is ambiguous, or when the posting does not define the criterion. Downstream tools should see unknown, not a fabricated yes or no. That is the same discipline you want later from structured resume scoring: missing evidence stays missing.
Write the prompt and the UI around that contract. The model gets posting text, policy text, and a hard instruction: quote or paraphrase only with a cite; otherwise leave the field empty. The widget should show the cite to the candidate when you answer, and should show a visible empty state, not a hedged paragraph, when you cannot. Recruiters reviewing the thread should see the same cites and blanks, not a cleaned-up summary that hides what was missing.
Chat is not an application and not a reject
Treating the transcript as an application is the second failure mode. A conversation can capture questions, intent, and optional pre-screen replies. It does not submit the candidate to the requisition. Auto-apply from chat skips consent, skips required fields, and dumps incomplete records into Greenhouse, Lever, Ashby, or whichever ATS you use. The candidate thinks they applied. The recruiter thinks they have a full packet. Neither is true.
Keep a hard boundary. The widget answers and, if you choose, collects. The apply control already on the career site, or the ATS apply flow it already uses, is the only submit. If the candidate asks to apply in WhatsApp, SMS, or the site chat, the agent cites the posting's how-to-apply line and stops. It does not create a profile, attach a resume it invented, or mark them as applied.
Auto-reject from chat is the third failure mode. A recruiter still screens. A no on a pre-screen, a messy answer, or a question the agent could not cite is not a knockout. Knockout logic in a public chat is brittle: people misread questions, the posting was wrong, the policy was outdated, or the channel truncated the reply. Route the transcript to a recruiter queue as needs review, including blanks. Do not close the requisition against them. Do not send a rejection from the bot.
If the candidate goes quiet after a useful chat, that is a sourcing follow-up, not a disposition. A personalized outreach sequence generator can draft a human-reviewed note that points back to the same posting. It should not pretend the chat already entered them in the ATS.
Example: overtime, relocation, and a warehouse posting
A talent-attraction lead for a regional warehouse role publishes a posting that states rotating second and third shift, overtime as scheduled, a named city, relocation not provided, and apply on the career site. The policy pack adds the public work-authorization sentence already on the posting and the link to the official apply form. The agent is not given pay bands, interview questions, or a note that exceptions sometimes happen.
A candidate opens the widget and asks whether you cover moving costs, whether days-only is possible, and whether they can send a resume in the chat.
A grounded reply cites the posting for location and relocation (not provided), cites the shift line (rotating second and third, not days-only), and cites the apply path. It does not discuss exceptions. For days-only, it does not mark the person ineligible. It records the preference as a note and leaves the screening decision to the recruiter.
If the candidate then asks whether overtime becomes optional after ninety days, and neither the posting nor the policy pack says so, that answer stays empty. The agent does not soothe them with industry norms. It says the posting does not state that, keeps the field blank, and still does not auto-reject.
If the candidate pastes a resume into chat, the agent does not parse it into an application. It cites how to apply and stores the paste only if your retention policy allows it. The recruiter opens the thread later, sees cited question-and-answer pairs, sees blanks where the posting was silent, and decides whether to invite a formal apply or a screen. That is the quality bar: cited answers, empty when uncited, human screening after.
Keep the transcript off the decision path
Treat the agent as a sourced conversation attached to a requisition, not as a hiring decision. Log posting version and policy version with the thread. If either changes, do not silently rewrite history. New chats use the new pack. Recruiters should see cites and blanks in the same view they use for inbound.
Chat events are notes on a sourced conversation. Application events are ATS submits with candidate consent. Disposition events are recruiter actions.
Do not pipe chat fit into later models as if the person had applied. An offer-acceptance probability model belongs after a real offer conversation, not after a widget that never submitted. Keep career-site chat, ATS records, and downstream scoring on separate contracts: chat answers questions, the ATS holds applications, people dispose.
Review a sample of threads on a fixed cadence for the three failure modes: replies with no cite, chats marked applied, and auto-rejects. Fix retrieval and posting quality first. Then tighten the agent's refusal to fill blanks. The talent-attraction lead owns that loop. The model does not.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first