Website change request template

Why this happens

Website projects change because business priorities change. New campaigns appear, stakeholders add ideas, and technical constraints evolve. Change itself is normal. Margin loss comes from undocumented change. When teams implement requests before recording impact, they disconnect delivery from scope and pricing.

Industry benchmarks show agencies repeatedly absorb over-budget delivery and overservicing when boundaries are unclear (Teamwork.com State of Agency Operations 2023). Standard service agreements treat additional services as a separate approval track for this reason (AIGA Standard Form of Agreement for Design Services).

The template below is not bureaucracy. It is the minimum evidence trail needed to keep client trust and commercial discipline aligned.

Template and workflow

Use one form per request. If multiple changes are bundled, separate them into distinct records so approval, pricing, and scheduling stay clear.

# Website Change Request

Request ID:
Project:
Date submitted:
Submitted by:
Client approver:
Agency owner:

## Change description
[Describe requested addition/modification in concrete terms]

## Business reason
[Why this is needed now]

## Scope impact
- Affected deliverables:
- New dependencies:
- Assumptions changed:

## Effort and cost impact
- Estimated effort:
- Pricing model (fixed/hourly/milestone):
- Additional cost:

## Timeline impact
- Milestones affected:
- New delivery date:

## Severity
(LOW / MEDIUM / HIGH / CRITICAL)

## Decision
(Approved / Rejected / Deferred)

## Approvals
Client sign-off:
Agency sign-off:
Approval date:

Common mistakes

• Request logs without commercial fields. If cost and timeline are missing, approval is uninformed.
• One approval signature only. Both client and agency need explicit approval responsibility.
• Bundling unrelated changes. It hides tradeoffs and makes acceptance ambiguous.
• No severity rule. Teams need escalation thresholds for larger changes.
• No baseline update after approval. Approved changes must update scope and schedule artifacts.

Public-sector and institutional contracting examples consistently show structured request documentation because it prevents ambiguity over what was requested, approved, and delivered (Smithsonian Office of Contracting and Personal Property Management).

How Clariva fits

Clariva helps agencies reduce change volume by tightening scope clarity before kickoff. When requests do appear, pair this template with clear script language and revision rules to keep decisions auditable.

Use the out-of-scope script guide, the revision pricing guide, and the web design scope templatetogether for end-to-end scope control.

Filled example: website scope expansion request

Example scenario: midway through a marketing site redesign, the client asks to add a gated resource center with login, access rules, and analytics tracking. The original scope included public pages only.

• Requested change: Add gated resource center and member login flow.
• Business reason: Sales team needs lead qualification prior to downloads.
• Affected deliverables: New templates, auth states, analytics events, QA cases.
• Cost impact: +€6,200 fixed.
• Timeline impact: +10 business days or phased release option.
• Severity: High (new capability and dependency set).
• Decision options: Approve now, defer to phase 2, or replace existing feature in current scope.

This format keeps tradeoffs visible. Clients can still say yes quickly, but they do so with full context. Teams can still protect schedule, but without framing the conversation as resistance.

How to operationalize the template

1. Store one canonical form: avoid multiple versions in docs, chat, and PM comments.
2. Set response SLA: commit to impact assessments within one business day.
3. Require both approvals: client approver and agency delivery owner.
4. Update baseline after approval: revise scope version and timeline artifacts.
5. Track aging requests: unresolved requests older than one week need escalation.

If you skip the baseline update step, the same request can be relitigated later. The form should not only capture decisions; it should feed your current scope-of-record.

Also define a minimum threshold where requests must be formally logged. Teams that only log large changes often lose margin through many small untracked additions. A low threshold creates discipline before leakage compounds.

Common edge cases and handling rules

• Urgent request with no pricing time: issue a rapid estimate band and confirm full estimate within 24 hours.
• Client says request was implied: attach scope excerpt and classify as ambiguity-to-change decision.
• Stakeholder conflict on value: keep technical estimate separate from business priority debate.
• Multiple small edits in one email: split into distinct line items for approval clarity.
• Delivery already started: stop additional work at the next safe checkpoint and formalize approval.

These rules help agencies keep momentum while staying commercial. The goal is not to block change; the goal is to remove hidden change.

Rollout checklist for agency operations

To implement this template across teams, treat it as an operating standard rather than an optional form. Start with one project type, train account leads on request classification, and review live requests weekly for consistency. The objective is not perfect wording. The objective is consistent decision quality.

• Publish one shared change request template with locked required fields.
• Assign request owner on every project responsible for impact assessment quality.
• Define approval SLA targets so requests do not stall delivery planning.
• Track approved, rejected, and deferred requests as separate categories.
• Review monthly data: average request size, approval cycle time, and unpriced exceptions.

Agencies that treat change logging as performance data tend to improve both pricing discipline and client experience. Faster, clearer decisions usually feel more collaborative than informal yes decisions that are followed by late commercial tension.

Keep the form lightweight, but do not remove impact fields. The minimum effective record always includes scope delta, cost delta, timeline delta, and authorized approvers.

Approval hygiene and auditability

A change request system only works if approvals are auditable. Store each request with version, approver identity, decision date, and baseline reference. When teams cannot quickly answer what changed, who approved it, and when it became active, scope control is effectively informal even if forms exist.

Keep your naming consistent: CR-001, CR-002, and so on. Link every approved request to a scope version update and milestone update. This creates clean traceability for both client communication and internal retrospectives. It also protects teams when memory differs later in the project lifecycle.

Frequently asked questions