UAT Strategy & Best Practices for SPM Implementation 

User Acceptance Training (UAT) can be a daunting time for the compensation admins during a new implementation, especially for admins who have not performed UAT before. To understand UAT, it helps to define what UAT is and really what it is not.  

What UAT is: Validation that the component build is working according to the requirements defined during the requirements gathering phase.

1. Process that is owned and executed by the Customer.
2. Time for the customer to get familiar with and drive their newly built SPM solution.
3. Prerequisite for Production Go-Live.

UAT is an opportunity for clients to test the system by using real data, real scenarios, one-off cases, etc. Just as you would take a test drive before buying a vehicle, admins need to lean into UAT and get familiar with the new SPM solution to confirm that it functions as expected.

What UAT is not:

1. Parallel testing or full reconciliation of prior results.
2. The opportunity to explore new requirements or compensation design.
3. Learning how to configure the system.
4. Testing of native functionality. 
5. Testing of entire organization/payees.
6. Testing of the full data set.

The goal of UAT is to test the new system parameters, formulas, calculations, and reports. The

system has been built based on the requirements discussed, which often includes new plan structure or elements that the prior system may or may not have accounted for. The prior system may also have had different administrative adjustments or calculations that do not align with the new system. Parallel testing, testing with an entire organization, or testing a full set of data often does not reconcile with the prior system and can lead to frustration and testing time lost.

For a successful UAT, consider using these strategies:

• Admin readiness  
  • The admins prepping and testing the system should have full knowledge of requirements and plan components captured during the requirements gathering phase. Some questions to consider are: How are the Base Commission Rates (BCRs), rates, attainment, and/or true-ups calculated? What kickers need to be considered? How is proration calculated? etc. 
  • Admins should complete formal training on the software prior to kicking off UAT. UAT is typically owned by the client, meaning that the data will be loaded, and credits and commissions are calculated by the client team. Admins will need to be able to navigate the system and validate results within the system. They should also be able to perform preliminary triage of defects so issues reach the implementation team with useful detail. The implementation team is happy to review and walk through the newly built system, but clients should have completed a formalized live or self-paced training prior to UAT start. Working on the initial training on the technology while also executing UAT extends the UAT timeline and leads to added stress.
• Simplify and start small  
  • Identify and create a subset of sample employees – CFO-VP-Mgrs-Reps-SDRs-Specialists. The sample size depends on the number of variations of roles and plans. You will want to ensure that you include 1-2 payees from each role, but you do not need 200 reps to test 3 rep plans.
  • At the beginning of testing, focus on a small number of payees and data lines, and review the more straightforward components. Newly trained admins will be getting accustomed to the software and driving the system, so they may need more time to understand the results and recognize errors in data or calculations. By starting small, testing will be much less stressful and frustrating. More data, more payees, and more difficult cases can be added over the course of UAT. 
• Thorough test case preparation  
  • Start documenting the different compensation scenarios that occur, keeping in mind each element of the commission plan that a Rep/Manager/VP could be paid on. Start high level with the basics of each type of component, then dive into product-specific kickers, exceptions, or one-off cases. Listing out all the variations of test scenarios required will assist in the next step – test cases.
  • Test cases expand on the test scenarios.  Admins should assign each test scenario to a particular payee(s), choose specific data that will apply to that test case, and then ‘do the math’ to calculate the rates, tier, and payout results that the new Sales Performance Management (SPM) solution should produce. You should be looking at this process as an individual result process by opportunity or potential payee. Remember your implementation team is available to review your test cases and provide feedback or additional examples. 
  • Identify data sets to be used in testing. There are two methods to attack the data: you can either use prior period data and build your test cases around the established data, or you can use your test cases and create dummy data unique to those. Option two allows you, as the tester, to control the data. You know exactly what data is coming into the system and that all your test cases have a line or two of data that applies specifically to the test case. This makes vetting the results more straightforward. When using prior or current data, you may be sifting through extra data, and there are often scenarios that may occur on rare occasions – which your current period’s data doesn’t include; thus, you will potentially miss testing or have to create ‘dummy’ data to accommodate.

Establish a Clear UAT Scope and Testing Plan 

Once admins are prepared and test cases are in place, a successful UAT strategy also requires a clear framework for managing the testing process. Before execution begins, define the scope, objectives, participants, responsibilities, and expected outcomes. Everyone involved should understand what is being validated, how testing will progress, and what falls outside the scope of UAT.

Teams should also establish clear entry and exit criteria. Entry criteria might include confirmation that the system is ready for testing, users have appropriate access, and required test materials are available. Exit criteria should define what must be completed before the organization can approve the solution for production. 

Scheduling is another important consideration. A successful UAT strategy needs to account for more than initial test execution. Teams should allow time to investigate issues, make necessary corrections, retest results, and complete a final review. Protecting this time helps prevent UAT from becoming compressed as production go-live approaches. 

Prioritize the Right UAT Test Scenarios

Successful UAT strategies focus testing resources where they provide the greatest value. Instead of attempting to test every payee or transaction, organizations should map important business requirements to representative scenarios and prioritize them according to compensation risk and business impact. 

Depending on the compensation plans being implemented, priority scenarios could include: 

• Commission calculations and quota attainment
• Rates, tiers, accelerators, and kickers
• Proration and true-ups
• Credits and adjustments
• Exceptions and other high-impact compensation scenarios

Teams should also consider appropriate negative scenarios. Testing what should not happen can be just as informative as confirming an expected calculation. For example, testers might verify that an accelerator does not apply until a specified attainment threshold has been reached.

Maintaining traceability between approved requirements, test cases, expected results, and completed testing gives teams a clearer picture of what has been validated and where gaps may remain. This approach provides meaningful coverage without turning UAT into an unnecessary test of the entire organization or data set.

Validate Data, Calculations, and Compensation Results

A correct final payout is important, but it does not always confirm that every step leading to that result worked as intended. Effective UAT strategies should therefore validate the relevant calculation path through the SPM solution. 

For representative transactions, testers may need to follow the process through: 

• Source data and credit assignment
• Attainment calculations
• Applicable rates or tiers
• Compensation calculations
• Final payouts and reporting

 Actual system outputs can then be compared with the expected results already established in the test cases. This allows compensation administrators to confirm that the underlying logic is functioning as expected rather than focusing only on the final number. 

When actual and expected results do not match, teams should investigate the source before assuming there is a system defect. A discrepancy may result from incoming data, an incorrect expected result, interpretation of a requirement, system configuration, or calculation logic. 

This targeted investigation helps compensation administrators and implementation teams determine where an issue originates. It also keeps UAT focused on validating defined requirements without turning the process into the full parallel reconciliation or full-data-set testing discussed earlier.

Create a Consistent UAT Defect Management Process

Identifying unexpected results is a normal part of UAT. What matters is having a consistent process for documenting, evaluating, correcting, and retesting those findings. 

A centralized defect management process gives testing and implementation teams a shared record of outstanding issues. Each reported issue should provide enough information for the appropriate team members to understand and investigate it efficiently. Useful details can include:

• The related test case
• Expected and actual results
• Relevant payee or transaction data
• Supporting screenshots or other evidence
• Potential business or compensation impact 

Preliminary triage can help determine whether the finding is a configuration defect, data issue, incorrect expectation, duplicate finding, or another type of problem. Categorizing issues according to severity also allows teams to prioritize defects that could materially affect compensation accuracy or critical functionality. 

A defined lifecycle of reporting, triage, correction, retesting, and closure keeps issues moving toward resolution while maintaining visibility into anything that remains outstanding.

Track UAT Progress and Determine Go-Live Readiness

Reaching the end of the scheduled testing period does not necessarily mean UAT is complete. One of the most important UAT strategies is establishing measurable criteria for determining whether the SPM solution is actually ready to move forward.

Teams can monitor a focused set of indicators throughout testing, including:

• Completed, passed, failed, and remaining test cases
• Open issues by severity
• Resolved defects awaiting retesting
• Completed retests
• Critical scenarios still awaiting validation 

Regular status checkpoints provide stakeholders with visibility into overall progress, risks, and remaining work. Defect triage can be handled separately so those discussions stay focused on issue severity, ownership, resolution, and retesting. 

Before final acceptance, critical compensation scenarios should have passed, and high-priority defects should either be resolved or formally addressed. Compensation administrators should also be prepared to perform the system processes and administrative responsibilities they will own after deployment.

Final UAT approval should document any accepted risks or outstanding items. This provides a clear record of the organization’s decision and helps support a more informed production go-live. 

Turn UAT Test Cases into Long-Term SPM Testing Assets 

The value of UAT does not have to end when the new SPM solution moves into production. Test cases, expected calculations, supporting data requirements, and lessons learned during implementation can become useful assets for ongoing system administration.

Organizations may be able to reuse applicable test scenarios when:

• Compensation plans or calculations change
• System configurations are updated
• New integrations are introduced
• Software upgrades are implemented
• Regression testing is required 

Retaining these materials can reduce the need to rebuild testing processes from scratch each time the SPM environment changes. Repeatable scenarios may also support future test automation where appropriate, while complex compensation situations may continue to benefit from manual validation and business judgment. Lessons learned during UAT can also strengthen future testing and ongoing SPM administration as compensation plans and system requirements evolve. 

The goal of UAT is to validate the newly built SPM solution with real sales scenarios. With preparation, simplification, and proper software training, UAT can be successful in reaching this goal and gaining confidence in the new compensation system.

Article written by: Lisa Moore