ITSM Tool Requirements: A Buyer Checklist
Most ITSM purchases go wrong by starting from a feature matrix. Start from the practices you will run, then check which requirements they impose.
Choosing ITSM software is easier when you decide first which practices you will run in the next year. A team that will run a service desk and incident response needs different software from one that also needs formal change approval and a configuration database. This checklist is organised by practice so that you can strike out what you will not use.
Before the checklist
- Write down the three problems you want to solve. If a tool does not address them, it does not matter how long its feature list is.
- Count the people who will use it, and divide them into those who raise requests, those who resolve them and those who administer.
- Decide who will own the tool. An unowned tool decays.
Service desk and requests
- Several ways to raise a request: a form, email and chat.
- Categories, priorities and routing to the right team.
- Due dates, or response and resolution targets, with a visible warning as they near.
- A customer-facing view so requesters can see status.
- Templates and canned responses.
- A knowledge base that is linked from the request screen.
Incident and on call
- Severity levels you can define yourself, with response targets.
- On-call schedules with time zone support, overrides and escalation policies.
- Integration with your monitoring through signed inbound alerts.
- A timeline, role assignment and a way to attach the conversations held elsewhere.
- Customer communication with approval.
- Reviews with owned follow-up actions.
Problem and knowledge
- Linking incidents to a problem record.
- A known error record with a workaround.
- Searchable articles, with an owner and a review date.
Change and release
- Change types with different approval routes.
- Approvals that only the named person can give.
- A calendar showing changes and freeze windows.
- A record of deployments by environment.
- Integration with your delivery pipeline through an API.
Assets and configuration
Decide honestly whether you need a configuration management database. It is valuable when impact analysis across many dependent systems is a regular need, and a burden when nobody keeps it current. Many small teams are better served by clear service ownership and good documentation.
Platform requirements
- An API and webhooks, so that you are not locked in.
- Role-based access, single sign-on and an audit log, at the plan you will buy.
- Reporting you can export.
- Data export, so that you can leave.
- Plan limits that match your seats and history needs. Check them in writing.
Questions for any vendor
- Which of these are included in the plan I would buy, and which are add-ons?
- Show me a real incident being run, start to finish.
- What happens to my data if I leave?
- How do I get my own pipeline's events into the tool?
- Which requirements on my list do you not meet?
Full suite or work platform
If you need a configuration database, a service catalogue with fulfilment workflows and formal request SLA timers, a dedicated ITSM suite is the right category, and Atlas is not that. If your work is mostly incidents, on call, software changes and a modest flow of internal requests, and you want it in the same workspace as your projects, tasks and documents, a work platform may serve with less overhead. Atlas covers incidents, on call, known causes, release-based change and request intake through forms and email, and states plainly that it lacks the rest. The pricing page lists which plan includes which module.