BRI AN HORISK Developing a new call-management system for the Scottish SPCA highlighted the importance of listening when creating bespoke software.
Developing a new call-management system for the Scottish SPCA highlighted the importance of listening when creating bespoke software
As a development company, there are lots of areas in which you can specialise. But most important of all for any bespoke developer, where you’re trying to develop a system for a specific need, is to listen.
One of our recent projects is a good example. The Scottish SPCA, Scotland’s animal welfare charity, runs a national helpline available to the public 16 hours a day. It takes over 200,000 calls a year, many of which are escalated to its 200 or so inspectors and animal rescue officers.
It wanted to replace its existing system for the management of these calls: leading call handlers through a process to enter the call, then dispatching the call to an appropriate inspector, recording their response and tracking the call to completion. Many calls are urgent, and all staff rely on the system for their job. Significant system downtime is unacceptable.
There are lots of users within the Scottish SPCA, who each had their own priorities. Listening to them all and combining their sometimes conflicting needs into a coherent system is hard. But this isn’t a complaint. One of the reasons this organisation is a great client is that it was happy for us to spend time with those who would be directly using the system, to get their perspectives and understand their job.
The following are a few issues we faced, where listening to potential users helped build a better system.
Streamlining the call process
It often helps to start with the things that are most visible to the end user, even if these don’t feel like your highest priority as a developer. Working with elements they’ll see and touch helps get users involved, particularly if they’re not familiar with an Agile development process. This lets them see some instant results, generating enthusiasm for the project and overcoming resistance to change.
In this case, the most-used part of the system was the screen that captures all the information about the call – so that’s where we started.
First, we listened to a sample of typical calls to the helpline. These highlighted the variety that came in, from the trivial to the critical. The call taker must quickly grasp the nature of the call and structure their response to it, capturing all the required information.
The existing system had been adapted from a generic field engineer helpdesk system, so hadn’t been designed with this specific call process in mind. It involved jumping around between a number of different tabs, in no obvious order – to the extent that some call handlers had resorted to taking notes on paper and entering the call in the system later, potentially delaying a response.
We looked at all the data required for the different types of call and spent time talking to the users to determine the best order to record the data.
Eventually we came up with a long, single-page form, with each group of data split into collapsible sections, all in the order in which it made most sense to collect. When the call type was entered, irrelevant sections would automatically be collapsed so they could be ignored. Having a long form rather than horizontal tabs made it easy for a user to scroll quickly through the call details. This went through several iterations as different types of user tried it out.
Who should deal with the call?
The Scottish SPCA inspectors need to cover the whole of Scotland, and the helpline is available from 7am to 11pm, so there are multiple shifts and a complex rota. At certain times of the day an inspector might cover a single or multiple areas, or be unavailable. But call handlers need to know who is the most appropriate person to allocate a call to at any one time.
Prior to this system, a rota was drawn up in each region for the local staff, and this was communicated to head office. It was displayed on a huge whiteboard in the call centre, and the postcode areas each person covered were listed in a paper manual. No surprise, then, that keeping everything up to date was a challenge.
We had many discussions with admin staff to tease out the business rules, and the exceptions to those rules. People don’t think in terms of logical rules – they just know how things work – so the skill here is in figuring out a way to encode that system into a set of rules that will work in every scenario. After numerous iterations, we finally devised a data structure capable of capturing all this information.
This allowed the administrator in
“Listening to all the users and combining their sometimes conflicting needs into a coherent system is the hard part”
each region to enter the full rota for their area (via an Angular app) and indicate exactly who was covering what area and when. Then, when call handlers entered the postcode of a call, they could be presented with a list of only those staff who were available in the area, or neighbouring areas, of the call.
The transfer of legacy data?
We knew from our discussions that historical data was vital, so our next challenge was to extract over a million records of legacy data from the old system. This was complicated by the fact that we weren’t able to get information from the existing supplier. However, we did have full access to the underlying SQL Server database.
Unfortunately, this database contained irrelevant tables and fields, so this turned into a laborious process of manually looking at all the data in the front-end for some sample calls, then determining which tables and fields each piece of data came from. We then devised a series of scripts to import and transform this data into our new data structure.
The essential part of this process, though, was getting experienced users to compare records in the old and new system. Users know instinctively whether or not data is correct – they will have a feeling about how many calls they expect at any one time, and what data should or should not be there – in a way that a developer or QA tester may not.
How do we give the inspectors more control?
All the inspectors are equipped with physical keyboard BlackBerry phones running OS 7 or below. These had worked well; they were rugged, easy to operate with gloved and/or dirty hands and relatively cheap, while IT were reassured by the security of the BES network.
In the original system, inspectors would receive a message with the details of each call – usually by email. The developers had worked out three letter codes to allow inspectors to automatically acknowledge, reject, or close jobs without involving call-centre staff by sending a reply message. The system collects these messages and acted appropriately.
But on speaking to inspectors, we discovered their frustrations over the things they couldn’t do. Viewing the full live call details, for example, or creating a more sophisticated response, such as rejecting a call but forwarding it on to another colleague.
We didn’t have the budget to build a BlackBerry-specific app for this sort of functionality, but since we were building a browser-based system, we were able to develop specific versions of the application screens that held the information the inspectors needed. This works well when they have a reasonable data signal, but email remains an option for when there’s no signal – as these can be queued to be sent later.
Again, after several iterations and trials with the inspectors, we devised a system of encoding all the choices a user could make in a series of “mailto” links. The call details would be followed by a list of their team members’ names, encoded as a mailto link. To re-allocate to a team-mate, they simply click the name of the relevant person, and the BlackBerry email client will create a new email to the system containing all the relevant info. One more click to send and they’re done.
Going live
With a business-critical system, going live requires not only confidence that everything is correct, but also the customer’s confidence that it’s correct.
This confidence begins with training, to ensure everyone understands the new system. We initially trained expert beta-testers both in the call centre and in the field – and they then trained newer or less-skilled users to ensure that everyone was comfortable with the new system.
As go-live approached, we started to run the new system in parallel with the old system – specific users were chosen to enter all their calls in each system to ensure we were capturing all information in both. To check that stats and reports matched up, we automated imports of data from the old system nightly.
After a few weeks of this, with tweaks to fix a few issues that arose, both we and the Scottish SPCA felt ready to press the button. After one final overnight data import, everyone started the following day with the new system and, thankfully, the transition went smoothly.
“Essential to the process was getting experienced users to compare records in the old and new system”
Final call
What’s interesting about these challenges isn’t the solutions we came up with, but the way to go about solving them. In almost all cases, the key was good communication with the client and end-users. An Agile method of project management helps here, as users are more involved in the process and can influence the system as it evolves, but so much depends on building good relationships with all the people involved, listening to their needs and giving them all something that they want.