What I Learned Scaling Operations at a Startup

How we effectively scaled support from 0 — 1m+ users

If it’s done right, during the really early days at a startup, customer support is owned by the CEO. He/she handles customer emails personally, alleviates customer tension points, and prioritizes bugs and product fixes all the while maintaining an overall vision to cater future features and growth plans to user requests.

These were the early days at Redbeacon, an online marketplace with the tagline ‘Whatever you need. Done.’ Redbeacon was originally created to cater the needs of everyone and correspondingly filled the supply side of the marketplace with high quality pros. Think handymen, dog walkers, boat captains, photographers, and hundreds of other verticals to meet the demands of customers looking for the perfect pro. Redbeacon has since found a more niche market and now caters specifically to home-service needs. The platform matches customers with pre-screened and pre-approved home-service pros who bid real-time on submitted jobs.

One of the problems a quickly growing startup, such as Redbeacon, encounters is that as the vision, team, business, and priorities expand, customer support very abruptly moves down on the CEO’s priority totem pole.

I was the 3rd hire at Redbeacon and I had a very specific focus on marketplace sales and support. The support ‘beacon’ had already been passed to our COO, and quickly thereafter to our Head of Business Development. Here are some of the things I learned as we grew the business and support team 100x both pre and post-acquisition by the world’s largest home improvement retailer: The Home Depot.

You have to fight for your customers. Startups move quickly. This means product launches happens fast. Unfortunately, due to a lack of resources, this can often result in the inability to optimize previously launched features. We’d launch a mobile app one week, a new online bid flow the next, and an entirely different pro CRM two weeks later. This meant our support team was flooded with issues, bugs, and questions. Because engineering/product were so engrained to launch, launch, launch, they moved slowly in understanding, quantifying, and improving the previously launched features. It was operation’s responsibility to speak up for customers, prioritize bugs, and review launch data — ops has to give users a unified voice.

Visibility matters. In order to understand the needs of your customers, you need to spend time with them. It is crucial that you personally provide the service experience you are building, observe customer frustrations, and use the product your building for customers. This is why everyone at The Home Depot, from C-Level executive to Online Associate, works in-store at least a couple days a year. They do everything from taking support calls, to loading lumber, to finding the perfect paint for a customer. In an online business, this is a little more complex, but even more important. I remember the second week our current CEO started. He was on the phone at 6 AM calling customers to understand how they were using our product. The next week, to maximize sales volume, our Head of Business Development (credit to Austin Vedder) assigned sales targets to engineers. He exposed the builders to the customers they were building product for and it was unbelievably valuable. Engineers began to understand and prioritize their own fixes and they could speak intimately to the product they were building — it forced engineers to think outside their own dev box.

External training is really hard. When you’re the only one taking calls, it’s easy to understand how everything is done and what issues to expect. And having engineers next to you to answer questions certainly makes it easy to get things fixed. All this changes when you spin up an external team. An external team requires a lot planning and definition, both of which are solely lacking during the early days at a startup. During the time we were building-up our external support team at Redbeacon, our motto became ‘Test internally. Launch externally.’ All new features and processes were tested by an in-house support team before we updated our knowledge base with the appropriate training docs (KPIs, SLAs, FAQs, etc.) and trained our external teams. This forced scalability through internal due diligence.

Data is your best friend. Because of Redbeacon’s unique business model, we built our own in-house CRM solution. But we made some mistakes along the way —reminder: do not harbor support email in individual Support Agent inboxes. This resulted in sexy data schematics like Ducksboard not being an option, on-top of many other issues.

Engineers were slammed with launches and bugs and they simply didn’t have time to build data dashboards. In order to establish SLAs/KPIs, the ops team was forced to get creative. With the help of an engineer, I quickly learned MySQL and started pulling core metrics like effective utilization, ASA, and FCR on a daily basis. Other members of my team jumped on the data pulls as well; some even learned Python to build out additional tools. Having data on-hand made quantifying and speaking to our business exponentially easier. As an added bonus, it made us less reliant on engineers and product teams. My personal motto quickly became, ‘ask for forgiveness, not for permission.’

Sometimes adding cost is the only option. Investors do not want to hear that their most recently funded startup needs to scale up a triple-digit call center. Isn’t that what technology is for? — Unfortunately, no. Sometimes the only option is to build a highly qualified and available support team. And frankly, in our customer-first generation, it’s expected (thanks Zappos & Nordstrom). There were particular processes involved in our offline marketplace exchange that required extensive handholding. There was simply no other way to solve issues such as escalations, guarantee handling, service provider no-shows, etc. Ultimately, supporting the business should be the first goal of any ops team and you simply cannot be the piece holding back the business from potential growth. It’s easier to search and solve for efficiency once the business has been proven, than to hinder growth by being unable to support the business.

Thanks for reading this far! If you got value out of this article, it would mean a lot to me for you to scroll down a bit farther and hit the recommend button.