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.

A 15-minute food delivery service plans to onboard drivers digitally by 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.

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.

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.

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).

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.

The negotiation 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 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 pain points 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.

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 sales@archetype.dev or on Twitter @getarchetype.