Compensation Plan Communication and Documentation Best Practices
Please, no one pagers! Compensation plans cannot be communicated to software developers with merely a one-page chart of title requirements and compensation percentages.
Did you know that the document you created to explain your compensation plan to your sales force is not detailed enough for your software providers or developers? That’s because there are conditions you don’t tell your sales force in their document that you need to explain to your software company.
The best way to communicate the requirements of your compensation plan to software developers is to create a complete technical design document.
What is in a complete technical design document? I’m glad you asked, so I’ll tell you.
Placing your definitions at the beginning of your technical design document is imperative. This way, they will be read first. When definitions are placed at the end, they are easy to miss.
In your definitions section, be sure to define all off the types of volume that you will track for calculation or reporting purposes. These could include Personal Sales Volume, Group Sales Volume, and Organization Sales Volume, for example. If a volume is calculated differently at times due to an exception, explain the exception in the definitions section.
Define exactly what it takes for a consultant to be classified as active, inactive, bonus qualified, etc. If there is more than one type of sponsor relationship (for example, enroller relationships and placement relationships), explain each of them clearly.
It is not a good idea to explain your compensation plan elements only in a chart. Use as many words as you need to fully explain each of your compensation plan.
Be sure that whatever terms you use to explain what is required for title promotion and title maintenance, these terms are first introduced and defined in the definition section at the beginning of your technical design document.
I learned a long time ago that it is not good enough to have a great set of definitions, an explanation of each compensation type, details on the title promotion and maintenance requirements for each title, and a summary chart. You also need to have in your technical design document some payout examples to illustrate your compression rules.
It is OK to have a summary chart in your technical design document. It is not OK to have a chart without the other sections just discussed.
The better job you do in communicating all of your requirements to your software providers or software developers, the better job they will do in meeting them.
If you are unsure whether to include mention of something, include it! It is always better to be more detailed in your communication with a software company than to be brief.