How to Run UAT in a SaaS Implementation (2026 Playbook)

Run user acceptance testing (UAT) in a SaaS implementation as its own phase, with a fixed window, scenarios written around the customer's real workflows, named testers who have been given protected time, one shared issue log, and exit criteria agreed before testing starts. For a typical mid-market implementation, plan two weeks of dedicated testing plus one week for fixes and retests. UAT is the last point where a misconfiguration is cheap to fix and the customer still has your full attention, so it deserves more structure than most onboarding plans give it.

Below is the playbook we recommend for implementation and onboarding managers: what UAT covers in a configured SaaS product, when to schedule it, how long it takes, how to write scenarios the customer will actually run, how to triage what they find, and what "passed" has to mean before you commit to a go-live date.

What is UAT in a SaaS implementation, and who owns it?

UAT is the customer confirming that the product, as you configured it for them, supports their business processes end to end. It sits after your own internal testing and before go-live. Panorama Consulting describes the purpose plainly: earlier test stages prove the system works technically, while UAT proves that the people who will use it every day can do their jobs in it.

In a SaaS implementation, that means testing four things: the configuration (roles, permissions, workflows, templates, notifications), the migrated data (do last quarter's records look right, do totals reconcile), the integrations (does a record created in the CRM arrive in the new system with the right fields), and the day-to-day processes those pieces have to support together.

Ownership is split, and the split should be explicit. Panorama's guidance is that implementers own the test materials, the support during testing, and clear guidance on what feedback they need, while the customer's project lead owns freeing up testers, participating, and returning findings. The single most common UAT failure is a customer who assumes the vendor is "doing the testing" and a vendor who assumes the customer is.

When should UAT happen in the onboarding timeline?

UAT belongs after configuration and data migration are complete, after your team has run its own end-to-end check, and before end-user training. Rocketlane's co-founder Srikrishnan Ganesan recommends making UAT a separate phase in the implementation plan, with its own activities, rather than folding it into "training" or "go-live prep" where it gets squeezed.

The squeeze is the risk to plan for. Panorama lists project phase extensions as the first UAT risk to mitigate: when configuration or migration runs long, teams take the time out of testing to protect the go-live date, and the project then fails as low adoption after launch. If UAT is a named milestone with a start date the customer's executive sponsor has seen, it is much harder to quietly delete.

Two scheduling rules that hold up in practice:

• Do not start UAT until the migrated data is in the test environment. Testing configuration against sample data tells the customer very little about whether their own records work.
• Book the testers' time at kickoff, not the week before. If UAT is on the kickoff agenda as a dated commitment with named people, it survives the inevitable calendar pressure later.

How long should UAT take?

Plan two weeks of dedicated testing plus at least one week for fixes and retests for a typical mid-market implementation, and scale from there. That guidance comes from Educe Group, which implements enterprise learning platforms: two weeks of dedicated testing, one additional week for re-testing resolved issues, and the emphasis on "dedicated" because scenarios run in stolen half-hours produce late, incomplete findings.

Treat these as planning defaults and adjust for the number of user groups and integrations. The variable that stretches UAT most is rarely product complexity. It is tester availability. If the customer can only give you two people for two hours a day, a "two-week" UAT is really 40 person-hours, and you should size the scenario list to that budget rather than pretend the calendar will stretch.

How do you write UAT scenarios the customer will actually run?

Write scenarios as the customer's real processes with their real data, give each one a clear expected result, and hand them over as a checklist the customer can run without you in the room. Rocketlane's recommendation is to provide example documents and lists of test cases, plus individual checklists for each dimension of the implementation (account configuration, user setup, data migration, integrations), because your guidance keeps the customer from missing key areas and lowers the effort they have to put in.

The most useful scenario set is built from what the customer told you during discovery and on the kickoff call. If a process owner said "every Monday I pull the overdue list and reassign anything older than 30 days," that sentence is a UAT scenario. Implementation teams that capture these commitments from call transcripts and Slack threads as they happen have most of the scenario list written before configuration ends. Stipulate does this by extracting processes, requirements and decisions from call transcripts and customer channels, which gives the implementation manager a running list of "this is how they work" statements to turn into test cases.

Each scenario needs six fields:

Aim for 15 to 40 scenarios for a mid-market implementation. Cover every integration at least once in each direction, every role at least once, and every report the customer said they run weekly or monthly. Include the ugly cases the customer mentioned: the record with three addresses, the month-end close, the user who belongs to two teams.

Who should test on the customer side?

Ask for two to five testers who actually do the work, who have protected time, and who are open to a new way of working. Rocketlane advises customers to pick team members who are "open to change and curious," because testers who are attached to the old process turn UAT into a debate about how the product works versus how they used to do things.

Protected time is the part that gets skipped. AWH, a services firm that runs client UAT constantly, describes the pattern: clients assign UAT to people who already have full-time roles, so it gets deprioritized, done last minute or after hours, and comes back incomplete. Their fix is to dedicate testers' time and, for large releases, to clear the testers' regular duties for a designated block of days.

Three roles to name before testing starts:

• UAT lead (customer): one person who consolidates findings, prunes duplicates, and is the single point of contact with your team. AWH's argument for a single channel is that multiple testers talking to the product team separately creates confusion and slows remediation.
• Process owners (customer): the people who run each scenario, ideally one per department or role in scope.
• Implementation lead (you): answers questions within the same business day, triages issues, and reports status to both sides.

If the customer cannot name a UAT lead with real availability, record it as a go-live risk now and raise it with the executive sponsor, while there is still time to fix it. The same stakeholder map you built at kickoff should show who can approve time for testers.

How should UAT issues be logged and triaged?

Keep one issue log, agreed before testing starts, with a severity for every entry and a named owner on whichever side has to act. The Original Software UAT market survey found that fewer than half of respondents were given tools to support UAT, and most of those relied on Excel to plan and track it. A spreadsheet is fine. Four spreadsheets, an email thread and a Slack channel are not. AWH's rule is that the tool matters less than the fact that all findings land in one agreed place.

A severity scale that works for configured SaaS products:

The fourth row is where implementations lose weeks. UAT surfaces every wish the customer has had since the sales demo, and if each one is treated as a defect the phase never closes. Log them, acknowledge them, and move them into the change-request process you agreed for scope control. Some are legitimate gaps in what was sold, and those need a decision from the sponsor rather than silent absorption by your team.

Triage daily during the testing window. A 15-minute call every morning with the UAT lead, walking the new issues, assigning severity and owner, and confirming what was fixed the previous day, keeps the log from becoming a backlog nobody reads.

What are the exit criteria for UAT sign-off?

Define "passed" as a short list the customer's sponsor agrees to before testing starts: what percentage of scenarios must pass, what severities may remain open, and who signs. A workable default is 100% of scenarios executed, at least 95% passed, zero open S1 issues, zero open S2 issues without an accepted workaround, and written sign-off from the process owners for their areas plus the sponsor for the whole.

The Original Software survey is a reminder of why the criteria need to be written down: 29% of respondents said the quality of software delivered to the UAT team was less than adequate, and 88% said UAT is key to achieving their quality objectives. If the customer discovers in week one that the build is not really ready, an agreed exit list lets both sides say so and reset the dates, instead of arguing about whether "mostly working" counts.

Sign-off should be a document, even a one-page one, listing the scenarios run, the pass rate, the open issues with their agreed disposition, and the signatures. It becomes the reference when someone asks, three months later, why a workflow behaves the way it does. It also feeds directly into the go/no-go decision in your go-live checklist.

Why do customers stall in UAT, and how do you unstick them?

Customers stall in UAT for the same reasons they stall everywhere else in onboarding: unclear ownership, no protected time, and nobody noticing until the date is at risk. OnRamp's 2026 State of Onboarding report, based on 161 onboarding and CS leaders, names unclear next steps and ownership as one of the top three killers of onboarding momentum, and finds that 62% of leaders lack real-time visibility into customer progress, with one in three admitting they do not know where customers stand at any given time.

UAT is uniquely exposed to this because the customer is doing the work. Your team can configure and migrate on schedule regardless of the customer's week; you cannot run their acceptance tests for them. The practical countermeasures:

1. Track scenario completion every day. If 4 of 30 scenarios are done by Wednesday of week one, you know now. Put the number in your status update so the sponsor sees it too.
2. Treat untested scenarios as open customer deliverables. They belong in the same deliverable register as the data export and the SSO metadata, with a named owner and a due date.
3. Escalate on a schedule you agreed at kickoff. Two missed daily check-ins triggers a note to the UAT lead's manager; a week of no progress triggers a sponsor conversation about the go-live date. Because the trigger was agreed in advance, acting on it is routine rather than confrontational.
4. Offer a guided session. A 90-minute screen-share where a process owner runs five scenarios with your implementation lead watching often produces more findings than a week of unsupervised testing, and it restarts momentum.

The point of all of this is that a stalled UAT is visible early enough to act on. OnRamp's data shows 57% of leaders say onboarding friction directly affects revenue realization; a UAT that quietly slips three weeks is exactly that friction.

How does UAT connect to the go-live decision?

UAT sign-off is the evidence behind the go/no-go call, and it should be one of the few hard gates in the plan. Broader implementation research explains why. Prosci's 2025 ERP implementation study found that implementations fall short of expectations between 11% and 31% of the time, about one in five on average, and that organizations spend 92% of their implementation budget on technical activities and 8% on the people side. Gartner, cited in the same analysis, expects more than 70% of recent ERP initiatives to fall short of their original business case by 2027. UAT is the one phase where the people side gets tested before launch.

The same pattern shows up in SaaS buying. Gartner's buyer research, reported by TechRepublic, found that 43% of buyers who regretted a purchase blamed the sales-to-implementation handoff and 32% blamed slow or complex implementation. A UAT that ends with the customer saying "yes, this does what we bought it for" is the strongest antidote to that regret you can produce during onboarding.

Practically, the go-live meeting should open with the UAT summary: scenarios executed, pass rate, open issues by severity with agreed dispositions, and sign-offs received. If any exit criterion is unmet, the choice is a dated remediation plan or a moved date, and the conversation about a slipping go-live is far easier when it is grounded in a test result than in a feeling.

Next steps

If you are planning UAT for an implementation now:

1. Put UAT in the project plan as its own phase with a start date, an end date, and a named customer UAT lead, and confirm it at kickoff.
2. Write the exit criteria (execution rate, pass rate, allowed open severities, who signs) and get the sponsor to agree to them before testing starts.
3. Draft 15 to 40 scenarios from what the customer told you in discovery and kickoff, in the six-field format above, and hand them over as a checklist a week before testing begins.
4. Agree one issue log, one severity scale, and a daily 15-minute triage call for the testing window.
5. Track scenario completion daily, report it in the weekly status update, and escalate on the schedule you agreed rather than when you lose patience.
6. Close with a one-page sign-off document and carry it into the go/no-go meeting.

Two weeks of well-run UAT will surface most of what would otherwise become the first month of support tickets, and it gives the customer's sponsor a reason to trust the go-live date you set.