More features, wrong reasons

by | Sep 6, 2021

When it comes to service management tools, more features means better. Simply because more features provide more options and the freedom to use the tools the way you want. Sounds simple, so what is the issue here?

Let’s further explore this idea with a simple example, the Inbox feature of 4me. The main purpose of the Inbox is to provide a specialist with an easy to use overview of all the assignments that are waiting for an action from this individual. Assignments are ordered based on their targets so what needs to be dealt with first appears on the top of the Inbox. Easy to understand and very effective.

This approach however requires that a service organization is able to determine targets for all assignments. In any sensible service management tool this is determined by SLAs when it concerns incidents and careful planning when it concerns other assignments like tasks, changes and problems. As a customer you would expect that your service organization is at least able to plan their work according to the importance of this work for the customer(s).

The reality is that many service organizations struggle a lot in this area. SLAs are non-existent or are the same for each service and each customer. Or even worse, the customer can decide what is important by selecting an arbitrary urgency level in the request. Of course everyone selects the highest level by default which doesn’t help either. This basically means that all assignments are handled on a ‘first in – first out’ basis, often not what the customer expects or needs.

So when we do not have enough control over the correct targeting of the assignments, the functionality of the Inbox feels limiting. We need more ‘freedom’ so we ask the vendor for more flexibility like changing the sort order, marking individual assignments as urgent, filtering, custom columns etc. With the result that each specialist decides his / her own priorities, just like in the old days.

When you have your basics in place you often need less features, not more”

The main takeaway of this story is that when you have your basics in place you often need less features, not more. Of course there will be cases where a new feature would be very helpful and a sensible vendor will always be open for suggestions and improvements. But at the same time, a sensible service organization should also be willing to take a look inside to determine why it needs all those extra features. It is often a clear indication that something else should be taken care off first.


Related articles

Ready for FinOps?

Ready for FinOps?

In the old days, life was simple. Service organizations were running on a yearly budget. One of the reasons this was possible was predictability of costs. It was relatively easy to predict costs of employees and assets. The rate of change in organizations was...

Intelligent Swarming: prepare yourself for shift-left success

Intelligent Swarming: prepare yourself for shift-left success

This blog is a follow-up of a previous blog where we explained the challenges of most support organizations preparing for a shift-left initiative. As explained in that blog, the traditional tiered support model is no longer effective after a successful shift left and...

95% of all support organizations are not ready for shift-left

95% of all support organizations are not ready for shift-left

Most support organizations use a tiered support model for handling incoming requests. It all starts with level 1 (the service desk) and requests can be escalated to higher levels of support based on the complexity of the issue and the skills and knowledge of the...