There once was a time where if you had a list of things to do, paying a bill, renewing or applying for something, you would have to go and visit a few different offices or send a pile of different letters.
Now, things are very different. I can pay my taxes, renew my car insurance and apply for a passport all at the same time from my phone, while eating my tea.
This has quickly gone from innovation, to an expectation.
With around 350,000 residents phoning the contact centre to do things that could be done online, we need to make sure that we’re keeping up.
Break it down
So, how can Council as a Platform, or CaaP, help?
Council: that’s us, and the services we provide, like booking an appointment to register a birth, paying for care, checking eligibility for respite breaks, and all those good things.
Platform: that’s all the systems, applications and tools we use to run those systems. Some are public facing, some are internal.
We blogged on service design patterns and why they matter. This work aims to identify common needs, like booking, applying and renewing, and form them into reusable components that we can use to build services.
If service patterns say, we need certain blocks, CaaP says we need those blocks to fit together and work well.
All our systems, applications and platforms, should fit together giving our residents a consistent experience, all the way through their journey, no matter how complicated things get behind the scenes.
Platform approach
This sounds pretty straight forward, but there’s an incredible amount of work going into planning the foundations.
That’s what we’re doing at the moment.
Phase 1.0 is us reviewing the systems we use, looking at the high volume interactions we have with residents and how these could be improved.
We’re linking with the service patterns work, and the essex.gov.uk project, which will all help with the monumental channel shift we’re after.
Phase 2.0 is when we pull our wellies on and bring in the diggers. First we’ll create and deliver a strategy for online applications.
Then we can start upgrading current platforms and commissioning new ones. Where possible we’ll reuse pre-built components, like GOV Notify and Verify to make the job easier.
While this is happening we’ll be looking at the issues and barriers we’ve identified with our high-volume interactions with users and seeing how platforms could improve on them.
CaaP to the future
CaaP is a way of delivering online services, rather than a project. So, it doesn’t really have an end date.
As long as we do things online, we’ll need to make sure the systems delivering services can work together and that users can complete complicated tasks as simply as possible.
3 comments
Comment by Mr M P Cole esq posted on
Good stuff! Keep it going!
Comment by Patrick Ruddy posted on
It great to look at high volume systems and improve them but it is at least as important to understand who is not using these systems and why, and to find a way to get those people online. A win win for the council and Essex citizens.
Comment by John Mortimer posted on
Doing similar exercises I have found it helpful to split calls in into two; value and failure demands. We want value demands, but failure demands are those that the design of the service has created. As a service designer, failure demands should be eliminated rather than designed in.
Also, it is important to note that paying bills, as an example, is not simply one demand. It is made up of different demands depending on the persons circumstance. What I am alluding to here is the demand I need help to pay; or I cannot pay. Most of these never make it as demands, many people fear contacting the council with this problem. And these demands are not suited to be online as they are complex and non-transactional, because it is the cause of why they cannot pay their bills that they need help with.