ServiceNow Change Enablement: Roles, Responsibilities and RACI

Core Change Enablement Roles

The Change Manager owns the overall change process, approves change policy, chairs the change advisory board, and ensures changes are tracked and documented consistently. The Change Manager is accountable for compliance with change governance and for trends in change outcomes.

The Change Coordinator manages the day-to-day change workflow: receiving change requests, logging them in the system, scheduling them for review, and tracking status through approval and implementation. In larger organisations, this role exists separate from the Change Manager.

The Implementer is the person or team that performs the actual change to production. For infrastructure changes, implementers are infrastructure engineers. For application changes, they are developers or application teams. Implementers follow the documented change procedure, execute the implementation plan, verify that the change worked, and report the outcome.

The Change Approver reviews changes and decides whether they should proceed. For standard changes, approval may be automated based on low-risk criteria. For normal and emergency changes, designated approvers—often representatives from operations, security, and affected business units—must approve before implementation.

Additional Supporting Roles

The Impact Reviewer assesses whether a proposed change might affect systems beyond the direct target. A change to a database could affect multiple applications that depend on that database; Impact Reviewer ensures those dependencies are understood and managed. The role may be performed by a data architect or platform engineer.

The Quality Assurance reviewer validates that the change has been tested and the test results support the decision to deploy. Testing might include automated testing, manual testing, or both. The QA reviewer ensures testing criteria have been met before the change reaches production.

The Business Owner for the affected service confirms that the change aligns with business goals and that any business disruption caused by the change is acceptable. The business owner might request delays if the change timing conflicts with critical business events.

RACI Matrix for Change Enablement

A RACI matrix clarifies who is responsible, accountable, consulted, and informed for each step in the change lifecycle:

• Change Request Submission: The person requesting the change is Responsible; the Change Manager is Accountable; technical teams are Consulted; the broader team is Informed.
• Change Assessment: The Impact Reviewer is Responsible; the Change Manager is Accountable; the QA Reviewer is Consulted; implementers are Informed.
• Change Approval: The Change Advisory Board is Responsible for the decision; the Change Manager is Accountable; the Business Owner and Implementer are Consulted; the organisation is Informed after approval.
• Change Implementation: The Implementer is Responsible; the Change Manager is Accountable; the Change Coordinator monitors and is Consulted; stakeholders are Informed of completion.
• Change Verification: The Implementer is Responsible; the QA Reviewer is Accountable; the Change Manager is Consulted; stakeholders are Informed of results.

Decision Rights and Escalation

Standard changes follow an expedited path with reduced review because they are low-risk. Standard changes are pre-approved through their template, so an individual request needs no approval; the review happens when a template is proposed, changed or retired. This allows routine, repetitive changes to move through quickly while preserving review for higher-risk changes.

Normal changes require Change Advisory Board approval. The board reviews risk, impact, resource availability, and timing conflicts before approving. If the board defers or rejects a change, the requestor can resubmit with additional justification, but the board must approve.

Emergency changes bypass normal review if an outage is occurring and the change is needed to restore service. An on-call approver can authorise emergency implementation. Retrospective review occurs after service is restored to determine whether the emergency change was necessary and whether any negative side-effects occurred.

Ownership and Accountability for Change Outcomes

The Implementer owns the successful execution of the change. If the change causes problems, the Implementer is responsible for investigating and applying fixes. The Change Manager is accountable for ensuring the outcome is documented and lessons are captured.

If a change is rolled back, accountability rests with whoever approved the change. If a change that looked low-risk caused outage, the approval process should be reviewed to understand why the risk assessment was wrong.

Communication and Notification Responsibilities

The Change Coordinator is responsible for notifying affected stakeholders before changes. Notification includes the change description, the expected duration, the systems affected, and the rollback plan. Notification goes to operations teams, to support staff who will field user calls about the change, and to business units whose users might be affected.

After implementation, the Implementer communicates the outcome. If the change succeeded, stakeholders are notified that systems are back to normal. If the change was rolled back, stakeholders are notified and asked to report any anomalies they observe.

Recurring Review of Role Assignments

Change roles should be reviewed annually to ensure they still match current responsibilities. When a person’s primary role changes, their Change role assignments should be updated. When staffing changes, new Change Approvers need to be trained on decision criteria and organisational standards.

Turning a role model into platform objects

A role description on a wiki has no effect until it is attached to something the platform can enforce. Each role in a change program needs a corresponding mechanism, and the choice matters. A person named as approver in a document is not an approver in the workflow unless an approval rule or an assignment exists that routes to them. Mapping roles to platform objects is therefore the step that connects the RACI to daily work, and the assignment groups governance guide covers keeping those groups clear and current, and this mapping step is where gaps often appear.

Check the RACI against the workflow before it is published

A RACI that reads well on paper can still be wrong once it meets the workflow. Walk through one example change for each change type, step by step, and at each step confirm that the person or group marked Accountable is the one the workflow actually asks to approve or close. Look for steps where the workflow requires a decision that the RACI does not assign, and for steps where the RACI assigns a decision the workflow never asks for. Both gaps can produce informal work that bypasses the record.

Rules for a RACI that holds up under pressure

1. Assign exactly one Accountable party to each step, even when several people share the work.
2. Name a deputy for every Accountable role, and record the deputy in the same place as the primary.
3. Write the RACI for the emergency path separately, so responders do not have to translate the standard path under pressure.
4. Limit Consulted roles to people who can change the outcome. Consulting everyone turns review into a waiting queue.
5. Re-run the walkthrough after any change to categories, approval rules or group membership.

When a role is vacant

Vacant roles are a common cause of silent stalls, and the same discipline appears in the offboarding controls for platform users. A change manager who moves to another team may leave a queue that nobody is watching. Treat a vacancy as an event with a procedure, and check group memberships during the access recertification cycle: the outgoing holder transfers open records, the deputy is confirmed in writing, and the platform group membership is updated the same day. Changes that were waiting on the vacant role should be listed in the next governance review, so they are not left in a state no one owns.

Where people confuse the roles

A common confusion is between the person who requested a change and the person who owns its outcome. The requester describes the need. The owner decides whether the change is acceptable and carries the consequences. Another frequent confusion is between approval and verification. An approver agrees the plan before the work starts. A verifier checks the result after it finishes. When the same person does both, the verification can end up confirming the plan rather than testing the outcome.

Questions readers ask about role design

Can one person hold several roles?

Yes for small teams, provided the roles that would check each other are not held by the same person for the same change. A person can be requester and implementer on a routine change, but should not approve their own normal change.

How many people should be on the change board?

The board should be small enough to decide and broad enough that the decisions reflect the services affected. The membership question matters less than whether each member has a defined reason to be in the room.

Should contractors hold approval roles?

Only where the contract and the access design allow it. A contractor can implement under a named approval, but approving changes to production usually needs an employee who is accountable for the decision.