A requisition is a decision, not a document
People use "req" loosely to mean the job post, but a requisition is really the approved decision to spend money on a hire: a specific role, at a specific level and budget, that someone with authority has signed off on. Treating it that way changes how you run the front of the funnel. The cleanest recruiting operations make the requisition the gate — sourcing starts only once a role is genuinely approved, defined, and funded — because everything downstream inherits whatever ambiguity the req carried. A vague, half-approved req produces a vague search, a confused hiring manager, and a candidate experience that wobbles. This is a practical recruiting-operations guide; the approval rules and budget authority are specific to your organization.
The intake that fills the req with substance
Before a req is worth posting, it has to be filled with real requirements, and that is a conversation, not a form someone types alone. The structured intake described in the hiring manager intake meeting is the input to a good requisition: what the role actually does, which requirements are true must-haves versus nice-to-haves, what success looks like at ninety days, and what the role pays. That intake feeds two artifacts — the job description the candidate sees, built using something like the job description formula, and the internal screening criteria that become your knockout questions. Keeping those two aligned, both traceable back to the same intake, is what keeps the search honest. A req where the public post and the internal scorecard disagree is a req that will generate arguments later.
Approval is where time quietly disappears
The dirty secret of time-to-hire is that a lot of it is spent before anyone sources a single candidate, sitting in approval limbo. A req waiting three weeks for a finance sign-off is three weeks of time-to-hire you will never measure as "recruiting being slow," even though the clock is running. The fix is to make the approval path explicit and visible: who approves a req, in what order, and what each approver is actually signing off on (headcount, budget, level). When approval is a defined sequence with named owners rather than an email someone forgot to forward, reqs stop dying in inboxes. This is the same routing-and-ownership discipline that makes offboarding and onboarding reliable, applied to the very front of the process — and it connects directly to headcount planning, where the decision to open the req should have been anticipated rather than improvised.
Budget, level, and pay belong on the req, not in someone's head
A requisition that does not pin down level and pay band is a requisition that will produce mismatched candidates and a renegotiation at offer time. If the intake settled on a band, that band should live on the req, and it increasingly has to live in the public post too: pay-transparency rules in a growing number of states require a salary range on the listing. Putting the band on the req from the start avoids the all-too-common sequence where a recruiter sources to one level, the manager interviews for another, and finance reveals a third at the offer stage. The cost-side of getting this right is laid out in cost-per-hire and recruiting budgets; the operational point is simpler: decide the number once, on the req, and let everyone downstream work from it.
One req, one source of truth
Where reqs go wrong operationally is fragmentation — the requirements in a spreadsheet, the approval in email, the job post in a job board, the candidate pipeline somewhere else, and no single place that says "this is the role, this is what it requires, this is who approved it, and here is everyone we are considering against it." The teams that move fast keep the requisition as the spine that holds all of that together, so the screening criteria, the post, the approvals, and the pipeline are facets of one record rather than four disconnected copies that drift apart. That is also what makes the funnel measurable — you cannot read conversion rates cleanly when the definition of the role keeps shifting underneath the pipeline.
Where the product fits
Hosting HR treats the requisition as exactly that spine: the role's requirements become structured criteria, candidates are scored against them, the public careers post and the internal screen come from the same definition, and the pipeline hangs off the req rather than living in a separate tool. When the front of the funnel is one clean, approved, well-defined record instead of a scramble of documents, the slow part of hiring — the part that happens before sourcing even begins — stops being slow. A req is a decision; the tooling's job is to make that decision crisp and then carry it all the way to the hire.