Maintaining in-house organization alongside the complexity that comes with satisfying customers’ demand for uniquely tailored offerings and pricing plans is a perpetual balancing act for businesses large and small. While some opt to play it safe, for Josh Odom, the only real option is to embrace complexity and innovate to keep things smooth for company and customer. Josh is the CTO of email delivery platform Mailgun, and he spoke with MGI Research analyst Andrew Dailey at the 2021 Monetize Forum. They discuss lessons learned and how finding the right billing solution in tandem with a commitment to meet their customers where they are is allowing them to monetize and expand into new territories.
Key Issues
Why should businesses with homegrown billing systems consider off-the-shelf solutions?
How can overages bring in revenue and work for the customer?
How can companies prepare for the complexity that comes with meeting customization demands?
Guest Profile
Josh is the CTO of Mailgun, an email delivery platform serving over 300,000 customers including Lyft, Microsoft, and Wikipedia.
He joined the company in 2015 and helped lead the spin-off of the business from Rackspace to become an independent company once more. Prior to Mailgun, Josh led a team of over 80 product managers and developers who were responsible for various cloud computing services in the Rackspace portfolio.
Andrew Dailey
Welcome to our next session, “B2B SaaS Journey to Usage Billing: The Mailgun Story.” Here at MGI, we often get pulled into helping companies with their monetization journey. In the course of our engagements with clients, many of the challenges often follow consistent themes: keeping pace with growth, struggles with internationalization, integrating acquisitions, complicated usage and tax scenarios—all of these are very typical challenges that organizations face. Often, in the first conversation we have with a client, a senior executive will say, “We have a very simple business. We’re just not that complicated.” That’s usually a good indicator that the business is anything but simple.
Joining me in our next case study interview is Josh Odom, the CTO of Mailgun. He’s going to share with us the Mailgun monetization experience and the lessons they’ve learned so far (spoiler alert: this business is anything but simple and uncomplicated). Welcome, Josh.
Josh Odom
Hey, Andrew. It’s great to be with you today.
Andrew Dailey
Give us a little background on Mailgun. What do you guys do? What are the scope and size of your business?
Josh Odom
Certainly. Mailgun was founded in 2010. The company was a Y Combinator-backed startup originally, founded by two individuals who realized in the early days of cloud computing that there was a need to be able to send and receive email in a reliable way from cloud infrastructure. That was the genesis of Mailgun. Of course, the strategy and the business model has evolved over time, but core to our focus as a business is enabling developers and partners to be able to send email messages through a reliable and robust API.
Many people think email is very much a solved problem, but when you’re running at a scale where you need to send millions or hundreds of millions of messages at once, Mailgun is the right solution for you. We work with customers like Lyft, where we’re responsible for sending all of their email messages through our platform so that they’re delivered in a timely and reliable way to their users.
Andrew Dailey
Tell us more about the Mailgun monetization journey. You guys have been on a good growth trajectory, expanding the business from a geographic point of view as well. When did that growth and some of the complexity that comes with expansion begin to affect your ability to monetize?
Josh Odom
That’s a great question. Early on at Mailgun, we relied on a pretty simple subscription billing model, which is what many SaaS companies start out with. Based on usage (the number of email messages that were being sent or processed), you would subscribe to a plan that best suited your needs with the right set of features.
We experimented with a number of different billing models over the years. As we’ve gone more upmarket, the subscription model is effective for many customers. However, for customers with highly specific needs calling for a level of customization, we reached a point at which our simple billing model and system were no longer sufficient. So that was kind of the first point where we had to evolve as a business. The second big point was the acquisition of Mailjet, a company based in Paris, France. The complexities there were really around multiple currencies, VAT taxation, and all of the complications that go into having a business operating internationally from an accounting and finance perspective.
Both of these developments introduced a level of complexity into the business where our original decisions of building our own billing engine or rating engine were just no longer scalable. We were in a situation I think many companies face, where they need to spend a considerable amount of their time building billing logic as opposed to focusing on building a great product experience for their customers. Ultimately, that led us to implement Chargify in early 2018 to replace our own homegrown billing system for the Mailgun business. We’ve recently migrated our Mailjet subsidiary onto the Chargify platform for contract billing as well.
Andrew Dailey
You mentioned that you offer usage and consumption-based models so people can pay as they go. They can also do pre-pay/pay in advance and enterprise deals. What unique challenges has that wide array of offers introduced from a monetization perspective, and how did you handle those (in addition to implementing new billing with Chargify)? What else did you have to do to try to tame the complexity that comes with all of that?
Josh Odom
For us, this is first and foremost about meeting the customer where they are. We learned that many of our developers who are just getting started (maybe building a hobbyist app or doing something for themselves to learn about software development, for example) don’t actually want a subscription billing model. They want a model where they can use and get to understand the service, and if their application grows into something more meaningful, then they’re very willing to pay.
So, on the low end, we have these hobbyist developers who may be working for larger companies in their day jobs. They value having a free tier where they get a certain allocation of usage and there’s no obligation to pay for that. As you grow up and scale on the platform, customers value a certain level of predictability in their costs, and with that predictability come features that we can bundle at certain price points to help encourage users to subscribe to higher value offers as they continue to grow on the platform. Last but not least is the contract model. The contract model has every possible permutation of complexity there is in the billing universe. We have customers who have very, very seasonal usage patterns. For example, we work with many finance companies that have a spike of usage around tax season, and they don’t want to actually subscribe monthly to their high watermark. They want to be able to pay for an annual allocation of emails and use that allocation throughout the year based on their business needs.
So, each of these has a very different level of customer engagement problems associated with it. The desire here was not to complicate our billing model. The real issue was making sure that we were meeting customers where they were, so we could serve customers who are just getting started and sending maybe 1000 messages a month or less all the way to customers who are sending a billion or more messages a month. We cater to both of those customer types on our platform. At a certain point, the pain and complexity of managing the different billing rules and models and having developers spend all of their time tweaking and tuning these models was just becoming untenable for the business.
Andrew Dailey
With a usage and consumption-based model, how do manage the challenge of trying to predict and forecast your own business when it’s based off of acquiring customers and their consumption of the product—which you have no control over? How do you handle that?
Josh Odom
Well, that’s a problem that we’re constantly working through each and every month because, even in a subscription world, so much of our revenue comes by way of overages. We do look at usage models to predict where customers are going to be, but really, it’s not until the very end of the month—sometimes the last two or three days of the month when overages are being incurred by customers—that we can really get a more precise understanding of where we’re going to be from a revenue perspective. So, we have several layers of modeling that we build on top of our usage system, the data that we’re getting back from our billing system, and our accounting systems, to be able to better predict, but it’s an interesting problem for us as a business and one that we’re constantly working to refine as we continue to grow and scale.
Andew Dailey
We were talking earlier, and you mentioned that you guys have built this billing service layer. Can you describe that? What exactly is that?
Josh Odom
Absolutely. So, with the acquisition of Mailjet, we’ve been living in this universe where we have our core billing system built on Chargify and the Mailjet custom billing system which we’ve been working to retire over the last several months. Billing actually touches many different facets of our business, so we wanted a common mechanism for our dashboard and our management systems to be able to interact with the billing system, regardless of where that data lives. So, we built a very lightweight service layer that allows things like our dashboard to be able to communicate with Chargify and know where to go pull invoices, how to update credit cards, and how to update other billing information without really focusing on what’s underneath the hood, so to speak.
As an example, this has given us the ability for our data warehouse to be able to pull invoice records or usage records. This is also how we set things for our SMS product set, where there’s a different price point for each country you’re sending a message to. We have a bunch of different inputs and outputs to all of these systems, but we wanted a very common way to manage the billing concerns across the entire face of the business, both here in the US and internationally as well. This service layer we’ve built allows us to have a common way of interacting with all of those different concerns.
Andrew Dailey
Got it. Presumably, that also helps with revenue recognition?
Josh Odom
That’s right. Beneath all of this, we use NetSuite. We have several different layers of transformation that happen in our data warehouse, and there are other integration layers that take everything that exists in our billing system and feeds that into NetSuite so we’re able to do revenue recognition properly. This is also the system that feeds all of our downstream systems for our finance organization as well.
Andrew Dailey
So, this growth business went from homegrown to off-the-shelf, putting in a service layer, international acquisition, and continuing to expand geographically. If you could look back, what would you do differently? What do you know now that you wish you knew then?
Josh Odom
Wow, well, there are quite a few things. First and foremost, I wish we would have started this journey earlier. When we first implemented a billing system, we didn’t realize the level of complexity we would be dealing with and how entangled all of the different business systems are. These transitions just take time. One of the things I do think would have helped us is more of a phased approach. When we first migrated to a billing system, we tried to do everything all at once, kind of in one cut-over. While that sounds nice, there are so many different reporting challenges, and there are always things that you’re going to find when you do a system migration like this, things that no amount of UAT or testing is really going to uncover. It requires you to just work through cohort, by cohort, by cohort of customers. And while you’re running a project like this, there are always a bunch of other business objectives and goals that are competing for the same time, attention, and resources. We were doing a complete repricing of our entire offer while we were doing this integration which was yet another complication.
So, looking back, thinking about how to do this in a more phased approach would have certainly been more helpful in terms of streamlining the migration. It was successful in the end, but being able to break this down into more discrete cohorts would certainly have been more helpful and would have streamlined the process as we went along.
Andrew Dailey
Talk to us about what’s on your roadmap going forward. What are the things you’re working on right now? How far do you think you’re going to extend it? Are you going to continue to come up with new pricing models and plans?
Josh Odom
Yes, absolutely. One of the things that we’re doing early next year for our Mailjet brand is a new pricing and packaging exercise, where we’ll be building a new set of subscription offers. That’s going to introduce its own set of challenges and a new pricing model for that particular group of customers. Additionally, one of the aspects of our business that’s been growing rapidly has been our SMS product set, and we’re going to be expanding that product into the US market through our Mailgun brand.
As I mentioned earlier, SMS is just a really neat product because each and every message that you send has a different price point, depending on whether it’s a US-bound message, a Canadian-backed message, et cetera. And it’s not just the rating of the usage that’s complicated. In SMS, it’s very common to have a credit-based option; customers will be prepaying for SMS credits that are drawn down as usage is incurred on the product. That’s a completely different billing model than we currently have on the Mailgun product today. So, for us, this just gets more and more complicated as our product set grows and we continue to endeavor to meet customers where they are.
Andrew Dailey
I want to go back to something you mentioned earlier, which is the fact that you’re making some amount of your money off of overages. As a consumer, overages are often an unpleasant surprise. How do you balance the revenue and profitability that come from that and the friction that’s inherent from the customer’s point of view with that model?
Josh Odom
Sure. I think there are a lot of businesses out there where overages are designed to be highly punitive. That’s certainly not our model. We’ve designed overages in a way that allows customers to, first of all, know when they’re approaching the threshold. We allow plan upgrades mid-cycle, so you can upgrade as soon as you start to incur overages, and you won’t be facing any punitive fees. You can basically optimize your plan based on your usage at any time during the period, so you’re not stuck or surprised by a large bill at the end of the cycle.
However, because of the usage model, we find many customers actually do value having overages so that they don’t have to subscribe into a higher tier if they have a highly seasonal business. I think the key to this is just making sure that customers know where they are mid-cycle and giving them the opportunity to upgrade. We have several support tiers and customer success tiers that are proactively reaching out to customers to let them know, “You’re approaching your allocation. Here’s what we can offer you in terms of plan upgrades,” to make sure the customer has found the right fit for them at the right time.
Andrew Dailey
Right. That’s the connection between customer support, account management, and billing.
Josh Odom
That’s right.
Andrew Dailey
Another thing you mentioned is the cohort analysis. In our practice, we often see organizations think, “Well, all our customers are relatively alike.” But in reality, there are a lot of snowflakes out there; from a distance they look similar, but upon closer inspection, they’re completely unique. They’re unique in terms of the agreement that you have with them, the services that are provided, how they pay, et cetera. How much work did you guys put into the cohort analysis, and did you expect to do that much analysis on cohorts in your original planning, or did that come later?
Josh Odom
There are really two different lenses through which to look at customers. One is for the customers who are on subscriptions, maybe paying between $35 a month and $1,000 a month. We have plans that really cater to those use cases. When you’re looking at those cohorts, there are very well-defined lanes that customers tend to operate in, so we’ve been able to design our plans and packages for those use cases.
However, once you cross that $1,000 a month spectrum, every single customer looks like a snowflake. In fact, the hundreds of customers we have on annual or enterprise agreements all have their own very unique packaging plans that we build in the sales process. Even though there might be some commonality in usage or number of email messages, people start to value different service tiers, different SLAs, and different features that are bundled. All of those variables make it so that each customer starts to look very unique in their own plan or design.
Andrew Dailey
Presumably you guys try to reduce the amount of complexity in your business as much as possible, and yet, when you’re out selling, you want to meet the customer where the customer is. From a sales point of view, that usually means creating whatever unique offer is necessary to meet that unique customer. How do you balance the desire of the sales organization to meet their numbers (and meet the customer) against the operational and financial need to minimize complexity?
Josh Odom
So early on, we did try to create very well-defined packages that fit the core features and bundles that our sales team was out selling in the market. Inevitably, though, there’s always a one-off. There’s always a special customer. We reached a point where we were going through this process weekly, at least, and we just decided that we were going to embrace the complexity and make it so that it wasn’t operationally tedious for the business.
We created processes where, from Salesforce, we could easily implement the right pricing and packaging models so that all of these bespoke packages we were out selling and proposing to customers could easily be created in an automated way in our own internal systems—so that there was a very, very low operational cost to supporting this. I think as companies grow and the complexity of the offers continues to increase, this is just something that every company, depending on where they are in this evolution, has to decide to embrace at a certain point to enable the sales team to build and curate the right package for the end user.
I think from the customer’s perspective, it can be a red flag if the sales team doesn’t have the flexibility to create the right curated offer at the end of the day. So, we just said, “Okay, for us to continue to grow as a business, we have to embrace the complexity and make it easy, operationally, to go implement”—which is what we did.
Andrew Dailey
Terrific. Well, Josh, thanks very much for your time today. We really appreciate it. I know your details are up in the networking section if anybody wants to reach out (I know you guys are hiring!), and I’m sure you’d be happy to join folks at the networking session later today. Again, thanks very much, and thanks to everyone for joining us here.
Josh Odom
Thank you.
