Brian Flood

VP of IT, Business Systems & Data

,

Fastly

   |    

May 30, 2022

In this week’s episode of the Enterprise Monetization Podcast, Sandeep Jain sits down with Brian Flood, VP IT Business Systems and Data at Fastly to discuss the complex nature of their Quoting and Billing process and talk about “William”.

Podcast Transcript:

Sandeep Jain:

Hi. Welcome to the 10th episode of “The Enterprise Monetization” podcast. And this is your host, Sandeep Jain. In this podcast, we invite thought leaders in the monetization space that has CPQ and billing, so that you can learn about challenges, opportunities, and best practices in enterprise monetization. Today, I'm super thrilled to invite Brian Flood to the podcast. Brian has over 25 years of experience in the field of business operations. And he has worked at different companies like UCSF, Palo Alto Medical Foundation, OpenDNS that was acquired by Cisco get lab, and now Fastly, whereas he's the vice president of IT for business systems and data. There's like who's in who, of the enterprise world, and Brian has seen it all. So I'm super, super excited to talk to him today to give his perspective on Quote-to-Cash. With that, welcome, Brian.  

Brian:

Hi, thanks. I'm thrilled to be here.  

Sandeep Jain:

Awesome. So before we go into Quote-to-Cash, let's talk about you first, can you share a quick fun fact about yourself with our listeners?

Brian:

Sure. So as I was getting into data, you knows it's 20 years ago, I moved 25 years ago, I was actually working in music. And they said, the first sort of 10 years of my career working remotely on tour with bands and I would download spreadsheets into the laptop and work on them on the road. Because the road is like all downtime with like, four hours of excitement every like two days. Otherwise, you're just bored. And so I would work on data. And then, you know, it was the early 2000s. So you get to another spot that has internet access, upload a spreadsheet, download another 65,000 lines, and then you know, keep on going. So that was actually the beginning of my data career was, I couldn't decide whether I wanted to be music or data and systems, until I figured out where the money was. I did both for a little while, that was fun. There was a good way to for my 20s.

Sandeep Jain:

That seems like too much fun, by the way. So how did you end up from there to Fastly? So, can you talk about your journey?

Brian:

Yeah, so you know, I was I struggled with spreadsheets when I was doing medical sort of billing analysis. So what we were doing was looking at under payments, you know, an insurance company and has a contracted amount that they pay or they're supposed to pay. That's not usually what they actually pay. And so I started looking at data to compare, and then we'd send them a bill for how much they underpaid us and it was on spreadsheets. And so eventually, I was like, there's got to be a better way. And I wouldn't sequel to start finding out ways to automate that analysis. And got really deep into analyzing, you know, how do we lower the cost of health care while increasing quality? And that's a huge problem in the United States. And we found a lot of really interesting ways to do it, particularly after I got my MBA. And then at UCSF, I spent some time after we implemented our electronic medical record system, we should have grabbed like their GL data, the medical records data and their payroll data, and, you know, found ways to optimize healthcare delivery, then lowered the cost and increased quality. But it would require a lot of work. And I think, you know, they went a different route to lower costs that actually lowered quality. So I was like, hey, you know, I want to try this tactic. I'm in San Francisco, I had been doing healthcare for like 18 years. In, I got an opportunity to join up with DNS. And they were like, 75 people at a time. And they I was like, I do analytics. So that's, it's transferable. And I talked to him about, you know, creating a SaaS metrics, dashboards. And I spend a lot of time in business school looking at the SAS model. And I give you a, which was the CEO at the time, and I showed him, here's what I built for your company, because this is exactly what we need. And then he asked me, like the most technical interview questions I've ever been asked but I had no idea what the answers were. But I was lucky enough to get the job and I sort of get out of healthcare because it led me down. We built you know, we started building analytics DNS. And then we found out sort of the same thing that most companies do at that size, which is like, Oh, the data is a mess. The systems are set up right. We're not capturing what we need actually measure the business. And at the time, David had, like he didn't have an office, he said, of the middle of the sales floor, and he put me next to him. So he just asked questions I would write sequel enhancer, like all day long. And if I was like, you know, David, our data is really bad. We need to fix the system. He's like, well, go do it. And as I don't know how to fix Salesforce, I'm from healthcare, I don't work at Salesforce. He's like, well go figure it out. That's startup, that's what we do. So it's like, alright, I'll go figure it out. So I started figuring it out and started, you know, loading data in that was missing, fixing some of the problems, eventually hired an admin and a developer. And then suddenly, I was in charge of business systems. And really only did it because they needed better data and it sort of grew from there. We built a really awesome system and platform there were, you know, we wanted to automate as much as possible, we don't want humans involved, because that's where bad data comes from. So you know, once a quote, got process, at the time, we were using Zuora. And we had built a bunch of automation to do like automated provisioning. And we had sort of once a quote close, everything was automated, no one touched anything, including, you know, invoices, credit card, payment, capture, and provisioning was all completely automated. And when we got acquired by Cisco, first, they were like, you're gonna move into the Cisco Sales Force. I was like, No, that's a terrible plan. You'll, you'll break our business. Here's, here's how we work. And I showed them all this automation. And even how we did free trials and sales are just, you know, select the products, they wanted a free trial, push a button and provision right from Salesforce. And, you know, fair enough approvals on that stuff. And they were like, Oh wow, this is cool. We don't have anything like this. You should stay on your own sales versus like, yeah, I know. So we did. And then they were like, well, how are we going to sell your product? And I was like, well, we can API and our Salesforce instance, you dumped the order data in, and then we'll process it just like you would any other order, keep the same data model, we want it to all look exactly the same. So we could leverage all that automation, keep the same data model, and it works incredibly well. And then we didn't care where it order came from. It could be a website, it could be a quote, it could be an order from our partner, or Cisco or wherever. As long as it came in through this API, we just processed it, and it was no getting stretched it. It was a beautiful thing. I think the key to that was we started early, before things got too crazy. We were able to build that stuff. And if we started later, I don't know that we would have got there. But so two years afterwards, the Cisco just said understand that scale, it was a really big company, like 80,000 people, I was like how things work at this size. It was interesting, but not where I wanted to spend the rest of my career like building companies that teaching people how to automate things that they are not actually interested in doing. And Git lab was a really interesting opportunity. They're fascinating company, 100%, remote, really interesting opportunity. And they got me into like building actually a product called Meltano, which they're still doing. But I tried to get away from business systems again, briefly. I was their senior director of data and analytics. But same problem. No one was taking care of the business system. So I started doing that. But then my friend Dana called me from OpenDNS as she moved over to Fastly. And she was like, well, you teach us how to do that thing that you did it OpenDNS, I was like, I mean, build a business like systems and analytics platform, like, yeah, sure, I can teach you how to do at the service of revising fascinating how they could go about doing something like that, and saw the complexity and also met with all these people that I was like, This is amazing company, and I love these people. I want to work here. And they sort of won me over and I was like, you know, Dana, you don't want to just build this and she was like, yeah, build it. So she had me on the phone with Bixby who's our CEO like the next day, and I think that was her playing all on. And so they had two people working on systems at the time and I had to start from the ground up and they were like 500 people but no one was tending to their business systems. There was no holistic architecture and so that's what I came in to do. How to like, I built out a financial systems seem a go to market systems team eventually took over the people systems. I had data warehousing and BI from the beginning. And don't get out of that we're still several ways to go there. And then about a year and a half ago, they asked me to start supporting IT which was interesting, because I've never actually worked in IT shop before, I've always done analytics and business systems. So I've actually been in corporate IT as well, and learning a lot and also understanding like, that's a critical part of creating this platform to run the business on. If we really think of, you know, CRM and ERP, your HRS, it's really they're all components of building a platform that you've run your business on. And when you start bringing in things like [inaudible 10:41], and how that flows, your employee data throughout all those systems, it made a lot more sense to me like, oh, actually, this like, it's pretty important that this plugs into all the business systems. It's like, this is the bridge between corporate IT and business systems, even though I think a business systems is not really IT. But anyway, that's, you know, we IPO at about two years ago. It was really fun, fascinating process, put in socks and rolls, which was I wouldn't say fun, but it was a fascinating process. And, yeah, now that's where that brings us today.

Sandeep Jain:

Awesome. So it's like music to data to business systems?

Brian:

Yeah, you know, there's always a struggle as an analyst, like how do I get better data, because the systems aren't doing it. And apparently, the way to do is you got to take over the system. So it's really powerful when you can build the systems to create the data, you need to measure the business that was like the secret sauce.

Sandeep Jain:

Got it. Let's talk more about this, Brian. So let's first start with this, what's your Quote-to-Cash stack at Fastly?

Brian:

Sure. So we're a heavy CPQ server shop. So we have one of those complex CPQ implementations I've ever heard of, you can think of Fastly as, you know, we sell sort of CDN products, like, you know, the typical CDN a little more faster than anybody else. And that's a fairly mature, you know, market space. Then we've got security where we do web application firewall, you know, to sit in front of whatever you're delivering off of the CDN. And then we've got sort of our early stage products, which is edge computing. Those three things all have different business models. You know, security is a SaaS model annual build up front, is CDN is its usage base, monthly billed in arrears. And some of them have very complex usage models, so you know, bandwidth and requests, and then they're tiered and on top of that, they're regional. And so you've got eight regions, each one with five tiers, for bandwidth, that's now 40 price points for one usage component of our baselines CDN, and then you got requests. And with requests, we do things like for every gigabyte of delivery, we'll give you 10,000 requests for free. And then here's an overage on top of that, and so things get really complex. So that's a huge part of our world is we build a very customized CPQ implementation, once that sales reps can manipulate all those price points, like they can't do that in lineup. So we had to build a UI that was support that and this sort of rate card concept. We're using ARIA for our buildings that are like our billing engine. But you know, ARIA can't handle all this complex logic. So we have this homegrown system in the middle. It's called William, because Bill is short for William and it's a billing tool. William does a lot of this complex mediation, really dealing with, you know, rolling up hierarchies. So sometimes we have like children accounts that need to roll up usage to their parent where the commit is based. And it all contributes to this overall command. Sometimes there's a child's pay, but based on the parent contract, so we have all these different sort of models that are just too complex for most billing systems. And so that we built this thing in the middle to sort of take care of a lot of the complex usage processes where, you know, we cross the streams, like requests and gigabytes of bandwidth for delivery. And then, you know, for ARIA, then it just becomes a great time to quantity because most releases are just getting to handle that level of complexity of usage indication. It's I haven't seen much out there yet that can do that level of complexity. And then, you know, we're using NetSuite for ERP, and then we use NetSuite for manual billing. Sometimes it just gets too complex you know, you've always got those, like snowflake customers that don't fit into anything and you've just got to manually create nimble for it.

Sandeep Jain:

Got it. There's a lot of interesting information. So what I heard is, you using Salesforce CPQ today?  

Brian:

Yeah

Sandeep Jain:

And but I also heard you say that you have built a UI on top of that, is that correct?  

Brian:

Yeah, we did. But it's within Salesforce. It's just a bunch of ARIA, I think it's ARIA now that the web components, wherever the latest and greatest UI, certainly the Salesforce stuff is. But yeah, we had to build a way to allow our reps to manipulate all those price points, because it's a lot. And then we also wanted to know, like, how do we know if this deal is good or bad for us? So we actually built a margin calculator into it. So our reps put in, like, how much traffic, how many HTTP requests are gonna come through this, you're gonna get like different companies like a streaming company. That's like streaming music, they're gonna have less HTTP requests, but a whole lot of bandwidth, versus a blog, or some site like Reddit of the world, they're gonna have a whole lot of interview requests, but it's all you know, text and animated GIFs. So it's not, there's not a lot of bandwidth there. And so like, there can be dramatic differences in how different customers might have a different margin based on the usage. So we actually built that in so we come up with an estimated sort of revenue amount, and estimated the cost amount to deliver that and then figure out the margin, like, is this a good deal or a bad deal for Fastly? And then can we tweak it to make it better? And where you know, because it all depends, where's their traffic? What region? You know, how much goes where? And that became a really powerful tool, although it's, it's one that's constantly changing.

Sandeep Jain:

Got it. And how many engineers, Salesforce CPQ engineers do you have in the team to sort of customize to the way you guys have?

Brian:

Internally, we actually like two at the moment, but we're hiring a ton more. And then we have an agency that we work with, where I've got two more developers there, I have an amazing architects, who is just a genius of how to make all this stuff work. Because you know, like, we're talking about the delivery model, but we actually have, I think, nine different pricing schemas across all of our products that we have to deal with. So like, there's no way to, like have a single price list on a piece of paper, when I have to dump it out for the orders, it's actually like 12 excel sheets.  

Sandeep Jain:

Got it. I want to give a sense to our listeners like, what does it take to build the CPQ thing that you guys did?  

Brian:

It took probably like nine months to a year to actually get it to where we were comfortable, and really feeling good about where it was at it. It took a really good architects and developer who had really creative sort of thought processes about okay, if I was a rep, how would I interact with this? What would I want to do to create a quote, and then, you know, we had all these other requirements, like legal language, that's about a quote, and has to be dynamic, because like, you know, they always want to tweak little parts of it, well, you get this much, you know, for free up until this amount, and then there's an overage and then and we need to be able to print that dynamically on the sales order form. And so, you know, between products and legal and accounting, there are a lot of state and sales, obviously, there are a lot of stakeholders in what is what is going to sales or to look like and then how do we create a UI that can generate that data? And it was a heavy lift, not just on the actual development side, but on the like, how like the design was really complicated and hard to figure it out.

Sandeep Jain:

Got it. Let's talk about William there. How many people did it take to build that? Was it done as part of engineering? Was it done as part of an IT team initiated like?

Brian:

It was done as engineering, it was actually our original billing system. And one of our founders actually built it, he's got a really funny story about he built it, like drunk on a plane. Like in the onboarding session, when I first came to Fastly, he was telling the story of [inaudible 20:25]. And it was the billing system originally, the entire thing, that was how they did billing entirely. But it was, you know, it was very early days, and eventually, they grew out of it you know, like, and building your own billing system was a horrible idea unless you're a billing system company. And that's your core competency, like, don't do that. So over the years, it was the sort of like, what do we have to build to make facilely work, because nothing off the off the shelf can do it. And that's where we sort of tore out all the pieces that other systems could do, like invoice presentation, cash application, all those downstream mechanic functions. And left in a lot of the usage, mediation that was like, you need to Fastly, and we couldn't find anything else that could do it. And so it's still engineering driven. And it was also, you know, we, we had to have it to manipulate all the usage data, because if you think about a CDN, like the user data is you know, billions and billions of rows of every HTTP requests. And so we need to aggregate that stuff, and we need a system, you know, you're gonna do that in Salesforce, it's not going to take billions and billions of rows and be happy about it. So that's where William came in was, aggregate that stuff, do all the really complex mediation, and then we needed a different system to begin with presentation, like credit cards, do the cash application, because like, you know, building your own credit card capture, you don't want to do that.

Sandeep Jain:

So tell me this thing. If William is doing all the heavy lifting, why not connect William directly to NetSuite where you can run your invoices, why do you need that other system that you mentioned?  

Brian:

Well, so this is actually where we're thinking about taking it is for next steps. You know, ARIA is now just like quantity times rate. And they're manually entering the rates in ARIA, it's not actually integrated. So there's a human being that's actually typing in those rates. And, you know, nobody wants to do that. It's a waste of time, and we can't scale it. So we've got all the rates sitting in CPQ. Those are the rates that go on the sales order, they could sign and I only want one source of truth, I don't want to sync those all over into five systems. So what we're actually going to we're building now is sort of like half of it will run in Salesforce. So Salesforce will sort of have this entitlements engine in it, look at what needs to get built today, when which customers and then turn William into a ratings engine. It's like a service, where we make an API call to it and say, here's this customer, go grab the usage, here's their rates for all the products that they're entitled to. And then give us back line items. And it's going to our idea right now is pushing back into Salesforce as line items, then just push all the header information and the line items into NetSuite bill out of there and do English presentation. And then just, we don't need ARIA at that point, we're just going to kind of all system, hopefully, they're not listening. But it's hard to become superfluous at that point, like it was put in before we had CPQ. And originally, you know, they were doing quotes on Word documents, and then copying and pasting the Word doc in a rich text field in Salesforce. And there's, you know, obviously, if it's just a giant blob of text.

Sandeep Jain:

So tell me this thing Brian, one of the challenges that we've heard is that on the CPQ, you know, it has its own data model, William will have its own data model, and the NetSuite will have its own data model. And what I heard from you that you have like three separate product lines, with three separate business models, like how do you manage the symphony of these three separate instruments?

Brian:

Really, really smart architects that are really creative? Because we do like we put them all on the same service or we can create a single quote with all three you know, one time fees SaaS annual build and monthly build arrears on a single sales order and it's pretty understandable. You know, I think we have some interesting stuff to do on some of it like, we were getting some feedback about like Valley, well, this year, it'd be a little better to understand. But it was not easy, we got to get really creative but it works. The problem is like we had to manipulate CPQ a lot, right. It's not set up to like, at least at the time, we were doing this like three or four years ago. And so we had to like leverage the discount schedules to create tearing. And so like some of our tears are actually just negative discount schedules and then they're just prices. And then later on, they built actual tearing. And we were like, we felt like at one point, were like three months behind the Salesforce, like, we would build that, we build some fake version of that we'd shoehorn into some feature that wasn't meant to be that way. And then they build the feature three months later that we actually needed. And really, they want you to pause for three months, and they'll catch up.

Sandeep Jain:

But this was, Brian, but this was being done on the CPQ, but once the service order is out, then William needs to understand what the CPQ did. So William also needs to understand the packaging, different business models. So how does that sort of interaction point work between the service models?

Brian:

That’s what we're building right now, we needed like are, we don't want our engineers to have to worry about any of this crazy stuff we did, or how that the data models are different. So we're building, we're calling it entitle. And so that's confusing, because there is already something called entitlements that that exists in Salesforce. And this is just custom that we're building. It's not what Salesforce calls entitlements. But we really wanted to simplify that data model down into something that we just don't have a JSON blob of, you know, here's the product, here's the rate, here's the type of the model of ratings. And also, here's the quote for the type of usage or the use of the specific usage fee that we need to use for it. And that's how we sort of marry the things is like, we have a quote that matches, this is the usage that you should use. And this is the product that uses that usage. And we just sort of break that down into multiple components. But really, what we're doing is creating this object that sits in between, that simplifies that data model down into something that's much more easily consumable by our engineering team. And, you know, it can facilitate this ratings, but it can also facilitate automated provisioning and self-service and all these other things, and it sort of lives in Salesforce. But we're recruiting sort of a real time version of it outside of Salesforce as we don't, we don't want Salesforce in our production stack. So it'll talk two ways. And our thought is that like, if somebody goes into self-service, and creates an entitlement on the engineering side, that needs to go into CPQ is entitlement engine, and I want everything in the same data model. So I'll go create a subscription and a contract and all that other stuff and then copy the entitlements and the same thing will work the other way. If a rep creates a quote in the Salesforce has elements get updated. We want to push those updates down to the engineering version. And then engineering will just interact with on their site, does that want to be dependent on the Salesforce API's working.

Sandeep Jain:

Interesting, interesting. And how big is the team roughly that is building the, that sort of maintaining William?

Brian:

There about, I think, five people right now on the engineering side, and then on the salesperson, I've got like three people that are sort of focused on this entitlements engine. And we're bringing in more, because this thing is big, right. Like we're revamping the entire end to end sort of Quote-to-Cash processes. So we're bringing in like, we have a program manager that specializes in this, a product manager who's going to you know, manage it, all the requirements and hammering that out. And then you really needed an enterprise architects who can see end to end has always integrated, how do we tie all these pieces together? They can understand the whole and envision because it's like it's in my head, but it's in my head at a very high cartoonish, like executive level. When you get down to those details, like I can't do that anymore. On my tech, I'm not allowed to touch the computers as a VP. You don't get to touch this stuff.  

Sandeep Jain:

Brian, you said earlier that, like do not build your own billing system. Do you still hold true with that sentiment, like as an…?  

Brian:

Yeah, I think as a, unless you're a company that builds billing systems like you should stick to your core competency and you know, the things that they can involve in building a billing system, as you well know, are like really complicated, especially when it comes to PCI and different types of payment capture and getting international. You know, it gets really complex to try to manage that stuff. And then, and it's all out there, right. Like, why build something that creates invoices, when you already probably have a tool in house that does it really well or, you know, you should buy one because building that and maintaining it is gonna be like your, if you're gonna have engineers, you should have them focused on something that's unique to your company, not reinventing the thing that already exists in 50 different ways.

Sandeep Jain:

And Brian, did you also talk about Sox compliance, because one of the challenges I've heard is companies that build their own billing or usage billing system, they have to worry about Sox compliance, at least when they go public?

Brian:

Oh, yeah. It's because you're from the data coming off of our or our pops around the world. From that point where we were the requests that used to be requests originates from until it gets into the billing system, all of that is in scope for Sox. And so we have to be able to prove out that that data is accurate. And that we have ways of showing that nothing manipulates that data on the way in or out, it's encoded in a special way. And then we have to sort of prove all the way through the stream that we didn't lose any of that data that we didn't even through all that manipulation, it ties back to the original use of your mountains. And that's hard. It there's a lot of engineering behind that. And then you've just you're [inaudible 31:53], where it's like, how do you change control manage, is we're building new products all the time with new usage pipelines. And, you know, getting into getting on getting products to understand like, hey, you actually have to give us a heads up way in advance. Because if you've got a new usage pipeline, we've got to end to end build it in scope. And then make sure that like, you know, even the pricing, and the discount schedules are all signed off on. And, you know, there's all the approvals that you need for Sox, just rights, etc, is much less of the financial controls. There's a lot of pieces there that early businesses don't need to deal with. But it becomes really, really hard to do after the fact because we basically had to rewrite all of the data pipelines.  

Sandeep Jain:

Got it. And Brian, is there any vendors of the systems listening to the podcast? Is there any advice that you can give them from a practitioner perspective that look here is the things that you could do, you know, the three months thing that he talked about out of sync with Salesforce? Are there any things that you would say, which vendors should think about was probably they're not thinking about today?

Brian:

You know, mostly, what I'm seeing in the market is a lot of focus on B2C, which are generally a lot simpler. And in B2B, we get really complicated models where they have requirements, and we have to meet them, we don't really want to sell to, you know, these multibillion dollar companies, they're like, well, we'll do this, but we want a very special way of you billing us and every company has these, so figure out a way to do things like we have a commitment amount for this set of products. And they roll up, the usage rolls up into this one commit about, and then we have a different product that has another commitment amount. And then a parent who has a commitment, and the children need to roll up to it. You know, these, these sort of concepts only exist in the B2B world. And that is where I'd love to see more focus on the complexities of B2B use cases, rather than like, yeah, we can manage, you know, 5,009,099 credit card bills every year. And I'm like, yeah, there's like, you know, 50 products that can do that, like, show me that you can deal with the most like some of my really complicated stuff, and I'll be impressed.

Sandeep Jain:

It make sense. And Brian, what are the top priorities for you fall asleep for the next few quarters? Like, what are your thoughts on that?

Brian:

It really, it's building that entitlements engine to really get fascinated to scale for different types of like, we want to enable much more self-service. We want people in the UI to be able to turn on features, and turn off features that they're entitled to on different services. In order to do that, there needs to be some way for the system to check that they're actually entitled to use that feature. And so it's really building this new model of using CPQ as our source of truth for rates and entitlements, rating them, you know, through William and then pushing that stuff into NetSuite for in which presentation and simplifies the model a ton. And so it gets rid of a whole entire system, which is really just doing a simple calculation. And so like that is going to take us probably until easily next July. And because it's Sox scopes, there's sort of like this unwritten rule that like, you never go live with a Sox system in q3, or q4, because you want two quarters have samples. And if one of them, if they find something wrong, like, you need a quarter to remediate it, so you'd like if we're gonna live in July, it's wait until January of 24. So really want to hit July. And so we're laser focused on rebuilding the stack and simplifying it. And we're in there, it's coming together finally, this is something I've been working on for like two years. It needed to happen a long time ago. But, you know, once people, once executives of the company realized, like, how big of a problem this is, and how bad it was going to get, it became the top priority real fast.

Sandeep Jain:

Got it. And with these multiple systems, are there any specific metrics Brian, you look at to measure the health, or I said like, nobody's screaming, so we are doing?

Brian:

Yeah, I actually look at the one the number of bugs in the system, they're coming back, because that means we're not doing our QA properly. And that's another big piece of this is we're starting to implement much more automated QA processes. Because we've had humans do them. But like, a human can create like three or four quotes to test a new product, I need to create actually, like 50, or 100. And in order to do that, I need a robot. So we're trying to implement those automated QA processes to minimize the number of bugs that make it into production, because that's really what, what kills us when you have a system that's complex, really easy to introduce bugs. And the other thing is like, “Yeah, who's kicking and screaming”, I have a Slack channel, which is like the worst idea ever. But we all have to do it, like the where the sales reps go to get help. Like, Hey, I gotta get my quote into this, I'm running into this air, and seeing how much traffic is in that channel is actually a really good metric for “Are we building the system in a way that they can intuitively create a flow or, you know, do we need to work on better training? Do we need to build a better UI”? Those are really what I'm, I'm focused on. And then I want to start doing sort of an NPS of the system to see like, you know, does it meet the needs? Like how are people actually feeling about it? And we just hired a CPQ product manager, who actually spend time with the users and like, sits with them as they create quotes and really understands the processes of the pain points.

Sandeep Jain:

I love that you said something about MDS, what does that stand for?  

Brian:

NPS, just like net promoter score.

Sandeep Jain:

Oh, NPS, net promoter score. Now, I get that. Okay.

Brian:

Like, what would you recommend our CPQ instance to your friends? No, we don’t. They’re not even in sales. But something along those lines NPS or not, it's I want some sort of metric to say like, does this meet your needs, or is it intuitive enough, is it doesn't work well? Because we get a lot of feedback. And it's very generic. And a lot of it is like, we're not getting trained well enough or, it's very specific. We just look we love where they're like, when I order this product, and I click here, I don’t want to be able to enter this number, and I can't do that. And we're like, oh, that's brilliant. Yeah, like we make that happen. Otherwise, we end up with like, CPQ is too complicated and like I can't do anything with that.

Sandeep Jain:

One of the things that I've heard from the sales leaders is time to quote, like when people start doing a quote and then till the end when this hit review, like how much time it does, and it's a function of the deal as well. I mean, some deals are complicated, but some sort of measuring there is a little quote indicator.

Brian:

This is one of my least favorite complaints is it takes too long to build a quote because it's too broad. So what I do with that, whenever I get that is I say, Okay, hit screen report and create five bullets. And you almost do like a, like a time and motion study of, like, where we are looking, what are they doing? And it gives us a huge insight into how was the rep thinking they're supposed to be using the system versus what did we design the system? Because you know, those things are never in any software projects, like they're never really aligned 100%. And then we can find out like, okay, exactly, where are things getting higher up? And then, you know, I was like, 90% of the time, it's like, well, approvals are taking too long. And they just can't get all this first quick proof. And we're like, yeah, that's not a system problem. But sometimes we uncover you know, these mythical steps that they believe they need to do, but they don't actually need to do them. And we're like, you know, you did these five clicks over here, you absolutely don't need to click on this thing. It's like, never click on those actually. Don't touch that stuff and we save time that way. But you know, before we had CPQ, it could take two weeks to create a quote at Fastly, because it was all done on in Word. And now we call them artisanal quotes when they have to do.

Sandeep Jain:

Artisanal quote, I’ll remember this this term.

Brian:

Yeah. So you know, going from two weeks down to like, five minutes is a pretty big deal. Now, nobody, none of the sales reps they were around, remember back then how horrible it was? So now five minutes is egregious. But that, you know, there's time in motions type study things are really helpful and understanding like, where are the gaps? Where are they getting hurt?

Sandeep Jain:

That's a great idea, Brian. Now on a related point, you talked about your team that has team and engineering. And probably there's another team that manages NetSuite. If a company is starting fresh today, and with these overlapping disciplines, like is there a recommendation on how to structure the teams for success?

Brian:

So this is sort of a point, I believe the business systems part needs to be centralized because we're building this platform, that needs to sort of support your Quote-to-Cash, procure to pay high to retire, it's all interrelated, and all these tools are components to a larger sort of platform. But then you've got these engineers who you need to build data pipelines that are coming off of your data centers. And I believe those folks going in engineering, they're not going to get the access and the support they need outside of engineering. And so you need really, really strong relationships, I think Mark, settle sort of, I steal this from him. He said at a conference a few years ago that “Business systems is different from it. And you need like a third relationship building, a third technical, and a third business acumen”. And this is where that relationship building comes in is, you've got to be able to as leaders of the organization really work tightly with the engineering teams, with your accounting stakeholders, with your sales stakeholders, and really align all those groups. And that takes effort and a different type of person, then you know, they typically find an IT department. And I think that's the sort of specialization of business systems is, you know, it's different. It requires you to really understand the business and really be able to work on relationships with all these people. And that I think, is how we made it successful.

Sandeep Jain:

Got it. Brian, this has been like the most amazing conversation I've had in some time. So this is overlapping business systems data. And I think the complexity of what Fastly has, I think that's what stands you guys apart in terms of how these things are structured now, but before I let you go, is there any recommendation of a resource like a book, or a podcast or a blog that that you would like to recommend to our listeners and viewers?

Brian:

The one that I because of the complexity, and because like I've got, I've got like six teams now that I manage. I'll do that the sensitive version is “How to not given an F”. That was written. And the point is that like you only have so many that you give in a day. So you'd be really careful about where you're spending your energy, and what you're really caring about and that was really helpful for me around like what really matters to focus on? What should I spend my day doing? And what's the best highest use of my time rather than like caring about every little possible thing? Where do you spend your time and that as it's something that I think about a lot, just because I pulled in 50 different directions that day, but I only have time to go to like, six. So how do I pick those six? And that's where those, that focus has really helped me, like hone in on how to make those choices?

Sandeep Jain:

Great answer, Brian. I think with all our busy lives at home with multiple [inaudible 45:45], we could use some of the lessons from that, I guess. Awesome, Brian. Hey, thank you again for your time today. It just, it was an amazing conversation. Thank you.

Brian:

Yeah, thanks for having me. It's been a lot of fun.

Sandeep Jain: Hi. Welcome to the 8th episode of “The Enterprise Monetization” podcast. And this is your host, Sandeep Jain. In this podcast, we invite thought leaders from monetization space that has CPQ and billing, so that you can learn about challenges, opportunities, and best practices in enterprise monetization. Today, I'm pleased to invite Navin Persaud. To this podcast, Navin has a deep expertise in running sales and marketing ops. He's currently the Head of Revenue Ops at a company called 1Password. I'm pretty sure all of you would know what that company is for. But for those of you who don't know, 1Password is a private company based out of Toronto, Canada, and they do password management for both businesses and for personal use. So they are like a Product-Led Growth company, if you're familiar with the term Product-Led Growth. Prior to that, Navin managed operations at several companies such as Fixed Software, Ceridian, Leader, Lenovo and IBM Canada. With that, I want to extend a very warm welcome to Navin. Navin, welcome to the show.
Navin Persaud: Thanks, Sandeep. Happy to be here.
Sandeep Jain:  Awesome. So, before we start, can you share a quick fun fact about yourself that you'd like to share with the audience of this podcast?
Navin Persaud: Sure, sure thing. I think people who know me know I love to fish fishing. I'm not exactly a great fisherman, but I love the analogies that that fishing offers me in my work life to my personal life. And really that persistence, the amount of effort preparedness, these are all things that work in both elements, whether, you're fishing or whether you're that sales rep trying to close that up order.
Sandeep Jain:  It's interesting. I don't fish but I could never call it that analogy. Well, we've all seen the fisherman just sitting and just waiting for the hook to be engaged. I don't know, what's the right phrase there? But I can imagine the patience and the diligence required to get this thing done, it's very interesting. Do you fish often, by the way?
Navin Persaud: Anytime I can get.
Sandeep Jain:  Wow. Okay. So I'm assuming you're close to a place which allows you to do what you want to do?
Navin Persaud: Proximity water doesn't stop me. If I have time, I'll go find it
Sandeep Jain:  How much is this, if you don't mind me asking this, the paying for this activity is like a few hours like what's the time commitment?
Navin Persaud: Yeah, usually, you have to know that you're gonna go a day before because then you have to pack the vehicle and make sure you have all your gear, have bade know that you're waking up early the next morning, and then you go.
Sandeep Jain:  Got it. And once again, my goodness, but is it kind of a solo sport, or is it?
Navin Persaud: It's either, but like, the great joy for me is taking my son. So my son is 18. And he loves fishing as much as I do. And sometimes he's pulling me to go fish when? No, I'm not thinking about it. So it's actually really great.
Sandeep Jain:  That's interesting. That's interesting. My son is eight years old, probably, that's a good dad and son bonding exercise, I guess. So thank you for sharing this, by the way. Let's come to some other fun stuff that we want to talk about today, which is monetization. So I give a quick summary to our audience. But Julie, just quickly share about your professional journey. You know, it seems that you started in marketing, sales, and then you're now into revenue operations, which is sort of an over encompassing thing?
Navin Persaud: Sure. I started my career as an IBM 15years, right at a university, I thought I was going to be a lawyer at IBM. Opportunity at IBM was amazing, as you know, entering the workforce, starting off as you know, an operations moving into sales roles, finding a home operations, and then eventually moving into SaaS organizations Rev Ops 2015. And then learning SaaS from there on in having never experienced Salesforce, didn't really know what SaaS was never sold software, moving from like a commodity based business to software and, you know, looking back, I wish I had done it sooner.
Sandeep Jain:  Go ahead and dial up one password. Can you talk more about the company and your role at 1Password?
Navin Persaud: Sure. I've been to 1Password for just over six months now. It's been an amazing journey, their Product-Led Growth Company, they serve as both individuals so like a B2C model, and companies as a B2B model. They're on an incredible growth curve at the moment. Product-Led, and my role here as leader of Rev Ops is to really just look at the internal processes and systems and sort of help the team remove obstacles, to just keep that efficiency rolling out, it's been a great journey. I've enjoyed the ride. And I look forward to more projects and initiatives that we're about to embark on here shortly.
Sandeep Jain:  Understood. And could you talk more about, like how your role is structured within is apart of the sales organization? Because revenue operations crosses the multiple boundaries of multiple functions. So that's why I'm curious about how it is organized at your company.
Navin Persaud: Yes, for sure. So I reported to our CRO, so we're part of the go to market organization, which is effectively sales, and that's typically what I've seen in my career. I think, once I've reached this particular level, I've always reported into either CRO or CMO. But generally in sales, because that's where the pain is felt. That's where they need someone to help them with the systems, and the process, and the reporting and the data. So it's a natural fit, and a natural home sales affords you the opportunity to be on the same team on the same page, so that you're working with each other as opposed to against each other, which is always great. In order to get things done, get buy in, and to generally just move initiatives forward.
Sandeep Jain:  Understood, and what companies have a separate revenue operations function, do they also have a Sales Ops as a function or is it kind of merged with the Revenue Ops?
Navin Persaud: I think Rev Ops is a new creature in the last few years, it's a buzzword. I think sales ops was more of a legacy term that companies are sort of just shifting away from. In the past, I've seen sales ops, I've been a sales ops leader, and it's really about, you have an MQL, you've created a customer, you have an MQL, you've created a customer like that was the journey. And your role was to operate within that. Whereas Rev Ops is a lot more encompassing is you have an MQL, you have a customer, then you have an upsell, you have a renewal, you have a churn, you start all over again, you have expansion. It's more of a full cycle. And it marries well into organizations where you have a CRO, who owns not only the new customer sales teams, but also the customer success and expansion teams as well. So it's a nice little wrapper.
Sandeep Jain:  Awesome. I think you explained this very well. And I mean, I've talked to quite a few people on that, but I think explanation hits the mark. So thank you for sharing that. And so look, we talked about a Product-Led Growth scenario. So can you talk about the challenges in this journey that you talked about, from a view point of a Product-Led Growth company?
Navin Persaud: Yeah. So first of all, it's great to be working in a Product-Led Growth company. Because here you have great virality in your product, great demand. And really what you're coming in, at least from my perspective, to fix are effectively the plumbing of all the systems and the billing and the process and the lead flow sand how all of that works in behind the scenes. And your hope is you're just trying to fix things and those processes to get out of the way of a product. So that the velocity people can you can acquire new customers that can move through your sales teams, and then into your customer success teams at great speed. Whereas the inverse is if you're not working in a Product-Led Growth company, you're really trying to fix those things to help drive velocity where it doesn't already exist, and that's where it's really challenging. In terms of challenges, I would say, having the ability for customers to self-serve is paramount. Lot of Product-Led Growth companies has the ability to acquire customers. So they would have like an Ecommerce solution where customers can sign up for a trial and then buy on their own. But not a lot of them have the ability for customers to move to different forms of payment. They have to get to a human in those instances. And that's where these bottlenecks start to appear and surface. And if not built and sort of planned appropriately. You run into scaling resourcing issues, because then all of a sudden, this, this big wave of customers who potentially needs to be upgraded or pay in a different way, needs a human to do it. And therefore you need more humans to kind of meet that demand.
Sandeep Jain:  So let's just focus on that. So this is the B2C workflow that you're talking about. And is there like the tools existing tools don't have that. They don't have an answer to that workflow that you're looking for. And you have to build these experiences yourself, or the experience is not great from the like, what's the problem there?
Navin Persaud: Well, this is actually B2B as well. But I find that a lot of Product-Led Growth companies, their product, and the way in which they bill is something that is inherent and built within their product from the get go. And over time, they extend the reach of the product to service billing and integrate with other systems. Sometimes it's not ideal, like it's not the best way or not really what the intentions of the product were solely there to solve for. And then you reach that period of limitation where it's either you, you scale back what the product is, and you buy something that just doesn't well in the market to solve for those pains, you just have to reach a certain amount of growth where you have to make that decision. And in the meantime, you have to make things work with the product you haven’t place, and the structure and a process that's already built into your platform, to scale allow for growth, and give that flexibility and upgrade paths etc.
Sandeep Jain:  Understood. And with respect to this particular like there are two workflows from B2C and B2B.And the tool that comes there is the CPQ, which is workhouses, the product catalogue, do you see any challenges there having a CPQ service these different channels, where your customers are coming from?
Navin Persaud: WithB2C, it's pretty simple. Like you try the product, you like it, you put down a credit card, you pick your tear away, you go, it's really not, from what I've seen, the CPQ use case there, where CPQ is most prevalent is on the B2B side, specifically, where you have a customer putting their hand up saying, you know, I hate pricing. CPQ is really your subscription engine, your ability to understand what the customer needs price of that quote, and then turn it into a customer with a subscription and a contract to be able to amend upsell down, sell churn renew over time. And it's really the management of that engine across 1000s of customers that makes it complex, if not done quickly. And in an efficient way, I've seen significant challenges with companies where they've waited. And then they decided, yeah, you know what, we need to go do this, and the work is just a lot longer, a lot longer. So because CPQ, and the systems I've dealt with are complex, it's that you have to translate or almost rinse everything that what was built into the CPQ framework, so that it can spit out what you need for it to go forward. And that's where all the challenge lies.
Sandeep Jain:  Understood. And then you'll experience Navin, for product like good companies, even for the customers coming from B2B. Is there a requirement for a self-serve CPQ that I don't want to put my credit card, but I'm gonna do a deal of several $1,000 or10s of 1000s of dollars. But I'd still want to talk to a salesperson, is that a valid scenario that companies should think about?
Navin Persaud: Absolutely. For the point that I raised earlier, if you're aren't building a fly wheel within yourself serve engine, your website's always on, and the ability flexibility for customers to buy what they need, without necessarily always having to talk to a human to get it done. You're hurting yourself, because then you're really relying on your ability to scale on the people that you have to service that demand in a timely fashion with the right price points, and all the other administrative actions that follow it. Companies who are Product-Led Growth and build that flexibility in from the start before them the ability to ramp sales teams over time to be extremely targeted, focused on a specific cohort of customers, whether it be in your enterprise or specific industries, or specific product types, etc. that’s really powerful. But if you're really requiring on the humans to service your demand, because you have a limitation of what someone can buy on their own, then you're sort of at the bit at the mercy of the people that you can hire and putting see.
Sandeep Jain:  Got it. And so one side of the CPQ may have been but the other side is a billing for that. Do you see any challenges with billing for both your B2C and B2Bcustomers?
Navin Persaud: Yeah, from personal experience, B2C is a new thing for me, so I won't go into that. I see. That's pretty straightforward. A lot of vendors out there I think Stripe was one of the most predominant ones. From a B2B standpoint, yes, because even if whatever CPQ you decide to choose and use, you then have to play nice with your billing system, a lot of companies that I've been with almost all of them, except for one, use NetSuite, which is typically your ideal stack. And you have to basically have the two systems play nice like you're going to do a set of calculations and understanding of ARR, and subscription and term and everything else and then basically tell the other system, here's what you need to go and do with that data. Here's how you need to create sales orders and invoices and renewals and billing schedules. And at any point, we may send you something else to upsell and down sell, etc. and your systems need to be handling that. I've never seen it. I've never joined a company where that process was great at the get go.
Sandeep Jain:  Understood. Well, from a NetSuite perspective, running subscription billing, do you find this, is this flexible? What do you think about the flexibility of the tools to support the amendments and renewal cases? That's something that is brought by all, every time I speak with somebody who say I have a very complex or unique renewal process or an amendment. And so what do you think about the complexity of the tools or ability of the tools to do service, this core requirement of SaaS businesses?
Navin Persaud: It's never really that can solution, do it. It's almost always do you have the skill in house to make it happen? I've seen this time and time again. So I mean, we just came off of a CPQ implementation, it was a huge lift. We're now sort of like cleaning up thereafter. But now we're focused on the next piece, which is like how do we integrate this data that we're getting on a CPQ, to our billing system, and what needs to change or what needs to be accommodated so that we can automatically send data back and forth. So it's not a capability issue, it's whether you have the skill and hours to turn on the feature functions that are necessary to accommodate. Quite often, I've seen that suite instances really just be stood up to generate invoices, and a lot of manual work being done by a finance team, just to accommodate that. You really don't want to be building like a massive building team, because that's just an administrative burden into GNA. What you want to be able to do is understand the areas whereby you can automate things, so that you can eliminate the time it takes for you to send out invoices, so you can improve the time it takes to collect cash, so that you can keep customers happy and renewing. So you can just be sort of pro active. And so like to recap, it's never the capabilities of the systems. It's the complexity and the resources of skill to actually make it happen.
Sandeep Jain:  Got it. And Navin, any thoughts on usage-based billing?
Navin Persaud: As a customer, I've seen it. So I've bought a lot of SaaS in my SaaS career. You have Salesforce and DocuSign, all these other solutions. And I'm constantly managing how many users do we have available today team, because we're hiring more people. And I need to make sure that I need to either go buy some or use what I have. And some companies do really well, they get you right when you need that license. You know, you can go into their self-serve like Sales force, the greatest example, I can go on self-serve my own licenses right now, whatever I need, I don't have to talk to anybody, will I get a deal? No, but I will get the licenses I need right now. If I'm thinking I'm going to need to make a bigger purchase off to call up my rep, and we'll have to talk through it that way. But night or day that's afforded to me, and that's available. Other companies have soft caps. I've dealt with a number of vendors whereby you can go over we'll catch you on a true up either at renewal or at some interval that you reach through their head. It's easier for me as a customer, because then you know, I can deal with it. It's more of like a deferred pain and it doesn't interrupt my business flow. I sort of liked that model being the vendor. I'm not sure how much I like that model, because I'm potentially leaving some error on the table, or I'm potentially hoping that my team has the right visibility to the reporting to understand where those trips scenarios exist. So they can go after that revenue at the right time.
Sandeep Jain:  Understood. So you're talking about mostly like a seat-based model where your number of seats are growing…
Navin Persaud: Unless you're also referring to like how much you use the product, DocuSign is a great example of that, I believe they have two models. I've used both where you have seat based or you have envelope based. An envelope base where they basically say, you get this many envelopes in a period. And you can just have as many different users in the system as you want doesn't matter, we're just going to charge you based on the number of envelopes you send out. And when you exceed that, we're automatically just going to bump you to the next year.
Sandeep Jain:  Got it. So I was asking more about that use case, which is, as a revenue offset, 1Password,that's if you decide to have usage billing for your own product. I don't know if you have it currently or not. But if it is based on I don't know, number of different sites, or number of different licenses that are stored in 1Password,and you charge your customers on the basis of that, does that add complexity to your own billing, like how you build your customers and how you do your operations for your customers?
Navin Persaud: On the self-serve side, companies like that, not really. I mean, every time you add a user, you get a charge. And when it's done through like systems like Stripe, or otherwise, the get you as soon as you add the user your credit cards on file, you get sent an invoice immediately. Where it becomes more challenging is when you have to move to invoicing as terms of payment, or something other than credit card. That's where you're having to understand that the change in usage, translate it into your billing process, and then issue an invoice. That's where it can be more complicated if you don't have the right systems talking to each other at the right times to actually automate that work. If that work is manual, it's not scalable.
Sandeep Jain:  Got it. I think the first use case which is more an advanced sort of billing, so pre-buy is what you need. So if I'm going from 5 seats to 10, I go and do the transaction on the website, which is going to be simple versus the scenario where somebody has to monitor how much I'm using. And then at the end of the quarter, month or year, generate an invoice based on how much I used; this requires a different billing scenario.
Navin Persaud: Great. Other companies are also adopting like packs or bundles, whereby you can pre buy, you know, like a bundle of 30or 40 seats. And then you can, you know, start using them and filling them upas you go for the company. You get the immediate purchase of that number of licenses straight up for the user, you have a threshold right away that you can fill and then figure out once you get past it.
Sandeep Jain:  Got it. So, Navin, when you look at this from now, let's say 100,000 foot view, B2CB2B,CPQ billing usage. And you look at this whole thing, is there one big challenge that sort of comes out for you saying, well, if somebody would have solved that actually will make sense or make your life easier as a RevOps person?
Navin Persaud: So I'll say this, the start, I love Salesforce. I'm like, I absolutely adore the platform, because it has made a different career for me. But the way that it's designed, unless you have the right skill in house, and your know what you're doing, and you have a plan, you can fall off the Yellow Brick Road in an instant, you can then decide to go and customize a bunch of things. And then realize, oh my god, I should have just configured some things because now it's so much complexity. You know, CPQ is a great product. I've implemented it three times now. And the biggest challenge each time that I've implemented, it was that we didn't start with it. We ended up with it. Because we realized the homegrown or existing process we had just wasn't going to cut it anymore, was creating downstream problems with our billing our ability to invoice, track renewals, understand churn, we needed something systematic programmatic. And moving to that system was the biggest pain every time that I've done it, not because the system is a pain, it's because you have a wealth of migrated data that you have to translate over. So there's advice that I could give to someone, it's don't wait. Don't try and build it on your own. Figure out a plan that's scalable for your business now, and portable life and when you need to move to something else. But if you don't allow for that, you're just deferring a whole lot of pain for your future ops team that's going to come in here and try and solve what you didn't plan for from the get go.
Sandeep Jain:  Got it, got it Navin. Anything about the interface between the CPQ and the billing systems. I think you alluded to that earlier. I think he talked about NetSuite versus and there could be other accounting systems as well, or billing systems, I should say?
Navin Persaud: You really need a partnership there with your ops team or whoever is going to manage your CPQ and your billing systems because you know, your hand in hand, you have one solution, generating quotes and renewals. Another solution highly dependent on that output to generate invoices and ensure payment. They have to be speaking the same language from like how you're recording revenue, if you have ramp deals, what are you going to invoice, is it staggered? What amendments look like? And then related to that is compensation, something that we're not even talking about here, but you have another team and finance needs to figure out how to pay your sellers, and how to incent them, and how to ensure that the revenue and the data they're getting is accurate and aligns to the plans and programs that are in place. So it's not just billing and solving that issue. There's another element of compensation that also has to play nice in this world.
Sandeep Jain:  Got it. And follow up on this. This the management of this accounting system of the billing system fall into the RevOps team or the finance team sort of owns that, I'm assuming it's a mixed responsibility, but I was just curious too?
Navin Persaud: It is definitely a mixed responsibility. One I'm continuing to learn and understand and grow through. And in my world today, if it's in Salesforce, my team owns it in terms of understanding untangling, making sure the data is accurate. We then partner with our finance teams to ensure that their invoices are accurate, and they go out the way they need to go. Finance owns everything, once it's passed it over to their system, invoice collections, all that thing. The ongoing management of subscription is where you really need to ensure that you have the right resources in place, regardless of which team so that you can understand those one offs, those nuances, you know, sales reps will always you know, apologize in advance to all my sales reps, they will always take the simplest path again. And because that's the nature of the beast and I applaud them for it. And I'm always trying to make them have that simplest path. The reality is, you got to make sure it's right, because then you have so many other things hinging off the accuracy of that an accurate invoice accurate comp, a renewal that needs to go out in a year's time, an amendment that could happen at any notice, a notice of churn expansion, etc. All these things hinge off accurate data and your system. And if you're billing if you're CPQ engine isn't accurately you know, keeping track of that data and managing contracts, you've just created a cycle of pain
Sandeep Jain:  Actually a good segue to this is how to structure the teams. Like you have done earlier talked about Sales Ops being more tactical, RevOps is now being more encompassing term. But now there is also this billing piece we were just talking about. So what's your recommendation, how to structure the teams to sort of minimize the friction and maximize your and go to market efficiency, I guess?
Navin Persaud: Yeah, I can talk a little bit about my team, we’re structured into three pillars, I have like a technical side of the team that handles our CRM and all the related integrations. They manage for of our projects and what we prioritize, I have a Reporting Analytics and soon to be managing the subscription or deal desk function. There did generally ensure that you know, the top of funnel is working, pipelines progressing, deals are getting closed accurately, rinse repeat, and then the analytics from that. The third function is a newer one, one that I'm starting up in sort of like the growth ops function. A resource or team of resources dedicated to understanding the customer success business, to ensure that there are renewals and amendments and upsells and growth. A repeated trend that I've seen in every SaaS company had been with, you grow through expansion, you may acquire logos on acquisition, but you grow on the backs of your customers. So ensuring that you have the right level of insight and data around how your customers are performing over time, their health, their metrics, etc. is absolutely vital for that engine to be, you know, firing on all cylinders.
Sandeep Jain:  That's very interesting. You describe that, Navin. And so companies have a customer support function, which is a post-sales support, but there's also customer success, which is post sales account management. Is your customer happy enough? Are we solving their pain points so that you know once the time comes to renewal, you see the flywheel effect at that point. Is this, How is your this third pillar correlated with a customer success team?
Navin Persaud: So shout out to all my customer success colleagues, customer success as a function, they're the quarterback in my mind. If you follow sports, specifically football, they're the quarterback. So sales makes a sale, they get the glory, then it's off to the customer success rep to make you successful. So speaking as a customer, I've worked with some amazing customer success reps that have increased my time to value with their software simply by being a knowledgeable and accessible resource around their product. And that's no different now, like with our customer success mission is ensuring that we have successful onboarding, that we have a single point of contact on all product related questions that were up to date on new feature functions, that we have our renewals on time. Like it's a super important function, because any subscription business cannot succeed if subscriptions aren't renewed. And your customer success function is the one that is totally armed at making sure that happens.
Sandeep Jain:  Got it. So what you're saying is, look, there is a place for customer success as a project manager or as a quarterback to make sure that the account is overall successful. But this third pillar that you talked about, how does that function relate with the overall customer success team?
Navin Persaud: Yeah, partner in crime almost like to help that team, understand their customers, segment them, help them understand renewal, help them coalesce all of the data that comes that companies like us collect to understand the health of that customer adoption usage, whether they're happy, generate a health score, which can then understand customers that are likely to renew customers are not likely to renew, what actions can we take to mitigate? What actions can we take to create advocates and promoters to grow and expand and create virality within your product, and more advocates, all of these things are data points that lives scattered in your CRM, or if you're lucky enough to have like a solution, like a gain site. They live there. But you need people to help pull it out and present it in a way that you can action it on a daily, monthly quarterly basis.
Sandeep Jain:  It's really interesting you're talking about this. Over the weekend, I was talking to a friend, he's a Sales Engineering Director at a security company, they are like the 5 billion in value that file. So they're a big company. And he's like Sandeep, I'm in sales engineering, I need visibility into what happens. It is what is happening with my existing customer accounts. And I think they're using gainsiteas well. It's like, well, I don't know, the visibility into the data that I can give to my team that they can make some sense out of it, and they can start helping them. So his particular ask was, look, I need to find out what features are being used by certain sort of customers like, what are the tickets that they're finding out? Are there about feature requests, which means that you're engaged with the product, or is it about more complaining that, hey, this thing doesn't work? So he's like, I'm flying blind. So can just somebody provide me the data? And so I can kind of relate that comment with what you were talking about, is there's a separate customer success team, but your team is in the middle that can help provide that visibility.
Navin Persaud: Absolutely.
Sandeep Jain:  So very interesting. Another related question, when you look at this whole B2B and B2Cworkflows for a product, lead growth company, is there like one of the minimum number of tools that you think teams off such as yours have to deal with to get things done? Now there's a CRM going to be there, there is a billing system CPQ. Like for usage, would you think about another system? Like how many systems do you think people shouldn’t?
Navin Persaud: Generally, SaaS companies have what I call like the SaaS spinal cord, you've got your marketing automation, that passes through your CRM, and then you have your billing system, and then connected to all of those things should be your product or way to provision it. Those are like the four core things that should be standard in every SaaS company. How are you marketing acquiring customers? Are you managing pipeline? How are you billing them? And then where are you provisioning them? Every SaaS companies should have those elements, it could be all one element. And then you have another element for your product, but they've got them all represented in some way or another. Each of those pieces of tech though, require ownership. So that you understand both the process and the data as your workflow moves through them. Without like naming any names, but I feel like companies tend to focus in one area and not so much in the other and they leave these bottlenecks. For example, great acquiring leads, but don't really think about how to make sure they get to the right humans at the right time so that they can make the right impactful connections to create pipeline, where they have a great CRM and don't think about, how are we going to sell a product? How are we going to price it quoted, renew it, etc. We're having an invoicing system that just does invoices and leads you to hire so many people in finance, because it's all manual. And lastly, don't have a means to provision the product in a timely manner. That's probably one of the things that I've seen in a lot of other companies and that it's super manual, it's not connected, there's no connective tissue when you close the deal, it says it starts here, when does it actually available to the customer for use? Those are all like, I say that the four key areas that you need to have structure and teams around and specific ownership to those systems, and then they all need to be sort of working together collaboratively. So if there's an operational function across those departments, they should all be talking to each other.
Sandeep Jain:  Got it. And Navin, if there's one or two things that you think can solve your biggest pain, what would those be assuming Gods are smiling at you today?
Navin Persaud: Let's play this fictitious example. Let's say in year two, I landed another SaaS company. And I get in there, I'll be like, okay, day one, I wouldn’t know how I'm doing it today, if you're selling anything, if you're just starting out, or if you have at least some inertia, we need to standardize this now. Because the pain, it's a road of pain, to get to CPQ once you have a lot of customers, because then you have this massive amount of history to crawl through to accurately understand all of your customers, their commitments, what they're worth, when they renew, etc, that the project that could be simple, becomes quite extensive. And I think a big barrier for a lot of companies is that, yes, Salesforce is a great product out there. But they feel as though they have to reach to a certain size before it makes like financial sense to get there. Totally get it, they got to figure it out somewhere in between, because like waiting, makes what could be simple, really difficult. CPQ like the Salesforce product, it's not hard to implement. What makes this hard is the time that you've waited, before you actually decide to go and do it. That was that's what makes it difficult. So they need a bridge, that there's definitely a market for companies that are atX to X size, that needs something to just manage that within their CRM in a more structured function. Format, don't do custom will try and build something, find something that's successful in the marketplace, it's compatible, and run with it.
Sandeep Jain:  One thing that's a great piece of advice, Navin, and one thing that I was thought about while you're speaking is if I'm a customer, and I will self-serve experience. Now if I'm dealing with two separate products, one with a CPQ and billing. So I need to self-service experience for buying. So that's brought by the CPQ. But I also need a sales of experience for invoicing. Now, if those are two traditionally separate systems, what happens to me as a customer? Am I looking at two different universes then, or how does that work? Actually, I'm just thinking aloud here.
Navin Persaud: Yeah, from a self-service standpoint, if it's a credit card transaction, it's typically one system. You buy you transact, you get invoice it all in one, sort of stripe is making a killing. It's when you get to limitations in your product, because your product is sort of like an extension or a legacy billing system that is maybe reaching a little further. And you didn't build a way for customers to move from tier one to tier two. And you then say, well, you've got to talk to a human. So there's a little problem, you have to go to a human. And you add, like inadvertently, you're adding friction to that.
Sandeep Jain:  Yeah, got it, Navin. Actually, I was referring to that particular workflow because what I've heard from folks is, look, credit card payments is easy schmoozing. You know, that's everybody gets it. But the problem is when the deal size goes up, your number I've heard is more than $2,000, some companies have limits on how much money you can put on the corporate credit card. So they say well, I need an upgrade for $3,000. I know what I want to buy as a sale person, so could you give me a quote, a self-serve quote that I can give it to my team. And I want to get an invoice as well there, but without talking to anybody. So that's where the self-serve CPQ self-serve billing, and bank to bank transfers and all that thing sort of comes up, which is I think what you're saying is a human has to get involved. As the consumer doesn't want it, the vendor does want it. But it just so happens that that you have to deal with.
Navin Persaud: Huge pain point, think of government entities, nonprofits, companies with you know, certain invoice requirements, like a lot of companies would love to buy self-serve, but can't because they have rules and policies that requires a paper invoice or a digital invoice, or they have a VAT ID or they have some kind of requirement that prevents them from transacting through a credit card. And that almost always in what I've seen remains talking to human.
Sandeep Jain:  Got it. So how do we get human out of the quote of the cash?
Navin Persaud: It's not always how you get out, its how do you ensure that you're deploying your humans in the most effective way as possible. Like, if you're you know, I love sports,so it's a great time loving sports right now with football and hockey and basketball and baseball going on. And you think of yourself as a manager, how do you deploy your players so that they can be efficient and lead you to winning outcomes, and deploying sellers to small transactions that are high volume, that's not success? That's employee churn. That's difficult to manage, it's difficult for your reps to get to quota, your response time suffer. So those are the things that you've got to look for to understand, okay, you've got great volume and velocity here. But you don't have an automated means to. It's all for it. And what you really want to do is put your humans on these larger customers to expand them and grow them. And that's what maybe takes more time. This smaller flywheel stuff that opens and closes quickly, you need a system to do that quickly. You know, there's a stat out there today that says, most buying decisions are 60% made before even talking to a human. And I agree, any SaaS that I've looked to buy, I've already done my research, I've taken as much of my demo, I've gone into G2 crowd or Trust Radius. I've looked at their support documentation. I've done everything that I think I need to do. Then at the last point, I'll be like, Okay, let me see your demo and send me a quote, that's when I'll engage as human.
Sandeep Jain:  That's a good way of putting in. And it's not about taking people out of the equation, but figuring out where they are most useful. And I think that's the big, big challenge in quote to cash today. Awesome. I did hear that calendar bell, a few seconds back. So I know the clock is ticking. So before we let you go Navin, do you have any recommendation on a resource, like a book, or a podcast, or maybe a blog that you want to share with our audience, that something that you identified with, and you want to share why as well?
Navin Persaud: Two things. One, I'm a huge Ted Lasso fan. Anyone who knows me probably knows the character that I fit in really well there. So I won't say it. The book that I've really enjoyed, as I've worked through it, as it's called “The subtle art of not giving enough”. And it's a great book, it really just summarizes that. There's only so many things in your life that really requires all of your attention, and effort to actually like, throw your passion behind it. And really be upset when you don't have the outcome. Everything else just work through it, it happen. Because if you don't, you're just going to stress yourself out. You're gonna have these outcomes, you're gonna have this all around you where people are not going to want to approach you, you're going to be combative, you're just never going to be happy. And once you realize that there's this inflection point in your life where so many so many things that I can manage within my control, to really, really care about and the rest, I still care about them. And if it's out of my control, it's out of my control. And it's a super resource. Mark Manson is the author, the subtle art of not giving a f$%^, basically the counterintuitive approach to living a good life. I recommend for anyone in a high stress situation.
Sandeep Jain:  So between fishing and this book that's how you manage your time, I guess.
Navin Persaud: I do. I try and get away from the screens as much as possible connecting with nature. And it's really for me, it's not about fishing. It's about being somewhere, some quiet some nature, focusing on just a single thing that bobber in the water and letting everything else just kind of like leave my mind. It's amazing. It's refreshing. It allows you to recharge and come back. Focus on the 30 things that enter my mind, the minute Monday 8am rolls around.
Sandeep Jain:  I love this, Navin, and I'll actually read this thing. The book that you suggested is just makes so much sense. While I hear you say that. So hey, look, it's been a fascinating conversation. I wish you the very best of luck at 1Password. The company is doing awesome. That applies for a lot of growth, which means a lot of work. Good work for you and your team. So best wishes there and thank you for your time today.
Navin Persaud: Great, thank you. Take care.