Sandeep Jain:
Hi,Welcome to the 9th episode of the “Enterprise Monetization Podcast”. And this is your host, SandeepJain. In this podcast, we invite thought leaders from monetization space thatCPQ and billing so that you can learn about challenges, opportunities and best practices in monetization. Today, I'm super excited to welcome our guest Arnon Simoni.He's a product manager at Pleo. We typically invite people from RevOps, sales and finance but Arnon is unique in that he is a product manager instead. So, we'll have interesting conversation today. For folks who don't know about Pleo – it is a startup that offers expense management solutions, Arnon is going to talk more about that later. Prior to Pleo, Arnon was at SQream where he was a product manager and earlier, an engineer. And before that he was part ofIsraeli armed forces.
Arnon Shimoni:
Pleasure to be here, Sandeep.
Sandeep Jain:
Awesome.
Arnon Shimoni:
I wouldn't actually say that the armed forces was like a major part of my development into a product manager or billing or anything like that, but thanks for the intro. Happy to be here.
Sandeep Jain:
Absolutely. Before we go into the depths of billing and CPQ could you share a fun fact about yourself?
Arnon Shimoni:
When I was about 15, I had a website. And that website was a link aggregator. This was a while ago, it was kind of before Reddit / Digg. And, I'm kind of showing my age here, but and we would host like funny games and videos. At the time, it was kind of like to take your mind off of work. It was very safe for work kind of thing. I was not really aware of all the non-safe for work things yet, really. And we hosted a little flash game that apparently made fun of McDonald's. And at 15, I got served from McDonald's threatening me to remove it, or else I was liable for something like $100,000 a day in damage. It wasn't my game. I didn't make it. I was just linking to it. But it always makes for an interesting story when I tell someone, I got served by McDonald's, but not in the way that you would typically get served. I was not happy about that. That really scared me. So that was my introduction into how things work, I guess.
Sandeep Jain:
That's a very interesting and unique fun fact, if there was one. And can you tell your journey from there till now as a product manager at Pleo?
Arnon Shimoni:
After the military, I was thinking, okay, what can I study? And I actually studied something completely unrelated which is communication systems engineering i.e., how do systems communicate? Mobile phones, first iPhone era, and communication systems were all the rage. And I got exposed to functional programming as part of that through a programming language called Erlang, which was highly used in telecom, of course, and finding a job in that space was hard. Instead, I ended up going for a job in Haskell, building a SQL compiler at the company I worked at previously called SQream. We were building like a data warehouse for really, really big datasets. It used GPUs for acceleration, kind of like cutting edge technology stuff. I ended up doing a bunch of roles there. I started as an engineer, then later I did a lot of kind of solution architecture. I was, of course, part of like the sales cycle, I was presales mostly doing a little bit of post-sales. And that's where I kind of got exposed to filing my expense reports. For every trip, I would have to spend a lot of time collecting the receipts and then filing the expense reports and waiting for reimbursements. But also, I was exposed to kind of how enterprises work. And we were working with like the biggest two three letter companies that you can think of around the world. I'm not going to name any names, but like the biggest companies in the world. And then when COVID hit I kind of wanted a different job where I could be around people, as I was working remotely. So, I joined Pleo, which is a company here in Denmark, which deals with expense management. I kind of felt like I had suffered through the bad expense management process. And I was happy to see someone was taking it on and doing something different with it. And when I joined, they asked me, you know, would you be willing to take on billing? And I wasn’t really sure what that meant. Because to me, all these kinds of things, it's a FinTech. So, invoice and receipt and billing and payments, everything kind of melded in my head into one kind of thing. I'm not, I wasn't very good at like managing my finances and stuff like that, which I probably shouldn't say. But I ended up kind of like, being tossed into the deep end with billing. And I found it incredibly interesting. It's very challenging to not just do okay, but to get it right and get it right for not just for the company, but for customers. So that's how I ended up in billing, and I've been there for over a year and a half now.
Sandeep Jain:
So awesome. That's an amazing story. So Arnon, let's talk about that. Like, why do you think companies need a billing product manager? For Pleo it may be relevant as you are in the business of expense reports which is related to billing. But do you think that startups in general, let's say SQream, your previous company, would need a billing product manager?
Arnon Shimoni:
I guess it really depends what kind of product it is, how you package, how you deliver it. Because for most enterprise software, like SQream, the way that it works is kind of like traditional, you know, you do a POC or a pilot, and then the company puts out like a purchase order, and then you begin fulfilling. So, the actual payment happens offline like between CFOs, or between finance departments with a bank transfer. And it doesn't really matter if it's late by 30 days or 60 days, you're still going to get the money and that kind of works for that more traditional industry. When the company when SCRIM also was going towards the SaaS route, I remember, we partnered with a company that helped kind of sort out the billing for you. So they would help you sort out all the metrics and calculate how much needed to be paid. And it was kind of opaque to us. Like, I don't remember that we could really understand how much we were, you know, collecting how much we were actually, you know, what the expenses were on that. And I've also had this kind of argument at Pleo when I joined, I think some people told me oh, you know, we shouldn't really be having billing product managers, we shouldn't be dealing with billing at all, we should just, you know, focus on what we do well, and kind of offload it to a third party company or a third party service, of which there are plenty, there's more than one billing service that you could go to. But I actually think that those services work for a very specific industry, maybe kind of very B2C, where you have a small set of products and services, or a very, very kind of light enterprise, maybe. But it doesn't work for a complex product. And specifically, it doesn't work for enterprise products, where customers expect a little bit more of a tailored service where they might kind of want to tweak and add items, remove items that where they might have different payment terms that that they would want to apply. So that's when things get complicated.
Sandeep Jain:
Got it. And could you talk about the payments team or the billing team at Pleo? Like, how big is the team? How many engineers does it take? And do you build everything, or have you taken third party tools in the stack at all?
Arnon Shimoni:
Yeah, so the billing team right now is about seven people, like six engineers plus me. And we are part of what we call the RevOps domain. So we sit together with other RevOps functions, so sales, Stop Market Ops, you know, sales enablement, those kinds of roles. So we're kind of close to them. And we're also kind of close to our finance department, which of course, are the ones who care about the end result of billing. But actually, our finance department owns the billing process. So they get to define, you know, what kind of payment terms do we give and what happens, you know, how do we accept payments even? So we're very close to them. But we are an independent group. Like I said, six engineers plus me. We used to be bigger, but actually, we actually split the team into two individual components into two individual teams. One of them focuses a little bit more on the commercial tooling around how do we interface with billing, making sure that we're building like the right kind of forms to do the CPQ process and make sure that we're integrated with our CRM, and the other team which is kind of the core team focuses on the infrastructure. So together, we're 12 people actually plus me. But we have seven people on the core billing infrastructure group. Now that team builds its own components and has kind of like a dependency on third party. So we do use third party billing services like Stripe, for example, we do use Stripe in our billing stack. But Stripe is actually only a relatively, it's a major part. But it's a small part of this entire piece that we call billing. Because as I mentioned, we have our own CPQ tooling, we have our own interactions with a CRM, I don't have any like you know, a sales rep or a BDR going into stripe and configuring billing directly. They work through our system, which kind of abstracts most things away from them.
Sandeep Jain:
So if I understand this correctly, you have built both a CPQ and billing system internally at Pleo?
Arnon Shimoni:
Yeah, that's true.
Sandeep Jain:
And this system, this integrated system, is it hooked to your CRM, I suppose, because salespeople need to Quote out of some systems?
Arnon Shimoni:
So yeah, exactly. So our salespeople work primarily in our CRM. And then we have, for example, we have a back office where we manage more than Customer Care style things where we manage renewals and that and we have our billing system, which we kind of as I said, we tend to abstract it away, so that most people never need to go into Stripe or interface with our billing system directly.
Sandeep Jain:
Got it. And do you have in terms of sales motions, is it just direct sales, or do you have self-serve as well?
Arnon Shimoni:
Yeah, we have both. For self-service, it's rather easy, we have about three plans that you can go into you sign up on the website, we are a financial product. So you do need to go through a due diligence process where we, you know, verify your identity and we make sure that it's actually a real company. But once you're done with that, you are on one of three plans, which are fairly, they're fairly standardized, they have each has their own set of entitlements, and it's pretty clear. Whereas with kind of sales lead motions, a customer may still sign up themselves, but then we would configure their product differently based on a contract that we signed with them.
Sandeep Jain:
Got it. And do you guys do amendments as well, like, if I'm a customer, I come in the middle of the contract, and I say I'm gonna buy more, or I'm gonna buy something different from player?
Arnon Shimoni:
Absolutely. You can upgrade you can downgrade, you know, it's, it's really based on what the company's needs are and, and whether we're delivering value to them. Because if there's no, you know, if the company isn't that our customer isn't getting enough value, then they're not on the right plan. And sometimes that's, by the way, a really hard thing. As someone who is, you know, kind of focused on the revenue. Sometimes it's hard to see customers like downgrade to a free plan, which of course we do have. But if it's right for the customer, you know, then then that's what it is. And we don't put any kind of blocks in letting people upgrade or downgrade themselves.
Sandeep Jain:
Got it. And to the workflow that you're describing, I suppose many B2B SaaS companies would want a similar workflow. Now, if they are listening to the podcast, they might think like, should I create this 12 people team to build the CPQ and billing, or do I buy something from outside? So I know, of course, you guys decided to do on your own. But do you think it's, and the reason I think you mentioned was what is out there is more B2C and it's not customized to what you guys are looking for? Yeah, is this something that you still believe as true that there's sort of like nobody has addressed this solution in a way that the needs?
Arnon Shimoni:
I think there's a big kind of gap in that market, where if you want to do like, if you want to play with pricing, for example, if you want to do like price optimization, then a lot of the current tools is Stripe included, by the way, which of course, like I said, we use, but these tools kind of aren't meant for that, and then you have to hack around them. I think there's a really big opportunity here. And I know there are a few kind of new players coming up that hope to solve this. But I haven't seen that yet. Building a billing system is incredibly difficult. It's incredibly difficult to get right. And that will depend on your complexity. So one of the things that we do, for example, at Pleo and this is the reason why I would say I would still keep it internal. And I would still build it ourselves is first of all, we're playing around with a pricing quite a lot in recent years. Because pricing is an art. It's not a science. We can't say Oh, this is a good price. It worked for another company. We can just take it and it doesn't work that way, prices are very kind of emotionally loaded and highly specific to, you know, between geographies. And we like to retain that ability to play around with that. But more than that, we actually have a little bit of a different way of collecting payments. With most SaaS products, you get your credit card, and that gets processed or you receive like an invoice and you pay it through your bank through a direct bank transfer. But with Pleo, the money is actually kind of hosted at Pleo. Because in order to use Pleo, you actually have to kind of load your wallet. So we collect payment from the companies’ wallet, and then we don't need the same kind of payments, collection infrastructure, because it is our payment infrastructure already. So using a third party solution actually, would be a lot more costly for us in that regard. But I would say the main reason is still kind of flexibility and being able to build around the limitations of whatever product you choose. And each different product has a set of limitations. Most of them are actually quite surprising. I recently did like a big review of all the billing systems that I could find, I got asked by both our CFO and CRO, why, why are we still on this, you know, homegrown billing system, I've heard that this other billing system is really good. And then I look into it, and I realize, yeah, like, if you look at a checklist, it looks good. But when you actually get down to the interactions with it, it's a really, really big pain to use. Now, I don't want to name any names, but each different billing system has so many limitations. And I think just getting to know those limitations would take many, many, many months of engineering time.
Sandeep Jain:
Why don’t you talk about these limitations?
Arnon Shimoni:
Yeah, so a lot of the newer kind of systems, they will try to have everything in one system, they will kind of like abstract, they might like still use Stripe underneath, but they'll abstracted for you to some regard. But then, for example, you can't do a one-time, you can't create a one-time invoice for your customer which is a kind of a weird limitation. Because in the most trivial cases, that's not necessary, you don't need to create a one-time invoice you the customer signs up, they use, they get charged for whatever they use. That's the all the new systems are like very usage based heavy. But then you can't create a one-time invoice or you can't apply a discount, or you can't change the price for that specific customer without changing the price for all customers. So there's all these kind of weird limitations which from a mature product, I expected more, I guess, then some other products won't let you use calendar kind of set dates for subscriptions, they won't let you reset the billing schedule, they won't let you anchor the billing schedule to another date. Some products won't let you control the proration. So proration is, my team will hate me for talking about proration. But you know, when you move from one plan to another, you need to prorate because the customer maybe is already paid for a duration for the upcoming period. And you don't want to charge them again. So you need to kind of like do a calculation, give them some money back, take some more money. And a lot of products don't let you control that or turn it off even they only have one mode and it's on or, you know, they have all these kind of weird remotes that that make a really big, like cut a really big headache for the people doing the reconciliation afterwards, or if you're being audited, God forbid, then you might get questions on why was this person billed twice? Well, you know, that's just how the billing system did it. So there's all these weird limitations where you're not going to see that in the documentation. But once you start playing around with these systems, you'll realize this doesn't do right by my customers. And this doesn't do right by my finance department. And that's really hard, that's a really hard pill to swallow for me. Because these are the two that I care the most about. First of all, my finance department care about them very deeply. And also for you know, legal and bookkeeping and auditing reasons, I have to do right by them. But then also my customers. I don't want to build them twice. I don't want to make mistakes. I don't want to give them the feeling that, you know, they're getting the right end of the deal here. So the billing system kind of have to take that into account. And sometimes, you know, you have to kind of forego revenue in that regard. Like my finance department will always say, yeah, keep proration on, sometimes the best result is to keep it off, and kind of forego the revenue that you would otherwise be making. If you kind of upgraded them in this specific month. I would rather give them like the higher product level without charging them extra for this month. And, you know, I seem to have a lot of discussions around that as well. But for me, sometimes the good the correct thing is to kind of give up some of that revenue that we would otherwise collect.
Sandeep Jain:
This is awesome. I have a few follow ups here. First of all, did he get the blessing of your CFO and CRO to keep you guys building the billing system?
Arnon Shimoni:
On some things, yeah. But to be honest, we've built it in such a way that it's probably the most scalable solution for us, and at least medium term. So in the next couple of years or so, this decision may change. In a year or a year and a half, we may want to say, Okay, we need to rip out some infrastructure and replace it with something else. I think once we're a little bit more stabilized on this is how we want to do business, this is how we want to price things, then that becomes a little bit of an easier choice.
Sandeep Jain:
Got it. But do people see advantage of building it or building this thing in house? Because there is a pay, like there is a 12 people team here working on this? So does the company feel that, hey, this is a good decision we did?
Arnon Shimoni:
I don't, the truth is for billing, most people don't like thinking about it. Unless as long as it works fine, no one cares if you're billing, not billing, the money comes in, we don't care. This kind of discussion only comes when something breaks. And then the question is, oh, shouldn't we have gone with another product which might have been more stable, or maybe, you know, we pay them. So they kind of owe us and you know, if they screw up, then they will have to get the consequences of that. So I haven't had a lot of these discussions because luckily that hasn't happened or system hasn't failed in the last two years kind of that I've been touching it. But I think for the most part, I've convinced both our CFO and our CRO that the flexibility that we have now, and we're making good use of that flexibility has actually come in very, very handy. We've done at least two pricing changes since I joined, we've changed our tiers, we've added new tiers, we were like playing around with the packaging, we're adding removing features based on you know, market research and talking to customers, of course. And we're also doing, I'm using this term quite a lot, but we're also kind of doing right by our customers. And we always have them retain the feature sets that we promised them when they signed up. So even if we remove features from, like one of our new plans, and we move them to that new plan, we have them retain their feature sets. And that's something that we're only able to do because we've built, we've separated kind of our entitlements engine from our billing. And most products don't let you do that, you can't kind of like set entitlements for a specific company unless you go the 100% custom route. And that could mean that you break up your product into many, many, many different like, you know, different line items, which you can do by crates for a different kind of messy experience on the both on the CPU side, but also on the customer's invoice at the end of the month.
Sandeep Jain:
Interesting.
Arnon Shimoni:
So we've been playing around with that. And I think we have something that actually really works. So I think I've convinced the relevant stakeholders and sea levels and VPs that that what we have works well and can continue to support us in the near future.
Sandeep Jain:
Got it. Let me ask you this a different way about the customers, you talk about doing right by our customers. But do your customers come to you explicitly and say that, Hey, we love the way you bill, or is the fact that they don't complain about it is a reward in of itself, you see what I'm saying?
Arnon Shimoni:
Yeah, I find it a little bit difficult to ask our customers about billing because like I said, no one wants to be build. We actually have had customers you know, reach out and say, oh, we actually have this feature. We didn't see it on the invoices, is everything's still okay. Do we, like are you removing this feature from us and sometimes they have actually come across situations where they were misconfigured at least from the billing side, the product was working fine, but we forgot to charge them for something. Which is honestly something I prefer to the other situation where we build them for something that they don't get. I mean, we still make mistakes. And some of these mistakes are because of you know, someone forgot to do something, or sometimes it's because of the weird edge case where a customer, for example, upgrades their plans and downgrades and upgrades next day and then downgrades again and does all these weird things. And that can sometimes cause problems. So it does happen that customers are built wrong, we will try to be proactive about those things and fix it before the customer notices. And many times we don't even tell them that we've had to fix some something for them. But you know, we have customers who really, really care, they care about the product that they're using, they care about, you know, the longevity of it, and will it be able to support them into the future, and a lot of them are happy to pay for the service that they're getting. So we do hear them quite a bit on a variety of topics. They're very engaged with us, we have get a lot of user feedback. Most mostly good, a little bit of bad stuff. Of course, there's always no, it's the truth is, you know, no product fits all customers. And sometimes they think, Oh, I'm getting like a bank, and we're not a bank. And then there's sometimes a little bit of questions around that. But for the most part from the billing perspective, I think most customers are happy to pay, and they're happy to pay the correct price.
Sandeep Jain:
Got it. You talked also about proration. And I want to talk a little bit more about this. I use a product. It's a product Led-Growth company $3 billion valuation, so they have like plenty of customers. And they have a self-serve, great plan. And I went there, and I upgraded my plan. And the thing was, it was very sneaky. They were charging me for the remaining period for the new plan but they were not refunding the money that I had paid earlier for the remaining period. And the amounts are very small, like there's like $100, or like $150, or something like that. But I as a customer felt cheated, that either you tell me beforehand when you're doing this upgrade that look, whatever money you paid, is done for. So and if you're upgrading in the middle of the period, you have to pay more for the new. And I love their product, by the way but I felt cheated as a customer that in total this thing, and this is all about proration. Because the billing system, whatever they were using, it had to refund me the money, which was paid earlier, and then charge me for the remaining period. And you talked about doing right by the customer and a customer trust. And, you know, I'm the founder and CEO of a billing company, you know, that's a different thing. But as a customer, I felt bad even though I hugely love their product.
Arnon Shimoni:
So let me ask you this, does it affect kind of your decision making process? If you want to stay with us come, you know, if a different product came along? Would you be like kind of willing to try that product instead, or are you kind of loyal to them for now?
Sandeep Jain:
I'm loyal to them because the product works. It's a beautiful product. My trust with the company's billing is off now. So let's say I'm an individual user, but I want my entire company to use that software, I'm going to be looking at the bill very, very carefully as to if something was done right or wrong. As billing is the thing, and if you lose the trust, you lose the trust. And it will not be okay for eventually hard. Yeah, it would have been okay, if they were to say, we are not going to refund you the money. And I may not like that but at least it was clear. Anyhow, it all boils down to this proration thing, which is so hard. And I actually went to the Customer Support Department because I was curious why they do, they did that way. And they said, look, our billing system does not do that what you're saying? I'm like, okay, so to your point earlier about, like there are a lot of billing solutions available, but does this solution fit your own needs? You know, there is that gap that you talked about earlier, I felt this.
Arnon Shimoni:
100%
Sandeep Jain:
So I just want to share that for you.
Arnon Shimoni:
You know, it's true. And to be honest with some of our older plans, we had kind of proration enabled, and we wouldn't refund. Like, let's say you had 10 users and then you went down to 8, we wouldn't give you the money back for those two users, which is fine. But I think it was also confusing company like our customers when they were adding users and then they did see a proration for a partial time. So what we've done with our newer kind of like from with the products that replaced those older tiers is I'm like we're okay with giving the customer a few days up to a month, let's say of free time on those on those users, so if you add a user on the like, you get your invoice on the first of the month and you add a user on the second, you get that user for free until the next invoice, and I'm okay with that. That's absolutely fine. It makes the situation so much less complicated. I don't care that the customer, you know, get some free time, if they can get value out of it, that's all we care.
Sandeep Jain:
Got it. So let's come back to the billing product that you guys build. What are the hardest part of this billing system that you felt? And it's interesting that you didn't come from the billing background. So you're probably learning as you're building. So could you talk about like, for the brave souls out there who want to still build their billing system that folks, please watch out on these few things that tripped you probably?
Arnon Shimoni:
All right. So I'll tell you the story about the first thing that my team did. So we were at that point, we were myself, plus two very senior engineers on the team, who had worked on billing systems before, and they were really, really good. But they still are really, really good. But, you know, at the time, they were also but younger, we, you know, we got this kind of request from the finance department. And they said, we do not give trials longer than this many days, let's say 15 days, 15 days is the most amount of trial that we're willing to give our customers. And I said, okay, so should we block trials longer than that? And they said, “Yes, that's the rules. And I also talked to our sales department, and I said, you know, how much trial do you give? And they all said, “Yeah, we never give more than the 15 days or whatever”. So we put in a block in the kind of CPQ system to not allow them to configure a trial longer than that. And the next day, after we deployed that, all hell kind of broke loose, and everyone was on my case, like, why did you block it? I'm like, Well, you know, those are the rules. We said, We don't give a trial longer than 15 days, like, Yeah, but we didn't mean for you to actually block it, you can't sell if you block, if you don't let us kind of play around with this with it, because the trial is like a super important part of selling. So we quickly had to undo that. So that's the first kind of Quote that we pushed. And it's also the first Quote that we had to kind of undo as well. And that's when we discovered that even if we have rules in place, we need a way to bypass those rules. The rules are okay for the very, very generic kind of standard company. But because we are B2B, every company has their own different requirements and rules. And some of them for example, you know, we were selling monthly, we have monthly payment terms for the most part, but some companies came by and then they said, “Look, we have a budget this year, we will not have a budget next year, we wanted to prepay for the year”. And you know, this seems weird, why would you want to pay in advance instead of pay monthly, but that's what they wanted. So we kind of started to adapt to all these different things that customers wanted. And I think what I'm trying to say from this is you have to build in the flexibility outside the norm. Even if you're you know, you will have someone tell you, oh, we never do, we never sell ‘X’ have the provisions in place to sell ‘X’ at a variety of different prices at a variety, you know, Pleo, for example, operates primarily in a set amount of countries. But we also have fairly complex companies that are on board with us that have subsidiaries in in different countries than we originally intended. So we need to have the mechanisms in place to support those, because we want to onboard them, we want to give them a good experience. You have to be flexible in what you plan, you can't plan only for the very, very strict kind of classic. Oh, the company on boarded, they finished their trial. Now they're paying and they never need any kind of interaction. Companies will request to pause their subscription, they will want to off board and then they'll change their mind a week later and asked to onboard again, they'll want to change their billing schedule, they won't want to have it on the first of the month, they want to have another 15, there'll be all these kinds of requests and you have to plan for that you have to know. But you also need limits. You also need to say okay, this is my red line, I will never cross this line. You also need to have those otherwise you'll you're building something that will quickly spiral out of control. And I think the way or the way that we've chosen to handle that is through our CPQ tool and through our kind of like interfaces. There are a setting set amount of things that a sales rep or a CX rep can do, customer care rep can do anything that kind of goes past that they have to request it from us because we have to be the ones doing it manually. And I know that sounds weird, but having that extra step means that it's much less frequently abused.
Sandeep Jain:
Well, yeah, that's interesting. You're right.
Arnon Shimoni:
Because anytime you open something, anytime you open up an opportunity for someone to abuse something they will, it's not because people are bad, but it's just how humans are. We tend to like go to the, you know, we check the limits, and we check what we can get away with. You see that with kids. When you have kids do you see you know, they inch, they keep trying more and more, see what they can get away with? At a very young age, like one and a half, two years old, you can see kid’s kind of testing the limits. And I think adults are the same that we just do it a little more, a little bit with less grace, I would say obviously.
Sandeep Jain:
So not only that, you have worked on the system, which is both a CPQ and billing. But if you look in the market primarily, there are CPQ players, there are billing players and more recently, there are usage billing players. What's your sort of thoughts on the way the market is structured? Because what you're doing is something different than what market is offering?
Arnon Shimoni:
Again, I think it looks like they're mostly aiming towards very, very basic B2B or B2C style situations, which I haven't seen how they would work for me, for my context. So I definitely think there's a lot more opportunity here. And you know, you mentioned that that article that was on, what was it protocol? The website, the thing, enterprise market, Enterprise SaaS market. And I do think that's actually true, I read that article, it came out, like in March, I think, I read that article, and I was like, Oh my God, this person speaks exactly what I've been thinking. I think it's ripe for kind of disruption. But I think we're the market we will go is towards a fairly kind of all in one solution. That will abstract, it might use other things under the hood, but it will abstract most of the stuff away. So that it's kind of easy, the same way that stripe did. What stripe did is they abstracted the whole, you know, taking credit card details away from before you had to build your own form, you would do your own validation, it was you had to do your own, you know, is very, very complicated. So they handle all that for you. I think that's what's going to happen, we're going to have like a very simple kind of API or interface that you would put on your website that allows you to select your plan or checkout. And you can configure and price things kind of quote things yourself. And there would potentially be a kind of middleware that would do the pricing. So once you add the product, the price might change and that would be decided by this kind of all-inclusive product. And that's what I think will happen, because I don't think there's going to be a disruption on the payment gateway side again, I think that field is kind of fairly well established, they would still want to keep using those well-established products underneath. But we will see something that tries to kind of abstract most of that away. That's what I think is going to happen. But you know, anytime you predict something, it doesn't happen. So I kind of hoped that it does, because that would make things a lot more simple. I'm not sure it would solve things for my company, but I think it would solve for a lot of other companies.
Sandeep Jain:
Why do you say that there? Because is it more unique on your side? Is that why you're saying?
Arnon Shimoni:
Yeah, you know, we're a FinTech. And we operate in a lot of different countries, and each country has their own kind of different set of requirements. And, you know, I'll give you an example with from our product, we have something called, we have a mileage feature, which lets employees get reimbursed for trips that they've done with their car. And that's very, you know, it's something that happens very frequently in Sweden, for example, but in Denmark, that barely exists. In France, as far as I know, it doesn't exist at all. So we will probably have to start figuring out how we price those features separately, or how we kind of detach them from the main product from the platform, as it were. And I think that gets really, really complicated when you're doing self-serve. And when you have this kind of maybe AI driven CPQ tool, maybe something with a little bit of intelligence, I think that won't work well based on my current understanding of how someone would build that, but maybe the actual kind of disruption that would happen is around how we structure and sell our products. I think SaaS was like a major disruption. Maybe there'll be another one of that kind of, of scale and an impact. That would change everything. I don't know it. So it's going to be interesting to see what the next big thing is. But, enterprise billing is, it's a really, really hard. It's a tough cookie, because it is so different from country to country, from product to product, from industry to industry. And it's also, it has to do a lot with fashion, more than anything. SaaS is fashionable now, but maybe it won't be in five, six years. And then any product that solves the SaaS billing won't be fashionable and when the time comes. And then I don't know, it's really hard to predict, I think, but that's kind of the reason why I think having a group with kind of the skills to build and kind of adapt might be something that a lot of companies would want to invest in. And I know it sounds weird, because, you know, I mentioned this at the beginning, I also had people telling me, this isn't our core competency, why are we spending time on this, and it's true. But I think if you don't have it in your competencies at all, then you will be stuck with the, whatever it is that you know, the top of the line offers you today. So let's say you go with stripe, you have basically four ways of doing billing, you have like a flat fee, you have use like kind of per unit, you have tiered or you have, you know, graduated volume, discount something. Those are the four models that stripe supports, if you're not falling into one of those, you're not going to be able to make up your own kind of business model, which may be a good idea, by the way for a lot of companies to kind of stick with one of those four. But that's not how enterprises work. They all want to set their own kind of their own billing structure in their own SKEWS structure and their own payment terms. And that's why it's hard.
Sandeep Jain:
Understood. Hey Arnon this was like an amazing conversation about why or why not to build your own billing system.
Arnon Shimoni:
Yeah. I would say do it, but it's hard.
Sandeep Jain:
Well, we look forward to more of blog posts from you on the more interesting and dirty parts of billing, if I may say that. But before we end this conversation, is there any interesting resource like a book or a podcast, or maybe a blog, maybe not necessarily related to billing, or CPQ, that you found interesting enough that you would want to recommend for our listeners?
Arnon Shimoni:
There’s the “Inspired” book about you know, how to about startups that how you would go about kind of building a product, which I think is really, really eye opening and how it makes you think about products that you use every day and how they came about. And what an MVP even is, to some regard. I think that's a really eye opening book and it's fascinating. Another one is “Thinking Fast and Slow”. I think that's the title of it, by Daniel Kahneman. Just understanding that a lot of people kind of have two systems of thinking one of them is fast, one of them is slow, really makes you kind of appreciate how systems are built. And it can also help you design the system better in a way that caters to the way people think. And I think that it's a tough book. It's very long. And it's sometimes hard to read, but it is kind of worth it even if you only read like let's say the first three, four or five chapters, still worth it, to get kind of an insight into how people think. Very, very, very kind of again, mind blowing to think about that.
Sandeep Jain:
Awesome. Hey, thank you again for your time and for this interesting conversation.
Arnon Shimoni:
Absolutely, pleasure.
Sandeep Jain:
We wish you luck in building the billing system at Pleo.
Arnon Shimoni:
Yeah, for many more years, I hope.
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.
