Topics Covered In this Article: Click the relevant subject to view
Basics
Advanced
Basics- Using Pre-Built Revenue Objects In the Model
Intro to Revenue
Customer Acquisition drives your revenue streams. If you're looking to make your revenue projections larger or smaller you are almost universally going to visit your customer acquisition assumptions first to have the largest impact on future revenue.
To add a Revenue Stream to our financial model, we'll click the big purple action button in the upper-right corner of the page and select our appropriate revenue "Type". Then, we'll have the option to choose from a few variations of that revenue "type", usually "simple" or "advanced".
"Simple" Build types of the different revenue streams are Disconnected from customer acquisition- they are NOT linked to customer acquisition by default.
"Advanced" or Other revenue streams NOT labeled as "Simple" are Connected to customer acquisition by default and will naturally pull in customers from customer acquisition.
Adding Revenue Streams in the Platform and Adjusting Metrics
As a person generally operating the model once it's set up, 95%-100% of operating your model and understanding it is feeling comfortable adjusting the input metrics (white background metrics), not messing with formulas / more complicated tasks.
How to Add "Tiers" of Revenue and Divide Customers Between Them
The "% of Total New Customers" metric is used to identify how many of the customers from customer acquisition choose the specific revenue stream that you're working in at the time.
If it's not possible for customers to choose to be in two revenue streams (For example, if it's not possible for a customer to be in a free tier and a pro tier) you need to manually make sure that your "% of Total New Customers" metrics across all the revenue streams (where this is true) equal up to 100%
Example:
Tier 1- 60%
Tier 2- 40%
If it IS possible for there to be overlap in two or more of your revenue streams / product offerings then it is okay to have the % of Total New Customers metrics (where this is true) equal up to MORE than 100%
Example:
All of your customers must have a subscription to make purchases on your platform. This means Subscription Revenue has 100%.
But only 20% of your customers can be expected to make purchases on your platform once they have a subscription. Transaction Revenue also has 20%.
Adding additional Revenue Streams
Seeing how Customer Acquisition Effects Revenue Streams
It's important to note that if you aren't bringing enough customers in monthly to mathematically make a single person, you won't bring in ANY people that month.
This is a common issue with low-volume customer acquisition in any form of modeling and also shows itself as an issue when you have revenue streams split out to a number of tiers that your customer acquisition forecast doesn't support.
For example: If I have 6 Tiers of revenue and only project 2 people a month, it's not possible to split up 2 people into 6 tiers mathematically (using our % of Total New Customers Metric) in a way that will allow me to say some % of them should be divided evenly.
To remedy this, you need to make sure if you want to break out your revenue into Tiers that you can split up the number of customers you plan to bring in monthly at least evenly between that number of tiers.
If you think of your business on a small, medium, large approach where the small customers are acquired more often than medium and medium is acquired more often than large, it may be necessary to split up your customer acquisition the same way so that you're ONLY bringing small customers into the small revenue stream (which would allow your % of total new customers metric to be 100%) and doing the same for the medium and large. This will ensure all your customers can flow into your revenue streams without issue.
Advanced- Building Revenue Streams From Scratch Using "Custom".
Intro: Theory of Simplifying Revenue and Building Base Layer of Custom Revenue
This video assumes you are comfortable building formulas so the actual steps to do so aren't in this article, instead you can easily leverage our full article / video walkthrough on Building Formulas and Linking Data by clicking the link for that article at the bottom of the page if you aren't familiar with those concepts.
Base Layer: Revenue at any point, will always boil down to People X Price. This is as simple as your revenue stream can ever be, and at the heart of every complicated build, is as simple as every revenue model is. From there we just layer on complexity to determine things like, "which people?", "how often is payment happening?", "how much of the payment is ours?", and questions like this.
Layer 1 of Complexity- Introducing specific customer channels and tiered revenue:
It's likely that you'll have more than one revenue stream, so we need to introduce the concept of some % of customers choosing one revenue stream vs. another. We do this by adding in an additional metric, usually called, "% of Total New Customers". This metric will be multiplied by the number of new customers coming in from customer acquisition.
The second concept introduced here would be the idea of "customer segmenting". If you have customers, for example who only interact with your SAAS revenue, and customers who only interact with your E-Commerce revenue then you need to ensure your metric calculation points to the specific customer acquisition strategy or customer acquisition category that matches which customers will interact with the revenue stream.
Layer 2 of Complexity- Breaking down "Price" into more Granular detail like "Average Transaction Size" and "Average Number of Transactions".
Compounding complexity and creating more "levers" that make up your price is a likely next step for building out a more granular revenue stream. The video also answers the question "Do you NEED this level of granularity?" The obvious answer is, it depends. If you're a subscription SAAS company, likely not- unless you're breaking price down on a "per seat" basis (Avg. Number of Seats X Average Price Per Seat = Price for a single company based average on number of occupied seats). If you're a marketplace, however, then it may be more appropriate to want to see an average transaction amount as well as the frequency (number) of transactions to gain more insight into the evolving "use" your platform is receiving.
By adding breaking the "Price" input metric down into two, smaller input metrics that make up price we now gain the ability to shape those behaviors over time and gain more insights using assumptions. For example, now we can say the number of transactions increases over time but the price per transaction doesn't or vice versa and this will let us identify what's driving revenue growth over the life of our model.
Before adding more complexity, we pause here at a guide for determining "how complicated" you should make your revenue streams to balance ease of presentation, navigation, and maintenance.
Tracking- If you don't track (or have plans to track) the data to the degree that you have it detailed in your model you need to simplify your financial model / revenue streams.
Presentation- Try presenting your model / revenue streams. Does it feel organic? If I tell you "I'm going to Walmart to pick up milk", you understand what I said. If I tell you I'm going to 3547 West Dunbar Ave, Milton, New Hampshire 78546 to pick up milk- you probably wont' know what I'm talking about even though that's the EXACT place I'm going. Speaking in addresses isn't normal, and you don't want your presentation to feel that way- more detail is not always more effective communication.
Defensibility- The further you break out your metrics into smaller parts and the more detail & complexity you add, rather than leveraging the law of averages, you begin to create / introduce more and more data points that you have to be able to defend. If you have price broken up like this:
Price = Average Transaction Size * Average # of Transactions Per Hour * Average Number of Hours Per Day Transactions Occur BUT you don't have any way of defensibly presenting a strategy that you know can increase the average number of transactions per hour (or to that degree of detail), you need to simplify your model / revenue streams.
Layer 3 of Complexity- Adding in items that augment revenue recognition on a transaction- a take rate
By adding a "%" input metric and then linking it within your revenue formula you can create a "Take Rate" that allows you to demonstrate how much of the revenue immediately received (or potentially passing through your platform) is actually recognized as revenue.
For example, if you have a service being delivered to a customer via a contractor and the contractor has an immediate take on 70% of that revenue, your take rate would show that you only recognize "30%" of the revenue generated from each transaction.
Layer 4 of Complexity- Introducing the ability to track customers within a revenue stream and account for churn (also known as "subscription logic").
Adding in a "subscription" logic will also give you access to the logic needed for several other more complex behaviors such as these:
Such as referencing customers from X months ago (to account for repeat purchase behaviors),
The ability to introduce "upgrade rates" where some % of the total customers you have at one point will effectively "churn out of one revenue stream and go INTO another" (this would work exactly like churn does but you would then add the now "leaving" customers to another revenue stream's customer base.
Layer 5 of Complexity- Building in Seasonality / Triggers for Revenue
This concept is simple on its own- we need a single metric to work as a multiplier in our revenue equation.
If you're taking the "trigger" approach or the "on/off" approach, then you need to override the value(s) of this metric so that it is only a value of 1 in the months where you need revenue and a value of 0 in all the months where you don't expect revenue.
If you're taking the "seasonality" then this metric should be a decimal but the same principal of overriding it will apply. Instead of thinking of the revenue as "on/off" necessarily, you'll be using a value of "1" as a baseline and using some decimal less than one to imply that business is "slow" in that month the same way you'd use a value higher than "1" to imply business is "accelerated" in that month.
You can reference this article in our expense walkthrough for making a non-monthly expense which details the two approaches we have to making a number repeat automatically at some interval rather than you needing to change every month's value across a 60+month forecast.
Demonstration of Breaking Out Revenue Streams to Target Customers (Small, Medium, Large)
It's important to note that if you aren't bringing enough customers in monthly to mathematically make a single person, you won't bring in ANY people that month.
This is a common issue with low volume customer acquisition in any form of modeling and also shows itself as an issue when you have revenue streams split out to a number of tiers that your customer acquisition forecast doesn't support.
For example: If I have 6 Tiers of revenue and only project 2 people a month, it's not possible to split up 2 people into 6 tiers mathematically (using our % of Total New Customers Metric) in a way that will allow me to say some % of them should be divided evenly.
To remedy this, you need to make sure if you want to break out your revenue into Tiers that you can split up the number of customers you plan to bring in monthly at least evenly between that number of tiers.
If you think of your business on a small, medium, large approach where the small customers are acquired more often than medium and medium is acquired more often than large, it may be necessary to split up your customer acquisition the same way so that you're ONLY bringing small customers into the small revenue stream (which would allow your % of total new customers metric to be 100%) and doing the same for the medium and large. This will ensure all your customers can flow into your revenue streams without issue.
Helpful Related Topics and Articles: