# Website change request template

Use one record for one coherent change. Duplicate the record when separate changes can be approved, scheduled, or released independently.

This is an operational starting point, not legal advice. Adapt contract and approval language for your business and jurisdiction.

## 1. Request identity

- Request ID:
- Project:
- Date submitted:
- Requested by (name and role):
- Client decision owner:
- Agency owner:
- Related scope, ticket, or approved baseline:
- Requested date and the reason for that date:

## 2. Client intake

### Goal

What business or visitor outcome should this change support?

### Location

- Public URL or route:
- Page or screen:
- Section, component, or record:
- Relevant state (signed out, error, menu open, after submission, etc.):
- Current evidence (screenshot, copy, asset, or link):

### Current and requested result

- Now:
- After:

### Approved source material

List the exact copy, facts, images, links, and named fact owner. Do not place passwords, secret values, private customer data, or access tokens here.

### Preserve

Name the nearby content, styling, routes, links, forms, analytics, integrations, accessibility behavior, and responsive states that must remain unchanged.

### Priority

- Business impact if unchanged:
- Urgency or real deadline:
- Is there a safe workaround?

## 3. Agency impact assessment

- Classification: included edit / revision / change request / defect / incident / new scope
- Affected pages, components, content, data, or vendors:
- Dependencies and assets still needed:
- Risks and assumptions:
- Accessibility, search, privacy, or legal review needed:
- Cost or allowance impact:
- Schedule or milestone impact:
- Options or smaller alternative:
- Recommendation:
- Decision: approved / rejected / deferred / clarification needed
- Decision owner, date, and record:

## 4. Execution brief

### Observable outcome

Write one sentence that a person can verify in the finished site.

### Allowed change boundary

List the exact pages, files, components, records, or services that may change.

### Preserved boundary

List the adjacent areas and behaviors that must not change.

### Acceptance checks

- Fact check:
- Scope or diff check:
- Desktop viewport and expected result:
- Phone viewport and expected result:
- Links, menu, form, booking, or checkout checks:
- Keyboard, focus, labels, headings, alt text, contrast, or zoom checks affected by this change:
- Search metadata, URL, redirects, or sharing checks:
- External destination or notification check:

### Stop conditions

Stop and return for clarification if:

- the requested location or approved source cannot be identified;
- implementation requires an unapproved page, component, integration, purchase, access change, or data migration;
- the requested result conflicts with another approved fact or requirement;
- verification would require a real customer action, live payment, secret, or irreversible external action without explicit authorization;
- unrelated changes appear.

### Authority

- May prepare a draft:
- May approve business facts:
- May approve cost and schedule:
- May approve the implementation:
- May release to production:
- May authorize a destructive restore or external action:

## 5. Verification and release record

- Baseline or checkpoint inspected:
- Change summary:
- Evidence captured:
- Checks passed:
- Checks not run and why:
- Unexpected changes found:
- Reviewer and decision:
- Release owner and release record:
- Post-release check:
- New baseline or version:

## Definition of ready

Do not begin implementation until all applicable items are true:

- [ ] One coherent outcome is described.
- [ ] The exact location and current state are identifiable.
- [ ] Approved facts and assets are attached or linked.
- [ ] Preserved areas are named.
- [ ] Commercial and schedule impacts have a decision.
- [ ] Acceptance checks match the change.
- [ ] Stop conditions are clear.
- [ ] The implementer and release owner have the required authority.
- [ ] Sensitive values and private customer data are not in the brief.

## Worked example: change a homepage CTA

Assumptions: a fictional five-page consulting website has a homepage, a contact page, and a contact form. It has no checkout or customer login. The client has supplied final copy and owns the business claim.

- Request ID: CR-014
- Goal: direct qualified visitors to the existing project inquiry form.
- Location: `/`, hero section, primary link visible before scrolling.
- Now: button says “Learn more” and links to `/services/`.
- After: button says “Start a project” and links to `/contact/#project-inquiry`.
- Approved source: exact label and destination approved by the client marketing lead.
- Preserve: hero heading, paragraph, secondary link, image, spacing, navigation, form fields, form recipient, and analytics configuration.
- Impact assessment: included content edit; no new page or integration; no schedule change.
- Acceptance: exact label and destination; unchanged adjacent hero content; visible focus; activation by keyboard; no clipping at representative desktop and phone widths; target form heading receives the visitor; marked test submission reaches the approved destination if submission testing is authorized.
- Stop condition: stop if the anchor does not exist, if the form destination is unknown, or if changing tracking is required.
- Authority: agency editor prepares; client marketing lead confirms copy; agency release owner publishes.