Derric Gilling is the co-founder and CEO of Moesif, a leading API analytics, and monetization platform. In this article, Derric discusses monetizing APIs.
Nowadays, selling to developers is hard.
- Individual developers have a lot more autonomy and authority.
- Developers can be skeptical of sales and marketing.
- Buying software is much more decentralized than five or ten years ago.
- There is the “not invented here syndrome.” What that means is, a lot of times, different companies want to build stuff internally instead of adopting other software.
Developers need buy-in from many stakeholders. It needs a legal and security review. The software must follow the procurement process if it is to be procured. As APIs deal with production data, it requires complex risk analysis. Considering all these aspects, a developer cannot make a decision alone. But, getting buy-in from all stakeholders can be a time-consuming feedback loop. So, to monetize your APIs effectively, you need to shorten the feedback loop.
Shortening this feedback loop
Land developers first – Get developers to pay a token amount to test the API. This will enable the developers to assess the value they get from the platform or API. So, essentially, you are selling to the senior management through the developers. There will be many developers already using and testing the product.
This also means that there is a change in your sales process. The sales focus is on high ROI opportunities.
- A customer has already seen the value of the platform before sales engage.
- As usage grows, the expansion is automatic.
- The sales team gets into a more consultative mode. This will drive higher adoption or usage of the API, which translates into more revenue.
Now the tricky thing, though, is each API business is different.
Prepaid versus postpaid – This is a billing strategy. In this case, we’re comparing two different billing strategies for when a customer will track the usage.
Prepaid – Customers purchase credits or quota ahead of time, and it is consumed later. It gives you a better cash flow. You get the cash upfront before you even have to service that subscription. This could be great, especially if your API is costly from a unit economics perspective. It’s also more familiar with typical enterprise sales processes, where you pay for a year upfront or maybe two or three years. Larger enterprises are used to some type of prepaid billing model. Now the con is, there’s a lot more onboarding friction. So as an individual developer, or someone that is trying to get up and running as quickly as possible, they might not necessarily want to ask their manager for a lot of money upfront, or they don’t even know how much uses they’re going to use, is it X number of transactions, or is it x times 1000 number of transactions. In such cases, postpaid is a better option.
Postpaid – The customer pays for their usage after the service is consumed. There is lesser onboarding friction because they can pay after the service is consumed. They don’t have to consider how many credits or tokens they need before consuming that API. The con is that it could be abused. You don’t want developers to sign up for 1000 free accounts and be able to walk away with a lot of money.
Usage or consumption-based pricing – Tiered vs. Pay As You Go.
Tiered Pricing – Traditional SaaS pricing with a pre-defined suite of features and capacity for each tier. The positives of tiered pricing are that it enforces a minimum spend, is predictable to the customer, and is easy to implement. On the flip side, there is some friction in expansion. It can also be perceived as rigid. If you have a plan for $150, but the value perceived by the customer is $200, the customer is happy. But, if the next level is $500, the customer may not see that value, and there is no mid-way.
Pay As You Go – Usage-based or consumption-based pricing based on unit price. The pros of this plan are that the customer finds it efficient as they pay only for the services they use. It is also more efficient. The con is that it is hard to set up, meter, and audit the process, so it is complex to implement.
When to invoice – Recurring vs. Threshold
Recurring – The customer is invoiced on a regular schedule, like a month, year, etc. This makes it easier to manage and more predictable. On the other hand, if it is prepaid, it can get complex. It can also be bad unit economics for low-cost SaaS.
Threshold – The customer is invoiced only after a credit limit is reached (it could also be prepaid). So, a customer pays, for example, $500 and then uses the service at a pre-defined cost. Once he reaches $500, he is invoiced again. It makes prepaid services easier and has a reduced transaction cost. The con here, though, is that finance teams might not necessarily like this because it can be very hard to manage and reconcile. You are also increasing some company liability because, in this case, you have a company or different customers put a prepayment before using a service.
There are multiple aspects on which you can decide on the value of the API –
- Transaction volume – It depends on the number of API calls or messages sent. It can be used for APIs and event-based platforms such as SMS and analytics.
- Revenue or cost share – It is a percentage of transaction share or revenue. Platforms focused on money, such as payments or expense reporting.
- Data volume – It is used heavily within logging companies, sometimes with an infrastructure. It could be gigabytes sent or minutes used. Platforms focused on data, such as logging or storage, can use this metric.
- User-centric – This is a modern version of charging per seat or user.
- Resource – This metric is used in infrastructure companies such as a database or virtual machine. It is calculated based on the hours the resource has been used or the number of resource units.
Self-service account management and support
When you first start, you’ll have all these individual developers using your API, but that doesn’t necessarily mean you can focus on and reach out to every single one. And so that’s not a scalable system to have. You will have issues during the onboarding process. There will be questions on integration. There will be changing business needs with additional functionality or team members to be added. There could be surprises around billing, invoicing, etc.
So, what we recommend is making management as much as possible self-service. This will reduce support time. Your sales and account management team can focus on the accounts that matter. For example, to reduce some of the billing surprises, make a self-service portal so they can see exactly what their usage is trending like and what their invoice is expected to be; provide a way to allow them to upgrade or change their account as needed.
Avoid billing surprises
The other big thing is avoiding billing surprises. You don’t want a developer to sign up in month zero and pay $50 a month, and a week later, they get a $10,000 bill because that is not a good customer or developer experience. So, we recommend setting up a system that will notify your customers when they increase their usage. That could be some quota limit, and if you send out an email when they reach a certain quota, it could be even more complex, where they can set up their own thresholds.
Reduce friction
The other thing you can look at is reducing friction. You can do this by looking at different partners and app ecosystems. For example, the manager’s credit card that was used to pay for the service decides to leave the company. Then that credit card might get canceled. So, you can leverage things like Amazon Marketplace and the Salesforce app exchange. This helps reduce some of those credit card issues.
Measure and reduce the timeline to a working app
To track customer experience, we recommend looking at it in two fundamental steps in the activation engagement process. First is what we call time to “Hello World.” This is the time it takes to make that first API call. That might use a tool like Postman. It is not much, but the developer is putting the work into testing the API, and they’re looking at your documentation and seeing if it will fit their needs. However, that doesn’t necessarily mean they got to see the full value of the platform. They’re not necessarily engaged; they just tested it with Postman. You’re aiming to roll out some integration to a wider audience, whether their end users will use that API. We want to ensure there’s a lot of engagement and use.
What to measure?
There are two fundamental metrics.
The first is the activation or the conversion rate itself. The second is the time it takes to reach the next step. That way, you can try and shorten that timeline as much as possible and squash it. Because until they get to that last step, it’s very hard to have a paying customer that has seen a lot of value from the platform.
To conclude, deliver good self-service and onboarding. Over-communicate as much as possible. Ensure you have the guidance and tutorials to get the app running.
