How Manchester’s Metrolink Can Be Better
An earlier version of this article mischaracterised the structure of the Metrolink control team, which has been addressed based on feedback.
Manchester’s light rail system, Metrolink, has had a bad run of late. The past 2 weeks has seen at least 3 major failures at rush hours: overhead line issues, signalling failures as well as succumbing to the chilly weather the UK’s currently experiencing.
Metrolink is undoubtedly a complex network, with many different routes on a shared infrastructure (unlike, for example, London Underground, where there is mostly, but not exclusively, segregation of physical tracks between the lines). It’s far from my area of expertise to suggest improvements to the infrastructure of a rail network, but one thing I do feel comfortable suggesting improvements to is how customer communications are handled during a crisis.
Warning. There are assumptions ahead (mainly based on my understanding of hanging out in tram spotter forums…)
As I understand it, there is a dedicated customer service team sat next to the Metrolink control room. That team is expected to respond to phone calls, the on-stop call points, Twitter, e-mail, keep the website updated, and more. I believe control of the displays at the tram stops (PIDs — passenger information displays), as well as any spoken announcements, does not lay with them, but instead with another member of staff in the control room (a network manager). The customer service team can see an overview of the network and sits next to the control room, where the controllers and managers who interact directly with the signalling systems and drivers, and develop recovery plans during a crisis, sit.
Now, let’s imagine the tools available to our customer service team. They probably have access to a CMS to update the Metrolink parts of the TfGM website, which involves adding text messages to a status display.
They use a social tool like Hootsuite or something to manage messages etc on Twitter, and have telephone on their desks. Some of this infrastructure is managed by KAM (the company who run Metrolink), and others by TfGM (the public sector body responsible for all transport in Greater Manchester). For the day-to-day this disparate set of tools works fine, and the workload probably manageable by the team. Now let’s imagine what happens in a crisis: a hypothetical points failure at Cornbrook (for those unfamiliar with the network, Cornbrook is a station that all but 1 Metrolink line runs through). By the time the control room has diagnosed that the points have failed, we might be already 10 minutes into the breakdown. There’s a queue of trams backed up across the viaduct because it took a period of simple diagnostics to identify it was something major, as opposed to something minor like a tram’s remote control for the points not working (the trams sit over a loop antenna in the track and send out a request for the points to change in the direction that is required).
The Metrolink managers decide to suspend the trams across the network. This is usually done so that when the fault is rectified, trams can continue at roughly the right level of spacing, as opposed to all getting into one big clump at the point where the blockage is. Now our unlucky person on the Twitter has to post the message that services are suspended. Perhaps there’s also a phone call coming in from someone who’s pressed the callpoint button, and the team also have to update the CMS, copying and pasting pre-prepared messages into the right boxes for the right lines. Sadly they can’t make a voice announcement or update any of the PIDs themselves, only network managers with access to the signalling system can do that, and they’re currently co-ordinating with the controllers who in radio contact with the drivers, co-ordinating a team of technicians to get on site, and maybe ringing Stagecoach and TfGM to co-ordinate ticket acceptance on regular bus services.
This is wrong.
Staff having the wrong tools to do their job is endemic across IT. Off-the-shelf solutions rarely integrate together well or expose appropriate abstractions, making smooth workflows hard and introducing multiple points of failure. Design thinking can make a huge impact here.
Now, let’s look at our hapless commuter’s point of view. They’re commuting from MediaCityUK to Sale, catching a MediaCityUK to Etihad Campus tram and then intending to change at Cornbrook for an Altrincham tram. Their driver has made an announcement saying that there’s a points issue and he’s been asked to stop at the next stop. The person has a smartphone and checks the tfgm.com website, seeing that buses 33 and 50 are accepting tickets. Our unlucky commuter doesn’t regularly get the bus, so has no idea where the 33 or 50 go from (and even more unluckily, the tram they’re on has stopped at Exchange Quay, which is far from the calling point of either of those buses). Even if they did manage to get on board one of those buses, they head into the city centre, not out to Sale where our passenger has to head up.
This is wrong.
And again this is wrong due to the commuter having the wrong tools. They get given just enough information to proceed, but it assumes a huge level of knowledge about the bus network, which you can find from other sources, but is that really the best thing for them to do right now?
How do we fix it? Well, we need to give people the tools they need. We need to give our customer service team the ability to present a consistent message across all channels, no longer splitting the ability to update the website and the PIDs and with different tools depending on exactly where in an organisational structure the responsibility lies. Perhaps they could be given a single “crisis management” tool that can update multiple channels at once with accurate information as the crisis involves. Perhaps this tool could even take a feed of information from the signalling system to update in real time when things start to recover but there may be long gaps between services due to the bunching up that happened earlier.
Maybe this tool could be a map of the Metrolink network that a user could click on to mark a particular series of stops as suspended or a point on the network that is causing delays. This would trigger appropriate messages and updates. Our unlucky customer service agent currently tweets out things like this:
Now, which stations on the Eccles line aren’t served? Is it ones going away from the city (so, between MediaCityUK and Eccles), or is it the ones between MediaCityUK and the city? It’s actually the latter, and it’s more confusing as the Eccles and Ashton lines actually run together as one service. Clear communication triggered by a single tool that holds the current state of the network and is updated as the situation unfolds could massively simplify things. Perhaps also linked to PIDs and speech synthesis providing phone messages and tram stop announcements too!
I’m really not a UX designer, but maybe a pop-up selecting a type of failure and then setting alternative patterns for different lines (perhaps the Altrincham-Bury can run as far as Bury-Deansgate, etc) would be the single point of how things feed in. And as mentioned above, it could show where individual trams are too?
Now how do we satisfy our commuter who now needs to switch to a bus? Maybe right now they use a tool like Google Maps to figure out what routes to take, but they need to cross-correlate with the announced alternative routes on Twitter. How about if during a disruption, a mini-journey planner came available on the website, where you selected the stop you’re at and where your desired destination is. Based on the knowledge of which routes are running, and which alternative bus services accept a tram ticket, then our traveller can now get a plan that works for them. In the event of a full-network shutdown, this could be a bus route, but for partial closures, this could be clever enough to route them to another Metrolink stop where they can complete their journey on an unaffected bit of the network. At the very least, providing maps for every tram stop showing where the nearby bus stops are, which services call at them and which directions those services go would be invaluable. An unlucky TV exec visiting MediaCityUK for the day might end up being told to get a number 50 bus to try and get their train back to London, not realising that the number 50 doesn’t stop in the city anywhere near Piccadilly. These simple bits of info ready to go providing more info about the bus alternatives than just numbers will really help, but a better travel planner would be the icing on the cake.
So how about it TfGM and KAM? Can you get better tools to your customer service staff so they can be more effective during a crisis? Can you be better prepared for when bus replacements are needed, especially for commuters who rarely use them, or visitors who are only using Metrolink?
