Field notes. John Arndt, Soxoa. Published .Written November 2026 as a planning guide for 2027. It will be revised when its facts are re-checked.
Plan 2027 one workflow at a time. Pick one frequent, checkable workflow with a named owner, measure how it runs today, run a bounded pilot against stop criteria written before it starts, and decide at the end of each quarter whether to expand it, change it or stop.
Most of the choosing happens in the last weeks of 2026, the pilot and the decision happen in 2027, and a second workflow comes only after that. The guide does not forecast which AI tools will exist next year or what they will cost; the method does not depend on those answers.
Why one workflow, not a strategy deck
A list of twelve AI initiatives spends attention on twelve things nobody has measured. One workflow measured before and after gives you a number you trust, an owner who has run a pilot, and a decision you can repeat. The question is not which tool but which piece of recurring work you will measure, and who owns the result.
Before January: choose the first workflow
Five steps, all of them possible in the last weeks of 2026 without buying anything.
List the recurring work
Write down the work your team repeats every week: what starts it, what it produces, who does it and roughly how often. The audit method covers how to collect this. Aim for a list you can read in five minutes, not a process catalogue.
Screen it with five tests
Countable volume, a named owner, examples you are allowed to share, a mistake you can catch before it does damage, and a result you can measure. The first workflow guide explains each test and the three candidates not to start with.
Score two candidates over the same weeks
Score frequency, variability, exception rate and ownership for your top two. For a second view, the free Soxoa MCP planning tools include prioritize_automation_workflows, which ranks up to twelve candidates you describe and suggests automate, assist or discovery. The tool itself says to treat its score as a discovery aid, not a promise.
Mark what stays manual
Before anything is built, mark the steps that stay human and say why: rare cases, judgment with consequences, anything irreversible. A leave it manual mark with a revisit date is a design decision, not a gap.
Name the owner, the reviewer and a backup
The owner runs the workflow after the pilot and can pause it. The reviewer checks outputs during the pilot. In a small company they can be the same person; write the names down anyway, with a backup for each.
Quarter 1: measure the baseline
Build nothing until the current process is measured. Two typical weeks is a starting sample; extend it if those weeks miss a monthly peak or an input type you see often. The automation assessment worksheet keeps the record in one place.
- Runs
- How many times the workflow ran, counted rather than estimated.
- Time per run
- Minutes from start to accepted output, including waiting if waiting is the problem you want to solve.
- Exceptions
- Runs that left the normal path and needed someone to handle them by hand, as a count and a percentage.
- Errors caught
- Mistakes found at review or later, and where they were found.
- Turnaround
- Time from trigger to finished output, if a customer feels the delay.
Quarter 1: write the bar and the stop criteria
Before the pilot starts, write the acceptance bar: the test the pilot must pass on real, approved examples, agreed by the owner. Then write the stop criteria: the conditions under which the pilot ends early, whatever anyone feels about it at the time. Criteria written after the results arrive tend to be chosen to fit them.
Stop criteria worth writing down:
A boundary is crossed
Any output reaches a customer, a record or a payment without the approval step the design requires. One occurrence is enough.
Corrections stay high
Reviewer corrections stay above the level the owner set, after the settling period the owner set.
Review costs as much as doing
Checking a draft takes about as long as doing the work by hand, so the pilot moves effort without saving it.
Exceptions swamp the reviewer
Exceptions exceed what the named reviewer can handle in the hours agreed.
The work changes underneath it
The process, the source system or the rules change during the pilot, so the baseline no longer describes the same work.
Quarter 2: run a bounded pilot
A bounded pilot has limits you can state in one breath: one workflow, a fixed period or number of cases, a named reviewer who sees every output, no irreversible action without recorded approval, and a person who can pause it and fall back to the manual process the same day.
Run it on approved examples, or on live work with review on every item. Record each case: the input, the draft, the reviewer's decision, the correction if any, and how long the review took. That record is what the end of the pilot rests on.
The build_workflow_pilot tool in the same planning tools turns a workflow you describe into proposed steps, review gates, acceptance checks and a Markdown plan, and flags the tools and connections it proposes for you to verify. It does not connect to your systems or run the workflow. The free workflow check gives you a one-page blueprint after you talk through one real process.
If the next step genuinely depends on what the work uncovers, read agentic AI vs workflow automation before choosing an agent, and compare it with a fixed workflow that has one AI step inside it.
Quarter 3: decide, then operate or stop
Put the pilot record next to the baseline and make one of three decisions, in writing.
- Expand
- The pilot met the bar, no stop criterion fired, and the owner wants it. Move it into normal operation with the same review, then reduce review only where the record supports it.
- Change and re-test
- It came close and the record shows why it missed, for example one input type that fails. Narrow the scope or fix that cause, then run a shorter pilot against the same bar.
- Stop
- It did not clear the bar, or a stop criterion fired. Write down what was tested, by how much it missed and what would have to change. A stop decision is a result, and the written record saves the next candidate from repeating the same test.
Operating it for the rest of the year
A workflow that continues needs a named owner, a monthly look at cost and accepted output (the monthly cost guide sets out what to track), and a re-test whenever the model, the vendor, the source system or the business rules change. Keep the approved examples from the pilot: they are your regression test.
Quarter 4: the second workflow and the 2028 list
Choose a second workflow only if the first is operating with an owner, or has been stopped with a written reason. Re-run the inventory: you now know what review actually costs in your organization.
Use the year's records to build next year's budget. The 2027 budget guide sets out the cost lines and how to set them against the hours a workflow takes. Then plan 2028 the same way, one workflow at a time.
A worked example: order changes at a distributor
A fictional 60-person distributor receives customer emails asking to change an open order: a quantity, a delivery date, an address. Today a customer service rep reads each email, finds the order, checks whether it has shipped, makes the change and replies.
Before January, the operations manager lists eight recurring workflows and screens them. Order changes pass all five tests: the inbox gives a count, the customer service lead will own it, past emails can be used once customer details are redacted, a wrong change is visible in the order system before it ships, and time per request can be measured.
In the first quarter the team logs two weeks: 180 change requests at an average of 7 minutes each, and 27 that needed a supervisor because the order had shipped or the request was unclear. That is 21 hours of handling in two weeks and an exception rate of 15%.
The lead writes the bar: on 60 approved past emails, the draft identifies the right order and the requested change in at least 55, and every draft that would touch a shipped order goes to a supervisor. The stop criteria: any change written to the order system without a rep's approval; corrections on more than one draft in five after the fourth week; review averaging more than 4 minutes a request.
In the second quarter the pilot drafts the change and the reply, and a rep approves every one before anything is written or sent. In the third quarter the team sets the record beside the baseline. If review averaged 3 minutes and corrections stayed under the limit, they expand to all reps, still reviewing every item. If corrections stayed above one in five, they stop, record which request types failed, and leave order changes manual for now. The figures are invented, not a prediction of what any pilot will achieve.
Doing it yourself or getting help
Soxoa publishes this guide and sells consulting that covers parts of this plan, so weigh this section with that in mind.
- On your own
- Self-serve automation tools can handle simple, low-stakes connections without paying anyone. The DIY tools comparison says when that is the right call.
- Hiring
- If the work needs human judgment or presence every day, a person may be a better answer than automation. See automation vs hiring.
- Soxoa
- A Live Build Workshop is one day with your team: you map one workflow and build a working automation on approved examples. An AI Build Sprint takes one to three workflows from mapped to operating, with a written stop decision if the evaluation does not clear the bar. A Fractional Chief AI Officer is a named outside AI lead on a monthly engagement. Each of these is quoted after a call (what Soxoa costs); the readiness assessment is free.
What would change this advice
This guide was written in November 2026 and will be revised when its facts are re-checked. The method, or the order of the quarters, would change for you if any of these turn out to be true.
- Your baseline shows the work is rare
- Then it is the wrong first workflow, however irritating it is. Go back to the inventory.
- A tool you already pay for does the job
- If a feature in software you already use handles the workflow with review, test that before building anything.
- Your data rules change
- A new contract, customer requirement or regulation that limits which data can go where changes what you can pilot. The private AI data checklist is the place to start.
- Models or vendors change during the year
- Re-run the pilot's approved examples before trusting the new version. This plan assumes nothing about which models will be available in 2027 or what they will cost.
Common questions
- When should we start planning AI automation for 2027?
- Before January, with the inventory and the choice of the first workflow, so the baseline can be measured in the first quarter. Nothing needs to be bought before the baseline exists.
- How long should an AI pilot run?
- Long enough to cover the normal variety of the work, and fixed before it starts. Write the period or the number of cases into the plan with the stop criteria, and extend it only with a written reason.
- Do we need an AI agent for this?
- Not to start. If you can write the steps and exceptions in advance, a fixed workflow with an AI step inside it is the simpler design. Consider an agent when the next step depends on what the work uncovers.