Autoprotect Group uses Fullview’s cobrowsing and session replays to record user sessions, share them company-wide so everyone is on the same page about CX, and resolve tickets quickly and efficiently.
Industry:
Auto Insurance, SaaS
Company size:
Mid-Market
use case:
Customer Support, Troubleshooting
integrated support workflows
troubleshooting
support agents and developers
Autoprotect Group's technical support team were already looking for a better way to understand and replicate user issues when their Platform Support Manager, Lee Oldham, found Fullview.
“We needed a GDPR-compliant way to understand user issues; Fullview’s session recordings feature was an immediate draw.”
Autoprotect Group is primarily in the auto insurance industry and is one of the UK’s largest providers of insurance products and dealer warranties to vehicle retailers and manufacturers throughout the UK, in Europe, and globally. They also have other functions, like a finance arm and their own auto technicians.
The team Lee manages at Autoprotect functions as a second-level support team. We sat down with Lee recently to discuss how Fullview has helped Autoprotect enhance and optimize its customer support workflows.
In our legacy systems, we could log in as a user and replicate an issue. Our new system doesn’t allow us to do that. We purposely built it so we cannot access a system as a user because of compliance reasons. So we had to go out there and find a solution that would still allow us to see and understand user issues but in a compliant way.
We looked at a few different programs and Fullview immediately caught our attention because of your user session recording feature.
With our legacy systems, although it was easy to understand and replicate user issues, customer impersonation comes with its own GDPR and compliance issues and we built our new system without that capability for precisely that reason.
But our new system lacked an easy way to see and understand user issues. When someone writes in with a support request saying something didn’t work for them, it’s can be difficult to figure out exactly what that was because it’s already not worked — the event has already come and gone.
So to be able to record those issues means we can see exactly what our user saw when the issue happened.
Fullview grabbed a lot of attention very quickly in our organization. Specifically because we don’t have to try and replicate issues anymore. We can just find the relevant replay recording. It’s been a complete game-changer for us.
In the interim between switching to our new system [without customer impersonation] and implementing Fullview, we didn’t really have much of a scalable process for seeing and replicating issues.
We used to actually have support agents on-site with our customers to see these issues in person because there were so few active customers using our new system [web application] since it had just been released.
Apart from that, we would typically ask customers: “Can you send me a screenshot? What have you seen?”
Once the initial release of the new platform had happened, it quickly became our process to have something like Fullview to see and understand user issues, which is why we started looking for a solution immediately.
We’ve now built our support processes around what your system offers.
Even when we could impersonate users, we often found that replicating bugs was still difficult because the situations and scenarios were different. Different internet speeds, different PCs, different browsers…it makes it difficult to replicate bugs because, since our solution is web-based, whatever bug the user is experiencing may not occur under different circumstances. So things could be working fine at our end and broken at the customer’s end. Issues like that used to slow down the initial diagnostics.
Now, obviously, with Fullview, you have access to all that information — what OS a user is using, what browser they are on — without even asking them, which speeds everything up.
Now, when a user writes us an email saying something didn’t work and when it occurred, we can immediately pull up that session and just watch what happened. The higher-ups were like “This is brilliant!”.
And once you’ve diagnosed the problem by watching the replay, an agent can then jump on a cobrowsing call with the user, take control of their screen, and solve the problem collaboratively.
Historically, our second-line team would be notified about an issue from our first-line team and ask themselves “Does what they’re saying make sense? Because we can’t go back to the customer again and retrace the issue.” If it seemed like it made sense, the second-line team would pass it on to the technical team, even if the information was inadequate or bad. Now, with Fullview, our second-line team can spend 10 or 15 minutes looking at the replay, pausing it, taking notes, and documenting. So it allows us to do more checks and for our first-line team to pass it on more quickly so we [the second-line team] can spend more time on it.
So ultimately, yes, it has improved the process. Because we’re not just passing a note on now. We’re actually spending more time on it now to really understand the issue before it gets passed on to the technical team.
It’s because a user session recording can flow all the way through. What I mean by that is before a session recording is sent to our technical development team, it has potentially gone through two or three other people doing their own checks, their own diagnostics, etc. So this recording is helping them all along the way.
That means that everybody gets the exact same information all the time, rather than someone inferring or misunderstanding a comment from someone else. It’s consistent all the way through.
We don’t have any concrete data because we’ve only just started to track those metrics. So, currently, we’re really focusing on how our support agents and developers feel since switching to Fullview.
For support agents, being able to watch a session replay without the pressure of a customer on the phone asking “can you fix it?” is great. And on the development side, not being able to reproduce a bug is no longer a blocker, because we’ve got video evidence that it did happen.
So it just makes things flow better throughout the whole process.
We still have occasions when someone sends a screenshot in and that causes a little bit of friction, but with Fullview, just being able to share a link of the user session screen recording — there’s no argument in that process. It just flows, which is why I think it’s good that we’ve embedded Fullview into our process.
We don’t get much use out of the console logs yet simply because the platform is so new and there are still some empty field names and stuff of that nature. However, in the future, since the platform is events-driven, we could potentially fire an error into the console logs and then your system can capture it. So I don’t see why it wouldn’t help us in the near future.
For me, the user session recordings are definitely a game-changer in this industry. And the fact that you have historical logs and can watch sessions up to a couple of weeks old is immensely helpful. Your new UI [with filtering, tagging, segmentation, and custom views] is brilliant.
And another good thing is just how quick and responsive your support team is. When you do spot an issue, you generally are very quick to inform us about it and get to work fixing it. Since Fullview is now a key part of our support function, we obviously can’t wait weeks for someone to fix an issue, and, with Fullview, we don’t have to. There have been times you’ve informed us that you’ve fixed an issue we hadn’t even noticed!
Your support team helping our support team is immensely appreciated. It’s the one thing I rave about personally.
Discover customer and product issues with instant replays, in-app cobrowsing, and console logs.