Most staffing RFPs fail before they're sent. They ask questions every provider answers identically ('describe your quality process'), weight price because it's the only column that's easy to compare, and produce a stack of glossy responses that differ mainly in font choice. The RFP isn't inherently broken as a tool, it's just usually written to collect marketing instead of to discriminate. Here's how to write one that actually separates providers, and, first, the more important question: whether you should be writing one at all.
When an RFP helps, and when it slows you down
The honest case for an RFP: your procurement policy requires one above a spend threshold, the engagement is large enough (multi-year, multiple seats, six or seven figures) that structured comparison genuinely reduces risk, or you're entering a provider landscape you don't know and need a map before a shortlist. The honest case against: an RFP cycle typically costs six to twelve weeks, and its output is written claims, the thing staffing providers are best at producing. If your spend is below the threshold that forces the process, a two-week paid pilot with your top one or two candidate providers is usually a better instrument: it costs less than the internal time an RFP consumes, finishes faster, and measures the thing you're actually buying, how their engineers perform inside your stack, rather than how their proposal team writes.
| Situation | Better instrument | Why |
|---|---|---|
| Procurement policy mandates competitive bidding | RFP (with a pilot as the final stage) | The process is required; make it discriminate as well as it can |
| Multi-year, multi-seat engagement | RFP shortlist, then paid pilot with finalists | Structured comparison plus behavioral evidence |
| One to three seats, need to start within a month | Skip the RFP; pilot with 1-2 providers | The RFP cycle costs more than the decision risk it removes |
| Unfamiliar provider landscape, no shortlist yet | Lightweight RFI, then pilot | You need a map, not a 40-page response |
| Extending or expanding an existing provider | Neither — negotiate against delivery data you already have | Your own engagement history beats any written response |
The sections that actually discriminate
Generic questions produce generic answers. The sections below force responses that differ between providers because they demand specifics that are checkable later, and because weak providers hurt themselves answering them honestly. If a question could be answered by pasting from the provider's website, cut it.
- Vetting process disclosure: 'Describe each stage of your engineer vetting, what percentage of applicants pass each stage, and the three most common rejection reasons at the technical stage.' Real vetting operations know these numbers; volume shops improvise them.
- Named-people commitments: 'Will the CVs you present be the people who actually staff the engagement? What contractual commitment do you make to that, and what happens if a named person becomes unavailable before the start date?' This question alone eliminates the bait-and-switch pattern, or surfaces it early.
- Replacement terms: 'State your replacement guarantee exactly as it appears in your standard contract: trigger conditions, timeline commitment, and what we pay for during the transition.' Ask for contract language, not policy prose.
- Compliance posture: 'Describe your data protection setup for engagements touching production data (DPA, subprocessors, where engineers physically work), and, for EU clients, how your model addresses misclassification and labor-leasing risk in the relevant jurisdictions.'
- Failure disclosure: 'Describe an engagement in the last two years that went badly. What happened, and what did you change?' The answer's specificity matters more than its content, a provider with no admissible failure has a truthfulness problem, not a track record.
- Rate transparency: 'Break the quoted rate into engineer compensation and your margin, or explain why you won't.' Many will decline; how they decline is itself signal.
Scoring design: decide how you'll judge before you ask
Scoring designed after responses arrive drifts toward justifying the response the team already liked. Fix the rubric before sending, weight the dimensions that predict engagement success rather than the ones that are easy to compare, and score specificity: an answer with numbers, names, and contract language outscores an eloquent answer without them, every time. Keep price at a weight that reflects its real share of risk, a 15% rate difference is trivial next to the cost of a provider whose replacement guarantee turns out to be decorative.
- 1Vetting depth and verifiability of the claimed process: 25%.
- 2Contract substance, replacement terms, named-people commitment, exit provisions, as written clauses: 25%.
- 3Relevant delivery evidence: references and case detail in your domain or stack: 20%.
- 4Compliance and security posture appropriate to the data the engagement touches: 15%.
- 5Price and commercial flexibility: 15%, and consider scoring the pricing model's transparency, not just its level.
Red-flag answers, and what they predict
| Red flag in the response | What it predicts |
|---|---|
| Boilerplate that never references your context, stack, or stated constraints | An engagement run on autopilot; you're one of hundreds |
| 'All our engineers are top 1%' with no acceptance rate, stage data, or method | Marketing in place of vetting; expect profile-reality gaps |
| Won't commit contractually that presented CVs are the people who start | Bait-and-switch staffing; the A-team sells, the B-team delivers |
| Replacement guarantee described in prose but absent from the attached contract terms | A guarantee that evaporates exactly when you need it |
| No failure story, or a 'failure' that's really a humblebrag | A provider that manages narrative, not delivery |
| Price dramatically below the field | Margin recovered later — junior substitution, change-order pressure, or churn |
| Compliance questions answered with 'we're fully compliant' and no specifics | The risk lands on you when a regulator or auditor asks |
End the RFP with a pilot, not a signature
However well-designed, an RFP measures writing. The strongest procurement pattern treats the RFP as a filter, not a verdict: use it to cut the field to two finalists, then run both (or the leader) through a short paid pilot before committing to the full engagement. Announce this in the RFP itself, 'finalists will be invited to a paid two-week pilot; full award follows pilot evaluation.' That sentence improves the honesty of every response you receive, because providers know their claims will meet reality in front of your engineers within weeks, not after the contract is signed.
