3 Reasons You Need Support Ops to Scale and How to Really Build It with Stripe and Assembled

Bob from Stripe explains why support operations teams matter as companies scale. Stripe started with every employee handling tickets, then built dedicated SupportOps to handle forecasting, metrics, and tooling. The three essential KPIs are customer satisfaction, SLA adherence, and contact rate efficiency.
Questions this video answers
Bob says the most important KPIs depend on company strategy, but generally: 1) Customer satisfaction measured via CSAT or NPS, 2) SLA adherence – first‑response and resolution time targets, 3) Efficiency measured by contact rate (cases per active user), which reflects long‑term product health and operational efficiency.
Chapters
Hi everyone, good morning. My name is Jen and I run sales and customer success here at Assemble. We help fast-growing teams scale their support by providing forecasting for their volume and their headcount. We help them with their scheduling and improving agent productivity. We're lucky to partner with some of the most progressive support organizations in the world, like companies like Stripe, Notion, Harry's, and Looker, all use Assemble. Now, before we get into this talk, I just wanted to get a sense from the room, how many of you all have heard about SupportOps before signing up for this talk? That's half heard of it, yes, okay. That's good, like, we'll definitely like, would want to like, chat about this afterwards. But one of the things that we've like, heard from like, other folks is when we talk about SupportOps, they're like, not sure what exactly it is. And it's true, it's not as established as something like sales ops or marketing ops or revenue ops. And that's something that we're hoping to change because the best support organizations in the world invest in this early. And speaking of the best organizations, we have Bob, Head of Operations from Stripe, joining us today to share his early journey in starting out support ops. And in transforming Stripe's customer support. And in case you don't know what Stripe is, Stripe is building the payments infrastructure of the internet. Millions of businesses around the world, ranging from startups to Fortune 500s, use Stripe software and API to accept payments, send out payouts, and also manage their businesses online. And Bob actually joined Stripe in 2015 to start support operations. And he was promoted to run all of operations in 2017, and now he looks after all of operations. And full disclosure, I actually worked at Stripe before. Bob was my manager there, and I learned everything I know about Support and SupportOps from him, so I'm really excited to have this session to interview him and ask him more about SupportOps. Thanks for having us today, Bob.
Thanks so much for having me, and I'm looking forward to chat.
Yeah, so I guess the first question I have is, how does Stripe think about support?
Yeah, I mean, from the kind of very early days of Stripe, right, like when the product wasn't even kind of fully fleshed out and there was just a few employees, the customer experience was always a huge priority. And there's all kinds of stories of like our founders actually kind of going to the physical location of the first users of Stripe to help them with their integration and then have set up like 24/7 pagers to offer support and advise them on a lot more than just kind of Stripe in general, but like give them advice on their website or anything else that might be helpful. So it's been ingrained in our culture. And that's not only the case because it, you know, it's kind of like started like that from our founders. It also makes a really good kind of business sense for Stripe, right? Like for those of you who are familiar with Stripe, right, like our core business model, we obviously take kind of a percentage of the payment volume that is handled through Stripe. And therefore our incentives are really well aligned with our customers because if If they are growing their business on Stripe, like Stripe will grow with them, right? And if you look at some of our largest customers, they actually started when they were quite small. They started on Stripe when they were quite small and they've really grown on Stripe ever since. So given that, in that light, it's kind of from both from a cultural perspective as well from kind of a pure business model perspective, it's an area that we care a lot about and that we're really willing to invest in. And that was already the case when I joined Stripe and even before I did. And that's certainly still the case today.
So let's kind of go back to the circumstances that led to the creation of Support Ops. What was the situation at Stripe like back then? And how did this team form?
Yeah, so I kind of mentioned the very early days where everybody was doing support. But that was actually for quite a while. Everybody at the company, you know, irrespective of their focus, whether they were engineers or in, you know, business development or anything else, they were supporting our customers. And it was kind of a shared expectation for the whole company. Now there's a lot of benefits to that, as you can imagine, right? Like it makes sure that everyone continues to understand the product really well. Everyone is aware of like pain points with the product. This is like direct connection with customers. But as you can imagine, it also has like downsides, as like, you know, it's, it's nobody's day job. And because of that, it's hard to kind of plan for how many people are going to need and, and things like that. So kind of that model, we start to outgrow that kind of before I joined. So by the time that I joined the company, there was already a small support team kind of, you know, who, who really task to support our customers. But what didn't really exist was anything else, right? So we had like a group of people who were spending their whole day supporting customers and talking to customers and, you know, trying to help them with their issues. But what we realized was that, you know, they were actually so busy because Stripe was obviously going through a lot of growth and, you know, our customer base was expanding that it was hard to combine that kind of active day-to-day support with, you know, kind of developing the strategy of support and the programs of the support model. And that's really where kind of the need for something like SupportOps became very apparent because, you know, like if everybody was kind of doing support directly, then nobody else was actually planning for what was needed in the future.
And I want to just rewind a little bit to something you had mentioned, like how back in the early days where support was everyone's job. I remember digging this up in Twitter and Christina Cordova, one of the early Stripes, had actually tweeted about this, where she had talked about how 7 years ago Stripe had this crazy support ticket backlog and they scheduled a hackathon at Patrick and John's house. And all the employees of Stripe back then went there and worked through it over the weekend. And I think she even posted this photo. Which is like everyone there with their laptops and answering support tickets.
Right. Yeah.
That's kind of like going back— Go ahead, Bob. Oh, I was going to say, it sounds like essentially, basically the volume and the growth at Stripe was growing a lot and the team, you had a dedicated support team, but then they're the people responding to customers. They didn't have the bandwidth necessarily to think through, like, how do we exactly, like, scale support and build the processes and the things that you had in place. So I guess when you were— well, do you remember, like, the moment when you were, like, asked to kind of, like, build the support ops? Because I think you were joining Stripe in, like, a slightly different role, still in the support organization, but then your role suddenly expanded and shifted. Can you share a little bit more about that one?
Sure, yeah, I was actually like kind of initially focusing mostly on like partner management, working with some of the partners that Stripe is using. And there was kind of like a company-wide project being kicked off around our sports strategy where product was involved. And we had a small kind of central Biz Ops team that was helping out with that. But yeah, I mean, I was actually like in the San Francisco office, the office that we had at the time in the Pioneer office in the Mission. In the Mission. Right. And Claire, who is our COO and still actually my boss, she— yeah, she— we were in like a meeting, we were discussing kind of the forecast and metrics, et cetera. And like, she pulled me aside at the end and saying like, can you help, right? Can you do some planning in terms of looking beyond what's kind of in the next few weeks, but really help with forecasting what we're going to need, let's say a few months from now and beyond. And, you know, I think that's kind of muscled what hadn't been built yet at Stripe, right? So like we were quite reactive in terms of volume growth and user growth. And I think the, you know, the team did a really good job of keeping up with that growth over the years, but it was clear that we were kind of as part of our growing pains, we're getting to a stage where we really have to be a lot more proactive. And I actually do remember the exact conversation that happened there of like, can you help build what is pretty much the— what we're calling Support Ops here.
So how did you build it out? Like, how did you think about what types of functions or what roles was needed in Support Ops?
Yeah, I mean, there's obviously a few steps there. I think the kind of— there were a couple of immediate problems that were very clear, and specifically about capacity and planning, right? So the kind of first thing that we started to do was to really focus on forecasting our support volumes based on historical trends and seasonality, user growth, right? And formulate things like contact rate, right? Like if you know how many users we have and you know how often each, or like let's say 100 users contact you, you can kind of extrapolate like what a support volume forecast would look like if you're hitting certain user growth targets. So forecasting was one. The other thing was success metrics, right? Like we at the time didn't really have good success metrics. Like we, I think we actually did delivered good support, but we weren't able to prove that we did, right? Like, it was a lot of anecdotal feedback. Like, we didn't, you know, send our customers a CSAT survey. We didn't really have a lot of operating metrics around how fast we responded or what the turnaround time was or how many people it took to resolve issues, etc. So, you know, in addition to forecasting and capacity planning, one big priority was to come up with better metrics and to actually set the baseline for like, well, how well are we doing today? And like, What does success actually look like, right? Like, where do we want to go to and what would be needed there? So reporting and metrics became a kind of a fast follow second area. And then in addition to that, like, there, yeah, there were like a lot of— sorry, go ahead, Jen.
Oh, I was just going to say, just kind of like pause on that one. Like, I think this like helped me see like the parallel with like sales, like with like sales ops. Usually like the first sales ops hire is someone you have who like partners with like the head of sales and like just understanding metrics, right? Like what does the funnel look like? It's like really understand the levers on like what you measure. So it sounds, it's like pretty interesting that like on the support ops side, like that investment on metrics and like forecasting and planning, which is like the most critical step first, but continue in terms of like what were the other things that you like added in building out this team?
Sure, yes. So I mentioned forecasting, I mentioned the kind of metrics and reporting. Other areas of focus were tooling. So we, we actually did like a migration to a different CRM at the time, which gave us a lot more out-of-the-box functionality, which was desperately needed. And then knowledge, training, and quality were, were other areas where we felt really under-invested, right? Like for those of you familiar with Stripe, like it's quite complex in the sense that we, you know, we offer an API to our users and it's really just kind of like a box of Legos and everybody can build what they want with it. And then if they run into issues, right? Like we're there to help. So like there is a kind of endless permutations almost that we have to support. So getting really, Good internal documentation and training involved in each of these different areas was another important area.
And so I guess as you think about the hires that you made, I like noticed that you mostly hired for people, and I guess it's like using my own like knowledge in terms of like what happened then, but like most of them were like specialists. Like you had like Toby was like very focused on analytics, Nick on like workforce management, How do you think about like the hiring profile in terms of like building out support operations?
Yeah, I think it's kind of to your earlier point that, you know, I guess the big takeaway from my experience is like this is like building out support ops should be its own kind of intentional strategy. Right? And it's additional to building out your support team in terms of like the kind of core group of people who are talking to your customers every day. And why thinking about those two, they're obviously interrelated, but like why thinking of them as two different problems to solve is important is because the people who do well in either group might actually be you know, have a different skill set or have a different background, right? And I think a lot of companies, they, you know, they might hire really good customer-facing people for the support teams who, you know, know the product, they're very empathetic, they can work with customers. And, you know, that profile sounds great for a support team, right? But that's not always the skill set that you need for, you know, things like forecasting, capacity planning, metric development, etc., right? So I think the The other thing that many companies do is, is then kind of like expecting the, the team managers of the support team to do all of that work, right? So like the team members are working with customers and then like, well, the team managers can do kind of all the other planning. But similarly, the team managers might be folks who have been promoted from, you know, support ICs into management roles, or they, you know, are maybe very strong managers, but maybe don't really have the skill set in any of these deep areas. So I think what we try to do is to actually accept that, right? Like, hey, we're going to need different profile and skill sets for people to do this. And you can get quite far with, you know, the kind of generalist startup profile who, you know, who can kind of solve a lot of different problems. Who are analytical, high horsepower, et cetera. And, you know, generally there's quite a few of those type of people at startups. But the problem with that is that, you know, they might work on one of these problems for like a few months and then they're eager to move off to the next thing, right? And, you know, for instance, with forecasting, that's something that we started 6 years ago, but we're still working on, right? It's really kind of an ongoing problem. And these are not like one-off things that you need to do. So that's, I think, where we said, no, for some of these areas, we early on want to bring in experts who have done this before, who are interested and eager to actually do this for longer periods of time and not just as one-off projects, right? And who can really build a foundation for the next phase of growth.
Yeah, it reminds me of that distinction we made at Stripe, like the difference between a project and a program, right? And people confuse the two, where like project is like one-off, but like a program requires a dedicated owner to maintain it and actually build on it. I guess the last question I have, because I know we're running close on time, is it sounds like an amazing story. Like, okay, crazy ticket backlog, form support ops, Stripe support is really good now. But I'm sure there were mistakes or snafus along the way. And so if you had to do this again, what are some learnings that you had, or what would you do differently?
Yeah, I mean, first of all, I would, I would say that before I kind of answer the mistakes we made or things we do differently, you know, one of my favorite operating principles that we have at Stripe is we haven't won yet. And, you know, we certainly feel like that every day. So it's obviously great to hear when, when our customers are very happy with their support interactions. Unfortunately, there's still a lot of customers out there that, that get stuck, right, and that need more help. And we feel this huge responsibility because we handle company's payments, right? And like, there's hardly anything they're going to care more about. So that's really, you know, why it's so important to us. In terms of things we— look, I wish we would have done earlier. One of the things is tying support interactions back to product feedback is an area where, you know, we for a very long time did so, but did very kind of custom analyses and, you know, deep dive, one-off deep dives, and let's label a bunch of support cases and, and, you know, like find out kind of what's, what's going on. It's only been kind of in the last 2 years where we really tried to solve this at the systems level. So to have, you know, a consistent taxonomy of products and issues and make sure that every support case is categorized appropriately so we can really report on How much users are contacting us about which issue, like what are the pain points, etc. So that's, that's probably an area where, yeah, I would recommend companies to start very early on.
So I know we're running close to time and I want to make sure we get some of the questions from the audience. And actually we have one from Jason M. Lemkin. What are the top 3 KPIs for support teams? This is your favorite question, Bob. Like you've drilled this into like everyone in like the support org at Stripe?
Well, I actually think it really depends on the company strategy, first of all, right? So like it's dangerous to kind of give this one answer that will work for everybody. And for some companies, the customer experience is gonna be more important than for others, right? Like the cost constraints are gonna be tighter for some companies than for others. But in general, kind of like with those caveats, I would say that you want to measure, you know, how well, like how good is the customer experience. And there's no better way to kind of measuring that than to ask your customers, right? Like how happy they are with their experience. And therefore, you know, you can choose CSAT, you can choose NPS, you can choose a variety of those. But I think that's most important is that you actually ask your customers how, how happy they are with the experience. And then on the other side, you want to have some type of objective internal bar on, you know, how quick should we get back to issues and how fast do we turn around issues, right? So a combination of like first response SLA, resolution SLA is going to be really important. And then maybe lastly, you want to make sure you're thinking about your overall efficiency, right? So like companies that are going through a lot of growth, they can very quickly quickly kind of explode in terms of the operational needs. And looking at things like the contact rate, for instance, that I mentioned, right, of like how many cases do like 100 active users of your product create every week, right? And like over a long period of time, you'll likely want to bring that down because it gives you evidence that you're addressing recurring issues in the product, which is obviously better than like building out larger support teams to answer that. And I think that's the contact rate is probably the more important one, right? Like from a long-term efficiency perspective, from a short-term efficiency perspective, you can look at things like productivity, right? Like how many cases do people handle per hour or per week? But I actually think that contact rate is the more important one.
So just like summarize the top 3 KPIs, or the first one is like CSAT, getting like measuring it from directly from the customers. The second one would be around like SLAs, which is like your responsiveness, so like first response SLA and resolution SLA. And the third one's a metric around efficiency, and the one that you think actually is something like tracking like contact rates and being able to like reduce that over time. Yeah. So I just wanted to close out, uh, with just like some of the takeaways, uh, from the session. So these are pretty much like the summary of like the things that Bob and I had like talked about. Uh, which is like one, like investing early in support ops to help your support team scale. Uh, two is like start with getting your metrics right, because you can't improve until you start measuring and having a baseline. Uh, three, don't expect the people supporting your customers to be the one to build your operations, because the hiring profile for support ops, uh, would be like hiring people who are like analytical, who are builders, who have like expertise, which would be a slightly different profile from like the folks that you would hire to be supporting your customers. Anything else you want to add, Bob?
I think those capture it. Obviously, every journey, like every company has their own journey, and the things we've gone through with Stripe might not apply to everybody listening, but I do think that these takeaways are hopefully useful, right, and like something to think about as each of if you are building out your teams. I guess the only other thing is, like, if any of you have follow-up questions, I'm bob@stripe.com, so always interested to connect.
All right. And I think that's a wrap. Thank you, everyone. Thank you, Jen and Bob. You guys did terrific. For the questions we didn't get answered, I will shoot them over to you guys if you want to address them later, but I really appreciate your time, and we're so glad to have you. Thank you for being part of SAS or Build.
Thanks so much for having us.
Thank you, Caitlin. Have a good one, guys. Talk to you later.
More from Jason

Why Your Next Hire Should Report to an AI, Tragedy Apps, and Too Many AI SDRs? | The Agents #004

Our Agents Drove Our Salesforce Bill Up 80%, Marketo Hates Agents, and We Stealth-Churned Off Notion

Managing 20+ AI Agents: Lazy Agents, Our $500K AI Bill, Stealth Churn & the Death of 60% Solutions







