Lessons in configuring a service, running pilots and handling diversity in skills
As we’ve developed our new consular appointment booking service we’ve encountered several challenges along the way, not least getting into the embassy in Madrid, and learnt many lessons which we can apply to future transformation work on legalisation and emergency travel documents.
Parents and children
We have set our service up with a hierarchical parent/child structure, with the parent level containing global shared settings and the child level containing each individual consulate’s account with its local users and settings. This has been essential for allowing us to gain consistency and scalability on one level (parent level) combined with flexibility and localisation at another (child level at each post). However, getting that balance right is difficult, and one of the areas where we have made the most iterations. A useful rule of thumb for this has been that if in doubt, start with the setting at the parent level as this is easier to manage and scale, and there is a risk that if you start at child level it may soon diverge (e.g. people may change the name of a service) and you’ll never get it back. Then it is a matter of responding to feedback and waiting to see whether needs emerge which warrant a change – and ideally identifying common cases so that these can in turn be grouped and shared for easier maintenance and scale.
Hiding unused options
Rather than writing bespoke software, to deliver this service we chose to license a configurable off-the-shelf solution, sometimes known as Software as a Service (SAAS). Such software normally comes with a wide range of functionality. We have learnt that it’s best to hide those features which you do not intend to use, or which have not been fully configured. People are curious and will click, select and save to their heart’s content, sometimes with unintended consequences – and with a globally distributed network it is hard to keep track of this. If you can’t hide it with an out-of-the-box setting, then CSS is your friend.
Running a pilot
We originally asked for posts to volunteer to join the pilot programme, and selected a representative range of locations, sizes and services offered. This was a practical way to get started, but created some disruption in countries with multiple posts: for customers there could be different instructions for how to make an appointment depending on the city chosen, and staff in the country would have to run two systems at once (particularly difficult in countries using the hub and spoke model). So, as the pilot expanded, instead of adding individual posts in new countries as originally planned, we shifted to prioritising the coverage of all posts in each single country before moving on. In this way, we ensured that the same service was available for all FCO locations in Spain, Turkey, Germany, France, Indonesia, and Vietnam.
We also underestimated the amount of time, assistance and encouragement which would be needed to get posts up and running on the new service, even if they had originally volunteered. In some cases this related to the levels of confidence of local staff faced with switching on a new online system, especially at the point of actually going live; in others it was due to the competing demands of case work and the difficulty in finding a window for the necessary investment in time.
Churn
A particular feature of life at the FCO is that staff regularly move between postings, and over the course of just a few months I have been surprised by how many times I have needed to update contact details. My starting point of a simple list of email addresses for staff involved in the pilot soon grew unmanageable, and morphed into a spreadsheet tracking incoming and outgoing staff, how far they had progressed with set up, and ultimately something akin to a CRM funnel with a range of filters to get the addresses needed at any point. In future I will start with this approach from the outset.
Skill diversity
There is a broad range of IT literacy amongst FCO staff – this makes it a challenge to pitch training at the right level for all people. Feedback on our first training indicated that what was “so straightforward” for one person was ” very complex” for another. We also faced the challenge of getting the right balance in breadth, aiming to cover the key points while avoiding information overload. We duly encountered some problems with areas we had not covered at first. We have addressed this by splitting out training for different levels of users and for different stages – setting up the service, running the service, advanced settings, etc
Related to this is the importance of getting the internal communications right, so that consular users know what to expect and are convinced that the change will be a good thing. We’re now planning more communications to staff as part of the wider rollout, to tell them how to get training and support and to warn them about common pitfalls.
Internal service support
We need to sort out support channels for our internal users – we currently have a small digital transformation team handling all the staff support, which we know we can’t scale for the worldwide rollout. So we are busy organising new support channels including a tips and discussion forum, more self-help guides on our intranet, and support via our internal IT helpdesk and digital hubs.
Content updates
We distributed guidance for updates to relevant pages on GOV.UK, but discovered one or two web editors are still partial to adding links in the style “click here”, or even its long lost cousin “click here”, which conflict with best practise guidance on how to write good links.. This prompted the need for an ongoing content audit as we roll out.
Data driven
Having decent reporting built in from day one made it easier to encourage data-driven approaches rather than just follow assumptions. If a post requested a set of highly customised changes before going live, for example to the elements of a booking form or the wording, we could encourage them to go live without the changes, check the data, and then see if the assumptions were valid and anything did still need changing. This would have been much more difficult if we couldn’t quickly access the data to monitor behaviour.
So what’s next?
With these lessons in the back pocket, we are now in the process of extending “CABS” to the whole network, lining up more user testing, making further tweaks based on feedback, and sharing our experience with colleagues from the Ministry of Justice and the Treasury. I’d welcome comments below if you have similar experiences to share.
Follow Mark at @markbarlow