Assessment Criteria for Request Fulfilment

We will soon begin our review of Request Fulfilment offerings in the ITSM market place. Our goal is to highlight the key strengths, competitive differentiators and innovation in the industry.

In my previous article I looked at what ITIL 2011 had added to the process, and some of the pitfalls we may have seen in trying to implement Request Fulfilment in the past.

I would now like to take a look at what this means, in practical terms, when approaching Request Fulfilment – what should we be looking for?

At the recent UK itSMF ITSM Software Tools Forum event in Manchester, vendors spoke to the audience at length about transitioning from IT focussed decisions, to business outcomes, and this is an area where Request Fulfilment could come into its own, especially in the sphere of interaction by non-IT users.

But a transition is a gradual thing, and the importance of the concept of conformance should not be forgotten. I think it remains an important element for any vendor’s toolset to be comparable to identified, accepted benchmarks, as well as unpicking the practicalities of deployment a solution.

Principles vs. Process

What is more important at this stage, is the ease of which a tool’s capability can be displayed.

Demos at shows are slick and well prepared and I dare say a lot of us have had to go through the rigours of setting up demos and knowing what to click, how and where.

What we are looking for vendors to do is demonstrate to us how easy is it to start from scratch, ideally with meaningful options for an end user to start with.

Suggested Criteria


It is probably too much of an extreme to launch from recognisable standards and certification/verification platforms, to merely focussing on the look and feel of menus and options for end users in one fell swoop.

So for that reason, I am including a need to understand how vendors align to accepted best practice standards.

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?

 Request Models

  • What request workflows are available out-of-the-box
  • How easy is it to develop more specific workflows?
  • What additional administration is required for deeper customisation? At what cost?

Menu Selection

  • How is your self-help portal set up?
  • How do you incorporate new service descriptions for your users?
  • How much administration is needed to do the more bespoke work?

Request Status Tracking

  • Show us how any request is tracked throughout its lifecycle?
  • Who can see it, and when, and which teams can change it/move it on its way?

Prioritising & Escalating Requests

  • Show us how your tool prioritises requests and how they can be escalated?
  • What kind of other factors can affect a ticket (for example breaching SLAs and the escalation from that point)?
  • If a request becomes something more complex, how does your tool allow the alteration of the request (for example, a Change)

Financial & Other Approvals

  • Demonstrate a request model that includes alternative approvals (other than immediate manager)

End-to-End Co-ordination to Closure

  • We don’t expect tools to prescribe exactly how organisations manage their Request Fulfilment processes, just as we don’t follow ITIL blindly BUT during the course of the review, we want to understand how  a request can move through its lifecycle, end-to-end.
  • We want to understand the simple (out of the box), the medium and the complex (and the related additional costs that might be involved to get an organisation there).

I think it is rare that anything is utilised completely “out-of-the-box” these days, and that organisations will always have a requirement for some level of customisation. Request Fulfilment is certainly a process that could lend itself to quite intricate customisation, to the point of over-complication.


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. Thanks, Ros.

Request Fulfilment in ITIL 2011

"ITIL 2011 sees a hefty revision for the Request Fulfilment process."

What is it?

The ITIL® Request Fulfilment process exists to fulfil Service Requests – for the most part minor changes or requests for information.

Request Fulfilment landed on us in ITIL v3 when there was now a clear distinction between service interruptions (Incidents) and requests from users (Service Requests for example password resets)

And what does ITIL 2011 give us?

ITIL 2011 sees a hefty revision for the Request Fulfilment process.  There are more detailed sub-processes involved with steps broken down logically.

Now, I like me a good diagram and finally Request Fulfilment gets a decent flow and most importantly the linkages to other interfaces to the other lifecycle stages are included in a lot more detail.

Perhaps the most impressive thing is far more detail in the section about the Critical Success Factors (CSFs) and Key Performance Indicators (KPIs) that have been included.  Having experienced the hilarity of definitions of over-complex metrics – this is a good starter for 10, straight off the bat and of course can be added to suit an organisation’s needs.

But what does all this REALLY mean?

It means nothing if the best practices cannot be applied and adapted into real life.

  • Now we all know that at the back of a Service Request is a process that will step through authorisation, any interfaces to other processes etc., but the business value is to provide a quick and easy way for end users to get new services.
  • A mechanism to reduce costs through centralising functions.
  • Understand what other stages of the lifecycles are needed alongside Request Fulfilment – this does not happen in glorious isolation.

Is there such a magic bullet?

The simple answer?  NO!

But there are a few things that should be taken into consideration when looking at implementing Request Fulfilment (often as part of an integrated solution).

Let’s look at the easy stuff first:

  • Look at starting nice and easily with simple Request Models that will happen often, and can be met with a consistently repeatable solution.
  • Look at what kind of options you are going to put in front of the user.  Most people are now familiar with the type of shopping basket type approach through the internet so offer them a familiar interface, with as many options that can be pre-defined
  • Make sure that the different stages of the request can be tracked – the purpose is two-fold:
    • End users don’t get (as) ratty
    • Reporting and routing can be made simpler and more accurate with meaningful status definitions

Getting the hang of this…

  • Give some thought to how you want to prioritise and escalate requests depending on their complexity to fulfil, and again pre-define where possible.

Let’s do the whole shebang…

  • Eventually there will be a need to include financial approval(s) which in turn means sticky things like deputies and budget limits
  • There may also be external interactions with fulfilment groups dealing with procurement

Back up a second – who now?

  • Give some thought to which groups are going to be involved.  In my experience it is sometimes easier to work backwards, from the outcome to the selection and fill out all the bits you need in between.
  • Easy stuff is most likely taken care of by a single, often centralised group – typically the Service Desk, or in some cases specific co-ordinators who work at that Level One tier.
  • Decide if your existing resolver groups are appropriate for some fulfilment tasks or where you need specialised groups and build your workflows to suit.  Typically the first-line support group handling the request always has the ability to track the progress of the request, and is the point of contact for the end users.

Is that it?

  • Whether your request is a simple How Do I to a Hand craft me a personally engraved and gift wrapped iPad the request needs a defined closure procedure.  There has to be a mechanism to validate that the request has been fulfilled satisfactorily before it is closed.

How do we go about deciding what works and what doesn’t?

There is something I will state, use and promote constantly, and that is the use of scenarios.  These are invaluable whether you are testing a deployment, performing user-acceptance testing with a client, or whether you are just evaluating products.

  • Decide on what criteria you need to establish your end goal
  • Break them down to manageable steps, and here the ITIL 2011 activities and points are very nicely presented to give a starter for ten
  • For a product review, for example, look at how easy it is to configure – can I do this myself using demos on the web, or do I need a proper demo on site/webinar with a tool administrator
  • As an aside, what kind of administrative skill is required for your tool of choice?

This is a doddle, no?

A number of things can kill an otherwise promising and/or straightforward deployment:

  • Poorly defined scope – People wanting the process to do too much or not really grasping the idea that Service Request models should be pre-definable, and consistently repeatable.
  • Poorly Designed User Interfaces – The best back end workflows in the world will not help you if the user interface makes no sense to an end user.  Too often I have banged my head against a desk with developers who love how THEY understand what is being asked, so who cares if some desk jockey can’t – they can ring the help desk, right?  WRONG!  Missing the entire point of the business benefits for removing the need to drive everything through 1-2-1 service desk interaction.
  • What is worse than a front end you need a degree in programming to work through?  Haphazard back end workflow that twists and turns like a snake with a stomach upset.  Just keep it simple.  Once it starts to get super-complex, then really ask yourself is this a minor request or something that requires specific change planning.
  • Make sure your tool of choice is capable of measuring meaningful metrics.  Remember, there are lies, damned lies and statistics.  What are you looking to improve, why, what is the benefit, and what can it lead to in terms of Continual Service Improvement

There are, of course, interactions that I haven’t gone into any great level of detail in this article; but do look at one of our latest articles by  Rob England has already touched on this in: What is a Service Catalogue? here on The ITSM Review.

Image Credit