Re: [otrs] Queue versus Subqueue versus All in one queue

[Leah Kelly]

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

[David Hess]

Hello Leah,

Likewise i cannot comment on what might be best, but i can share what I am using Queues for.

We have mainly use Queues to control response times, and all agents have access to all queues.

Queues:

Support (main queue with escalation times set and uses the survey module to send surveys when tickets are closed)
Inquiry (basically a non-support queue that has no escalation times and does not send surveys when tickets are closed)

Spam (queue that users can send spam emails into

Delete (queue that admin can use to delete tickets that were in the spam queue)

We had thought about breaking the support queue into sub queues but the need never really arose for us.

But i think a general guideline would be to use a new queue when one of the queue-related configurations needs to be different.  This would include queue permissions, response templates, escalation times, etc.

I hope that helps you as you work on your design.

Regards,
David

[Gerald Young]

@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:

[Mike Morris]

> 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

My two cents worth:

OTRS (or any ticket system) exists to make our work more efficient, of course. So, IMHO, it should be configured to reflect your business processes. We have queues that correspond to major functions happening within the workflow.

The decision for me is what will minimize the amount of change (work) manipulating OTRS itself instead of doing the business work directly. Much of my input about that comes from the Agents themselves telling me what will make their life easier.

Mike Morris

The Music Place

1617 Willowhurst Avenue

San Jose, CA 95125

(408) 445-ARTS (2787)

------------------------------------

    Your Random Historical Quote:

        I enter upon the discharge of the high duties which have been assigned me by

        the people, again humbly supplicating that Divine Being who has watched over

        and protected our beloved country from its infancy to the present hour to

        continue His gracious benedictions upon us, that we may continue to be a

        prosperous and happy people.

                    - James Knox Polk, Inaugural Address, March 4, 1845

------------------------------------

  

[Marty Hillman]

Just how we are working it in our organization.

 

We considered having one user per queue, but since our practices are more geared toward teams, we opted for separate queues for those different processes.  It also allows for reporting on issue types.  For example, we have queues for Login and Access Rights, Printing, Phone/Fax Issues, etc.  Under the Websites queue, we created several sub-queues labeled by the particular web service (www.xxx.com, www.yyy.com, etc.) so that developers could track time spent for each separate business unit (each business unit has their own websites).

 

With the mechanism above, I can assign multiple agents per queue.  All agents are notified when a ticket arrives in their queue.  The first one to open it is assigned the ticket.  They can assign it to a different agent, but it is tracked that they saw the issue and passed on it.  This enables us to reliable monitor ticket flow and where we need to focus on training.

 

There is one major queue that overrides all others.  That queue is monitored by my Level I to Level III support team when time permits.  They perform triage on all tickets and assign them to the proper queues.  End users can also select their own queue, but they seldom go that extra step.

 

Hope this helps give you some ideas.

 

Marty

[Leah Kelly]

Thank you everybody, this helps a lot! I appreciate your answer Gerald, this clears things up for me
regarding the differences between the configuration set-ups. Thanks! I have decided to keep
the parent Client Services, with each AM as a child (subqueue). This is because most requests are
made to specific AMs as they are their POC.

The next questions would be, is there a way to filter the generic requests that are made
to the parent (support@) into the AM who represents them? Sometimes clients don’t know
who their AM is, so they just write to the generic box. It would be nice to push that client
to the AMs queue so the appropriate AM could handle their client.

I was thinking we could do it based on domain names, can anybody think of a better more
efficient way?

Thanks again!

[Gerald Young]

Web:

CustomerGroups, customers members of groups that belongs to the queues they have access to. (Each Queue has a group. Each agent can be members of multiple groups. Remove Queue from "users" group.

Email:

PostmasterFilter.