locked
multiple analysts can assign an incident and work on it at the same time RRS feed

  • Question

  • Hi,

    I have my analysts complaining that they get a double booking experience when working on incidents. One analyst can start working on an incident then another analyst comes along and starts working on the same incident.

    After confronting the team of analysts i suspect they do not bother to assign their incidents before starting work on them. Either that or there is a serious lag in the consoles.

    Can i create some workflow or something to make assigning an incident mandatory when opening it?

    Thursday, April 10, 2014 3:30 PM

All replies

  • very likely you're seeing the corner-case of two behaviors; Service manager's instantaneous snapshot views and technical people's tendency to avoid the Apply button.

    Assume instead that they are opening the incident, putting their name in the "assigned to" box or hitting the assign task, then continuing to work without submitting that change back to the database. here's an example: 

    1. Anne and Bob are both working the desk and about to wrap their current calls. they simultaneously click on the unassigned IR view, intending to get a new ticket in a few minutes time.
    2. Anne get's free and goes and gets the first IR in her view, IR123.
    3. she double clicks the incident, puts her name in the assignment, and goes to work on the IR without hitting apply. The assignment Anne entered only exists in the memory of her PC, until she hits apply or OK. The database still has the IR as unassigned. 
    4. Bob get's free and goes and gets the first IR in his view, IR123.
    5. he double clicks the incident, puts his name in the assignment and DOES hit Apply. At this point, the IR is assigned to Bob, so it disappears from the unassigned view for any future analysts.
    6. Bob goes to call the user, only to realize the user's line is busy because Anne talking to them, curses the gods of double booking, closes the IR window and goes to get more work.  
    7. Anne get's the user's problem solved, unaware of Bob's experience, fills in the resolution, all her work etc, and finally hits OK to submit the whole IR, but she gets a write collision error, curses the gods of double booking, closes and reopens the IR, and reenters all her work. 

    you can see how a minor mistake on Anne's part, not hitting apply after entering time sensitive assignment data, caused bob a bunch of useless work, investigating a IR that already had assignment, and herself a bunch of extra work retyping all the IR resolution data. 

    If Anne had hit apply, then it wouldn't have disappeared from bobs list until he refreshed the view (either with F5 or by clicking onto another view) but when he opened the IR to start work, he would see it already assigned and go get another one with no double work. if Anne had submitted and Bob has refreshed it would have never been an issue because the first IR on bobs updated list would have been IR125.

    Thursday, April 10, 2014 4:30 PM
  • Having a dispatcher would help, but I know that's not a solution for everyone. Thomas explained it very well though!
    Thursday, April 10, 2014 5:19 PM