REPETITIVE-TASK TRIAL WORKSHEET — SPLICE WORK
Companion guide: https://splicework.ai/blog/manual-work/ai-for-repetitive-tasks/

Use this in a test or review environment. Example records below are fictional.
Expected behavior is a test criterion, not a claim that a test has passed.
No email signup required. Copy, edit or print this file.

1. DEFINE THE JOB
Task:
Owner:
Trigger:
Input source and record identifier:
Authoritative source if records disagree:
Expected destination and output:
Allowed actions:
Action requiring approval:
Approver:
Stop/escalation rule:
Manual fallback:
Who maintains the connection, fields and templates:

2. FICTIONAL CASES TO ADAPT

GABLE — LISTING FILE
Input: Just sold; 48 Juniper Lane; verified agent contact; approved template;
one uploaded property photo; price and square footage not supplied.
Expected: editable file uses supplied data, omits missing numbers with a note,
fits the photo without stretching and remains subject to coordinator review.
Check the actual crop, file access and any visual-review findings.
Fail case: blank fields, awkward photo proportions, unsupported request.
Actual output / evidence link:
Human decision:
Corrections:
Outcome (accepted / corrected / stopped / failed):

FINANCE — REMINDER PREPARATION
Input: DEMO-104; original balance $1,200; $900 paid; $300 remaining; no reply.
Expected: current remaining balance in a draft; human approval before sending.
Then test paid status, a customer reply and unavailable payment-status access.
Check the appropriate stop/escalation and any records from an interrupted run.
Actual output / evidence link:
Human decision:
Corrections:
Outcome (accepted / corrected / stopped / failed):

BEEP BEEP — REPLY HANDOFF
Input: Within an approved campaign, a prospect asks about CRM compatibility.
Expected: interested conversation surfaced to a person; routine follow-up to
that recipient stops while the person takes over. No autonomous negotiation.
Also test an unsubscribe and an ambiguous 'ask after our review' reply.
Check routing, contact state and what remains scheduled.
Actual output / evidence link:
Human decision:
Corrections:
Outcome (accepted / corrected / stopped / failed):

3. YOUR ACCEPTANCE CASES
For each: write input + expected behavior BEFORE running it.
Normal supported request:
Missing data:
Conflicting or changed source record:
Duplicate input / retry:
Unavailable connection:
Unsupported request:

Record the actual output, source link, reviewer decision and failure reason.
Keep unsupported requests separate from failures on supported requests.
Do not treat an unreviewed result as a successful completion.

4. MEASURE HUMAN WORK
Use the same completed-item definition before and after.
Observed date range:
Items completed:
Manual hands-on minutes:
Assisted review minutes:
Extra correction minutes (beyond review):
Upkeep minutes:
Net minutes released = manual - review - extra correction - upkeep:
Elapsed time, including waiting (record separately):
One-time setup minutes (record separately):
Accepted unchanged:
Needed correction:
Stopped appropriately:
Failed on a supported task:

Illustrative arithmetic only:
30 items x 8 manual minutes = 240 minutes.
30 reviews x 2 minutes = 60; 6 extra corrections x 5 = 30; upkeep = 20.
Net: 240 - 60 - 30 - 20 = 130 minutes, or 2 hours 10 minutes per week.
At an illustrative 360 setup minutes, time recovery is 360 / 130 = 2.77 weeks.
Replace these assumptions with observations. They are not customer results.

5. DECIDE THE NEXT STEP
Which cases passed, and where is the evidence?
Which stopped correctly?
What must be fixed before expanding access or volume?
Who approves that expansion?
When will you review the workflow again?