Podcast

#134 – Startup operations, infrastructure, & scaling it all | Chris Jones, Michael Mizrahi, & Ben Grynol

Episode introduction

Show Notes

Operations is one of the main foundations of building a tech startup. It’s needed to operationalize the product that exists and helps you decide when and how to automate processes. As your company grows, it will become harder and harder to keep your operations manageable. So, it’s important to start that process today. In this episode, three Levels’ team members discuss infrastructure, throughput, how companies are built, and how they come together.

Key Takeaways

09:33 – Automate processes

Miz said automating shipping and delivery emails doesn’t lessen the customer experience, but actually enhances it.

Behind the scenes, start building the process so that if someone places an order, their order should be able to get shipped and out the door without someone needing to copy and paste their address into a different system and copy over details and shipping exceptions and all these kinds of things, and send a message that, “Your package is shipped, here’s the tracking information.” We’re doing all this manually when these are things that can very, very well be automated, that doesn’t take away from the customer experience, the member experience. You can still have a great member experience by automating shipping delivery emails. And arguably, it’s better because they’re more timely. They don’t have to wait until someone gets through a queue. So all that long tail processes is probably the rest of phase two as we’ve defined it here.

10:13 – Document everything

Chris said he was shocked how heavily documented the processes at Levels were. But good documentation goes a long way toward helping the company succeed.

When I started, I was a bit shocked in a good way of how much documentation there was in place for a company of this size. When I came in, there was three support specialists. And normally, a company that size, it’d be like all tribal knowledge, all like, “Oh, I just know how to do this,” and maybe one or two things written down. So the fact that, I mean, really hand it over to Miz and the team for, “Hey, because of Levels, let’s document things. Let’s put the work in now.” When I’m at the community and asking questions like, “How do you issue a refund? How do you track an order?” Like, “Oh, here’s a Loom, here’s a place to go.” And I was like, “Wow, this is incredible repository. Things that I sometimes wouldn’t even see at very mature installations.” I happen to know some of the guys building the Verizon call center. And sometimes, you get into the, wow, they… Even just the little things go a long ways even when you’re a small team and it matters.

11:19 – Know when to speed up and when to slow down

Chris said the goal isn’t just to do things as quickly as possible. Sometimes you have to slow down and listen to your customers.

There are certain things where we’re looking for efficiencies and to optimize and saying where can we be more efficient with tools like a text expander of little safe snippets versus rewriting the email every time and spending five minutes when you’re writing the same thing of like, “Hey, can I take my sensor into a sauna or a spa?” That is very cut and dry, us getting more efficient on that. But there’re also areas where we want the team to slow down and make sure that we are still human and we’re listening to the customers. And this isn’t just trying to be a human chatbot where it’s like how fast can we answer the tickets and how quickly can we solve it? But saying, “Let’s take the extra time to know our members.” We have a very large percentage of our member base that interact with support. And a piece that I keep reminding the team and people as we’re looking to grow it is we are an extension of the product. This is not an afterthought of support around how do you get costs down low from a line item on a COGS stand sheet, this is an investment in the end-to-end service offering. It is just as important.

13:37 – Keep your goals in mind

Miz said it’s important to stay focused on the brand you’re trying to build and what kind of relationship you want to have with your customers.

This isn’t about ruthless optimization of metrics and service level agreements and hitting the targets. Because we could do that. Our structure would look very different and our results would also look very different. And we might save a few bucks, but it’s the wrong phase of the company to start over optimizing in those areas. And that’s not the brand and the relationship that we’re trying to build with our members. And so keeping the goals in mind is incredibly important, especially in this kind of industry and function where it’s probably easy to go overboard and do this the wrong way, so to speak.

20:51 – Balance your priorities

Miz said responding quickly to customer queries is great, but you have to balance that with what your team is consistently capable of.

Support from so many companies is already such a miserable experience that if we can respond well in two hours, we’re already doing exceptional. And in the 15 minutes is just like a complete wow. So the two hour zone is probably healthy. And we could probably get away with moving to the four hour, five hour zone. But then, qualitatively, thinking through the member experience here, if you just got a sensor and you’re really excited to put it on and something goes wrong and you have questions or you’re nervous, a quick response in those moments means the world. And you might still hit the, “Yes, I’m satisfied” if you get the response a few hours later because we solved your problem. And the question is like, “How did we do? Did we solve your problem? And it’s not good, okay, or great.” So yes, we still might get those greats, but we know some of the qualitative just by being users of the product ourselves and just hearing people’s stories that there are times and places where being quick and being responsive really does make a difference. That’s why we have weekend support. That’s why we’re mindful of our hours. And so there’s a healthy balance here of just using good judgment and not only going off of the data, and that’s where we get some good play back and forth.

22:00 – Remove unnecessary interactions

Miz said there are many questions or items that could be self-service, so give customers an easy, automated answer for simple questions.

There are interactions that need to happen and there are actions that don’t need to happen. And so we want to automate and remove as many as possible of the interactions that just are unnecessary for the member and for us. How do I reset my password? How do I change my shipping date? All these either FAQs or transactional things that we can very easily build into the product through a setting on your profile page, export my data, delete my account, whatever it might be, that should all be self-service. And we should get rid of all of those contexts and really spend the time interacting with members where there’s deep questions, understanding, community building opportunities, product feedback that we’re getting and going back and forth on. That’s where we want to spend the time. And if the acute issues can be well handled quickly, self-service, that’s a win-win for everyone. And so that’s really the mindset and philosophy on scaling here. It’s not just like keep up with everything. It’s keep up with the right things, get rid of the wrong things.

25:49 – How to lean into asynchronous communication

Chris said that if you want to start using asynchronous communication with customers, you have to make sure you’re still giving them an optimal experience.

Even though we have all agreed to work asynchronous when we signed up for Levels as an employee, that doesn’t mean our members have signed up for that same type of experience. So this is another experiment of like, I really want to try to lean into asynchronous as a channel as long as we can say, “Can we still deliver a world class experience doing it?” Versus just saying, “Well, everyone has a phone. Everyone has live chat. Everyone has these channels. And they have it in every language, 24/7. And now we’re having 15 call centers around the world in every language. And people are sitting there waiting for the phone to ring on an eight hour shift and don’t talk to anyone.” I’ve been in those shifts. It’s not fun to be on a graveyard shift when they’re like, “Yeah, no one called today.”

31:30 – Simplify as much as possible

Miz said to get really good at one channel before you start adding in others. Keep the processes as simple as possible so everyone knows how to handle everything.

It really depends on phase. I would start wide at first just to figure out the basics in very early stages. And then, I think my position and advice would just be simplify as much as possible, get really, really good at one channel. And then once you build out the processes, once you have a plan for how you’re going to team members and actually keep up with the volume and understand what issues come up, where you have escalations, maybe you have a business that has a lot of fraud and chargebacks, and that becomes a big function that you need to build out. Spreading that out over channels becomes really messy. At least I’ve seen from some peers and companies I’ve helped out along the way. And so simplifying as much as possible so that the processes are crystal clear that everyone knows how to handle everything. And then you can experiment with turning on some of these other channels once you have some confidence that you can handle it, and that your members or customers are asking for it.

46:42 – Hire passionate people

Chris said to hire people who believe in your brand’s mission and purpose, because they are the ones who will want to make your product better.

Where you can, hire people that are just as passionate about the product or the service you’re building as the rest of the team. So everyone that joins Levels is like, “Oh, I love your mission.” And the amount of people that are applying for the current opening job, they’re like, “How do I be part of this team? I have been following you guys. I’ve listened to every podcast.” You want brand ambassadors on your team that are pushing your brand forward and advocating because they really believe in what you’re doing, versus just, “Oh, let me go find someone who’s really good at support, and can find an FAQ, who can navigate tools.” They’re going to work the queue good, and they’re going to do a good job and they’re likely going to get good CSAT, but it’s the harder problems, or the… Eventually, it’s like, they’re going to say this is a job. It’s going to be like flipping burgers. Like yeah, I’ve seen that case over and over again. You want people that want to make the product better, make the experience better, make the tools better because they feel part of it.

48:30 – Build the right team

Miz said there’s a lot of value in hiring correctly and building the right focus and culture of the team, because those people are the ones who will solve your company’s problems.

One subtle point that’s worth adding here is that this isn’t to say that we don’t build a process and we don’t improve things along the way. But when you have people building process that understand the issues deeply and can be empathetic and understand the complexity and have seen the issue dozens and dozens of times, the process that that person will build to automate or fix this problem will be very, very different from the smartest analyst coming in, looking at the problem and trying to solve it. And so there’s value in hiring correctly and building the right culture and focus of the team. Because the processes that you build when you do have to scale will be better ones that better serve your members and that better serve the company and the brand and the product. And so that’s why that matters, particularly.

Episode Transcript

Chris Jones (00:06):

This isn’t just trying to be a human chatbot where it’s like, how fast can we answer the tickets and how quickly can we solve it? But saying, let’s take the extra time to know our members. We have a very large percent of our member base that interact with support. And a piece that I keep reminding the team and people as we’re looking to grow it is, we are an extension of the product. This is not an afterthought of support around how do you get costs down low from a line item on a COGS stand sheet. This is an investment in the end to end service offering.

Ben Grynol (00:45):

I’m Ben Grynol, part of the early startup team here at Levels. We’re building tech that helps people to understand their metabolic health. And this is your front row seat to everything we do. This is a whole new level.

Ben Grynol (01:11):

One of the most interesting, yet likely nerdiest things that we could talk about on this podcast is the idea of scaling operations. But when it comes to startups, when it comes to tech, it’s a very interesting conversation if you’re interested in this idea of operations, infrastructure, throughput, how companies are built and how they come together. And so for Chris Jones, had a member experience, and Michael Mizrahi, Miz as many of you know him by now, Miz is head of operations. The three of us sat down and discussed these phases of building out opposite levels. There’s really been three phases and we’re now entering the fourth.

Ben Grynol (01:49):

Chris has a ton of experience with different companies, including Zynga, TurboTax, Google Nest, and Miz spent a lot of time helping to build Uber from its early days until it IPOed. And so there wasn’t a ton of info about metabolic health, but if you’re interested in startups, in scaling and in all of these ideas of building infrastructure, it might be a conversation you are interested in. Anyway, no need to wait. Here’s where we kick things off.

Ben Grynol (02:22):

Yeah. So there’s lots of interesting thoughts around ops and the way that ops can scale at any company will differ. Generally, ops, there’s this dichotomy of startups where you don’t want to implement too much process too early, but when it comes to things like ops, you need tooling, you need processing, you need these systems in place to start to scale. And so that would be interesting to dive into some stories given each of you have very interesting lenses on ops, as it relates to past experience and thinking through how we have… We’re basically hitting this fourth phase of operations, this iteration on ops at Levels. So diving into all things related to ops and seeing where it goes.

Chris Jones (03:07):

Awesome. Miz, if I think from a Levels standpoint, I mean, when I came in, you had a lot of the things documented and well oiled. So if you could start more from the early days of Levels, like when you didn’t have really any process to now, I think that’d be a great place.

Michael Mizrahi (03:23):

Yeah. Yeah. That’s good to catch us up on the phases that Ben is talking about. So when I first started talking to Levels to Sam, Josh, Mike D., the rest of the team, the team shared a lot of docs with me, with looms and background on how they were running things. And so the early days of the beta, they were still handholding a lot of members through the process. And the process was completely manual. We’re talking spreadsheets, jot forms, Zapier, like all these different tools scotch taped together, and a lot manual process to fill each and every order.

Michael Mizrahi (03:54):

So for every single order that’s placed, there were multiple hands on it through all the phases. And as the volume started to pick up from maybe half a dozen to a few dozen a week, that work started taking on just a lot more time and responsibility. And that’s when they started looking to hire. And I was coming in from previous experience at CloudKitchens, at Uber, having seen what this looked like at massive scale, right? And so I’ll use the Uber example. I came in the early days in 2013, where each city is running its own process, onboarding its own drivers, handling its own customer support tickets. When people say operations in tech, that’s what this really means. It’s kind of like operationalizing the product that exists, but rubber hits the road, you got to actually make that happen.

Michael Mizrahi (04:41):

So there’s people to move through processes, things that have to get done in a certain order, that’s the operations bucket. And so I had seen that from the early days of Uber, then scale all the way to millions and millions of trips per day in 500 plus cities. And necessarily, you have to change the way you do things along the way, and you implement all sorts of tools and process and checks and people, and just a lot of complexity, a lot of which is very necessary. And so it’s funny coming into a very early stage startup and just seeing how things can be done. So simply knowing what it might look like at massive scale, and then trying to find your way back to like, what is the next step that it needs today just to get it to the next point, to alleviate some of the pain points.

Michael Mizrahi (05:23):

And that’s when you just start looking ruthlessly for any manual process that doesn’t need to be manual, things that you can automate, products that you can build. You still want to stay in touch, still want to have control. So that’s where we got started. And the best place to do that is really to document the process that is already happening in the shadows. And then you can identify what you might be able to automate and scale up. And so that’s the broad overview and the way the lens I took on it.

Ben Grynol (05:46):

That was 1.0, was everything was manual. It was necessarily manual. It was all hands-on deck. It was Mike D. It was Josh. It was Sam. Everyone pitching in to do all these things related to ops. The interesting thing is, you don’t want, in ops or in startups, you don’t want to be at some perfect state. You don’t want to design for, “Hey, we’ve got all this tooling” because you’re spending time unnecessarily, because you don’t really know if you’ve got traction if you’re doing 10 orders per week. The more efficient thing is to be manual is that it’s almost like an option, like knowing when’s that option, when you’re going to exercise your option of like, “Okay, we’re at 50, we’re at a 100, where is the bandwidth constraint where throughput is suffering” and more time is spent doing manual things than necessary.

Ben Grynol (06:30):

And so we’ll call that 1.0. And 2.0 is when you started operationalizing it, Miz. 3.0 is when Chris came in and started implementing some KPIs and some analytics around ops. And then now 4.0 is a lot of scaling, experimentation and testing. So we’ll go through all these different phases and talk about them.

Michael Mizrahi (06:50):

Cool. Yeah. You got phase one, the manual days, where you want to have tight control. There’s so much variance where introducing process doesn’t make sense. It would be a fools errand to introduce process at that point because things can go in so many different directions. Phase two is, I think, starting to bring more people into the mix. And so all of a sudden, you have a need for documentation and process that is somewhat repeatable. And so at this point, the team is, I think Mike and Mercy. And so Braden was our first external hire probably fall of 2020. And things had to be documented so that Braden could start running with it. Right?

Michael Mizrahi (07:26):

And so previously, if you had a, let’s use a support response as an example, we did SMS. So people could literally just text a number and Mike or Josh would answer. Saturday morning, Sunday night, Friday, whatever it was, you could text us, which was really important for that relationship with early members. You could also email us, but you could email help@levels or you could email josh@levels or mike@levels. You could call us because we put our phone number on stuff and people just were able to answer the phone. We had an email tool for help at called Zendesk. And so the long story short here, many, many tools, many, many services, not one place where conversations are happening.

Michael Mizrahi (08:04):

And so that first step is starting to consolidate all of these different tools and simplify as much as possible so that there’s one place for all customer conversations to happen, so that you’re not getting to the point where Ben writes into Levels and has a question about applying his sensor and Mike needs to know that Ben also texted, “Oh, I already got that. That’s handled.” That works when you’ve got a few members and you’re the only one doing it. It doesn’t work when you’ve got dozens of members, hundreds of members and beyond.

Michael Mizrahi (08:31):

And so that was step one, is, let’s get everything into one tool and build. And from there, we can have a shared platform, shared foundation, shared visibility to then start layering on process and standards of doing things in the same way. And so that was the first step there. Just to fast forward through the rest of the steps of phase two, documenting all of the process, establishing standards and guidelines. You don’t want to put in like a heavy handed refund policy with no exceptions. Let team use their judgment. Things are going to be different. Things are going to go in different ways. Let’s have the principles of what great support and service looks like. So that’s that phase. And then the team starts growing and you need to be able to repeat that with multiple new hires and bring them into the mix.

Michael Mizrahi (09:10):

Along the way, you can start standardizing some language, but we’re really talking about standardizing support here, but there’s things that you want to avoid overdoing, right? We’re still a small company. We still know our members deeply. We’re not trying to build a call center for Verizon. It’s a very different kind of business. And so making sure that we keep some hard in it and that we make sure that we understand what we’re doing, why we’re doing it. And behind the scenes, start building the process so that if someone places an order, their order should be able to get shipped and out the door without someone needing to copy and paste their address into a different system and copy over details and shipping exceptions and all these kinds of things, and send a message that your package is shipped, here’s the tracking information.

Michael Mizrahi (09:51):

We’re doing all this manually when these are things that can very, very well be automated, that doesn’t take away from the customer experience, the member experience. You can still have a great member experience by automating shipping delivery emails. And arguably, it’s better because they’re more timely. They don’t have to wait until someone gets through a queue. So all that long tail processes is probably the rest of phase two as we’ve defined it here.

Chris Jones (10:12):

I think about when I started, I was a bit shocked in a good way of how much documentation there was in place for a company of this size. When I came in, there was three support specialists. And normally, a company that size, it’d be like all tribal knowledge, all like, “Oh, I just know how to do this” and maybe one or two things written down. So the fact that, I mean, really hand it over to Miz and the team for, “Hey, because of Levels, let’s document things. Let’s put the work in now.” When I’m at the community and asking questions like, “How do you issue a refund? How do you track an order?” Like, “Oh, here’s a loom, here’s a place to go.” And I was like, “Wow, this is incredible repository. Things that I sometimes wouldn’t even see at very mature installations.”

Chris Jones (10:59):

I happen to know some of the guys building the Verizon call center. And sometimes, you get into the, wow, they… Even just the little things go a long ways even when you’re a small team and it matters. And Miz hit on a couple really interesting points that we try to still continue to iterate on as we get into, I guess, phase three, is, there are certain things where we’re looking for efficiencies and to optimize and saying where can we be more efficient with tools like a text expander of like little safe snippets versus rewriting the email every time and spending five minutes when you’re writing the same thing of like, “Hey, can I take my sensor into a sauna or a spa?” That is very kind of cut and dry, us getting more efficient on that.

Chris Jones (11:40):

But there’re also areas where we want the team to slow down and make sure that we are still human and we’re listening to the customers. And this isn’t just like trying to be a human chatbot where it’s like how fast can we answer the tickets and how quickly can we solve it? But saying, “Let’s take the extra time to know our members.” We have a very large percentage of our member base that interact with support. And a piece that I keep reminding the team and people as we’re looking to grow it is we are an extension of the product. This is not an afterthought of support around how do you get costs down low from a line item on a COGS stand sheet, this is an investment in the end to end service offering. It is just as important.

Chris Jones (12:24):

And a lot of the lessons, I think, where I really first, probably felt that was running up a lot of support at Nest, where people like Tony Fadell would actually say, “How every word in an FAQ, every kind of thing how we show up is a reflection of the brand and of the product and product experience.” And when you are putting products in your homes where it might be life and death, does your smoke alarm go off? Does your heat come on in the middle of a cold front? That matters. Lives can be on the line. And to have our frontline people remember that of like there could be a baby crying that’s in a cold house and there could have a smoke alarm that’s going off. That type of empathy.

Chris Jones (13:03):

And similar with people. Like, we’re asking them to put a device in their skin, or they get worried of, “Hey, I have a reading. Should I go to the hospital, see a doctor?” Your health and your information is very personal. And we need to make sure that the team is, they’re able to automate the things where we’re not adding value and spend more times on the things that are by listening to the members and actually taking a pause, and not just see how quickly can I work the queue and get through it.

Michael Mizrahi (13:30):

Yeah. You touched on some really good points there about keeping perspective in mind and just being human around all of this. This isn’t about ruthless optimization of metrics and service level agreements and hitting the targets. Because like, we could do that. Our structure would look very different and our results would also look very different. And we might save a few bucks, but it’s the wrong phase of the company to start over optimizing in those areas. And that’s not the brand and the relationship that we’re trying to build with our members. And so keeping the goals in mind is incredibly important, especially in this kind of industry and function where it’s probably easy to go overboard and do this the wrong way, so to speak.

Ben Grinnell (14:07):

Let’s challenge the one point that you made, Miz. So that being, at this phase, right? So the challenge is, to Chris’s point, there were some interesting experiments that he’s run and continues to run and it’s around latency, right? Like, how quickly we answer? One of the things that has surfaced time and time again is people will say, “Levels has unbelievable support. I feel so supported.” And then the opposite side is, “I know there’s a human on the other end, but it feels like I’m speaking to a robot” because it’s the dichotomy between being efficient and having snippets so that you’re not spending time… we’ll call it wasting time. You’re not wasting time on transactional things, i.e., what happens when my sensor is in sauna. Somebody says that line and we’ve got to snippet. That is a transactional thing where a snippet is great.

Ben Grynol (15:00):

But when somebody sends in something that you need to decipher the meaning, like what are they really asking here? And there might be three questions where the lead is somewhat buried and they want to know that somebody is being empathetic on the other end of that message. Whether that’s answered in five minutes or two hours, what you’ve found, and maybe you can touch on some of those things in the experiments is like, the satisfaction actually goes down when it gets really quick because it starts to feel too transactional.

Ben Grynol (15:28):

And so why don’t you go into some of those learnings because Miz, this is the challenge on what you had said is like, we pride ourselves in having unbelievable world class support. And there might never be a time where we want to get that transactional on making ops feel overly efficient or overly transactional. It’s just, where do we have the right process in the right place? And then the right human knowledge, like people who use discretion to say, “This is when we do this thing, and this is when we don’t do that thing.” So I don’t know, Chris, do you want to go into some of those experiments that you’ve run? Because they’re very, very interesting.

Chris Jones (16:02):

Sure. So when I came in phase 3.0, one of the metrics that the team was shooting for was to answer, I believe, 80% of inbound emails within an hour. And most times, they were exceeding that. I would look at the data and be like 95, or 95% of the emails within an hour. And I was like, “Wow, that is incredible.” And I thought about it for two things. One is, I was starting to model out how big a team do I need as Levels grows and doubles and triples and quadruples. And I was trying to figure out like, a year or two, three years from now, how big a support team do I need to maintain that? So one, there’s a little bit of a financial team size. And the other was, I had run a similar analysis at Nest where we were looking to shut down email because it was the lowest performing CSAT channel of all the ones.

Chris Jones (16:56):

And you’ve obviously probably seen a lot of companies shut down email when it’s like, “Oh, it doesn’t perform. Let’s just get rid of it.” I challenged that internally. I said, “Well, I don’t think it’s email as a channel that’s a problem. I think it’s how we treat the email channel in terms of how we staff it and how we…” It was more of a afterthought. So what I found in my analysis was, I didn’t see any change, this is at Nest, of the CSAT if you responded within five minutes, 15 minutes, an hour, all the way up to four hours. And then after that, I saw a slow decline of CSAT, like hour by hour, where I could now model. If I staff of a service level of 24 hours or 12 hours or six hours, it impacts to CSAT over time just by moving it up as more like text messaging versus email where we’ve trained the people email, you’re going to get a response in 24 to 48 hours. So people have a low expectation coming in.

Chris Jones (17:48):

So I had a little bit of data to back my theory. And what I asked the team is, let’s slow down. And I was trying to do two things. One, I wanted to know early where we were young, what was the right model for Levels? Maybe I had data from Nest, but maybe that didn’t apply here. So I wanted to test it as we’re in the experimentation phase to and for models going forward. So I asked the team to get out of the queue, go for a walk, go for a run, do some project time. And it was hard for them because they were getting used to a little bit of gamification.

Chris Jones (18:21):

Every week was like, “Can we beat last week’s score? We did 90%, now 92%, now 95%.” And it became almost like a game of whack-a-mole and Chuck E. Cheese, of like, boom, boom, boom, boom, where they were great, but they also had growth ambitions as people of like, “I want to help out on this project, but I feel anxiety at least stepping away from the queue for even 15 minutes” because they had this gamification of like, “I need to be in there for every email.”

Chris Jones (18:49):

So I’ve sold them for a couple things. One, job satisfaction of employees, allowing them more time to actually help out in other areas to add more value to the company, and seeing at what point are members going to start penalizing us for not being super fast? And we found it, as we took our foot off the gas or intentionally slowed down, we didn’t see a hit in CSAT at all. I mean, we had a number of weeks with the lowered service level of more like 80% in three hours of still 99%, which is great.

Chris Jones (19:21):

And there’s actually probably another round like, “All right. Should we do another round where we actually slow down even more to actually figure out where the floor is, of where do we actually start seeing a little bit of pain?” So it did a couple things. One, it allowed me if I can now scale with a much smaller team, knowing that I’m not solving for this super fast, I have to have people 24/7, 7 days a week, always on the queue, always there. So I don’t need an army of support specialists. It also allowed that team to be able to contribute more to the company, helping out on IRBs or projects or help desk.

Chris Jones (19:53):

So they’re growing and they’re adding more value and it increases their happiness, and it shows up in their daily work of just like, “Wow, I get to help members. But then I also get to do all this project work and still handle the queue.” Which, as Miz was talking about in phase two of 10 or 20, or 30, we are definitely usually averaging over a thousand emails a week with a team of six, spending half their time in the queue. So the equivalent of three FTEs is handling about a thousand emails a week, which is really effective and really efficient.

Michael Mizrahi (20:27):

So this is where Chris and I have a really good yin and yang, and it’s fun to play off of it. Because he’ll suggest these things and say, “Let’s push it even further. Let’s try delaying more hours.” And from the quantitative side, he might be right. CSAT probably won’t take a hit. We saw that changing the response times from within 15 minutes to changing it to within two hours, generally pretty steady. My hypothesis is that support from so many companies is already such a miserable experience that if we can respond well in two hours, we’re already doing exceptional. And in the 15 minutes is just like a complete wow.

Michael Mizrahi (21:01):

So the two hour zone is probably healthy. And we could probably get away with moving to the four hour, five hour zone. But then, qualitatively, thinking through the member experience here, if you just got a sensor and you’re really excited to put it on and something goes wrong and you have questions or you’re nervous, a quick response in those moments means the world. And you might still hit the, “Yes, I’m satisfied” if you get the response a few hours later because we solved your problem. And the question is like, “How did we do? Did we solve your problem? And it’s not good, okay, or Great.” So yes, we still might get those greats, but we know inaudible 00:21:34] qualitative just by being users of the product ourself and just hearing people’s stories that there are times and places where being quick and being responsive really does make a difference.

Michael Mizrahi (21:46):

That’s why we have weekend support. That’s why we’re mindful of our hours. And so there’s a healthy balance here of just using good judgment and not only going off of the data, and that’s where we get some good play back and forth. What I’ll say though, is that there are interactions that need to happen and there are actions that don’t need to happen. And so we want to automate and remove as many as possible of the interactions that just are unnecessary for the member and for us.

Michael Mizrahi (22:12):

How do I reset my password? How do I change my shipping date? All these either FAQs or transactional things that we can very easily build into the product through a setting on your profile page, export my data, delete my account, whatever it might be, that should all be self-service. And we should get rid of all of those contexts and really spend the time interacting with members where there’s deep questions, understanding, community building opportunities, product feedback that we’re getting and going back and forth on. That’s where we want to spend the time.

Michael Mizrahi (22:40):

And if the acute issues can be well handled quickly, self-service, that’s a win-win for everyone. And so that’s really the mindset and philosophy on scaling here. It’s not just like keep up with everything. It’s keep up with the right things, get rid of the wrong things.

Chris Jones (22:55):

I absolutely agree. I do love the yin and yang of Miz and I bouncing ideas and coming with different perspectives and whether it be data hypothesis. And I think it makes both of us landing in a pretty good spot because we’re all hearing different perspectives around like why we’re pitching something and different points of view. And related to that is one thing we talked about around are we providing a great world class experience? This is another topic we’ve been talking about is, which channels do we offer? Miz talked about early on doing SMS, email. There was a phone number, but Miz, correct me if I’m wrong, that wasn’t a live call that more created a voicemail into an inbox. Is that correct?

Michael Mizrahi (23:36):

That’s where it ended up. I think at one point, we did give out our direct cell phone numbers.

Chris Jones (23:41):

Oh, gotcha.

Michael Mizrahi (23:41):

Yeah. But the number in the email, I think, went to a voicemail. Maybe ring everyone’s phone. But we’re talking early, early days. I think that eventually got turned off.

Chris Jones (23:49):

This is one that comes up a little bit where we talk, as people who follow our podcast are very much aware of Levels as an asynchronous work culture. Time for deep work, time for projects, times for memos, and work when it works best for you. Definitely I’m trying to lean into that as much as possible as we think about our support channels. Are most of our support channels asynchronous? Social media, email, channels like SMS, where we can be efficient, we can be effective and still be pretty timely. Like, are we able to get back within an hour or two where you’re not waiting all day long? But we have got some pushback from our members around, I want to talk to someone, where’s your phone number? I don’t have live chat.

Chris Jones (24:31):

And this is another area where I’ve done some modeling to say, if we do the… you’re going to have a phone number of the… you need to answer this, make calls within five minutes or whatever typical SLA you want for call, I would have to triple the size of our team and continue that growth rate to unlock synchronous channels because they’re so inefficient by nature. It would be a common week. It was common every week at Nest. Someone in the call center would have a four plus hour call with a member, because you can imagine someone trying to install a thermostat and, “Oh, well, go downstairs, turn off your breaker, come back upstairs. Okay. Well now, take the thing off the wall and unscrew it.”

Chris Jones (25:15):

You’re basically providing over the phone HVAC support. So in that environment, phone was absolutely very critical to the product because you’re asking people to hook up wiring and powering. And a lot of our tickets today are, you don’t necessarily need that synchronous. Like, “Hey, why did I get this spike? I had the same meal five times and now a different score. Can you help me understand why? I’m getting pretty quick.” There may be a time where we do say, “Do we actually need some of these synchronous channels because of the nature of those types of calls really require it?”

Chris Jones (25:48):

So even though we have all agreed to work asynchronous when we signed up for Levels as an employee, that doesn’t mean our members have signed up for that same type of experience. So this is another experiment of like, I really want to try to lean into asynchronous as a channel as long as we can say, “Can we still deliver a world class experience doing it?” Versus just saying, “Well, everyone has a phone. Everyone has live chat. Everyone has these channels. And they have it in every language, 24/7. And now we’re having 15 call centers around the world in every language. And people are sitting there waiting for the phone to ring on an eight hour shift and don’t talk to anyone.” I’ve been in those shifts. It’s not fun to be on a graveyard shift when they’re like, “Yeah, no one called today.”

Michael Mizrahi (26:30):

Like I said, this brings up a lot of memories from my time at Uber, when we were launching phone support. And boy, what a process it was to actually turn on the phones. Different kind of business, right? So there’s a lot of real time issues that happen where someone gets into a crash or there’s an incident. And people want to be able to pick up the phone and talk to someone. And it’s not even about the fact that whether or not we can do something, it’s just having someone to call matters so much for trust and for just the relationship in general. But yeah, it’s very, very hard for large organizations to turn on phone support because it’s very, very difficult to plan for, to capacity plan for and to manage. And if you get it wrong, it’s extra painful. You have these stories of leaving people on hold, of not knowing how to solve a problem in the moment, right?

Michael Mizrahi (27:15):

The agent can’t really ask for help. They’ve got to solve it in the moment. Otherwise, you’re putting people on endless hold. You’ve got phone trees. You need a way to verify the customer, because they’re just calling up a random number and saying who they are. So you have the whole, like your customer verification processes. What a process. So I think in our context, quick, fast, timely support that’s actually thorough and helpful can take care of 95% of this. And then there’s a remainder that we have to figure out how to be exceptional on. But for the most part, if you’re great and quick and consistent and actually helpful over email, you can handle most of your cases.

Ben Grynol (27:51):

So let’s go deep into the idea of… I mean, we’re a startup and we’re developing things as we go. It’s inevitable that it will continue to evolve. But there isn’t really a playbook for startups, right? Whether you’re a SaaS company, it depends on the level of support and the type of product. As you said, the latency needed for… Let’s use the example of a driver gets into a crash. I mean that’s existential. They need to talk to somebody. And so the phone is the quickest way, the lowest latency way of getting someone on the phone of what to do next. But assume a company is a startup where you are thinking about ops and the way that companies can design things. You’re thinking through like, should we have chat? Should we have phone? Should we have email? Should we have SMS? Should we support digital platforms, as far as like engaging and answering questions there?

Ben Grynol (28:42):

If each of you are thinking through… What would be, I guess, some advice or some takeaways for people who have startups, who are building startups right now and they’re sort of questioning like, “Should we do that, or shouldn’t we?” What’s your outlook on, like do you minimize to one channel? Do you focus on the one that gives the most value? Let’s go to the extreme. Maybe phone is actually the most valuable channel for the type of business someone’s building. And you’re like, “We’re not doing email.” That’s probably not realistic. But, “We’re not doing email. We’re doubling down on phone. And here’s the number.” What sort of each of your outlook on giving advice to startups that might be thinking through building out their ops info right now?

Chris Jones (29:23):

Oh, oh boy.

Ben Grynol (29:24):

On the spot, Chris Jones. On the spot.

Chris Jones (29:28):

I don’t want to use the default of it depends. But I would say try them all. Because it’s one thing to say, “Oh, I watched this podcast and here’s what Levels does. So I’m going to do that.” Or, “Here’s what Amazon does. I’m going to follow that.” What I found is, every company I’ve worked for, even the companies that feel like the same size, the support experience is unique and special and how they treat it and the value they get and how it drives the business. So there’s a little of having to know of what’s the most important thing for your business? Is it that product feedback? Is it quickly finding bugs and errors as that flywheel? Or is it just, hey, we want to use this as a marketing thing of like, hey, you have someone the white glove service and that’s really part of your product offering?

Chris Jones (30:15):

So I would say try it. I mean, just as Miz said, “Hey, we put a phone number out there. We tried SMS.” Or you do experiment. I mean, Miz can probably talk to this one around. When you have an email form versus like a live chat form side by side, which ones do your members use? Is there a different type of question? I know we saw this within Nest as we had all of them. It depended upon which channel drove a very different top driver’s list. So you can imagine people where it’s like, “I have an order question in order [inaudible 00:30:45].” Email, email, email. People were like, “Here’s my tracking number. Where’s my product? Or where’s my refund?”

Chris Jones (30:51):

If it’s I’m installing something? Phone. So now you’re going, if you only went one channel, you may never like, “Oh, I didn’t realize people can install this product because we never offered that.” So I would lean into, while you’re small, doing experiments and to a point where it’s like, whether it’s Mike or Dave or whoever, like yeah, it’s the head of product taking these calls in and you’re learning what was valuable, what was not. So I’d lean into the experimentation culture and really just figure out what works best for your company. I don’t claim that there is a right path or a wrong path, but there’s a what’s right for you.

Michael Mizrahi (31:26):

And I agree with Chris in the experimentation side. I’d say it really depends on phase. I would start wide at first just to figure out the basics in very early stages. And then, I think my position and advice would just be like simplify as much as possible, get really, really good at one channel. And then once you build out the processes, once you have a plan for how you’re going to team members and actually keep up with the volume and understand what issues come up, where you have escalations, maybe you have a business that has a lot of fraud and chargebacks, and that becomes a big function that you need to build out. Spreading that out over channels becomes really messy. At least I’ve seen from some peers and companies I’ve helped out along the way.

Michael Mizrahi (32:08):

And so simplifying as much as possible so that the processes are crystal clear that everyone knows how to handle everything. And then you can experiment with turning on some of these other channels once you have some confidence that you can handle it, and that your members or customers are asking for it. We, somewhere along the way, turned on chat within the app. So we used Help Scout, and Help Scout has a in app beacon where you can read the articles. You can then have an option to get in touch and you can either send an email or start a live chat if someone was online. And we found that the live chat actually wasn’t heavily utilized. And when it was, those are things that could have been ending up in emails anyways. And a lot of the times, the chat gets abandoned and becomes an email conversation regardless.

Michael Mizrahi (32:48):

And so it didn’t make sense to keep staffing for real time chat because you do have to respond within a minute if someone opening a chat, which is very different from getting an email and you can respond in five minutes. And so the demands on the team are just so different. Almost every platform today in the customer service base is going to give you this multichannel, omnichannel, every single way to get in touch with us. We’ll pull in your Twitter mentions, your Facebook, mentions your Instagram DMs, your in-app chat, your web beacon chat, your email, your phone, keeping up with that is I think very, very difficult from a process standpoint, from a training standpoint and just kind of like a quality perspective.

Michael Mizrahi (33:25):

So yes, find the channel that works for you and then stick to it and then you can layer on. But I think simplifying process and actually focusing on solving members’ problems or customers’ problems is the priority, and finding the best channel to solve those problems consistently and then moving from there. So we’re somewhere along that route. We’ve landed on email for now, but we get DM for Instagram, like how much do we support there? At some level, you have to be visible. We can’t just close the DMs and not answer any Twitter mentions. There’s some level of engagement that’s important. Bucketing support specifically, if we’re talking about account issues or order issues, funneling those to the same place that they’re tracked and measured and follow consistent process is super important.

Ben Grynol (34:06):

Yeah. There’s nothing more anxiety inducing than… Whether you’re big or small. But if you’re small, let’s assume small is two people doing support at a startup, and you’ve got all these channels open, and it’s just like a fire hose of information, ding, ding, ding. And you’re trying to be focused, but you can’t because it’s being reactive. And where it gets really challenging is when you need to triage information in the future. Right? Where did I answer Billy’s question? Was that on an Instagram DM? Was that on…

Ben Grynol (34:40):

Not having a centralized place where it becomes a source of truth, right? And knowing, and training. That’s a big thing too when you start to get into volume. Like a lot of volume coming in, training everybody who is on the front lines of support to say, “When you get questions through channels that are not the centralized source of truth that have to do with things like order status that have to do with things with customer information, politely redirecting that to, ‘we want to support you. Can you please email this channel so that we can make sure that it is tracked and that the loop is closed on it?’”

Ben Grynol (35:18):

Otherwise, you get these open-ended things where people get more irate as much as that can cause tension. Sometimes, it can cause people to be more irate where they’re like, “Wait, I was in the middle of this DM and you stopped because you had to go to some other thing because you’ve got too many channels going.” So it’s one of those tensions that is really hard to solve. But knowing that you are supporting people in enough channels, but not so many when you’re small, that it’s like you’re causing your own internal inefficiencies, if we want to call it that. We should dive into one thing here, which is this idea of 3.0, so that’s when Chris came in, that’s when we started getting more rigor around reporting, analytics, doing weekly deep dives on everything happening in ops.

Ben Grynol (36:07):

And this 4.0 is this idea of starting to operationalize everything that happens on digital and bringing it under ops because, digital… let’s define digital that being like any social platform where we have a presence. We’ve got enough volume of inbound comments and information that they’re not just the thumbs up like, plus one, I love this thing. They’re like these deep, meaningful things saying, “I have a question about either metabolic health or my sensor” or, or, or. And if that’s not supported, that can be a really poor customer experience. So we’re just, at this point, we’re starting to operationalize that as this channel that everything is aggregated and then it lives under the pillar of ops so that the support is there. So why don’t we go into this idea of like 4.0 and why we’re currently doing this because the volume, without a doubt, it exists on a daily basis?

Chris Jones (36:57):

I mean, I’d mentioned earlier, let’s say we’re getting a thousand emails a week. Sometimes our volume from social channels can actually be higher than that. So your point of like, email might be our primary channel, but as we put more content out there, we are naturally causing more people to be talking about us on multiple platforms. So you brought up a couple things. One, we want to make sure we’re staffing it with people that are knowledgeable to be able to help people. It’s not the, “Hey, let’s hire someone that is just as social for more of a engagement,” but more of people that can really help answer people’s problems as the type of person we put behind the DMs.

Chris Jones (37:34):

Two, we also looked at, from an experimentation, what type of tools should we use? And there was some experimentation of someone like Mercy might say, “Oh, I’m glad to going to log into Instagram, into Facebook, into Twitter, into YouTube” because the native experience that she was responding or what she could do with it might be better. But then Matt say, “Well, let’s experiment the tool more like Sprout Social.” If we bring that all into one central place like we did with Help Scout, does that provide more efficiency, more analytics, more ability for us to see easier what’s going on?

Chris Jones (38:06):

And we’re landing sometimes in the middle. There sometimes are areas where the native tool allows a richer conversation around that person can do on that platform, bells and whistles, than what they can’t do by having it all in one place. So today, we don’t bring social media and DMs into Help Scout. We could. There’s likely an integration. We said, “We want to have all of our data in one place.” But we’re like, is that really the best thing for our members in the conversation? And is it really going to be a better experience? Or is it like, yeah, now we’re solving for just… having all data at one place and we’ve actually watered down the experience?

Chris Jones (38:40):

So as people go through it, you’re always trying to balance the efficiency, the experience, what each tool can do. But for us, I mean, Ben, as you know, social is a big lever force and we get a lot of volume. And sometimes, definitely from a DM, we want to make sure we are staffing that when someone’s reaching out of like, “Hey Levels, I have a question.” We want to treat that just like we do our email channels from an SLA. Now you get into where someone mentions us. They’re not DMing us, but to what degree do we amplify the conversation or respond to it? This happens a lot on our Facebook group. People are asking questions around like, “Hey, can I take my sensor in the sauna?” And this is a little bit of an experiment for us where we say, “Well, to what degree does the community actually help each other out?”

Chris Jones (39:25):

So what we actually find is most times, it’s not a bunch of questions that we say, hey, are going unanswered, but it’s other members helping other members of that flywheel of like, “Wow, this actually is a great source of knowledge where maybe I don’t have to have a team that’s always checking every post in Facebook and answering just like they would at DM. The community is self solving.” So it is interesting that experiment of like, to what degree are these micro communities, whether it be on Instagram or on YouTube or on Facebook, are they helping each other out? Which is really where we would love to get because that’s a lot more leverage of members helping members. But sometimes, we need to be there as a backstop if it’s not happening.

Chris Jones (40:04):

If there’s a lot of questions coming up on whatever platform and people are going, “Hey, I still have this question and no one’s helping me,” we do need to lean into that to make sure they’re getting the help that they need.

Ben Grynol (40:13):

For providing some context on it. And this is a bit anomalous, but on YouTube alone, on that one David Perlmutter video, the one that Dr. Pete and Casey did, as of right now, there are 907 comments on it. So you go, “Cool.” Let’s imagine the scenario where in some startups, depending on the volume, the digital team, whomever is in charge of social or digital, will take care of the engagement. They care of the creation, the distribution, the analytics, the engagement. But when you’re talking about a thousand support emails a week and a thousand will assume every comment was something where someone had a question, a thousand pieces of information coming in through one piece of content, not one platform, a single piece of content on one platform, and we’re on Twitter, and we’re on Instagram, and we’re on Facebook, and, and, and.

Ben Grynol (41:06):

Yeah. It’s just like, all of a sudden, you go, “Oh my goodness.” That’s the back to where we started the conversation, exercising the option to say we really have to operationalize this thing because this is unsustainable for one person to work through. And we want to make sure that we’re answering people’s questions. If they truly have questions, we are engaging with them.

Michael Mizrahi (41:27):

The pointing that Chris made earlier that’s worth boosting is the over optimization that some of these ops and support teams can sometimes get into by insisting that everything is in the exact same tool and everything’s categorized correctly. And then you ask like, “Okay, so what? What are you doing with this data? What decisions are you making? What processes are you changing?” And oftentimes, there’s actually not a lot of action items that come out of it. And the amount of work that goes in to forcing standardization, to forcing process that doesn’t provide any real value or return is just painful to watch.

Michael Mizrahi (41:58):

And so being flexible, being loose, like yes, this volume data might be extremely valuable in 10 years from now. But so is our members’ experience, and so is our team’s experience in handling these issues. And so let’s just solve for the problems we have and not try to boil the ocean with what all the things we could do, but probably won’t.

Chris Jones (42:16):

Yeah. The number of war stories I’ve been a part of, of being part of a large company that’s trying to standardize on some type of platform, whether it be a CRM or some type of system, and then you’re like, “Did we just spend six months arguing what the definition of a customer is?” Because one business unit is B2C, the other one is B2B, and they can’t agree around like, “Oh, I might have one customer with several contacts below it” versus like, “Well, I’m talking to Bob and Mary who are individual people buying our software.” And I’m just like, to your point, going, “Why are we even doing this?” Versus like, “Oh, well, some executive says we should have all of our data in a single spot because it’ll enable better tracking, better 360 who uses all of our products.” I’m like, “Are you really solving for an edge case of that 0.01% of someone that happens to be a business owner and an end customer using multiple products from us because we’re tons of brands and products?”

Chris Jones (43:11):

And then just the amount of internal effort that goes just to get that thing up and running, to actually be in a worse spot. You’re like, well, now we’re migrating to the mean where all those cool features you had for a B2B versus a B2C, all go away. And I saw some of that, I’d say a lot of that, at Google, where they build very scalable solutions. As Miz mentioned Uber. They’re probably sitting with 20,000 agents across all these vendors. So for them, they’re all in one tool and they think about scale all the time. It’s what they do. Of like, will this product support a billion users? That’s just how their mind works.

Chris Jones (43:47):

So when we were coming in from Nest, of a highly customized interface around, our agents could see the settings you had in your Nest thermostat to be like, the reason why your HVAC is not coming on is because you didn’t set it to hot versus cold. And I can actually see your config settings with proper sharing permissions and opting in to, respect privacy, but the agent’s ability to really troubleshoot that because it can help them and see what they’re seeing versus of like, “No, the big central tool doesn’t support that level of customization, therefore you have to ask the customer all this data, and that’s why the calls can take four or five or six hours,” versus some of the context that, “Can you provide context to the frontline around what do you know about this member?”

Chris Jones (44:28):

Obviously, you don’t want to be creeping and want to respect their privacy, but do you know where they’re coming from? If they’re coming from within your app, do you know what page they’re on? So you can anticipate of like, “Oh, you’re coming from the my data page. I can almost likely guess what you’re going to ask me before you even ask the question, just based upon where you came from.” Like a referral URL of like, “Hey, which podcast is driving the most volume to our support.” That tells you a lot about that person’s coming in and their intent. Same thing with where they’re at in your product experience of like, what can I infer and tee up or even offer tailor the self-service to be more personalized based upon what you know around what they’re likely trying to solve.

Michael Mizrahi (45:05):

Or secret context machines today that are able to do that, or the exceptional people that have joined our team to be the front lines and to connect all those dots and to understand how everything works. And we can do that really well with the team of, let’s say, whatever we have, six to eight people. The ability to do that with 20,000 agents gets so much harder. And that’s where you need to build context and present that all to the person responding so they can understand what they’re doing and understand what they’re looking at. We spent two plus years at Uber building our own support ticketing tool to replace what we were using previously, Zendesk, so that members from the app could select this specific trip, say I had an issue with this trip, submit an issue.

Michael Mizrahi (45:47):

And then the agent has the trip pulled up already, has the fair, has the charge information, has the chat UI or the messaging UI right in the center, and can actually solve that problem that’s directly in front of them, versus have to figure out which trip are you talking about? There were two at 4:00 PM. Was it this one or that one? And all of that work that makes customer service so miserable, you can solve those problems, but it requires that you then put the work onto the rider, the customer, the member to select the exact issue correctly. And when that goes wrong, it breaks the whole system. And so our secret power today are exceptional people who are really smart and talented and really good and empathetic and can connect all the dots. Someone’s writing in from a Yahoo address, but they can’t find their account, search the name on the Gmail address. Like try and connect the dots and just be really, really proactive. And great people are what led us do that today?

Chris Jones (46:38):

I fully agree. And one thing to add to that is, where you can, hire people that are just as passionate about the product or the service you’re building as the rest of the team. So everyone that joins Levels is like, “Oh, I love your mission.” And the amount of people that are applying for the current opening job, they’re like, “How do I be part of this team? I have been following you guys. I’ve listened to every podcast.” You want brand ambassadors on your team that are pushing your brand forward and advocating because they really believe in what you’re doing, versus just, “Oh, let me go find someone who’s really good at support, and can find an FAQ, who can navigate tools.”

Chris Jones (47:14):

They’re going to work the queue good, and they’re going to do a good job and they’re likely going to get good CSAT, but it’s the harder problems, or the… Eventually, it’s like, they’re going to say this is a job. It’s going to be like flipping burgers. Like yeah, I’ve seen that case over and over again. You want people that want to make the product better, make the experience better, make the tools better because they feel part of it. And that becomes harder as Miz and I have found out.

Chris Jones (47:36):

When you start scaling towards, especially when you’re bring in a BPO vendor and scaling, I’m going to generalize, most of them like, this is a job. And show me the FAQ, show me the steps, I will repeat it and follow up policies and follow up procedures. And all I call BPOs are very good at, if you have a process, they will follow it to the T. But their ability to go above and beyond or to think what else can I do and go and really connect with that member is more of an edge case. It doesn’t happen nearly as often. They’re almost lightweight chatbots of like… They are like decision tree. If this, then this, do this. And they are very good at that.

Chris Jones (48:14):

So if you have a mature business where it is a very repeatable process and there is a step and you’re not to waiver from the step, that is a great time when you want to say, is a BPO willing to go? Where it’s like, “I can’t really automate this. I need to do with humans, but I’m trying to keep the cost fairly low.”

Michael Mizrahi (48:30):

One subtle point that’s worth adding here is that this isn’t to say that we don’t build a process and we don’t improve things along the way. But when you have people building process that understand the issues deeply and can be empathetic and understand the complexity and have seen the issue dozens and dozens of times, the process that that person will build to automate or fix this problem will be very, very different from the smartest analyst coming in, looking at the problem and trying to solve it. And so there’s value in hiring correctly and building the right culture and focus of the team. Because the processes that you build when you do have to scale will be better ones that better serve your members and that better serve the company and the brand and the product. And so that’s why that matters, particularly.

Chris Jones (49:17):

Another way I’m thinking about from context for helping is, a couple of examples I’ve seen in practice when I was at TurboTax. Most of their call centers were overseas. People that had never filed taxes in their life. So when you’re throwing terms like, “Oh, I have a small business, I’ve got a 1099, I’ve got a W-2, I’ve got an S Corp and a C Corp,” you are getting people going, you have to arm them with the data because they’re going I can’t empathize with what it’s like to file taxes and the fact of fed and state and the timing and the anxiety around do you have to… The difference of owing money versus a refund can really be like, oh my God, this is the best service ever, to like, I don’t have that money. This anxiety around something like that. Or even at Nest, when we started going more nearshore, a lot of people going, “Yeah, I don’t have an HVAC.” I don’t know the concept of these tools. I have a mini split.

Chris Jones (50:09):

It’s harder for them to wrap their heads around what is the member going through. So to a degree, people that you’re hiring, that… I mean, one, obviously at Levels, we have everyone using the product to the degree that we can. That way, they can be like, “Oh, I had that same issue. I know what you’re going through when you ran into that.” And they can really have that deep empathy be of like, “I got that loss and I know how I felt when I got it. I can just imagine what you’re going through.” Versus it being like, “Yeah, I don’t know what you’re talking about like a low reading. I don’t know what you’re experiencing. I can just read this FAQ.”

Chris Jones (50:39):

So you don’t always have that. But to a degree, that you can hire teams that really relate to the product and service you’re doing because of, “Yeah, I’ve got smart home devices.” So when you’re talking about, “Hey, the Bluetooth drops,” you’re like “Yeah, I can relate to that.” And be more empathetic with better solutions.

Ben Grynol (50:55):

Have the high EQ. We don’t need some robotic algorithm just taking care of everything because you’re going to get back the answers that might not be helpful in that case. And so you leave what could have been a positive or a neutral interaction is very quickly turned into a negative touchpoint. And luckily with people who really care about the work that they put out, we’ve got people on the support team that have turned a lot of these, we’ll call it, sore spots for interactions or some of the negative interactions where people felt like they weren’t supported in the answers they were given. And they flipped them where it went from, “I was very dissatisfied to Miz, or Jessie, or Braden, or Sonny, or Brittany.” The best I’ve ever… like, just so positive and elated over the service. So it’s great to see that, but that really shows the value of having that personal touchpoint where it’s, “Hey, we’re here to help you. We really do want to help you.”

Ben Grynol (51:57):

And people understand that when… Because there’s almost this apologetic nature where we don’t keep hammering… Like people have that EQ where they look at the response, they say, “I don’t feel that I’m solving this for this person, so I’m going to figure out how to solve it.” And even though we don’t have phone, and sometimes maybe having a phone in that case would help to resolve that where they can hear the human on the other end. But somehow, we managed to do it through text based communication, or even, actually I shouldn’t say that, through, Flanigan did it the other day where he used a loom, right?

Chris Jones (52:29):

Yeah. Totally.

Ben Grynol (52:29):

Like, “Hey there, this is a human on the other end of this thing. Here’s a video. Here’s the sentiment.” And I think just the way that we’re always pushing these tools to flex in the ways that they’re needed, allow us to give that support in a very different and meaningful way. So we’ll see how we can scale all this as we continue to grow.

Michael Mizrahi (52:47):

That is the magic question. How do you scale it?