@Leah, >each AM has his own queue not a bad idea (AM = agent), but only if it's the *agent* the customer needs, not the task (that multiple agents can address).
>Developers are in a subqueue In practical terms, subqueue is identical to root queue with the major (sole?) difference being whether the queue has a parent. > It works okay when nobody has taken ownership yet. But if somebody has, you have to change yourself to the owner, then move it back to the person's queue, and then the next person has to do the same thing. Surely there's a simpler solution. Don't forget to unlock on queue move. (SysConfig setting). This might, in itself, help a bunch. > can somebody tell me what the main advantages/benefits are of each of the three configurations (one person per queue, many people in one queue, and many subqueues (each with one person in them) within one queue)? one person per queue = segregation of tickets. Note that I'll repeatedly say that a queue is a "Hat" in which the ticket sits. My usual description of a queue is the [types of] agent[s] who is/are able to service a request. If a customer has a dedicated CSR, for instance, it makes sense that a ticket should be directed to that CSR (this is not a customer based queue, which is not optimal, in my opinion). many agents in one queue = minimal hassle to get a task submitted by customer. The customer chooses a type of task (Queue) to be handled, and random agent who is able to handle that task can lock the ticket and work on it. No need to really shuffle the ticket between queues unless using tiers of agents, which leads to ... subqueues... Which are basically queues with parents as labels. In *general*, there is no inheritance, no particular other benefit, but can be used for your own reporting. In my opinion, unless you're using something like Location (or, maybe, Language) as your master queue and then agents or departments/tasks as subqueues, (or, then agents as subqueues of departments/tasks), you may find that a bunch of agents as root queues (no parents) suffices for your needs. Note that a bunch of queues means a customer may need to sift through them in web submission unless ACLs or group membership applies to the customer. On Mon, Feb 3, 2014 at 10:09 AM, Leah Kelly <lke...@tenstreet.com> wrote: > It does help, thank you for that. Would anybody else have any input on the > primary differences between these three > set-ups, and why one would use them? > > Thank you for any guidance! The manual doesn't go into it at all. I am > wondering if individuals possibly shouldn't have > queues, maybe queues are meant more for a process or a department. Any > insight would be appreciated! > > Thanks, > Leah > --------------------------------------------------------------------- > 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 >
--------------------------------------------------------------------- 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
