Who are the best Varicent implementation partners?

Judge any Varicent partner, Lanshore included, on four things: whether their consultants design the data model before they build it, whether build documentation is a deliverable rather than an afterthought, how they handle retroactive adjustments and restatements, and whether they will run a reconciled parallel run before cutover. Lanshore does all four, has delivered incentive compensation for 15+ years, and resells no SPM platform, so it recommends Varicent only where it fits. Ask every candidate for the design document from a past build and for the name of the person who will be on your project.

Is Lanshore a certified Varicent partner?

Lanshore implements and operates Varicent and resells it no more than it resells the other eight platforms it works on, so the recommendation to use it is based on fit. This page makes no claim about a partner tier or certification; what it describes is how the work is done: documented model design, migrations from legacy ICM and spreadsheets, validated integrations, parallel runs before cutover, and managed operations after go-live. Ask us directly about current partner status and about the consultants who would staff your project.

How long does a Varicent implementation take?

It is driven by plan complexity, data readiness, and the number of plan populations, not by the platform. A mid-market plan set of 3 to 6 plans and up to about 1,000 payees migrating from spreadsheets typically runs 10 to 14 weeks from kickoff to cutover, including one parallel-run cycle. Enterprise programs with many plans, overlays, and retroactive mechanics run 6 to 12 months.

Can Lanshore migrate us to Varicent from Xactly, SAP Commissions, or spreadsheets?

Yes. The work is the same in each case: reverse-engineer the existing logic, separate policy from accumulated error, design the Varicent model, migrate history and open balances, and reconcile parallel runs before cutover. Lanshore's SPM Operations demo includes an agent-assisted Xactly-to-Varicent migration mode that mirrors the engagement pattern.

What skills does our team need to administer Varicent after go-live?

Someone who is comfortable thinking in tables, joins, filters, and effective dates, because Varicent plan logic is built through SQL-based linking rather than fixed forms. With a documented model, that person can run cycles and make plan changes safely. Without one, every change becomes a guess. Lanshore delivers the documentation and trains your administrator on it, or runs the platform for you.

Can Lanshore take over a Varicent build that is in trouble?

Yes. Rescue starts with an honest assessment of the existing model, a written path to a reconciled parallel run, and a decision on what to keep and what to rebuild. Lanshore has rebuilt crediting and calculation logic on a commission process that had run on manual overrides for over a year and restored a controlled monthly cycle.

Solutions

Varicent Implementation Services for Enterprise Teams

Lanshore is a Varicent implementation partner for enterprise comp teams: it designs and builds complex plans on Varicent, migrates plan logic and history onto it from legacy ICM systems and spreadsheets, integrates it with CRM, ERP, HR, and payroll, rescues builds that have stalled, and runs the platform afterward as a managed service. Lanshore has delivered incentive compensation for 15+ years from the US and Latin America, implements nine SPM platforms, and resells none of them, so the recommendation to build on Varicent is made on fit.

Who it is for

Compensation, RevOps, finance, and IT leaders at mid-market and enterprise companies that have selected Varicent or are weighing it against other platforms, and whose plans involve the mechanics that make Varicent worth its data model: multi-level crediting, overlays and splits, retroactive quota and territory changes, draws and clawbacks, multiple plan populations, and high transaction volumes. It also fits teams whose Varicent build was delivered by someone else and no longer matches the plan, and teams that inherited a Varicent instance nobody on staff can read.

The problems it solves

An open data model that will model anything, including mistakes

In Doug Erb's view, Varicent's strength is that it is an open data model: tables, calculations, and SQL-based linking, with no fixed object hierarchy forcing the plan into a vendor's shape. Anything in a plan document can be modeled. The same openness is why builds go wrong. Two builders will model the same plan two different ways, a calculation chain can depend on a table nobody documented, and a rule that looks right in a demo can be wrong for an edge case that was never loaded. Varicent rewards disciplined design and punishes improvisation.

Admins who cannot read the logic they inherited

Because Varicent is built with SQL-minded linking between tables, administering it well takes someone who thinks in joins, filters, and effective dates, not someone who expects a form to fill in. When an implementation partner leaves and hands over a model with no build documentation, the in-house admin can run the cycle but cannot change the plan with confidence. Every mid-year SPIF or territory change then becomes a ticket to an outside firm, or a manual adjustment outside the model.

Retroactive adjustments and restatements

The hard part of any commission build, on Varicent or anything else, is what happens when the past changes: a quota corrected after payout, a territory move backdated two months, a deal re-credited after a dispute, a clawback on a cancelled contract. The model has to recompute prior periods, work out the difference against what was already paid, and present the restatement to the rep and to finance in a form both can reconcile. Builds that treat this as a later enhancement end up with a spreadsheet of manual true-ups beside the platform.

Spreadsheet logic that nobody has ever written down

Teams moving onto Varicent from spreadsheets or a legacy ICM system usually find that the real plan lives in formulas, lookup tabs, and one analyst's habits rather than in the plan document. Migrating that logic means first reverse-engineering it, deciding which quirks are policy and which are errors, and getting comp, sales, and finance to sign off on the answer before anything is built. Skipping that step moves the ambiguity onto a new platform.

Integration treated as a file drop

Varicent calculates from whatever it is given. If the CRM extract arrives with missing close dates, duplicate opportunity records, or a hierarchy that does not match the HR roster, the calculation is wrong before any rule runs. Implementations that stop at a scheduled file import, with no validation step and no reconciliation of the outbound payroll file back to the calculation, produce errors that reps find first.

A build that stalled before go-live

Some Varicent projects arrive at Lanshore in trouble: the partner has rotated staff, parallel runs do not reconcile, the comp team has stopped trusting the numbers, and the go-live date has already moved twice. Rescue needs a frank assessment of what in the model is sound and what has to be rebuilt, then a short path to a reconciled parallel run, rather than another round of patching.

How Lanshore delivers it

1
Plan design review and requirements
We read every plan document, SPIF, and policy in force and resolve ambiguities in writing before build, with comp, sales, and finance signing off. Each plan component is written as a testable requirement with its data source, crediting rule, effective-dating rule, and expected treatment of retroactive changes. Where the plan design should change, we propose options and model their cost before configuration.
2
Model design before model build
On Varicent we design the data model on paper first: the tables, their keys and effective dates, the calculation chain, and the points where adjustments and restatements enter. The design states how each retroactive case is handled, which prior periods recalculate, and how the true-up is presented. This is the document the in-house admin will read for years, so it is written for them, not for the project team.
3
Build with documentation as a deliverable
Our consultants build the crediting, hierarchies, calculations, adjustments, statements, and reports from the agreed design, and the build documentation is updated as the model changes rather than written afterward. Every calculation step is named for what it does and traced back to a requirement. The result is a model a SQL-minded administrator can read and change without guessing what the previous builder intended.
4
Migration from legacy ICM or spreadsheets
We reverse-engineer the existing logic, separate policy from accumulated error, and migrate plan logic, history, open balances, and year-to-date attainment onto Varicent. For a mid-market plan set (3 to 6 plans, up to about 1,000 payees), a Lanshore spreadsheet-to-platform migration typically runs 10 to 14 weeks from kickoff to cutover, including one parallel-run cycle. Enterprise migrations from legacy ICM systems run longer, driven by plan complexity rather than by the platform.
5
Integration with validation on both ends
We connect Varicent to the CRM, ERP, HR, and payroll systems, validate every inbound load before calculation, and reconcile every outbound payroll and finance file back to the calculation run. Lanshore has integrated SPM platforms with Salesforce, HubSpot, Microsoft Dynamics, SAP, Oracle, Workday, NetSuite, and ADP, plus billing, order management, and data warehouse sources: more than 20 distinct source systems in all.
6
Testing, parallel runs, and reconciled cutover
Each rule is tested against expected results, with edge cases for mid-period transfers, splits, clawbacks, and backdated changes. Then full periods run in parallel with the existing process and every variance is traced to a cause. Cutover happens when the variances are explained. For a rescue engagement, this is the first milestone: a reconciled parallel run that gives the comp team a reason to trust the model again.
7
Rescue of a troubled build
When a Varicent build has stalled, we assess the model as it stands, separate what is sound from what must be rebuilt, and put the fastest credible path to a reconciled parallel run in writing, with the trade-offs stated. Lanshore has redesigned a broken commission process from the plan document down, removed a manual override layer, and re-established a controlled monthly cycle. Rebuilding everything is recommended only when the existing model cannot be made readable and correct.
8
Hypercare and managed support
The team that built the model supports the first live cycles while your administrators take over, with training on the model design and documentation. Afterward, you can run Varicent yourselves, or Lanshore runs the monthly cycle as a managed service for a predictable monthly fee, with agents handling data loads, validations, calculation runs, and exception queues, every action logged, and a person approving anything that affects pay. Lanshore publishes no support SLA or coverage hours; the operating calendar is agreed per client.

Get an assessment

Platforms we deliver on

Varicent

Related case studies

When the pressure gets too much for a manual spreadsheet system
Variable pay administration moved off Excel onto a governed platform
Architecture redesign to fix a broken compensation process
Commission process broken for over a year, restored to systematic accuracy
Reacting to changing business needs for variable compensation
Third-party dependency for every plan change replaced with a flexible model
Tackling resource challenges with expert advice and managed services
Error-prone manual Excel commission process replaced with managed operations