Do You Have A Plan Configuration Checklist?

Do You Have A Plan Configuration Checklist?


We recommend using the following checklist to verify plan configuration. This is a very detailed checklist to help ensure (almost) nothing has been missed. 

================ Plan Configuration Check List ================

Plan - Sanity Check
  • [x] My plan is in the appropriate state (ex: "Active" not "Draft")
  • [x] I have performed an automated review of my plan ("Review" tab)
  • [x] I have exported my plan description as text and reviewed it ("Review" tab)
  • [x] I have verified beneficiaries for my plan ("Benef." tab)
  • [x] I have verified the cumulative vs. non-cumulative setting for all tiers ("Incentives" tab)
  • [x] I have reviewed how per-transaction reward formulas are applied ("To All Transactions" vs. "To Transactions At This Attainment Level") ("Incentives" tab)
  • [x] I have reviewed plan-level advanced options ("Calculations" tab)

Plan - Filtering
  • [x] I have specified the appropriate transaction saved query ("Limits" tab) 
  • [x] I have configured a dynamic filtering formula ("Limits" tab) if appropriate  
  • [x] I am using the appropriate effective date(s) ("Calculations" tab)
  • [x] I have configured appropriate advanced options to "look back" in time (YTD, QTD, etc.) if appropriate ("Calculations" tab)
  • [x] I have verified that only eligible transactions will be selected, even If another data source is added later on
  • [x] I have considered calculating and storing per-transaction values in my dynamic filtering formula

Tips: 
  • Let's say a plan has a monthly payout, but is based on YTD performance, You should configure advanced option "StartDate=YearStart" to ensure all YTD transactions are counted towards attainment. Same thing for QTD plans with monthly payouts.
  • A saved query is more efficient than a filtering formula. A saved query will generate a SQL query which only loads relevant data. A filtering formula will load and evaluate each record (in-memory). Note that you can use a transaction query to pre-filter, and then apply a dynamic filtering formula to post-filter.
  • When choosing an effective date field, any record without this field set will NOT be selected. This may be a good way to filter (or pre-filter) data. For example, if "Payment Date" is your selected effective date, any record with an empty "Payment Date" set will not be processed. This can be an implicit way to scope filtering to a one data source.
  • A filtering formula may be a great opportunity to calculate and store per-transaction values, which can then be re-used by reward formulas. Use the StoreTransaction() function to store re-usable per-transaction calculated values.

Plan - Crediting
  • [x] I have chosen the appropriate plan targets ("Targets" tab)
  • [x] I have specified the appropriate crediting field(s) ("Targets" tab)
  • [x] I have considered individual vs. team-based crediting ("Overview" tab)
  • [x] I have appropriate crediting alerts enabled, so failed crediting is visible ("Targets" tab)
  • [x] If splits are required, I have allowed crediting of multiple targets ("Targets" tab)
  • [x] If splits are required, I have considered both crediting splits vs. creating separate plans 
  • [x] I have verified the need for a dynamic crediting formula ("Targets" tab)
  • [x] I have considered calculating and storing per-transaction values in my dynamic crediting formula

Tips:
  • Only use team-based plans when collective performance must be measured, or when there is some type of territory rollups. One disadvantage of team-based plans is that you must define quotas on teams (not users). Indeed, teams (not users) will be credited and are the target. Also, with teams, there is only one way to "slice" the hierarchy. This is not suitable if the same hierarchy needs to be dissected across multiple dimensions.
  • Assume that transactions specify territories (not users). You may assume that the only choice is to create a team-based plan. However, also consider the following alternatives:
    • Create an individual-based plan. Set the crediting field to be the territory field. Choose the option to credit users via teams (see advanced options on the "Targets" tab). When the system sees a team on a transaction, team members and/or managers are credited.
    • Create an individual-based plan. Set the crediting field to be the territory field. Add aliases on users with team names. When the system sees a team on a transaction, users with the corresponding alias are credited.
    • Create an individual-based plan. Set the crediting field to be the territory field. Add custom variables on teams to indicate which users should be credited. Configure a crediting rule to lookup the custom variable on the team and credit users.
  • If splits are required, enable the appropriate "If Multiple Users Match" advanced option ("Targets" tab). If you require a dynamic crediting formula, you can use "||" or ";" as separators. In some cases, using a separate plan may be an easier way to implement splits.

Plan - Attainment Metric & Goal
  • [x] I have configured the appropriate attainment metric ("Overview" tab)
  • [x] If attainment is based on a Custom metric
    • [x] I have entered a custom formula.
    • [x] I have verified whether checkbox "this is a global attainment value" should be checked
    • [x] I have provided a metric name (ex: "Sales") and unit name (ex: "Count")
  • [x] If attainment is based on a per-target custom variable
    • [x] I have chosen "As Percentages Of a Per-Target Dynamic Quota" in the attainment mode dropdown ("Incentives" tab)
    • [x] I have entered a custom variable to use for quotas
    • [x] I have verified that the specified custom variable is set on target users or teams ("Incentives" tab)
  • [x] I have verified the need for a dynamic quota formula ("Incentives" tab)
  • [x] I have considered calculating and storing per-calculation values in my dynamic quota formula

Tips:
  • A Custom attainment metric is preferable to a Score attainment metric, because you can customize its name and units. You also have the option to calculate a global attainment value.
  • If you are using a team-based plan, the credited targets are teams, so quotas should be specified as custom variables on teams (not on users).
  • If using a QTD or YTD plan, and quotas have been entered monthly, you probably should specify "#+" or "!+" (not of "@@", "##", or "!!").

Plan - Attainment Levels
  • [x] I have verified all attainment thresholds ("Incentives" tab)
  • [x] I have checked whether tiers should be cumulative vs. non-cumulative ("Incentives" tab)
  • [x] I have confirmed whether blended rates should be used ("Calculations" tab)
  • [x] I have considered the possibility that attainment may be negative ("Incentives" tab)
  • [x] I have considered the possibility that some targets may not have any attainment ("Calculations" tab)

Tips:
  • Choosing whether attainment levels are cumulative vs. non-cumulative is extremely important and a common mistake.
  • To use blended rates, enable the corresponding "Per-Transaction Buckets" advanced option ("Calculations" tab).
  • If it's possible for attainment to be negative (ex: refunds), the first threshold probably should not be ">= 0" but something like -999999 to ensure reward activation ("Incentives" tab).
  • If it's possible for some targets to have no attainment (ex: no transactions credited), you may need to configure option "When No Transactions Credited" and provide a default attainment value such as zero ("Calculations" tab).

Plan - Reward Formulas
  • [x] I have verified how per-transaction reward formulas are applied ("To All Transactions" vs. "To Transactions At This Attainment Level")
  • [x] If the plan is YTD / QTD, I have added a condition to skip over transactions which are not in-period
  • [x] If blended rates are used, I am using [Transaction].[calculated_primary_metric]
  • [x] I have set the $explanation variable to describe each payout (ex: $explanation = 'Level 1')
  • [x] I have verified advanced options on payouts, such as Estimated, Pay Once, etc.
  • [x] I am dividing by 100 when values (ex: custom variables) are specified as percentages (ex: "10" means 10%)

Tips:
  • Choosing how a per-transaction formula is applied to transactions is extremely important and a common mistake.
  • If your plan is YTD or QTD, and you don't use deductions, you should add a statement to exit if [Transaction].[in_period] is 0. This ensures you only pay over transactions in the current period.
  • Suppose that you are using blended rates. Suppose that your attainment metric is Revenue. You should use [Transaction].[calculated_revenue] in reward formulas. This ensures the revenue amount is split when crossing tiers. Using [Transaction].[Revenue (System)] instead would yield the full (un-split) amount. If you need to calculate rewards based on a metric other than your attainment metric, you can use [Transaction].[bucket_weight] to pro-rate.
  • Make sure to double-check advanced options within reward formulas, such as Estimated, Pay Once, etc.

Plan - Incentive Dashboards
  • [x] I have set meaningful reward titles when configuring rewards ("Incentives" tab)
  • [x] I have examined incentive dashboards to review the look-and-feel for payees
  • [x] I have enabled "Per-Transaction Rate" options if appropriate ("Calculations" tab) and checked it's applied to the correct metric
  • [x] I have enabled "Per-Transaction Explanation" options if appropriate ("Calculations" tab) and set $explanation in my reward formulas
  • [x] I have configured advanced options to display stored values if appropriate ("Calculations" tab)

Tips:
  • Simple tweaks can can make incentive dashboards a lot more appealing
  • To store and display per-transaction amounts, see this KB
  • To store and display per-calculation amounts, see this KB

Plan - Edge Scenarios
  • [x] I have configured appropriate plan dependencies in advanced options ("Calculations" tab)
  • [x] I have scoped calls to GetCommission() and related functions as needed
  • [x] I have considered scenarios where a transaction's date is moved to another period
  • [x] I have considered scenarios where a transaction's amount is negative
  • [x] All my formulas include comments
  • [x] I am making use of lookup tables when appropriate

Tips:
  • If a plan has a dependency on another plan (ex: pay when you get paid, draw plan), make sure to specify a dependency on the "Calculations" tab. This is common for plans which issue actual commissions based on previously calculated estimated amounts.
  • Let's say that you call GetCommission() to get the estimated commission amount on a specific transaction. You may need to specify the planId parameter, if the payee can receive a per-transaction commission on the same transaction, but via another plan.
  • If it's possible for the effective date to "move" to another period, you may want to issue the difference between a/ what has been paid so far on this transaction to the payee and b/ what is the re-calculated owed amount.
  • You may want to define plan-level lookup custom variables and refer to them in formulas. This avoids hardcoding too many values within formulas.

Calculations
  • [x] I have checked calculation alerts and understand each one
  • [x] I have checked the "Credits" tab
  • [x] I have checked the "Rewards" tab
  • [x] The calculated amount makes sense (ex: it's not $0.01 or $999,999,999)

    • Related Articles

    • Configuration Experiment #V3

      Goal The goal of this experiment is to help you understand how to use custom variables in your configuration. For this challenge, you will use a demo workspace and enter some configuration. When asked to write down something, please copy the value to ...

    • Configuration Experiment #V5

      Goal The goal of this experiment is to help you understand how to use custom variables in your configuration. For this challenge, you will use a demo workspace and enter some configuration. When asked to write down something, please copy the value to ...

    • Configuration Challenge #R3

      Goal The goal of this configuration challenge is to get your familiar with various formulas. For this challenge, you will analyze formulas and try to determine why they were added. Comments were removed to make the task more difficult. Difficulty ...

    • Configuration Challenge #R2

      Goal The goal of this configuration challenge is to get your familiar with various formulas. For this challenge, you will analyze formulas and try to determine why they were added. Comments were removed to make the task more difficult. Difficulty ...

    • Configuration Challenge #R1

      Goal The goal of this configuration challenge is to get your familiar with various formulas. For this challenge, you will analyze formulas and try to determine why they were added. Comments were removed to make the task more difficult. Difficulty ...