How Approvals Should Work for Changes (Simple Process)

Last updated

May 13, 2026

Reviewed by

IT Service Delivery Lead

Speakable Summary

Approvals should be fast, written, and tied to impact. Book a Fit Check to define who approves changes and what information must be included.

Opening

Most downtime caused by IT is not malicious. Itis caused by changes made without clear approval, clear rollback, and clear verification.

Most SMBs do not need bureaucracy. They need one simple rule. If a change can disrupt work or create cost, it must be approved in writing first.

This page explains a simple approval process you can use with any IT provider. It keeps decisions fast and prevents surprise invoices.

Direct Answer

Approvals should work through a short-written request that states impact, cost, and rollback. The business approves before the change begins and the ticket records what was approved and what was verified.

‍

What approval and change mean

Approval definition
Approval is a written yes from the business before a change begins.

Change definition
A change is any action that modifies configurations, access, systems, vendors,or costs.

‍

The simple approval process

Step 1: All changes start as a ticket

No texts, no hallway requests, no side emails totechs. The ticket is the system of record.

The ticket should state what is being changed and why. If it is not in a ticket, it is not approved.

Step 2: The provider submits a short change summary

The summary should fit in one screen. It should include only what a decision maker needs.

Change summary must include

●    What is changing

●    Why it is needed

●    Who is impacted

●    When it will be done

●    What could break

●    Rollback plan

●    Cost or billing method

●    How success will be verified

Step 3: The business approves in writing

Approval should be a simple yes reply in the ticket thread or email-to-ticket. No verbal approvals.

Approval must come from the assigned approver. If the approver is unavailable, the backup approver is used.

Step 4: Execute in a change window when possible

If the change can disrupt work, schedule it outside peak business hours when possible. If it must happen during business hours, set expectations and provide an update cadence.

For high-impact changes, require a “go” message before starting. This prevents accidental cutovers at the wrong time.

Step 5: Verify and document closeout

A change is not complete until it is verified. Verification means a real workflow works again, not just “the change applied.”

Closeout notes must include

●    What was done

●    What was verified

●    Any follow-up tasks

●    Any new documentation created or updated

‍

Who approves what

One approver rule

Pick one primary approver and one backup approver. This keeps approvals fast and avoids committee delays.

The approver is usually the Owner, COO, Managers, or Finance lead depending on the business.

‍

Approval categories SMBs should use

Category 1: Routine changes

Routine changes are low-risk and low-cost. These can be pre-approved in the agreement.

Routine changes still require a ticket. They do not require special approval each time.

Category 2: Business-impact changes

Business-impact changes can disrupt work or affect multiple users. These require explicit approval before execution.

They also require a change window and rollback notes.

Category 3: Cost-impact changes

Cost-impact changes create new recurring charges or significant one-time spend. These require explicit approval from the budget owner.

They should include the monthly cost, any annual commitment, and cancellation terms.

‍

Approval and rollback failures to avoid

Work starts before approval

If work begins before approval, the business loses control and invoices become surprises. The rule is simple. No approval, no start.

Approvals are verbal only

Verbal approvals create disputes later. Written approvals protect both sides.

No rollback exists for risky changes

Risky changes without rollback are avoidable downtime. If rollback cannot exist, that risk must be stated clearly before approval.

‍

‍

Common Questions

Do we need approvals for every change?

No for routine low-risk changes that are pre-approved in scope. Yes for anything that can disrupt work or create new cost.

Do approvals slow down support?

No because routine work stays fast. Approvals protect the business for changes that create risk.

What’s the difference between support and a change?

Support restores normal operation. A change modifies the environment or adds scope.

What if something is urgent during an outage?

Containment and restoration comes first. Any change that expands scope still gets written approval, even if the approval is short.

What if a vendor requires a change?

Vendor requests can still create risk. The change summary should include vendor case number and expected impact.

How do we prevent surprise invoices?

Approval must include cost method and scope. If cost is not stated, it is not approved.

Who should be the approver?

Choose the person who can say yes quickly and understands impact. Use a backup approver for continuity.

How do we handle after-hours changes?

After-hours work should be planned. Approval should include the window and communication plan.

What is the simplest approval evidence?

A written yes inside the ticket thread. That is enough for clarity.

What is a Fit Check?

A Fit Check defines your approver, categories, and templates. It clarifies what is pre-approved and what requires signoff.

‍

Key terms in plain English

Approval: A written yes before a change begins.
Change window: A scheduled time for changes.
Rollback: Steps to undo a change if it fails.
Verification: Confirming the workflow works after the change.
Scope: What is included and excluded in your agreement.
Ticket: The system of record for requests and decisions.
Pre-approved: Routine changes allowed under monthly scope.
Closeout notes: Summary of what happened and what was verified.

‍

When a change needs explicit approval

‍

‍

Copy/paste approval template

Change request
What is changing:
Why:
Who is impacted:
When:
Risk and what could break:
Rollback plan:
Cost or billing method:
How we will verify success:
Approval: YES or NO
Approved by:
Approved date and time:

‍

Common mistakes

• Starting work before approval and fix it by using the ticket rule.
• Using verbal approvals and fix it by requiring written yes.
• Not stating cost and fix it by requiring cost in every change summary.
• No rollback plan and fix it by writing rollback or stating the risk clearly.
• Closing changes without verification and fix it by requiring workflow confirmation.
• Too many approvers and fix it by using one approver plus backup.

‍

Common objections

Approvals will slow us down. Routine work stays fast and pre-approved. Approvals prevent downtime and surprise costs for risky changes.

We trust our provider. Trust is good but written approvals prevent misunderstandings. They protect both sides.

We do not want a process. This is the smallest process that works. One ticket, one summary, one yes.

We do not know what is risky. The provider should state risk and rollback clearly. If they cannot, the change should not proceed.

‍

What affects change approval requirements

• It depends on how disruptive the change is.
• It depends on whether the change adds cost or commitment.
• It depends on whether rollback is possible.
• It depends on vendor dependencies and timing.
• It depends on business hours and staffing.
• It depends on how standardized the environment is.

‍

How we manage change approvals and verification

We use tickets as the system of record and require written approval for changes that create disruption or cost. Each change includes rollback thinking and verification steps.

Routine work stays fast and ticketed. Risky work is approved and scheduled so the business stays in control.

‍

‍

‍