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”.
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.
Hi, thanks. I'm thrilled to be here.
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?
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.
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?
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.
Awesome. So it's like music to data to business systems?
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.
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?
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.
Got it. There's a lot of interesting information. So what I heard is, you using Salesforce CPQ today?
Yeah
And but I also heard you say that you have built a UI on top of that, is that correct?
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.
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?
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.
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?
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.
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?
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.
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?
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.
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?
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.
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?
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.
Interesting, interesting. And how big is the team roughly that is building the, that sort of maintaining William?
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.
Brian, you said earlier that, like do not build your own billing system. Do you still hold true with that sentiment, like as an…?
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.
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?
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.
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?
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.
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?
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.
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?
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.
I love that you said something about MDS, what does that stand for?
NPS, just like net promoter score.
Oh, NPS, net promoter score. Now, I get that. Okay.
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.
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.
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.
Artisanal quote, I’ll remember this this term.
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?
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?
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.
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?
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?
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.
Yeah, thanks for having me. It's been a lot of fun.
