Support’s Wild Ride: Impacts of Udemy's First Inflection Point
There’s a scene in the 2008 Pixar flick Wall-e, where our helpful little robot protagonist is suddenly launched into space, holding on for dear life to the outside of a rocket. It’s a perfect metaphor for support’s experience at startups when that first inflection point hits.
In 2012, I joined Udemy as 15th employee. At that time, we subsisted in a shared office under a freeway, and I had to bring my own laptop my first day, so it’s no surprise that support was an afterthought. In many cases, the CEO covers the support inbox at a startup, so it was at least a bit more evolved at Udemy, where we had a one person support “team.”
The leadership team at Udemy right before our inflection point were like DIY astronauts, trying to get their rocket engines to ignite. We had knowledgable pilots, like Eren Bali, Gagan Biyani, Dinesh Thiru, Mia Gokce Tombul, Archie Abrams, Tim Parks, Max Altschuler, Holly McNamara in the cockpit, looking at levers they had experience with. But this was an untested rocket, a new model, so really they’re just trying stuff. Product experiments, outreach campaigns, new marketing channels. Growth lurched and sputtered, but gains were made painstakingly slow through learning and grit and teamwork.
Then, something works. The right combination of levers are tweaked and suddenly, engines spark to life. A roar of potential reverberates off the walls. In seconds the entire ragtag crew buckle in and are pushed back into their seats, accelerating toward the stratosphere.
Houston, we have inflection.
Support, like Wall-e, clings to the outside of the rocket at liftoff
At Udemy, liftoff came in the form of an innocuous affiliate campaign launched by Dan Murphy, selling a two-for-one deal on online Excel courses through Amazon Local. Overnight, 100,000 new users turned a manageable volume of tickets into a tornado, tossing houses on support’s head. MVP product implementations and bespoke backend tools that were fine when we were serving only early adopters, caused intense friction for the new user base. Almost instantly there was a huge backlog, with response times at embarrassing levels despite herculean efforts by our sole support person.
Support, like Wall-e, will find themselves on the outside of the rocket at liftoff, casually doing maintenance and checking the hull for cracks.
Support scales not by choice, but as a chain reaction.
Most teams in a startup scale strategically. Investments with limited capital are made to maximize growth, and that strategy continues with the sudden explosion in growth, and the subsequent fundraising that comes with it. Teams like product and marketing choose to invest in new areas. They hire and grow based on opportunities.
Investment in support is not based on opportunities, it’s a consequence of growth. Support is forced to scale by necessity; reactively, and exponentially with user growth. And the faster a company grows, the harder it becomes for Support to keep up. The fundamental correlation between user growth and ticket volume is a critical realizations leadership has to recognize as early as possible. Support scales not by choice, but as a chain reaction.
At Udemy, we didn't recognize this reality ahead of time and, as a result we weren't ready for the chain reaction. By the time I was tasked with taking over support, we'd built a 2 week response time backlog and our CSATs were under 40.
As a result, I had to focus immediately on short term, quick impact solutions, rather than truly scaleable initiatives that would take time to implement. This included suboptimal, temporary fixes which I knew we'd have to undo later. For example, nearly half our tickets were refund requests so I setup a basic auto response to anyone that used the keyword "refund" asking for the necessary information we'd need to more quickly process the ticket. This was far from an ideal fix, as those with queries like "I don't want a refund but..." were met with an auto response of "In order for us to process your refund..." Very much not ideal, but getting through this moment of crisis was the main priority. It was also an easy change to undo, which we did as soon as we'd gotten a hold of volume.
The other main focus was to bring the company as a whole into the effort. There were large batches of tickets we could partition out and give to any competent individual to resolve, but we didn't have time to wait to hire someone. Instead, the answer was a daily "ticket bash" where we bribed members of various teams with pizza and beer if they would spend an hour helping to clear the queue. This solution turned out to not only help with our short term backlog, but gave a new way for folks usually several levels removed from our customers to find connection and build more intimate relationships with Udemy's overall mission. As support grew, the ticket bash became a regular occurrence, even when volume was manageable.
Over the next 10 years, our customer operations team would grow to support over 100 million students, with courses from over 200,000 instructors in 75 languages as Udemy went from series A to a successful IPO as the world's leading online education company. But first, we had to find a way to get support back into the cockpit. Next time, I'll explore our first foray into building a truly strategic partnership between Support and the rest of the org. Stay tuned!
