Change requests

Change requests

A change is anything bigger than a ticket — work that needs planning, approval, scheduling, and a rollback plan. Examples:

• Migrating staff email from one provider to another
• Replacing the wifi access points across an academy
• Patching the SIMS server during a maintenance window
• Rolling out a new MDM profile to every Chromebook
• Re-cabling the IT suite over half-term

If a single agent can do it without anyone else needing to know, it’s a ticket. If it touches multiple people, systems, or weekends, it’s a change.

The lifecycle

State	What it means
Draft	You’re still writing it; not visible to anyone else
Pending approval	Submitted; waiting on the configured approvers
Scheduled	Approved; will run at a specific time
In progress	Currently happening
Completed	Done, change applied
Reviewed	Post-implementation review done
Rolled back	Failed; the rollback plan was executed
Cancelled	Pulled before starting
Rejected	Approvers said no

The change moves through these via buttons on the change page — you can’t skip steps.

Filling out a change

The form asks for:

• Title — single-sentence description
• Summary — one-paragraph background explaining why the change is needed
• Type — Standard / Normal / Emergency (drives which approval chain applies)
• Risk — Low / Medium / High; high-risk changes require approval
• Impact — None / Minor / Outage
• Downtime required — flag; automatically requires approval when ticked
• Window — scheduled start and end times
• Implementation — how are we doing it? Step by step.
• Rollback — what we do if it goes wrong, half-way through
• Test plan — how you’ll verify success once the change is done
• Affected services — comma-separated list of affected services
• Affected schools — tick any academies impacted
• Linked entities — external references (label + URL) for runbooks, vendor tickets, or anything that depends on this change

A good change has a rollback plan that actually works. If you can’t articulate what to do when half the migration completes and the network drops, you’re not ready to schedule.

Approvals

Standard changes (template-driven, low-risk, well-understood) often pre-approve. Normal changes need the chain configured in admin → Approvals. Emergency changes can be self-approved by anyone with helpdesk::change::emergency permission, but every emergency change is auto-flagged for review.

The change calendar

The Changes calendar view (agent-side) shows every scheduled and in-progress change across the trust in a monthly calendar grid — the source of truth for “is anything happening tonight?”. Change-freeze periods are highlighted on the calendar. End-users can see upcoming changes as a list via the portal’s changes page.

Use the calendar to spot conflicts: two changes overlapping on the same service, a change scheduled inside a freeze, a change starting at a school’s break time.

Post-implementation review

After every Completed change, do a PIR — even five sentences:

1. Did it go to plan?
2. What surprised us?
3. Did we need the rollback plan?
4. What would we do differently?
5. Anything to feed into the next change?

PIRs are where the team gets better. Skipping them turns every change into a fresh adventure.