Change Request Template: The Fields That Matter

A change request is the record that proposes a change and carries it through approval, implementation and review. A template keeps requests consistent so that approvers know where to look. The risk of a template is length: every field added is a field someone fills with the minimum. Keep only what an approver uses.

The template

• Title: what is changing, in a phrase an operator would recognise.
• Type: standard, normal or emergency. For a standard change, cite the catalogue entry.
• Reason: the problem or benefit that justifies the change.
• Scope: the systems, services and teams affected, and what is explicitly out of scope.
• Requester and implementer: named people.
• Risk: the worst reasonable outcome, the likelihood, whether it is reversible, and the evidence from testing.
• Implementation plan: ordered steps, with owners.
• Rollback plan: the trigger, the steps and the time they take.
• Verification: how success will be measured, and by whom.
• Window: start and end, in a stated time zone, checked against the change calendar and freeze windows.
• Communication: who must be told, and when.
• Approvers: names and decisions with comments and times.
• Outcome: succeeded, partially succeeded, rolled back or failed, with notes and any linked incident.

Keep it usable

• Use a short form for standard changes: catalogue entry, system and time.
• Pre-fill what you can. If the requester is known, do not ask again.
• Link rather than copy. Point to the test results and the runbook.
• Write the outcome the same day. Details fade fast.

Building it in Atlas

For changes delivered as releases, the Release Management record already holds many of these fields: a name, version and type, a start and target day, an owner, the scope, a readiness checklist with required and optional checks, sign-offs with comments, deployments by environment and release notes. Add a required operations check for the rollback plan, and a required check for the freeze calendar if you want it visible in the readiness list. For changes that are not releases, a task with a checklist and a description laid out like the template above gives you a record in the same workspace as your other work.