ServiceNow Change Order Process

ServiceNow Change Order Process (CCaaS - Standard and Normal Changes)

1. Purpose

To define the standardized process for creating, managing, and executing Change Orders in ServiceNow for CCaaS deployments, ensuring:

• Traceability of production changes
• Alignment with ITIL practices
• Audit-safe documentation of deployments
• Clear ownership across roles

2. Change Types (Definitions)

2.1 Standard Change

• Pre-approved, repeatable changes with low risk
• Used for known, routine activities (for example: prompt updates, flow modifications)
• No formal approval workflow required at submission stage
• Designed to streamline deployments

Examples (from workshop):

• Modify voice flow
• TTS or prompt updates
• Schedule updates
• Digital flow changes

2.2 Normal Change

• New, complex, or higher-risk deployments
• Requires:
  • Risk assessment
  • Approval workflow
  • CAB review
• Minimum 3 business day lead time required

Examples:

• Net new queue or infrastructure deployment
• Agentic agents deployment
• Unified experience rollout

2.3 Emergency Change

• Used when:
  • Production is broken
  • Immediate restoration is required
• Occurs during active incident management

3. Naming Convention (Mandatory Standard)

All change orders must follow:

[Org Name] + [Ticket / Enhancement / Incident #] + [Default Description]

Example:

Maximus Canada - ENHC0010149 - Modify Voice Flow

Enhancements:

• Include Org Name
• Include Ticket Number (primary work item)
• Retain ServiceNow default classification text

4. Roles and Responsibilities (Who Does What)

4.1 Implementer (Primary Owner)

Roles:

• Cloud Developer
• Business Systems Analyst
• Integration Engineer

Responsibilities:

• Create and submit standard changes they implement
• Populate:
  • Short description (with naming standard)
  • Scope (in work notes)
  • Schedule (deployment timing)
• Update status in real time:
  • Scheduled -> Implement -> Closed
• Execute deployment
• Validate outcome
• Complete closure notes

Key principle:

Standard changes should be done by whoever is implementing the change.

4.2 Senior Business Analyst or Delivery Lead

Responsibilities:

• Own normal changes
• Drive:
  • Change creation (or review)
  • Scope definition
  • Stakeholder communication
• Work with implementer on:
  • Risk evaluation
  • Deployment planning

Acts as:

• Change coordinator or delivery manager for complex work

4.3 Manager (Change Authority, for example Erikk)

Responsibilities:

• Approve change requests (initial approval stage)
• Define:
  • Standards
  • Naming conventions
  • Deployment expectations
• Ensure:
  • Governance adherence
  • Process consistency

4.4 CAB (Change Advisory Board)

Participants:

• Senior stakeholders (for example: Matt Green, Gaurav Saad, Bill Chau)

Responsibilities:

• Review normal changes
• Approve or reject deployments
• Validate:
  • Risk
  • Timing
  • Impact

4.5 Team Members (Analysts or Non-Deployers)

Responsibilities:

• Provide:
  • Requirements
  • Enhancement details
• Do not typically deploy changes (role-dependent)

5. Standard Change Process (Step-by-Step)

Step 1: Create Change

• Select Standard Change template
• Choose relevant template (for example: Modify Voice Flow)

Step 2: Populate Details

• Short Description (use naming standard)
• Category: Contact Center
• Assignment:
  • Group: Contact Center
  • Assigned to: Implementer
• Work Notes:
  • Add change scope

Step 3: Schedule

• Set deployment time (local timezone awareness required)
• Note:
  • Timezone inconsistencies may exist; verify before submission

Step 4: Submit Change

• No approval required (pre-approved)

Step 5: Execute Deployment

• Update status in real time:

Scheduled -> Implement -> Closed

Critical behavior:

• Status updates should occur during deployment, not after

Step 6: Close Change

• Add closure notes:
  • Example: Deployment successful - no errors
• System tracks deployment duration

6. Normal Change Process (Step-by-Step)

Step 1: Create Change

• Select Normal Change

Step 2: Populate Details

• Full description (can be generated via Copilot if needed)
• Category: Contact Center
• Service Offering: Genesys Cloud
• Assignment: Delivery Lead or Implementer

Step 3: Add Plans

Must include:

• Implementation Plan
• Back-out Plan
• Test Plan

Step 4: Risk Assessment

Complete:

• Business criticality
• Complexity
• Back-out difficulty
• Outage impact
• Stakeholder communications

Step 5: Request Approval

• Initial approval: Manager
• CAB approval: via CAB meeting

Step 6: Schedule Deployment

• Must be at least 3 business days from creation
• Align with deployment window where possible

Step 7: Deploy

• Once approved:

Scheduled -> Implement -> Closed

7. Deployment Windows (Recommended Standard)

• Preferred:
  • Weekly window (for example: Wednesday evening)
• Reality:
  • May vary based on client needs
• Standardization improves:
  • Predictability
  • Release governance

8. Key Operational Principles

8.1 Real-Time Tracking

• Change status must reflect actual implementation state
• Enables:
  • Duration tracking
  • Audit visibility

8.2 Standard Change Governance

• If a standard change causes an incident:
  • It is revoked as standard
  • It must be re-qualified through repeated success

8.3 Separation of Duties

• Standard changes: Implementer-led
• Normal changes: Delivery and governance-led

8.4 Documentation Reuse

• Enhancement details should feed:
  • Change descriptions
  • Planning sections
• Copilot can accelerate creation of structured change descriptions

9. Quick RACI Summary

Step	Implementer	Senior BA or Delivery Lead	Manager	CAB
Create Standard Change	Yes	No	No	No
Create Normal Change	Assist	Yes	No	No
Populate Details	Yes	Yes	No	No
Risk Assessment	Yes	Yes	No	No
Approval	No	No	Yes	Yes
Execute Deployment	Yes	Oversight	No	No
Close Change	Yes	No	No	No