Building a business case for investment

A business case is a document that lays out the pros and cons of a decision (such as buying software or investing resources in a project). This can be extremely valuable to document an evaluation process and memoralize the thinking and decisions made. If you're operating within a larger organization with multiple stakeholders or teams, this can make a substantial difference in speeding up your decision-making.

A simple outline for a business case can be:

We highly recommend you create a business case like this for purchasing a DAP (even if you’re considering building in-house) because it helps in a multitude of ways:

Most of the business case's sections are self-explanatory, so we’ll focus on the least well-understood aspect: the “Expected ROI.” 

For this, we must create an ROI model, a calculation (potentially shown in a spreadsheet over time) demonstrating the expected return on investment (ROI) from building in-house or buying a DAP. 

This model has two sides: the cost/investment and the return. We’ll show you how to build both these sides below: 

Calculating return/revenue/value

It’s better to start with the return side because this will help you estimate how valuable this endeavor could be and help frame your investment choices. 

To do this, you have to do the following:

Key metrics for common use cases

Ideally (and ultimately), you’ll want to increase the number of new customers you can win or reduce the number of existing customers you churn. Use cases tied to these metrics will be easiest to model.

For example, if you improve your user onboarding or trial experience, you are likely to increase your win rate (or conversion rate), or if you improve your self-serve support, you may increase your win rate and reduce your churn rate. 

It can sometimes be hard to directly link improvements in UX or feedback collection to these metrics, so this is where you should discuss or review your assumptions with your project sponsor. No one knows for sure what will happen, so the best way to reduce risk and increase confidence is to make a well-reasoned or logical case, explaining why you think these in-app use cases will lead to these outcomes. 

Calculating Customer Lifetime Value

For any metrics that affect your ability to win or retain customers, you’ll use the ‘Customer Lifetime Value’ (CLV) to understand business value. 

CLV = ARPU (per month) x Lifetime (months)

You can calculate the Lifetime by dividing one (1) by the (monthly) churn rate. 

So, for example, if the ACV of your SaaS product is $24k per year (i.e., $2k per month), and your annual churn rate is 6.0% (i.e., 0.5% per month), you can see that CLV is $2k per mo x (1 / 0.003) = $2k per mo x 200 months = $400k. 

So, in this scenario, each customer is worth (on average) $400k to the business. 

Value of increasing paid conversion rate

If your in-app experiences can increase the rate at which new prospects convert to customers, you can model the value as follows: 

New customers per month = potential new customers each month (e.g., accounts created per month) x paid conversion rate (e.g., account created to subscription started)

Now, you can assume the conversion rate, for example, is increasing by 10%. 

If you have 100 new accounts created per month, and your current paid conversion is 5%, but with a DAP, you hope to increase that by a tenth to 5.5%, that would mean you’d have an additional 0.5 accounts won per month (100 x 0.5%)

However, the value of each account won is $400k, so an extra 0.5 accounts per month is worth $200k (each month), or $2.4M over the year. 

This assumes a flat number for new accounts, but if your presence in the market is growing and you expect to create more new accounts per month, you’ll drive even greater value. 

Value of reducing churn rate

If you can reduce your churn rate by a tenth (from 0.5% per month to 0.45% per month), your customer lifetime would increase from 200 months to 222 months. This would change your CLV from $400k to $444k.

Subsequently, every customer you win will generate an extra $44k (of lifetime value). Using the assumptions above, winning 5 accounts per month leads to an additional $220k of value generated per month or over $2.6M per year. 

Note that this doesn’t assume any changes to your paid conversion rate or the number of new accounts being created monthly. 

Value of reducing support tickets

If you believe that offering more self-serve support or CMD+K search and answers will reduce the number of tickets your team has to handle, then you can also model the value of these. 

To find the cost of handling a support ticket, review the average number of support tickets handled by your support team per month and divide these by the total cost of your support team. 

For example, if your team of 4 handles 120 tickets per month, and assuming the average salary of a CS rep is $60k per year (and an “all-in-cost” factor of 1.2x, which includes taxes and supplementary costs of employing someone), then each ticket costs: 

( 4 people x ($60k per year / 12 months) x 1.2 all-in-cost factor ) / 120 tickets per month = $200 / ticket

So, if your in-app experiences can reduce the number of tickets by 10%, then you are in line to save 12 tickets x $200 / ticket = $2,400 per month (or ~$29k per year). 

The extra time saved from these tickets can be spent elsewhere, or you can handle more customers before your business needs to hire an additional CS rep. 

Value of a better user experience

In addition to the above, there is a lot of less tangible value that can be derived from effective in-product experiences:

You can include these aspects in any write-up of your business case, even if there isn’t a clear numeric value associated with them. 

Creating a more advanced model

Instead of a single calculation that shows the return, you can become more sophisticated in your forecasting so that your calculations are more accurate in the following ways:

The best way to create an advanced model is by creating a simple one that works, and then layering on top of this as necessary. 

Incorporating the cost / investment

Let’s look at the other side of the equation: what would it cost to implement in-app experiences based on building vs. buying? 

The cost of buying a DAP

This should be straightforward, as you can get quotes from the vendors you’re considering. You may even be able to get rough ranges early in the sales process, even if you don’t get a formal or full pricing proposal until later. 

Some things to note about the cost:

Cost of building in-house

This is more tricky to calculate, and most teams underestimate this cost, which can be problematic because it can mean less availability of resources, a longer time to implement and be successful, less overall usage of in-app experiences, much higher cost and time than expected, or all of the above. 

To better understand the cost of building (or using a DAP product that relies on more engineering) let’s make some assumptions: 

To understand the cost, we’ll calculate the engineering time spent, both in the beginning and on an ongoing basis. Additional time from a PM, designers, copywriters, etc., will not be counted as that may not be incremental or different from what would be spent using a DAP. 

The upfront time in creating in-app experiences may be spent on the following:

If you’re starting with a few simple in-line banners, all the above may take as little as a single full day; if you’re starting with a user onboarding checklist, it might take a week, and if you’re building for multiple use cases or creating more intricate/native UX flows it could take a month. You can/should estimate this with your product and engineering team based on the most valuable use cases you’ve identified. 

The on-going (monthly) time could be spent on:

Again, the time spent on this can be quite variable, but it will likely be at least 2 days per month and could easily be 1-2 weeks. 

Generally, when building a case and trying to estimate the ROI, you should err on the side of more conservative (i.e., assume it takes longer than you anticipate) because, at this stage, there are likely many unknowns that can increase the length of time required (just like any product feature). 

Let’s create an example: a SaaS company is looking to improve trial conversion and reduce customer churn with the following:

For this, assuming a high-velocity and skilled engineering team, we could anticipate the time spent over the year to be roughly 1-2 weeks per row (for initial set-up, ensuring patterns match designs, work well in the product, can be targeted well, etc.) and 3-6 days per month (for creating new experiences, adjusting existing, etc.).

That leads to 12-24 weeks (60-120 days) of engineering time over the year.

Now you can calculate the cost based on the “all-in-cost” of an engineer: In the US, the average mid-level software engineer salary at a mid-stage SaaS company is $175k per year (source). Let’s assume a 1.2x “all-in-factor” and 260 total working days per year. This means the cost for the above is ~$50-100k per year.  

Of course, you can/should plug your estimates into this model; you may have a different average salary or consider the time cost to be different. If you want to become more sophisticated, you may also factor in other costs of building in-house, such as QA or design time. 

Assessing opportunity cost

The bigger cost of building in-house is likely the opportunity cost of not pursuing other work. All software companies are constrained by their engineering teams (a finite resource), so developing a solution for in-house user onboarding requires prioritizing it over another project. 

Therefore, you may want to at least list the other project/s that would be parked or de-prioritized to enable capacity for this work. If those projects seem low-value, it improves the case to build in-house, but if they seem potentially high-value, that should be considered in the overall business case.