As a Support team, we aim for an ambitious average First Response Time (FRT) target of under 3 hours and a C-Sat happiness rating of 90% or above. Whilst these metrics are used to track how well we do as a Support team, we cover much more ground for our customers beyond just responding in a timely and friendly manner.
Marvel's Support team is made up of smart people with backgrounds and interests in diverse disciplines including graphic and product design, UX, illustration, QA, open data and programming.
In this post, I'll be talking about bug fixing, one of the ways we've been involved in development and how this positively impacts the support we provide to our customers.
Like many product engineering teams, ours work in fortnightly agile sprints. Sprints usually consist of feature building, but also bug fixing and infrastructure maintenance/improvement. A balance is needed between these areas to keep pushing the product forward in a way that is inline with Marvel's vision, our customer's expectations and to keep the product running soundly and bug free.
As with all software products, it's inevitable that our customers will occasionally find bugs. In order to keep with the equilibrium we described above, we prioritise our bugs with a simple matrix. Bugs are ranked accordingly and wait in line to be included in an active sprint. For highest priority bugs, customers can expect a fix within a single day, everything else within 2 weeks or longer.
Our bug turnaround is pretty high, which is cool! However, there will always be a few of those low priority bugs that keep getting pushed to the back of the line by higher impact bugs. Whilst, this is necessary to keep the product moving forward and running smoothly, if you are a customer that has reported one of these bugs, it can become a little frustrating.
One of the most satisfying ways I've been able to apply programming to Marvel Support is by fixing low hanging, low priority simple bugs. These bug fixes may not have a massive impact across the whole of Marvel's user base but can absolutely make the world of difference to the single customer who reported it.
For example, a recent ticket was opened by a customer who found that their Spotify embed code was being rejected in Marvel's editor. The feedback Marvel gave was that the HTML was incorrect. To explore further, I asked the customer to send me the HTML they were trying to embed. The code looked fine but threw the same error when I tried to use it within my own Marvel project.
I decided to check the subdomain āopen.spotify.com" in the HTML code against the subdomain Marvel was expecting. Alas, the issue was found. We were looking for a match on the subdomain āembed.spotify.comā. It appeared Spotify had updated this their end, and we as a product that supports HTML from Spotify, needed to update our codebase to match. So I did just that, and deployed the fix. I was able to let the customer know within the same day that the issue had been resolved for them. Another happy and returning Marvel customer!
This is but a single example of how the Marvel Support team are empowered to fix an issue before it reaches development - saving valuable engineering sprint time.
By trusting our team with access to Marvel's codebase, we mould the traditional perception of how we define āCustomer Supportā. Our priority is always our customers, but achieving good FRT and C-Sat statistics allows us the flexibility to extend our service and take support one step further.
You can read more about how you can bring your prototype to life using embeds here.
