How Approvals Should Work for Changes (Simple Process)

Last updated

May 13, 2026

Reviewed by

Reviewed by: IT Service Delivery Lead

Speakable Summary

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

Opening

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

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

This page explains a simple approval process youcan use with any IT provider. It keeps decisions fast and prevents surpriseinvoices.

Direct Answer

Approvals should work through a short writtenrequest that states impact, cost, and rollback. The business approves beforethe change begins and the ticket records what was approved and what wasverified.

LINK: IT Support page
LINK: Managed IT Services
LINK: Managed IT Pricing

Clear definitions

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 changedand why. If it is not in a ticket, it is not approved.

LINK: Help Desk
LINK: FAQ

Step 2: The provider submits a short change summary

The summary should fit in one screen. It shouldinclude 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 theticket 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 itoutside peak business hours when possible. If it must happen during businesshours, set expectations and provide an update cadence.

For high-impact changes, require a “go” messagebefore 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 orupdated

Who approves what

One approver rule

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

The approver is usually the owner, COO, officemanager, or finance lead depending on the business.

Approval categories SMBs should use

Category 1: Routine changes

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

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

Category 2: Business-impact changes

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

They also require a change window and rollbacknotes.

Category 3: Cost-impact changes

Cost-impact changes create new recurring chargesor significant one-time spend. These require explicit approval from the budgetowner.

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

What should never happen

Work starts before approval

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

Approvals are verbal only

Verbal approvals create disputes later. Writtenapprovals protect both sides.

No rollback exists for risky changes

Risky changes without rollback are avoidabledowntime. If rollback cannot exist, that risk must be stated clearly beforeapproval.

‍

‍