Scoping the first ITSM release: which practices to switch on first

The fastest way to stall an ITSM rollout is to try to switch everything on at once. A mid-market team gets further by launching a small, useful scope and adding practices as the data shows where the pain is. ITIL 4's guidance to start where you are and progress iteratively supports exactly that.

What belongs in release one?

Release one should replace whatever people use today for asking IT for help, and nothing more:

• Incident management: logging, categorising and resolving interruptions. Every platform in this comparison documents it.
• Service request management: the routine asks, such as access, equipment and information. For most mid-market desks this is the majority of volume.
• A short service catalog: the five to ten request types that cover most of that volume, each with a form that captures what the fulfiller needs.
• Knowledge: answers for the top recurring questions, so requesters and any AI agent can resolve them without a ticket.
• One intake path that works: email plus a portal or form is enough to start.

What should wait for release two?

Service level targets are easier to set once you have a few weeks of real data. Release two is the time to add SLA timers, refine routing, add the next tier of catalog items and introduce AI triage or agents if they are not already on. It is also when you can measure what share of tickets the automation handles.

When do change and problem management come in?

Change enablement and problem management add the most value when outages caused by changes, or the same incident recurring, are real costs. Many platforms gate them by plan: Freshservice puts problem, change and release management on Pro; Jira Service Management puts change management and advanced incident and problem management on Premium. If you will need them within a year, check which plan includes them before you sign, because that plan sets your per-agent price.

How long should each release take?

Scope drives time more than the tool. A team that limits release one to incidents, requests, a short catalog and knowledge can usually go live in weeks rather than months. Vendor statements about speed are claims: SysAid, for example, states a help desk can be up and running in 30 days or less. Use them as a prompt to ask what that assumes.

What is the test that release one worked?

Three signals: requesters use the new intake path without being reminded, agents stop working tickets outside the tool, and you can report volume by category for the first month. If those hold, move on to release two. If not, fix intake and categories before adding practices.