How accuRx changed the course of vaccine booking across the UK in less than 4 weeks

Jennifer Rose
Accurx
Published in
8 min readJul 29, 2021

Jen Rose, Product Director at accuRx

“Vaccine is go.”

Back in November, this message from our Head of Product Benji would change the course of me and my team’s life for the next few months.

In early November, it became clear that GP practices were to play a key part in delivering vaccines, alongside mass vaccination centres, hospitals and pharmacies. Once the government announced that the first vaccines were ready to go, we started discussing how we could help at accuRx. We had already built a fantastic messaging service used by over 98% of GP practices in the UK, and had extensive knowledge of the GP network across the country, but hadn’t yet built anything focused specifically on vaccines.

Speaking to our GP users, it became clear that they were worried they wouldn’t be able to participate in the national vaccination programme without supporting tech to help them deliver it. If they didn’t have a way to make the rollout more efficient, they risked neglecting their existing commitments to patient care.

We knew we needed to act quickly if we were to have a real impact. GPs across the UK were working out how they would book and administer vaccines, so once we decided “vaccine is go,” we wasted no time. Later the same day we ran a session to map out what we needed to deliver in an initial version — weighing up getting something live quickly whilst making sure it would do the job necessary.

We thought the biggest problem would be getting the right people to the right vaccine centres, so we decided to build accuBook — a product for GPs to easily invite patients to book their COVID-19 vaccinations via SMS.

Mapping our MVP (Minimum Viable Product)

The Minimum Viable Product (MVP)

We came out of this session with 5 user flows that would be necessary to build for our first iteration if we wanted to enable people to book themselves in from the start:

  1. Setting up vaccination clinics and calculating how many appointments would be available for patients to book into
  2. Uploading a patient list and invite them in bulk to book in for their vaccines
  3. Patients being able to book themselves in by choosing from available appointments
  4. Manually booking patients without mobile numbers in, and following up with non-responders
  5. Being able to see which patients are booked in for a given day to receive their vaccinations

Having set ourselves a deadline of having a working version by Christmas, we built the above and shipped our MVP in less than 4 weeks. This meant we were in time for practices to use our software to invite and book in patients for their first vaccination deliveries.

We’ve previously written about how this was possible from a technical point of view, so as the Product Manager of the team I thought I could compliment this by walking through a few of the other factors that made it possible.

  1. We had a strong team

We care a lot about team structures at accuRx, and put a lot of time and effort into making them great. My product team had been working together for a few months prior to November, and had already built two products together; Patient Triage and Batch Messaging. We had a high level of trust, a real drive to support our users, and the whole team was keen to take on this challenge together.

2. We didn’t have to start from scratch

Before we pivoted to the vaccines work, our team had recently finished building a product for batch messaging, allowing our GP users to upload a list of patients to send out a text or personalised link to them all at once.

Once we started scoping the accuBook MVP, we were able to re-use some of the elements we’d already built for vaccine flows, such as the mechanics of uploading a patient list, and sending invites to patients in bulk via SMS.

You can see how similar the patient list upload screen is for both batch messaging (left) and for vaccine invites (right)

Our team had also worked on Patient Triage, an online consultation product which enables patients to fill in a simple form to tell their GP about a medical or admin query online, versus waiting on hold on the phone for ages in the morning about something non-urgent. One of the main flows we had built was the patient-facing flow where they filled in details about their query, which we then used as the basis for the patient booking flow for the vaccines product.

Aleena, one of the engineers in our team, had already put a lot of effort into making sure we had baked accessibility in from the start for Patient Triage, for example ensuring that the pages could be read by a screen reader. Being able to lift the accessibility features from elsewhere was a real advantage. You can read more about why accessibility is so important to us in Aleena’s blog.

3. We had the necessary infrastructure

At accuRx we have a real bias for action, and the phrase ‘ship early and often’ has always been a principle our product teams have lived by. This meant we didn’t have to try and come up with a way in which engineers could be working on similar parts of the code in parallel to each other. We already had processes in place to be able to release sometimes multiple times a day, as our public release notes show.

‘Feature flags’ were also already in common use. This meant our engineers could be working and testing new things without fear of something being released too soon if someone else wanted to push a change live for users.

4. We made sure our ways of working pivoted with us

One of the key things that helped us build so quickly was close-knit communication. We were building the 5 flows I mentioned earlier in parallel, so there was a lot to keep track of.

Mike (our tech lead) and I already had a great working relationship… a good thing, because it was about to be put to the test! From the day after the story mapping session, we moved to daily syncs every morning, to check our progress, which was a great way to make sure we were on top of all of the moving parts.

We also moved to having daily goals within the team, vs our normal weekly ones. This helped keep everyone focused on the most important thing to do that day. Mike and I also continuously checked in on our ways of working and what we could be doing better — an example here below of us reflecting on an unproductive team planning session and realising it would be better to do individual check ins with the engineers to save everyone else time:

5. We knew our users REALLY well

A really tricky part of building the accuBook MVP was that no one had run a COVID-19 vaccination clinic yet — our aim was to get the MVP live before they had to invite their first patients. Therefore it made our usual process of going out and researching this with our users really tricky. We still did it, but some of the first conversations we had before anyone had run a vaccination clinic went a bit like this:

“When you’re setting up your clinics, how far in advance are you going to know how much vaccine you’ll get”

“We’re not sure yet, we’re getting told soon”.

“How are you thinking about your DNA (did not attend) rate and ensuring vaccines aren’t wasted?”

“We have no idea what the DNA rate will be yet. We’re thinking low? We’ll copy what we did for the flu and learn as we go”.

This meant we had to make a LOT of assumptions at the beginning. It was important to make sure we were documenting these, so that we could go back once we (and primary care at large) knew more about some of the specifics and amend what we were planning to do.

A document tracking our assumptions — as we learned more we either ticked them off, marked them as incorrect, or deferred them until we had more info.

6. We became comfortable with ‘regret work’

A vaccination programme of this scale hadn’t been carried out before, so we had to enter into building the product aware and comfortable with the fact that we would have to iterate on what we released. In practice, this sometimes meant iterating within days after setting features live, due to the real-time feedback we were getting from our wonderful, engaged users.

We also had to be OK with the fact that some parts of the product may well have to be changed or scrapped depending on the ever changing nature of the vaccination programme and how little time we had to research beforehand. It wasn’t easy, but going in with this mentality made it easier to make these decisions as they came up.

And we did it! In just under 4 weeks, we went from ‘go’ to getting something live to help practices get their patients booked in a lot quicker than using pen and paper.

None of the above would have mattered if it wasn’t for how hard the team were willing to work. Everyone put in late nights and gave up their weekends because they cared so much about delivering something that would make a difference to the pandemic and the healthcare of millions. It was a really challenging time for everyone involved, and we’re still feeling the after-effects as a company of that ‘go’ decision.

However, I think I speak for the whole team when I say that we’re all incredibly proud of what we achieved, and humbled at how we were able to help out our users when they needed it the most.

To date, over 21 million vaccines have been booked in and managed through accuBook, which is over ⅓ of all vaccines in England. Over 5,000 GP practices have used accuBook and the busiest days have seen 300,000 bookings. We’re proud that even amongst the over 80s cohort, an average of 70% booked their vaccine appointments through our mobile invites.

While we wouldn’t usually work at such pace, and we’re always thinking about how we can produce our best work to help our users and their patients without burning out our own teams, we certainly learnt an awful lot throughout this experience!

A couple of examples of our lovely users’ experiences with accuBook — we wouldn’t be here without their ongoing feedback and support:

--

--