The operations automation playbook

Most operational drag lives in handoffs. A new customer's details wait in an inbox to be copied into the CRM. A report is rebuilt by hand every Monday. A support ticket sits in a shared queue until someone reads it and decides who should have it. Each handoff is small. Together they set how fast the business can move.

This note describes the method we use to automate that work. It has four steps: measure the work, sort each step by the kind of decision it needs, automate with a person on the steps that write to systems of record, and log every run.

Step 1: measure the work

List the recurring processes, and for each one record how long a person spends on it, how often it runs, and how long work waits before anyone touches it. Take the numbers from the systems where you can: ticket timestamps, CRM history, email received and record created times. Estimates from a workshop are usually wrong in the direction of the work people dislike most.

Here is an illustrative inventory for a small operations team:

In this example the four processes take about 337 hours a month. That is time spent, not time saved. Some of each process stays with a person by design, as the last column shows, and the first automation of any process needs review while it proves itself.

Measure waiting time as well as working time. A step that takes three minutes but waits two days for someone to pick it up is a better target than a step that takes twenty minutes and happens right away.

Step 2: sort every step by the decision it needs

Break each process into steps and give each step one of three kinds:

• Rule. The step follows a fixed rule: copy a field, send a reminder after 48 hours, route by product code. Automate it with plain code.
• Judgment. The step needs reading or interpretation: extract fields from an email, classify a ticket, summarize a call. Use an AI step, and test it against real past cases before it runs.
• Write to a system of record. The step creates or changes something in the CRM, billing, accounting or a customer account. A person approves it, with the context they need to decide quickly.

type StepKind = 'rule' | 'judgment' | 'write';

interface WorkflowStep {
  name: string;
  kind: StepKind;
  // Judgment steps need a confidence threshold; below it, the case goes to a person.
  minConfidence?: number;
  // Write steps always need an approver.
  approver?: 'ops' | 'finance' | 'account-owner';
}

Most handoffs need a rule, not a model. Use AI where a rule runs out, and nowhere else.

Step 3: automate, with a person on the writes

Email to CRM record

Customer details arrive by email and are typed into the CRM by hand.

const emailToCrm: WorkflowStep[] = [
  { name: 'Receive email from the intake address', kind: 'rule' },
  { name: 'Extract name, company, email, phone and request', kind: 'judgment', minConfidence: 0.9 },
  { name: 'Validate fields against the CRM schema', kind: 'rule' },
  { name: 'Draft the CRM record and check for an existing match', kind: 'rule' },
  { name: 'Create or update the CRM record', kind: 'write', approver: 'ops' },
  { name: 'Notify the account owner', kind: 'rule' },
];

The approver sees the source email and the drafted record side by side, and approves, edits or rejects it. Reviewing a drafted record is much faster than typing one, and nothing reaches the CRM without a person seeing it. Edits and rejections are saved, and they become new cases for the extraction step's evaluation set.

Reports

Pull every figure from a query against the source systems. If the report includes a written summary generated by a model, check every number in the summary against the query results before it is sent, and send it to a reviewer first until the checks have held for a while.

def weekly_report():
    metrics = run_queries(["revenue", "new_accounts", "churned_accounts", "open_tickets"])
    summary = draft_summary(metrics)            # optional AI step
    check_figures(summary, metrics)             # every number in the text must match a query result
    send_for_review(build_report(metrics, summary), reviewer="ops-lead")

Ticket routing

A classifier reads each new ticket and assigns a queue and a priority. Routing does not change a system of record, so once the classifier has been tested against a few hundred past tickets it can run on its own. Tickets below the confidence threshold go to a person to route, and every misroute that agents correct is recorded and added to the test set.

Customer onboarding

When a deal is marked won, the workflow drafts everything onboarding needs: the account, the project, the welcome email and the kickoff invitation. Creating the customer account and issuing credentials are writes, so a person approves them from a prefilled form. Reminders, follow-ups and the check-in schedule after that are rules and run on their own. If any step is stuck for more than 48 hours, the workflow alerts the owner.

Step 4: log every run and plan for failure

Automations fail: an API times out, a field arrives empty, a system is down for maintenance. Build for that from the start.

• A log of every run: what triggered it, what each step did, who approved what, and how long each step took.
• Retries with backoff for temporary failures, and idempotency keys on writes, so a retried step never creates the same record twice.
• A queue for failed runs that a person reviews, instead of failures that disappear.
• Alerts on stuck work, measured against the waiting times from step 1.

Choosing tools

There is no single right tool. The choice depends on volume, how failures must be handled, whether the workflow writes to a system of record, whether you need an audit trail, and who will maintain it.

• No-code workflow tools such as Zapier, Make and n8n suit small handoffs between systems with standard connectors, at modest volume, where a failed run is easy to notice and redo by hand.
• Workflow engines such as Temporal, and schedulers such as Airflow, suit long-running processes with many steps, retries and state that must survive restarts.
• Custom code suits business rules that don't fit a connector, high volume, strict security requirements, or writes to systems of record that need approval steps and an audit trail.

Many companies use more than one. What matters is that every workflow, whatever it runs on, is measured, logged and has a person on the steps that write.

Common mistakes

• Automating a broken process. Fix the process first. Automation makes a bad process fail faster.
• Automating the wrong step. If the delay is in waiting rather than working, a faster step changes nothing.
• Letting automation write to systems of record unreviewed. A wrong record in billing or the CRM costs more to find and fix than it saved.
• No run log. Without one, nobody can say what the automation did, or why.

How we do this

Our Workflow automation platform follows this method: it measures where work waits, runs scheduled jobs and event-driven workflows, adds AI steps only where a rule can't do the job, puts a person on any step that writes to a system of record, and logs every run. It starts with a one-week audit, and the platform runs on your real data within 90 days of the audit.