What Are Rules?
In general terms, a rule is a set of calculation steps applied to data from specified activity in order to determine certain results from it.
Core supports 3 different types of rules for producing results:
- Payment rules calculate commissions, bonuses, and other incentive amounts earned from various sales activities.
- Info rules produce non-payment performance measure results like quota attainment, sales contest rankings, product margins, revenue schedules, etc.
- Data management rules transform data to support rules building and reporting requirements.
In Core, collections of these rules, grouped into plans, are used to automate the commission process.
One Rule or More?
The Core rules engine is very robust. It is possible to build a rule that performs all the calculation steps for multiple incentives. However, as more data and criteria are added, the complexity of the rule grows increasingly difficult to maintain in that approach. Rule changes, reporting, and auditing results become confusing and impractical to manage efficiently.
Consequently, best practices for building commission rules advise “one rule for each incentive type” a company offers to its salespeople.
For example, one rule contains all the detail for calculating the amount to pay for closing a new sale. Another rule supports the calculation steps and data for commissions earned for renewing a service contract. These represent individual rules because they are designed to reward different activities and the calculation steps and data required to calculate each is different.
Info and data management rules follow similar guidelines. Other considerations for deciding to build one rule per key result or multiple results combined into a single rule include:
• Do the incentives use similar data and fields?
• Are the calculations substantially different from other rules?
• How many calculation fields are required in reporting for each incentive?
• Will auditing be significantly easier with multiple rules?
Examples of components that fit into a single rule versus those that require multiple rules are listed below.
Elements often covered by a single rule:
– Multiple calculation variables.
– Variables that apply to multiple people and groups (even at different rates).
– Components that use multiple master tables like rates by product, tier levels, sales assignments, etc.
– Different “use cases” like adjustments for role splits that might happen occasionally.
– Decision trees with different output options.
– Manual overrides of variables or payouts.
– Tiered rate structures and accelerators.
Requirements that generally necessitate multiple rules
– Reporting more than three calculation results from a rule.
– Balance forward operations.
– Data merging rules.
– Management override splits that use different calculations.
– Complex use cases or a high number of exceptions.
1. Does a single rule calculate the payment for just an individual or can it apply to a group?
A rule will typically pay a group for a specific type of activity like selling to a new customer versus upselling to an existing one which might be based on different data and calculations and handled in a separate rule.
2. Can a rule reference independent rate tables in addition to performing the necessary calculations?
Individual rules allow for multiple calculation steps and references to multiple tables for different rates or other factors needed in the calculations.
3. Can a single rule pay splits at different rates to different people?
One rule can pay multiple splits from a transaction even if different roles are paid at different rates. However, if the calculations for paying splits for other roles are very different, then more than one rule might be necessary.
4. If a single rule has multiple calculation steps, how many of the calculation/output results from that rule can be put on a report or dashboard?
While rules can have numerous data references and calculation steps, best practices recommend no more than three types of reportable output per rule to minimize complexity.
5. Can I include all my incentive types in a single rule?
While it is possible to do this, overly complex rules across a number of incentive types make auditing and reporting more difficult. Best practices recommend building rules in a way that makes them easy to audit and report on.
6. Are chargeback events built into the same rule that calculated the payment that later needs to be recovered?
Chargebacks usually have very different criteria for recovery than the rule required for the initial payment. In most cases they are handled in a separate rule.
7. What factors determine if a single rule can be used or if multiple rules are needed?
In general, if desired outputs differ significantly in the steps needed to produce results, the fields and data used in the calculations, or the activity they are targeting, then separate rules are best. Other factors include the number of exceptions or use cases in a rule, reporting requirements, and ease of auditing.