Templates › Benefits register
Benefits register
Template id: benefits-register
Responsible skill: value-realisation:benefit-realisation-plan. Benefit statements are written with value-realisation:benefit-hypothesis, owners agreed with value-realisation:benefit-owner and baselines designed with value-realisation:baseline-design.
How to use this template: keep one register per initiative or one for the whole portfolio, in a place the organisation already uses and can secure. Every report and dashboard reads its value figures from this register and keeps no copy of its own. Record owners as roles. Report at team, role or process level only, never for named individuals. Mark everything the organisation has not yet supplied as [To confirm: ...]; never fill a gap with an estimate presented as a measurement. Rows marked "fictional example" show the level of detail expected and must be replaced.
1. Register context
| Field | Value |
|---|
| Register scope (initiative or portfolio) | [To confirm] |
| Approved case or cases covered | [To confirm: case reference and approval date] |
| Register owner (role) | [To confirm: Benefits Realisation Lead or equivalent] |
| Finance contact (role) | [To confirm] |
| Review forum and frequency | [To confirm: for example value review, quarterly] |
| Minimum group size for staff and usage measures | [To confirm: agreed with data protection officer and HR] |
| Edit rights | [To confirm: roles allowed to update entries] |
| Last updated | [To confirm: date] |
2. Benefit statements
Benefit type: time released, quality, financial, experience, risk reduction, capability. Class (financial benefits only): cashable, non-cashable, cost avoidance, revenue.
| ID | Benefit statement (one change, one measure) | Initiative | Type | Class | Strategic outcome served | Owner (role) | Deputy (role) | Dis-benefits recorded |
|---|
| B01 (fictional example) | Median working days from request to issued proposal for the bid team falls | Proposal drafting agent | Time released | Non-cashable | Faster response to customers | Head of bids | Bids operations manager | Added review time for drafts; agent run cost |
| B02 | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] |
| B03 | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] |
3. Measurement
| ID | Measure definition | Baseline (value, window, date) | Baseline design | Target range and date | Method after launch | Data source and owner | Confidence |
|---|
| B01 (fictional example) | Working days from request logged to proposal issued, excluding requests withdrawn | [To confirm: measured value] over six months before launch | Comparison group with before and after | [To confirm: range] by second quarter after launch | System extract plus monthly sample review | Bid tracking system, bids operations manager | Medium |
| B02 | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] |
| B03 | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] |
4. Realisation profile and enablers
| ID | Expected level by period (range) | Enabling changes and decisions | Enabler owner (role) | Enabler due date | Adoption level assumed | Quality guard (if any) |
|---|
| B01 (fictional example) | Q1 none; Q2 partial; Q3 full range | Old proposal template withdrawn; decision on use of released time | Head of bids | [To confirm] | Bid writers using the agent routinely on new requests | Sampled proposals meet the bid quality checklist at no worse than baseline |
| B02 | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] |
| B03 | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] |
5. Status and results
Status: not ready, on track, at risk, off track, realised, retired.
| ID | Measurement point (date) | Result (range) | Evidence reference | Variance against profile | Tolerance | Status | Owner commentary | Action and due date |
|---|
| B01 | [To confirm] | | | | [To confirm] | Not ready | | |
| B02 | [To confirm] | | | | [To confirm] | Not ready | | |
| B03 | [To confirm] | | | | [To confirm] | Not ready | | |
Report each class as a separate total. Never add them together into one headline.
| Class | Planned to date | Realised to date | Evidence standard | Finance agreement (role and date) |
|---|
| Cashable | [To confirm] | | [To confirm] | [To confirm] |
| Non-cashable | [To confirm] | | [To confirm] | [To confirm] |
| Cost avoidance | [To confirm] | | [To confirm] | [To confirm] |
| Revenue | [To confirm] | | [To confirm] | [To confirm] |
7. Overlaps and apportionment
| Benefit IDs sharing an effect | Shared process or population | Apportionment method | Agreed by (role and date) |
|---|
| [To confirm] | | | |
8. Closed and retired benefits
| ID | Closed as realised or retired | Date | Reason or evidence | Handed to (business-as-usual role) |
|---|
| [To confirm] | | | | |
9. Change log
| Date | Change (baseline, target, owner, status) | Reason | Agreed by (role) |
|---|
| [To confirm] | | | |
Credit: Template from CopilotForge by Simon Foote (https://github.com/SimonFoote-greensparx/CopilotForge), licensed under CC BY 4.0. Keep this credit when you share or adapt the template; in your own completed document you may keep it as a footer or remove it.
Download the template (Markdown)