So, you’ve landed yourself a new gig running customer support at a snazzy up-and-coming startup. Congratulations!
I recently found myself in that exact situation after joining the dashing folks here at Baremetrics. (I’m Kaegan by the way–Hi! Go ahead and read the tale of Josh hiring me. Also, follow me on Twitter.)
There’s a ton of content out there about building a startup, but not a ton for jumping onboard once it’s already gotten off the ground and overhauling some part of it. I’ll be tackling this from the perspective of my role (Customer Support), but really anyone who is joining an established startup will find something to chew on here.
So, without further ado, I present: Kaegan’s Fantastical List of Things to do (and not to do) When you First Start Doing Customer Support at a Startup, or #KFLOTTDANTDWYFSDCSAAS for short.
Read all the things. Twice. Seriously.
You’ve got the skills, the experience, the know-how and the confidence, but you probably don’t know a heck of a lot about the product you’re going to be supporting.
There’s a good chance your new startup won’t have much internal documentation. So here are three places you can undoubtedly siphon some knowledge from…
- Your team’s chat — At Baremetrics, we use the awesome (and Vancouver-based!) team communication tool Slack. One of its best features is that its entire history is searchable. Early on I spent time rummaging through some of the more recent history in channels like #backend and #business. You’ll get a look at what’s currently being worked on (in other words, what’s broken) and as a bonus, insight into your new company’s culture. Don’t get too carried away though—there’s no need for you to know what your designer had for lunch 3 months ago (though having gotten to know Nick, it was probably tacos).
- Historical help tickets — You’ll learn a ton about how folks use the product, what the pain points are, and likely get some ideas about what to work on once you get up and running. For me, it was also great to get a feel for the way customer interactions had been handled up until that point. As an example, I noticed that Josh likes to say :highfive: when something has gone swimmingly, which I’ve gone ahead and appropriated as my own.
- API and Developer Documentation — Baremetrics simply couldn’t exist without Stripe. So I went ahead and read the Stripe API documentation. All of it. Crazy, right? Well, maybe not. Not only are our developers heavily using Stripe’s API, but our customers are using it as well. Simply put, I needed to speak their language. I’m by no means a programmer, but I can now hangout in our #backend Slack channel and (mostly) understand the conversation going on around me.
Your biggest weakness at the get-go is a lack of understanding of the ins and outs of the product, and that’s fine! Take advantage of the time you have early on to read everything you can get your hands on. However, you can only learn so much by reading, which leads me to…
Get your feet wet right away
If you’ve already worked in customer support, then you’re familiar with reading and responding to customer questions. If you haven’t, well you’ve probably (I hope) spoken to other humans before, so you’re all set on that front. So why not jump right in?
Here’s a couple of things I did in my first week…
- Answer tickets — Use your resources (chat history, ticket history and API documentation) and have a crack at it. Ask lots of questions, but try your best to find the answers yourself. You’ll remember a lot more than if you’re handed the answers (teach a man to fish and so on…). Plus, your new team will think you’re awesome, which is never a bad thing.
- Write and update help documentation — If you’ve been doing some reading, you’ll surely have taken some notes (more on that later), so why not spruce them up a little and offer them to your customers? Back in college, I found one of the best ways to study was to teach the thing I was trying to learn to my study group. It’s one thing to read about a concept, but it’s another to actually teach it. Your customers will be better equipped to perform self help, and when things get busy, you’ll have already completed a major project.
Don’t wait too long to get started. Take that new job excitement and channel it into something. Of course, make sure to check with your team that it’s okay, and have someone look over your work for the first little while.
Write down all the things
The first few weeks are going to feel like an information overload. The important thing is to make sure you’re taking notes—lots of notes. You can use anything: the notes app on your phone, Notepad/Wordpad, Evernote…anything. We use Trello, so I jumped on that bandwagon.
Not only will your notes be great to draw on later when the same question or problem inevitably comes up again, but you can look back on them and get some self-assurance (“Hey! I know that thing now!”).
The most important thing here is that you are in an incredibly unique and never to be repeated situation. You’re both a new customer of the product (in that you’re experiencing it for the first time) and you’ve got a behind-the-scenes look into the inner workings of the company. So you’re going to notice things—broken things, confusing things, wonky things—that you’ll never notice the same way again.
Now, why not just blurt these things out as you come across them? Well, there’s a few reasons for that.
- You’re still learning the ropes — The other side of the newness coin is that you’re, well, still new. Some stuff may seem weird, but you don’t yet know enough to know why things are the way they are. So hang tight.
- You probably don’t have the answer yet — On day one you’ll notice some things that could use a little elbow grease, but you probably won’t be able to craft a solution right then and there. If all you’re doing is identifying problems, you’re putting the onus on the other guys to fix it. But you’re here to make things better!
- They know — Startups grow quickly, and things that worked six months ago may not be working now. But there’s sooo much going on, that fixing it has probably just fallen off the radar.
Here’s an example: when I started, we were using Intercom to handle customer support questions. Intercom is fantastic and does a lot of great things, but once you need to start tracking bugs, feature requests and answering lots of questions in a day, it starts to show some cracks. I recognized this almost right away, but I decided to stick with it for a while until I could propose something better.
Fewer than two weeks in, Josh messages me…
“So, FYI, if you find Intercom isn’t working as a way to handle customer support, I’m all ears on a different solution. We’ve tried a number of things over the past year, but don’t feel shoed in to Intercom if you think there’s something else we’d benefit from.”
Boom. Josh already knew.
We were already using Help Scout for support documentation, which made it an easy choice to use for tickets too. By the end of the day, we had migrated over.
Sidenote: We still use Intercom for most of our customer marketing, just not for support.
You’ve got a fresh pair of eyes and they won’t last forever. Soon the quirks will become the status quo. So take notes and start thinking of solutions! You’ll come away with a smorgasbord of projects to work on for the next while.
Closing thoughts and next up
I can confidently say that I have broken every single one of these guidelines in my first few weeks on the job (some more than once). So long as your founder/maker/boss-person was super thorough in the hiring process, they’re probably stoked to have you there. So go crazy…ask questions…break things…fix things…then break them again.
I have at least four months worth of projects lined up, most of which came out of notes I took in the first week or two. More blog content, more swag, more Twittering, more of everything!
But I’m open to ideas and suggestions (ulterior motive, perhaps?). Got a cool idea or perspective for me? Hit me up in the comments and let me know! :highfive: