|
|
|
|
|
|
Queue setup can vary, depending on your particular operation. The particular steps ("how to do it") are located in the queue help topics, and the discussion below can provide insight into design and configuration options.
Tickets use configurable category fields for things like Ticket Type, Product, Location, and Next Step. The values used in these fields come from a system-wide master table that is maintained by the TeamHeadquarters Administrator. However, each individual queue can have a subset of the options available in the master table. If your available options must vary for different collections of tickets, then multiple queues will be required.
The cost rate for each person can vary from queue to queue. So, if your cost rates need to vary between customers, or lines of business, then each one will require its own queue.
Each queue can have a unique set of access permissions. For example, a user may have full control over one queue, have read-only access to a second queue, and not even know a third queue exists. Different sets of security needs will therefore drive the creation of different queues.
Each queue has its own set of users who can be assigned tickets. So, if your support operations require different sets of users for first, second, and third line support, then multiple queues will be required.
A project queue has more capability than a stand-alone queue. The main differences to consider are that project queues allow your support operation to be naturally represented in a project portfolio, and they can easily have ticket time reported in time sheets. As a result, support operations can be integrated with all other aspects of the organization's work, planning, and reporting.
Queues and projects carry overhead and require maintenance. It is best to use as few as possible, within the constraints discussed above.
