Skip to main content

Change Request

🧭 Computerman Change Request Workflow

Purpose:
This workflow ensures all IT changes—no matter how small or large—are handled in a consistent, secure, and documented way. It supports client transparency, accountability, and reliable service delivery.

🔁 Workflow Stages Overview

  1. Standard Change Request Initiated

  2. Log the Request in Autotask

  3. Document & Assess the Change

  4. Approval Request Sent

  5. Approval Received (or Denied)

  6. Implement the Change

  7. Close the Request

Each stage is explained below in full.

🟦 1. Standard Change Request Initiated

Trigger:
A change is requested either internally or by the client.
Examples:

  • Create a shared mailbox

  • Set up email forwarding

  • Grant folder access

  • Reset a user password

  • Perform a small configuration change

Who Can Initiate:

  • Clients (via ticket, email, or phone)

  • Technicians (for proactive changes)

  • Team leads or project owners

🟧 2. Log the Request in Autotask

Action:
Create a new Change Request Ticket in Autotask. Select the appropriate ticket category (e.g., "Standard Change – User Access").

Include:

  • Who requested the change

  • Who the change is for

  • Detailed description of the change

  • Urgency and impact (if known)

  • Any attachments or context

Tip: Use a predefined template if available.

🟦 3. Document & Assess the Change

Goal:
Ensure the change is understood, low-risk, and does not disrupt operations or compliance.

Technician must document:

  • Purpose of the change

  • Impact (none, minor, or service-affecting)

  • Risk (low/medium/high)

  • Implementation Plan (what will be done and when)

  • Rollback Plan (if the change fails, how to undo)

This step ensures we're always thinking ahead—especially when it comes to security and continuity.

🟩 4. Request Approval

Standard changes still require approval from the appropriate approver (usually the client's designated contact or manager).

Send an approval email using our pre-written template.
The approver should reply with "Approved" or ask questions before proceeding.

💡 Use Autotask workflow rules to automatically notify the approver based on ticket type or UDFs.

🟧 5. Approval Received (or Denied)

If approved:

  • Proceed to implementation

  • Update the ticket status to reflect “Approved – Pending Implementation”

If denied or unclear:

  • Clarify with the client

  • Do not proceed without documented approval

🟦 6. Implement the Change

Before implementing:

  • Ensure all documentation is complete

  • Ensure approval is recorded in the ticket

During implementation:

  • Follow the documented implementation plan

  • If anything deviates, update the ticket in real-time

After implementation:

  • Test and verify success

  • Notify the client the change is complete

🟦 7. Close the Request

Final Steps:

  • Document the outcome in the ticket

  • Mark the change as “Completed” or “Closed”

  • Update configuration items (if needed) in the IT documentation system

  • Send a follow-up email to the client confirming successful implementation

🔐 Security & Compliance Notes

  • Always use secure methods for handling credentials

  • If change involves access permissions, always document who gained access to what and when

  • Rollback plans must be considered mandatory—not optional

🧠 Technician Tips

  • Use judgment: if a small change affects critical systems (e.g., access to CEO inbox), treat it with high sensitivity

  • Communicate clearly: clients appreciate knowing when changes happen, even small ones

  • Don’t skip the rollback plan—even for “simple” changes

✅ Change Types You Might Encounter

Change Type Examples Risk Level Approval Needed
Standard Change Password resets, mailbox access, folder share Low Yes
Normal Change Server patching, firewall rule changes, software install Med/High Yes (CAB or Director)
Emergency Change Fixing critical outage, security patch post-breach High Verbal approval + Retro documentation

📌 Summary Checklist

Step Completed?
Ticket created in Autotask ✅
Purpose documented ✅
Risk & rollback assessed ✅
Approval requested and logged ✅
Change implemented and tested ✅
Ticket closed and client notified ✅

Would you like this exported as a PDF or Wiki HTML page for easy drop-in to your training platform or internal Confluence? I can also generate the "Normal Change" workflow version next if you're ready.

Back to top