The standard ITSM tool selection process involves comparing features across vendor candidates. ServiceNow, Cherwell, BMC, Atlassian Jira Service Management, Freshservice, ManageEngine, and various others all have feature comparison matrices that buyers work through during evaluation. The process produces a recommended tool. The implementation begins. Then the trouble starts.
The trouble usually has very little to do with which tool was selected and a lot to do with the implementation capability the organization brings to the work. The selection focus on tool features misses the actual driver of implementation success. This piece is about what the selection process should actually focus on.
Why feature comparison matters less than people think
The major ITSM platforms in 2025 have largely converged on similar feature sets. Incident management, change management, request fulfilment, problem management, knowledge management, service catalog, reporting and analytics — these are all available in essentially every major platform at functionality levels that meet most organisational needs.
The differences between tools at the feature level exist but are usually not strategic. One tool's change advisory board workflow has slightly different options than another tool's. One tool's reporting interface is faster than another's. One tool's mobile experience is more polished. These differences matter operationally but rarely determine implementation success.
The factors that actually determine whether an ITSM implementation succeeds are mostly not about the tool. They're about the organisational capability to define requirements, configure the tool to those requirements, manage the change to operational practice, train staff, integrate with adjacent systems, and sustain the implementation over time as needs evolve.
An organisation with strong implementation capability will succeed with most major ITSM tools. An organisation with weak implementation capability will fail with most major ITSM tools. The selection of which tool matters much less than the assessment of implementation capability.
What implementation capability actually requires
Implementation capability includes specific organisational competencies that are often missing from selection-stage evaluation.
Process design capability — the ability to articulate clearly what your service management processes should be, including the specific decisions and handoffs that the tool needs to support. Most organisations have less of this than they think. The tool can't configure itself to undefined processes.
Configuration capability — the technical ability to actually configure the tool to match the designed processes, including form design, workflow construction, integration setup, and reporting configuration. This requires specific platform expertise that takes time to develop.
Change management capability — the organisational ability to roll out the tool to users, train them on new processes, address resistance, and sustain adoption over time. This is mostly not technical but is often the largest determinant of implementation success.
Integration capability — the technical ability to integrate the ITSM tool with the broader IT environment including monitoring tools, CMDB sources, identity systems, communication platforms, and other systems that should exchange data with the ITSM tool. The integration work is where implementations often stretch.
Sustaining capability — the ongoing ability to evolve the implementation as organisational needs change, address technical debt, manage upgrades, and prevent the implementation from drifting into unmaintainable state. This is the dimension most often underestimated during selection.
What selection process should actually do
A more useful selection process would weight implementation capability assessment heavily alongside tool feature evaluation.
The implementation capability assessment should examine the organisation's existing competencies in process design, configuration, change management, integration, and sustaining capability. It should identify capability gaps that the implementation will require closing. It should evaluate whether closing those gaps is realistic given organisational resources and timeline.
The tool selection should then weight tools by how well they match the organisation's actual capability. Tools that require less custom configuration suit organisations with less configuration capability. Tools with simpler integration patterns suit organisations with less integration capability. Tools with strong out-of-box content suit organisations that need to start with proven patterns rather than custom-design from scratch.
This selection logic produces different recommendations than pure feature comparison would. An organisation with limited configuration capability might be better served by a tool with stronger out-of-box content than by a more flexible tool that requires more configuration to be useful. An organisation with limited integration capability might be better served by a tool with broader pre-built integrations than by a tool with stronger native capabilities that needs more custom integration work.
What the implementation phase should focus on
Once the tool is selected, the implementation phase should be structured around capability development rather than around tool deployment per se.
The first capability to develop is process clarity. Before configuring the tool, the implementation team needs to have clear documentation of what the processes will be. Configuring the tool to processes that aren't yet defined produces configuration that doesn't match what the organisation actually needs.
The second capability is platform expertise. The team needs to develop deep familiarity with the specific tool's capabilities, configuration patterns, and limitations. This typically requires dedicated time and often vendor or partner support during the early phases.
The third capability is integration design. The implementations that integrate well with adjacent systems require specific design work that often gets shortchanged in implementation timelines. Investing in this design work early prevents integration debt that compounds over years.
The fourth capability is change management for the user community. The technical implementation is the smaller part of the work; getting users to adopt the new tool and processes is the larger part. The change management work needs dedicated effort and should be planned alongside the technical implementation rather than as an afterthought.
Where vendor and partner support actually help
Vendor and partner support during implementation can address specific capability gaps. Knowing where this support helps and where it doesn't is part of effective implementation planning.
Vendor and partner support is genuinely useful for platform-specific configuration expertise that the internal team doesn't have. Working with partners who have configured the platform for similar use cases shortens the learning curve significantly compared to figuring it out from documentation.
Vendor and partner support is useful for integration patterns that have been done before. The partner has likely connected the platform to common adjacent systems many times and can apply proven patterns rather than designing from scratch.
Vendor and partner support is less useful for organisation-specific process design. The processes need to reflect the organisation's actual needs, not generic best-practice templates. Partners can support process design but can't substitute for the organisation's own process clarity.
Vendor and partner support is largely ineffective for change management with the user community. The internal organisation has to do this work. Partners can advise but can't be the change agents the user community will respond to.
What ongoing maintenance actually requires
The implementation is the beginning, not the end. ITSM tools require ongoing maintenance and evolution to remain effective as organisational needs change.
Most organisations underinvest in ongoing maintenance after initial implementation. The implementation team is often dispersed once the tool is in production. The platform gradually accumulates technical debt, configuration drift, and unaddressed evolution needs. Within a few years, the implementation is meaningfully less effective than it was at go-live.
Sustainable implementation requires dedicated ongoing capability — typically a small team responsible for the platform across its lifecycle, including configuration changes, integration evolution, upgrade management, and continuous improvement. This team often gets cut during budget pressures and the platform suffers accordingly.
The organisations that maintain effective ITSM implementations long-term are the organisations that maintain this dedicated capability. The ones that don't see implementation effectiveness erode over years until eventually they conclude they need to "implement a new tool," which usually means they need to actually do the implementation properly this time including the ongoing capability piece.
What I tell people during selection
When colleagues ask me about ITSM tool selection I tell them that the tool choice matters less than they think and the implementation capability matters more than they think.
I tell them to assess their organisation's implementation capability honestly before evaluating tools. Most organisations have less capability than the implementation will require. Identifying the gaps before selecting the tool allows them to plan for capability development as part of the implementation.
I tell them not to overweight feature differences in tool comparison. The features that matter most are usually present in any major platform. The features that differ are usually marginal to overall implementation success.
I tell them to plan for ongoing maintenance capability from the beginning. The implementation is a project; the maintained platform is a service that needs sustained support. The organisations that recognize this from the beginning produce better long-term outcomes than the organisations that treat implementation as the end of the work.
The ITSM tool selection problem is mostly mis-framed in the standard process. The reframed problem — focused on implementation capability rather than tool features — produces better selection decisions and better implementation outcomes. The reframing requires honesty about organisational capability that selection processes don't always encourage but that ultimately serves organisations better than feature-comparison theater.
