Support Analysts, we fix stuff!
It’s surprising how difficult most of us find it to define what being a “Support Analyst” really means. The go-to phrase of “they fix… stuff?” (with an ominous pause and an uplift in tone turning it into a question at the last minute) sometimes makes me feel like I must be doing some mysterious work for an unspeakable organisation. Perhaps it’s because this internal support function can have so many faces in different organisations, can be specialised or generalised in so many ways, that it’s difficult to know where to begin.
Imagine then the difficulty in explaining to your colleagues (or a potential new recruit) exactly how a team of four Support Analysts help to keep the business running day to day. To say “we fix stuff” isn’t an inaccurate definition by any means, but it is incomplete. Behold, the many hats of a Support Analyst…
Often, you’re equal parts detective and translator…
In Rightmove, the Support Analysts are the team you go to when anything goes wrong with our customer/consumer-facing features or any of our internal applications. We support other “Rightmovers” in doing their day to day jobs, from troubleshooting consumer issues to selling products to our customers, to creating our customer invoices, to supporting new feature releases… the list goes on.
Being a Support Analyst often means taking a very small amount of information about a process or feature you know even less about and figuring out how it’s supposed to work when it’s not broken. It means working hard to maintain a rough idea about how the whole company and every team within it fits together, so you can follow a thread through different teams and database tables to home in on the cause of the problem.
It also means translating between those groups of people internally who speak our customer’s language compared to those who speak our website’s language. We exist in both worlds at once and make it our mission to bridge the gap between them wherever possible, whether that be emphasising the customer impact to a product team or breaking down the impact of product priority calls to a customer team.
That only becomes more important when things go really wrong.
…then, you’re crisis management
Imagine that several of your internal applications have gone down inexplicably. You can’t process new orders, your billing process has stopped and half of your customer-facing teams can’t access the information they need to help people. Just as you’re getting your head around this first unfortunate set of events, a worrying number of phone calls are now joining the queue to speak to your customer-facing teams about a broken login page (you remember, the teams who currently can’t access any useful information).
Colloquially, this is what we would describe as an “everything’s on fire” kind of day.
In situations this extreme, a cross-team incident group do the actual fixing. For Support Analysts, the focus shifts to logistics and communication. We filter the deluge of information from everyone impacted by the incident to leave just the detail that’s going to help our engineers fix it (and then make sure they get it). At the same time, we also make sure everyone who needs an update gets one. Remember all that work we talked about around understanding how the whole business slots together? That tells us who’s likely to have been impacted by all this (and who will be, if it’s not fixed soon). It also tells us who is going to need what level of information to keep their team functioning.
All the while, regular priority requests and support issues keep coming and no one is getting any more patient. All of the niceties you usually enjoy in your relationships with your colleagues vanish in a haze of emotive customer complaints, incident-busting Zoom calls and the word “URGENT” in angry, red, bold font.
Always, you’re a human being
The thing is, it’s horrible when systems break. When you’re having the worst day and feeling like you’re letting your customers or your team down because that one infuriating error message just won’t quit and let you do your job, is it any surprise that our interactions get panicked? Too often Operational and Technical Support teams get caught up in that panic and it ripples out, to colleagues and to customers, making the whole day a challenging experience that everyone clamours to purge from their memories.
If you can ooze patience and understanding, remind people that behind the Helpdesk there are human beings who understand what they’re going through, it’s surprising what a difference that can make. Spending the time on quiet days to build trust and respect between your Support teams and the rest of the business can turn that really challenging day into a huge learning opportunity.
To return to our “everything’s on fire” metaphor, a firefighter’s most obvious job is fighting fires, but if they’re doing their job well then an equal effort will go into preventing those fires from igniting in the first place.
That means first and foremost, you need to be an activist
If you find that your biggest celebrations are around the disasters you collectively react to then stop and immediately re-think your perspective. The best support teams are proactive. This is where the “Analyst” comes into our job title. It’s about getting to know teams and how they function better, as well as acting as a consultant to the business to share that big-picture perspective. It’s about not just fixing the issue but working out why it’s happened in the first place and making sure that the engineers who build new features or the teams who help our customers function know what those root causes are. It’s about being persistent and driven in all of that, so that it doesn’t take a challenging “everything’s on fire” kind of day to make meaningful changes to how you work as a business.
In driving this mindset forwards over the last year we started with a support portal called the Helpdesk that not only lets people raise and manage their own tickets but also supports automation. That means we can do things without needing human intervention, like letting people know when we’ll be getting back to them with an update so they can trust that we’re going to help them.
We’re also using the technology behind the Helpdesk to record the root cause of every support ticket raised with us. It’s showing us patterns like the long-term bugs that have been worked around for so long that the work-around has become the norm, as well as the website features where our customer-facing teams aren’t as confident in advising our customers. The plan is to share that information on a regular basis with our product teams and make sure they understand the impact that fixing those root-cause-problems would have for the rest of the business.
Most importantly, we’re not treating any of these things as a box-ticking exercise. We talk about it regularly with each other and with other teams. We ask for challenges and feedback and then we tell those people confident enough to share with us exactly what we’re going to do to be better. In return they trust that when everything’s going wrong for them, they can rely on us to really listen to why it matters. That is perhaps the best way to stop yourself sliding into a reactive mindset and the easiest step to start with.
Building bridges with a cup of tea ☕️ 🍪
If you find that it’s difficult to get people to share that feedback with you (or are struggling with keeping it constructive and building trust) then why not try a small ‘grab a cuppa’ group of the team plus three or four others from different teams. Put everyone in a comfortable space and avoid Powerpoint slides. Just chat and get to know each other to start with and the rest will come. If all else fails, you’d be surprised how effective an excellent selection of biscuits is in getting people to open up!
