Starting a marketplace is hard. Scaling a marketplace is harder.

Trying to turn an idea into reality is hard — it’s hard because you don’t know where to start, it’s hard because convincing people to do things they haven’t done is hard, it’s hard because you need to believe something will work when everyone tells you it won’t. It’s hard because you don’t know where the line is between brilliant and stupid, and you’re not always sure which side you’re on. When we started Handy, we thought if we could just get to certain milestones — the thousandth customer, the ten-thousandth pro using the platform, the millionth booking made — it would get easier, that scaling is simpler to do than starting. It isn’t. We’ve learned this firsthand. Starting is hard. Scaling is harder.

The first scaling challenges always catch you by surprise, they wait until 6:00am on Sunday to call you and shake you awake. They come in the form of the distraught cleaner calling your phone to say they opened a customer’s front door and their cat, Muggles, escaped. They come in the form of your platform’s communication system struggling with the volume and then accidentally misrouting phone calls and messages. They come in the form of customer service tickets rapidly coming in and you not having the capacity to handle them. While starting challenges occur quietly in a corner of an incubator, or in your garage with a few friends, scaling challenges occur publicly while you’ve got hundreds of thousands of users watching you, waiting for you, relying on you. The consequences are bigger, the nuances are more important, and more people are reporting on what your company is doing, not doing or, worse, misconstruing both. The companies we respect the most, the ones we turn to for learning and inspiration have all had moments of scaling that challenged them to their core.

When we started Handy over 3 years ago we had challenges that we thought were our hardest. We didn’t know where our first customers would come from, we didn’t know how to decide which of the ten pros should be given access to the platform out of two hundred applicants, we didn’t know what price to charge, we didn’t know what to do when a cleaner didn’t show up to a job. But every instance of a problem was individually fixable, very fixable. It took but a phone call, or for us to ask a pro if they were interested in working a few extra hours, or for one of us to personally go and take care of a job. And then, we started to scale.

As Handy rapidly scaled from a dozen jobs a week to hundreds, to thousands, to tens of thousands, the scaling challenges came at us fast. And unlike the early days of Handy, where it was possible to fix each instance of a problem by dedicating all of our resources, it took us some time to realize that wasn’t possible at scale. At scale, it’s not possible to fix the instance. That’s fighting a losing battle. You actually have to fix the underlying problem at its root. This causes a seismic shift within the org when you realize you cannot fix each instance, and instead you have to fix each underlying problem. The obvious question to ask then is “why doesn’t a company work on all it’s problems before it begins to scale?” The challenge here is many times you don’t actually know what your scaling problems are till you reach that scale. The other seismic shift, is the realization that you can’t fix all the underlying problems at the same time. There’s a very important sequencing that occurs in terms of how to deal with the underlying problems that develop at a local services marketplace as you scale. And admittedly, we haven’t always gotten the sequencing right. Sometimes, we focused on fixing the wrong problems first.

Today, to help us better understand which problems to prioritize and where to focus our resources to deliver the best customer experience possible at our current scale, we use a simple pyramid:

1. The base level of the pyramid starts with trust — without trust nothing else matters. If your customers don’t trust you, they won’t use your service. If people didn’t trust the cleaners and handymen using the Handy platform to enter their homes, nothing else would matter. Through deep background checks, insurance, and a comprehensive customer rating system, the Handy platform has built trust with our consumers such that when a consumer comes to Handy they trust us enough to make a booking on the platform. One out of every two people that do a search on Handy make a booking — it wasn’t always like this. It has taken enormous effort to build to the current level of trust that exists with our consumers.

2. The second level in the pyramid is reliable logistics. To us, this means that whatever service is being delivered, it must consistently show up on time. We’ve spent the last three years building a platform that attempts to get 100% of pros to their customers at the right time. The biggest fail point at this level is the percentage of the time that a pro simply cancels their job at the last minute and the customer doesn’t get the service they requested. In our biggest cities, a year ago this was over 12%, today that number in New York is less than 2%. This means that for 98% of the bookings, the pro arrives for their customer at the scheduled time. That’s still not good enough. Our challenge today is to shrink that 2% to 0.2%.

3. Third is service delivery. At Handy, this means the quality of the service itself once the pro is at a customer’s home. Service delivery is one of the most subjective and hardest parts of local services, and improving it involves everything from the method for registering service professionals, to customer and pro rating systems, reliable feedback loops and educating the customer to ensure their expectations are properly aligned with the service that will be delivered. We maniacally focus on the percentage of 5 star cleanings that occur through the Handy platform — a year ago that was 60%, today over 70% of bookings are rated 5 stars and over 85% are rated 4 and 5 stars. We continue to focus on how to get to a world where 100% of bookings are rated 5 stars.

4. The fourth is incident resolution. As with many things in life, with local service delivery there is a probability of something going wrong. Unlike with goods, the incident rate for services is higher — there are more variables that could go wrong than in getting a package from A to B. As a result, it is important to have fast and effective incident resolution to deal with unexpected issues across logistics, service delivery and trust.

5. Fifth is service personalization. Imagine a world where your customers trust you, and the pros using the platform consistently show up on time and deliver a service your customers are happy with. The next step is to focus on personalization — how can individuals take an experience and make it theirs. We think about personalization not in the form of what standard items a person does inside your home, e.g. clean the kitchen vs clean the bathroom, but instead how they can personalize the experience at a level where it is obviously unique to you. This might include things like picking up cleaning items for you or stocking up on a few paper goods like paper towels, or using a specific scented cleaning product that your pro knows you like.

6. The last step, or the pinnacle of local service delivery is to do the unexpected — to deliver something amazing to customers that they didn’t even know they wanted. From leaving scented candles at our first customers’ homes and folding their towels into animal shapes, to the kittens delivered by Uber, we know what these “surprise and delight” moments can feel like. We hope to get here at scale.

Delivering Local Services at Scale

At Handy, we use the framework above to identify priorities in the stack of things to work on. Scaling is a never ending process of revisiting the same challenges at different volume points and learning from each and every one so that we get better and better. A few times over the last three years, scaling has caused Handy to slip down the stack and has required us to reevaluate parts of the platform that handle logistics or issue resolutions. There have even been a few days over the last year when our marketplace simply grew too quickly and the system that processes jobs broke down — this had meaningful downstream effects in the flow that causes tickets per job to go up and subsequently overwhelmed our customer service center. This pushes you all the way back down the stack to the problem of reliable logistics. There have even been times when we inadvertently tested the trust of some our customers as we moved our business to a recurring only model on web and an on-demand model on mobile. Although, we knew this was the right thing for most of our customers, we should have re-focused our efforts on communicating more and rebuilding the trust of the customers for whom it wasn’t, instead of continuing to focus on logistics at the time.

Today at Handy we’ve expanded our focus to steps 3 and 4 — consistently offering a high quality service and providing rapid resolution to user questions — these were problems we solved at ten thousand bookings, yet here we are revisiting them again at two million bookings with a more sophisticated team dedicated to addressing each one of them more effectively than before. At the end of the day, what we’ve learned the most about the challenges of scaling is that it never stops. At every moment in Handy’s history we can look back 3 months and say “I can’t believe that’s what we were doing 3 months ago, I can’t believe those were our challenges then”. We also know that while every moment feels like the most challenging moment, in 3 more months we’ll look back and say the same thing. They’ll be more challenging, the stakes will be higher and thankfully we’ll know that much more about how to solve them.

Umang Dua & Oisin Hanrahan

Co-Founders - Handy

P.S. In case you were wondering, we found Muggles and returned him safely to his owner.

Thanks to Paddy Cosgrave, Rebecca Greene, Philip Hanrahan, Scott Hilleboe, Spencer Lazar, Ken Little, Melody McCloskey, Pat Phelan, Alex Taussig and David Tisch who read drafts of this article and helped make it better.