The short version
- Choose one repeatable task with clear inputs and an accountable reviewer.
- Reverse the effort and risk scores so harder, riskier work does not score higher.
- Record current handling time, exceptions and errors before testing.
- Download the scope worksheet and define what the automation must never do.
For a small business, a useful first automation has a narrow job: take a known input, produce a checkable output, and give a person a clear place to review exceptions. Use the scoring method below to compare ideas, then complete the worksheet before choosing tools.
Score every candidate on four axes
Rate each factor from 1 to 5 using the same scale across your candidate processes:
- Volume (V): 1 means infrequent work; 5 means frequent, repeated work. Record the actual weekly count beside the rating.
- Rule clarity (C): 1 means judgement varies by case; 5 means the desired output and exceptions are clearly documented.
- Effort (E): 1 means a small, accessible input and output; 5 means substantial integration, permissions or process changes.
- Risk (R): 1 means a recoverable internal error; 5 means a mistake could cause serious customer, financial or operational harm.
Priority score = V + C + (6 − E) + (6 − R). Scores range from 4 to 20. A higher number suggests a better starting candidate under your assumptions; it does not predict savings or override a serious risk.
For example, ratings of V=4, C=4, E=2 and R=2 produce 16/20. These are illustrative ratings, not a benchmark. If two ideas score similarly, prefer the one with a clearer reviewer and easier rollback.
Check the starting point
Volume helps only when the task is worth doing and its output can be checked. Remove unnecessary steps before automating them. Pause any candidate with unresolved data permission, unavailable system access or no accountable reviewer, regardless of its score.
Consider whether a simple rule or template can do the job before adding AI. Use AI where variable language or documents require interpretation, and test its mistakes explicitly. Our use-case guide gives candidate workflows to evaluate.
Write the baseline down first
Record a representative period, item count, handling time, rework, exceptions and response time. Distinguish measured values from estimates. Compare the same type of work after testing, including human review, maintenance and tool costs. See the automation ROI guide for the measurement plan.
Workflow scope worksheet
Complete one copy per candidate. Download the editable plain-text worksheet or copy the prompts below into your own document. No email or sign-up is required.
- Job and owner: What single task should change, and who decides whether the output is usable?
- Input and trigger: What starts the work? Specify one source, file format and the minimum fields needed.
- Output and destination: Describe the exact result and where a reviewer will see it.
- Rules and exceptions: List categories, approved guidance, missing-data cases and cases that must stop for a person.
- Human review: Name the role that checks the output, resolves ambiguity and performs any customer-facing action.
- Data and access: Confirm permission to use samples, redact unnecessary personal data and check connector availability. Record unresolved requirements.
- Baseline and acceptance: Set a test period, sample set and pass/fail criteria before testing. Include wrong outputs and review time.
- Boundaries and fallback: State prohibited actions, the stop condition and how the existing manual process resumes.
Worked example: support intake to a review queue
Illustrative scope only. This is a fictional sample, not a customer deployment, live integration or measured result.
Input: a sample request says, “Please send a copy of my invoice.” A permitted input record contains a request ID and redacted message text. The example does not assume access to billing records.
Transformation: assign a suggested category, billing enquiry; create an internal summary and a draft acknowledgement using approved wording; flag anything missing or ambiguous for review.
Output: a review item containing the request ID, suggested category, draft, missing-information note and reviewer role. A person checks the category, identity-verification needs and wording before acting in the existing support system.
Boundary: no automatic customer reply, invoice lookup, refund or account change. The customer team performs any approved external action. Connector feasibility, access and data handling must be validated before implementation.
Test: include routine messages, mixed requests, empty inputs and messages that try to override the approved process. Record category errors, missing-information flags, draft edits and total handling time. Define acceptable error levels with the process owner; do not choose a success threshold after seeing the results.
For the next design step, use the support-agent permission-contract example to define allowed actions, the queue and retry guide to plan recovery, and the inference startup test guide to check how long the workflow takes after a restart. These are illustrative planning guides, not customer deployments.
Decide whether to test
Proceed with a limited test only when the input is permitted, the output is checkable, a reviewer is assigned and the manual fallback works. Keep unresolved items visible in the worksheet. Stop or redesign if reviewing and correcting the output costs more than the work it removes.
CompileSquad offers remote AI workflow automation for small businesses, including support intake and document-processing workflows. Discuss one workflow with CompileSquad using a short, non-sensitive summary of your completed worksheet.
Frequently asked
Should our first automation be our biggest problem?
Usually not. Your biggest problem is often the hardest and riskiest to automate, a bad place to learn. A high-volume, lower-stakes process gives you a faster, safer win that builds the confidence to tackle the big one later.
How do we know if a process is too complex to automate first?
If you cannot describe its rules clearly, or every case seems to be an exception, it is too ambiguous for a first project. Start with something you could almost write down as a checklist.
