Projects

Projects are the main entity in Integration Planner, because the ultimate goal is to compare a set of potential integration projects. Projects contain metadata about the project, the ROI input details, and references to one or more Data Flows that further define the project.

Projects are often 1 to 1 with a given application you might build an integration to, but that doesn't have to be the case. For integrations to large, complex applications, you may break those up into separate projects. This is supported by Integration Planner.

Configuration Options

General

• Project Title - This is a name that will be used throughout Integration Planner to reference this Project.
• Description - This is optional meta data that can be used to further clarify what the project is.

Market Size

• Integration Total Available Market (TAM) - To the extent you can find the information (or reasonably estimate it) how many users/installs does the potentially integrated application have? We'll build your serviceable market from there.
• Integration Servicable Available Market (SAM) % - What percentage of those users/installs are potentially a good fit for your application. It may be 100%, but you should think very carefully about whether it truly is if you find yourself answering that.
• Annual Integration Serviceable Obtainable Market (SOM) % - Of that percetange of potential user/install overlaps, how many do you reasonably think you can close as customers in a year. This is your biggest judgement call and could also serve as your sales target to make sure you get the ROI you're building out.

Revenue

• % SOM Must Have - Of the SOM you calculated, what percentage of those users/installs would view this integration as a "must have" feature? Make sure % SOM Must Have and % SOM Nice to Have do not add up to more than 100%.
• % SOM Nice to Have - Of the SOM you calculated, what percentage of those users/installs would view this integration as a "nice to have" feature? Make sure % SOM Must Have and % SOM Nice to Have do not add up to more than 100%.
• Expected Monthly Churn Reductions - If you were to launch this integration, how many customers/month would you prevent from leaving your product. If you don't know just put 0. If your numbers are relatively low, you can use decimals (e.g. 0.5 if you would lose 6 customers/year).
• Expected Reactivations - How many sales have you previously lost that you believe this integration will bring back to life and turn into customers? If you don't know, just put 0. This assumes a one-time number, not a monthly one.
• Average Monthy Recurring Revenue Per Unit - Of the customers you are targeting this integration, what is their expected monthly recurring payment for your product? (Estimate if necessary.) If you charge an annual or quarterly basis, just convert it to monthly amounts. The algorithm expects it to be monthly.
• Average One-Time Revenue Per Unit - If you charge onboarding or implementation fees, what are they on average for the customers you are targeting for this integration. If you don't charge onboarding fees, just put 0.

How This Is Used

The metrics you enter when configuring a Project are what go into calculating the "Revenue Potential" metric used in the Priority Dashboard. These are effectively the revenue side of an ROI model.