Provisioning¶
What is provisioning?¶
Provisioning is the process of issuing entitlements to an entity. An entity is the “who” in a business model, this is usually the customer who is tied to the revenue. In this context, an entitlement is the right to a specific product. The “product” could be represented as access to a cloud platform, support hours, virtual credits or really anything. Assigning an entitlement in practice involves giving a customer access to an account or a product. A real world example of provisioning would be a prospect signing up and having an account issued to them. While this scenario is simplistic it can become more complex the larger the customer or product. Contract negotiation, professional services, automation, etc rapidly make the process more challenging. While a business model isn’t meant to solve all of these issues, it should be flexible enough to handle whatever processes are employed.
Onboarding¶
In any well run organization, ample resources are dedicated to inducting new members. This is also true for software vendors, and provisioning is the first step in this process. For a direct sales motion, the go-to-market team will shepherd new customers by offering education, technical support, and collateral to ensure they can start using the product as quickly as possible. Regardless of the support program, if the vendor can’t provision an accurate set of entitlements or it takes weeks to receive the product, onboarding is a failure. This first impression is so important that industry veterans created a billing framework called CPQ (configure price quote) to deliver the best result.
Configure price quote¶
Some of the words in CPQ are may be familiar coming given the last section covered configuration. The main idea behind CPQ is to get everything ready for a prospective customer to be provisioned. This begs the question: what is needed for a customer to receive their entitlements? Our primary concern is which products at what prices. Provisioning is where a legal agreement to exchange money for services takes place! The “configure” and the “price” refer to what pricing and packaging is within the contract. So, if you have followed the configuration section you are armed and ready with “C” and “P”.
The business model serves as a source of truth for pricing, packaging and other default terms for a contract. It’s reasonable to also use this data to help a prospect better understand what they are paying for and how much. This brings us to quotes, which are a by-product of your configuration. A quote is a preview of what a contract could look like under a set of proposed pricing. In the pricing section, we mention that a list price can be thought of as the “starting price”. It can also be thought of as the starting point for contract negotiations and can be seen as the ceiling for the value of the product. In a direct sales motion, which involves direct negotiations with a human, the end price will usually end up discounted. The “quote” is a tool to present how the contract and resulting invoices will look with the negotiated prices and terms. Hence, giving the customer a better understanding of the product’s value. Let’s go through an example of how a quote could be used to explain how much a customer will pay:
A prospect comes into the sales funnel through the inbound a “Contact sales” form found on the website. They speak with a sales representative and find that the product is a good fit for their needs. Negotiation begins at the list pricing and terms that are found in the public marketing documentation. The sales representative creates a quote based on their discussion by moving the price and the years committed. They continue to negotiate until the final quote is agreed upon and the prospect signs the MSA. The customer is issued an account and the business model is updated. At this point the customer has been fully provisioned.
The entire point of this process is alignment between customer and vendor. There are two outputs from this process: A “paper contract” known as an MSA and the data in our business model (the “contract”). Once both of these documents are created and finalized, the initial provisioning process is complete.
Contract lifecycle¶
Onboarding a customer will result in a contract being initiated. Every contract has a start and an end. While we don’t always know when the end will occur, it’s safe to assume any contract can and will be decommissioned. A contract coming to an end can be a good or a bad thing. It could be ending due to an amazing renewal that has come about after a massive upsell. Alternatively, it could be ending due to customer dissatisfaction. Regardless of the situation the beginning and ending of a contract define the bookends of the contract life cycle.
During the life of the contract additional changes may also occur, which result in edits or amendments to the initial terms and conditions. These changes can prolong the life of a contract, adjust it to end earlier or be completely unrelated to the lifecycle. Changes to contract can occur due to numerous reasons, but most of the time they are customer initiated. For example, a customer would like a new product so instead of creating a new contract an amendment is made to the orignal one. These types of one-off asks occur frequently which means there are lots of changes through out the life cycle of a contract.
How is provisioning modeled?¶
Configuration and provisioning data models represent the encoding of the terms from the paper contract. contracts and contract_prices are specifically the fundamental units of provisioning logic. These two models represent what a customer and vendor are owed since they contain the link between a customer and their invoice.
One of the main purposes of setting up reusable pricing and packaging is to assign it to contracts. A contract can then easily reference a pricebook and automatically inherit all of the relevant pricing and packaging. This can lead to a single pricebook being connected to many contracts at once which makes it easier to manage pricing and packaging at scale.
Basic contracts¶
When a contract inherits from a referenced pricebook it will assume all of the same list prices and terms. In the case of a contract with no overwrites the configuration will become the source of truth for pricing, packaging and invoice terms. The contract itself will then serve as the intersection between customers, configuration and dates. In terms of required fields the contracts table must have: customer_id, started_at and ended_at. In order for an invoice to be created products and prices must also exist, but this is not required by the data model directly. Within the Wikipedia example we can demonstrate how basic contracts work by displaying the configuration, a contract and the resulting invoice.
products.id |
products.name |
list_prices.id |
list_prices.price |
pricebooks.durable_id |
pricebooks.name |
invoice_delivery |
invoice_schedule |
list_prices.created_at |
|---|---|---|---|---|---|---|---|---|
1 |
Updates |
4 |
0.05 |
b |
Enterprise |
ARREARS |
1 |
2023-11-01 |
2 |
Creates |
5 |
0.04 |
b |
Enterprise |
ARREARS |
1 |
2023-11-01 |
4 |
Enterprise platform fee |
6 |
5000.00 |
b |
Enterprise |
ADVANCED |
12 |
2023-11-01 |
pricebooks.durable_id |
pricebooks.name |
contracts.customer_id |
contracts.durable_id |
contracts.started_at |
contracts.ended_at |
contracts.created_at |
|---|---|---|---|---|---|---|
b |
Enterprise |
OptimusPrimeBot |
OptimusPrimeBot_contract |
2023-11-01 |
2024-11-01 |
2023-11-01 |
products.id |
products.name |
line_item.price |
line_item.quantity |
line_item.amount |
invoice.total |
invoice.invoice_delivery |
invoice.status |
invoice.contract_id |
invoice.created_at |
|---|---|---|---|---|---|---|---|---|---|
1 |
Updates |
0.05 |
8617.0 |
430.85 |
102547.65000000001 |
ARREARS |
DRAFT |
OptimusPrimeBot_contract |
2025-01-16 00:00:00-08 |
2 |
Creates |
0.04 |
2552920.0 |
102116.8 |
102547.65000000001 |
ARREARS |
DRAFT |
OptimusPrimeBot_contract |
2025-01-16 00:00:00-08 |
Contract overrides¶
A convenient feature of contracts is the ability to override the pricebook and list prices. This is often used to represent discounts or additional terms that come up in negotiations. In practice, this process is similar to how prices inherit and override pricebook configurations. An override can be accomplished by creating a row in contract_prices that references a list price. The contract price model mirrors the fields of list_prices table. To demonstrate we can use the Wikipedia example to model an enterprise contract with an override on the “Create” product. This will result in the line item on the invoice reflecting the overridden price instead of the list price tied to the pricebook.
products.id |
products.name |
list_prices.id |
list_prices.price |
list_prices.created_at |
pricebooks.durable_id |
pricebooks.name |
invoice_delivery |
invoice_schedule |
|---|---|---|---|---|---|---|---|---|
1 |
Updates |
4 |
0.05 |
2023-11-01 |
b |
Enterprise |
ARREARS |
1 |
2 |
Creates |
5 |
0.04 |
2023-11-01 |
b |
Enterprise |
ARREARS |
1 |
4 |
Enterprise platform fee |
6 |
5000.00 |
2023-11-01 |
b |
Enterprise |
ADVANCED |
12 |
products.id |
products.name |
contract_prices.id |
contract_prices.price |
contract_prices.created_at |
contracts.customer_id |
contracts.durable_id |
contracts.pricebook_id |
contracts.started_at |
contracts.ended_at |
|---|---|---|---|---|---|---|---|---|---|
3 |
Platform fee |
1 |
2.00 |
2023-11-01 |
OptimusPrimeBot |
override_contracts |
b |
2023-11-01 |
2024-11-01 |
products.id |
products.name |
line_item.price |
line_item.quantity |
line_item.amount |
invoice.total |
invoice.invoice_delivery |
invoice.status |
invoice.contract_id |
invoice.created_at |
|---|---|---|---|---|---|---|---|---|---|
1 |
Updates |
0.05 |
8617.0 |
430.85 |
102547.65000000001 |
ARREARS |
DRAFT |
override_contracts |
2025-01-16 00:00:00-08 |
2 |
Creates |
0.04 |
2552920.0 |
102116.8 |
102547.65000000001 |
ARREARS |
DRAFT |
override_contracts |
2025-01-16 00:00:00-08 |
One-off invoices¶
Contracts control many of the specifics of an invoice. For example, the start and end date of a contract directly control how many invoices end up being created and when. So in a sense, invoices and line items inherit directly from contracts and their prices. This relationship can be demonstrated in the case of a one-off revenue event like an ad hoc invoice. Since a one-off invoice is by definition a singular event, creating pricing and packaging is a waste of time. Simply creating a contract along with contract prices will generate a requisite invoice. Let’s create one using the Wikipedia example to show the similarities.
products.id |
products.name |
contract_prices.id |
contract_prices.price |
contract_prices.created_at |
contracts.customer_id |
contracts.durable_id |
contracts.pricebook_id |
contracts.started_at |
contracts.ended_at |
|---|---|---|---|---|---|---|---|---|---|
2 |
Creates |
2 |
1.00 |
2023-11-01 |
OptimusPrimeBot |
solo_contract |
2023-11-01 |
2024-11-01 |
|
4 |
Enterprise platform fee |
3 |
5300.00 |
2023-11-01 |
OptimusPrimeBot |
solo_contract |
2023-11-01 |
2024-11-01 |
products.id |
products.name |
line_item.price |
line_item.quantity |
line_item.amount |
invoice.total |
invoice.invoice_delivery |
invoice.status |
invoice.contract_id |
invoice.created_at |
|---|---|---|---|---|---|---|---|---|---|
2 |
Creates |
1.00 |
2552920.0 |
2552920.0 |
2552920.0 |
ARREARS |
DRAFT |
solo_contract |
2025-01-16 00:00:00-08 |
Other types of provisioning¶
This section has descriped provisioning in the context of direct sales but we’d be remiss to not cover other scenarios. There are several more common methods of selling that can alter how you provision entitlements:
Direct sales
Product led growth (or product led sales)
Partnership and affiliate sales
Direct sales is quite literally a human speaking with each prospective customer to sell them the product. Product led growth, or product led sales, is when a prospective customer can complete the sales process completely or partially in the product. Partnership and affiliate sales, also known as a reselling, allow 3rd parties to sell a vendor’s product.
Product led growth¶
In the distant past, B2B software vendors exclusively practiced direct sales motions and built large sales forces to support these initiatives. Over time more tools have been developed to automate sales and billing enabling the product led sales movement. Today, most agree that direct and product led sales are useful and many companies support both. While there is certainly merit in allowing for prospective customers to purchase from their ideal sales channel, there is no free lunch. Supporting two different flows at once requires time and effort. As per usual, it’s up to the practitioner to decide whether or not the tradeoffs are worth it.
Product led provisioning¶
CPQ is normally discussed in the context of direct sales. Salesforce (and the more rarely using Hubspot and Dealhub) offer robust technical solutions in this domain. We won’t go too far on direct sales CPQ solutions because they are marketed and covered by many vendors (see here, here and here for a few materials).
Does this mean we don’t configure, price and quote in product led sales? Of course we do! From our perspective CPQ is a framework not a product or a feature. There are tools that abide by this framework, but don’t define it. So why can’t it be built out directly in the product? Not surprisingly, it has, but most don’t know they are abiding by the architecture of CPQ.
Let’s go through an example to show how a PLG motion which includes all of the elements of the framework and then finally provisions the customer:
The company Lucid charts runs a PLG motion which can be seen from their pricing page. They offer several different plans with different sets of entitlements. This page contains all of the elements of pricing and packaging satisfying the configure and price portions of CPQ.
Attempting to buy the individual plan then requires you to go through a self service payment flow. The order summary shows what you are paying for (a quote for the expected cost).
Once the purchase is complete we can view the contract, which depicts pricing and lists out the allocated products.
Partnerships, affiliates and reselling¶
Building out a sales force, billing and marketing are a few of the primary objectives of a GTM team. This takes time, effort and resources to accomplish even a decent outcome. If instead, another company put in that effort while you build a product… would you take them up on it? The essence of these partnerships is that a 3rd party will take a piece of the GTM burden in exchange for a cut of revenue. App stores, cloud marketplaces, affiliate marketing programs are all examples.
CSP marketplaces¶
There are many different types of partnerships, but we will focus on the CSP (cloud service provider) marketplaces since they are popular and have a substantial affect on automation. The most common CSP marketplaces are also the most commonly adopted cloud service providers:
This chapter will not cover the benefits of marketplaces but instead focuses on how it changes the business model. When working with these partners, they require that the business must also be modeled within the marketplace. Pricing and packaging, provisioning, rating, billing and reporting are co-opted with different flavors of good, bad and ugly. Technically, marketplaces only require you to report usage through their metering APIs and provision customers appropriately. This could be seen as a huge benefit of working with marketplaces, but most companies already have an established process. This means managing a 3rd party system along with your own. Multiple business systems means more people to manage them. More people to manage means more overhead.
Marketplace provisioning requires the same things other processes require. Pricing and packaging must be set in advance or configured using custom prices. This feature is called a “private offer” within the marketplaces. Each marketplace offers its own unique configurations and will review the submission before publishing. A listing will also be published in the marketplace that represents your marketing presence in said CSP. This will also serve as a checkout page for customers to purchase the product (a example is displayed below).
Once a purchase occurs in the marketplace, it will redirect customers to the existing system to provision an account with the appropriate products. How is this new customer reflected in the company owned business model? Replicating the exact pricing, packaging and contract is the ideal way to model a marketplace customer. This allows for the rest of the system to pretend it’s the one administering the process. Fortunately each marketplace offers a variety of notifications and APIs to keep the state of the customer in sync. Accomplishing high fidelity duplication allows for all of the normal reporting mechanisms to stay in place. While metering, rating and billing are forked back into the marketplace, having visibility into which customers are purchasing products in real time is important.