a potted history

When we were first asked to develop a ticketing system to go with our information display system back in the early nineties, things where a lot easier. At that time customers did not have any hardware on the front of office desks, and we were specifically asked not to record caller details. The first systems were built using a combination of hardware much of which has not changed since that time. The ticket printer was placed by the door and callers took a ticket as they arrived, this queue of waiting callers was then handled in order, and people were called to a reception counter using a combination of pre-recorded announcements, visual displays, and LED displays at a serving location. In larger offices additional repeat displays would direct people to the correct area of an office for the interview room that they were being called to. As there was no terminal available on the counter, we provided two styles of small LCD display terminal, one with a full alphanumeric keyboard for the reception counters, and a smaller numeric only pad for the interview rooms. All of this hardware was managed from a single back office PC, which provided the supervisor interface during the day and access to daily statistics after the office closed.

Being linked to Public Address and LED beacons, the addition of staff security was an often requested facility, and the system supports a panic alarm package that can be activated from the terminals and additional panic strips or buttons within a room. These facilities extend to control of the CCTV system to select the relevant camera of a multi camera system so that both security guards and supervisors are able to monitor the situation without having to access the actual location. This fully integrated package makes management of a caller area easy to undertake, and provides a tidy base on which to build.

The embargo on recording callers data only lasted a year or so and by the mid nineties we had expanded the system to provide a full historic database of callers visits and appointments. About this time the installation of terminals actually at front office counters was starting to take off with the lower cost involved in providing the hardware, and the proof from the ticketing system that a lot of time was being wasted going behind the scenes to access information that was now becoming available on back office machines. Since the ticketing system was not part of the IT system, the separate terminals were retained, but a number of sites requested a means of removing the terminals which were taking up unnecessary space. At this time we had an active users group, and one of our annual gatherings to review software updates also discussed the provision of a web based interface to the system, which was introduced at the turn of the century. Part of the reason for the delay was the sudden sale of the Benefit Agency office infrastructure to private landlords. While the IT system remained under departmental control, the queue management system was 'sold' with the building, and the new owners had no incentive to even maintain the system. A few BA sites have retained control of the system and these are still tracking caller details in the same way they did in the mid nineties.

Needing to address the problem of new council, inland revenue and similar sites now having PC terminals on the desks, a virtual OTU was first created that worked in a similar way to the stand alone terminal and provided a range of facilities. This was rapidly replaced by a full web based interface into which additional facilities could be incorporated without the restrictions that the small screen and slow serial access of the stand alone terminal placed on the system. The system still supports the older OTU ( alphanumeric ) and ELF ( numeric ) terminals which can be appropriate for security positions or rooms where a full PC terminal is not appropriate. However all of the the facilities of the system are now available to anybody who as a network connection and a 'log on' ID for the system. Many sites are using the system to log telephone calls and all other correspondence from a client so that the total contact information is available for each client how ever they present themselves.

One of the major changes early in two thousand was the removal of the front of house ticket printer. In the 90's, waiting times of 60 minutes were not unusual and it was these times that 'Charter Mark' inspection was trying to address. Changes to practices, and the provision of computer terminals on the counters has drastically reduced these times and in some offices, times that were excessive in the nineties are now measured in minutes, and everybody having to take a ticket is now actually becoming the bottleneck. So rather than vandal proof robust printers in the caller areas simple thermal printers behind the counter provide a means of printing tickets if a caller needs to be referred to another queue. In addition to managing callers to the enquiry area of the office, a pass system is also provided that uses the same behind the counter ticket printing to produce visitor passes, and those visitors are monitored in much the same was as a caller to the enquiry area.

I am sure by this point readers can see that the system has been providing the facilities of a CRM system for some time, but because we were always referred to as a ticketing system gaining the opportunity to quote for offices CRM requirements have often been blocked. Since CRM systems do not provide the ticketing systems, and the necessary infrastructure to both call visitors to a counter and monitor their activity within the office, we are being asked to provide that service, but this has now become something of a problem. Offices do not want to use two pages open in the web browser ( at least IE7 now has tabbed browsing, something we have been using in other browsers for some time ) and so we need to integrate these facilities into the one interface.

Early attempts to do this have had mixed success. The use of Apache, PHP5 and Firebird allows it to be installed on any server and on some sites these facilities are provided by a customers own IT department, but the provision of real time control of the announcements, displays, LED's and panic alarm hardware has been a source of some difficulties. Replacing Firebird with a link to central database server can result in rather long delays at times between 'Calling next' and the relevant announcements and displays changing. Since Firebird has no licensing costs, we prefer to maintain it and in sites where there are no existing CRM facilities, the system can provide those facilities at no extra cost. Mirroring data between Firebird and another database is on of it's strengths, but is an area that needs to be discussed.

In addition to the server, which may be serving more than one office, a workstation provided the interface to the hardware such as public address, displays, LED and panic alarm hardware. In older systems this machine also provided the supervisor display and report printing, but that is now provided via the web interface on any browser in the office or at remote sites if a number of sites are controlled centrally. Something that could not have been done in the past. While we have tried to be flexible and work with the local 'supplier' of computers to provide this hardware, a number of problems arise which are brought about by the additional hardware built into these machines. Where maintenance is split between two providers, the machines have often been left in a state that requires even more work by ourselves to get them operational again, so we prefer to provide and maintain these machines ourselves. We maintain fully configured spares, so that in the case of a machine failure we can get you working again quickly, and will then rework the machine back into the spares stock. An additional problem that has been arising more recently has been the 'requirement' that these machines are left with windows automatic update running. In the past year on two occasions this process has left the announcement side of things inoperable and getting those sites working again has been problematic. Because of the need to be able to re-configure the machine quickly, W2k is preferred on this machine. While XP can be used, W2k is less restrictive when accessing all of the additional hardware used in the caller area and is less prone to problems should an update be required. Much of the hardware we are using has been working stably with previous versions of windows, and we try to maintain a same day repair service, something that has been proving difficult with the problems that XP has been creating. Many of our display systems have been running for years without problem and we see little reason to switch OS version at this stage.

We have introduced a couple of new LED display options, and are always looking to other options on hardware, so the flexible base on which we have been building allows lots of things to be configured on a site by site basis. We just need to retain some control so that we can offer the service that you expect for such a critical front line facility.

As well as the queuing elements of the system, the integration with web based services has allowed expansion of other areas of the system. An additional system that we supply offers room booking and management. A cut down version of this is included in the CMS allowing interview rooms to be booked, and preventing double booking of both rooms and members of staff. Additionally in much the same way as the pass option has been added to the system, management of booking for other rooms in the building, and the creation of displays relating to the days activities in those rooms can also be integrated. Remote displays can either be managed directly from the system, or as simple web based pages scrolling on a kiosk type browser local to the display.

Another extension to the system using the kiosk browser is the provision of a touch screen ticket printer at the site entrance. While this is an expensive option, it does have the advantage of allowing much more user interaction before printing a ticket. For sites with multiple services, tickets can be printed and be allocated directly to each without the need for interaction with the receptionist. Pre-booked appointments can be identified and the relevant staff member notified directly. Following the collapse of the plan to issue Benefit ID cards, the work on the integration of this facility into the ticket printer has not been rolled out, but this provision could be restored on a local basis. Another slightly more expensive option can then be taken advantage of is the provision of a real time text to speech engine to call clients by name rather than simple ticket number. This is working successfully on a couple of sites and apart from the occasional complaint about privacy, most clients like the personal approach. The cheaper text to speech packages have trouble with real names, but the rVoice package provides call center quality at a reasonable price.

We are planning to try and re-start the user group collaboration, even if only as a web based forum, and we would welcome any suggestions as to how we can improve our offering. We are currently sandwiched between the back office CRM systems and the 'deli counter' ticketing systems. We would like to be given the opportunity to open up that ground and provide a package of hardware that meets all your queuing requirements without conflicting with your existing systems.