Coming Soon: Axios, Biomni, Matrix42 & ServiceNow Showcase Service Catalogue

Axios, Biomni, Matrix42 and ServiceNow - who leads the pack in Service Catalogue?

Axios, Biomni, Matrix42 and ServiceNow are confirmed participants for our upcoming ‘Service Catalogue’ review.

Our assessment criteria at a glance:

  1. Service Design – the ability to create a database of service records, containing a number of business and technical attributes, processes and workflows.
  2. Service Structure – the ability to organise and structure these services into a hierarchy of services and service offerings, ideally useable in a graphical format
  3. User Request Portal – a user-friendly/external facing portal that provides users with an intuitive User Interface to request services
  4. Request Fulfilment – request management workflow functionality that can be easily used and configured by system users
  5. SLA and event management – the ability (in the software or by integration) to define universal and bespoke levels of SLA which are then automated and escalated though an event management process – ideally linking with Incident, Problem and Change Management functionality
  6. Demand Management – the ability to provide real time allocation and monitoring of Service consumption, with financial calculations
  7. Dashboard – real-time user-friendly graphical monitoring and analysis of usage, trends and metrics across services and to various stakeholders
  8. Service Reporting – the ability to present output that summarises individual and bundled service performance, consumption, SLA and event performance, in user-friendly, portable and graphical format

Full details of the assessment criteria can be found here.

Reviewer: Barclay Rae

Confirmed Participants:


All results will be published free of charge without registration on the ITSM Review. You may wish to subscribe to the ITSM Review newsletter (top right of this this page) or follow us on Twitter to receive a notification when it is published.

Image Credit

Assessment Criteria for Incident and Problem Management

We will soon begin our review of Incident and Problem Management offerings in the ITSM market place. As with our previous comparison of REQUEST FULFILMENT – Our goal is to highlight the key strengths, competitive differentiators and innovation in the industry.

During Request Fulfilment our original aim was to look at how the tool supported the process, but refreshingly vendors who participated also shared their experiences and some insight into their consulting approaches.

When assessing the bread-and-butter elements of Incident Management, the challenge will be to identify be true differentiators in a discipline that is quite rigid.

We would like to encourage the same philosophy of identifying how deployment experiences have shaped the evolution of tools.

Incorporating Incident & Problem Management for a review

From my experience, deployments often implement Request Fulfilment, and Incident Management in the early phases of projects, but often Problem Management is left until later phases.

Yet the two processes, in tool terms are often linked together – quite often the record functionality and layout is the same for Incident, Problem (and Request for that matter).

My assessment criteria for the Incident and Problem Management review are below, if you have any comments or recommendations please contact us.

Suggested Criteria for Incident & Problem Management

Overall Alignment

  • Have our target vendors aligned to ITIL and if so, to which version?
  • How do the set up roles and users to perform functions?
  • What demo capabilities can they offer potential customers?

Logging & Categorisation

These can either be made simple, and to great effect, or made so complex, that they become irrelevant as the Service Desk totally ignore them and pick the first thing on the list!

  • What information is made mandatory on the incident and problem record?
  • What categories and/or sub-categories are provided out-of-the-box?
  • How easy is it to customise these fields and values?
  • Show us how incident/problem matching and linkage to known errors are presented to users and/or service staff to expedite the process.
  • How much administration is needed to do bespoke changes?


“Oh come on now,” I hear you cry, “What tool cannot track incidents and problems?”

But there can be a lot more to tracking these records than meets the eye:

  • What statuses are included out-of-the-box and how easy is it to add/modify status definitions to suit customer requirements
  • Can your tool show how many “hops” a record may face if wrongly assigned?

Lifecycle Tracking

Perhaps the best way of allowing vendors to show off their tool’s capabilities is for them to really go to town in terms of playing out scenarios.

The aim of this assessment is to look at how tools can help keep communication going during the lifecycle of an incident/problem and its linkage to other processes.

  • First time Fix from the Service Desk
  • Resolved via support group(s)
  • Demonstrating visibility of the incident/problem through its lifecycle, from  end-user, Service Desk and support group(s) points of view
  • Linkage to other processes


  • How are priorities determined and managed (out-of-the-box)?
  • What happens when the priority is adjusted during the lifecycle of the incident/problem?
  • We would like to also give vendors an opportunity to show us how they link SLAs to Incidents.


  • Demonstrate routing to multiple groups
  • Show the tool’s capability for handling SLA breaches – in terms of notifications and the effect on the Incident record during that time
  • Show us what happens when an incident/problem has NOT been resolved satisfactorily
  • Demonstrate integration between incident and other processes

Major Incidents and Problems

Much like categorisation, this can be very simple, or can be made so complex, and more time can be spent negotiating the process than fixing the issue in the first place.

  • Provide and end-to-end scenario to demonstrate how the tool handles the management and co-ordination across multiple groups for a Major Incident & Problem

Incident & Problem Models

All of the above criteria are what I consider the basics of an ITSM tool.

But I am keen to delve deeper into what vendors understand by the concept of Models.

In turn, how can their tools add significant value in this area?

There are several ways of looking at this concept (there will be no points for throwing it over the fence to Problem Management and focussing on Known Errors).

There are assessment criteria around the handling of Models, and we want to see how tools help in this aspect.

  • Demonstrate how your tool facilitates the use of Models (include if/where links to other relevant processes/support groups as part of the demonstration).

Incident & Problem Closure

It makes sense to end our list of assessment criteria examining how tools resolve and/or close incidents and problems by default.

  • Show how an incident/problem is routed for closure.

This assessment will be quite scenario heavy, and we want to give participating vendors the freedom to develop their scenarios without limiting them to defined parameters (for example, specifying which service has failed, or which groups to use).

A key part of the assessment will also include how flexible the tool is with regards to customisation.

Incident Management can sometimes be taken for granted, so we would like participating vendors to really take a look at how Incident Management can made “everyone’s” business.

But more importantly, Problem Management is often left to later phases, while organisations focus on processes like Request Fulfilment, Incident and Change – perhaps there is a case to make for implementing them hand in hand?

What is your view, what have we missed?

Please leave a comment below or contact us. Similarly if you are a vendor and would like to be included in our review, please contact us.