Workforce planning that turns an approved plan into requisitions

What does OpusHire workforce planning cover?

A workforce plan in OpusHire holds the positions a company intends to fill: unit, location, grade, number of seats, needed-by month and cost. The plan carries its budget caps and forecast, goes through an approval chain, and once approved releases each position as a requisition on its release date, so the plan and the hiring it causes never drift apart.

Positions can be entered one by one, pasted into a department sheet laid out by month, or imported from a workbook. A re-imported workbook is compared row by row with the plan as it stands, so an edit made in OpusHire after the export is kept rather than overwritten, and a conflict is listed instead of applied.

Planning is built for in-house hiring teams and is switched on for corporate workspaces during onboarding.

How is demand forecast?

Demand is computed in code from the drivers you enter, such as revenue per period and a demand rate per driver, and each figure on screen carries the formula and inputs behind it. A missing input shows as a dash with the reason, never as zero, and a later planning year is marked as indicative.

Scenarios sit side by side. A comparison breaks the difference between two scenarios into its steps, and stops rather than closing the gap with a number it cannot account for. Scenario levers, such as an attrition or vacancy assumption, change the forecast terms they name and never rewrite a position's cost.

Plans can look up to five years ahead. Only the first year carries positions and releases; the years after it are forecast figures.

How are budgets and labour cost handled?

Each position is checked against the most specific budget cap that covers it, in needed-by order, and the plan shows which caps are exceeded. Money is kept per currency and never converted, and cost figures are visible only to people with pay access; for everyone else they are withheld rather than shown as zero.

What happens when a plan is over budget is a company setting: a warning, an extra Finance approval level with a written reason at submit, or a firm block. "Over" is measured by the server from the stored positions, not taken from the screen.

On-cost is applied when a planner presses the button and the loaded figure is stored, so a later change to a rate cannot quietly restate a figure an approver has already signed.

How does approval and release work?

Submitting a plan freezes its approval route, so a later policy change never retargets a plan in flight, and the route is shown before Submit. Approvers decide on the exact version they saw; once the last level approves, each position becomes one requisition on its release date and cannot become two.

• Deputies and stand-ins. An approver can name a deputy for a date range, and an administrator can add a stand-in with a recorded reason.
• Reminders and escalation. Waiting approvals are reminded and escalated once, on the schedule the company sets.
• Amendments. An approved plan is changed through an amendment that is approved in its turn and applied in one step, never half-applied.
• Seats, not requisitions. Tracking counts each seat as planned, open, accepted, joined or closed, so a requisition for three hires is three seats.

Who can see and change a plan?

The company administrator owns the plan. A Finance viewer can read every figure, pay included, and change nothing; a unit contributor can enter and edit positions only in their own units and never sees pay. Everyone else gets no access at all.

Current strength comes from figures entered against the organisation chart or from a headcount upload of counts per unit; no individual employee record is stored for planning. An AI-assisted narrative can summarise a plan for approvers, and every number it uses must be one the platform computed. It is labelled AI-assisted, human-reviewable.

Frequently asked questions