Talent SummonerHeadcount Plan Change Log
Use a headcount plan change log to record demand changes, assumptions, approvals, owners, evidence and the next corrective action.
A headcount plan change log records how an approved or proposed workforce plan changes over time. It should answer four questions without reconstructing a meeting from memory: what changed, why it changed, who approved it and what happens next. Keep it alongside the plan version and its supporting evidence; do not overwrite the previous state.
A planned role is a demand signal, not proof of funding, manager capacity, candidate availability or offer acceptance.
How to set the boundary of a headcount plan review
Start each review with an as-of date, timezone, plan owner, covered period and system of record. Define what the plan counts: employees, contractors, backfills, open requisitions or some combination. Separate approved positions from requests and scenarios. If the denominator changes, record that as a plan change instead of silently comparing unlike totals.
The U.S. Office of Personnel Management (OPM) Workforce Planning Guide (3 November 2022) presents workforce planning as a continuing cycle of analysis, action planning, monitoring and refinement. The CIPD workforce planning factsheet (29 July 2025) describes balancing labour supply and demand and turning analysis into action. These support a traceable record, not a required format or benchmark. Sources checked 5 September 2026.
What belongs in a headcount plan change log?
Log a change when it can affect the number, timing, scope, owner, approval state or skill requirement of planned work. Examples include an approved budget change, a replacement becoming a new position, two requests being merged, a role being paused, a target start moving, or a must-have being redefined. Do not create a new event for a spelling correction unless it changes the meaning or evidence.
Use one event per material change. Keep these concepts separate:
| Concept | Meaning | Example record |
|---|---|---|
| Observation | A new or corrected fact available to the team | A department confirms that a planned departure date changed. |
| Assumption | A condition used for planning but not yet confirmed | A launch is expected to require one additional support shift. |
| Decision | An authorised instruction that changes the plan | The finance owner approves one replacement role for Q4. |
| Consequence | The affected row, scenario, timing or dependency | The replacement moves from possible to approved; the start date remains unknown. |
If evidence supports only an assumption, label it assumption. Do not upgrade it to approved because it appears in a spreadsheet or meeting note. If authority is unclear, use HOLD and name the confirmer.
What fields does a headcount change event need?
Give each change event a stable ID, and keep both the old value and the new value. A useful event includes:
| Field | What to record | Control question |
|---|---|---|
| Event and time | Event ID, recorded time, timezone and recorder | Can someone place the change in sequence? |
| Plan identity | Plan version, scenario, period and owner | Is this the same plan another reviewer is using? |
| Scope | Role or workforce group, location if relevant, and in/out boundary | Which rows and totals are affected? |
| Before and after | Prior value, new value and unit | Did the count, date, state or requirement actually change? |
| Trigger | Observation, request, approval, dependency or correction | What event caused the edit? |
| Evidence | Budget decision, forecast input, approved brief, meeting record or source link | Can a reviewer inspect the basis? |
| Authority | Decision owner, approver and approval date | Was this person authorised for this change? |
| Consequence and risk | Impact on timing, capacity, skills, dependencies and scenario; residual risk or mitigation | What else must be revisited, and who owns the risk? |
| Next action | Owner, due or review date and stop condition | What closes the event or keeps it open? |
The U.S. Government Accountability Office workforce-planning principles, published 11 December 2003, emphasise stakeholders, critical skills, tailored strategies and monitoring. Use them as prompts to name affected people, state the skill or capacity implication, identify an action and revisit it. They do not establish a headcount target.
How to run a headcount plan review and fix failure signals
Before a planning meeting, snapshot the current plan. Review open events, new changes and events ready to close. Test evidence, authority, scope and next action, and retain the prior plan version even when a change is accepted.
| Failure signal | Why it matters | Corrective action |
|---|---|---|
| A total changes with no event ID | The plan cannot be reconciled | Restore the prior total, identify the source change and create an event before approving the new version. |
| "Approved" has no approver or date | The status may be an assumption | Mark it HOLD, name the decision owner and set a review point. |
| A date becomes precise without new evidence | Precision can disguise uncertainty | Restore the bounded date or range and record the assumption and owner. |
| One event contains several unrelated edits | Scope and accountability become unclear | Split it into one event per material change and link related IDs. |
| A merged role loses its original request | The change cannot be audited | Keep both IDs, identify the surviving record and document retained scope. |
| A role is paused with no trigger | Pause can become invisible backlog | Add the dependency owner, review date and condition for resuming or closing. |
| A skills change has no recheck | Sourcing or assessment may use an old brief | Version the requirement, identify affected work and assign a comparable review. |
Close an event only when the result, evidence, owner and next review are recorded. If a dependency is unresolved, leave the event open or mark HOLD. Do not delete a rejected request; retain its reason and date so a later reappearance is distinguishable from a new request.
Copyable headcount change-log template
Copy this block into the plan's approved workspace.
HEADCOUNT PLAN CHANGE LOG
Plan version / scenario / covered period:
As-of date and timezone:
Plan owner / decision meeting:
System of record / access boundary:
EVENT ID:
Recorded at / recorded by:
Affected role, team or workforce group:
Change type: observation / assumption / decision / correction
Trigger:
Evidence or source reference:
Authority / approver / approval date:
Before: [value, unit, state and plan version]
After: [value, unit, state and plan version]
Impact on timing, capacity, skills or dependencies:
Risk or mitigation / risk owner:
Scenario affected: base / constrained / upside / other
Decision: proceed / merge / pause / revise / escalate / hold / close
Next action / owner / due or review date:
Stop condition:
Communication required and audience:
Linked event IDs:
Closed at / closed by / closing evidence:Fictional example: tracing a headcount plan change
Record each headcount plan change as its own dated event, as this fictional Lantern Row example shows. At Lantern Row, a Q1 plan has two approved customer-support replacements and one possible implementation role. A manager reports a later departure date. Event HC-014 records the dated confirmation and changes the replacement window from January to an unconfirmed later window; approved headcount is unchanged.
Finance approves the implementation role only if a customer contract is signed. The team records a second event: the role is conditional, finance owns the dependency and the contract decision is the stop condition. At the next review, each event is closed or kept open with a new review date. The log preserves what was known at each point.
Where Talent Summoner fits
Talent Summoner is our product for AI candidate sourcing, CV ranking and outreach you confirm before it sends. Its candidate-sourcing workflow, checked 29 September 2026, starts from an approved role brief and searches LinkedIn, GitHub and other public professional sources, returning a ranked shortlist with must-haves, nice-to-haves and plain-English reasoning. Its candidate-ranking tool can help compare supplied CVs after the criteria are agreed.
The current product does not own a headcount plan change log, approve budgets, manage requisition status or maintain an application pipeline. Keep approvals, plan versions and change events in the team's chosen planning system. Use sourcing or ranking only after the role scope is authorised, and have a human verify evidence and make the hiring decision.
What is a headcount plan change log?
A headcount plan change log is a dated record of material changes to planned workforce demand, timing, scope, owners, assumptions or approval state. Each event links the before and after values to evidence, authority and a next action.
How often should the log be reviewed?
Review it whenever the plan is reforecast, a material assumption changes or an approval is made. A regular cadence can help, but an event should not wait for a meeting when leaving it unrecorded could mislead the plan.
Should a proposed role appear in the log?
Yes, if it changes the plan or scenario. Label it proposed, conditional or assumed, state the evidence and name the approval required. Do not count it as approved headcount until the authorised owner confirms it.
Does Talent Summoner update headcount plans?
No. Talent Summoner supports candidate discovery and comparison after a role brief is ready. Headcount approval, the application pipeline and change control stay with the team's own planning process.
At the next forecast review, snapshot the current plan, assign an event ID to every material change and test each entry for evidence, authority, scope and a stop condition. When a role is approved for candidate research, use the reviewed brief with candidate sourcing or candidate ranking, while keeping the headcount change log as the source of planning decisions.
