This post is all about queue management.
A queue is simply a list of “work items” including cases, activities or other entity types. Queues are a place to organize and store “jobs” waiting to be processed. CRM includes queuing and workflow tools to efficiently manage incoming requests, this post will explain the concepts connected with this management.
System / Personal Queues
There are two specific types of queue, personal queues and system queues.
Personal queues are queues tied to an individual user (or team), whilst system queues are available across the whole system. Personal queues can be used to route important activities to individual users. System queues are used for queues of work that need to be shared. (For example: A queue of newly arrived support cases.)
With a personal queue other users do not have access to see the details of the queue. It is possible to configure CRM to automatically move items to personal queues as they are assigned.
System queues are a container for work items that a group of people might work on. Queues can be configured for any record type in the system but by default queues are configured to work with cases and activities.
With system queues agents can indicate what queue items they are working on, providing managers the ability to see who is working on what. (And importantly what items are not being worked on.)
System queues can be given a type of Public or Private. Public meaning that the queue is available to all users in the system. Private indicating that it is available to a list of members which can be defined on the queue.
Delete / Deactivate a Queue
Queues can have an email alias, meaning you can create an email address such as support@mycompany.com and have emails to this address automatically routed to the support queue.
When queues are created they are immediately active, they don’t need to be published to make them active. Active queues and be deactivated and reactivated. Queues can be deleted but ONLY if there are no queue items associated with the queue. Meaning that before you can delete a queue you must re-route the items to another queue or delete them before attempting the delete of the queue.
Note: Deleting the queue items removes them from the queue it does not delete the associated record.
Create and Maintain Queues
Whenever a user or a team is created a default queue is automatically created, this is their personal queue.
System queues can be created from the Service Management area under settings. Or in business management under settings.
You will find a queues option under service management, in addition to the option within settings. (under business administration)
It is worth understanding that the “queue” option within the Service area actually displays the entity “queue items”. So when you view a queue you see its contents not the definition of the queue.
When you create a new queue, if you enter an incoming email address a mailbox is also created. (As shown below.)
Within the mailbox you can configure how the server profile associated to the email address should behave. Such as configuring server-side sync for incoming synchronization. The options available for configuring mailboxes are not covered in the scope of the MB2-714 exam. They are worth understanding but I wouldn’t expect any specific questions on how to configure mailboxes. It should be enough to simply appreciate how the mailboxes operate with queues.
It is worth understanding that an option exists to “Delete Emails after Processing”, this will remove the queue item after it have been processed.
Also, having created the queue and mailbox the newly created mailbox will need to be approved and tested before it will operate.
Once the queue has been created you are ready to add queue items to the queue. With emails this could be automatically handled on the receipt of a new message, with cases you can use routine rules to automatically route cases to the queue. (Such as automatically move high priority cases to an escalation queue.) These options will be covered later in this post.
Or you can manually route items directly to the queue as required.
Manually Adding Cases and Activities to Queue
Here we’ll look at how to manually route a case (or other activities / entities) to a queue. From the case form you can access the “Add to Queue” option.
Once selected you and chose the queue you’d like to move the case onto. In my example I have selected the “High Priority” Queue.
Now the case is allocated to the queue, I can see it by looking to the list of active items in the High Priority queue. You can also see the details of the queue the case is on by using the “Queue Item Details” button from the case. This will present a screen something like the one below. Notice that this allows the user to see which user is working on the case. (Worked by) This field is set as users are assigned to the case or they pick the case from the queue.
Note: If the case is already assigned to a queue the “Add to Queue” button still shows, in this situation the “Add to Queue” button would effectively remove the case from the first queue and move it to the new queue. An entity can only exist one queue at any moment in time.
When we add a case to a queue, behind the scenes nothing is really happening to the case entity. But a new queue item is created on the required queue to show that this case is the “list” of items to be processed from the queue.
You can also move one (or more) items to a queue from an active case view. See below that you can select one (or more) cases and then select the “Add to Queue” option from the common bar from the view. This approach is useful when allocating several items in one go or when you want to quickly move something to a queue without opening the record.
Working with Queue Items
So having routed one or more items, next we’ll look at how to work with the items on a queue.
A queue is simply a list of queue item records. Therefore, a queue is not a collection of records but a collection of queue items. What is routed to the queue is not the record itself but the queue item record. Meaning the queue item is a go-between record sitting between the record and the queue.
In the service module when a queue is selected from a view the system is actually filtering the queue items by the queue selected. If you inspect a queue item you see no details about the actual case / activity associated, the queue item will simply state who is working on the case and when it entered the queue. This does mean it is quite a common customization to add additional information to the queue item, for example priority might be useful on a queue item in some organizations.
The drop down of queues will contain a list of all available queues, you also have their other options that might be useful to filter queue items. Including looking in all queues, all public queue or all queues the operator is a member of. These options are useful if a single person needs to monitor multiple queues.
Having selected an appropriate queue(s), you can then change the view to show;
The items someone is working on or items that are available is governed by the “worked by” field on the queue items. Meaning you’d either be looking at all queue items with the worked by set to the current user (your to-do list) or all items with a blank worked by (your “could do” list). The worked by field will remain set to the current user until the queue item is completed or the queue item is “released”, which effectively wipes the worked by field and puts the queue item back into the “pot”.
Pick Queue Items
From the queue you use the “pick” option to show when you are working on a case. (or other queue item.) Highlight one or more available queue items then select the pick option, this will present a dialogue similar to the one below. Picking the queue item will assign you as the owner. You then have an option to remove the item from the queue or not. If the item remains in the queue the “worked by” field is also set to show that you are now managing the case.
See below that I left the items in the queue so the “Worked By” field has been set to me.
You can also use the route option to move a queue item from one queue to another. Or in the route dialog select a user (or team) to allocate to the queue item. And again an option is presented to remove the queue item (or not). The owner and worked by fields are then set in the same manner as someone picking the queue item, except the selected user is used instead of the current user. This approach is typically used when a team leader “dishes out” the queue items rather than the operator picking them.
Release / Remove Queue Items
Let’s say you are allocated some cases you can’t do, maybe your about to take a holiday and need to release current activities to ensure that someone else processes these items whilst you are away. This is done by using the release option from the queue. Simply select the item(s) you wish to release and select the release option. This approach leaves the queue items in the queue, “waiting” for someone else to pick them up.
An alternative approach would be to use the “Remove” option. This however would remove the items from the queue. When considering the remove option it is important to understand that only the queue item is removed not the associated case / activity.
Note: Directly from the case you can add the case or route the case to the queue. But to pick and release the queue items you are required to do this from the queue views.
Case Routing
Another important aspect of managing queues is the concept of case routing. Within a service management setting the use of queues is very common. The ability to automatically route cases is a really effective way to help with the management of queues. The automatic routing might be based on a characteristic(s) if a case, for example all new installation requests to be sent to the installation team’s queue or all high priority requests to be sent to a “High Priority” queue.
I’m describing queues in the context of service management but it is important to understand that queues could be used by other parts of the business, for example, all fresh leads might be assigned to a new leads new leads queue.
Cases and other entities can be routed to shared queues (private system queues), system queues (public system queues) or even personal queues.
An effective way to manage new cases is to set automatically allocate the case. This can be achieved in a couple of different ways. One would be to have a workflow that is triggered when a case is created, this could then create appropriate queue items based on the case detail.
Or you can use the case routing rule functionality embedded into the service management area to route cases based on various criteria when the case is created or “saved & routed”. The rule can then add the case to a new queue or assign to a user / team. Thus making use of the save and route functionality.
Note: If you are using auto-save, it is important to understand that the case is not routed when the auto save kicks in! The routing happens when the use selects the “Save & Route” option.
At the start I said this was going to be an exciting post, I might have lied a little! But I do hope I have given you enough background information on queues to support your preparation for the MB2-714 exam
A queue is simply a list of “work items” including cases, activities or other entity types. Queues are a place to organize and store “jobs” waiting to be processed. CRM includes queuing and workflow tools to efficiently manage incoming requests, this post will explain the concepts connected with this management.
System / Personal Queues
There are two specific types of queue, personal queues and system queues.
Personal queues are queues tied to an individual user (or team), whilst system queues are available across the whole system. Personal queues can be used to route important activities to individual users. System queues are used for queues of work that need to be shared. (For example: A queue of newly arrived support cases.)
With a personal queue other users do not have access to see the details of the queue. It is possible to configure CRM to automatically move items to personal queues as they are assigned.
System queues are a container for work items that a group of people might work on. Queues can be configured for any record type in the system but by default queues are configured to work with cases and activities.
With system queues agents can indicate what queue items they are working on, providing managers the ability to see who is working on what. (And importantly what items are not being worked on.)
System queues can be given a type of Public or Private. Public meaning that the queue is available to all users in the system. Private indicating that it is available to a list of members which can be defined on the queue.
Delete / Deactivate a Queue
Queues can have an email alias, meaning you can create an email address such as support@mycompany.com and have emails to this address automatically routed to the support queue.
When queues are created they are immediately active, they don’t need to be published to make them active. Active queues and be deactivated and reactivated. Queues can be deleted but ONLY if there are no queue items associated with the queue. Meaning that before you can delete a queue you must re-route the items to another queue or delete them before attempting the delete of the queue.
Note: Deleting the queue items removes them from the queue it does not delete the associated record.
Create and Maintain Queues
Whenever a user or a team is created a default queue is automatically created, this is their personal queue.
System queues can be created from the Service Management area under settings. Or in business management under settings.
You will find a queues option under service management, in addition to the option within settings. (under business administration)
It is worth understanding that the “queue” option within the Service area actually displays the entity “queue items”. So when you view a queue you see its contents not the definition of the queue.
When you create a new queue, if you enter an incoming email address a mailbox is also created. (As shown below.)
Within the mailbox you can configure how the server profile associated to the email address should behave. Such as configuring server-side sync for incoming synchronization. The options available for configuring mailboxes are not covered in the scope of the MB2-714 exam. They are worth understanding but I wouldn’t expect any specific questions on how to configure mailboxes. It should be enough to simply appreciate how the mailboxes operate with queues.
It is worth understanding that an option exists to “Delete Emails after Processing”, this will remove the queue item after it have been processed.
Also, having created the queue and mailbox the newly created mailbox will need to be approved and tested before it will operate.
Once the queue has been created you are ready to add queue items to the queue. With emails this could be automatically handled on the receipt of a new message, with cases you can use routine rules to automatically route cases to the queue. (Such as automatically move high priority cases to an escalation queue.) These options will be covered later in this post.
Or you can manually route items directly to the queue as required.
Manually Adding Cases and Activities to Queue
Here we’ll look at how to manually route a case (or other activities / entities) to a queue. From the case form you can access the “Add to Queue” option.
Once selected you and chose the queue you’d like to move the case onto. In my example I have selected the “High Priority” Queue.
Now the case is allocated to the queue, I can see it by looking to the list of active items in the High Priority queue. You can also see the details of the queue the case is on by using the “Queue Item Details” button from the case. This will present a screen something like the one below. Notice that this allows the user to see which user is working on the case. (Worked by) This field is set as users are assigned to the case or they pick the case from the queue.
Note: If the case is already assigned to a queue the “Add to Queue” button still shows, in this situation the “Add to Queue” button would effectively remove the case from the first queue and move it to the new queue. An entity can only exist one queue at any moment in time.
When we add a case to a queue, behind the scenes nothing is really happening to the case entity. But a new queue item is created on the required queue to show that this case is the “list” of items to be processed from the queue.
You can also move one (or more) items to a queue from an active case view. See below that you can select one (or more) cases and then select the “Add to Queue” option from the common bar from the view. This approach is useful when allocating several items in one go or when you want to quickly move something to a queue without opening the record.
Working with Queue Items
So having routed one or more items, next we’ll look at how to work with the items on a queue.
A queue is simply a list of queue item records. Therefore, a queue is not a collection of records but a collection of queue items. What is routed to the queue is not the record itself but the queue item record. Meaning the queue item is a go-between record sitting between the record and the queue.
In the service module when a queue is selected from a view the system is actually filtering the queue items by the queue selected. If you inspect a queue item you see no details about the actual case / activity associated, the queue item will simply state who is working on the case and when it entered the queue. This does mean it is quite a common customization to add additional information to the queue item, for example priority might be useful on a queue item in some organizations.
The drop down of queues will contain a list of all available queues, you also have their other options that might be useful to filter queue items. Including looking in all queues, all public queue or all queues the operator is a member of. These options are useful if a single person needs to monitor multiple queues.
Having selected an appropriate queue(s), you can then change the view to show;
- all items,
- just items you are working on,
- items that are available
- etc.
The items someone is working on or items that are available is governed by the “worked by” field on the queue items. Meaning you’d either be looking at all queue items with the worked by set to the current user (your to-do list) or all items with a blank worked by (your “could do” list). The worked by field will remain set to the current user until the queue item is completed or the queue item is “released”, which effectively wipes the worked by field and puts the queue item back into the “pot”.
Pick Queue Items
From the queue you use the “pick” option to show when you are working on a case. (or other queue item.) Highlight one or more available queue items then select the pick option, this will present a dialogue similar to the one below. Picking the queue item will assign you as the owner. You then have an option to remove the item from the queue or not. If the item remains in the queue the “worked by” field is also set to show that you are now managing the case.
See below that I left the items in the queue so the “Worked By” field has been set to me.
You can also use the route option to move a queue item from one queue to another. Or in the route dialog select a user (or team) to allocate to the queue item. And again an option is presented to remove the queue item (or not). The owner and worked by fields are then set in the same manner as someone picking the queue item, except the selected user is used instead of the current user. This approach is typically used when a team leader “dishes out” the queue items rather than the operator picking them.
Release / Remove Queue Items
Let’s say you are allocated some cases you can’t do, maybe your about to take a holiday and need to release current activities to ensure that someone else processes these items whilst you are away. This is done by using the release option from the queue. Simply select the item(s) you wish to release and select the release option. This approach leaves the queue items in the queue, “waiting” for someone else to pick them up.
An alternative approach would be to use the “Remove” option. This however would remove the items from the queue. When considering the remove option it is important to understand that only the queue item is removed not the associated case / activity.
Note: Directly from the case you can add the case or route the case to the queue. But to pick and release the queue items you are required to do this from the queue views.
Case Routing
Another important aspect of managing queues is the concept of case routing. Within a service management setting the use of queues is very common. The ability to automatically route cases is a really effective way to help with the management of queues. The automatic routing might be based on a characteristic(s) if a case, for example all new installation requests to be sent to the installation team’s queue or all high priority requests to be sent to a “High Priority” queue.
I’m describing queues in the context of service management but it is important to understand that queues could be used by other parts of the business, for example, all fresh leads might be assigned to a new leads new leads queue.
Cases and other entities can be routed to shared queues (private system queues), system queues (public system queues) or even personal queues.
An effective way to manage new cases is to set automatically allocate the case. This can be achieved in a couple of different ways. One would be to have a workflow that is triggered when a case is created, this could then create appropriate queue items based on the case detail.
Or you can use the case routing rule functionality embedded into the service management area to route cases based on various criteria when the case is created or “saved & routed”. The rule can then add the case to a new queue or assign to a user / team. Thus making use of the save and route functionality.
Note: If you are using auto-save, it is important to understand that the case is not routed when the auto save kicks in! The routing happens when the use selects the “Save & Route” option.
At the start I said this was going to be an exciting post, I might have lied a little! But I do hope I have given you enough background information on queues to support your preparation for the MB2-714 exam
No comments:
Post a Comment
if you have any doubts, please tell me