Reimagining our Support Tool from the ground up

Reimagining our Support Tool from the ground up

At Echo, we build most of our tools in-house. Here is a tour of the tool we’ve built for our Patient Care (PC) team to respond to patient inquiries; known as the Support Tool.

The problem

Prior to the Support Tool, we had a primitive tool that performed basic CRUD operations. It did not accommodate our PC team well. It meant that they had to alternate between multiple tabs and tools to satisfy a patient query. It also required that advisors knew in detail how Echo works internally, which is quite different from how patients experience Echo. We were fast approaching a bottleneck in our operation and needed a reimagined tool for the size that we had grown into.

Brainstorming a solution

We wanted to design a tool where the PC advisors could spend most of their time without switching between tools. We ran idea generation workshops where several representatives from the PC team brought ideas of how best to help our patients. We had pharmacists, phone and chat advisors, and team leads. Our goal was to build something that was a joy to use. Being an online pharmacy, we neither operate like a local pharmacy nor like an e-commerce company. We have unique customer service concerns that made designing a support tool challenging. A delay in receiving the medicine you need is not the same as a delayed pizza delivery.

How patients get in touch

There are two ways that patients can get in touch with Echo:

  • Asynchronous messaging via the web or mobile application – using Intercom
  • Phone calls – using Aircall

In the early days of Echo, Intercom was our primary mode of communication with patients. But as we grew, more of our patients were of an older demographic, many of whom prefer to get in touch via phone. This created a new challenge for the tool to authenticate the callers as securely and quickly as possible.

The tool’s core objectives

The tool had to satisfy two key requirements:

  • Secure and quick authentication
  • Query-resolution in as few clicks as possible to make the experience pleasant for both the patient and the PC team

The solution

The model we came up with is as follows:

  • start every patient query with a conversation, originating from a phone call or Intercom conversation
  • authenticate the user
  • show a snapshot of the patient’s account
  • perform tasks on the account via “workflows” to resolve their queries

Getting in touch via text

When we receive an Intercom message, the advisor can click through to the Support Tool from within the intercom message. (The yellow bubble in the image is only visible to the advisor).

Getting in touch over the phone

Unlike with Intercom where we immediately know which patient is getting in touch because the user is logged in, on phone calls we need to verify that the caller is who they say they are. We have two authentication methods depending on how the call is originated:

  • authenticated via a “Challenge Flow”
  • authenticated via the app

Authenticated via the "Challenge Flow"

Here, the caller has got in touch by dialling the phone number directly into their phone. Therefore, we have no way of knowing who they are. They may not even be an existing patient. We receive calls from GPs, local pharmacies and individuals inquiring about the service.

We have a separate challenge flow for GPs and local pharmacists who call about their patient who is registered at Echo.

In the case of an existing patient, we ask a set of questions that allow us to authenticate them securely and quickly. If all responses are valid, we "unlock" the account. This protects us from social engineering since the advisor doesn’t have any information to accidentally spill.

Prior to this, all the burden of the authentication would fall on the PC advisor — this was far from ideal. Now, there is much more consistency between advisors and there are significant efficiency gains.

Authenticated via the apps

Another method to authenticate a caller is when the patient gets in touch via the apps (mobile and web) instead of dialling the phone number directly. Using this method, we’re able to skip the challenge flow described above and immediately identify the user since they are logged into the app. This creates an additional time-saving (almost a one minute reduction in call time) and is a pleasant experience for both the patient and the advisor.

The process is as follows:

  1. The user taps on the "Call Echo" button
  2. We generate a short-lived six-digit token and store it against the patient’s account ID in our database
  3. The caller’s phone app is then populated with our customer service number followed by the 6 digit token (the token acts like an extension number)
  4. We receive a webhook along with that token
  5. If the token is valid, we fetch the account ID and redirect to the caller’s account page in the Support Tool

The left-hand side panel

Besides the authentication aspect of the tool, there are a couple of helpful features to note. One of these is the left-hand side panel.

The left-hand side panel shows the agent any conversations they are assigned to. For example, as soon as they answer a phone call on Aircall, the call immediately shows up in their side panel. We do this by streaming the conversations as they come in. They are then taken to the Challenge Flow or are immediately taken to the account page, depending on how they get in touch (as explained above).


Workflows are the backbone of the Support Tool. Once the caller has been identified, the advisor will use workflows to resolve queries. They allow us to retrieve information and/or make changes to the patient’s account. There are myriad actions we may want to perform on an account. As such, we need a logical way to add these actions over time, and by different engineering teams. Workflows present a pattern that lets us achieve this goal without ending up with a bloated tool over time. Each workflow is standalone and does not need to take into account the other workflows. This makes it straightforward for any engineering team to jump in and create a new one.

At the moment we have just over 30 workflows, but this model could easily scale over time without the tool becoming bloated.

We use the keyboard shortcut CMD-K to search for workflows.

Here’s an example of a workflow:

In every workflow we provide a script for the agent to use which they can easily copy. Previously these sorts of scripts were stored in intercom as macros, which made them harder to find and less standardised. Building the script into the tool allows us to ensure consistency across different agents using it.

At the end of a workflow, when the button has been pressed, we also store that a workflow has been done on the patient’s account and add a note of this to their intercom conversation for future agents. This helps our patient care agents follow what has happened to the account and collaborate to support each other.

High-level stats

Another feature is our top-level stats that give the advisor a quick snapshot into the account’s history.

From here we could link to our other services, such as our Issues service. If there is an active issue open, it means that a ticket has been created to escalate the query to a pharmacist, an engineer or another team.

Closing thoughts

It’s been almost a year since the rollout of the Support Tool. The tool has scaled well with the PC care growing 4x in size; they currently serve over 400,000 patients. The workflow model has enabled us to support PC advisors as the different areas of the business change and new features are introduced.

The rapid phone authentication has made calls a smooth and secure process, saving our advisors more time per call.

Of course, we still have a way to go to improve PC tooling further. For example, one thing we want to support is managing telephone appointments with our pharmacists, which enables our patients to ask clinical questions without needing to visit their GP or local pharmacy.

Since the rollout, we’ve found the approach of having workflows which are self-contained, to be really helpful. As for any features we’ve added to the patient experience, we have been able to easily add support for our patient care agents without having to reorganise the code or make the tool bloated.

Any questions or feedback? Want to hear about new posts?
Follow us on @BuildingLloydsD
© 2024 Metabolic Healthcare