Manage long queue lists in new phone tickets?

[shostakovich]

Hi,

in our OTRS system (unfortunately) we'll probably face > 100 Queues, maybe close to 200. Probably I'll have to make "target queue" in the new phone ticket dialog more handy. Typing into the dropdown box does only match the top level. Currently I'm thinking about Javascript and an additional search box, which filters the queue dropdown respectively. Not sure if this may become a difficult task -

...did you manage to make long queue lists somewhat more neat? Some input?

TIA
Michael

[Daniel Obee]

We at least have a feature implemented that presets the last queue used. Since agents mostly answer a particular line or project that helps a lot.

Other than that: Intelligent queue naming and a strong thought about access privileges and necessities. I don't know much about your setup but agents with write access to > 100 queues kinda makes me think...

Greets
Dan

[shostakovich]

We at least have a feature implemented that presets the last queue used. Since agents mostly answer a particular line or project that helps a lot.

Unfortunately does not apply here...

Other than that: Intelligent queue naming and a strong thought about access privileges and necessities. I don't know much about your setup but agents with write access to > 100 queues kinda makes me think...

Makes me also think. Well, we've got the first Level support receiving any kind of phone calls that are being supported here. They resolve as many issues as possible and if they can't, put it in a respective queue. Queues reflect support units (like "app::office", "infrastructure::storage", "infrastructure::nas hardware")- and we've got many of them, even if often the same people are involved, but that varies slightly sometimes. So the phone agents need to see any possible queue - Access privileges won't help here.
Access privileges.. Well historically, in the old ticket system, everyone was allowed to do and see everything. And they used it a looong time. a) I need to keep complexity low and b) it's basically a question of (project) time, politics and user acceptance ... I'll see if I'll make some rudimentary access level system...

[Daniel Obee]

Queues reflect support units

Maybe the problem lies here. The cause most probably is mostly to run proper statistics, right? This could be solved by using free fields - if you refuse to use the ITSM package, which might be the best option anyway.

Greets
DAn

[shostakovich]

Yeah, statistics. Also: In the old system agents were used to choose case topics hierarchically - a destination queue was auto applied. The idea now was to have the queue names close to what their topic is. So an office support group is "Applications::Office" in our queue tree. A new agent should be able to sort tickets into the appropriate queue, thats the goal. But with many queues the concept suffers from being intransparent because tooo big.
I'm not too much into the free fields thing, I know ITSM uses some... Yes, we need ITSM because having priorities calculated from a criticality index and a dynamic impact (the cip-Matrix) is what has been starved for here... No escalation management, only best possible use of Priority.