# Repair or rebuild: decision workbook

Use this workbook with the blank comparison CSV to decide the justified scale of work on an existing business website. It records a recommendation for discussion, not an automatic verdict, supplier agreement or approval to build. You can use it with any delivery partner.

If the problem is not yet understood, investigate it before selecting a project. A traffic graph, site age, low enquiry count or broad complaint does not establish a platform limitation. A recommendation can cover different next steps for different requirements.

The files are static. They do not scan, calculate, upload or validate anything. Keep private evidence in your own workspace. Record references rather than credentials or customer personal data. The worked CSV and the example below are entirely fictional.

## 1. Name the requirement

Start with a task the buyer or team needs to complete, such as choosing the relevant service or publishing approved changes. Name the affected page or system and the reason it matters. Distinguish an essential requirement from a preference or future possibility.

Record what was actually observed separately from the suspected cause. Include the evidence date, environment, device, version or account role where relevant. A provider's statement that a task is impossible is an untested claim until the specific restriction and relevant alternatives are examined.

For buyer tasks, observe likely users attempting a realistic task without giving away the answer. That can expose a problem in the journey; it does not alone identify the code or platform change needed. [GOV.UK usability-testing guidance](https://www.gov.uk/service-manual/user-research/using-moderated-usability-testing).

For a decline in Google Search traffic, use the relevant report and compare like-for-like periods and affected pages or queries. Google's guidance describes several possible causes of search declines, so the decline alone cannot select a rebuild. [Google traffic-drop guidance](https://developers.google.com/search/docs/monitor-debug/debugging-search-traffic-drops).

## 2. Compare options against the same task

Use one row for each option under a stable requirement ID. Start with Repair and Rebuild rows in the blank CSV. Add a Structural improvement row if a larger change to content, navigation or templates can retain the current platform. Rename or remove unused options with a reason in the decision note.

For every credible option, ask:

- What work meets the requirement, and what remains outside the scope?
- What existing URLs, content, functions and accounts are retained?
- What evidence supports feasibility? What has not been demonstrated?
- What will the owner supply or approve, and what access is needed?
- What estimate covers this exact scope? Who supplied it, when, with what exclusions and assumptions?
- What are the delivery dependencies, recurring costs, maintenance and handover responsibilities?
- What common acceptance evidence would show that the requirement was met?

Keep provider estimates and sources in the record. A missing estimate is Unknown, not zero. Do not compare a small visual update with an entire replacement as though they solve the same requirement. Do not count complaints or average them into a rebuild score.

For replacement, include preservation and transition work even when the visual design is the main concern. A rebuild does not require changing every URL. If addresses change, follow the separate preservation plan; this workbook is not a redirect or launch checklist. [Google site-move guidance](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes).

## 3. Treat metrics as evidence with limits

For performance reports, retain the tested address, URL or origin scope, device, date, metric, tool and data type. PageSpeed Insights distinguishes controlled lab tests from eligible real-user field data covering the previous 28 days; field data may be unavailable or reported at origin level. Keep those limits visible instead of treating different reports as equivalent. [PageSpeed Insights documentation](https://developers.google.com/speed/docs/insights/v5/about).

A performance score does not measure buyer demand or whether the platform must be replaced. Google's page-experience guidance also distinguishes good experience from a guarantee of top rankings. Improving an actual performance problem can be worthwhile without implying a complete rebuild or a commercial result. [Google page-experience guidance](https://developers.google.com/search/docs/appearance/page-experience).

These are decision controls we suggest, not a repair-versus-rebuild test prescribed by Google or GOV.UK. The relevant provider must assess the actual implementation.

## 4. Write a bounded recommendation

Choose a next step: Repair, Structural improvement, Rebuild, Investigate first or Defer. Explain which requirements it covers, why the alternative is not selected at this stage, what remains unknown and what would change the decision.

Use “candidate” or “proposed” when feasibility or terms are not agreed. Planning acceptance evidence is different from recording a passed check. A commercial agreement and launch authorization happen separately.

## Blank recommendation note

- Business / current site:
- Prepared by / date / version:
- Requirements considered and priority:
- Evidence references and coverage limits:
- Proposed next step for each requirement:
- Why this is proportionate to the requirement:
- Alternative options considered and reasons not selected now:
- What stays; what changes; what remains outside scope:
- Feasibility evidence and assumptions still to demonstrate:
- Comparable estimates, source/date and any missing terms:
- Owner input, dependencies, ongoing responsibilities and handover:
- Acceptance evidence required later:
- Open questions, each with owner, next action and decision point:
- Evidence that would change the recommendation:
- Nonessential work deferred and condition for reconsidering it:
- Person reviewing the recommendation / next discussion:
- Current stage: Preparing a recommendation; no build or launch approval

Keep a decision history when the scope changes: earlier decision, new evidence, affected work, cost/schedule consequences and who agreed the revision. Do not erase an unresolved question just because an option has been preferred.

## Field guide for the CSV

Import as UTF-8 with all columns treated as text. The supplied files contain no formulas. Use a unique option ID within each requirement, and repeat that requirement's task, observation and evidence so rows remain understandable when filtered. Duplicate rows for further options and requirements.

| Field | What to record |
| --- | --- |
| record_kind | Working record for your own entries. Every supplied worked row says Fictional example. |
| requirement_id | Stable reference such as R1. The same requirement ID groups comparable options. |
| required_task | The buyer or team task, its importance and affected page/system. |
| observation | What happened and under which conditions. Keep the suspected cause separate. |
| evidence_reference | Source or secure file reference, date and relevant scope. Missing evidence stays explicit. |
| constraint_status | Observed symptom, Demonstrated restriction, Untested claim or Not established. A symptom is not proof of its technical cause. |
| option_id | Repair, Structural improvement or Rebuild; use a distinct label for any other alternative. |
| proposed_work_and_retention | What this option changes, preserves and excludes. |
| feasibility | Evidence that the option can meet the task, its assumptions and what still needs demonstration. |
| delivery_and_ongoing_terms | Estimate and source/date, scope assumptions, owner input, schedule, recurring responsibilities and handover; use Unknown for missing terms. |
| acceptance_evidence | The evidence to request after delivery. Use the same requirement-level criteria across options; do not mark a planned check passed. |
| unresolved_questions | Named open questions and dependencies that could change the option or decision. |
| assessment | Candidate, Not selected at this stage, Investigate first or Deferred, with a reason. This is a manual assessment, not a scored output. |
| owner_and_next_action | Who acts, what they do and when the question must be reconsidered. |

If importing entries from elsewhere, treat them as text and check for spreadsheet formula characters before sharing. No worksheet can verify a claim just because its evidence field has been filled in.

## Fictional worked example: Bay Lane Advisory

**Every business fact, note and conclusion in this exercise is invented.** `baylane.example` is an illustrative address, not an inspected site. No usability session, platform inspection, performance test, implementation or customer result occurred. The scenario inputs below demonstrate reasoning; they are not links to actual evidence files or reports.

The imagined service business wants buyers to distinguish advisory work from implementation, its team to publish approved service changes, and relevant pages to perform adequately for visitors. The current decision concerns scope, not selecting a supplier or platform.

### Scenario inputs F1 to F3

- **F1, fictional content and template note:** the scenario stipulates that the current site combines two offers on one page, while its existing page template supports separate service pages and ordinary navigation links. This is an assumed capability in the exercise, not a tested finding. No buyer usability evidence is supplied. Date: not applicable, fictional exercise. Environment: imagined current site.
- **F2, fictional editing note:** a team member cannot publish an approved service change with their current account. A provider attributes that difficulty to the platform. Account role, configuration, template restrictions and supported alternatives have not been reviewed. The symptom is supplied as a scenario input; the claimed platform restriction remains untested. Date: not applicable, fictional exercise. Environment: imagined editing account.
- **F3, fictional performance note:** a single lab report is described as flagging slow loading, but the URL, date, device, metric and conditions are missing. No usable field data is supplied. There is no numeric score or executed performance report in this exercise. Performance cause and repair scope are not established.

### R1. Help buyers choose the relevant service

**Proposed next step: request a bounded repair proposal.** F1 makes it reasonable within the exercise to consider separating the service explanations and updating navigation on the current site. Keep useful content, existing appropriate URLs, enquiry handling and the platform. New page addresses and links would need review; the exercise does not approve a particular URL change.

A rebuild could address the same content task, but the record contains no demonstrated need to replace the platform for this requirement. Neither route automatically supplies accurate service facts or proves buyers will understand them. Ask both options to use the same acceptance evidence: approved scope for each service, an understandable route to the appropriate page and a usable enquiry step.

The repair is a candidate, not a confirmed implementation. The business lead must supply the service boundaries; the delivery partner must demonstrate the relevant template and navigation changes, assess preservation implications and provide terms before work is commissioned. Reconsider replacement if that review shows the required structure cannot be supported practically, with evidence and comparable scope.

### R2. Publish approved service changes

**Proposed next step: investigate first.** F2 establishes an imagined blocked editing task but not its cause. Examine the necessary account role, configuration, training and template behavior in a safe review environment before comparing a targeted change with platform replacement.

No access change, training result or editing test has occurred. The business lead and delivery partner should agree the task and review conditions before scope approval. Acceptance would later require the intended editor to complete that agreed task with the agreed permissions and guidance. Replace the platform only if the evidence and complete comparison support that decision.

### R3. Investigate the reported loading problem

**Proposed next step: gather usable evidence.** F3 cannot establish the affected scope or cause. The delivery partner should obtain a dated report with URL/origin scope, device, metrics and conditions, then investigate the actual issues. Preserve unavailable field data as unavailable.

Neither targeted optimization nor replacement is justified as an approved solution by this incomplete report. Compare remedies after the evidence is usable, with the same agreed performance scope and before/after conditions. A measured technical improvement would still be separate from search or enquiry outcomes.

### Worked recommendation note

- Requirements: R1 service choice, R2 approved editing and R3 reported performance. Priority and delivery order must be confirmed with the business lead.
- Proposed action: ask for a bounded repair proposal for R1; investigate R2 and R3 before deciding their scope.
- Replacement decision: not supported by the current exercise as a whole-site commitment. R2 or R3 could change that assessment if demonstrated constraints and a like-for-like comparison justify replacement.
- What stays for the R1 candidate: the platform, useful material, appropriate existing addresses and enquiry route, subject to scoped review. The exact new page plan is not yet approved.
- Missing terms: estimates, cost, schedule, ongoing support, owner review time and handover are Unknown for both options. No savings or delivery-duration claim is made.
- Open questions: Q1, demonstrate R1 feasibility and preservation implications; Q2, identify the cause of the editing block; Q3, obtain and investigate comparable performance evidence; Q4, obtain matched scope, estimates and responsibilities.
- Owners and decision point: business lead confirms tasks and supplies facts; prospective delivery partner investigates and scopes options; resolve material dependencies before authorizing the affected work.
- Deferred work: no purely visual replacement is included in this decision. Reconsider it only with an explicit business requirement and separately agreed scope.
- Current stage: ready for a scope discussion and targeted investigation. No repair, rebuild, publication or launch is approved.

The worked CSV has two options for each requirement. Its six rows share these inputs and limits. There is no overall score and no fictional claim that the business saved money, kept rankings or received more enquiries.