AI IMPLEMENTATION ACCEPTANCE CHECKLIST
AppliedAgents | 7 October 2026
https://www.appliedagents.com.au/services/ai-implementation/

Use this editable worksheet with any supplier. Adapt the cases to your
workflow and agree the expected behaviour before testing. This is a planning
aid, not a certification or a substitute for your business requirements.
Use fictional or de-identified information until data handling is agreed.

WORKFLOW AND RESPONSIBILITIES
Task and intended improvement:
Trigger / starting point:
Finish / definition of complete:
Tools and authoritative records:
Person responsible for reviewing results:
Person responsible for exceptions:
Actions requiring approval:
Scope exclusions:

BEFORE BUILDING
[ ] Check whether an existing feature can do the job.
[ ] Confirm supported connections, account plans and required access.
[ ] Specify which information each tool receives and retention arrangements.
[ ] Agree the quote, acceptance criteria and who signs off the result.
[ ] Separate build fees, licences/usage, support and future changes.

TEST CASES TO ADAPT
1. Ordinary task: Complete input reaches the intended destination once.
2. Missing information: The gap is visible; the system does not invent it.
3. Conflicting information: The disputed field goes to the agreed reviewer.
4. Duplicate event: Replaying the event does not repeat an unwanted action.
5. Unavailable destination: Pending work is visible and can be recovered.
6. Partial completion: Completed steps stay distinct from pending steps.
7. Uncertain AI output: The agreed review or fallback step is used.
8. Restricted access: Information stays within the agreed permissions.
9. Pause and restart: New work stops and resumes as agreed, without losing
   track of work already underway.
10. Changed or withdrawn request: Outdated reminders or actions are stopped.

RECORD ONE ROW PER TEST (copy this block)
Case / example ID:
Environment and version:
Expected behaviour (agreed before the test):
Actual result and evidence location:
Status: not run / passed / failed / needs clarification
Unresolved issue and responsible person:
Retest result and date:
Reviewer / acceptance decision:

ILLUSTRATIVE CASE: CLIENT ONBOARDING
Input: Accepted engagement C204; folder created; project tool unavailable.
Expected: Folder remains recorded. Project setup is marked pending. The
agreed person is notified. Recovery completes the missing step without
creating another folder. No message says the whole setup is complete.
Actual result: Not run. This is a fictional example, not a test receipt.

BEFORE LAUNCH
[ ] Agree how to pause the workflow and who can do it.
[ ] Confirm access to accounts, documentation and relevant exports.
[ ] Record licence/ownership terms for custom code and third-party parts.
[ ] Agree exception handling, support hours and response commitments.
[ ] Identify known unresolved issues and the decision on each.
[ ] Agree the fallback if the workflow cannot run.

MEASURE THE WHOLE TASK
Baseline period and number of tasks:
Time spent doing the task, reviewing and correcting it:
Exceptions, duplicate actions, missing records and rework:
Pilot period and number of comparable tasks:
Same measures after implementation:
Ongoing running and support costs:
Decision: continue / revise / stop; reason and owner:

Time released is capacity, not automatically cash saved. Separate measured
results from estimates and account for changes in task volume or complexity.