Thanks for giving your company as an example.
Maybe, our company is probably has very typical setup of the helpdesk.
There is one Helpdesk that monitor incoming tickets and assign to the appropriate queues (two at the moment - support and software change request). There are three supervors/managers who are responsible for the tickets. There are 12 agents who carry out the work.
The Helpdesk could assign the ticket to the agents (and possibly the responsible person at the same time). The agent could work on the ticket on the day or within the week. The Helpdesk want to check any outstanding tickets (this could be done via Search function).
The Helpdesk found that there are two tickets related together so the Helpdesk merge them up. Immediately the Helpdesk becomes the Owner (by default) which is a problem. Not sure why this is the case.
The Helpdesk could set the ticket for pending and send a reminder to the agent (not necessarily the Helpdesk). Again, the ticket is locked and now owned by the Helpdesk (by default). Not sure why this is the case.
There are other situations where the ticket get locked by default.
This could occur for the supervisor (responsible person).
Now, we could turn the auto-lock to get rid of the above "problem".
On 1/16/07, Nils Breunese (Lemonbit) <nils@lemonbit.nl> wrote:
Robert Bui wrote:
> 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?
In our company the agents lock the tickets that they're going to work
on themselves. They keep them locked when they're waiting for a
follow-up, so the tickets stay in their locked tickets list and do
not appear in the queue, unless unlock time is reached or the ticket
esacalates.
> 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.
OTRS is meant to be very flexible and fit into whatever workflow you
want. This also means however that it probably takes some tweaking to
your liking. Scenarios could be nice, but they would never cover the
matter. Maybe if you'd explain your business setup maybe people here
might have some practical suggestions.
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/