Who to hire for Spiff commissions on Salesforce

A commission error is not an ordinary defect. When a report is wrong, someone corrects it. When a payout is wrong, a person is paid too little, or the company is paid back later, and either way trust takes months to repair. That single fact should shape how you hire for Spiff. The partner you need is the one who is nervous about the first payout, not the one who is excited by the first demo.

Context first. Salesforce completed its acquisition of Spiff on February 1, 2024. Salesforce now presents the product as part of its sales offering and describes the category plainly: "Incentive compensation management software automates the calculation of sales incentives using data from sources such as CRM systems and sales performance data." The page is on Salesforce's incentive compensation management site. Those words are worth holding on to, because they locate where project risk lives: in the data feeding the calculation and in the rules applied to it.

#Start with the plan document, not the tool

Every compensation project worth trusting begins with a single artefact: a plan document written in plain language, covering who is eligible, what is paid on, when it is earned, how credit is split, how quotas are set, and what happens with exceptions such as cancellations, clawbacks and mid-period role changes. Rules in software are only as good as that document.

Ask each bidder how they handle a plan document that does not exist. Many organisations discover during discovery that the real plan lives partly in a PDF, partly in spreadsheet formulas and partly in the memory of a sales operations manager. A good partner will treat reconciling those into one document as the first milestone, and will not begin configuration until sales leadership and finance have both signed it. A weaker one will start building from the spreadsheet and inherit its undocumented quirks.

#Who you need in the room

Three roles matter. The compensation designer or analyst understands plan mechanics and can challenge a rule that sounds simple but produces odd results at the edges. The Salesforce data specialist knows how opportunities, products, accounts, teams and ownership are stored in your org and how they change. The payroll or finance liaison understands the hand-off, approvals and the calendar.

The relevant Salesforce credentials are Salesforce Certified Platform Administrator, for anyone who must read ownership and sharing; Salesforce Certified Agentforce Sales Consultant, which is the current name of the credential formerly known as Sales Cloud Consultant; and Salesforce Certified Revenue Management Consultant, where quotes, orders and contracts feed the calculation. They are listed on Trailhead's credentials pages. None of these proves compensation expertise, so also ask for plan types the team has actually configured, such as tiered accelerators, team splits, overlay roles or multi-year deals.

#The data underneath the plan

Most calculation problems turn out to be data problems. Credit follows ownership, so if opportunity owners change after close, or account teams are maintained informally, payouts will move in ways nobody expects. Product hierarchies, currencies, discounts and renewal flags all influence what counts.

Ask the partner for a data readiness review before configuration. It should list each attribute the plan needs, where it lives, how often it changes, how complete it is and who owns it. The review will probably surface gaps, such as missing close dates on historical deals or opportunities without a primary contact. The cheaper fix is usually in Sales Cloud, before data reaches the calculation. A partner who proposes to patch around poor data with ever more rules is building something you will struggle to audit.

#A first engagement: one plan, one team, one parallel cycle

Do not begin with the whole sales organisation. Choose one plan and one team that is representative but not your most complex, and agree a pilot of roughly eight to twelve weeks. The deliverable is a parallel cycle: the new system calculates payouts for the pilot team while the existing method continues to pay, and a named analyst reconciles the two line by line.

Salesforce's product page lists capabilities that are useful in a pilot, among them rep statements, in-app comments and an audit log. The audit feature is described as: "Quickly adjust plans across or within teams, with every change tracked in an audit log." Treat that as something to test rather than assume. Ask the partner to change a rule mid-pilot and show who changed it, when, and what it did to the numbers.

Success criteria should be written in advance. For example: every difference between old and new calculations is explained and classified as either an error in the old method, an error in the new rules or a data issue; reps can see and understand their own statements; and finance has approved the process for closing a period.

#What goes wrong when it is run like a generic CRM project

The first failure is treating go-live as a date. In most projects, a go-live that slips by a week is an inconvenience. In compensation, it can mean a period closes with two methods in force. Anchor the plan to the pay calendar, and have the partner state which dates are immovable.

The second is skipping communication. Reps read statements to check their own pay. If the new statement shows different numbers, or uses new terms, without explanation, you will spend the following quarter answering disputes. Ask the partner to prepare communications and a dispute process, not just configuration.

The third is optimising for the sales leader alone. A leader may want faster plan changes, which is a fair goal. But finance needs controls and an audit trail, and sales operations needs a manageable change process. A partner who cannot describe how a plan change is requested, approved, tested and released has only solved one third of the problem.

#Payroll hand-off and period close

The step after calculation is where many projects quietly stall. Someone has to approve the numbers, someone has to release them to payroll, and someone has to be able to explain a late correction. Ask the partner to draw the close calendar as a timeline from the last deal booked to the pay run, naming the person who acts at each point and what happens if they are away.

Then ask about the file or integration that reaches payroll. What format does the payroll system expect? How are adjustments for earlier periods represented? What is the control that stops a payment being released twice, or released before approval? A partner with real experience will answer from the payroll side, not just the Salesforce side. If your payroll provider is separate from your finance team, ask for the partner to meet that provider early, since constraints on file formats and cut-off times tend to appear at the end of a project, when they are most expensive to accommodate.

#A test any bidder should pass

Give each shortlisted firm the same small scenario on paper. A rep closes a deal in March, the customer cancels in June, the rep moves to a different team in May, and the plan has a quarterly accelerator. Ask the firm to explain, without software, what the payout looks like in each quarter and what the plan document would need to say to settle it.

The scenario is deliberately ordinary. A firm that has done compensation work will ask clarifying questions about clawback windows and credit at the date of close, and will notice that the plan document is silent on one point. A firm that has not will skip to describing configuration screens. The questions they ask matter more than the answer they produce, and you can compare firms on a like-for-like basis without paying for a trial.

#Plan changes after go-live

Compensation plans change every year, and often mid-year when territories or products move. The ease of that change is a large part of the value, so ask how the partner will leave you able to make it. A sound approach separates who proposes a change, who approves it, who tests it and who releases it, and records each step. It also includes a test set of historical deals that the team can re-run after every change, so that an edit to one rule does not silently alter the payouts of another.

Ask the partner to show how a rule change would be tested against last quarter's data and how the difference would be presented to finance. If the answer relies on one person's memory, you are buying a dependency rather than a capability.

#Ten questions for the shortlist

1. Which plan types have you configured, and which was hardest?
2. What do you do when the plan document does not match the spreadsheet?
3. How do you test edge cases such as clawbacks, mid-period transfers and split credit?
4. What data do you require from Salesforce, and what do you do when it is incomplete?
5. How do you structure a parallel run, and who signs it off?
6. How does a plan change get requested, approved and released?
7. How do payouts reach payroll, and what controls sit in that hand-off?
8. How will reps be told what changed, and how do they raise a dispute?
9. What would you leave out of the first release?
10. What will our team be able to do unaided at handover?

A strong answer to the third question names specific cases and describes the test evidence. A weak one says that the system handles edge cases. Systems handle what rules tell them to do, and edge cases are exactly where rules are missing.

#References and evidence

Ask for references from the compensation owner, not the project sponsor. Compensation owners know how many disputes arose, how long period close took before and after, and whether plan changes became easier. Ask the partner what they refused to configure, and why.

Ask for artefacts too: an anonymised plan document, a data readiness review, a parallel run reconciliation and a test script for edge cases. A firm that has done this work well will have these in reusable form. Logos are not evidence, because a logo cannot tell you whether anyone was paid wrongly in the first quarter.

#Commercial models and the statement of work

A fixed-fee discovery that produces the plan document and data review is a sensible first purchase. The pilot suits a fixed price once the plan is agreed, with a clear change process for new rules. The wider rollout can be priced per plan or per team, because each is a countable unit.

Be clear about who provides data extracts, test accounts and access, because delays there compress the parallel run, and the parallel run is the part you must not shorten. Salesforce describes setup of plans as quick, but your own timeline depends mainly on how quickly the plan is agreed.

#When you can skip a partner

A small team with one simple plan, clean Sales Cloud data and a sales operations person who already understands the calculation may manage alone, particularly if the configuration is done in days and verified by hand against a spreadsheet for a cycle or two. The test is whether you can write the plan in one page and explain every payout to a rep.

Bring a partner in when plans are layered, when credit is split across teams, when data quality is uncertain, or when payroll integration is needed. Background questions are covered in integrating Spiff with Salesforce, should I migrate from Spiff and what happened to Spiff.