User Acceptance Testing Template: Approve Workflows With Evidence

User Acceptance Testing Template: Approve Workflows With Evidence

A user acceptance testing template records whether a delivered system supports the work your business needs to do. Use it to define realistic tasks, expected outcomes, actual results, evidence, owners and approval conditions. Business users run the tests; the accountable leader decides whether to accept, restrict or delay the release.

Updated: September 8, 2026

The demonstration looked good. A new inquiry appeared, a task was created and the sales dashboard updated. Then someone asked what happens when the same customer submits twice, the assigned salesperson is away or the inquiry has no contact details.

Those questions belong in your acceptance record before the workflow reaches customers. The template below helps a founder, operations lead or project manager document the answers without writing code or becoming a software tester.

If your supplier has delivered a workflow but acceptance is still vague, book a free consultation with Wavicle. Bring the business requirement and one example of work that must succeed. That gives the discussion a concrete starting point.

What should your user acceptance testing template prove?

User acceptance testing, usually shortened to UAT, checks whether people can complete agreed business tasks using the delivered system. A completed test connects the original requirement to an observed result. A useful acceptance decision therefore has evidence behind it: who tried the task, what happened and whether the outcome met the agreed condition.

A supplier may have checked that the individual parts work. Your team still needs to confirm that the complete job makes sense in practice. Can an operations coordinator identify an overdue request? Can a salesperson correct a mistaken assignment? Does the next person in the process receive enough information to continue?

Atlassian's user acceptance testing template describes a structured record for organizing results and comparing actual with expected outcomes. Source checked September 8, 2026. That distinction matters: a meeting note saying everyone liked the demonstration gives you much less information than a recorded business test.

There is broader evidence for taking delivery capability seriously. PMI's February 2024 Pulse of the Profession report, checked September 8, 2026, reports an average project performance rate of 73.8%. It also reports a 57% increase in the use of hybrid project approaches and that 64% of senior leaders say their teams need new technical skills. These are general project findings, not measurements of UAT effectiveness or forecasts for your project. For a business owner, the practical implication is to make the acceptance process usable by the team you actually have, whichever delivery method the supplier uses.

Keep the scope specific. A UAT record evaluates a delivered workflow. Your business requirements document states what the business needs. Your operational readiness checklist covers the wider launch decision, including support, ownership and recovery. Link these records so a passed test does not get mistaken for approval of everything surrounding the launch.

What can you copy into your UAT document?

Start with a short cover record: workflow name, version being tested, business owner, supplier contact, test dates, participating roles and the requirements included. State what is outside this round. If customer payments are excluded, say so explicitly; nobody should infer they were checked because customer intake passed.

Next, copy these fields into a spreadsheet or shared document. Use one record for each scenario. The example entries are hypothetical and illustrate a US professional-services firm checking an inquiry-routing workflow; they are not client results.

Keep expected and actual results in separate fields. Copying the expected wording into the actual-result field before testing makes the sheet look complete while removing its value. A blank result means no evidence yet.

Use clear statuses. Not run means nobody has executed the scenario. Blocked means they could not execute it, perhaps because their account was missing. Failed means they ran it and observed an unacceptable outcome. These require different next actions. Neither blocked nor not run counts as a pass.

For teams that prefer an existing downloadable workbook, Smartsheet provides a UAT test case template in its test-case collection. Source checked September 8, 2026. Whichever format you choose, retain the link between the requirement, expected outcome and recorded result.

How do you write tests that reflect real work?

Begin with the jobs people must complete, described in their own language. “Create an inquiry and assign it to the right person” is understandable. “The automation functions correctly” is too broad to test or dispute usefully.

Write the expected result before running the scenario. Include an agreed time limit only where timing is part of the business requirement. If a follow-up task must appear within five minutes, record that threshold and measure it. Five minutes is an example requirement, not a universal standard.

For the hypothetical inquiry workflow, use a small set of distinct business situations. A normal inquiry should produce the correct owner and task. A repeated submission should follow your agreed duplicate rule. A submission without a required contact detail should follow a visible correction route. An inquiry assigned to an absent employee should reach the agreed backup. A staff member without permission should be unable to view restricted information.

Also check correction and recovery. If someone enters the wrong company name, can the authorized user fix it without creating another customer? If a connected system is temporarily unavailable, does the team see pending work and know who must act? Ask the supplier to create a safe test condition for that scenario; do not interrupt a working business system just to see what happens.

Have the person who receives the handoff participate. The salesperson may see a task while the coordinator sees a completed submission. Testing only one screen misses whether the information needed for the next action arrived intact.

For AI-assisted work, include situations where the appropriate result is a request for review. Suppose the workflow suggests an inquiry category. A clear request should receive the agreed category; an ambiguous request should reach a person if that is the approved policy. Record both the suggested output and the final action. A plausible sentence is not sufficient evidence that the business decision was right.

Avoid relying on one successful AI example. Use a varied set of approved sample inputs and repeat important checks. The business owner should agree which errors block release and which outputs require review. Do not invent an accuracy percentage after looking at the results to make a weak test set pass.

Finally, separate defects from new requests. A missing agreed owner is a defect. A newly requested dashboard may be valuable, but it belongs in a change decision unless it was part of the agreed scope. This keeps acceptance fair to both your business and the delivery partner.

How should business users run testing and handle failures?

Arrange a short orientation before execution. Show participants where the sample records are, which account to use, where evidence belongs and whom to contact when they cannot proceed. Protect time for testing; assigning it alongside a full customer workload often leaves the record unfinished.

Use a test environment or a controlled arrangement agreed with the supplier. Sample messages should go to test recipients. Sample transactions should not trigger real charges or customer commitments. Use invented or appropriately protected records, and restrict access to screenshots containing confidential information.

Let the business user operate the workflow. The supplier can clarify instructions and investigate problems, but should avoid taking over every difficult step. If the user cannot complete an ordinary task without coaching, record that observation. It may reveal a training gap, an unclear screen or an unsuitable process.

When something fails, record enough for another person to reproduce it: test ID, time, steps taken, input reference, expected result and actual result. “Didn't work” creates another conversation. “The backup owner remained blank after the absent-owner scenario” gives the supplier an actionable starting point.

Agree impact categories before the test session. A release-blocking failure prevents a critical task, exposes restricted information or creates an unacceptable customer action. A lower-impact issue may have a workable temporary procedure. Labels should reflect business consequences, not how easy the supplier thinks the repair will be.

After a repair, rerun the failed scenario against the updated version and retain the earlier result. Also check nearby tasks that the change could affect. If the assignment rule changed, repeat the ordinary and backup-owner scenarios. A note saying “supplier fixed it” is a progress update; the retest provides acceptance evidence.

Keep a short unresolved-issue list alongside the test records. Each issue needs a responsible person, next action and decision date. Record disputed requirements separately so your team can resolve scope rather than endlessly rerunning a test with different expectations.

When should you approve, limit or delay launch?

Agree the release conditions before testing starts. Critical scenarios should have passed, blocking issues should be resolved and any remaining limitations should have an owner and an explicit decision. A high overall pass rate does not cancel a failed critical requirement.

For example, imagine that a hypothetical test round contains twenty scenarios. Nineteen pass, but the failed scenario sends a customer's details to the wrong recipient. Calling the round “95% successful” obscures the decision that matters. The counts are illustrative; the principle is that impact must remain visible alongside totals.

Use a compact sign-off record. State the workflow and version, requirements covered, dates tested, evidence location, unresolved issues, release decision, restrictions, decision owner and approval date. Include a review date for temporary workarounds. Keep this record accessible to the people who will support the workflow.

Acceptance can be full, limited or withheld. Limited acceptance might permit one internal team to use a workflow while a non-critical reporting issue is corrected. It should specify the permitted users and activities, the temporary procedure and when the decision expires. Avoid using “conditional approval” as a vague way to leave all problems open.

Withhold acceptance when a critical result is unproven or a failure has no acceptable control. State exactly what evidence would change the decision. That gives the supplier a clear route to completion and helps the business avoid an indefinite delay.

Passing UAT also does not prove that the workflow will save money. After release, compare actual work with the baseline you agreed before delivery: time to assign an inquiry, proportion with an owner, overdue follow-ups or manual correction effort. Acceptance demonstrates that the delivered behavior meets requirements; ongoing measurement shows whether that behavior improves the business.

How can Wavicle help turn acceptance criteria into a working workflow?

A useful starting scope is one complete business workflow, from its trigger to its final handoff. Identify the records it touches, who makes decisions and what happens when an input is missing or a step fails. Then define the evidence your business owner needs before approving it.

For an inquiry-routing project, a Wavicle engagement can be scoped around connecting the intake form, customer records, assignment rules and follow-up tasks. The acceptance work should cover ordinary processing, duplicates, missing information, ownership changes and visible exceptions. Ask for the test records and operating handoff as explicit deliverables when agreeing the scope.

Bring your current process, the systems involved and examples of failed handoffs to the consultation. These help establish whether the right next step is a small repair, a workflow build or clearer operating rules. Book a free consultation at Wavicle to discuss that scope and the business evidence needed to accept it.

What are the frequently asked questions?

Who should run user acceptance testing?

People who perform the affected business tasks should execute the scenarios using representative permissions. The supplier supports preparation and repairs. An accountable business owner reviews the evidence and makes the acceptance decision.

Can I use a spreadsheet for UAT?

Yes. A shared spreadsheet is sufficient when it records requirements, steps, expected and actual results, evidence, issues and retests clearly. Keep one current version and a named owner so conflicting copies do not create conflicting decisions.

How many UAT test cases do we need?

Use enough scenarios to cover agreed business requirements, critical handoffs and important exception paths. There is no universal count. A small workflow needs fewer cases than a process spanning several roles and systems, but critical risks still need explicit checks.

Is UAT the same as the supplier's testing?

They serve different purposes. The supplier checks the delivered system during development. UAT adds evidence that representative business users can complete the agreed work. Ask what earlier checks have been completed so UAT can focus on business acceptance.

Should every failed test delay release?

A failure should be judged against its business impact and the agreed acceptance conditions. Critical failures block release. A lower-impact issue may support limited acceptance when the workaround, owner, deadline and approving decision-maker are recorded.

What should we do after the supplier fixes a problem?

Rerun the failed scenario on the updated version, record fresh evidence and check related tasks that the repair could affect. Retain the original failure and link the retest so the approval record shows what changed.

Does passing UAT guarantee an AI workflow is reliable?

No. It shows that the tested scenarios met the agreed conditions. AI outputs can vary, and real usage may introduce new situations. Retain human review where needed, monitor exceptions after release and revisit acceptance checks when the workflow changes.