Strategies for a Successful UAT 

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’s beneficial to acknowledge what UAT is and really what it is not. 

What UAT is: Validation that 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. Similar to when test driving a vehicle or trying on shoes, during UAT the admins need to lean in 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. Also, the prior system may have had different administration adjustments or calculations that again may not align to 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 also should be able to do preliminary triage of defects to assist in UAT. 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 straight forward. 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. 

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

OpenSymmetry Favicon

Stop searching. We have your answers.