Headcount planning

Agree the number before the requests start arriving

Set a hiring plan for each department and year, then have every position request measured against it the moment it is sent. Planned, approved, waiting, hired and remaining live in one table — and the decision is still made by a person.

What it does

A plan, and every request measured against it

Position requests already went through approval. What was missing was the number they were meant to fit into.

A hiring plan per department and year

Give a department a line: how many people it expects to hire that year and, if you want, the annual salary budget behind them, in one currency. Years run from last year to two years ahead, so next year can be written before it starts.

Live utilisation, not a spreadsheet

Each line shows planned, approved, waiting, hired and remaining, counted from your own requests and the jobs linked to them. Budget committed and requested sit beside them for admins; anyone else who raises a request sees the headcount columns only.

Every request checked against the plan

When a request is sent it is matched to a plan line and comes back as in plan, over headcount, over budget or no plan line. The match is by department name — spelling, capitalisation and Turkish characters do not break it — and by year.

Two rules, both off until you turn them on

A line can block requests that exceed its limit, and it can approve requests that fit the plan on the spot. Nothing is ever rejected automatically, an admin can still open a request deliberately, and a budgeted line never auto-approves a request that states no budget.

The request itself, unchanged

Title, department, location, number of people, employment type, reason, optional budget per person, target start date and the business case. One admin approves it, or rejects it with a reason, and no team member decides on their own request.

Two AI actions, a credit each

Turn a free-text note into a draft request, or ask for an assessment of one. Both are optional, a credit is taken only when a usable answer comes back, and the pair can be switched off for the account in your AI settings. Everything else here works without them.

The plan table

One table that answers how many are left

The plan sits on the same page as the requests, so the number and the decision are never in two different places.

Planned, approved, waiting, hired and remaining for each department and year, with a progress bar that changes when a line goes over.
Approved counts the people on approved requests; hired counts the people actually hired in the jobs linked to them.
Waiting requests are shown but do not count against the limit — only approved ones do.
Budget committed and requested appear for admins. A request with no budget, or one priced in another currency, is listed as unknown rather than quietly converted.
AI assessment

Evidence first, then a model that may only read it

Ask for an assessment of a request and the figures are worked out on our servers from your own account before the model is called. It writes the words around them.

Median time to hire over the last 12 months — from similar job titles when there are at least three such hires, otherwise across the company, otherwise it says there is not enough data.
Applications per hire, how many applications this request would need, the latest date the job should be opened, and a reading of the timeline: on track, tight or at risk.
The budget in the request against your own salary band, plus the open load — other waiting requests, people already approved and live jobs — and the plan check itself.
A sentence that quotes a figure the evidence does not contain is removed before you see it. The model never approves a request, never rejects one and is told not to advise either way.
Where it earns its place

Three moments this changes

A hiring plan is usually a spreadsheet somebody else owns. These are the moments it needs to be next to the requests.

Budget season

The numbers are agreed once, then forgotten

Put what was agreed into the product, so the plan lives where the hiring actually happens.

  • One line per department and year, with the annual salary budget beside the number of planned hires.
  • Save the same department and year again and it updates that line instead of creating a second one.
  • Next year and the year after are already selectable, so a plan can be written before the year begins.
Mid-year

Requests keep arriving after the plan is set

Decide once whether a line is advice or a limit, and let the check do the rest.

  • Leave the line advisory and the badge simply tells the approver where the request lands.
  • Switch blocking on and an over-plan request is not created — though an admin can still open one deliberately.
  • Switch auto-approval on and a request that fits the plan is approved as it is sent. Nothing is ever rejected this way.
Timing

Somebody needs to start in November

Work backwards from how long your own hiring has actually taken instead of guessing.

  • The assessment gives the latest date the job should be opened for that start date.
  • It says how many applications a hire has taken you lately, and how many this request would need.
  • It reads the timeline as on track, tight or at risk — and says plainly when there is not enough history to judge.
Questions

What people ask before they set a plan

Short answers about what the product actually does, and what it deliberately does not. The AI part is also set out in the AI Transparency Notice.

No. Hireall is a hiring system, not a record of your workforce, so it cannot tell you how many seats a team has filled. The plan is a hiring plan: how many people you intend to hire in that department that year. Everything counted against it — approved requests, waiting requests, people hired in the linked jobs — comes from your own hiring activity.

No, and it cannot. Automatic approval comes only from the plan check, which is arithmetic; it is off until you switch it on for a line, and it applies only to a request that fits. There is no automatic rejection anywhere in the product. The model is instructed not to recommend approving or rejecting, and none of the figures it writes are its own.

From your own account, over the last 12 months, calculated on our servers before the model is called: median time to hire, applications per hire, your own salary bands, your open requests and live jobs, and the plan check. There is no market salary data, no industry benchmark and no outside statistic. When your own history is too thin, the assessment says so rather than estimating.

By department name and year. The name is matched loosely, so a different capitalisation or a Turkish character will not create a second line, and saving the same department and year again updates the line you already have. The year comes from the target start date, or from the day the request was opened when no target date was given.

Nothing changes for them. Requests are written, approved and rejected exactly as before; the card just says there is no plan line for that department and year. Both rules belong to a single line and are off by default, so a plan you have not finished cannot stop anyone from asking.

Part of the platform

Put the number next to the decision

Walk through a plan line and an assessment with us in a 30-minute demo.

Talk to our team

Tell us about your roles and team size — we'll map Hireall to your hiring process and the plan that fits.

Contact sales Priced per company, not per seat