Dispatching Role at the Service Desk

[rzesie]

Hi All,

I wanted to ask you what do you think about separate dispatching roles at the service desk.
A solution that someone is trying to put on me is a one with a separate person doing the ticket routing, quality checks, etc.
So the workflow looks like that:
1. Agents pick up calls, fill in the tickets and assign to Dispatching group
2. Those people, check if everything is ok and forward or when not reject the call back to the agent.
3. When ticket comes back from 2nd line they route the ticket further and/or assign to agents for customer contact satisfaction check.

Did anyone worked in such environement? For now for most of the customers my agents handle the ticket routing by themselves.

Any advantages / disadvantages of such solution in your opinion?

Thanks in advance!

Regards,
Jacek

[UKVIKING]

Jacek

The ultimate answer. It depends

If the Service desk staff all work together, this method has benefits and drawbacks

1 - It turns some staff into nothing more than ticket takers and ticket writers.
2 - there is no clear owner within the SD as this gets passed like an unpaid bar bill.

We had a similar system - which was rotated through the staff on shift

1 -3 people answering phones and creating the initial ticket

1 - 2 people taking the initial ticket and doing some SD analysis and investigation support for the ultimate 2nd level tean

1 - 2 people dealing with the old cases - trying to clear them

As the staff was on shift (early, morning, late etc), that defined what role they had each work week - son none of the staff got stale and they kept busy and the ones with better diagnostici skills were noted by shift leader and the 2nd line teams

This should be within the SD front line team
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[UrgentJensen]

Jacek

I'd just add that if you can do this then it makes sense in an ITIL world because the SD should own all incidents and requests. By having this function you are actually doing your IM process effectively.

Rock on.

UJ
_________________
Did I just say that out loud?

(Beige badge)

[rzesie]

UrgentJensen,

Just to check if understand correctly.

The role is implemented and is rotated in a more less the same way as you mention.

My 'problem' lies in the fact that someone is trying to talk me into making it a role that assigned to specific persons instead of rotating it.

I'm not really convinced because I don't want to divide the service desk into parts. This can in the end lead me to a place where some agents perfectly create tickets but do not have any knowledge about the 2nd line support groups, etc.

Therefore I've asked for advantages of a 'fixed' solution vs the 'rotating' one.

Thanks once more!

Regards,
Jacek

[UrgentJensen]

Sorry misread the question!

Well it's simple. How long do you want your team to stay with you? Give anyone a repetitive role and they'll burn out.

Advantages of fixed:

- Establish deep relationships with other support teams
Consisten approach
- Intimate knowledge of the process and who to chase

Disadvantages:

- It's going to be a slightly confronatational role. If relationships with other support teams degrade then the process will grind to a halt. Having different people involved will keep it fresh.
- Burn out - as I said, it could bore someone to death - if your Desk is young they will find this role frustrating and obstructive to their careers. I have specifically hired older people, single mums etc. for SD and admin roles because it suits their lifestyle better and are less likely to move on.

Another benefit of rotating the roll is that it will educate the whole team in the process.

Hope that helps a little.

UJ
_________________
Did I just say that out loud?

(Beige badge)

[UKVIKING]

Jacek

In mymodel, all of the people work within the Service desk and are part of the service team

Because we were a Mangled (managed) hosting company with several customers in each region (EUROPE), US & Canada (east & west Coast), Asia Pacific (Aus, NZ, China, HK & japan)

and we had 2 NOCs - London and Honolulu, the primary NOC ( 12 on 12 off) would get the phone calls and the new calls and the other team will deal with the outstanding ones.

All of the staff in each NOC would rotate on their shift schedule between doign day, night and weekend in accordance with local law s and practices.

The team lead would always be in the Primary and managed the staff

If there were more calls than availabel staff in Primary, the secondary took the calls.
And then the Shift leads in each NOC, then the NOC duty mgr if required.

When the rush started /ended ( start of uS market , end of UK market, etc), the roles each staff member would take would depend on what shift

This required each staff to document every action and email within the ticket.

Escalation by the team went to the Primary lead, then the Duty manager, then to me as the Senior (tech NOC mgr - not admin NOC mgr)

I dealt with those that the NOC staff were having issues getting a resolution. I would deal with a particular type, write down a plan for dealing with them and provide training. Hopefully they dealt with that difficult one the next time

All of us worked in the NOC. All of us were doing Incident Mgmt dealing as the SD/NOC would do - deal with the customer, do initial investigation, escalate to appropriate internal or external support, chase...rinse and repeat as required.

As UJ said, the roles should NOT be based on Dave or Mike or Cathy but on specific roles within the SD that have been created.

The SD Incident mgmt documentation covered how the Incident was handled, passed around and escalated internally. In addition to the vendor or 3rd party escalation and problem identification and escalation as well as major incidents

It took a while to get the documentation up to date but slowly it took

It helped that the Director was big on ITIL to start

This is all Incident management
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[rzesie]

Guys,

You're a great help to me! I'm having exactly the same opinion as you do but I'm being pushed back to a fixed solution.

I will cite you as an authority in the matter and hopefully it will work out good for me.

As you mentioned before I have a young team here and I don't want to burn them out too fast.

Thanks once more!
Jacek

[CCDave]

Guy, you need to define what you class as a Service Desk. What is described here is a log it and flog it senario..I.E. A case is created and directly escalated. This is a Call Centre......

[UKVIKING]

CC Dave

You are right

the general term - Service Desk - from an itil point of view is a function

however, there are many kinds of service desk with in an IT environment

Call centre
Service Desk
etc

A call and flog it desk usually is a contact point which farms the work out

sometimes, this is done within 1 service desk (organization) which is sub divided into a call centre, technical response centre
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[UrgentJensen]

True but that's doesn't impact the question too much because irrespective of the technical level of the SD, theoretically you'd still have this role somewhere (and most likely on the SD).

UJ
_________________
Did I just say that out loud?

(Beige badge)

[rzesie]

CCDave,

I didn't state that it's a call centre neither described it anyway..unless I missed something.

I would agree with UrgentJensen - irrespective from what kind of service you have the question was meant to ask for the ticket routing and this is relevant for Call Centres, Helpdesks and Service Desks.

It does not matter how much do I solve (btw around 60% on first contact) I still have to route some tickets further.
In this case around 30% of them...

[erfo02]

My point of view is that the first two levels does not add any value to the customers at all. It might add some kind of value to the internal service organisation but is that the results your SD is aiming for? This is like assuming that the people working in the SD is useless and in order to anything to happen it has to be forwarded to the 2nd line. For me this kind of thinking is 20 years out of date - sorry.
For me the only way to create a SD worth the name is to make sure that you put as much competence in the first level in order to solve as much as possible directly. Added to competent people you should have a management system that support this of course.
This will be the cheapest and, from customer point of view, the most appreciated way of doing it.
_________________
Eric Fogelstrom
Founder/CEO CompITIL
ITIL Service Manager

[rzesie]

erfo02,

I never said that forwarding is the only option. As mentioned in an earlier post we solve around 60% of the incident in a sophisticated and highly customized environment.

The only thing I wanted to ask for is your opinion on the way the routing of the rest is done and I've got a lot of answers that satisfy me and moreover I agree with your opinion as well!

Cheers!