How should recruiters turn changing client notes into a role brief?
Format: Article.
Keep the last approved role brief while you draft a new version. Show what changed, who asked for it, and what still needs the client's decision. A recruiter should not have to guess whether a comment on a call replaced an agreed job need.
A role brief sets out the job. It does not judge a candidate. Use the change process to make duties, place, hours, and terms clear. Keep open questions visible. Do not turn a vague client wish into an applicant score or a rule that screens people out.
Treat client notes as proposed inputs
Keep notes under one role ID. Record who spoke, when, and how the note arrived. Keep the exact words of an unclear request. The person who asks for a change may not have the right to approve it. The latest email does not always replace the agreed brief.
Greenhouse lets teams set up job approval steps before recruiting or creating an offer. Changes to certain job fields can trigger a new approval request. [S03] That is a provider-specific example of why revision matters. It does not mean your applicant tracking system reviews every change to free-text notes.
An agency needs its own agreement about which changes require client sign-off and who owns that check. Do not rely on a platform notification unless its actual coverage has been verified.
Use a role-brief revision packet
Start with the role ID, old approved version, and new draft version. Add the planned start date for the change and the recruiter in charge. Then fill this table. These sample values are hypothetical.
| Field | Current approved brief | New note | State and next action |
|---|---|---|---|
| Work location | Main office | “Some days at the annex” | Clarify address and expected days |
| Shift | Weekday daytime | “Need evening coverage too” | Client must confirm hours and frequency |
| Main duties | Account support | Add renewal reporting | Draft revision for client review |
| Tools | Approved application list | “Advanced systems skills” | Ask which tasks and tools are required |
| Terms | Current approved terms | No confirmed change | Preserve current terms; do not infer |
For each row, add a source link, decision owner, and decision date. Use states such as confirmed, proposed, conflicting, or unresolved. “Discussed” is useful history, but it is not approval.
Attach a short change summary that a client can check without rereading the full brief. Also retain the clean proposed version so the approver can see how the changes work together. A row-by-row approval is not enough if the combined role now says something different.
Ask questions that resolve the ambiguity
Ask a clear question, not just “Please confirm the new requirements.” For evening work, ask which days, hours, and site. Must the role cover them, or is this a choice? For a software skill, ask what task the person must do. Do not invent a skill level from a vague note.
If a note raises a question about fairness, law, or policy, send it to the right human reviewer. Do not turn it into a screening rule while you wait. This process does not judge what is legal. It does not let AI rank, reject, or hire people.
Keep the disputed field out of the brief sent to staff. If the gap affects the whole role, hold the new version. Do not send a partly approved brief that staff may treat as final.
Hypothetical example: the annex changes the role
A fictional client approved an office-based support role. During a call, a team lead asks for evening coverage at an annex. The account manager later says the daytime schedule should remain unchanged.
The recruiter drafts a change and attaches both notes. The place and hours rows are marked conflicting. They ask the client's approved contact what the annex work means. Is it part of this job, a new job, or a request still up for discussion?
The contact confirms the job stays at the main office during the day. Staff do not release the annex change. The packet keeps the decision, both notes, and the same approved brief. No applicant is ruled out for evening work that was never approved.
Release the version, not just the email
Before you send the brief, check every changed field. Show the decision or the question still open. Record who approved what and when the change takes effect. If the client approved duties but not terms, do not mark the whole packet approved.
Tell the team which version to use. List the job posts, staff briefs, and draft messages that a person needs to check. Saving the new brief must not, by itself, change a public job post or send new terms to candidates.
Core Agentic can discuss custom software to draft these packets from approved client records. It is not a finished recruiting platform. We would agree on access, how long to keep data, any use of cloud services, and system links. Recruiters and the client's approved contacts make the decisions.
Book a Demo to discuss a role-brief workflow that makes changing requirements clear before your team acts.
Sources
These sources describe the named provider or framework. They do not establish a Core Agentic integration, customer result or certification.