Pricing models & rate caps: how to stay competitive and profitable

Clients say to me, “We’re capped at £X a day on this lot—how do we price to win without killing our margin?” Here’s the straight answer: rate caps are ceilings, not strategies. Misread them and you either underprice yourself into a painful delivery, or overprice and get screened out before anyone reads your method statement. The trick is to treat caps as guardrails and build a pricing system that can flex for each call-off while protecting margin.

What a “rate cap” really is (and isn’t)

  • A maximum, not a promise. It’s the most a buyer can pay under the framework, not what they intend to pay.
  • A control on inputs, not outcomes. Caps usually apply to labour categories (e.g., “Engineer Day Rate”), not the total solution price. Buyers still expect competition at call-off.
  • A compliance gate. Exceed it and you’re non-compliant. Meet it and you’ve only passed the first filter—now you need to price to win.

Across CCS/YPO/NHS SBS/Everything ICT, the pattern’s the same: framework sets the ceiling; mini-competition or catalogue direct award drives the actual rates down.

Why agencies get it wrong

  1. They treat the cap as the price. If you put every role at the cap, you’ll lose to anyone who sharpened a pencil.
  2. They price “to get in the door” on the framework, then forget to model delivery reality at call-off (TUPE, clearances, travel, on-call, tooling, 3rd-party fees).
  3. They ignore utilisation. A £400 “profitable day rate” at 100% utilisation becomes a margin bleed at a realistic 70–80%.
  4. They miss indexation rules. Some frameworks allow annual uplifts (CPI, ONS indices); others don’t. If you don’t model that, year 2 wipes your margin.
  5. They don’t separate “cap day rates” from “output pricing.” You can be rate-cap compliant yet still price the outcome (fixed fee, unit price, banded volumes) to protect margin.

Build a pricing model that can’t lie to you

Here’s the model I install for clients. Use your own numbers, but keep the structure.

1) Cost to serve per role (fully loaded).
For each labour category, calculate:

  • Base salary
  • On-costs (ER NI, pension, holiday, bank hols, training, certifications)
  • Delivery overhead (tooling, laptops, licences, vetting, CE+/ISO maintenance)
  • Central overhead allocation (Ops, finance, bid, management)
  • Target utilisation (e.g., 75% billable)

Worked example (illustrative):
Engineer salary £40k. On-costs 27% → £50.8k.
Delivery overhead £4k. Central overhead allocation £6k. Cost base = £60.8k.
At 75% utilisation, billable days ≈ 0.75 × 220 = 165 days.
Floor day rate (break-even) = £60,800 / 165 = £369.
Add target margin 20% → £461 target.
If the cap is £450, you’ve learned something vital: either increase utilisation, reduce overhead, redesign the delivery model, or no-bid for roles priced at the cap. Do that maths before you promise a rate.

2) Three price points per role.

  • Floor: break-even (never submit below).
  • Target: healthy, sustainable margin for BAU.
  • Stretch: for complex/urgent/low-competition call-offs.
    All three must sit ≤ cap. If they don’t, fix the model—not the spreadsheet formatting.

3) Outcome pricing library.
Where the framework permits, convert capped inputs into outputs that favour you:

  • Per device/user/site/month,
  • Per incident/resolution band,
  • Per installation/mobilisation stage,
  • Fixed-fee sprints for design/build.
    You remain cap-compliant on labour, but the unit economics reflect your efficiency.

4) Assumptions & exclusions log (non-negotiable).
Every price carries an assumption log: volumes, geographies, security clearances, on-call windows, SLAs, tooling included/excluded, third-party charges, TUPE status, transition effort, and change control trigger points. No log = you are volunteering to deliver more for the same money later.

5) Price-risk register.
List the risks that hit your P&L (delays, unvetted staff, travel spikes, scope creep, client-side dependencies). Give each a probability × impact and either:

  • bake a contingency into the price, or
  • create a paid option (e.g., accelerated onboarding, out-of-hours premium).

How to use caps to your advantage at call-off

  • Exploit category design. Often you can use cheaper roles for chunks of the work. Build a pyramid: fewer high-cap roles, more mid/low roles, same outcomes.
  • Band your volumes. Offer tiered unit pricing (e.g., 1–100, 101–500, 501–2,000). Buyers like visible savings; you protect margin at small volumes.
  • Offer options instead of padding. Keep the core price keen and put risky/rare demands behind priced options (on-site within four hours, overnight changes, major-incident war room).
  • Show cost drivers transparently. “If you can accept a 6-hour response instead of 4, price reduces by £Xk.” It wins trust and often wins the bid.
  • Use indexation if allowed. If the framework permits CPI-linked uplifts each anniversary, state it in your call-off pricing and contract schedule.

Price scoring: don’t guess, model it

Most evaluations use a relative formula (e.g., lowest price scores 100, others score proportionally). Build a small price-to-win model:

  1. Assume a competitor spread (±10–20%).
  2. Simulate the scoring with the published formula.
  3. Find the price that gets you the points you need given your expected quality score—without crossing your floor.

If price is 30% of the weight and your narrative is strong, you may not need to be the cheapest—you need to be cheap enough. The model shows where that is.

Common cap pain points (and fixes)

  • Travel & subsistence (T&S). If the framework caps day rates and disallows T&S recharges, your “cheap” price just got expensive to deliver. Fix: local delivery footprint, remote-first design, or explicitly priced site days.
  • Unsocial hours. Night work and out-of-hours responses annihilate margin unless you have a premium built in. Fix: published OOH multipliers or a separate OOH service line.
  • Security clearance & vetting. BPSS/DBS/SC lead-time and cost are real. Fix: pre-vetted pool, priced onboarding, or a mobilisation fee.
  • TUPE. If staff transfer to you, your cost base is whatever you inherit. Fix: TUPE due diligence before committing to rates, plus a variation mechanism in the call-off.
  • Third-party tools. If the buyer wants a specific platform, your licence/reseller economics matter. Fix: show pass-through with an admin margin or seek buyer-held licences.

The playbook (use this every time)

  1. Pull the cap table for the lot.
  2. Run your floor/target/stretch model against it.
  3. If any core role can’t hit target under the cap, redesign delivery; if it still doesn’t work, no-bid.
  4. Decide the pricing shape (inputs vs outcome units; fixed vs variable).
  5. Build the assumption log and price-risk register.
  6. Add options for the “what-ifs” (OOH, surge, extra geos).
  7. Model the price scoring so you know your points at your chosen price.
  8. Sanity-check with delivery (not just sales).
  9. Lock approval thresholds (who can go below target; who can approach floor).
  10. Publish the call-off price pack (narrative + schedules) and store it in your SSOT.

What “good” looks like

  • Your team can quote within 24–48 hours because the numbers aren’t guesses; they’re calculated.
  • You rarely need to renegotiate because your assumption log and options cover the edges.
  • Your margins hold in delivery because you priced utilisation, overhead and risk like adults.
  • You don’t fear rate caps; you design around them.

Bottom line

Rate caps aren’t the enemy. They’re a constraint that rewards the disciplined. Price lazily and you’ll lose—or worse, you’ll win and bleed. Build the model, set the floors, convert inputs to outcomes where the rules allow, and show buyers the trade-offs in plain English. That’s how you stay competitive and profitable under government frameworks.

‍

Back To Hub