The One-Page Assumptions Log That Saves Your Pricing From Clarifications

What is a bid assumptions log?

A bid assumptions log is a one-page record of the key things you’ve assumed to price the contract. It states what you included, what you excluded, and what you need from the buyer to deliver at that price.

It prevents pricing clarifications because it removes “silent” assumptions. The buyer can see your baseline, and your evaluator can score you with confidence.

In this post, you’ll learn what to put in the log, how to keep it to one page, and how to use it during drafting and sign-off so it protects your bid (without turning your response into legal waffle).

Why this matters (and why pricing clarifications are rarely “just admin”)

Pricing clarifications usually land when a buyer can’t reconcile your price with your method. The numbers might look fine, but the assumptions behind them are missing, scattered, or inconsistent.

That creates three problems.

First, time. Clarifications arrive when you’re already busy delivering, and the deadline is often tight. One unclear line in a rate card can trigger five emails and two internal meetings.

Second, risk. In many processes, the buyer can ask you to clarify, but they generally won’t let you rebuild your offer. If your answer implies a material change, you can end up non-compliant. You’ll see how clarification steps get described in real tender packs, for example in this UK tender document section on requests for clarification.

Third, marks. Evaluators score what’s written, not what you meant. If your pricing basis is fuzzy, it can drag down commercial confidence and deliverability.

A lot of authorities already think in “assumptions, dependencies and exclusions” because it sets a baseline for what’s been priced. Here’s an example of an assumptions, dependencies and exclusions schedule used to define the priced position.

Your one-page log is the bidder version of that baseline, written in plain English.

What goes into a one-page assumptions log (without turning it into a novel)

The trick is to log only assumptions that can change price, scope, or risk. If it wouldn’t affect the buyer’s decision, it probably doesn’t belong.

Aim for four tight groups:

1) Service scope assumptions

This is where most pricing confusion starts.

Keep it practical. State what your price includes, at what volume, and to what standard. If the ITT uses a term that could mean two things, pick one meaning and write it down.

If you’re referencing contract language, it helps to mirror how agreements define and interpret terms. Many public frameworks formalise this structure, as you’ll see in documents like this TfL framework agreement template.

2) Volume and demand assumptions

Say what you assumed about:

• number of users, sites, or wards
• call-out frequency
• travel expectations
• operating hours and out-of-hours cover

Put ranges where you can, and state what happens if the buyer exceeds them (for example, “additional units priced at £X”).

3) Dependencies (what you need from the buyer)

Dependencies aren’t excuses. They’re delivery conditions.

Examples include access to sites, nominated contacts, timely data, approvals, or buyer-provided equipment. If a dependency fails, your cost model changes, so it must be visible.

4) Exclusions and optional items

Exclusions stop “we assumed it was included” arguments.

Keep them polite and factual, and link them to the pricing structure. Optional items are useful because they let the buyer add scope without forcing you into a vague all-in price.

To keep it scannable, use a simple table like this.

Area	Assumption (plain English)	Why it matters to price	If different, then…
Mobilisation	Buyer provides site access within 10 working days	Delay adds PM time	Start date moves or change control applies
Volumes	Price covers up to 200 users	Higher volumes increase support load	Add £X per extra 50 users
Travel	1 site visit per month included	Extra travel adds cost	Extra visits at £X per visit

If it doesn’t fit on one page, it’s doing the wrong job.

How to use the log so it prevents clarifications (and protects your score)

A log only works if it’s connected to your answers. Otherwise it becomes “another document” that no one reads until the panic sets in.

Use it in three moments.

During solution drafting (before pricing is “final”)

As you write the method statements, capture assumptions in real time. Don’t wait until commercial day. The delivery team always reveals the truth, usually in a throwaway line like, “We assumed they’d supply the hardware.”

Lock those into the log, then reflect them back in the response where relevant.

During pricing build (to align narrative and numbers)

Every cost line should map to one of three things:

• a stated requirement
• a stated assumption
• a stated option

If you can’t point to the line, it’s a hidden assumption. Hidden assumptions are where clarifications come from.

If your delivery answer says “24/7”, but your price assumes business hours, you’re buying yourself a clarification. Or a loss.

During final review (to spot score-killers)

This is where evaluator thinking matters. At Bidsmithery™, bid support is shaped by both sides of the table, writing bids and evaluating them. That perspective is useful because it highlights what’s hard to mark, where evidence is missing, and where your commercial position reads as risky.

Even if your team writes the bid, an external reviewer can spot the mismatch between what you claim and what you’ve priced, before the buyer does.

The one-page assumptions log checklist (copy this)

Use these prompts as your minimum structure. Keep each line short, and make every assumption measurable.

→ Assumption ID (A1, A2, A3) so you can reference it in answers
→ Statement (one sentence, plain English)
→ Category (scope, volume, dependency, exclusion, option)
→ Priced impact (what cost line it affects)
→ Evidence/source (ITT section, site info, buyer message)
→ Tolerance (what range is included)
→ Change trigger (what makes it chargeable or re-planned)
→ Owner (who in your team confirmed it)
→ Status (open, agreed, clarified, withdrawn)

If you can’t explain an assumption without a long paragraph, it’s probably two assumptions. Split it.

Common mistakes that trigger pricing clarifications

Burying assumptions in the pricing notes. Evaluators and buyers often read the response first. Put the log where it’s easy to find and cross-reference.

Using soft language. Words like “may”, “typically”, and “as required” can be fine in methods, but they’re dangerous in pricing. Replace them with thresholds and ranges.

Contradicting yourself across sections. One team writes mobilisation, another writes staffing, finance writes pricing. Without a single assumptions page, you get three versions of “what’s included”.

Treating dependencies like blame. Write them as delivery needs, not as conditions designed to wriggle out of responsibility.

Forgetting exclusions. If you don’t state what’s out, the buyer may assume it’s in, and you’ll be asked to confirm at the worst time.

Conclusion

A one-page bid assumptions log is simple, but it’s not “nice to have”. It’s how you stop pricing questions before they arrive, and how you make your offer easier to score.

If you want a sharper, evaluator-led check on whether your assumptions, narrative, and pricing match, consider Bidsmithery™ Bid Review retainer support, or the Bid Win Rate Accelerator Training. If you’d like to talk it through first, you can book a fit check call.