When Jens joined Sqills a little more than a year ago, he wore many different hats at his previous employer. Today his job consists of working with the continuously growing list of operators that use S3 Passenger. We caught up with Jens to discuss his experience as a customer support engineer.
What is your role at Sqills?
My role is making the customer happy, to make sure that I address their issues as best and as quickly as possible. I am here to solve their problems.
Some people might assume product support is like working at a help desk, but more technical. Would you agree with that description?
No, I would say that it’s actually the complete opposite! People might assume that you are constantly on the phone, forwarding calls or reading from a script. That is nothing like the reality. I think that product support is the place to be if you want to learn as much as possible in as little time as possible. If you want to know a lot about the entire scope of S3, support is the place to be. You deal with absolutely everything.
This is true on all fronts, from generic functionalities to customer specific implementations. When you describe your job, people will ask if you wear a headset, take calls. Honestly, you cannot compare it to a help desk position. You must be willing to learn every day and be willing to accept that you won’t know the answer to every question.
Does everyone at product support have their own specialisation?
That develops naturally along the way. We have functional support team members and technical support team members. We are the first point of contact if something goes wrong or if our users have a question. I started out working with one of our smaller operators and new opportunities just kept coming. I was relatively new to the support team when the partnership with Eurostarwas formed, so I had the opportunity to jump in early and learn loads about the context of this customer.
Do you feel that you are done learning?
No, quite the opposite. Where I was an all-rounder in my previous job, I’m now fully focused on analysis. Over the past year, I have been challenged constantly on the contents and context of S3 on the. There really is something new every day, today is no exception. Earlier, I was looking at the new ‘social distancing’ feature in the context of Eurostar, and they have a different approach than other operators. A colleague and I were both staring at the screen for a while to figure out how social distancing works for them.
Is the challenge because S3 Passenger is a complex product or because of the range of operators?
It is a combination of both. The product itself may appear straightforward until you look at the details, at that point it can become very complex. Every development team at Sqills has their own specialisation, I think that highlights just how complex the product is.
What makes the job entertaining is that you are in direct contact with the customer, you are ultimately there for them. It’s awesome to see an operator generate a lot of revenue in a day, we actively contribute to their success.
You’re also in touch with almost every colleague at Sqills. If you need help with front ends you talk to Dev-Z, if you need help with the Journey Search you talk to LOPD, it gives you a chance to connect with everyone. We try to get our information from everywhere in the organisation.
S3 Passenger constantly has new updates and eight major releases per year. How do you handle staying up to date?
We watch all the demos from the different development teams. You aren’t required to attend or watch, but it helps a lot. Even if the information doesn’t seem relevant right away, have a look and learn. Who knows what you might need it for later. Sometimes you work on a question from an operator who is using an ‘early release’ and you just had a demo about that specific feature. That makes you go “oh yeah, so that’s how that works.” We also have information sessions for each major release and get a preview of what is to come.
How do you communicate with the operators?
Everything is digital, I’ve never once answered a phone. I really like that we do as much as possible through tickets. You have a single place to look – Jira – and that’s the gospel. If I am out sick tomorrow, you’ll be able to look at Jira and take over my tickets. That is our goal, to ensure that we document everything in such a way that the organisation keeps going. Of course, there’s regular meetings with customers, but we do our utmost to make sure that everything is documented properly from these calls as well.
This works much better than hearing “oh yeah I’ve spoken to him/her on the phone” or having a question in my personal inbox. I also don’t send many emails. In the year that I’ve been here I may have sent 10 to 15 emails, either being related to something like HR or Sqills events.
What other colleagues do you have the most contact with?
We often talk with product owners. When a problem comes up, we need to ask the appropriate development team for a solution. However, in some cases it is good to discuss problems with someone who knows the original idea behind a feature. In that case, it pays off to talk to the product owner of that team.
What do you like most about your job?
I honestly don’t know what I am going to do tomorrow. You are constantly being challenged and dealing with new situations, even if things may be a bit hectic at times.
And what is your least favourite thing about the job?
Personally, I am not a fan of documentation, but I understand it is necessary. Product support can stay up to date through demos, but operators need to be able to read about these new features. And it would make all of our jobs easier if we had ‘standard’ answers for any question a customer may have.
Right now we are able to refer operators directly to existing documentation in about 15 to 20 percent of all questions, without having to assist any further. Our documentation is excellent, what it says, the way it is documented, language use, quality, and version management.
Is the team still working on improving that?
Absolutely, there is a documentation team within support. This team meets every week to determine how they can make our documentation even better.
What skills are needed for a good customer support engineer at Sqills?
It needs to be someone who wants to help, someone stubborn. If you aren’t stubborn you may have a developer who says “that’s not true” or “that’s not possible” …but it is and you have proof. Someone who isn’t afraid of a discussion and someone who works accurately – because you are in direct communication with the customer. You represent Sqills.
Something else that will benefit you is a willingness to learn. At Sqills I got the chance to start fresh. Take an API for example, I knew what an API was – that it made it possible to send messages back and forth – but what it ultimately does and how it works, you really learn quickly on the job.