In this week's episode of the Enterprise Monetization Podcast, Sandeep Jain sits down with Arnon Shimoni, Senior Product Manager of RevOps at Pleo to discuss why or why not build your own billing system.
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.
Pleasure to be here, Sandeep.
Awesome.
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.
Absolutely. Before we go into the depths of billing and CPQ could you share a fun fact about yourself?
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.
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?
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.
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?
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.
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?
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.
So if I understand this correctly, you have built both a CPQ and billing system internally at Pleo?
Yeah, that's true.
And this system, this integrated system, is it hooked to your CRM, I suppose, because salespeople need to Quote out of some systems?
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.
Got it. And do you have in terms of sales motions, is it just direct sales, or do you have self-serve as well?
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.
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?
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.
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?
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.
Why don’t you talk about these limitations?
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.
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?
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.
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?
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.
Interesting.
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.
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?
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.
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.
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?
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.
100%
So I just want to share that for you.
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.
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?
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.
Well, yeah, that's interesting. You're right.
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.
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?
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.
Why do you say that there? Because is it more unique on your side? Is that why you're saying?
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.
Understood. Hey Arnon this was like an amazing conversation about why or why not to build your own billing system.
Yeah. I would say do it, but it's hard.
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?
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.
Awesome. Hey, thank you again for your time and for this interesting conversation.
Absolutely, pleasure.
We wish you luck in building the billing system at Pleo.
Yeah, for many more years, I hope.
