Spiff Implementation Checklist: What to Do Before You Start
Most Spiff implementations that go wrong don't fail during the build — they fail before it even starts. Missing CRM data, undefined comp policy, unclear ownership: these are the things that cause delays, disputes, and rework. This checklist covers the 10 things you need to have in order before your implementation begins.
Before a single plan gets built in Spiff, there's groundwork that has to happen on your side. In my experience leading implementations — including the full rebuild for Storyblok — the projects that go smoothly are the ones where this groundwork was done upfront. The ones that struggle are almost always missing something from this list.
Each item below is rated by how critical it is to have ready before kickoff.
A single, agreed compensation policy document
Your commission plans need to be fully defined in writing before anyone builds them in Spiff. That means: quota structures, attainment thresholds, accelerator rates, clawback terms, payment timing, and how edge cases are handled. If this document doesn't exist — or if multiple versions are floating around — you'll be designing the comp plan during the implementation, which doubles the timeline and guarantees rework.
Why it matters: Spiff builds what you tell it to build. If the source of truth is unclear, the output will be wrong. Get Finance, RevOps, and Sales leadership aligned on a single document before kickoff.
Clean, consistent CRM data
Spiff calculates commissions based on data it pulls from your CRM — typically Salesforce or HubSpot. If that data is messy, the commissions will be wrong. Before implementation, audit the key fields Spiff will use: close date, deal value, currency, rep ownership, product type, contract length. Look for duplicates, nulls, and inconsistencies. Fix them before kickoff, not after.
Why it matters: A plan that looks correct in Spiff can produce wrong outputs if the underlying CRM data is unreliable. Bad data is the single most common cause of rep disputes after go-live.
A named RevOps or Finance owner for the project
Someone on your team needs to own this implementation — attending weekly calls, reviewing plan logic, signing off on testing, and making decisions when questions arise. This person needs enough authority to confirm comp policy details and enough CRM knowledge to help with field mapping. Without a clear internal owner, decisions stall and timelines slip.
Why it matters: Implementations without a named internal owner average 2–3 weeks longer than those with one, in my experience. This is the single most underrated prerequisite.
CRM admin access confirmed
Your Spiff implementation will require read access to specific CRM objects and fields — at minimum opportunities, users, and products. Before kickoff, confirm that either your Spiff consultant or a designated CRM admin can review field-level data, create connected app credentials, and configure the integration. Waiting for IT or security approval after kickoff is one of the most common sources of delay.
Why it matters: Integration setup is usually week one or two of the project. If access isn't ready, the whole timeline shifts right.
A list of all roles and plan types
Map out every quota-carrying role in your sales org and which commission plan applies to each. Account Executives, SDRs, Solution Engineers, Customer Success Managers, Sales Managers — each may have a different plan structure. Include headcount per role. This list drives the scope of the implementation and directly affects the timeline and cost.
Why it matters: Discovering mid-implementation that there are two additional plan types not discussed in scoping is extremely common and always causes delays.
Documented edge cases
Think through every exception to the standard plan rules: What happens when a rep joins mid-quarter? How are split deals handled when two reps work the same account? What triggers a clawback — churn within 30 days, 60, 90? How are multi-year deals recognised — full value upfront or annual instalments? Write these down. Every edge case that isn't defined upfront will surface as a dispute after go-live.
Why it matters: Edge cases are where most commission disputes come from. Defining them in advance means they get built into the plan logic from the start rather than patched in later.
12 months of historical deal data available
Before go-live, your commission plans need to be tested against real data — not toy examples. Having 12 months of closed won deals available (either in the CRM or as a clean export) allows you to run the new plan logic against known outcomes, compare results to what was actually paid, and surface any discrepancies before reps see their first statement.
Why it matters: Plans that pass sandbox testing but haven't been validated against real historical data regularly produce surprises in the first live cycle. This is the most reliable way to build rep confidence from day one.
Currency and territory structure defined
If your sales team operates across multiple regions, define upfront: which currencies are in scope, how exchange rates are applied (fixed monthly rate, live rate, or contract rate), and whether reps are paid in their local currency or a base currency. For Storyblok, this meant getting clarity on 8 currencies before a single plan was built — that clarity is what made the multi-currency configuration clean rather than patched.
Why it matters: Multi-currency configuration is foundational infrastructure in Spiff. Getting it wrong early means fixing it while reps are already live — which creates distrust.
Finance sign-off on the implementation plan
Finance will own the post-launch process — approving statements, managing adjustments, handling queries. Get them involved before kickoff, not after. They often catch comp policy ambiguities that RevOps misses, and their buy-in means faster approvals during testing and a smoother handover at go-live.
Why it matters: Implementations where Finance is brought in late almost always require a second round of changes after go-live, when they see the outputs and raise issues that could have been addressed at the design stage.
A rep communication plan ready
Think about how you'll introduce Spiff to your sales team before go-live. Reps who understand why they're moving to Spiff — and what it means for them — adopt it faster and raise fewer queries. A short internal comms plan covering what's changing, when it's happening, and how to access their statements reduces the support burden on RevOps in the first month after launch.
Why it matters: Rep adoption is the measure of a successful implementation. The best-configured Spiff instance still fails if reps don't trust or use it.
The Most Common Missing Item
If you only do one thing from this list before your implementation starts, make it item one: get your compensation policy into a single, agreed document. In my experience, this is missing or incomplete in the majority of projects that run into trouble. The conversation that happens when you try to write down exactly how your plans work — including all the exceptions — is exactly the conversation you need to have before anyone opens Spiff.
A note on "we'll figure it out as we go": It's tempting to start the implementation and resolve ambiguities along the way. This works for minor details but not for structural questions like how accelerators are calculated, what triggers a clawback, or how split deals are attributed. These decisions affect plan architecture. Changing them mid-build means rebuilding — and if they're changed post-launch, it means explaining to reps why their statements are different from last month.
How Long Does Prep Take?
For a team that's reasonably organised, working through this checklist takes one to two weeks. The bottleneck is almost always the compensation policy document — getting Finance, RevOps, and Sales leadership aligned on the same version of the truth takes time, especially if there are disagreements about edge cases.
For teams where the comp policy is already well-documented and the CRM is clean, prep can be as short as a few days. The Storyblok implementation moved quickly in part because the internal team came to kickoff with clear answers to most of these questions — which meant we could move straight into building.
Ready to start your implementation? If you've worked through this checklist and want to talk through what a scoped Spiff implementation looks like for your team, book a free 30-minute discovery call. No pitch — just a direct conversation about what you're trying to solve.
Want a second pair of eyes on your prep?
Book a free call and I'll tell you whether you're ready to start — and what to fix if you're not.
Book a Free Discovery Call