A founder can lose a month trying to automate a business before identifying a single task worth automating.

The demo looks persuasive. A tool summarizes a meeting, drafts an email and suggests a sales plan. But the demonstration leaves out the work you will actually pay for: collecting inputs, checking answers, correcting errors and deciding who is allowed to act.

The first useful AI workflow should fit on one page. This edition helps you choose it.

Welcome to AI Operator Weekly. Each issue will examine one business workflow, give you a usable method, and make the evidence clear. The opening examples are illustrative. We will identify measured results when we have them.

Begin with the queue you already have

Write down three tasks that recur every week. Good candidates have a clear beginning and end: turning an inquiry into an internal summary, drafting a reply from an approved policy, or converting meeting notes into a checklist.

“Help with sales” is too broad. “Turn a new inquiry into a draft brief containing the customer's request, deadline and unanswered questions” is specific enough to test.

Choose work where you can inspect the answer. If nobody can tell whether an output is correct, a convincing paragraph can create more work than it removes.

For a first pilot, keep money movement, account changes, legal commitments and customer promises outside the model's permissions. This is a practical way to make errors inexpensive to catch. Expand permissions only after you have evidence and a recovery procedure.

Use five questions to narrow the choice

Give each candidate zero, one or two points on each question:

  1. Frequency: Does it happen rarely, weekly, or almost every working day?
  2. Input consistency: Are the inputs improvised, partly structured, or reliably structured?
  3. Judgeability: Is correctness subjective, partly checkable, or easy to check against a source?
  4. Containment: Could an error escape immediately, require substantial repair, or remain an internal draft?
  5. Ownership: Is responsibility unclear, shared, or assigned to one person who can review and stop the workflow?

The score is a discussion aid, not a validated prediction of success. Reject a candidate with no accountable owner or no safe review boundary even if its total is high. Among the remaining candidates, investigate the highest score first. Then check volume and real time spent.

A frequent two-minute task can be a better first experiment than an impressive task performed twice a year.

A worked example: preparing lead briefs

Consider a hypothetical five-person service business receiving 40 inquiries a week. Someone currently spends 12 minutes on each inquiry reading the message, writing a brief and identifying missing details.

The proposed workflow is narrow:

  • Input: the inquiry and a short, approved description of the services.
  • Output: a draft brief with request, timing, missing information and a source excerpt for each factual claim.
  • Owner: the person already reviewing inbound inquiries.
  • Boundary: no customer email, quote or CRM change without that person's approval.
  • Fallback: use the existing manual process when input is unclear.

Assume review takes four minutes per inquiry, setup takes 90 minutes, and weekly maintenance takes 30 minutes.

The current process takes 480 minutes a week. Review takes 160 minutes. After maintenance, the apparent recurring saving is 290 minutes. In the first week, subtract setup too: 200 minutes.

These are assumptions, not results. If review actually takes 11 minutes, the recurring saving falls to just 10 minutes after maintenance. A fast draft would have hidden a weak business case.

Use this calculation:

Net time saved = baseline handling time - AI handling and review time - repair time - maintenance time.

Track setup separately so it does not disappear from the first month's economics. Include tool fees before deciding whether a small time saving is worth buying.

Your one-page workflow worksheet

Copy and fill this in before choosing a tool:

  • Task: When ___ arrives, we currently ___.
  • Volume: ___ items per week, based on ___.
  • Baseline: ___ minutes per item, measured across ___ ordinary examples.
  • Approved inputs: ___.
  • Required output: ___.
  • Correctness check: The reviewer compares ___ with ___.
  • Owner and reviewer: ___.
  • Allowed actions: ___.
  • Actions requiring approval: ___.
  • Failure route: Return to ; record the reason in .
  • Pilot success: ___ net minutes saved, with ___ acceptable error rate and no unapproved external actions.
  • Stopping rule: Pause if ___.
  • Actual result: ___ items, ___ review minutes, ___ repair minutes, ___ maintenance minutes, ___ tool cost.

If you cannot complete the correctness check and failure route, narrow the task before building.

Run a seven-day pilot

Days 1 and 2: Time the existing process. Keep a small set of ordinary examples, including messy inputs. Use information you are authorized to handle, and remove unnecessary personal or confidential details from experimental inputs.

Day 3: Test the draft workflow against those examples. Check omissions and invented details as well as formatting.

Days 4 through 6: Run a small batch in draft mode. Record every review and repair, including failed attempts. Keep the manual fallback available.

Day 7: Compare the whole process with the baseline. Decide to continue, revise or stop. Do not redefine success to fit the result.

A sample of 20 items may reveal obvious friction; it does not establish reliability for every future input. Keep watching the workflow after the pilot.

The decision to make today

Pick one task and write its correctness check. That is your first deliverable.

Next week we will build a baseline log that makes review time and repeat failures visible. Subscribe on this page to receive the next edition, and share which recurring task you are testing in the comments.

Source note: The risk boundary and review approach are informed by NIST's AI Risk Management Framework, particularly its focus on context, measurement and managing risk. The scoring worksheet and service-business example are our original methods and hypothetical arithmetic; NIST has not validated them.

Published by Primus Vekuh. This opening edition has no paid placement or affiliate links.