strategy of queue hierarchy

[zeus]

hi

please, advise

what is the "correct" strategy for queue hierarchy?
vertical of horizontal (when is it better to use each one of both)?
is queue branching good or evil?

[wurzel]

Hi,

http://doc.otrs.org/3.0/en/html/what-is-a-queue.html


Flo

[crythias]

viewtopic.php?f=62&t=21712

what is the "correct" strategy for queue hierarchy?

A queue is designed to be a collection of tickets that the agents assigned to the group assigned to the queue are able to accomplish. Do not use queues for customers.

vertical of horizontal (when is it better to use each one of both)?

Horizontal is good for significant differences in types of tickets to be organized, and for different departments handling tickets.

Vertical is ... well, depends. Vertical might be useful for location, language, or sub categorization. However, getting to specific things to address should be handled by services.

is queue branching good or evil?

Making queues is a one direction action. You can't delete them (you can invalidate them) once you create them. More Queues=more organization = more "handling" of the ticket, but more "reporting" capabilities.

It all depends on how much "organization" and "reporting" you wish after you segregate the tickets to the agents who will handle the tickets.

[zeus]

Do not use queues for customers.

ok, yes, "begers can not be choosers"(c)

Horizontal is good for significant differences in types of tickets to be organized, and for different departments handling tickets.

mmm ... so, what if it is all tickets are related to one department only? I'm trying to deploy OTRS mostly for our IT department but the bundle of the questions is much different, from networking (L2,3,5-7) to purchasing different stuff

Vertical is ... well, depends. Vertical might be useful for location, language, or sub categorization. However, getting to specific things to address should be handled by services.

ok, it is keyword for me (concerning the services)

but more "reporting" capabilities ...
...
It all depends on how much "organization" and "reporting" you wish

so, if I want to have detailed reports and statistics, to branch queues is not bad idea indeed?

[crythias]

so, what if it is all tickets are related to one department only

Read the link I posted.

but the bundle of the questions is much different, from networking (L2,3,5-7) to purchasing different stuff

General categorization of types are good candidates for queues. Specific things that would be handled as part of the type are good candidates for services.
For example: networking, purchasing = queues
networking::first floor, networking::second floor = vertical/subqueue
purchasing::capital expense, purchasing::consumables = vertical/subqueue

Possible candidates for service:
cable run
domain connectivity
email connectivity
Internet connectivity
server purchase
media purchase

See also viewtopic.php?f=62&t=6337 and viewtopic.php?f=60&t=11235

so, if I want to have detailed reports and statistics, to branch queues is not bad idea indeed?

not a bad idea, no, but you should consider what you want to report on before you get too granular.