Get a free demo
Episode 24
Data for Subscriptions Podcast

The Pains of Billing and Monetization

Guest

Arnon Shimoni

Arnon Shimoni
Monetization Product Lead, Storytel

Watch:

Episode description

The Pains of Billing and Monetization

Uncover challenges in pricing, communication, and revenue booking. Delve into various touchpoints and understand the impact of billing complexity, while gaining insights on building a robust billing system. Hear from Storytel’s Arnon Shimoni on their approach to customer signup, payment methods, and discounts, and discover the importance of cross-team collaboration for optimal billing performance.

Highlights

You have been quite vocal about the fact that running or optimizing a billing system is complicated and risky?

Oh… 100%. When you’re starting up, when you’re just starting to build your customers, let’s say in the startup, you’re thinking about it often as an engineering problem, like, OK, how do we get the credit card like from the customer and make sure that we get some revenue. Like, that’s the first thing that they think about. As you go through the different maturity stages, that taking-the-credit-card is is no longer the problem, right? That’s already solved. There are lots of tools, lots of solutions for that, and then it becomes, OK, how do we increase revenue? How do we manage multiple products? How do we upsell? How do we cross-sell? And then it comes to how do we manage the data for that? How do we know if a customer has upgraded when we sent them that offer? How do we know which ones converted? It just balloons, right? And you could include that in billing, or you could say that’s a separate data issue. For me, it’s very close to billing. I’m not sure I would include it in the billing life cycle, but it’s certainly within that scope of influence.

When one looks at driving a billing transformation project, do you have some input in terms of how we should take that decision and when is a good time to make that shift?

I think the most important thing when you take a transformation project like that is understanding where the risks are and what and where you’re reducing the risks. Usually, you take on these kinds of projects because you’ve identified a risk. You’re saying I cannot keep maintaining my current system because my engineers don’t want to work on it and they’ll quit if they have to keep working on it. That’s a risk. You’re saying oh, well, we haven’t built it in a way that’s scalable. If we grow another 50% over the next year, it’ll start breaking. We won’t be able to build customers. That’s a risk. If you think, well, I’ve put all my eggs in one payment processor’s basket, and if that payment processor decides to boot us, if you lose that ability to funnel revenue into a company, that’s a risk, right? And when you have identified a sufficient amount of those risks, then you can formulate a plan on how to tackle that. If you don’t know what your risks are, then you have to do that risk assessment.

Can we talk about the different ways one can approach solving for billing needs?

I would say buy stuff off the shelf. Now here is the problem, because if you look at Stripe, for example… and this is not just a Stripe problem. It’s common with other tools as well. You have to create a translation layer right from your own product – the way that your product thinks and talks, and you have to translate that into the business rules that Stripe understands… or any other tool. So I don’t think, for most companies, going 100% with one tool works. I really struggle to see how you can connect a product like your own product to a third-party tool and be happy. 

The other side is you build everything yourself. The ultimate form of control. You have full control over the entire business logic. But I think that’s going to be extremely tedious, and unless that is like a core component of your business and you cannot operate in another way, I would strongly advise against it because you’re going to be creating so much tech debt overtime that’s going to be really, really hard to undo. It’s you’re not going to be able to migrate to another system because you’ve built so many different things that are critical to your business that you’re relying on what just don’t exist in the outside world.