
Incident Monitor example: A support request is opened by Agent A. Agent A is the owning resource. Agent A does whatever to work the request - removes it from the HelpDesk Queue to his personal queue. He probably takes ownership and assignment of the request. In IM those are two separate properties of any given request. Agent A works the request, and comes to a logical stopping point - perhaps he solicited the user for some more information, that's very common. The user calls in the next morning, and gets Agent B. Agent B asks the user for her request #, Agent B pulls the request, sees that Agent A has assumed responsibility for the request and has done some work on it, and that Agent A has solicited some more info from the customer. The customer communicates the more info to Agent B, and Agent B can do two different things at this point: 1. Record the additional info in the request & move on - as soon as Agent A returns to the system he'll see that entry by Agent B. Agent A picks up where he left off when he returns to the system, armed with the additional info recorded by Agent b. 2. Record the additional info in the request and assume assignment, working the request to resolution. Agent A retains ownership, but Agent B has assumed assignment. The system will continue to notify Agent A (because he owns the request) of progress made to the request, up to and including the point where Agent B resolves and closes it. Number Two happened a lot: it was very important to maintain a smooth transition in the customer-facing aspect of the request management system. Agent B was able to easily pickup the ball and carry the request to completion, and Agent A still had visibility of the request from the point he asked for more info from the customer/user. I feel like I'm talking a completely foreign language here - the terms and processes between OTRS and what I'm used to I think accomplish the same things in very similar ways, but I am having trouble drawing the parallels.
"Nils Breunese (Lemonbit)"
11/27/2007 10:44 >>> Kris Jacobs wrote:
Hmmm... thank you Nils.
I'm used to working in Incident Monitor at a previous employer: http://www.monitor24 ( http://www.monitor24/ )-7.com/corp/prod_im_overview.asp
This concept of locking tickets seems very foreign and counter- intuitive to me.
I am not familiar with Incident Monitor, but how does that prevent agent B from working on an issue, not knowing that agent A is also busy working on that if it doesn't use some sort of locking? Nils Breunese.