Implementation (ICM)

What is ICM implementation?

Implementation is the initial engagement that configures an incentive compensation management system before it goes live. It covers connecting the CRM and finance systems, building the comp plans into the tool, migrating enough history to be useful, validating the output against results you already trust, and getting the first live run out of the door.

It is a project. It has a scope, a timeline, and an end. That last property is what separates it from everything around it, and it is also what gets lost, because implementation is usually bundled into a platform fee and discussed as though it were a single indivisible thing.

What implementation is not is the ongoing work of adding a new rep, a new plan, or a new entity after you are live. That is onboarding, and it never ends. The distinction is covered in implementation vs onboarding, and it is worth reading before you sign anything, because the boundary between them is the boundary of what you are paying for.

The five phases

PhaseWhat happensWho owns it1. DiscoveryDocument the plans as they actually work, including the exceptions nobody wrote down.You, with the vendor2. Data connectionConnect the CRM, finance system, and payroll. Map the fields the plans depend on.Vendor, with your CRM admin3. Plan buildConfigure plans, rate tables, components, crediting rules, and approval flows.Vendor4. ValidationRecalculate a period you already closed and compare it to what you actually paid.You and the vendor together5. Go-liveRun the first live period in the new system, usually in parallel with the old one.You

Phase four is the one that decides whether the project succeeded, and it is the one most often rushed. If the new system reproduces a quarter you already closed, to the cent, you can trust it. If it does not, the discrepancy is telling you something important about a plan rule nobody documented, and that is far better discovered in validation than in a live payout.

How long does ICM implementation take?

This is the question prospects ask most often, and the honest answer is that it depends almost entirely on one variable: how complicated your plans are, and how well you can describe them.

SituationWhat drives the timeSmall team, few plans, clean CRMFast. The work is mostly connection and validation.Many plans, or one plan with many exceptionsSlower. Every undocumented exception is discovered rather than configured.Messy or incomplete CRM dataSlower, and the fix is upstream. No commission tool can calculate from fields that are not populated.Historical data migration requiredAdds a distinct workstream that is frequently underestimated.Plans that nobody can fully articulateSlowest. Discovery becomes plan design, which is a different project.

The strongest predictor is plan complexity. As one reviewer put it after a migration, the simpler the plan, the easier it is to set up and maintain. That is not a platitude. Complexity in the plan converts directly into time in the build, and it keeps converting, every year, in maintenance.

What this means?

For Finance, the two costs most often left out of the model are historical data migration and change management. Neither is on the invoice, and both are real. Enterprise reviewers of ICM tools warn specifically about the change management cost that arrives with the transition, and about historical data that did not come across, leaving gaps in year-over-year reporting. Budget for both. See change management.

For RevOps, discovery is where the project is won or lost. The plans as written and the plans as actually paid are rarely the same document, and every undocumented exception you surface in week one is a week you do not lose in month three. Bring the spreadsheet with the manual overrides in it. That file is the real plan.

How Visdum approaches implementation

Visdum runs implementation as a defined engagement rather than an open-ended configuration exercise: connect the data sources, build the plans as they actually operate including the exceptions, migrate the history you need, and validate by recalculating a period you have already closed so the numbers can be checked against something real before anyone depends on them.

Because plans are configured rather than coded, the components that make a plan complicated, such as tiers, accelerators, splits, and clawbacks, are set up as building blocks rather than as bespoke logic. That is what keeps a complex plan from becoming a long project, and, more importantly, what stops every subsequent plan change from becoming a small implementation of its own. Where implementation ends and onboarding begins is stated up front, so the scope line is a written boundary rather than a conversation you have later.

Take a self-guided product tour to see this in action, or read the Salesforce implementation guide.

Related terms

Implementation vs Onboarding · Onboarding (Sales Comp) · Change Management · ICM · Data Exception