Client Acceptance (UAT) & Go-Live Guideline
Department
Summary
How Kiluth runs client acceptance (UAT) and go-live: checklist and handoff flow from release candidate through UAT planning, execution, acceptance sign-off, go/no-go decision, go-live execution, and post go-live verification. Explicit decisions, sign-off proof linked in Asana, and clear “ready” criteria.
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 | |
|---|---|
| 1 | UAT planning and execution |
| 2 | Acceptance sign-off (including proof + linking) |
| 3 | Go/no-go decision and go-live execution |
| 4 | Immediate post go-live verification and hypercare handoff |
| 5 | Project 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.
For hosting preconditions when the client hosts with Kiluth, see Maintenance & Hosting Guideline.
Definitions
| Term | Definition |
|---|---|
| UAT (User Acceptance Testing) | Client-side validation that the delivered scope meets agreed acceptance criteria |
| Acceptance criteria | Conditions used to decide whether a deliverable is acceptable (often defined in the signed brief / SOW) |
| Acceptance sign-off proof | Evidence 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-live | The controlled release of the product/change into the client’s real operating environment |
| Hypercare | A short period after go-live where the team prioritizes stabilization and rapid response |
Operating Model (Sprint + Asana + Visibility)
| Operating Model | |
|---|---|
| 1 | Asana is the system of record for work tracking, approvals, and handoffs. |
| 2 | Use checkpoints and decision points: don’t move forward until the previous step is “done”, and branches are explicit. |
| 3 | Handoff order: upstream defines handoff artifacts/exit criteria; downstream defines execution after handoff. |
Roles & Responsibilities
| Role | Responsibility |
|---|---|
| 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 Executive | Involved when go-live risk, timeline, or contractual/commercial commitments need escalation |
UAT & Go-Live Process Walkthrough
The UAT and go-live process follows four sequential phases. Each phase builds on the previous one and must be completed before moving to the next.
Process flow:
- Phase 1: UAT Preparation - Prepare release candidate and plan UAT
- Phase 2: UAT Execution - Run UAT and collect acceptance sign-off
- Phase 3: Go-Live Decision & Execution - Make go/no-go decision and execute go-live
- Phase 4: Post Go-Live - Verify go-live and handle hypercare if needed
End of flow: Once go-live is verified and acceptance is complete, proceed to project closure and handover. See Project Closure & Handover Guideline.
Phase 1: UAT Preparation
What you’ll do: Prepare the release candidate for acceptance and create a UAT plan with clear scope, timeline, and sign-off criteria. Ensure all necessary references are linked in Asana before proceeding.
Step 1: Prepare Release Candidate
Prepare the release candidate and confirm the scope being presented for acceptance is clear and linkable in Asana.
Prerequisites: Development work is complete and ready for client acceptance.
Process:
| Action | |
|---|---|
| 1 | Prepare release candidate (RC) build/version |
| 2 | Confirm the scope being presented for acceptance is clear |
| 3 | Link RC/version reference in Asana |
| 4 | Link signed brief / SOW in Asana |
| 5 | Link acceptance criteria reference in Asana |
Checkpoint: Proceed only when RC/version reference, signed brief/SOW, and acceptance criteria reference are all linked in Asana.
| Outcome |
|---|
| Release candidate is ready, and all acceptance references are clear and linkable in Asana. |
Step 2: Plan UAT
Create the UAT plan task, link acceptance criteria, set UAT window, and identify who from the client signs off.
Prerequisites: Release candidate is prepared and all references are linked.
Process:
| Action | |
|---|---|
| 1 | Create Asana task using the template below |
| 2 | Link acceptance criteria reference |
| 3 | Define what will be tested (high-level) |
| 4 | Identify who from the client signs off (name/role) |
| 5 | Set UAT window (dates) |
| 6 | Define how issues will be tracked (Asana tasks linked to UAT plan) |
| 7 | Confirm UAT scope and sign-off method are agreed and recorded |
| Asana Card Template | |
|---|---|
| Title | Plan UAT for [Client Name] – [Project Title] |
| Assignee | Project Manager |
| Description | Please 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. |
Checkpoint: Proceed only when UAT plan is agreed (scope, window, who signs off) and recorded in Asana.
| Outcome |
|---|
| UAT plan is created, agreed, and recorded with clear scope, timeline, and sign-off criteria. |
What happens next: Proceed to Phase 2: UAT Execution.
Phase 2: UAT Execution
What you’ll do: Execute UAT with the client, track issues, and collect acceptance sign-off proof. Ensure all issues are resolved and documented before proceeding.
Step 1: Run UAT
Execute UAT with the client and track issues as Asana tasks linked to the UAT plan. For bug report format and templates, see Bug Report Guideline.
Prerequisites: UAT plan is agreed and recorded.
Process:
| Action | |
|---|---|
| 1 | Provide release candidate to client for UAT |
| 2 | Track issues as Asana tasks linked to the UAT plan |
| 3 | Triage issues (prioritize and categorize) |
| 4 | Fix issues (coordinate with Technology/QA) |
| 5 | Re-test fixed issues |
| 6 | Summarize UAT results |
Checkpoint: Proceed only when UAT issues are tracked in Asana and linked, and UAT results are summarized.
| Outcome |
|---|
| UAT is complete, all issues are tracked and resolved, and results are summarized. |
Step 2: Collect Acceptance Sign-Off
Collect acceptance sign-off proof from the client and link it in Asana.
Prerequisites: UAT is complete and results are summarized.
Process:
| Action | |
|---|---|
| 1 | Create Asana task using the template below |
| 2 | Assign task to Account Executive (AE) |
| 3 | AE collects client acceptance sign-off |
| 4 | AE stores sign-off proof and links it in Asana (Sign-off proof: [Link]) |
| 5 | AE keeps the “latest meeting minutes” sign-off proof link up to date |
| 6 | If contract-related: ensure signed document is used (not email-only) |
| Asana Card Template | |
|---|---|
| Title | Collect acceptance sign-off for [Client Name] – [Project Title] |
| Assignee | Account Executive (AE) |
| Description | Please 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. |
Checkpoint: Proceed only when acceptance sign-off proof is linked in Asana (AE owns upkeep of the latest proof link).
| Outcome |
|---|
| Acceptance sign-off proof is collected, stored, and linked in Asana. If contract-related, signed document is used. |
What happens next: Proceed to Phase 3: Go-Live Decision & Execution.
Phase 3: Go-Live Decision & Execution
What you’ll do: Make the go/no-go decision based on acceptance sign-off, then execute go-live with verification and rollback plans in place.
Step 1: Make Go/No-Go Decision
Record the go/no-go decision and notes in the go-live task.
Prerequisites: Acceptance sign-off proof is linked in Asana.
Process:
| Action | |
|---|---|
| 1 | Create Asana task using the template below |
| 2 | Review acceptance sign-off proof |
| 3 | Assess go-live readiness (rollback plan, verification plan) |
| 4 | Record decision explicitly: “Go” or “No-go” |
| 5 | Document decision notes (short summary) |
| 6 | Follow the action path based on the decision (see decision tree below) |
Decision tree:
| Outcome | Action |
|---|---|
| Go | Proceed to go-live execution. Keep verification/rollback steps visible in Asana. |
| No-go | Pause go-live, document blockers, align revised plan (timeline + responsibilities), and reschedule. |
Checkpoint: Proceed only when go/no-go decision is explicitly recorded in Asana with notes.
| Outcome |
|---|
| Go/no-go decision is recorded in Asana. If “Go”, proceed to execution. If “No-go”, blockers are documented and plan is revised. |
Step 2: Execute Go-Live
Execute go-live with Technology, coordinate with PM, and verify completion.
Prerequisites: Go/no-go decision is “Go” and recorded in Asana. If the client hosts with Kiluth, hosting preconditions must also be met (see below).
Process:
| Action | |
|---|---|
| 1 | Confirm preconditions are met (see template below) |
| 2 | Technology executes go-live |
| 3 | PM coordinates execution |
| 4 | Execute verification steps (listed in task) |
| 5 | Confirm technical verification |
| 6 | Document go-live completion and verification results |
Hosting preconditions (when client hosts with Kiluth):
| Precondition | |
|---|---|
| 1 | Hosting decision made (client has decided to host with Kiluth) |
| 2 | Hosting paid (if not already paid at project start) |
| 3 | Hosting activation complete (per Maintenance & Hosting Guideline) |
| 4 | UAT test cases approved/signed by client |
Go-live is blocked until these are met. See Hosting Activation Process.
| Asana Card Template | |
|---|---|
| Title | Go/no-go + Go-live execution for [Client Name] – [Project Title] |
| Assignee | Project Manager |
| Description | Please 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] • If hosting with Kiluth: Hosting paid, hosting activation complete, UAT test cases signed (see Maintenance & Hosting Guideline) 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. |
Checkpoint: Proceed only when go-live is executed and verified.
| Outcome |
|---|
| Go-live is executed, verified, and documented. Rollback plan and verification steps were followed. |
What happens next: Proceed to Phase 4: Post Go-Live.
Phase 4: Post Go-Live
What you’ll do: Verify go-live completion and handle hypercare if needed. Prepare for project closure when acceptance and go-live are complete.
Step 1: Verify Go-Live
Confirm go-live verification is complete and document results.
Prerequisites: Go-live execution is complete.
Process:
| Action | |
|---|---|
| 1 | Review go-live verification results |
| 2 | Confirm technical verification is complete |
| 3 | Document verification completion |
| 4 | Link verification results in Asana |
Checkpoint: Proceed only when go-live verification is confirmed and documented.
| Outcome |
|---|
| Go-live verification is complete and documented. |
Step 2: Handle Hypercare (If Needed)
Define hypercare window, track issues, and record exit when complete.
Prerequisites: Go-live is verified.
Process:
| Action | |
|---|---|
| 1 | Assess if hypercare is needed |
| 2 | If needed: define hypercare window (dates) |
| 3 | Assign hypercare owners |
| 4 | Track issues during hypercare period |
| 5 | Record hypercare exit when complete (or transition to support) |
| 6 | If not needed: proceed directly to closure trigger |
Checkpoint: Proceed only when hypercare window is defined and completed (or transitioned), or confirmed not needed.
| Outcome |
|---|
| Hypercare is handled (window defined, issues tracked, exit recorded) or confirmed not needed. |
What happens next: When acceptance sign-off is complete and go-live is verified, proceed to project closure and handover. See Project Closure & Handover Guideline.
Go-Live Checklist (PM Use)
This checklist is used by PM to track progress for each UAT and go-live process. Complete each item in order where applicable.
Phase 1: UAT Preparation
| Checklist | |
|---|---|
| 1 | ☐ RC/version reference is clear and linked |
| 2 | ☐ Signed brief / SOW is linked |
| 3 | ☐ Acceptance criteria reference is linked |
| 4 | ☐ UAT plan agreed (scope, window, who signs off) |
Phase 2: UAT Execution
| Checklist | |
|---|---|
| 1 | ☐ UAT issues tracked in Asana and linked |
| 2 | ☐ UAT results summarized |
| 3 | ☐ Sign-off proof: [Link] (AE owns upkeep of the latest proof link) |
| 4 | ☐ If contract-related: signed document is used |
Phase 3: Go-Live Decision & Execution
| Checklist | |
|---|---|
| 1 | ☐ Go/no-go decision recorded |
| 2 | ☐ Rollback plan exists (high-level) |
| 3 | ☐ Verification plan exists |
| 4 | ☐ If hosting with Kiluth: Hosting paid, hosting activation complete, UAT test cases signed |
| 5 | ☐ Go-live executed and verified |
Phase 4: Post Go-Live
| Checklist | |
|---|---|
| 1 | ☐ Go-live verification confirmed and documented |
| 2 | ☐ Hypercare window defined and completed (or transitioned) |
| 3 | ☐ Closure trigger met: acceptance sign-off is complete + go-live verified |