The IT Skeptic - Comments for "Shopping: request vs incident"

cheetahs and elephants

skeptic — Wed, 08 Aug 2012 17:58:00 +0000

No I'm not saying that. Nor did I mean to imply that SPOC means single channel. That's just an artifact of our analogy.
I did indeed mean to imply that there is nothing special about incident priority amongst other request types.. If u service my incidents as cheetahs and my non-incidents as elephants I will quickly go elsewhere. It will happen that some requests are of higher priority than incident requests.

The very fact that IT considers incidents more important than other requests shows our inside-out nature and failure of customer service. We need to treat all requests including incidents as one pool handled and prioritised by customer service, and handle repair of interruptions as an entirely separate activity and team.

It's logical Spoc...

RichPem — Wed, 08 Aug 2012 16:33:35 +0000

I couldn't agree more with the thrust of your post.

I don't necessarily agree that an SPOC implies the channel has to be the same though. I might order over the telephone and file returns on the internet, or vice versa. I might be happy to return the item at an alternative store, if it's more convenient.

And of course the levels of service might differ too because the classes of request are different. Comparing the service levels of a 'service request' with an incident is like asking why your elephant doesn't move as fast as your cheetah.

Personally I think this is nothing more than theoretical niceties. Most people just want to know where to go and what will happen when they go there - doesn't matter if it's the same place or not (provided it's no significantly greater inconvenience). That's service for you, not forcing everything down the same pipe because a book says it's best practice (and I know you're not saying that) :-)

Rich

self checkout

skeptic — Fri, 03 Aug 2012 18:56:30 +0000

I doubt you are opening tickets direct with level 2. Experienced users put enough detail in so that the ticket gets forwarded by the Level 1 SPOC to Level 2.
Try NOT putting the detail in and you will soon find out you are still going through the SPOC.
The analogy with supermarket self-checkout is that you are still going through checkout. You aren't going upstairs to the accountants to pay your bill.

Self-service

Vladimir — Fri, 03 Aug 2012 09:45:33 +0000

In the modern stores there are self-service checkouts that help experienced customers to get through quicker in case there are queues in the store or for some other reasons (geeky or sociopathic customer experience?).

I see strong parallels with modern IT environments where experienced customers are given possibility (in form of self-service portal) to put through their incidents & requests (wherever they do distinguish difference or not) directly to experts, avoiding SPOC.

I like the SPOC concept, but dislike the implementations I saw. There is often lack of subject expertise from an experienced customer view. In techy services like IT applications or outsourcing services (not just plain desktop support) this becomes real challenge.

Vladimir_ITSM at twitter (@vivanovs)

SPOC or not

aroos — Thu, 02 Aug 2012 08:15:03 +0000

In the shop the most interesting number is of course the sales, i.e how many (much) sales we made. Returns are interesting only if there is something unusual about them.

I personally detest communicating with a SPOC which does not understand what I am talking about. I would much prefer to contact an expert directly. The concept of a SPOC is based on the assumption that the majority of user requests are fairly simple. This can be true in many cases but not always.

Aale

What we don't want to see happen

skeptic — Wed, 01 Aug 2012 10:03:44 +0000

Let me clarify some more here.

It is possible that you make users go to one website or ring one number to get a change to their security access, and a different website or phone number to report a network outage. (Aale seems to be anti-single-point-of-contact these days but I think there is still general agreement that SPOC is good practice and I personally detest having to deal with multiple points of contact.) But EVEN IF you want to impose a separate channel on users depending on their type of request, they are still all requests.

What we don't want to see happen is

we run a report on how many incidents we have dealt with this month and another report for "all other requests"
the records are actually in two different database tables
we have two SLAs, one for incidents and one for "other"

This is absurd on every logical level but ITIL has imposed it on many tools and organisations.

I compiled this taxonomy of request classes. Is Incident more or less important than each of the other types of request? You can't answer that. It depends on the site and their policies and priorities. You have to monitor performance across all request types including an overall consolidated reporting. You have to prioritise according to impact and risk and value, not according to what type of request it is. A priority-2 new-user-provisioning request can be more important to the customer than a priority-2 service outage: you must manage your entire portfolio of requests, not in silos by type. And especially not by peeling off Incidents on their own and lumping everything else in one Request bucket: that's inside-out crazy talk.

It is possible to have a

skeptic — Tue, 31 Jul 2012 18:58:00 +0000

It is possible to have a separate Complaints desk. Good places don't becuase they want to offer single point of service. And of course small places don't.
In general all transactions start and end the same, only the middle varies. And yes it varies a lot .
A purchase workflow is different to a return is different to a repair is different to a layby is different to a booking for future appointment is different to a simple enquiry .... they all differ in the flow of resolution. As a customer I see them all as transactions and expect as much of them as possible to be uniform.
Even with a separate complaints desk I would arrive at the normal sales desk and be sent there, so the transaction still starts exactly the same.

There is an object class of Request or Response or whatever you want to call it, and ALL user interactions are subclasses. They all inherit some properties and behaviiurs from the parent class.

Actually they are different

aroos — Tue, 31 Jul 2012 08:10:21 +0000

Roy's question is good.

Shopping at least here usually means that you pick your thing and pay it at the check out. The process is quite simple. The check out point does not usually handle complaints and returns. If it does, it can be quite unpleasant for other customers who would like to pay.

Also the right to return things is not automatic. Of course faulty items can be returned but they may need to check that the item is actually faulty so that it is not a case of a user error. Many stores will accept even non faulty returns under certain conditions but these need to be checked. For this purpose some stores have a separate customer service desk, which handles inquiries and returns but not purchases.

So, I would say that these can be two different functions using different procedures.

Aale

There are many types of

skeptic — Tue, 31 Jul 2012 03:39:42 +0000

There are many types of interactions with users, not just 2. At least a dozen by my reckoning. Of course we keep records of each type, so we can see incidents. But to treat incidents as something special.or distinct from requests is utterly geeky and inside-out.
We interact with users. We should track and manage them all centrally with common tool and process. Each type will have variations. Incident is one such variation.

Good answer for the customer

Roy Atkinson — Mon, 30 Jul 2012 23:16:30 +0000

Rob - Often, we as the business (yes, I do include IT in that phrase) have our own interests, and too often they've been put ahead of the customers' interests. You are correct in thinking that, as a customer, I don't care to know how the sausages are made in the back room; I only care that they are available, fresh and tasty.

I also know very well that it's of great importance to the store how many things were returned, whether broken radios, clothes that don't fit, or sausages that have "gone off." We need to know--even if our customer doesn't care--more than just what our sales tally tells us at the end of the day, i.e., how many tickets we've resolved.

Just as it's frustrating to go through an arcane process to return something to the store, it's painful when we only view the incident/request dichotomy from the IT perspective.

We do, however, want to find out how many times our customers' work has been interrupted because of faults in their desktop configuration or in our network or in our applications or their delivery, with the goal of eliminating as many of these faults as possible.

To to back to your metaphor of striking the rock where it will break, I'm hard pressed to think of a more natural division than between "what did we sell" and "what broke or didn't work." Whether we call these two things "incidents" and "requests" is irrelevant. It is not that difficult to make this separation invisible to the customer. And that, I believe, is the key.