Recipe - How To Setup Manager Override Plans

Recipe - How To Setup Manager Override Plans


This article applies if you want to setup a plan which pays override commissions to managers. For example, this could be a territory manager plan, which pays commissions to managers based on sales from reps within their territory.

Becoming Familiar With General Plan Setup
We first recommend first reading this article to become familiar with fundamental mechanisms of plan configuration.

Create Teams
Start by creating teams within Sales Cookie. Make sure to specify a manager for each. Also make sure to add team members.



If you have quotas, they should be defined as custom variables on teams (not on users / managers). Indeed, we want to measure sales performance vs. a goal. Teams is who will be credited, even though rewards will go to managers. So to recap:
  • Define quotas on teams because crediting will be team-based
  • Define payout rates on teams or users / managers as appropriate (both are valid use cases depending on whether commissions are based on team-based rates, or manager-based rates)

Specify Plan Targets
The goal here is to ensure the plan targets the right individuals or teams. First, make sure you've selected "By Team" on the home page of your plan. 


Next, you could target teams with a certain tag, or explicitly list target teams. Follow this article to specify plan targets.



Select Crediting Field
The goal here is to ensure the plan credits targets correctly when processing transactions. If your data has a territory field, you can specify it. Follow this article to specify the crediting field.



If you do NOT have a territory field within your data, how can we credit the correct team so that we can pay the manager an override commission? 

Perhaps you have another field with the rep name / owner. In this case, we can lookup the rep name, figure out which team this rep belongs to, and credit the corresponding team.  



For other cases, you can use a dynamic crediting formula to process transaction data and decide which team should be credited. For example, here we are returning "WA" when the ZIP is 98052 or 98004. If you have a team with an alias of "WA", it will be credited with the transaction.



Finally, if your target teams include a hierarchy, you should decide whether you want a rollup from child teams to parent teams. Most of the time, you would choose this setting to ensure multi-level rollups.



Select Eligible Transactions - Filtering
The goal here is to ensure the plan only processes eligible transactions based on a criterion. Follow this article to filter transactions.



Select Eligible Transactions - Effective Date
The goal here is to ensure the plan only processes transactions within the calculation period based on each transaction's date. Follow this article to set your effective date field.

Define Attainment
The goal here is to define attainment for your plan. Follow this article to configure attainment.

Refine Tier Behaviors
The goal here is to define how tiers work. Follow this article to refine tier behaviors.

Define Rewards
The goal here is to add rewards to each attainment level. Follow this article to define rewards. You will notice that, because your plan is a team-based plan, you can assign rewards to managers. Teams will be credited with transactions, but payouts will go to team managers.



An Alternative To Team-Based Plans
Sometimes, you want to pay override commissions to managers based on special assignment rules for which teams don't make sense. 

Let's say that, if the sold product is A, you want to pay a certain manager, but if the sold product is B, you want to pay another manager. It would be awkward to use setup teams called A and B, and credit transactions to teams based on the product name.

In this case, you can use a user-based (not team-based) plan, with a dynamic crediting formula. In this example, we check the product name. Depending on whether the product is A or B, we lookup a custom variable called "@@ManagerA" or "@@ManagerB" set on the credited user. Now, for each rep, you can specify which manager should be credited for product A vs. product B sales. 
 


    • Related Articles

    • Recipe - How To Efficiently Setup A New Plan

      This article describes a recipe to efficiently create plans based on common patterns. Those patterns work for 75% of plans. This article is intended to be a compact reference and provide general guidelines. Initialize Plan The goal here is to quickly ...

    • Recipe - How To Setup "Pay When You Get Paid" Plans (Invoices Only)

      Advanced Setup This is an advanced setup because two different timelines are involved. One timeline is associated with opening invoices. Another timeline is associated with receiving payments. Sometimes, 2 systems are involved as well (ex: a CRM ...

    • Recipe - How To Setup A Monthly Plan With QTD Attainment

      Advanced Setup This is an advanced setup because there are two different ways you can setup plans with QTD attainment but frequent payouts (ex: monthly). This article applies if you want to setup a plan whose attainment is QTD, but pays commissions ...

    • Recipe - How To Setup A Monthly Plan With YTD Attainment

      Advanced Setup This is an advanced setup because there are two different ways you can setup plans with YTD attainment but frequent payouts (ex: monthly). This article applies if you want to setup a plan whose attainment is YTD, but pays commissions ...

    • Recipe - How To Setup "Pay When You Get Paid" Plans (2 Systems)

      Advanced Setup This is an advanced setup because two different timelines are involved. One timeline is associated with closing deals. Another timeline is associated with receiving payments. Often, 2 systems are involved as well (ex: a CRM system and ...