Field notes. John Arndt, Soxoa. Published .
A team spends hours rekeying invoices. An automation demo extracts the fields in seconds. The proposal multiplies those seconds across the monthly volume and declares the savings.
The proposal still needs to account for checking, corrections, duplicates, exceptions, and the person who owns the result. Those details determine whether the workflow improves the operation or simply moves the work into a different screen.
The scope-automation-opportunity draft Claude skill comes from an invoice-intake engagement kit prepared in October 2026. The completed kit included proposal and statement-of-work templates, a discovery rubric, an acceptance protocol, a delivery playbook, a handoff workbook, and a private fee/capacity model. It was a planning and delivery package. It contained no completed client implementation or measured client savings.
The transferable method is to define one bounded workflow, put evidence around the decision to build it, and specify what a useful result would require.
Walk one ordinary case and one difficult case
Start with the actual trigger, inputs, decisions, tools, handoffs, and output destination. Watch where a person checks meaning or makes a consequential choice. Check whether an existing approved feature or a straightforward import already handles the job.
For invoice intake, an illustrative boundary could be an approved folder, extracted header fields, mandatory human review, and an approved CSV. Payment approval remains with the responsible person. Other workflows need their own boundary; a previous project's file limits or sample sizes should not become universal rules.
The difficult case matters because it reveals the queue behind the demo. What happens when a field is absent, a source conflicts, or the provider fails? Who sees that exception? What can they do next? What is the manual fallback?
Missing ownership or data approval is a hold. A high score elsewhere cannot fill in the missing person who must authorize processing or review the output.
Make the economics include the work that remains
Use observed counts and timings where available. Label estimates clearly. Measure intake, entry, checking, corrections, exceptions, and reconciliation over a stated window.
Here is an illustrative calculation, not a customer result. Suppose 300 monthly items currently require six active minutes each: 30 hours. Assume the proposed process needs two minutes of ordinary work per item, adds five extra minutes for 10% of items, and needs two hours of monthly oversight. That is 14.5 hours, leaving 15.5 hours of potential capacity before implementation effort and software cost.
Those assumptions need testing. Capacity value also differs from cash savings. If no expense disappears, describe the time available for other work instead of claiming money has returned to the bank account.
Run a downside scenario. If review and exceptions consume the apparent benefit, the recommendation may be a simpler process improvement or no build.
Agree acceptance before the demonstration
The pilot brief should name representative inputs, difficult inputs, independent expected results, the candidate version, and pass/fail rules. Report every case, including failures. Keep raw system accuracy separate from output corrected by a reviewer.
Include the operating test: can the designated person handle an exception, explain an approval, and use the fallback? A clean extraction score does not answer those questions.
A sample request:
“Use scope-automation-opportunity on our invoice-intake notes and timing log. Recommend automate, assist, discovery, or stop. Keep payment approval human, include downside economics, and propose a finite acceptance plan. Label every unmeasured assumption.”
The skill can use compatible calculation tools when available, but it does not require a particular vendor. It does not inspect systems, sign an agreement, or implement a workflow by itself. The new package remains untested in Claude.
Start with one workflow and a small set of approved examples. Decide which missing fact would change the recommendation, then collect that fact. An acceptance decision and permission to go live should each be explicit; neither follows automatically from a good demonstration.
Get the skill
scope-automation-opportunity is part of the free Soxoa Ops plugin for Claude. In Claude Code, add the marketplace with /plugin marketplace add johnarndt/soxoa-claude-plugins, then run /plugin install soxoa-ops@soxoa-plugins. You can read the skill on GitHub before installing it, or copy its folder into ~/.claude/skills/.