Archetype | Revenue Optimization for Volume Discount Plans: Case Study
logo

Revenue Optimization for Volume Discount Plans: Case Study

Thu Aug 11 2022

In this article we will explore a sample case study as to how an API-first KYC company can adopt a usage based billing model to increase revenues and boost the customer experience for their users. As more companies are shifting from subscription models and annual contracts to usage based billing, teams are starting to analyze how they can apply this same switch to their businesses.


We will outline a number of clear pain points mentioned by real customer conversations and how they are thinking about building usage tools into their revenue models.


Let’s dive in!


A 15-minute food delivery service plans to onboard drivers digitally fby using a KYC API to validate drivers license. This company is launching their product and shops the market for an API to embed in their app and process identity checks.


The delivery app estimates that usage will be 10,000 calls per month and negotiates a contract for this usage. Rather than paying the off-the-shelf pricing of $1/call, the KYC company offers them a discount of 25% per API call over a 12-month period. Once signed, API cost to the delivery startup is no longer tied to usage, but rather set at $7,500/month = $90,000 annually.


Now, let’s fast forward 12-months from when this contract was signed and analyze if using a contract was the optimal way to bill, both in terms of maximizing revenues for their API and delivering the best customer experience.


See usage below:



To our eyes, real usage (blue line) tracks the estimated usage (red line) rather closely. However, if we focus on a granular level, especially within certain time ranges, we see the many inefficiencies around the API company billing via contracts.


Pain Points from customer conversations:


  • Estimating usage: For the delivery startup to agree to a contract for API usage before their product is live is an assumption. There are many variables at play here, including seasonality, adoption rates, product launches, etc and thus, estimated usage will almost never match real world usage. This is the basis for inefficiencies.
  • Ramp Period: During the initial 30 days when developers were testing the API internally, only 50 calls were made. Since the contract was set at 10,000 calls a month, the delivery startup is still paying the full amount even though usage is far below. This is wasted spend and can become increasingly strenuous on the delivery company should the product development period take longer than 30 days, resulting in greater wasted funds should the ramp curve be closer to 3 or 6 months (very common).
  • Overage: During the month of July, the number of calls exceeded the estimated 10,000/calls. Under contract terms, every call above 10,000 resets at the stock price of $1/call. Nearly 500 calls jumped to that higher price point. With no cap set at the 10,000 calls mark, the delivery company opened itself up to increase risk. Imagine if calls were 20K or 50K that month (including a hack or another edge circumstance). Every call above 10,000 would have reset to $1, all falling outside the pre negotiated contract value.
  • Labor cost/time of negotiation: Thenegotiation process for the API company is a manual back-and-forth process. This causes the API company to assign salespeople to the prospect, with the need to potentially ask hire ups for deal approval, resulting in many hours across multiple sales members to negotiate, review and finally invoice the customer. This is both slow and expensive to pay employees to manage this process.
  • Contract length: Contract lengths are most often set against a strict number of months. In this case, a 12-month period. This is rather inefficient as usage is hard to estimate more than a few weeks out, and also causes the need to spend sales hours and time to renegotiate at the end of the contract length. This also allows the delivery company to shop around for other solutions at the end of the 12-month period.
  • Loss of revenue: Due to the many inefficiencies defined above, we expect the API company to miss out on potential revenue.


Thinking smarter, new ways to bill via automated usage based billing.


In addition to the many use cases of automated billing with Archetype, the focus here will be on launching a usage based plan to replace the current contract structure in the hopes that the API company will 1) increase revenue and 2) increase the customer experience.


We are going to create a graduated pricing model using the following pricing guidelines. The first 100 calls to any customer are free, followed by $1/call between 101-1000 calls/month and an automatic 8% discount ($0.92/call), between 1001-10,000 calls. Calls exceeding the 10K mark will fall 5 cents per 10K/calls/month until it hits the minimum amount of 70 cents/call for any amount of usage.


Using this new pricing strategy a few key benefits rise to the top. Let’s revisit all our previous painpaints under the new model and see how our metered billing model compares.


Since we are now using a metered plan, usage is no longer estimated over a set contract length. This allows the end user to pay for their exact usage on a per call basis.


Using a metered plan also bolsters the customer experience during the ramp curve for the end customer. During the month of January when only 50 calls were made, the new model will bill this at zero dollars, putting less pressure on their business and obviously helping with cash flows. The API company is still getting the value of a customer integrating their product and will make money when usage grows to a significant level.


With a usage plan also comes the benefit of the entire process being automated - including set rates. Similar to how self-serve customers can onboard and begin using their product without sales interaction, enterprise customers can act similarly. As their usage grows, the graduated model automatically discounts and invoice them. This saves on many manual hours across sales, accounting and onboarding teams.


Another benefit is the ability to have shorter billing cycles and no need for set contract length. Shorter billing cycles mean better cash flows for the API company and lower credit risk, while no set contract length could lead to a lower risk of losing a customer when a contract expires. Both are big business benefits for the API company.


A final benefit is a direct increase in revenues. In addition to a better customer experience for the delivery company and dollars saved in salesperson interaction, the API company is now using a model that drives increased revenues. For this example, revenues over the 12-month period increased by $7,660 (8.5%) while still offering a nearly 9% average call discount from the off-the-shelf rate of $1/call. Applying this $7,660 to a conservative revenue/EV ratio of 8x, we see the enterprise value jump by over $50,000.


Summary


We have seen that a usage based model can benefit a business in three main buckets. 1) increasing revenues 2) automating processes and saving on time and manual labor hours and 3) increasing the customer experience for the end user.


If you would like to see how your enterprise customers should adopt a usage based model instead of strict contract terms, connect with us at Archetype or on Twitter @getarchetype.


Thanks!

Sign up to our newsletter

Get the latest articles on all things data delivered straight to your inbox.

Share:

Latest Articles

Don’t undersell your API!

Mon Sep 12 2022

Don’t undersell your API!

Getting customers is hard! From API-first startups to larger enterprise organizations, companies are launching and selling various API products to generate revenues for their businesses. The core of having a successful API comes in two parts. The first is the ability to build a product that people love and use often. The second is around efficiently pricing your product to ensure you are generating maximum value across your entire customer spectrum. We will explore the various ways someone can

The Basics of the Python SDK

Wed Aug 17 2022

The Basics of the Python SDK

In the last couple of blogs we discussed the different ways we can monetize our API. In this blog we’ll go over some of the implementation specifics and how we can integrate this with our app. In this post we’ll specifically focus on working with the Python SDK. Initializing SDK Now that we have some context, let’s go ahead and install the python SDK. We have the python package published to pypi.org, under the name archetypewsgi. pip install archetypewsgi Note: If we have python3 insta

Revenue Optimization for Volume Discount Plans: Case Study

Thu Aug 11 2022

Revenue Optimization for Volume Discount Plans: Case Study

In this article we will explore a sample case study as to how an API-first KYC company can adopt a usage based billing model to increase revenues and boost the customer experience for their users. As more companies are shifting from subscription models and annual contracts to usage based billing, teams are starting to analyze how they can apply this same switch to their businesses. We will outline a number of clear pain points mentioned by real customer conversations and how they are thinkin

API Monetization: For Revenue Teams

Fri Jul 15 2022

API Monetization: For Revenue Teams

API Monetization is the process of generating revenue from your APIs. The range of businesses that charge for their API products is quite large, from small seed stage companies to enterprises. The focus of this article will be around the various ways to think about API monetization.

What is Usage Based Billing?

Mon Jul 11 2022

What is Usage Based Billing?

There are many different ways to charge users for the same experience. In this blog post, we'll explore the different recurring revenue models you can have as a business and the tradeoffs for each business model.

Why API Marketplaces Suck

Sat Feb 26 2022

Why API Marketplaces Suck

API marketplaces have been on the rise as a way for companies to find and use APIs. However, there are many reasons why API marketplaces don’t work.

Ready to dive in?