How Can I Credit Multiple Users For One Transaction?

You may want to issue commissions to multiple users over the same sales transaction. This may be necessary when multiple users contribute to a sale, or because you have a multi-level commission structure (ex: override commissions).

There are two ways you can achieve this:

• Configure your plans to allow splits (this article)
• Make an ad-hoc change to allow splits (learn more)

There are cases where splits are uncommon and you just need a quick ad-hoc fix. See this article for more information.

If you have frequent splits, a more structured approach makes sense. This article explains how you can configure your plan to handle splits.

Creating Separate Plans

One easy way to credit multiple users is to create separate plans, each targeting a different crediting field within transaction data.

For example, if your transactions have a field called "AE", and another field called "BDR", you could create 2 plans (one for AEs and one for BDRs). This assumes AEs and BDRs can be paid independently.

Each plan can then refer to the right crediting field, and calculate commissions independently. Here is how you can specify which exact crediting field to use for each plan ("Targets" tab). In this example, we are configuring the AE plan, so we are referring to the "AE" field for crediting purposes.

Crediting Multiple Users Directly
Suppose that you now want the same plan to credit multiple users. For example, you have an AE plan, but multiple AEs may need to be credited with the same transaction.

If you only have one transaction field tracking reps, you can use the || separator within your sales data to request multi-user crediting:

Next, edit your plan and choose the appropriate option based on how you want to handle the split ("Targets" tab):

If you have multiple transaction fields tracking reps, you always specify a list of crediting fields within each plan ("Targets" tab):

Here too, edit your plan and choose the appropriate option based on how you want to handle the split ("Targets" tab):

If you have multiple transaction fields tracking reps, another option is to map them all to the "Owner / Sold By" category when importing data. Here is an example of a CSV file, with reps specified in different transaction fields. In this example, the user is identified by its email address, but other identifiers will also work (learn more here).

When you import sales transactions, you can map multiple transaction fields to the "Owner/ Sold By" category:

You can then edit your plan, and specify how credits should be split between different users by going to the "Target" tab. You can choose to split credits equally between users, assign full credit to each user, split credits based on salaries, etc.

When your plan is submitted for calculation, the crediting engine will split credits between users. It will then determine which rewards each user qualifies for, based on specified attainment levels for the plan.

For more advanced scenarios, use a dynamic crediting rule. This allows you to further control crediting.

Creating Multiple Users Via Teams

Another option is for your imported transactions to specify a team or territory. This makes sense if you have rollups or management override commissions. We'll walk you through an example.

Here is an example of a CSV file containing sales transactions with a team specified. In this example, the team is identified by its name, but other identifiers will also work (learn more here).

When you import sales transactions (from a CSV or other systems), you can map this field to the "Team / Territory" category:

You can then define teams - including team members and a hierarchy (if you have one). Here is an example of a team hierarchy:

Next, create a plan and make sure it's set to measure team / territory performance (the second option):

When you configure your plan, you can choose whether parent teams should be credited with amounts credited to their children by going to the "Target" tab. For example, if a transaction worth $500 in revenue is credited to team "Atlanta", you can choose whether its parent team "Georgia"  should be credited the same amount. Whether this makes sense depends on your business and how you set quotas / goals.

When your plan is submitted for calculation, the crediting engine will assign credits for each transaction to the right team. It will then determine which rewards teams qualify for, based on specified attainment levels for the plan. It will then assign rewards to members of the team as per your specified reward assignment settings.

In the example below, a reward of type "% of revenue" was added. The assignment was configured to split the reward based on team member salaries, but other options are available. Therefore, the crediting engine will lookup the team credited for the transaction, compute the reward (5% of revenue), and assign rewards to members of the team.

Conclusion
This was a brief overview of some of the options available to you. Other options and capabilities are also available such as dynamic crediting. Contact our support team for additional assistance.

• Related Articles

• Error - Can't Credit Transactions

  Applicability This error applies to the following situation: You are importing transactions You do not have any field mapped to category "Owner / Sold By" You do not have any field mapped to category "Territory or Team" Impact This error prevents you ...

• What Does The "Credit Date" Represent?

  The "Credit Date" field tells you the effective date which allowed the transaction to fall within calculation period. When running a calculation for a given time period, we must determine which transactions are eligible based on their dates. In some ...

• How Can I Programmatically Create Or Update Users?

  This article explains how you can create or update users using simple API calls. To add or remove users from teams, see this article. To add or remove custom variables from users, see this article. Create Or Update Users To create or update users, ...

• How Can I Show Users Information About An Upcoming Period?

  Consider the following scenario: You have created a monthly plan and are currently in January You have started a calculation for January and released credits (or rewards) Users can see the January period on their personal incentive dashboard You want ...

• Do I Need To Provide Salary Information On Users?

  Salary information for users is encrypted in the database, and also masked when displayed in the web interface. Also, only full admins can view this field (limited admins cannot). Special security filtering (at the data retrieval level) prevents ...