Client Acceptance (UAT) & Go-Live Guideline

Department

Delivery

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 Kiluth Tasks, 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
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.

For hosting preconditions when the client hosts with Kiluth, see Maintenance & Hosting 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 + Kiluth Tasks + Visibility)

Operating Model
1Kiluth Tasks 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

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:

  1. Phase 1: UAT Preparation - Prepare release candidate and plan UAT
  2. Phase 2: UAT Execution - Run UAT and collect acceptance sign-off
  3. Phase 3: Go-Live Decision & Execution - Make go/no-go decision and execute go-live
  4. 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 Kiluth Tasks before proceeding.

Step 1: Prepare Release Candidate

Prepare the release candidate and confirm the scope being presented for acceptance is clear and linkable in Kiluth Tasks.

Prerequisites: Development work is complete and ready for client acceptance.

Process:

Action
1Prepare release candidate (RC) build/version
2Confirm the scope being presented for acceptance is clear
3Link RC/version reference in Kiluth Tasks
4Link signed brief / SOW in Kiluth Tasks
5Link acceptance criteria reference in Kiluth Tasks

Checkpoint: Proceed only when RC/version reference, signed brief/SOW, and acceptance criteria reference are all linked in Kiluth Tasks.

Outcome
Release candidate is ready, and all acceptance references are clear and linkable in Kiluth Tasks.

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
1Create a task using the template below
2Link acceptance criteria reference
3Define what will be tested (high-level)
4Identify who from the client signs off (name/role)
5Set UAT window (dates)
6Define how issues will be tracked (tasks linked to UAT plan)
7Confirm UAT scope and sign-off method are agreed and recorded
Task Template
TitlePlan UAT for [Client Name] – [Project Title]
AssigneeProject Manager
DescriptionPlease plan UAT for this project:

References
• Project: [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: tasks chained to this one

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 Kiluth Tasks.

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 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
1Provide release candidate to client for UAT
2Track issues as tasks linked to the UAT plan
3Triage issues (prioritize and categorize)
4Fix issues (coordinate with Technology/QA)
5Re-test fixed issues
6Summarize UAT results

Checkpoint: Proceed only when UAT issues are tracked in Kiluth Tasks 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 Kiluth Tasks.

Prerequisites: UAT is complete and results are summarized.

Process:

Action
1Create a task using the template below
2Assign task to Account Executive (AE)
3AE collects client acceptance sign-off
4AE stores sign-off proof and links it in Kiluth Tasks (Sign-off proof: [Link])
5AE keeps the “latest meeting minutes” sign-off proof link up to date
6If contract-related: ensure signed document is used (not email-only)
Task 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: [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 Kiluth Tasks (AE owns upkeep of the latest proof link).

Outcome
Acceptance sign-off proof is collected, stored, and linked in Kiluth Tasks. 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 Kiluth Tasks.

Process:

Action
1Create a task using the template below
2Review acceptance sign-off proof
3Assess go-live readiness (rollback plan, verification plan)
4Record decision explicitly: “Go” or “No-go”
5Document decision notes (short summary)
6Follow the action path based on the decision (see decision tree below)

Decision tree:

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

Checkpoint: Proceed only when go/no-go decision is explicitly recorded in Kiluth Tasks with notes.

Outcome
Go/no-go decision is recorded in Kiluth Tasks. 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 Kiluth Tasks. If the client hosts with Kiluth, hosting preconditions must also be met (see below).

Process:

Action
1Confirm preconditions are met (see template below)
2Technology executes go-live
3PM coordinates execution
4Execute verification steps (listed in task)
5Confirm technical verification
6Document go-live completion and verification results

Hosting preconditions (when client hosts with Kiluth):

Precondition
1Hosting decision made (client has decided to host with Kiluth)
2Hosting paid (if not already paid at project start)
3Hosting activation complete (per Maintenance & Hosting Guideline)
4UAT test cases approved/signed by client

Go-live is blocked until these are met. See Hosting Activation Process.

Task 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]
• 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
1Review go-live verification results
2Confirm technical verification is complete
3Document verification completion
4Link verification results in Kiluth Tasks

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
1Assess if hypercare is needed
2If needed: define hypercare window (dates)
3Assign hypercare owners
4Track issues during hypercare period
5Record hypercare exit when complete (or transition to support)
6If 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 Kiluth Tasks 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