Like most entrepreneurs, when I started my Shopify app I did everything. Even though I'd been an engineer I filled every role. Juggling these roles was fine when the company was small. I could give the right amount of time to product development, marketing, support, maintenance and admin.

As the company grew it got to the point where support was taking most of my time. Even though the app continued to grow, it felt like I was neglecting the product and marketing. I knew something needed to change so I could regain balanced focus.

Looking at what I was doing day-to-day it seemed that support was the piece that could most easily be hired into. But the app was barely ramen profitable, so being able to hire in budget didn't seem likely, until I came across an agency whose angle is hiring 'virtual staff' from The Philippines.

In The Philippines there’s good English, education, Internet, work ethic, and an established work-from-home culture. Costs are a quarter of hiring where I am. They have a big book of people with general administration skills who can be hired part time or full time. The skills they outlined and the costs looked attractive. I was still very skeptical that I could hire quality support with the knowledge we needed, but intrigued.

It starts before hiring

Let’s rewind a bit, since hiring someone into the company and expecting them to support a pretty technical app would be setting them up for failure. My preparation started a lot earlier.

An ex-boss loved to say ‘we don’t do manual’. Any manual task that’s repeated regularly and is economic to do so would be automated. His team was one of the leanest and most profitable in the Fortune 500 company I worked for. We got really good at having a sense of if something should be automated or not, and how to do it. We were masters of ad hoc SQL scripts, powershell, templates, batch jobs and email filters.

I’d kept the same in mind when doing support for my app. I'd been building up many email templates and scripts so that I could often just read the email, hit a button to generate a response, customise it a little, and then push send.

I'd been creating tutorial videos and a lot of help docs. Most users didn’t bother with them, but they’d provide great training to our new team.

Using helpdesk software for a team of one felt like a bit of overkill at times, but it both helped me to separate out support from the other parts of my work and to start to think about which features we’d need as I moved into managing support.

All of this would mean that the learning curve for a new support hire would be manageable. Even so, I realised that I wouldn’t be able to hire someone to do 100% of the support I provided. Just having them filter and deal with the most common tasks itself would free up lots of my time. Focussing down the job spec onto the essentials would increase my chances of finding a good fit.

The job spec

With my first support hire I wasn’t trying to pull myself 100% out of support. That’d require finding someone with strong Shopify, Liquid, HTML, JS and CSS skill and being good at customer service. The ‘being good at customer service’ is what the spec focussed on, leaving training up on the technical stuff being a nice career development carrot.

As I had detailed processes and documentation to follow, what the hire needed to be was someone who can follow directions closely, know when to deviate from them if necessary, and when to reach out for help. This I test them out on before hiring.

Their written communication needed to be clear, with a solid grasp of English. Customer service isn’t for everyone (staying professional in the face of an angry, irrational customer isn’t easy!), so they needed to have done a customer-facing role before and have come across situations where customers weren’t happy.

Other than this, their attitude is the main thing I’m looking for. Ready to learn, self-motivated and friendly.

Hiring process

The agency had a pool of screened and processed candidates. They do a good job of managing expectations: there’s no way you can hire someone with deep technical skill through them for example. You specify what you’re looking for and they get to work.

After a week or so they gave me the three candidates they felt were the fit best. Each candidate had a CV, audio presentation, personality test, references, and a standard questionnaire. This helped to highlight anyone I felt wouldn’t be a good fit. I could veto any and get a new three.

The next part was a video call. It’s a pretty typical interview, focussing on who they are, their experience and personality, and what the role entails. I took all three onto a test.

It would've been unreasonable for candidates to learn lots about our app and to use new tools like our helpdesk software to respond to real queries. Instead, I shrunk everything down in scale.

I gave them just five response templates to choose from, covering very basic queries. Then I described scenarios in a doc, and they’d choose the relevant response template to use. I was looking for the ability to follow simple directions. They were also invited to customise the responses to make them more personal to the ticket: if the customer mentioned they’d been struggling for sales, the best candidates would use an empathetic tone.

One question didn't have an appropriate response template to choose. This checked that they would not send wrong or poor quality responses, instead favouring to ask me. They could, if they wanted, come up with some ideas for a response but if they were at all unsure they were directed to ask me. Some people view not being able to do a task that's been given to them without help, and having to ask the boss as a weakness- a dangerous trait that’s difficult to shake. Successful candidates know their limitations.

Another task was to do basic research into a feature of our app using the help articles available and draft a response for checking. Even though many customers don’t bother to read the docs, our help team should!

Then as a stretch question we asked about styling something with CSS. They could use anyone they new and online resources to work it out.

They were asked to complete the test in 45 minutes. This gave them the need to prioritise, to balance the test in the right way. It wasn’t tracked or enforced but it was good to see how candidates themselves managed their own time.

I was really pleased that in the first batch of three candidates I found my first support hire. She was one of my best hires that stayed with us for years.

Onboarding

My expectation with onboarding was that I’d be still spending most of my time on support for at least the first three months. This was a long-term investment in a new team member that’d start paying itself off 6+ months from now. There's no way you can expect your first support hire to be net positive in the short term. In fact, you're going to have to work even harder as support and training take up even more of your time. That proved to be true for me.

I divided the types of tickets into three sets: a) those she could answer herself, b) those she wasn’t sure of and needed input, and c) those she couldn’t be expected to answer without stronger technical skill.

I set up the helpdesk just like a typical tiered support. She'd pick up every new ticket that comes in. If she couldn't handle something or had doubts (the (b) tickets above), she'd assign it to me with a private note describing what she thinks. Rather than me resolve the ticket directly with the customer myself, so she could learn, I’d add a private note with the reply and she’d send it to the customer. This would become a new response template she’d add to her notes. After dealing with the same ticket type a few times she started to answer them herself. It was rewarding for both of us to learn this way.

For the (c) type tickets I didn’t have any expectations on. They’d usually be around 10% of tickets, so it would have been workable if I had to keep working on them myself, or at some point hire a developer hire to take them. On this, she exceeded expectations and started learning more technical skills.

Keen to support her on this, I added features to our app and made little command line tools so that she could slowly start to learn the coding skills needed to support customers. It was key that I had hired someone who was aware of their limits, not afraid to ask for help, ambitious to learn, and thorough in checking their work. This allowed me to give them freedom to explore and learn these areas without affecting our customers in a negative way.

For quality control I used our weekly one-on-one to randomly pick a few tickets from the helpdesk and read her responses. I coached her on tone, how I would’ve responded slightly differently, and flagged problem areas for more learning.

As the weeks went by she handled more and more tickets herself. I realised at one point that most days I wasn’t needed on support at all. She was a great hire, out of a hiring process that screened for the right qualities. I went on to hire two more colleagues the same way with similar success.

Empowerment

I was concerned that building out a team who needed to follow systems closely could make them feel like cogs in a machine. I wouldn't want to work like that and I didn't want to build a company like that. It was important to address this right from the first support hires so our foundation was good.

Our aim was that everyone on the team should feel ownership and empowerment to do their job, and get satisfaction from a job well done. They should be able to regulate themselves if they’re doing well or poorly without a manager watching over their shoulder. The manager should have confidence in them to work well without micromanaging.

One tool to empower support was the customer happiness surveys that were sent out automatically when tickets were resolved. This helped the team see what made customers most happy and what didn’t, tuning their responses and improving themselves without being told what to do.

Juggling what was often hundreds of open tickets is tough. The team shouldn’t have to think about or be told which ticket to respond to next. Our goal was that a customer should not have to wait more than one working day to get a response from us.

With some careful coding we showed the SLA for every ticket in our helpdesk, and all queues were ordered by this. A report came out every week where the team would look at how they did, zooming in on any missed SLAs to learn and improve. They owned their performance.

By setting up support and hiring like this I built a small team that all stayed with us and were one of the most valuable parts of being able to scale. Our first support hire was a cornerstone in the foundation that freed me up from support and let me go on to build the team and our products to a successful exit.