I understand what you are saying and accept what you are saying. However, the terminologies used here are counter-intuitive.
Updates/follow-up's make the ticket appear back on the queue again. That is what I meant by flooding the queue. So the person who is responsible for the queue has to go through the queue and re-assign to the agents again to get it off the queue. Am I doing something wrong here? How best to approach this?
If there is a way to not to get them appear back on the queue again then I would really like to know.
Maybe the manual could create one or two scenarios of managing tickets and queues. That is, the work-flow process. If there is then please point me to that section.
Maybe, the process seems very intuitive to someone who has worked with OTRS for a long time or as a developer. However, it is very confusing for the "first-timer".
However, now after this discussion, I have better understanding and will re-work on the set-up of OTRS. Hopefully, my staff don't get too confused.
On 1/15/07, Nils Breunese (Lemonbit) <nils@lemonbit.nl> wrote:
Robert Bui wrote:
> By that logic, a agent can only work on it if the agent has the
> lock on it (hence the owner).
That's correct and completely intended behavior.
> Once unlocked then the ticket get back to the queue.
That's also correct.
> In our situation, it's a dilemma for us. If ticket unlocked and
> return to the queue then the queue will get very long as we get
> over 200 issues a day, in addition to updates/follow-up's which
> could be at least 1000 a day. That's alot within a week and flood
> the queue.
If you don't close tickets, yes, they will stay in the queue. Were
else should they go? Updates and follow-ups are not separate items in
the queue, they are attached to a ticket.
> By common sense, a ticket should not be locked for more than the
> time required to update the ticket. If a ticket exceeded the
> required time to get resolved then that should be escalated for the
> responsible person to follow-up.
Take a look at chapter 8.4 'Ticket Escalation' of the OTRS 2.1
manual: http://doc.otrs.org/2.1/en/html/x1350.html
> Though, if the ticket is assigned to someone to work then it
> should not return to the Queue. The ticket should stayed inside the
> agent "To Do" list.
That to do list is the agent's list of locked tickets.
> To get around this, we need to create one queue per agent such
> that the unlocked tickets don't flood the main queue. Is this what
> we should do?
Doesn't sound like a great solution. I think the normal use of
locking tickets, unlock times and escalation works just fine.
Nils Breunese.
_______________________________________________
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
Support orr consulting for your OTRS system?
=> http://www.otrs.com/