Operator Stack
Workflow May 31, 2026 published

Write the SOP Before Building an AI Automation

A practical checklist for turning a messy repeated task into a reviewable AI automation scope.

Start With the Current Task

An AI automation project should begin with the task as it works today, not with a tool choice. Write the standard operating procedure first. The SOP does not need to be formal. It only needs to show what happens, who owns each step, what inputs are used, and what output is acceptable.

This prevents a common failure: automating a vague process and then discovering that every run needs manual judgment anyway. A clear SOP turns the project into a narrow workflow that can be tested, reviewed, and improved.

Capture the Trigger

Every useful automation starts with a trigger. Write down the exact event that starts the work:

  • A client sends a completed intake form.
  • A CSV export arrives every Monday.
  • A folder receives new invoices.
  • A support inbox receives a tagged request.
  • A content draft is approved for repurposing.

Avoid triggers such as “when there is time” or “when someone remembers.” Those are operating problems, not automation triggers. If the start condition is unclear, fix the operating rhythm before building.

Define the Inputs

List the input files, fields, and permissions before adding AI:

  • File names or source systems.
  • Required columns or answer fields.
  • Optional fields that can be blank.
  • Fields that often change names.
  • Access method, such as export, shared folder, or documented account permission.
  • Data that must not be pasted into a public model or stored in a repo.

This step is where many small automations become safer. The SOP should make credential boundaries explicit. Do not ask a client or teammate to put passwords, private tokens, or raw customer secrets into a spreadsheet, prompt, or repository.

Separate Deterministic Work From AI Work

Use deterministic steps for math, matching, formatting, and file movement. Use AI where language or judgment is useful.

Good deterministic steps:

  • Rename columns.
  • Remove duplicate rows.
  • Calculate totals.
  • Match IDs.
  • Generate a dated folder.
  • Build a standard report shell.

Good AI-assisted steps:

  • Summarize support themes.
  • Draft follow-up questions from intake answers.
  • Rewrite a report summary in plain English.
  • Classify free-text notes into review buckets.
  • Suggest risks for a human reviewer to confirm.

The SOP should state which steps are allowed to be AI-assisted and which must remain formula-based, scripted, or manually reviewed.

Write the Acceptance Check

Before building, define what a correct run looks like. A useful acceptance check is specific enough that another operator can say pass or fail.

Examples:

  • The report includes the same total row count as the source export.
  • The summary names the reporting period.
  • The draft email includes no unsupported pricing or legal claim.
  • The output file is saved with the client name and date.
  • The human reviewer can see the source file used for each final output.

If the output cannot be checked, the automation cannot be trusted. Add the review step to the SOP instead of pretending the workflow is fully automatic.

Build the Smallest Version

The first version should automate one narrow path:

  1. One trigger.
  2. One input package.
  3. One output.
  4. One review checklist.
  5. One fallback path when the input is incomplete.

Do not start with every exception. Capture exceptions in the SOP as “manual handling” until they repeat often enough to deserve automation.

Add a Failure Path

A human-out-of-loop system still needs a safe stop condition. The SOP should say what happens when the automation cannot continue.

Use plain rules:

  • Stop if a required file is missing.
  • Stop if a source URL fails.
  • Stop if a private credential is requested.
  • Stop if the AI output makes a claim that is not supported by the input.
  • Leave the artifact in review when a disclosure, source, or quality check fails.

This is how an automation stays useful without becoming reckless. The goal is not to remove every human decision. The goal is to make the machine do the repeatable work and stop cleanly when the decision is not safe.

Turn the SOP Into an Offer

Once the SOP runs reliably, it can become a service, template, or internal operating asset. Package the useful layer:

  • A short setup checklist.
  • Example inputs.
  • The review checklist.
  • The failure rules.
  • A note explaining what the automation does not do.

Strong automation products are specific. “Turn weekly exports into a reviewed client report” is clearer than “save time with AI.” Keep the claim tied to the workflow the SOP actually supports.