--- id: saas/comissao-ativacao-pagamento industry: SaaS and technology usage: common effort: medium grain: Sale or account x milestone; person x week or month --- # Commissions tied to activation and payment Variable pay for SDRs, closers, AMs and CS calculated on what the customer did after the sale (activated, paid, used the product), with the right owner for each period and one auditable line per item. ## Executive summary **For:** SaaS companies that pay sales and CS variable compensation on what the customer does after the sale. **What it solves** - The payout is ready in hours, with one line per sale the team can check. - Credit goes to whoever held the role at the time, not to today's owner. - The target rewards customers who activate and pay, not just signed contracts. **Why it matters:** Commission is the number the team trusts most, or least. A rule tied to activation and payment aligns sales with retention, but it only works if every line can be audited: one dispute a month costs more than the whole automation. **Business questions it answers** - How much of the W+5 activation target did each ISA hit this month? - Which September sales have not paid their first boleto (bank slip) yet? - Who was this account's AM in August, and how much MRR did they carry? - How much of the customer's revenue came after the close? - Why is my variable pay lower this month? **What you need** - CRM with owner history and billing or accounts receivable connected to Nekt - The milestones that pay variable compensation, with the source and deadline of each - A table of targets and parameters with validity dates **What you get** - A calculation base with one line per sale and milestone - Totals per person with target attainment - A feed to the commission tool or the payout spreadsheet - An AI agent that explains variable pay line by line ## Detailed ### The problem In SaaS, variable pay depends on events outside the CRM: the customer activated, paid the first boleto (bank slip), used the product. Calculating it by hand takes days and causes disputes: the deal owner changed after the sale, a canceled boleto counted as paid, the rep's name appears in three spellings and nobody knows which version of the rule applied that month. ### Business rules 1. **Every milestone has a source and an official date.** Declare the milestones that pay and the source of each: sale (deal won date), activation (product milestone or onboarding date), first payment (accounts receivable or billing), usage (consumption in the first 30 days after activation). The milestone date is the event date at the source, never the date someone moved the stage in the CRM. (Avoid: Paying activation on the 'onboarded' stage set in the CRM.) 2. **First payment is the first valid installment paid.** Discard canceled installments, sort the customer's remaining ones by due date and keep the first. It counts when it has a payment date. Second and third boletos follow the same rule for AM targets. A charge declined and then paid is a single payment. (Avoid: Taking the installment with the earliest due date, canceled ones included.) 3. **On-time activation counts from the sale week.** Real example: activation by W+5. The sale week runs Sunday to Saturday and the deadline ends on the Saturday of the fifth following week. Rate per person and sale week = sales activated on time / sales of the week, with a target (for example, 60%) and a stretch target (80%). A sale activated late shows as late, it does not disappear. (Avoid: Counting the month's activations over the month's sales.) 4. **Credit goes to whoever held the role at the date.** The sale's SDR or ISA is the deal owner on the won date. The AM of an account in a past month is the owner valid on the cutoff day (for example, the 5th); the current month uses the current owner. Read from owner history, never from today's owner. An account enters an AM's book only if it was active on the reference date. (Avoid: Calculating the past with the deal's current owner.) 5. **A person is an id, not a name.** Use the CRM user id and a people table with mapped spellings and nicknames, team, role, start and end date. Never join on a name typed in a free field or a spreadsheet. (Avoid: Normalizing names with a CASE scattered across queries.) 6. **Post-sale revenue in fixed windows.** When variable pay depends on the revenue the customer generates on the platform (transaction volume, platform revenue), measure it in 30-day cycles from the close (cycle 1, 2 and 3) and compare with the 30 days before the close. Real result = cycle 1 minus the previous 30 days, so you do not pay for revenue that already existed. (Avoid: Paying on all of the customer's revenue in the month of the sale.) 7. **Targets and rules have validity dates.** Targets per person and period and parameters (percentages, bands, deadlines) live in a table with start and end validity, not in code. A month's payout uses the version valid that month. A day-prorated target (monthly target x elapsed days / days in the month) is for tracking, never for paying. (Avoid: Changing the percentage in code and recalculating past months.) 8. **Tests, internal accounts and manual adjustments kept apart.** Test deals, internal and duplicate accounts are excluded through a list with a reason, not ids written in code. Manual MRR or credit adjustments go into a table with author, date and reason, added to the payout and visible on the person's statement. (Avoid: Test ids and adjustments written inside the SQL.) 9. **One auditable line per item.** The calculation base has one line per sale (or account) and milestone, with person, dates, status (on time, late, pending, canceled) and the unique key (for example, week plus deal id) the commission tool uses to update without duplicating. The person's total is the sum of those lines, and they can check them one by one. (Avoid: Sending only the total per person to the commission tool.) 10. **A paid month is frozen.** After payout, the month is stored and not recalculated. A payment or activation that arrives later goes in as an adjustment in the month it was found, with the original month recorded. A cancellation after payout follows the declared clawback rule, without rewriting the past. (Avoid: Recalculating the paid month when a late boleto arrives.) ### Milestones that usually pay variable compensation Role, milestone and the source that proves it. - **SDR / ISA** → Won sale (`deal won date`) - **ISA** → On-time activation (`milestone by the Saturday of W+5`) - **ISA / AM** → First boleto paid (`1st non-canceled installment with a payment date`) - **AM** → Second and third boletos paid - **Onboarding** → Consumption in the 30 days after activation - **Platform closer** → Revenue in the 30, 60 and 90-day cycles (`cycle 1 - prior 30 days`) - **CS** → Account value indicators above target - **AM** → Book MRR on the cutoff day ### Definitions | Metric | Definition | |---|---| | Sale | won deal, not on the test list, with a won date in the period, credited to the owner on the won date | | Sale week | Sunday to Saturday containing the won date | | On-time activation (W+5) | activation milestone dated by the Saturday of the fifth week after the sale week | | On-time activation rate | sales of the week activated on time / sales of the week, per person | | First payment | the customer's first installment by due date, excluding canceled ones, with a payment date | | Owner of the month | owner valid on the month's cutoff day (closed months) or the current owner (current month) | | Real result | customer revenue in the 30 days after the close minus revenue in the previous 30 days | | Attainment | actual / the person's valid target for the period | ### Pitfalls - **Today's owner got paid for the past.** Transferred accounts had earlier months' books recalculated with the current owner, and the former AM lost credit. How to avoid: Owner valid on the cutoff day, read from history. - **A rep with three names.** The same rep appeared with a nickname, full name and a misspelling, fixed by a CASE copied across several queries. How to avoid: People table with id and nicknames. - **A canceled boleto as the first.** The first installment by due date could be a canceled and replaced one, and the sale showed as unpaid. How to avoid: Exclude canceled installments before sorting. - **Double activation.** The same account had more than one onboarding record and generated two activations. How to avoid: Deduplicate by the account's first onboarding date. - **A test deal in the payout.** Test deals were hard-coded ids in the SQL; a new test made it into the payout. How to avoid: Exclusion list with a reason, reviewed at every payout. - **Lines without a key in the tool.** Lines without a unique key reached the commission tool and were stored twice. How to avoid: Week plus deal key required; a line without a key is not sent. ### Acceptance test - [ ] For each person and month, the total payout is the sum of the base's lines, and every line has a source and a milestone date. - [ ] Changing a deal's current owner does not change the payout of any closed month. - [ ] No canceled installment counts as a first payment. - [ ] A week's on-time activation rate, redone by hand for 3 people, matches the base. - [ ] Every line sent to the commission tool has a unique key, with no repeated key. ### Context document ```text Commissions tied to activation and payment - Variable pay is calculated from the calculation base: one line per sale or account and milestone, with person, milestone date and status. Totals are the sum of those lines. - A sale is credited to the deal owner on the won date. AM of a closed month = owner valid on day . Never use the current owner for the past. - On-time activation: milestone by the Saturday of the fifth week after the sale week (Sunday to Saturday). Target %, stretch target %. - First payment = first non-canceled installment, by due date, with a payment date. - Targets and parameters come from the rules table valid for the period being calculated. - A paid month is frozen. Late items go in as adjustments in the month they were found. - When explaining variable pay, show the lines that make up the total and the status of each. Client exceptions: - : the activation milestone for product is . - : the onboarding team is paid on consumption in the 30 days after activation. ``` ### Variations - **CS indicators:** An account counts for the CSM when three value indicators (for example, features used, failures identified and savings logged) are above target in the month. - **Platform revenue:** For transactional platforms, the closer is paid on platform revenue in the 30-day cycles after the close. - **Company targets:** Monthly MRR, NPS, churn and delinquency targets in the same table with validity dates, tied to OKRs.