Service Request Management organizational change and capability development
Domain 5: Organizational change and capability development
This domain tests how to adopt and sustain service request management: roles, skills, culture, communication, and reinforcement.
Core rules
- Adopting SRM is an operating-model change: catalogue, request models, approval matrix, roles, tooling, targets, and reporting must fit together.
- Use organizational change management to engage stakeholders, assess impact, communicate the reason for change, pilot, train, and reinforce.
- Build capability across the service desk, fulfillers, approvers, and service owners: service knowledge, customer empathy, authorization judgement, data accuracy, security awareness, automation literacy, and commercial awareness.
- Clarify role changes. Self-service and automation often move agents from routine transactions to exception handling, advice, quality assurance, and demand analysis.
- Align with ITIL 4 guiding principles: focus on value, start where you are, progress iteratively, collaborate, think and work holistically, keep it simple, optimize and automate, observe transparently.
- Reinforce with governance, training, knowledge, metrics, and recognition-not a one-off launch.
Worked example
An organization introduces a self-service portal for password resets and software requests. It starts with two high-volume items, trains users and agents, defines escalation for failures, and tracks adoption, fulfilment time, and satisfaction. Service desk fears of job loss are addressed by redefining roles toward complex requests and advice. After the pilot, the catalogue is expanded based on data, not opinion.
Traps that cost marks
- Tool-first adoption with no process, roles, or training.
- Launching without communication or stakeholder engagement.
- Ignoring culture and resistance until after go-live.
- Measuring go-live, not adoption and outcomes.
- Leaving the service desk unsupported as its role changes.