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) <[EMAIL PROTECTED]> 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/
_______________________________________________ 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/
