SaaS Model - Ratio Driven Growth - For Startups

I have done quite a few SaaS financial models and quite a few more customizations therein. One of the main build-ups I have not done yet is one based on the ratio between different employee types combined with quota attainment of Account Executives. Also, check out this SaaS Rolling Revenue Forecast.

$125.00 USD

The template will be immediately available for download after purchase. This is included in the SaaS financial model template bundle.

Recent Updates: Added fully integrated financial statements (IS/BS/CF), cap table, and capex with depreciation logic.

The goal is to have a universal template that can be used for many SaaS businesses. Industry standards have been used as much as possible. Here is how the model works from an operational perspective:
  • The user will define the amount of Sales Directors (SDRs) hired per month (this can be adjusted in each year separately) as well as the starting headcount of SDRs.
  • The user will define how many Account Executives (AEs) should be planned to exist per every 1 SDR. This can also change each year to account for the natural effect that often happens where there tend to be more AEs per 1 SDR as revenue increases. i.e. in year 1 you may have 1.5 AEs per every 1 SDR but in year 5 you may have 2 - 3 AE's per SDR. All of this can be controlled with simple inputs.
  • The user will define the expected monthly quota per AE. This means the amount of new paying customers that an AE signs up each month. Also, inputs exist to determine how long it takes the AE to start meeting their monthly quota. There are up to 5 monthly ranges for the AE to build up to 100% of their quota and you can have them reaching their quota earlier if desired.
  • The user will define the number of customer service reps (CS) that are needed per x number of monthly sign-ups plus per number of current active customers.
  • The user will define the annual salary per SDR/AE/CS in each of the 5 years.
  • The user will define the percentage of revenue to be allocated to an engineering budget per year. Based on that percentage, the % of type 1 to type 2 engineers and the annual salary of up to two types of engineers, the engineer headcount populates.
  • Logic was added so you can plan when SDR's and AEs actually start being hired if it is not the first month of the first year of the forecast.
  • There are then fixed expense assumptions for executive hires, other general and administrative expenses, sales and marketing expenses, and research and development expenses.
  • COGS is defined by two possible calculation. They include the cost per active user per month and cost as a direct % of revenue. You can use either or both.
  • There are one-time startup costs and capex assumptions.
  • There are assumptions for any investor equity and/or debt. Based on the assumptions, it will auto-populate if any more equity is needed from owners if the investor and/or debt proceeds don't cover the total cash requirement.
  • I included a monthly and annual P&L detail as well as a cash flow summary, executive summary, and contribution/distribution summary that shows the final annual effects of all the assumptions.
  • There are advanced metrics, including CaC, CaC payback (months), LTV, LTV to CaC, Avg. revenue per employee and Avg. revenue per user.
The primary reason for using a lot of ratios is that it allows the user to plan this financial model without thinking too hard about scale. Instead, nearly all the scale happens based upon the defined ratios. This is more efficient than trying to figure out how many AEs / engineers / CS reps you need over time without having them based on the other areas of operation. The only thing you have to think about is how many SDRs you want to hire per month. This results in more realistic financial forecasting in the long run.

Note, I am not a financial advisor and this is not financial advice. It is just a tool so use at your own risk and enter your own assumptions. The figures I have entered in the template you see in the video are arbitrary, but the thought that goes behind them is important for the user to understand when planning their own scenario.

For pricing help, see this SaaS pricing simulator.