Open Experiments

Open Experiments


The following experiments are more open-ended. They will require you to figure out things on your own. You may struggle along the way, and wonder why things are not working.

===== Configure A Pay When You Get Paid (2 Systems) Structure (High Difficultly) =====
Start by reading the following:

Create a demo workspace. Demo transactions will represent sales for the purpose of attainment. 

Sign up for a free QuickBooks Online account. You may also request a developer account so you can create sandboxes which don't expire. Invoices will represent payments for the purpose of paying commissions. 

You will need to link invoices to sales. For this, you can create a custom field in QuickBooks Online called "Opportunity ID". Create a few invoices whose "Opportunity ID" is set to the Unique ID of your demo transactions. Mark those invoices as paid in full.

Try to configure one plan based on demo sales. This plan should issue estimated commissions. Consider adding a few tiers with different percentages. You may want to set an arbitrary quota to achieve this.

Next, try to configure another plan based on QuickBooks online payments. It should process paid invoices and lookup a/ beneficiaries and b/ estimated commission rates based on the "Opportunity ID". Try to have a calculation working such that an actual commission is issued.

This is a difficult exercise. Do not hesitate to reach out when stuck. If you are able to make it work, it means you can already handle complex structures.

===== Create an Excel Report (Medium Difficulty) =====
Start by reading the following:

Create a demo workspace. You will connect to the data in this workspace.

Try to create an Excel report which shows the total payout per beneficiary per plan. This will require you to select CalculationResults and follow relationships to other entities (ex: CalculationResult > Calculation > Plan to get the plan name). Even though your demo workspace will not have estimated commissions, consider adding a filter to exclude all CalculationResults whose IsEstimated = TRUE as this is best practice, and because we are looking for actual payouts only.

Next, try to create an Excel report which shows the average per-transaction commission by customer.   This will require you to select CalculationCommissions and follow relationships to other entities (ex: CalculationCommission > CalculationCredit > Transaction to get the customer). Even though your demo workspace will not have estimated commissions, consider adding a filter to exclude all CalculationCommissions whose IsEstimated = TRUE as this is best practice, and because we are looking for actual payouts only.

Finally, examine CalculationResults and CalculationsCommissions. How are they related? What do they represent?

This is a medium-difficult exercise. Do not hesitate to reach out when stuck. If you are able to make it work, it means you can create virtually any report you want.

===== Configure A Multi-Plan Recoverable Draw (High Difficulty) =====
Recoverable draws can be configured per-plan. However, in this case, advances and repayments only take into account payouts calculated for this plan. For this exercise, we want to create a draw plan which takes account payouts from multiple plans.

Create a demo workspace. Create regular 2 monthly plans to your own liking. Run calculations and make sure they both issue some payouts, for the same period, to the same payees. For example, plan #1 issues a $1000 payout to user A, and plan #2 issues a $2000 payout to user 2, for the same period. It's up to you how to structure those plans.

Next, create a draw plan which takes into account payments from both plans. Set a dependency on both plans in advanced options ("Calculations" tab). Suppose that X is the recoverable draw amount. Add formulas such that:
  • If the payout P from both plans is less than X, then we add a positive recoverable payout worth X - P to make up the difference (this is an advance to ensure the guarantee is met)
  • if the payout P from both plans is more than X, then add a negative recoverable payout to repay any amount above X, but no greater than the amount due in recoverable amounts (this is a repayment)

For example, if a payee has received $3000 in payouts from plan #1 and plan #2 combined, and their recoverable guarantee is $2000, they would be able to repay up to $1000, because they still won't fall under the $2000 guarantee ($3000 earned - $1000 repayment = $2000 guarantee). However, if they never had any past recoverable payouts, their owed balance is $0, so we should not deduct anything! If they had past recoverable payouts worth $100, they would repay $100 because they can, and because that's how much they owe. If they had past recoverable payouts worth $6000, they would only repay $1000, as we still have to provide a guarantee of $2000 to them.

To complete this rather difficult exercise, you will need to:
  • Use one or more global rewards (since this is not a per-transaction reward)
  • Query all rewards from plan #1 and #2 for the current period (this is their earned commissions)
  • Query all recoverable rewards for the current and past periods (this is their owed balance)

This may give you a head start:

Two tips in terms of general approach. First, you may choose to configure a single global reward, which either issues a positive or negative recoverable amount. Or you could configure 2 separate rewards, which either calculate an advance or a repayment. Second, you may want to use Min() / Max() functions, or you could use IIF() functions if you prefer. You could also use WHEN() blocks.  

Once you've solved this exercise, evaluate different scenarios to make sure it all works. Enhance your plan to use per-user custom variables, so that the recoverable draw amount can vary by payee. You may also want to introduce a maximum repayment per period, so that repayments are not too aggressive. For example, this could be a $2000 recoverable draw, but with a $500 per-period cap to spread out repayments.

This is a difficult exercise. Do not hesitate to reach out when stuck. If you are able to make it work, it means you can handle complex payout calculations.

===== Analyze Crediting Strategies (High Difficulty) =====
Create a demo workspace, and suppose that a customer wants crediting rules for 2 managers (Eric Smith, Terry Nash) and one VP (Sam Norton):
  • When Daniel Martinez is credited, credit Eric Smith but only starting June 1st
  • When Kate OConnor OR Veronica Haley are credited, credit Terry Nash
  • When Daniel Martinez or Kate OConnor are credited as per the above rules, credit Sam Norton

Consider different strategies to accomplish this:
  • Can you and should you use teams? There is a rollup to Sam Norton, so teams could make sense. At the same time, we're crediting users (no territories are involved). Could you still make it work?
  • Can you and should you use dynamic crediting formulas? What would it look like? Can you implement the rollup via crediting formulas? Is it a good idea?
  • Can you think about some ways to leverage custom variables? Why would it be a good idea? How would you use custom variables to deliver this type of crediting?

Play with different configurations to see what can be achieved. There is some ambiguity in this question. Consider the pros and cons or various approaches. We can follow up with a brainstorming call to discuss the merit of each approach.

===== Configure Custom Attainment (High Difficulty) =====
Create a demo workspace, and suppose that the customer is an insurance company. They want to rename "Revenue" to "Premium". How could you make this happen? Consider the following options:
  • Configuring a plan-level custom attainment metric / formula 
  • Renaming "Revenue" on incentive dashboards

Play with different configurations to see what can be achieved. There is some ambiguity in this question. Consider the pros and cons or various approaches. We can follow up with a brainstorming call to discuss the merit of each approach.

Next, suppose that they want to pay commissions based on the average revenue attained by each rep in a given period. Try to configure a custom attainment metric / formula to calculate this.

Next, suppose that they want to use $10.00 as a quota for reps if they have been with the company for less than 1 year, but $5.00 as a quota otherwise. How would you deal with this scenario?

    • Related Articles

    • Configuration Experiment #C1

      Goal The goal of this experiment is to help you understand how configuration changes impact crediting. For this challenge, you will use a demo workspace and alter the configuration. When asked to write down something, please copy the value to a ...
    • Configuration Experiment #T4

      Goal The goal of this experiment is to help you understand the time dimension in calculation mechanics. For this challenge, you will use a production workspace and enter some configuration. When asked to write down something, please copy the value to ...
    • Configuration Experiment #C2

      Goal The goal of this experiment is to help you understand how configuration changes impact crediting. For this challenge, you will use a demo workspace and alter the configuration. When asked to write down something, please copy the value to a ...
    • 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 #R1

      Goal The goal of this experiment is to help you understand how configuration changes impact crediting. For this challenge, you will use a demo workspace and alter the configuration. When asked to write down something, please copy the value to a ...