Benefit quantification without controlled data is the disciplined expression of observed change, modeled value or future target when the evidence cannot establish a controlled causal effect. It identifies the population, baseline, comparison, period, measure, source, calculation, uncertainty and alternative explanations behind each number. It labels descriptive results separately from attribution and forecasts. A precise bounded claim can still be useful to an evaluator; the absence of a control group limits what the number proves, not whether the team may report verified observations.
Buyers ask for outcomes, and proposal teams want numbers. The available evidence is usually messier than the sentence they hope to write. A client tracked cycle time after a rollout but changed staffing at the same time. A case study reports fewer errors without a stable denominator. A product team calculated “hours saved” from a demonstration rather than production logs. A benchmark comes from another sector. A target is copied into the executive summary as though it were achieved. Adding a percentage sign does not cure these weaknesses. It can turn an honest observation into an unsupported causal promise, conceal the population and time period, or convert assumptions into contract exposure.
Start by classifying the number before polishing the sentence. An observed result says what changed in a defined setting. An attributable effect says the intervention caused some of that change and needs a credible counterfactual or causal design. A modeled estimate converts inputs and assumptions into a range. A benchmark describes another population. A target states what delivery will seek and how it will be measured. Do not promote one class into another. Build the smallest calculation the evidence can support, show the denominator and period, test sensitivity to material assumptions, and state the relevance gap between the source setting and the buyer. When past impact cannot be isolated, offer a transparent mechanism and measurement plan instead of fabricated certainty.
Evidence class
Classify the number before choosing the verb
Use an evidence label that controls the grammar of the claim. An observation can say that median handling time fell between two defined periods for a named sample. It cannot by itself say the solution caused the reduction. An impact estimate needs a design that addresses what would have happened without the intervention. Current UK government evaluation guidance makes this distinction explicit: monitoring can establish that an outcome changed, while attribution asks whether the intervention was responsible. The Magenta Book describes experimental and quasi-experimental approaches that use a comparable unaffected group or period as a counterfactual. Where that design is absent, causal confidence must fall.
Modeled estimates and targets solve different problems. A model can estimate avoided effort if current volume, time per case, adoption and loaded cost are supplied, but the answer remains conditional on those inputs. A target expresses an intended future state and needs authority plus a measurement plan. A benchmark reports what occurred elsewhere and needs a relevance statement. Preserve these labels in the evidence record, not only in a footnote. Reviewers often remove caveats during shortening; if “estimated” or “observed” is the only word preventing a causal overclaim, it belongs next to the number wherever the claim appears.
| Class | Permitted statement | Unsupported upgrade |
|---|---|---|
| Observed result | The measured value changed in this setting | Our solution caused the change |
| Attributable effect | The evaluation estimates an intervention effect | The effect applies everywhere |
| Modeled estimate | Inputs produce this range under assumptions | These savings will be realized |
| External benchmark | A comparable source reported this result | The buyer will achieve it |
| Target | Delivery will aim for and measure this level | This level exists today |
Measurement
Reconstruct the denominator, period and operating context
Rebuild each result from its source. Record the service or workflow, population, eligibility rule, sample size, measurement window, baseline window, statistic, numerator, denominator, unit, source system, data owner and extraction date. Note missing records, manual adjustments and excluded cases. A claim that error rate fell from 8% to 3% is incomplete until the reader knows whether the denominator is transactions, fields, documents or reviewed cases, whether the same sampling rule applied in both periods, and whether severity changed. Prefer absolute counts beside percentages when they help the evaluator judge scale.
List concurrent changes and selection effects. Staffing, training, policy, demand mix, seasonality, backlog clearance and changed measurement can all move an outcome. This does not make the observation useless. It changes the verb and confidence. If only successful sites adopted the process, label that selection. If the baseline used a peak month, show a longer series or explain the choice. If the source is a client statement, preserve the approved wording and date instead of reverse-engineering unsupported precision. A result with transparent limits is more credible than a stronger sentence detached from its record.
- Name the population and inclusion rule.
- Show numerator, denominator and absolute scale where useful.
- Use comparable baseline and follow-up windows.
- Record concurrent operational and measurement changes.
- Keep the approved source wording and extraction date.
Model
Model the smallest defensible range and expose the assumptions
Begin with a unit the source can support. If a timed study shows a task required between four and six fewer minutes in the tested configuration, report that interval before annualizing it. To estimate annual released hours, multiply by eligible annual task volume and expected adoption, then divide consistently into hours. To estimate financial capacity, apply an approved loaded-cost or alternative-value assumption and state whether released time is expected to reduce spend, avoid future hiring or free capacity for other work. These are different benefits. Time released does not automatically become cash saved.
Create low, central and high cases only for variables that matter. Vary task volume, adoption, time effect, persistence, error rework and unit value where they materially change the result. Avoid combining benefits that share the same mechanism: fewer handling hours and lower labor cost may be two expressions of one effect, not additive value. Keep implementation effort, ongoing control and displacement costs on the same time basis as benefits. The UK AQuA Book emphasizes documenting data, assumptions, decisions, verification and validation and treating uncertainty as inherent in analytical outputs. Apply that discipline in miniature to every proposal model.
Round to the precision supported by the inputs. A modeled range of roughly 2,000 to 2,600 hours is more honest than 2,347.8 when demand and adoption are estimates. State which input drives the range and what evidence would narrow it. If a client cannot release the source data, have an authorized owner validate the calculation and disclose the evidence boundary. Do not create a composite “ROI” by mixing verified client observations, buyer-supplied volumes and vendor assumptions without labeling each layer.
| Input | Evidence status | Sensitivity question |
|---|---|---|
| Eligible volume | Measured, buyer-supplied or assumed | What if demand is lower? |
| Effect per unit | Observed, attributed or benchmarked | Does it persist at scale? |
| Adoption | Measured or planned | Which users and tasks are excluded? |
| Unit value | Approved cost or opportunity value | Is this cash or capacity? |
| Duration | Contract or evidence period | Does the effect decay? |
| Cost to realize | Implementation and ongoing control | Is timing aligned? |
Buyer relevance
Translate the mechanism, then commit to measurement
Explain why the source result is relevant without claiming equivalence. Compare workflow steps, user population, transaction complexity, baseline maturity, operating hours, regulatory controls, language, integrations and adoption conditions. The transferable part may be the mechanism rather than the percentage: pre-population removes repeated entry; a validation step catches missing data earlier; structured routing reduces handoff delay. State which buyer data is needed to estimate scale. If differences are material, use the case study to prove capability and the model only as an illustrative scenario, not as a buyer forecast.
For a future benefit, define the measurement before the target. Specify outcome and process measures, baseline period, population, unit, source, owner, cadence, quality checks and decision threshold. Separate leading indicators such as adoption and completion from outcomes such as cycle time, error or service access. Identify how changes in demand and mix will be handled. Where attribution matters, propose a proportionate evaluation design, such as phased introduction or a credible comparison, subject to buyer agreement and ethics. Where no counterfactual is practical, say that the review will test contribution and alternative explanations rather than promise causal proof.
Treat optimism as a measurable risk. The 2026 Green Book describes a systematic tendency to overstate benefits and recommends explicit adjustment based on historical forecast error where possible. A bidder need not import government adjustment percentages into an unrelated proposal. It can use the principle: compare prior forecasts with actual delivery, reduce the claim or widen the range, and show the assumptions that remain. End with a result the buyer can govern: an observed source fact, a bounded planning estimate, a target with authority, and a method for learning whether the proposed mechanism delivers in this contract.
- Compare source and buyer conditions before transferring a result.
- Lead with the proven mechanism when the percentage is not transferable.
- Define baseline and metric before approving a future target.
- Separate adoption signals from buyer outcomes.
- Use actual-versus-forecast history to temper optimism.
What good looks like
Useful outcomes from quantify proposal benefits without controlled data
- Every benefit number is labeled as observation, attributable effect, model, benchmark or target.
- Claims expose population, baseline, comparison, period, unit, source and calculation.
- Causal language is reserved for evidence that can address a credible counterfactual.
- Modeled value uses ranges and sensitivity for assumptions that materially change the result.
- Case-study relevance and differences from the buyer’s environment are explicit.
- Future benefits have a baseline, owner, data source, review cadence and decision use.
Operating model
How to run the work
- 01
Classify the evidence before the claim
Decide whether the available number is an observed change, attributable effect, modeled estimate, external benchmark or future target. Apply only the language permitted by that class.
- 02
Reconstruct the measurement record
Capture population, sample, baseline, comparison, period, unit, numerator, denominator, source system, exclusions, concurrent changes and data-quality limitations.
- 03
Calculate the narrowest supported benefit
Reproduce the arithmetic, normalize units, avoid double counting and retain a result range where assumptions or sampling make a single point misleading.
- 04
Translate evidence to the buyer context
Explain which workflow mechanism may transfer, which source conditions differ, and which buyer variables determine whether the result can recur.
- 05
Commit to measurement rather than invented impact
For future outcomes, define baseline establishment, target, metric specification, data owner, review point, attribution limit and corrective decision before making the promise.
Evaluation
Questions that change the decision
- What type of number is this: observation, causal effect, model, benchmark or target?
- Which population, process version and time period produced the data?
- What baseline or comparison exists, and is the denominator stable?
- Which other changes could explain part of the observed outcome?
- Which assumptions convert an operational measure into time, money or social value?
- How sensitive is the result to volume, adoption, unit cost and persistence?
- Which source conditions match or differ from the buyer’s environment?
- What will be measured after award, by whom, and for which decision?
Failure modes
Where teams lose control
A before-and-after change may be described as caused by the offered solution.
A percentage may hide a tiny, selected or changing denominator.
Projected hours saved may assume every released hour becomes productive capacity.
Monetary value may multiply overlapping benefits and count the same effect twice.
A client benchmark may be applied to a buyer with different volumes, maturity or constraints.
An average result may conceal users or locations that experienced no benefit or harm.
A target may be written as guaranteed performance without delivery and commercial authority.
False precision may make weak evidence look stronger while increasing contractual exposure.
Measurement
Measure the finished job
Measure the completed workflow, including review effort and exceptions. Output volume on its own is not evidence of a better process.
- quantified claims with explicit evidence class
- claims with population, denominator, period and source
- modeled benefits with assumption and sensitivity record
- case-study results with buyer-relevance differences disclosed
- causal verbs supported by an approved evaluation basis
- targets with baseline and measurement owner
- benefit claims changed or removed during evidence review
Questions
Common questions
Can we report a before-and-after improvement without a control group?
Yes, as an observed change with the population, periods, measure and concurrent changes disclosed. Do not say the solution caused the full improvement unless the evaluation supports attribution.
How should we express estimated savings?
Show the formula, evidence status of each input, low and high cases, costs to realize and whether the value represents cash, avoided cost, capacity or another benefit. Avoid precision beyond the inputs.
Can a benchmark from another client support our proposal?
It can support capability or a planning range if you explain differences in workflow, population, volume, maturity and constraints. It does not prove that the buyer will achieve the same result.
What if the buyer asks for a guaranteed benefit?
Define the metric, baseline, controllable conditions, attribution, exclusions, data, remedy and authority before accepting a guarantee. Route the commitment through delivery, commercial and legal approval rather than converting an estimate into a promise.
Sources
Primary references
- Magenta Book: central government guidance on evaluation HM Treasury and Evaluation Task Force
- Quality in policy impact evaluation UK Evaluation Task Force
- AQuA Book guidance on analytical quality assurance HM Treasury
- The Green Book 2026 HM Treasury
About the author
Tony Kim
Tony writes about applied AI, dependable product engineering and the systems that turn complex response work into controlled delivery.
Ziva
Proposal software for source-grounded RFP, RFI, DDQ and questionnaire response work.
Bid, proposal, presales, security and compliance teams. Start with the workflow, constraints and evidence you already have.
