Financial planning for SaaS startups

[Update 03/23/16: I've created an improved version of the template - check it out!]

A few people who read my recent post about financial planning asked if I could provide an example for a good financial plan, so I'd like to post one here. The plan is very similar to the one that I created in the very early days at Zendesk and re-used a few times in the meantime, but I had to make a few adjustments to make it more generic.

It's a simple plan for an early-stage SaaS startup with a low-touch sales model – a company which markets a SaaS solution via its website, offers a 30 day free trial, gets most of its trial users organically and through online marketing and converts them into paying customer with very little human interaction. Therefore the key drivers of my imaginary startup are organic growth rate, marketing budget and customer acquisition costs, conversion rate, ARPU and churn rate. If you have a SaaS startup with a higher-touch sales model where revenue growth is largely driven by sales headcount, the plan needs to be modified accordingly.

For non-SaaS business models the template needs to be modified more heavily or may not be useful at all, other than that it shows my way of thinking around business planning. That was one of the points that I was trying to make in the original blog post – you can't simply re-use a template, your financial plan needs to mirror your specific business case.

Here's the plan as a Google spreadsheet. If you want the original Excel version please let me know (yes, Excel is one of the few desktop apps that I'm still using).

[Update: If you'd like to get the original Excel version, which looks a bit nicer, you can download it here. If you like it, tweet it!]

The grey box at the left contains all assumptions (blue text color). Everything on the right is calculated, no hard-coded numbers there. I have, of course, used dummy numbers for all assumptions.

The model should be largely self-explanatory but here are a few notes:

• It all starts with the signups that you're adding. I've separated signups into non-trackable signups (signups that you get from word of mouth, PR and so on) and trackable signups (signups from AdWords and other paid advertising where you can track the costs of acquiring a signup). You may have to break this down further depending on your customer acquisition channels.
• Then I'm assuming that you're converting a certain percentage of signups into paying customers (with a one month time lag, assuming that you have a 30 day free trial). The model contains just one conversion rate regardless of the signup source. You can change that if your conversion rate varies depending on the signup source.
• Next up, I'm calculating revenue by multiplying the (approximate) number of customers that you have mid-month by your average revenue per account. If you have a tiered pricing model or a per-seat pricing, consider modeling that.
• Moving down to the costs side – this should all be self-explanatory. Just replace the dummy values by your actual values or assumptions and add additional expense categories as needed.
• Regarding P&L and cash-flow, I'm keeping things really simple here and am assuming that your EBIT is equal to your operating cash-flow. That is, I'm assuming that you're charging your customers on a monthly basis, that you're not making any investments (in accounting terms) and that there are no taxes or interest payments. I think that simplification works well for most very early-stage SaaS startups but it of course needs to get more sophisticated as you grow.
• Last – but not least because this is one of my favorite parts – the sanity checks: I've seen MANY financial plans with an EBIT margin north of 90% in year 3. That's a classic mistake which can happen if you project your revenues to grow exponentially but don't provision realistic increases on the costs side as well. Adding some sanity checks will help you spot these mistakes and make sure that your plan remains realistic. For example, I've included the number of paying customers which each support agent needs to take care of. If that number gets too high you need to allow for more support staff.