Part 7: U.K. GDS: GOV.UK Notify (2019)

By Pete Herlihy, Lead Product Manager, UK Government Digital Service, with Georges Clement, Harvard Kennedy School

In the summer of 2015 GDS started work on the delivery of cross-government platforms. We ran discoveries and alphas for things like taking payments, hosting, and sign-on.

Our minister wanted to provide a status-tracking platform — a simple way for citizens to track and trace an application (for benefits or a student loan, for example), a request, a purchase, or a payment in a few clicks — that would:

• Make it easier for people to find out what was happening with their application.
• Reduce the massive cost to the taxpayer of running contact centers all over the country.

So, in August 2015 I put together a team of three and we started a discovery into status tracking.

The Discovery Phase

The government receives hundreds of millions of calls every year, and our research showed that one in four of these calls were from people simply asking for an update on their application.

We toured the country to learn as much as we could about how various UK Government teams process these applications, following them around their buildings — from the mail room, through various back-office teams, and back to the mail room again.

We also worked with teams to map their services, and after we tried it a few different ways, a powerful pattern emerged. We divided the services into three layers: end-user interactions, system interactions, and back-office staff interactions. We also mapped things horizontally according to how long they took. This gave us a pretty good visual representation of the process and the timing.

We then folded up the bottom two slices, so all you could see was the end users’ experience of that service. We found we could predict with astonishing accuracy when the phone calls would come in. The maps also showed us the events or systems we could use to trigger updates so users wouldn’t feel the need to call in the first place.

By now the team was starting to confirm a reckon that we’d had early on — that status-tracking tools are often just a channel-shift for anxiety. They save some phone calls, but you’re still forcing people to sign in to your website for an update. And for every person who does, there are many more who won’t, instead just anxiously waiting for a letter to arrive in the mail a week later.

The Pivot and the Bad News

The team determined it would be better just to tell people what we know when we know it, so that seconds after a case worker clicks ‘approve’ on your benefit application or your student loan, you get a text message letting you know.

So we pivoted. We decided that the best way to meet those very real needs — of making it easier for citizens to know their status while saving truckloads of taxpayers’ money — was a not a status-tracking platform but a notifications platform.

We then had to tell the minister that we weren’t going to build the thing he’d asked for. We were going to build something completely different. At first this didn’t go down particularly well. But we were able to meet with the minister, share what we’d learned, and sell the idea that this would be a much simpler and more effective way to meet the same needs. We now had an advocate for a U.K. government notifications platform, and GOV.UK Notify was born.

Lessons from Delivery

We sent our first message for the Digital Marketplace service team in May of 2016. It was an email to 2,316 vendors about the opening of a new procurement framework. A little over three years later we’re sending up to 3 million messages a day, for more than 1,250 service teams and 393 organizations across every corner of the U.K.’s public sector.

We’ve learned a huge amount while developing and scaling the technical and business operations of Notify. But there are a handful of things that we got right, or got wrong, that can provide guidance for teams looking to successfully deliver a platform at scale.

Find the Simplest Solution to the Problem

Moving to notifications over status tracking was clearly going to provide a simpler solution to most of the problems we were trying to solve. And in truth it wasn’t really a pivot — we were seasoned enough to recognize that we were being handed a solution rather than a problem. We were always going to explore various ways to solve that problem through discovery and alpha phases.

We often assume politicians are attached to their ideas, but they’re more interested in solutions that work. Don’t be afraid to push back, but work hard to meet with them directly. You’ll often find they are open to persuasion and they can give you a powerful mandate.

You Don’t Need as Many Platforms as You Think You Do

While we were working hard starting to deliver Notify, platform teams were also doing great work delivering GOV.UK Pay and Platform as a Service (GOV.UK PaaS). We were also thinking about other platform opportunities. We had lots of ideas about what would be most useful to focus on next, but they were largely derived from our own experiences working on digital services and products. What we’d failed to do was thoroughly research what teams really needed, or even validate that our ideas were good.

So GDS undertook one of the most exhaustive user research exercises I’ve ever seen, interviewing more than 150 service teams of all shapes and sizes from all over the country. The output was a comprehensive list of things that services do. The most common things on the list, and the proportion of services with that need, were:

• Publishing information 90% (GOV.UK)
• Sending notifications 85% (GOV.UK Notify)
• Collecting information 80%
• Having a two-way conversation 65%
• Collecting files/evidence 45%
• Confirming a user’s identity 30% (GOV.UK Verify)
• Taking payments 30% (GOV.UK Pay)

Looking at this list we could then map our existing government platforms against those needs, highlighting where the greatest opportunities were for additional common platforms.

That gave us a good idea of what we should be exploring next: two-way conversations (potentially supplementing face to face meetings or telephone calls with something like web chat) and collecting information and evidence (something like a forms platform).

Delivering a small number of platform solutions would probably let us meet 80 percent of the common needs that exist across government websites.

Do Less, Better

Platforms don’t need to be all things to all people; in fact they’ll suffer if you try to do that. You’ll end up with software “bloat,” where a product has so many features that it becomes almost unusable.

Make simplicity your unique selling point.

With Notify, we were able to establish strong demand for the common needs we were planning to deliver before we started. This gave us a lot more confidence to say no to things we knew weren’t common and avoid building the wrong things just to chase the early adopters.

I was interviewed by the BBC’s technology correspondent back in 2016 about our aspirations for Notify. When the article came out, the headline was “Making government a bit more digital,” and the sole quote from me was, “It’s not sexy, it’s boring stuff done well.”

I wasn’t quite sure what to make of that at the time, but in hindsight it’s the perfect summary of what platforms should do.

Because we’re making something once, for everyone, it allows us to invest in quality in a way that might not be justifiable for a single service team or organization building their own platform. A good example of that with Notify is having multiple concurrently integrated connections to the mobile phone networks, with real-time switching based on performance and price. This provides significant resilience and performance enhancements to all users of Notify — and saves them money too.

Build for Self-Service

One of our first principles for Notify was that whatever we delivered had to be as self-service as possible. Getting started with Notify needed to be just like trying out any other product on the web. We joked that Jeff Bezos doesn’t come round to your house for a chat when you’re thinking about buying something from Amazon. We wanted to break the learned helplessness of teams in government, who often feel they’ll need a meeting or a series of workshops to get started with a new service.

So we encouraged people to try it first. Then, if they got stuck, to get back in touch so we could work together to make that bit of the process better for the next team. Without exception people were happy to do that and the insight we gained from this approach was invaluable.

We called this “permission to play.” We needed people to feel it was okay to just get in there try this thing out. It was incredibly useful in blog posts and presentations, and even in conversations, to be able to leave a call to action to go to the website and create yourself an account.

There were a number of other smaller and easier things we did to build on that permission to play. To make it as easy as possible for people to kick the tires of Notify and make their own decisions about whether it would work for them. In short, it’s just a list of things that make openness and ease of access a massive asset for a platform:

1. Give your platform a useful name to make it easier for people to talk about.
2. Get a good URL for your product. Make it short and snappy, so it’s easy to say and remember.
3. Learn the common questions people have and answer them on your product pages.
4. Publish your developer documentation openly. Don’t force people to create accounts before you provide access.
5. Publish your performance. People trust actual performance data over service-level agreements (SLAs).
6. Tell people who’s using your platform. Early on, teams will often note that one or more of the big departments (or indeed their own department) is using it and feel instantly reassured.
7. Publish your roadmap. This helps with teams that have needs you can’t meet on day one.
8. Open source your code. This is important for re-use but also for transparency and trust.

Look After the Long Tail

We knew not all service teams would have access to software developers in order to integrate with Notify. Others would have legacy systems that just weren’t possible to integrate with, and some wouldn’t have a system to integrate with at all.

It’s this long tail of medium and smaller service teams that are so often left behind when it comes to any kind of service transformation. They just never quite make it to the top of the prioritization list.

We didn’t want them to be left behind this time. It was really important to us that they could benefit from using Notify just like the bigger, better-funded service teams.

For that reason, everything you can do with the Notify API, you can do using our web interface.

Around half the services using Notify use the web interface to send their notifications. Without this option, many of these teams just couldn’t send notifications — and their users and their budgets would continue to suffer.

Easy to Use Isn’t Enough — We Need to Remove Barriers to Entry

The biggest blocks to adopting Notify for service teams — and, I suspect, most platforms — are budget and procurement. We wanted to make these things easier or, better still, remove the blocks completely.

So we worked with our treasury and legal departments to establish our organization as a “central purchasing body.” This meant we could buy email and text messages in bulk. By aggregating demand we could get a great price for everyone. It also meant that we could procure these items once so that all our service teams could use Notify without any additional procurement activity.

We managed to set aside some funds to provide a modest free allowance of messages for all teams. We did this for two reasons. First, so that they could get started immediately without worrying about getting a business case signed off for their spend. And second, because moving public money between departments is inefficient and expensive. It’s much better to not invoice at all than to spend something like £80 in costs to raise and process an invoice to recover a £12 text-message bill.

With the modeling we did and the funds we were able to provision within our budget, around 80 percent of teams using Notify don’t pay anything at all.

Be Patient

There’s an old saying that everyone in government wants to be second, no one wants to be first. And we definitely saw a bit of that when we were starting out on Notify.

We worked closely with a number of teams right from the start of our discovery, so we knew we had a good number of early adopters. Even so it was another team in GDS that was first to go live, and it took another three months for Notify to reach five live services.

Three-and-a-bit years on and we’re now seeing five new live services every single day.

GOV.UK Notify live service adoption

Two-thirds of service teams using Notify say they heard about the platform through word of mouth. And we’ve seen that once the first service team in an organization starts using it, it’s not long before the others follow suit.

So we’ve always focused on the number of organizations using Notify as on the number of services, because one leads to the other. Both lead to an increase in the number of notifications being sent, which is ultimately where the benefits are unlocked.

So far, we’ve helped our service teams send more than half a billion messages.

A Platform Is a Business — Run It Like One

The proportion of our team’s effort it takes to run GOV.UK Notify.

Cross-government platforms share every aspect of running a normal business. They’re classic start-ups, really, from finding seed money from the investor (in our case the treasury) to developing the product, selling it, setting pricing models, contracts, supporting users, collecting payments, etc.

It’s very easy to focus on the technical operations of a platform and neglect the investment in the business operations required to make the platform sustainable. With Notify, as much as we focus on ensuring we don’t accumulate a mountain of technical debt, we quickly learned that we need to regularly spend time making sure we don’t end up with a massive business-operations mortgage.

Having a good understanding of what it really takes to run a platform business is vital. But we’ve learned that it’s crucial that those funding and providing oversight to the platform appreciate this too. That way we make sure we have the money we need, the right people on the team, and access to other specialists like lawyers and economists when required.

What’s Next for GOV.UK Notify?

Notify isn’t “done.” Good products never are. We’ve still got a number of important features to add. And we need to iterate what we’ve already released as we continue to learn from our users and their evolving needs.

While we have terrific adoption of the platform, we’re still only a fraction into the markets and benefits that Notify has the potential to reach or the benefits it has the potential to confer.

As usage grows we have to continue to scale our technical and business operations. We also need to remove as much friction and support effort as possible, making Notify even easier for us and our users. This will allow us to continue to run the platform at scale with a small multidisciplinary team of 10 to 12 people.

Running a platform also puts you in a unique position to see what good patterns of use are emerging and creates a responsibility to share those things. So we’ll also be increasing our focus on the quality of the notifications that are being sent and looking to help teams with guidance and content-design support. If we’re going to make it so easy to send messages to people, it’s important to us that they’re as effective as they can be.

Going Global

One of the most tangible benefits of being so open about what we are doing with Notify and how we’re doing it is the potential for reusing code, patterns, and guidance internationally. We are rapidly seeing a global community forming around platforms, which we’re excited and proud to be a part of. It turns out that all governments largely have the same challenges and opportunities in the platform space.

The federal governments in both Australia and Canada have taken the Notify codebase and operating model and are now running their own tailored versions of the platform. We catch up regularly with them to share what we’re both working on and what we are learning.

We’re also in conversations about the reuse of Notify and what we’ve learned with the governments of Brazil, Ontario, and Nova Scotia, as well as the team at Code for America.

These are exciting times for platforms like Notify.