Client Acceptance (UAT) & Go-Live Guideline

Department

Delivery

Table of Contents


Purpose

This guideline defines how Kiluth runs client acceptance (UAT) and go-live as a concrete checklist + handoff flow (what to link, who signs off, and what “ready” means).

Outcome
Acceptance and go-live decisions are explicit, risks are surfaced early, and the client sign-off proof is easy to find.

Scope

This guideline covers the workflow from “release candidate is ready” through:

Included
1UAT planning and execution
2Acceptance sign-off (including proof + linking)
3Go/no-go decision and go-live execution
4Immediate post go-live verification and hypercare handoff
5Project closure trigger (acceptance + go-live complete)

This guideline does not define detailed deployment tooling or incident response operations. Those live in Technology-owned documents when needed.

For environment definitions and the Technology execution playbook, see Go-Live & Incident Response Guideline.


Definitions

TermDefinition
UAT (User Acceptance Testing)Client-side validation that the delivered scope meets agreed acceptance criteria
Acceptance criteriaConditions used to decide whether a deliverable is acceptable (often defined in the signed brief / SOW)
Acceptance sign-off proofEvidence the client accepted (email confirmation or signed document; signed document required for contract-related decisions)
Release candidate (RC)A build/version intended for acceptance and go-live pending validation
Go-liveThe controlled release of the product/change into the client’s real operating environment
HypercareA short period after go-live where the team prioritizes stabilization and rapid response

Operating Model (Sprint + Asana + Visibility)

Operating Model
1Asana is the system of record for work tracking, approvals, and handoffs.
2Use checkpoints and decision points: don’t move forward until the previous step is “done”, and branches are explicit.
3Handoff order: upstream defines handoff artifacts/exit criteria; downstream defines execution after handoff.

Roles & Responsibilities

RoleResponsibility
Project Manager (PM)Owns the UAT/go-live plan, coordinates execution, keeps risks visible, ensures checklists are completed
Account Executive (AE)Owns client coordination for acceptance, sign-off collection, and upkeep of the “latest meeting minutes” sign-off proof link
Technology (implementation owner)Prepares RC, supports go-live execution, provides rollback plan, confirms technical verification
QA (if assigned)Confirms QA readiness and supports defect triage during UAT/hypercare
Business ExecutiveInvolved when go-live risk, timeline, or contractual/commercial commitments need escalation

Step-by-Step Process

Step
1Prepare release candidate (RC) and confirm the scope being presented for acceptance is clear and linkable in Asana
2Plan UAT: create the UAT plan task, link acceptance criteria, set UAT window, and name who from the client signs off
3Run UAT: track issues as Asana tasks linked to the UAT plan (triage → fix → re-test)
4Collect acceptance sign-off proof: AE links proof (Sign-off proof: [Link]) and keeps the “latest meeting minutes” proof link up to date
5Go/no-go decision point: record “Go / No-go” + notes in the go-live task
6Execute go-live: Technology executes; PM coordinates; verification + rollback steps are listed in the task
7Stabilization window (hypercare) (only when needed): define window + owners; track issues; record exit
8Project closure & handover (when go-live is verified and acceptance is complete) — see Project Closure & Handover Guideline

Decision point: go/no-go

OutcomeAction
GoProceed to go-live execution. Keep verification/rollback steps visible in Asana.
No-goPause go-live, document blockers, align revised plan (timeline + responsibilities), and reschedule.

Asana Card Template: Plan UAT

Asana Card Template
TitlePlan UAT for [Client Name] – [Project Title]
AssigneeProject Manager
DescriptionPlease plan UAT for this project:

References
• Project card: [Link]
• Signed brief / SOW: [Link]
• Acceptance criteria reference: [Link/section]

UAT plan
• What will be tested (high-level): [List]
• Who from client signs off: [Name/role]
• UAT window: [Dates]
• How issues will be tracked: Asana tasks linked to this card

Checkpoint
Proceed when UAT scope and sign-off method are agreed and recorded.

Asana Card Template: Collect acceptance sign-off

Asana Card Template
TitleCollect acceptance sign-off for [Client Name] – [Project Title]
AssigneeAccount Executive (AE)
DescriptionPlease collect client acceptance sign-off for the agreed scope:

References
• Project card: [Link]
• RC/version reference: [Link]
• UAT results summary: [Link]

Acceptance sign-off
• Sign-off proof: [Link] (stored/linked by AE)
• Optional quote (1 line): [Quote]

Note: if the acceptance decision affects contract-related decisions, use a signed document.

Asana Card Template: Go/no-go + execute go-live

Asana Card Template
TitleGo/no-go + Go-live execution for [Client Name] – [Project Title]
AssigneeProject Manager
DescriptionPlease coordinate the go/no-go decision and go-live execution:

Preconditions
• Acceptance sign-off proof link exists: [Link]
• Rollback plan exists (high-level): [Link/notes]
• Verification plan exists: [List/link]

Decision (write explicitly)
• Decision: Go / No-go
• Decision notes: [Short]

Execution
• Go-live date/time: [Datetime]
• Technology owner: [Name]
• Verification steps: [List]

Proceed only when the decision is written in this task.

Go-Live Checklist (PM Use)

Preconditions (before UAT)

Checklist
1☐ RC/version reference is clear and linked
2☐ Signed brief / SOW is linked
3☐ Acceptance criteria reference is linked

UAT

Checklist
1☐ UAT plan agreed (scope, window, who signs off)
2☐ UAT issues tracked in Asana and linked
3☐ UAT results summarized

Acceptance sign-off

Checklist
1☐ Sign-off proof: [Link] (AE owns upkeep of the latest proof link)
2☐ If contract-related: signed document is used

Go/no-go + go-live

Checklist
1☐ Go/no-go decision recorded
2☐ Rollback plan exists (high-level)
3☐ Verification plan exists
4☐ Go-live executed and verified

Hypercare + closure trigger

Checklist
1☐ Hypercare window defined and completed (or transitioned)
2☐ Closure trigger met: acceptance sign-off is complete + go-live verified