CMS9.8 Tagging

Created by: Lester Caine, Last modification: Wed 20 of Aug, 2008 (09:21 UTC)

There have been many requests for more queues, but it has now been realised that the problem has nothing to do with queues, and a simple change will allow ALL of the differing requirements to be met without the need for more queues. That is not to say that additional queues will not be added in CMS10, but rather the pressure has been removed. One of the reasons that CMS10 had been delayed was the attempt to sort out how queues would be handled in it, and take the opportunity to change things, but the current plan actually needs little change to the core system but will allow customization to be added in CMS10. CMS9.8 is just being viewed as a stepping stone to getting CMS10 implemented at all sites eventually - as part of the ongoing maintenance support.


When an enquiry record is created, the drop down list of tags will be replaced with one for 'departments', and this will have an additional set of options for 'Invalid Ticket' and 'No Show' which can be enabled. 'No show' for example will only be enabled where the ticket printer is front of house. The current arrangement of drop down lists for refer and clear will then be dropped altogether, making the receptionists job somewhat easier.
The new set of options replacing 'TAGS' will in fact further process the ticket if required, so that for instance, 'No Show' will also <Clear> the ticket removing the need for any other action and at this level additional 'reception' level actions will be introduced.


We will still retain the 26 tag and 10 clearance code limits, but the storage of these will be moved from the TICKET table to the TRANSACTION table, so we can record a different set of options for each department. The selection of a department will load the necessary set of tags for that particular department. To make the operation of this easier for the user, and still retain the ability to move a client between departments, the department selection can be changed as an alternative to clearing the ticket, so the clients ticket information will be displayed on the basis of the department they are currently selected to, and whether the secondary tagging is required can be enabled on a queue by queue basis.
How a 'queue' works can now be modified and with the simple change above, two types of queue are immediately created. If tagging is not enabled for a queue, then simply selecting that department will also refer the ticket to the queue. Where tagging is enabled, the appropriate set of tags will be displayed, so that the user can also set any relevant options before referring the ticket to that queue.
This also opens the possibility of creating additional styles of queue with more complex options but that is probably best kept until CMS10. An obvious style of sub-tagging is 'change of address' which essentially needs to be taken out of the department level and handled at the reception level. The nlpg package in CMS10 is intended to carry out that function, and then notify ALL departments of a change of address, which would also manage updates to the LLPG database automatically. This operation would not involve the use of a 'queue' under the new methods of working which is why the the debate on extra queues was being complicated. Some operations should be available at the 'receptionist' level removing the need to tag those types of operation, and these will be added as additional departments in the selection list.


Initially referral to a queue will trigger the simple back office notifications with a pop-up to the currently logged on department members, with the usual additional note if this is an appointment for a particular staff member, and all the tickets will be displayed in the same list, but expansion of how tickets are handled WITHIN a queue will now be possible. The secondary A to Z tagging could be used to allow 'sub-queues' to be created, or we will be able to introduce 'skills based' displays, where a junior member of staff will only see those enquiries that they are cleared to handle. This requires an extension to the department flag in the staff table, and an additional 'TAGS' type field will be introduced here, so that the various sub categories can be flagged. This does retain the assumption that a member of staff can only be in one department, and this may be incorrect in the way some sites work, which did add to the complexity of the discussion. However it is felt at present that those sites can still be accommodated within the proposed expansion.


The main problem with all of this development is the reliance on the legacy CMSOnline and CMSOffline for managing the 'profile' information within the STATS table. These simple changes do not affect that since the limitation of 10 queues that this enforces does not now require any changes.  We still have the restriction of the reports that are generated by CMSOffline, which a replacement web based system will eliminate, but short term we can still create most of the timing based reports that are required. It will just be breaking out the fine detail that sub-tags introduce that may have to be exported for processing initially. While it would be nice to retain the during the day profile recording, it may be that simply dropping it will allow faster progress to be made in other areas. The intention is to drop facilities from CMSOffline where they are now available via the web interface and then any facilities from CMSOffline that have been missed can be identified.


Finally the way that the clearance code is managed will be replaced with a number of flags that can be applied at the ticket level or at the department level in addition to the secondary reason code. These will initially be set to 'Resolved', 'Awaiting Client' and 'Satisfied'. The 'Satisfied' tag is intended to provide a satisfaction survey report, and may be implemented as a multi-level drop-down with five levels of satisfaction. The 'Resolved' and 'Awaiting Client' will link in with the long term element of the tasks module that is planned for CMS10, and indicate if a particular enquiry was finished, and if not finished are you waiting on some action from the client before it can be finished.