# Existing tools or custom workflow: decision worksheet

Compare the complete task before buying another tool or commissioning a build. Fill this in with the person doing the work, its reviewer, and the person responsible for tool access. Unknowns are questions to investigate, not reasons to assume a new feature will work.

Business / team: ____________________
Prepared by: ____________________
Date / version: ____________________

## 1. Define the job without a product name

Trigger: ____________________
Frequency: ____________________
Person doing the work: ____________________
Required sources: ____________________
Accepted output: ____________________
Reviewer: ____________________
Next action and its approver: ____________________
How missing or conflicting information should appear: ____________________
Current pain and the evidence for it: ____________________
What the process must preserve: ____________________

## 2. Check the approved options

Do not assume a feature exists in the team's account because it appears in a demonstration. Ask the administrator to verify the selected account and task.

| Tool / process option | Exact plan or account | Relevant capability checked in current documentation | Access or settings owner | Unresolved requirement |
| --- | --- | --- | --- | --- |
| Current manual process / template | | | | |
| Existing approved tool | | | | |
| Configuration or process improvement | | | | |
| Proposed custom component | | | | |

Permitted material for testing: ____________________
Who authorizes use of that material: ____________________
Source preparation or redaction needed: ____________________
Can an approved export or manual input support an early test? ____________________

## 3. Prepare the same examples for each path

Use permitted examples and keep a reference showing what the reviewer should notice.

| Example | Source material | Required result / important facts | What the reviewer should flag |
| --- | --- | --- | --- |
| Ordinary task | | | |
| Missing important information | | | |
| Conflicting information | | | |

Keep instructions and acceptance conditions documented. If you change the brief or source preparation, repeat the comparison and record the change.

## 4. Record the complete task

Use observed effort where possible. Keep estimates labeled. A fast draft is only one step.

| Option and example | Input preparation | Draft / processing effort | Review and correction | Accepted result? | Important omissions or unsupported claims |
| --- | --- | --- | --- | --- | --- |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |

Can the reviewer verify the important facts? ____________________
Does the output expose missing information? ____________________
Does it respect the approval and action boundaries? ____________________
Where does the largest remaining effort sit? ____________________
What do staff find difficult or avoid using? ____________________

## 5. Name the gap before proposing custom work

Specific unmet requirement: ____________________
Evidence the requirement is unmet: ____________________
Could a better template, source process, or configuration address it? ____________________
Could an existing supported integration address it? ____________________
What would a contained custom component do? ____________________
What would it explicitly leave manual? ____________________

- [ ] Supported access and integration feasibility need to be verified.
- [ ] Drafting, approving, updating records, and sending messages have separate boundaries.
- [ ] A successful output test is not treated as proof that an integration is ready.
- [ ] Adding more sources is not treated as a fix for unreviewable output.

## 6. Compare operating requirements

| Requirement | Current process | Existing tool / configuration | Contained custom workflow |
| --- | --- | --- | --- |
| Setup effort | | | |
| Software and usage charges to verify | | | |
| Preparation, review, and correction effort | | | |
| Training and instructions | | | |
| Access and account administration | | | |
| Maintenance and retesting | | | |
| Ownership / license terms to confirm | | | |
| Support and fallback | | | |

Separate known terms, observed effort, and estimates. Confirm recurring charges with the actual suppliers and proposal rather than assuming a price.

## 7. Decide what to do next

- [ ] Keep the current process and improve its template or ownership.
- [ ] Use an existing approved tool with a documented review step.
- [ ] Investigate an existing configuration or integration.
- [ ] Scope one custom component around a demonstrated gap.
- [ ] Revise the task or stop because the evidence is insufficient.

Reason for the decision: ____________________
Evidence we have: ____________________
Unresolved question and owner: ____________________
Next test or investigation: ____________________
Decision reviewer and date: ____________________

## 8. Assign continuing ownership

Instruction and source owner: ____________________
Access and account owner: ____________________
Maintenance and support owner: ____________________
How staff report an issue: ____________________
Fallback when the tool is unavailable: ____________________
What we retain if changing tools or providers: ____________________

Further reading: [UK Government AI Playbook — specifying requirements](https://www.gov.uk/government/publications/ai-playbook-for-the-uk-government/artificial-intelligence-playbook-for-the-uk-government-html#specifying-your-requirements). It is public-sector guidance; this is an original small-business decision worksheet, not a procurement requirement.

Bring the task and what you have tried to a free 30-minute AI consultation with John Rice. Further planning, training, or implementation is separately scoped paid work.