Episode Description

In this episode Dimitri interviews Petros about setting up support for your operation.

Transcript

Dimitri [00.00.05]: Are you an entrepreneur, a designer, a developer, never before has it been easier to get your new venture off the ground. Whether you’re just getting started or have already begun your journey, you’ve come to the right place. In each episode we will dive into a new challenge breaking it down into simple, digestible terms. I’m Dimitri…

Petros [00.00.21]: …And I’m Petros.

Dimitri [00.00.23]: And you’re listening to Listen-Ship-Repeat, episode 10, “Setting up support for your operation”

(Music)

Dimitri [00.00.35]: As you’ve probably noticed Thanasis isn’t with us today, I’m here with Petros. We’ll be talking about setting up your support for your operation, today. We will probably get on with this, I mean getting people that we know or have worked with, that can contribute to topics better than us, speaking on the podcast, since they’re much more experienced. So, welcome Petros! It’s great to have you here. Would you like to tell us a bit about yourself?

Petros [00.01.17]: Yes, I’m Petros and I started many years ago as a programmer, but know somehow I’m a manager. I work at companies, I set up software teams before I have been working as a freelancer. Also six years ago I started at Github as the first technical support person internationally and now I’m the technical support manager for Europe and APAC for the past two years.

Dimitri [00.01.51]: Great! So, we’ll be talking about setting and building up your support for your operation here tonight. We’ve talked about several company sizes in the past like the tiny one, the co-founder with the developer, the more scaled with 50 plus people. So, I think it would be nice to focus on that mid tier, where your team has just started to scale and you might have a tiny team of developers. So, I would like to ask you, why do I have to have support for my operation at that point.

Petros [00.02.28]: Alright, so first of all it’s a practical thing. You need to somehow listen to your customer, you need to listen to the problems you product has to get feedback, but also to make your customers feel that there’s someone out there where they can reach out and feel that someone is listening to them. The other thing is practical because now you have grown a little bit and you know have more users, so it’s more of a pain for the co-founder or the first developer to spend time doing support, which is what a new startup usually does. They don’t have a separate support person that handles that stuff, they do support themselves, which makes sense. Now, with more people and more users it makes sense to find your first or couple support people.

Dimitri [00.03.31]: That’s interesting! So, in addition to addressing your support issues and difficulties that people might have with your product , it’s also building a relationship with your customers, right?

Petros [00.03.41]: Exactly, this is a big thing at Github. We don’t want just a team that handles support requests, we want to build relationships and we want to be know as a company that values its users and customers, but also support as a general idea.

Dimitri [00.04.05]: So, I might be the non tech founder or one of the developers and the team has grown a bit and we’re getting enough user feedback, for us to justify having that person or team in operation, cause for it might be simply too time consuming. So, my question for you is, what would you tell our listeners out there, how they would go with setting up the team, hiring the first person.

Petros [00.04.37]: So, I wish it would be easy, but from my experience it’s not that easy. Hiring, especially for technical support, where I specialise is rather difficult and the reason is, we usually like people that have the technical background to do that job, are usually invested in other areas. They have been developers and they want to change their career or they want to enter a company in an easier way, so let’s say support is a way to do that and it’s very difficult to find someone that combines both good technical knowledge and background and also have the empathy and writing good english, which is the language used for support, so the combination is very difficult to find. But other than that, they way you can go about it is, of course by having a good job description, posted at various websites like, LinkedIn (we are using LinkedIn lot) and maybe reach out in conferences, which for support we don’t have that many, but I can offer a suggestion to attend “SUPCONF”, which is support focused and is pretty good.

Dimitri [00.06.16]: Do you have any other in mind? If you don’t we can add them to the show notes later so people can check them out.

Petros [00.06.20]: You mean like, links, conferences? Unfortunately for support there are not too many out there. We usually go to writers’ conferences or developers’ conferences, so try to do that.

Dimitri [00.06.35]: Alright. So I simply mean that clear communication skills and understanding are key for this kind of position.

Petros [00.06.45]: Exactly!

Dimitri [00.06.50]: Know, what kind of channels are there, in order to be able to communicate with my users and customers?

Petros [00.06.55]: For startups, the most popular is email based support and depending on your size and traffic you can just have an email address and use that, you can give that out to people to send you the support requests there. But you may want to use a specific tool that is maybe based on email but gives you a bunch of other things like, integrations to your product and date about the users and stuff like that and there are many new out there popping up every month. We can give links probably for this episode, but I want to mention ZenDesk as a third party tool that we have experience with. I also want to mention that we usually like to build our own tools, in house. We did that for a while and I was personally of the opinion that if you want to provide the best support out there you need to build your own tool. However, that has its risks, because you also need the internal team to actually maintain it and extend it.

Dimitri [00.08.30]: So, we’ll talk about that soon, meanwhile I’d like to ask you for these channels, should I be present to each and every one of them when I start my operation?

Petros [00.08.47]: So, like I said you have email, but you can have presence on Twitter, on social media and the question is, “Should I be everywhere?”. My experience not only shows that you don’t have to be everywhere, you cannot do a great job. So, my advise is to focus on one thing and do it well, like an advertisement, you have your support page and you say that your official support channel is email, right? You can of course use Twitter, if you have a Twitter account and give a reply here and there, but you cannot offer support there, like the same quality of support you can give using email. As for the phone support, forget it, for starters. It’s that it’s a different kind of support, it needs different skills, with email you can handle almost every request, but with the phone call it’s real time handling of a support request. Whereas with email it’s a sync, you can actually take your time, ask your product or developer team for input and then prepare your reply, go back and forth, email is very good across time zones, because you may want to handle that. So, a thread may live several days so you will have to go back and forth for several days.

Dimitri [00.10.45]: You mentioned Twitter, I’ve actually seen some stuff here and there like, people sending a mention to somebody they have an issue with and the reply that comes back is “Please DM us” so we can take this private. Have you had public support like that, because I have seen it, even on Facebook pages I have seen it. It’s always like, “oh, I have this problem..” and the answer is “send us a message” or “send an email here and we’ll look into it right away”.

Petros [00.11.20]: There are two problems with public support. The first problem is that sometimes you reveal private information and you don’t want to do that and the other thing is, what kind of support you can provide on these mediums. For example on Twitter you have the character limitation, so it’s very difficult to go back and forth using that limit.

Dimitri [00.11.51]: Maybe you can tell them, these are enough characters in order for you to restart it..

Petros [00.11.56]: Yeah! That, yes!

Dimitri [00.12.02]: In public support, I’m assuming that if I’m getting back to somebody in one of these forms, then maybe that information is available to everybody, so they’ll have their answer before they reach out, or is that not the case?

Petros [00.12.21]: That’s true, yes. Actually when we started at Github, we used to have both public and private threads, like the tool we were using back then offered that option. So, for the people that were reaching out, the thread was public by default with the option to turn it to private. That covered both cases, like handling the private requests with sensitive data, but also deciding to leave something public so that other people can read it and in that way you may reduce, let’s say you support load, because you wouldn’t have to reach out for every little thing. That has it’s problems though, if it’s not a community that you are actually maintaining and curating, content dies, it becomes old and outdated and that creates more problems than those you are trying to solve. So, if you don’t have a dedicated community, like forums or personnel that actually maintains that and you also have a user base, your fans, that actually help you there and moderate everything, then it creates more problems than it solves.

Dimitri [00.13.44]: Excellent point of view! So, you mentioned Zendesk before, would you like to talk about some tools, third party tools?

Petros [0013.54]: The problem is that I only have experience with Zendesk, to be honest, so I can definitely give a few links from other tools that we evaluated from time to time, but most of the support at Github it’s been done using an internal tool that we build from scratch.

Dimitri [00.14.20]: Okay, so if I’m this tiny or medium sized startup, I’ve found my first support person and maybe I’m not happy with Zendesk, is it worth my time to develop my own internal tool or is it something that people should look at later stages? Also as a follow up, I’d like to ask, what was missing from Zendesk or the other stuff that you’ve evaluated, that led you invest time and money to build this?

Petros [00.14.55]: I think I can describe our story at Github, the cycle that we are almost doing now and may answer your first questions as well, whether it’s worth building your own tool or not. So when we started, we were using a third party tool, it wasn’t very popular, but it was for support. So, as we were growing, not very fast, we were still small and we had like, two people in support, we found that we needed some feature that the third party wouldn’t implement, because they would have to attend for the whole user base and not for their only customer. So, we either had to develop chrome extension to implement those features or just live with it. At some point we decided to build our own tool and we really developed what we needed, which was a very fast way to reply to as many support requests as possible without context switching and without doing too many clicks and all that. So that was our first basic requirement.

Dimitri [00.16.22]: ..And you weren’t satisfied with the solutions provided back then, right?

Petros [00.16.26]: No. We tried a couple of them to be honest, but we weren’t satisfied. They all had the problem that they were trying to look at it from the general perspective and satisfy the majority of their users, but we needed something very specific that was tailored to our needs back then, based on the size of the company, the size of the users that we had and all that. So, we did a very quick solution that had just one page, you were looking at your queue and you were clicking at the space to open the next one, reply and then when you sent out the reply you were back to the queue clicking space. So, that was the quickest that we could think of. It was just one web page. You could actually click space many times and it would open many different tabs for you, so you had every support quest loaded so you were saving time from going back and forth. So, we did that and we stuck with that tool and we started to develop it further, then we hired our first developer to maintain it and then we grew that team and that tool became full with features and every feature was exactly what we wanted and Github support. It’s fully integrated, it has features that our product has, like @metiones and comments and referencing issues at Github and everything that we needed. So, generally the best way to integrate with your products is to actually build it yourself, right?

Dimitri [00.18.50]: Is this available publicly?

Petros [00.18.58]: The name is “Halp” and it’s not publicly available, it’s only an internal tool and we thought about maybe extend it’s life, because if it was a product there would be a reason to keep on maintaining that and all that.

Dimitri [00.19.12]: If it was a product, you would have to put it out there and then you’d have paid customer and then you’d have to have support for that as well.

Petros [00.19.22]: We would have not only to to support that, but also we’d have the same problem the previous third party services had. If we wanted to add a feature, would that make sense for the external customer? Would it be necessary to have an internal version and an external version, which is an added problem for maintenance costs and all that, right? That was a big question. Imagine that now we have a two or three people team that maintained that tool and that’s a cost right? And not only that, but how do you support multiple channels, like let’s say you grow your support reach, do you keep just adding features and is that your core business, is your core business maintaining a support tool, maybe not, right? So, maybe now would make sense to go out and use a third party tool and focus on good integrations with your product and avoid all the problems that go along with having to maintain and internal tool. Which is still an open question to be honest, if you ask me know after going through all the stages, I would say, start with a third party one and make sure that it has a good API so that you can use anything that is missing and integrate it with your product.

Dimitri [00.21.01]: So, if you are a small startup you definitely recommend something third party. However I think that as you grow and you get more customers a lot of specific needs might arise and that’s why you would need to evaluate building your own tool. Tonight we’re talking about setting up your support, tools, getting your first support person, etc. I was thinking maybe to get into how would you get into a specific customer on the surface, because at some point you will visit us again in order to talk about managing your support ops that you have already set up, but I think it’s very useful to talk about dealing and engaging with customers even though we just talk about setting up, so would you like to talk about that for us a bit?

Petros [00.22.06]: Yes, of course. One of the most important things is to be responsive, generally. So one of the things we try is to send out a response even if we don’t have a solution so that the customer knows that we listened. The other thing, that we capture everything, we capture feedback, like if a customer contacts us and it’s not something that we can fix on the spot, we capture that, we make sure they understand that we understood what they’re asking so if sometimes it’s not so clear and we repeat what they said in their own words and then we categorise that feedback so that is available to the product and development team. That’s done in the internal tool. However, if the report is a bug report, we open an issue and we try to reproduce and we have the steps, we open an issue with the steps, if we have some technical information we also include them, if we can create a screenshot that’s also there, sometimes we like to create animated gifs, which is a thing with github issues, so we include that too, in order to communicate everything in a great way.

Dimitri [00.23.43]: An animated gif of the actual issue?

Petros [00.23.49]: An animated gif of the steps that you actually take to eliminate the problems.

Dimitri [00.23.52]: Okay, so it’s not a gif of cats dancing or something like that right?

Petros [00.23.57]: Well, no, but sometimes we do that because we want to persuade our product team to do something so animated gives are a nice way to do that. So, what completes the cycle after we receive a customer feedback is that we always get back to those users that reported the problem, so this is something that our internal tool is good at, it keeps references and everything and then just with one click you can view all the related support requests and reply back and that’s really something that people appreciate.

Dimitri [00.24.46]: Okay, I’d really like to elaborate on this in the future, as there are tons of thing that I would like to talk about here, but for know I’d like to ask you how do I best communicate this feedback I’ve received back to the product team, the development team, the team that the issue that I’ve got relates to?

Petros [00.25.25]: Yeah, that’s a great question. First of all, before I share some tips and advice, I have to mention that you need to establish a channel of communication. If it’s not something urgent, like the system is down or something like that, we don’t use Slack and say what about this and that. We rely heavily on issues and a synchronous communication for that. However, you need to have an agreement with your product team, or your engineering team about how you communicate those issues and what to expect from that. So, it’s okay to open an issue describing a problem and maybe not receiving a response there as long as that’s the agreement, right? You know that they read it, but they don’t have to reply, maybe. Maybe they agreement is that they open the issue, they read it and they need to leave at least one comment saying if something makes sense or if we are missing something about their workflow or maybe something is coming up when something is in the roadmap and they communicate it back to us so that we know. So, these are an overall. The next thing is to have a place, in the past we had problems because we were giving feedback all over the place, maybe it was in one repository or in the internal support tool itself, maybe it was in a slack channel or whatever. Like you said people are confused, so you need to know where feedback has to go. That’s for general feedback. For bug reports, it’s very easy, like you know where the team is working, so you go to that repository and you open an issue and that’s it. On what to say, that’s an advise I want to give. It’s not just copying the customer’s feedback, because sometimes you cannot interpret things the same way a product person or an engineer can do but you really need to understand it and express it in your own words and reduce it in the sense of giving a summary, because sometimes a user will come with a wall of text or with ten feature requests all together, so you don’t want to pass that on to the others, because they have so many things to do and reading all that is not the very easy thing for them to do, so you need to give a summary of what the user is asking.

Dimitri [00.28.28]: Very interesting points here, what stays in my mind especially is in terms of public support how can things might turn irrelevant, but it’s still out there, that really stuck to me and it’s definitely that I will keep in mind moving forward. Would you mind doing a recap of what we discussed?

Petros [00.28.59]: Sure! We discussed about when you need your first support person and we talked about how to hire one and how difficult that is and we talked about the different support channels out there and the fact that may want to start with just email. We talked about when you want to have presence in various channels, we talked about tools, support tools, third party tools or internal tools and if it’s worth the time to develop your internal tool. I talked about the cycle we did or we are doing right now in Github, starting from an internal tool and then maybe considering a third party one. We also gave an overview of how you deal with customer requests and I gave some advice on how to communicate your customers’ feedback to your product or engineering team.

Dimitri [00.30.11]: Okay, so there you have it, setting up your support. I’d like to start a support series and next time you’re on with us, Petros, we might get into ongoing support and elaborate to that penultimate point that came up. So thanks for being here tonight with us!

Petros [00.30.28]: Thanks for having me!

Dimitri [00.30.31]: It was very nice talking to you! So, you can send us your question by calling us on 8663705050 from anywhere, you can email us at hello@listenshiprepeat.com and you can drop a couple of reviews or stars on iTunes. You don’t have to go through the process of righting stuff, however if you want to do so we would appreciate that. You can just give us stars and that makes us go up in the rankings, more people discover us and listen to us, so feel free to share your opinion on iTunes about us and with that our episode comes to an end. We will talk to you soon. Good bye!