SaaS Cost of Goods (COGs) is the fulcrum on which gross margin and key SaaS metrics balance. SaaS Finance managers have to think strategically as they define exactly how to calculate COGs. More expense in the SaaS COGs bucket brings down gross margin but might improve Customer Acquisition Cost (CAC) - but this can have implications in the long term. On the other side, putting credit card processing, freemium hosting, and even Customer Success in operating expense lowers operating profit but raises gross margin.
At the highest level, SaaS COGs should include all the direct costs for producing and delivering the product that you sell. In the tech world, though, sometimes the difference between product support and innovation is a fine line. Expense categories like hosting, salaries, customer success all require a nuanced approach when deciding whether to put all or an allocated portion into COGs.SaaS FP&A leadership has to get beyond the high-level guidance of GAAP and have a good decision framework regarding COGs. Experienced Finance managers recommend being consistent, as best as possible, through various stages of growth and keeping it simple enough that it can be managed. In our first monthly webinar, SaaS Conversations with Lauren Kelley, we delved into the details of what goes into COGs, and the implications for how you go about making these decisions. Brian Beaupre, Head of Finance at Cisco Cloud Security joined Lauren – the discussion follows.
SaaS Conversations with Lauren Kelley, COGs: What’s In/What’s Out
Lauren Kelley: Hello, everybody. We are live now with our webinar series SaaS conversations COGS - What's In and What's Out. We're going to give it another minute or two for folks to join in, but thanks everybody for joining us right now. Brian and I are in two different places in the Boston area. We got hit with a fair amount of snow last night. Brian, I can see some of your snow behind you.
Brian Beaupre: I don’t know if you can see all of it, but it's a good 15 - 16 inches out there.
Lauren Kelley: We only got about 12 inches, but it was very wet and hard to shovel this morning. My husband conveniently had a hernia operation last week so he couldn't do any shoveling
.Brian Beaupre: Lucky you.
Lauren Kelley: Yes. So as long as we're here, I think we'll get started. Just a little bit of housekeeping. All the phones for the participants should be on mute. If you're having any having any troubles dial in on a landline that usually works better than the computer. And if you have any questions about the topic today, please send them in through chat and we'll answer them as best we can during the broadcast and we'll have a Q&A at the end of the discussion. I've got a question here. Let me just check and make sure if everyone could respond and let me know that they're able to hear. Also, I just wanted to make sure that everybody could hear. Let's see. We've got some questions here. Is everybody able to hear? I'm new on using this platform. Is everyone able to hear could you put your information into the QA? Yes, I'm hearing, yes. Okay, so we can move ahead. Excellent.
So, let me just go back and finish on the housekeeping. Yep some more yesses. I'm hearing ok. So, everyone's okay on that. That's the worst thing that you don't want to hear. On housekeeping also, if you have any questions and you want to continue the conversation after this webinar, you're welcome to go to our website and go to the SaaS QA and continue the discussion.And with that let me get started and introduce Brian who's our speaker today. Brian is the head of Finance at Cisco Cloud security. He came into Cisco with the acquisition of CloudLock where he was the Director of Finance. He's an active and thoughtful participant in the Opex benchmarking community and he's also on the board and steering committee at the CFO Leadership Council. He brings a wealth of finance experience to the discussion after being in senior Finance Management at a range of tech companies, including Agyro, Ipswich, and NetSuite. I didn't realize you were at NetSuite, which is pretty cool.
Brian Beaupre: Yeah.
Lauren Kelley: And for those of you who don't know me. I'm the CEO and founder of OPEXengine. OPEXengine is a SaaS benchmarking platform and community. It's a give to get paid subscription for SaaS Finance folks. We’re an independent community of software and SAAS companies, B2B, SaaS primarily. We've been doing it for over 10 years and we benchmark companies with revenues between a million and about 500 million. So, if anybody is interested in the SaaS benchmarking also, please feel free to contact us after this.
Let's jump right into the topic today starting at the highest level. What's the definition of COGS, the direct costs of producing and delivering the products that you sell. Brian when we were talking in prep for this, you said something that I thought was great. So, I put it down here. How do we keep the lights on and what do we need to do to deliver what we promise to the customer? Let’s start by setting the framework at the highest level of how you think about COGS. Give us a little more perspective on that.
Brian Beaupre: Sure. I think one of the key considerations for all stakeholders here, you know in the webinar is that it is you know COGS is very subjective. You could poll everyone here and get different answers. If you talk about what the underpinnings are of COGS in your organization, it's going to be slightly different, but I think the most important thing obviously is that it's tethered to your business model. And as you had talked about it's really, in its essence, if you had to sanitize it down to just one kind of concise mission statement, it's what are the expenses required to deliver the baseline functionality that we promised the customer during the acquisition process.Now that kind of second part of that definition is where sort of the subjectivity comes in because it has to be tethered to your offer. You know, what do you consider your standard normal offering, what does it involve, is there a kind of an elevated level of support and consultancy with your customers, or is it limited to tech support? What happens from a devops standpoint? So it can get very subjective. But I think the most important thing is to remain consistent and evaluate trends within that consistency rather than get too caught up with the specific drivers and you know, as we had talked about sort of at the outset of this column when we had some of the prep calls that obviously can be a challenge as your organizational maturity evolves, but I think just trying to be as consistent as possible, I think is the most important thing and being able to kind of evaluate trends within that sort of framework that you've set for at the outside.
Lauren Kelley: Yes, absolutely. And that's where when you start thinking about SaaS it gets a little trickier. You can read loads of blogs on this. The following thing sort of big categories typically go into COGS for SaaS company: the hosting expense, the cost of any third-party product or license, the salaries of anyone involved, and that can include your customer support your services. And then there's always the big question which we get all the time is: does customer success sit in or out, and we'll have some discussion about that in a few minutes.But what I'd love to do is, still keeping it at the higher level and establish the framework. When you think about how you've had different experiences at different companies, give some examples where you've really had to go back to that original definition of COGS and try and make a decision. What bucket some expenses go into, whether it's COGS or opex.
Brian Beaupre: Sure. So, you know, I think for example when we look at hosting, hosting historically has been just kind of a pure COGS bucket and I know we'll talk about this a little bit detail in a little bit, but I think let's say you're leveraging AWS, obviously the industry leader there, you know, are you able to take a look and inspect your AWS footprint and understand how much of that are we able to tag and tether to specific sort of pre Revenue opportunities. And so, whether that's development efforts or pre-sales motions it has to do, you know, with hosting something associated with trials things of that nature. And so I think that's really one of the kind of more unique challenges that I've kind of seen in my experience and I think particularly for companies where hosting assumes a high concentration of your COGS. I think it's of critical importance to make sure that you partner closely with your ops team so that you can understand do you have the ability to sort of map what's happening in sort of our internal operations to what we're seeing in AWS and be consistent with how we're classifying those expenses, whether it's opex, whether it's you know, if it's and sales are D versus COGS that sort of thing. So that's kind of one, that's through a kind of a very narrow lens from an AWS standpoint.I think when we talk a little bit about salaries of any one involving who supports kind of the backbone of that baseline functionality, there can be some gray area of nuance there to know about, are you only looking at folks that are involved with help desk and bug enhancements? Are you, say, looking at everyone involved in your baseline tech support? That's even basic or some sort of elevated 24/7 type situation. Do you just put everyone in there? You know, there's a question. Do you allocate some of management or overhead into those buckets? And so, there are a certain amount of you know, subjectivity issues involved with some of these and I know we're going to get to a customer success here in a little bit. So, I'll pause a little bit before before digging into that. But those are just a few examples that we talked about and I know we're going to talk a little bit about hosting in a minute. So, I'll pause there.
Lauren Kelley: Yeah, and lets do a poll of the audience on how they handle hosting expense. While that’s running, let's talk about hosting expense and if we could ask the audience to put in whether they put all of their hosting expense into COGS or if they allocate between COGS as well as opex and we can have some discussion about where those kind of things might go.I think this is also a great lead into the next topic that we were going to talk about is again staying at the higher level because what we're trying to do is here is establish a framework in thinking about COGS. Thinking about the strategic considerations around COGs, there can be a sort of friction or interplay between gross margin, and SAAS unit economics. Okay, we've got a fair number of people who have put in their hosting expense between the two choices. So, let's end the poll now and so we're seeing yes 41% of the folks here allocate some of the hosting expense into operating expense and then 59 or 60 almost 60% rounding up, we put all of Hosting expense into COGS. Well. That's great. Actually. I apologize. I think I needed to hit share poll results. Can you all see that? Can you see that Brian? Okay, great.Let's move on and look at some of the strategic considerations. And I thought it was great also in our pre conversation talking about both. You know consistency is not just the mechanical effort of making your buckets consistent, but you really have to have a framework to keep it consistent specially if you're thinking about going from early stage up to a hundred million and beyond. Obviously, there are going to be changes along the way but you really have to have a good framework for thinking through what's going to go in COGS and how your business model is going to change. Brian, I think you have some good examples of as your business model evolved as you got bigger and bigger you're going to have to do different things to deliver your products and support them. So, I'd love to hear some of your thoughts about that.
Brian Beaupre: Yeah, so we did talk a little bit about consistency at the outset, and I think, you know, a counterpoint or a challenge to that is look you can't, say, stick consistent throughout your entire growth trajectory. It's not going to be feasible to think that, you know, the inputs for COGS are going to be the same at 50 million as they were for, you know, a five hundred thousand - 100 million dollar company. A great example is if you decide to penetrate other markets, or you're moving upstream. Let's say you're making it into sort of the federal space or the or another space and their certifications that are required for this sort of revenue generating competency that you're going to have. You know, that could potentially be something that hits in the COGS bucket and it can be substantial if you're bringing in consultants. If you have to hire for a very niche competency and your spending substantial dollars there that can be a significant fluctuation inside of your P&L, and yet that's one of those things that you can have to call out. Obviously, you can report it, you know, you can call out those nuances and say, you know, if we, look if we pull this out this is what the trajectory would look like across that trend, but you know, it's not atypical that as you’re starting to penetrate different markets you move upstream.From a from a go-to-market standpoint that you're going to have to put different things in COGS that didn't happen before and I know that we'll talk a little bit about the second part of the slide here, which I think is really important as it relates to, you know, why do we try to manage what’s going into COGs? You know, it seems like a basic question we all can probably answer, but I think you can host and sort of the day-to-day disciplining cadence around trying to hit your gross margin targets, which is, why do we want a strong gross margin? How does that triangulate with all the different unit economics and SaaS metrics that are out there? So, I'll pause there and kind of let you can bridge us there.
Lauren Kelley: Yeah just reminds me in one of our SaaS Finance meetups a couple of years ago, a fairly large public SaaS company, the CFO mentioned that they had just made a change, for example, on credit card processing fees and moved it into COGS and previously it had been CAC. And so, this is a company with a high volume, low cost product where credit card processing fees is the only way that they transact and so that was a couple points difference there by making the change. From a public perspective, I think their thesis with investors was that they were still a very high growth company so for them, they were more focused on the SaaS unit economics and in which case lowering CAC even by a couple of points is significant target. On gross margin they could manage to add to COGs there because some of the efficiencies that they had in hosting, their gross margin also looked good. And I think that's kind of a jump off to the next discussion where you've made the great point, that a high gross margin can fund future Innovation, which obviously we all need to do in this industry.
Brian Beaupre: Yeah, and I think it's interesting. I think it's particularly relevant against the backdrop of SaaS metrics, where you know both SaaS unit metrics and Gross Margin are important. For example, yes, it's great to set a goal and to make sure that you can hit that number, but it's intended to be able to fund Innovation and growth and development in your operation. It's not just a pat yourself on the back and say we have maybe, you know, 80 some odd percent Gross Margin which was above our target. Great, you want that because it suggests optimization and profitability at the unit level, and so you’re then deploying those resources and assets elsewhere across your organization to make sure that you're ahead of the competition, that you're innovating, and things like that, and I think you know that sort of aligns very closely with all the concept of SaaS metrics and I think that can get lost a lot of times where folks like the benchmark themselves and compare, and say, oh we're, you know, we're better than them. We are better than the benchmark. When in reality, it's trying to tell you this is when you should accelerate investment. This is when you should throttle back investment, that sort of thing.SaaS metrics really serve as a leading indicator, not the end goal. And I think Gross Margin in a lot of ways can feel at times in our day to day jobs, as you know, the end goal. Did we hit the target we set out? Great, we’re really great, we’ve achieved optimization and consistency. But high achievement there should then be redeployed in reallocated elsewhere in your organization and let you have that competitive advantage and have that differentiation out in the market. So that's been my perspective on it, its been my experience and, you know, I like I said, I think it bumps up very closely with sort of the spirit of SaaS metrics where, you know, it's great to have them, but they're supposed to be leading indicators for how you're going to allocate resources investment things of that nature.
Lauren Kelley: Yeah, absolutely. So, I have a question in the Q&A about credit card fees, a finance person who says they believe it belongs in COGS because it's a direct variable cost associated with the delivery of the service, whereas other executives believe it should be a G&A expense.You know, one of the things we’re doing with the SaaS benchmarking and the metrics community is to help, all these operating people dealing with all the details day-to-day understand how other companies are handling similar issues. Operating a SaaS company is complicated and most of the key SaaS metrics are not defined by GAP. We can supply, if you want to contact me directly, some support to talk to some other folks who are doing it that way.In terms of credit card processing fees and where they sit, I’m seeing it more and more commonly going into COGs because it is part of delivering your service, but there are good arguments each way. Really up to your discussions with your auditors. It's your own internal strategy. It just seems that the trend has turned a bit. I think 10 years ago or even five years ago credit card fees pretty much were going into opex, and now more and more companies are putting them in COGS. So, and maybe that relates to the fact that COGS have been generally going down because of hosting expense.
Brian Beaupre: So that's interesting. My experience has been that they were in COGS across a couple organizations. So, that's at least, we don’t want to give advice or anything like that, but my experience over the last three organizations they have had COGS.
Lauren Kelley: So, then we have another question that says, that not to hang up on this point, does all the billing and sales tax collection remittance belong in COGS. I don't know if I can answer that, and before Brian says anything, he can talk about his own experience and I should have said this up front but remember we're not auditors and every company needs to review their specific policies with their auditors. We have no legal authority here, but we're just giving you experience of what we've seen with lots of different companies. And with that I'll turn it over to Brian, if you have any thoughts about billing or sales tax.
Brian Beaupre: That's actually a great question, and I think it just kind of talks to COGS in general. You can justify, you could justify both sides of the fence as well, which is what I think is fascinating. My personal experience is that has not been a part of COGS, but I could very easily see the argument to say, you know, billing is absolutely a part of the value proposition that you put out there to the customer and it’s part of the end-to-end experience from a customer acquisition process. That's part of the negotiation that we have gone into so I could I can absolutely see that. It has not been my experience that we've carved that out and put it in COGS.
Lauren Kelley: Great. Thank you. So, let's jump into the real detailed questions around all the different categories that are talked about as being part of COGS. Starting off with head count, again, it comes down to, you can talk about what categories of work should go in, and then the headcount associated with that when you're talking about whoever's involved, the different parts of the organization, devops, people who are managing the hosting, all those folks, as well as professional services, customer support, some or all of customers success. But then it gets into, and specially we see a difference with smaller companies versus large companies, a lot of the allocated expenses you might see with a big company like facilities cost per person or IT cost per person or all the different pieces that can be allocated to a fully loaded headcount, oftentimes sit in G&A, or they may sit in some other opex category. Sometimes it's a situation where it just, sort of happens that way because it's easier not to have to allocate and sometimes it's a strategic decision. Well, at this stage of our growth, we don't really care what our G&A is but we do care what our gross margin is, so we're not going to allocate. Do you have some comments about that Brian and what you've seen in your experience?
Brian Beaupre: Yeah. I guess my comments on that will be it's always, you know, it's a bit of balancing act, right? Like you want to, especially in the SAAS community, you don't want to overcomplicate things because then it erodes the value of benchmarking, and so if every organization is getting highly customized with the way that they're allocating COGS across, you know, tech support, whatever it may be, then the kind of value of benchmarking and bumping yourself up against other organizations in a similar cohort sort of goes away. And so, I am always an advocate for keeping it simple whenever possible and not trying to kind of over-engineer the calculations for that very reason to make sure that because if everyone's getting highly customized and fine-tuned, there's going to be no values or bumping yourself up against your peers. Having said that, I could absolutely see a scenario where, let's pretend you were a very small organization where you only have less than 20 employees, for example in the folks involved in devops, let's call it, straddle really 50% of their time on development efforts plus, if we have a handful of customers, you know, doing some sort of Ops work to make sure we're, quote unquote, keeping the lights on, and so at that point do you get into some sort of time tracking discipline and cadence where you're having those folks kind of allocate how much of their bandwidth are they putting towards development activities, how much are they putting towards functionality associated with the current customer and that doesn't feel like over-engineering to me, because like I said, you have a very limited footprint and it can make a huge difference from a pure percentage point standpoint inside your organization how you decide to designate those folks. So, it's sort of a balance, you know, like we had talked about. I guess I'm providing literally no answers here, but I think that's kind of the nuance around COGS, which is, you know, you want to try and keep it tethered to your business model so that it makes sense, but you also don't want to fine tune it to the point where you're going to lose the value of benchmarking as you grow and that you can leverage that really powerful ability to bump yourself up against your peers because of overcomplicating it, you're going to be, you know, you're going to be out of luck too.And so, I think keeping it simple, my experience has been fully loaded head count. But again, I've been with mid-market, larger, and even at kind of the startup organizations that have a substantial Revenue Run Rate where it's not as impactful to try and cut up everybody's bandwidth, so my experience has been fully loaded tech support, no facilities allocation just comp benefits that sort of thing, and so that's kind of what my experience has been. But again, I would not be shocked and would expect that the folks involved here have had very different experiences.
Lauren Kelley: Trying to stay on top of the Q&A a little bit. In terms of hosting, because that's obviously a huge area for COGs. For example, just starting on the list of things we put here, what about freemium hosting? I mean the issue is that most SaaS companies are a fully integrated platform between their product or service, their marketing website, and certainly a freemium offering with upselling to a paid version. I think, first and foremost, freemium is a lead gen introductory pre-sales kind of strategy, and so that's not, you know, that ought to be in sales or in sales and marketing. What do you think about that? And what have you seen, have you worked at any companies that had a freemium offering?
Brian Beaupre: I have, but they didn't have a substantial kind of hosting footprint. But, I agree with you a hundred percent in terms of if you have the ability to carve these things out and track those expenses within your sort of AWS environment, I absolutely believe that that's, you know, part of your numerator of CAC and that it's, you know, fits into that sales and marketing sort of engine rather than a COGS rather than a COGS expense. That's again, that's my limited experience with it. But I do agree that I think it should sit in those buckets and not COGS.
Lauren Kelley: Yeah, and then the issue is that going back to your mantra of keep it simple for some companies. It's sort of hard to carve that out because it's the same people who manage and that can get complicated. I just see one quick question I'll go back to. So the question was, so devops is out? Can you answer that Brian? Do you think devops should be out or in terms of COGS?
Brian Beaupre: I think it depends on; my experience is that devops is in, but if you have an example where they're doing strictly development, efforts, you have to understand, you know, what's going to be the outcome of those sort of development efforts and how much are they spreading their time. So again, my experience, devops have played a much, you know, if you have to go 51/49, they're more so on sort of the baseline functionality of keeping the lights on and making sure you hit those SLAs, but in a lot of ways they are still engaging in some of those development efforts. So, I do think that it's a great question. My experience again, making sure that it's not too impactful from a you know, from a materiality standpoint has been to keep it simple and I have had them as part of COGS on my side.
Lauren Kelley: Okay, great. And onboarding, and to some extent we've looked at it with some companies as to whether it's paid onboarding or part of the product. You know, is it a separate fee for onboarding and sort of a professional service or is it something that you do that you offer or, it also depends on whether it's onboarding before you pay for the product or not? Some companies the eval stage is really the onboarding stage and that's, you know, pre-sales in a sense. So, what kind of things have you seen around onboarding
?Brian Beaupre: Great, it's a great topic. What I've seen, my most recent experiences - onboarding is not a part of COGS. And once again, I can absolutely see the counterpoint to it, which is getting us up and running on the functionality, as you promise to us kind of part of the standard offering. I think the goal, with the allure a lot of SaaS organizations is that you don't have a complicated onboarding process, and so a lot of that has happened in the pre-sales motion and that when you do that hand off, that tech support is able to triage any of those sort of complicated onboarding issues that come up at the outset. So, my experience has been onboarding has not been a part of COGS. But again, I do think that that's you know, the theme of the theme of the talk that depending on the complexity of your offer and what the pre-sales process looks like it could be, you know, an argument could be made to put it in college, but that's not what I've done historically.
Lauren Kelley: Great, and in terms of the next points we have here professional services, tech support. Are there any nuances around that that you've seen in terms of putting those in COGS?
Brian Beaupre: Sure. So, I can't speak specifically on the professional services side of things. So, most of the SaaS organizations I've been a part of have been SaaS only. We don't do, kind of advanced advanced services in that regard. Tech support for, you know, I think for the majority of us, tech support, all hundred percent, goes into COGS and that has been my experience. Again, I'm sure that there's exceptions to that. So that's kind of what I would speak to and then when we get into and I don't want to jump ahead. I know you're going to talk a little bit about audits and things of that nature. So, I'll pause there.
Lauren Kelley: Yeah, I think it would be really good because that's such a great point to talk a little bit about audits and you know also, as you mentioned, we were talking about it when you think about, you know, or how do you even think about future new markets You might go into one that might require different audits than what you're doing right now and trying to keep that relatively consistent. While you do that, if you could talk about that, I'm going to try and launch a poll and I'm going to add a third question.
Brian Beaupre: So, all right. So, I think the, you know, the certifications, it's my experience, for example, has been from a Federal standpoint. So, if you're start trying to penetrate the Federal market, you have to work toward certification. So, you hire consultants, you know full-time FTEs. Where does that go? Because one could argue that that's very much a development activity. You don't have it yet, you're trying to get your offering up to the standards that are required by this goal, but then the converse of that is in theory, this is going to be a revenue generating certification for you moving forward and obviously COGS has to get matched up with revenue. And so the you know, the decision that we had made, is that certification to penetrate this Federal space when it's a COGS, you know, and we decided at the time, you know, regardless of the debate that we might have internally, or the other folks might challenges on why we are making the decision, as of now, everything tethered to this objective is going to hit that bucket so we just wanted to make sure that we remain consistent despite the fact that I think, you know, an argument can be made, it’s building towards functionality that you don't currently have right now. But then, what we're looking at is, we're mapping it towards. It will be part of the baseline functionality that we have out there in this space with those customers and will be a revenue-generating asset for us. And so, I think that's the way that we've looked at.
Lauren Kelley: Okay. That makes sense. Well, let's jump into the always popular discussion about software capitalization and what parts of that go into COGS or not. I'll tell a little bit of a story there, and then while Brian's talking, I'm going to try and run a poll. You know, we run what we call the SaaS Finance meetups, Brian's participated in the ones here in Boston, and we typically do it in the Boston area and in the San Francisco Bay area, and a couple of years ago, I think it was 2015-2016, we went around the room in Boston and asked all of the participants, what percentage of software do you capitalize and the answers ranged from 0 to 75%, and about a week later I asked the same question in San Francisco and pretty much everybody was at zero or maybe under 10%, and I thought it was so Interesting that it was such a difference. And then, for a couple years, the issue sort of petered out. We stopped asking the question and everyone was like, oh, you know, nobody capitalizes software anymore in SaaS. And then as you know, Brian, recently in December we had that conversation again at the SaaS Finance MeetUp here in Boston, and it seems like it's come up again, and I'd love to get your thought about how you've seen that evolved and what companies are doing.
Brian Beaupre: Yeah. And so there's been industry documentation on this recently. I don't remember the exact code there, but you know, if you are hosting the code on your servers, there is an argument that could be made the year again generous of the concept of this revenue generating asset, and so that capitalization, which historically, like I said, traditionally sat in an opex bucket you could flow through COGS in that perspective where again, you know, an argument could be made that the development that you're making is going to be towards a revenue-generating asset and you're, you're hosting the code on your servers, that this is a future revenue generating asset for the organization, and so that those expenses that are being amortized can get run through COGS rather than opex. And so that's somewhat of, again, nuanced and more recent thing. But I do think there are specific components of that characterization, particularly around are you hosting it on your servers, is it your code, you know, is it the expectation that it's going to be a revenue generating asset? I think if it checks a lot of those boxes, a very strong argument can be made that that capitalization gets run through COGS.
Lauren Kelley: Great. Thanks. So, I’ve just launched this poll. Do you capitalize any software development and also started on the question of do you put all of your customer success expense into COGS? So, let me end the poll now. Is anybody, you have 30 seconds more to participate in the poll, and I guess, well doing that we have this, I can move to that slide. So, I will end the poll… still getting people putting information in. About 70% of you on the line now have participated and I loved the statistics. I wish my whole life could run this way.
Lauren Kelley: So, 63 percent of the participants who took our poll do not capitalize any software development and 37 do. If you want to throw into the Q&A what percentage you're capitalizing, be happy to read that off. It's a little difficult without any context because I think there is a big difference between big companies, small company, different business models, etc, etc. And amazingly the customer success expense question in COGS or not in COGS is equally split between 50/50. So, I think it remains a somewhat controversial question. Anyone that can jump in and break that tie can I vote?
Brian Beaupre: There's someone that kind of jump in and break that tie. Can I vote?But I think, that's I mean, I think that that's not a typical to see to see that sort of split because it is kind of very much tethered to your business model and what you're out there promising to the customers, and so for us, our customer success are very different than tech support, their compensated differently, the motion is very different, it's a very much sort of this elevated level of almost consultant type work. Where how are you leveraging this to drive your business and how can I help you sort of highly customized your instance or make sure that you're deploying it in the right way versus triaging sort of the day-to-day things, which is kind of part of, how do you use our functionality. So that this is what we promised, not necessarily, how do you leverage this as a strategic advantage as a differentiator, and that's sort of what our customer success organization is done. But again, that naming convention can, you know, can be implied in very different ways. So that's just been my experience with that, but that's really fascinating to see it so split but also not entirely surprising.
Lauren Kelley: Yeah, and I think you know one of the things that we haven't talked about but we see or and we've talked to a lot of people about this that when you are trying to figure out whether customers success should be in COGS versus sales and marketing, what are the comp plans for the customer success people? If they are comp’ed directly on revenue generation, renewals, expansion, whatever, then absolutely you have to look at it as a sales and marketing expense. Or, there may be some component if you want to break out some piece of it and allocate it to COGS. But again keeping it simple, we find, if customer success is sitting in sales that's another indicator versus more and more companies are setting up a structure like a customer group and we've seen some really interesting structures where you have customer success and product management sitting in a group under, someone who is the Chief Customer Officer who's not the salesperson and is not specifically tied to revenue, but more to retention and you know overall numbers as compared to specific, quotas like you'd have in sales.The original discussions maybe 10 years ago when people start talking about customer success in SaaS, it was much more about a group that would be dedicated to engagement with the product. And you know, if SaaS is all about acquiring customers and then engaging with your customers, it makes sense for customer success to be something that is separate from sales and is something that is part of COGS. It really comes down to, I don't think there's a standard organization and organizational structure and targets for customer success anywhere in each company does it differently? Would you agree with that?
Brian Beaupre: Absolutely. Absolutely. I think it's a great way to put it. Unfortunately for me, our customer success flows are not compensated based on renewals retention rate or pegged to anything there and they're still not in COGS. So, we sit right in the middle of that nice gray area that I've referenced countless times during this during this call. But I do think that that's a really important marker to call out.
Lauren Kelley: Absolutely. I'm going to try, Brian and I wanted to try and keep this to about 30 - 35 minutes, and then also to encourage discussion. We’ll keep answering questions as long as folks are on, but that kind of covers most of our main topics. We have a lot of questions here to answer. I do want to also mention that OPEXengine is running a free Sales Planning Survey. It's sponsored by our partners, Adaptive Insights and InsightSquared, and we're running it. It's all confidential and participants will get the results, but not relating so much to COGS, but some super interesting information there.So, let me now go back to some of the Q&A. I'm going to just sort of work through some of this. There was a question, just Brian, just to clarify. I'm working kind of backwards through all of this, so I apologize up front for getting different pieces of the questions. Brian, did you say that your customer success question costs are not in COGS?
Brian Beaupre: They're currently not now. It's not a substantial amount of dollars, but we have not put them in COGS, that's correct. So, they're still there in that kind of a separate group. They don't roll into sales, but they are considered operating expense.
Lauren Kelley: And then another comment, is not capitalizing development is a missed opportunity to leverage the tax benefit? And you know, I think that's definitely true. But it also relates to the size of your company and the type of company that you have, right?
Brian Beaupre: Right.
Lauren Kelley: What do you know about that Brian?
Brian Beaupre: I can't say I see I have extensive experience as to the tax benefit tax benefits there, so happy to talk a little bit about that offline with the folks involved.
Lauren Kelley: And then another follow-up question. If you do not capitalize software, then should you allocate engineering salary cost based on time spent, on maybe future revenue generating functionality in the COGS?
Brian Beaupre: I certainly think that that's a good discipline in a good process to go through. I think the challenge that you have is that you know at some point aren't all development activities geared towards generating, you know, revenue generating assets. And so but I do think that's an important discipline and an important muscle to have is if you're able to kind of establish that line of demarcation, you know between revenue generating assets versus non again, I could you know, I could make the argument that all of our development opportunities are for, you know, future products enhancements things that are going to generate revenue. But I absolutely would think that that's something you want to take a look at if you had the ability to differentiate cleanly between two.
Lauren Kelley: Yeah. I think and I should mention I've gotten a couple of questions on this. The slide deck will be available for everybody. So, everybody who's registered can get a copy of that and they can also get a recording of this. I think one other question here that I think we haven't answered. Oh, yeah, actually it's a comment in B2B SaaS companies there's often things like data migration training, train-the-trainer, help which is optimizing the use in the value of the solution. So those are some more sort of granular items that you would think about. Do you have any comments on that? And especially, you know, I should mention, Brian you're going from an innovative smaller company to dealing with Cisco, and let's just say a very large company with a lot of hardware and a lot of different perspectives about COGS. Be fun to hear some of your comments about that.
Brian Beaupre: And well, it's a fair kind of characterization than the nice part for us is that where we're at the forefront of SaaS at Cisco, so the organizations that I oversee, was actually the first outside of WebEx, which was done quite some time ago, SaaS Acquisition they've done in quite a while and they acknowledge that is a very different cost footprint and a very different kind of COGS non-supply chain motion than they're accustomed to. So, for the most part it's actually been much more educational and questions asking on their part is, anything else, they're very inquisitive.And as you know, as Cisco tries to make this transformation towards cloud and recurring revenue in the next few years, they're very much curious in terms of, you know, this is an important topic for them, like how do we leverage COGS as strategic asset for us to fund growth, you know, in these different business units that we have and so you were talking a little bit about data migration, optimization. You know, in a lot of ways I look at the way that I've, you know, had a say in how our customer success organization has been where they sit between objects and COGS, and I almost view them in a lot of ways as kind of an optimization engine as part of our exchange. And so, I have not had those expenses in COGS, again like I said, it would be interesting to learn more about your specific product offering and how that, you know, and how that relates to your interactions with customers. But I almost view kind of the customer success through the myopic, admittedly myopic lens that I have right now, as sort of a bit of a kind of escalated optimization function within our organization and not necessarily, have we given you everything that you need to leverage our product as we promised you, that sort of thing. So that's my take on it, but again, it's a, you know, it's an interesting discussion and one that can be had many times over.
Lauren Kelley: Yeah, no, absolutely. Here's a last question, then I think we'll wrap up and what I would encourage everybody to do is, we'll create a topic in the SaaS Q&A and anyone who wants to continue the conversation and maybe, Brian, you could help participate in that and answer questions that people have may be following up on this. I know you have a day job too that is a lot of a lot of work, but that would be great to encourage the sharing. So this question is, what are your experiences on product maintenance if our product development or devops develop new features, but also maintains the current offerings? Should that time be broken out between R&D and COGS?
Brian Beaupre: I would say yes. If you have the ability, granted, to have that granular distinction, I would absolutely say they should be broken out. A lot of times it becomes pretty murky and administratively challenging to do so and that's where I can think you kind of want to err on the side of simplicity, but it's good to do the sensitivity analysis too, particularly, if that's going to be impactful for the gross margin optics that you have out there. You know do a sensitivity analysis, then look if we just decide to keep it simple and go all in on either side of the fence. What does it look like for us, but then understanding where you're going to go in the future?I think if you have the ability to do so, you absolutely should because, again, if and when you ever do get challenge from an audit perspective, you're very clear in terms of, and as long as you document, you know, how do we vary crisply articulate what are the development efforts versus maintaining the existing software? So, I think if you have the ability to do so and it's clearly documented in your consistently leveraging that moving forward. I absolutely think you should
.Lauren Kelley: Yeah, that kind of gets into some of the discussions we've had in the SaaS Finance meetups about how do you get that granular? Do you do it based on time sheets? Do you do it based on cost categories or do you do it based on the VP of engineering saying, well, these guys are spending about 40 percent of their time on that and 60% here and like you say if you document it and are consistent in your methodology. Maybe that's the best you can do.
Brian Beaupre: You know, I think a lot of it goes into how you're building your organization too. Any good SaaS Finance leaders going to ask probing questions and inspect how are your people spending their time? And so, I think from a staffing perspective that's an important thing like do we want all of our R&D folks kind of splitting their time between these two things. And so hopefully you're going through that discipline in that cadence on a regular basis because I think you can inform how you want to staff and how you want to kind of build your products and sustain your products moving forward. So, I think it's you I think it's an important muscle to have to make sure that you're doing that sort of inspection because I think it's hard to scale. If not impossible to scale with having your R&D organization. So, to splitting their time and so I do think it's an important thing to make sure that you're running sensitivity analysis on but not doing it so that you can engineer towards a number, but understanding how that fits in with your business model and how that fits into their scalability.
Lauren Kelley: Yeah, absolutely. Well, this has been so great. Thank you, Brian. Thank you to the audience for all your great questions. Really appreciate your taking the time today, even on a snow day where you're juggling lots as I know and for providing terrific real-life context to some of these discussions again. I can only urge everybody on the on the call to join the discussion on www.opexengine.com and you look for the SAAS Resources. We'll try and keep the conversation going. COGS and what goes into COGS is evolving issue for SAAS companies. Thanks everybody. Thanks, Brian, and thank you to the audience. Bye now.
