Acceptance Is Where It Turns Ugly: 5 Conflicts That Blow Up in UAT and a Scorecard to Minimize the Fight

Opening: a week before launch, both sides feel cheated

An NT$450K website-revamp project, week 11, a week before launch: the client sends a 30-item "issues list." Some are real bugs, some are "features I assumed would be there," some are "not how I pictured it." The vendor sees out-of-scope additions; the client sees things that should've been included. Acceptance (UAT, user acceptance testing) is where outsourced projects most easily turn from partnership to opposition — and 90% of the conflict was buried the day the contract was signed.

Industry myths busted

Myth 1: "Acceptance is just testing before launch." → Truth: acceptance is "comparing deliverables against pre-agreed standards." Without pre-agreed standards, acceptance becomes a he-said-she-said.
Myth 2: "Everything the client raises is a bug." → Truth: a client list usually mixes three things — real bugs, out-of-scope requests, and subjective preferences — each handled and billed completely differently; lumping them guarantees a fight.
Myth 3: "Feature done = delivered." → Truth: "delivered" must include "acceptance criteria + acceptance method + acceptance deadline," or "done" is forever in dispute.
Myth 4: "Longer acceptance is safer." → Truth: open-ended acceptance freezes the final payment and lets scope creep indefinitely; a clear window protects both sides.

Core framework: classify every issue into three before handling (Bug / Scope / Preference)

When the issues list arrives, tag each item first, then handle by the table — this table is your "acceptance compact":

Class	Definition	Handling	Billing
Bug (defect)	Doesn't match spec, broken function	Vendor fixes free, counts toward acceptance	Not extra
Scope (out of scope)	New feature not in spec	Change order, re-estimate	Extra
Preference	In spec but subjectively changed	Assess effort; small in, large via change order	Case by case

Make these three clear in the contract and the acceptance meeting, and 80% of "blow-ups" become "reconciliations."

Three typical scenarios compared

Small marketing site (under NT$150K): acceptance standard as "pages match design + forms submit + mobile usable," 7-day acceptance.
Mid feature system (NT$500K): "user-story acceptance criteria" ticked item by item + a UAT environment, 14-day acceptance, staged.
Large integration (NT$1.5M+): a formal UAT plan, test cases, defect severity (P0-P3), SLA tied to staged final payments, 30-day acceptance.

Full hidden-cost list (the price of vague acceptance)

Back-and-forth communication hours: a mid project with no defined acceptance standard burns 20-40 extra hours of unproductive talk in UAT.
Delayed final payment: it's often 20-30% of the contract; a stuck acceptance freezes that cash flow indefinitely.
Scope creep: every "just tweak this" averages 0.5-2 days; ten of them is two weeks.
Relationship depreciation: one ugly acceptance zeroes out a 5-year renewal opportunity — and renewal clients cost almost nothing to acquire.

KPI scorecard for evaluating an outsourcing partner (acceptance maturity, 1-5)

☐ Does the contract list "acceptance standards" explicitly?
☐ Is a separate UAT environment provided?
☐ Is there a defect severity (P0-P3) scheme?
☐ Are issue lists classified into Bug/Scope/Preference?
☐ Is the change-order process documented?
☐ Are acceptance deadline and final-payment terms clear?
☐ Is there a post-launch warranty period?
☐ Is a checklist template provided to tick off?

If ≥ 6 of 8 are "yes," the vendor's acceptance maturity is usually trustworthy.

ScriptWalker's approach + where it doesn't fit

Our approach front-loads acceptance: at kickoff we deliver an "acceptance standards doc + checklist template," provide a separate UAT environment, classify every issue into three, and route changes via written change orders. Where it doesn't fit (honestly):

Clients unwilling to define acceptance standards first, insisting on "build then talk."
Projects with weekly major changes who won't accept change-order billing.
Relationships expecting "unlimited free tweaks forever."

Transition / kickoff playbook

Kickoff week 1: co-sign the acceptance standards doc and checklist template; define defect severity and acceptance deadline.
During dev (end of each phase): staged mini-acceptances to catch gaps early, not all at the end.
UAT (7-30 days): client ticks off the checklist; issues go into the three-class table; sync every two days.
Post-launch warranty (30 days): real bugs fixed free; new requests go to the next change order.

Decision checklist

☐ Does my contract state acceptance standards?
☐ Can I tell bug, out-of-scope, and preference apart?
☐ Did the vendor give me a separate UAT environment?
☐ Is there a written process for change requests?
☐ Are final-payment terms clearly tied to acceptance?
☐ Is there a post-launch warranty period?
☐ Is the acceptance deadline clear?

FAQ

How long should the acceptance period be?

By scale: ~7 days for a small marketing site, ~14 days for a mid feature system, ~30 days for a large integration. The point isn't "longer is better" but "clear" — open-ended acceptance is a risk to both sides, freezing payment and breeding endless creep.

The client raised a new feature not in the spec during acceptance — now what?

Tag it as "Scope (out of scope)," re-estimate and quote via a written change order; don't silently absorb it. Define the three-class handling in the contract upfront and this conversation shifts from "argument" to "reconciliation."

Final payment keeps getting stuck — where's the usual snag?

90% of the time it's "acceptance standards weren't pre-agreed," so the client accepts on subjective feel. The fix is delivering an acceptance standards doc and checklist at kickoff, tying final payment to tickable standards rather than "until the client is satisfied."

A bug found after launch — whose is it?

Set a post-launch warranty period (usually 30 days); within it, real bugs that don't match spec are fixed free by the vendor; new requests go to a new change order. Write the warranty into the contract so neither side has to guess "is this a bug."

Call to action

Want a ready-to-use "acceptance standards doc + acceptance scorecard" template? We offer a free 30-minute consult to fill in the acceptance criteria for your current project and minimize the risk of a pre-launch fallout.