CMS Queue Expansion
In the past tagging and queues had been designed as separate facilities, but it as become apparent that current operations are somewhat different, so as part of the expansion of the number of queue's we are looking to tidy up the operation in this area.
If we keep the basic tagging to 26 items, it's a manageable length list for the users. Duplicating that to the referral drop down was the thing that seemed the wrong approach, but there is no need to! *IF* we say all records must be tagged, then the only options that are needed for 'Refer' are the queues related to the tag(s) used. Most of the time 'Refer' does not need a drop down, only when there is more than one tag, and until a ticket is tagged the button does not appear. What this means is that we actually replace the basic set of tags with a set of 26 queues, and we just have the one set of titles for these. For offices which clear a section of their enquiries at initial reception, the serving time or that 'tag' can then be incorporated with the serving time for the tickets that are referred to a queue. Currently only the serving time for the queue is reported.
Once a Tag has been selected, a second drop down list may appear with the 'sub' options for that tag, if these have been defined. Keeping everything nice and tidy and avoiding lots of long lists. The only problem remaining is how to handle multiple enquiries, do we show the sub-list for the last tag used, or provide all of the sub-list items for all the selected tags. One of the ideas floating around is to timestamp the tag information, so we can use the time between selecting tags as an indication of 'serving time'. This only comes into play when we have 'multiple enquiries' on the same 'ticket' and also depends on what needs to happen with the sublist items. Do we need to record X1 serving time as well as X2 or can we get away with just 'X'. A separate table of 'TASKS' will be needed and will allow multiple 'actions' on a ticket record. It may be that we can combine this with 'Clear' - currently a number of offices are using that for extra tags which can now be handled properly with the planned changes. Rather than clearance codes, the sub-list tags would provide that function.
The changes to 'STATS' that are outline in the CMS9.8 Upgrade document can be managed easily - provided that Online looses it's current display of queue information on the right - which is where the 'profile' statistics are currently taken from. Basically rather than a single record with 10 sets of fields for ten queues, the 'STATS' table will have records with only the three numbers we need for 'profile', and multiple records so we can have an unlimited number of queues. ( Keeping the 26 limit just makes displaying information easier when we do not have all queues listed - the letter is a quick reference ). There is also a possibility that we can add a second set of three fields to show the 'serving' information against a queue but I need to do some more work on that, since serving times can be quite short - but then waiting times are now as short.
Once we have defined a larger queue range, the team facility used for designating which staff members receive pop-up information also needs changing. The initial plan is to replace the team number, which was used for teams 1 to 10 with a set of flags similar to the existing TAG field. These can then be selected and deselected in the same way as the tags are currently. In this way a staff member can be flagged to receive pop-up messages from a number of queues if required. Additional fields may be added to the STAFF table to add further controls once the basic functions have been achieved.
A request has been made for only posting the pop-up to the next available member of staff. This will be handled as a change to the appointment pop-up, by creating a temporary appointment. See Queue Supervisor for the outline on how this will be implemented.