Automation Strategy

Automation strategy — decide whether, where, and how before anyone builds

This is the discipline layer of the automation suite. It answers three questions that come before the first node is wired: should this be automated at all?, on what platform, and is a platform even the right tool vs code?, and what orchestration guarantees does every automation have to meet so the fleet doesn't rot? No platform API, no importable JSON, no code lives here — the moment the decision is made, you route to the skill that builds it.

Building the flow (design + importable artifact) → ../automation-flows/SKILL.md. Driving a specific platform's live API/MCP → ../n8n/SKILL.md, ../make/SKILL.md, ../zapier/SKILL.md, ../power-automate/SKILL.md. A typed API client in code → ../api-connector-builder/SKILL.md. Receiving webhooks in your own app → ../webhooks/SKILL.md.

Every fact about pricing and platform capability below moves fast. Treat the ≈ figures as hedges and re-check the vendor page at author time; the honest limits (Zapier can't create Zaps via public API; Power Automate can't create end-user "My flows" cleanly via API) are called out where they matter and expanded in the references.

1. Should you automate at all?

Most "we should automate this" instincts are wrong — not because automation is bad, but because the process underneath isn't ready, or the payoff isn't there. Gate on four factors, all of them, before writing a line:

• Frequency — how many times per week/month does this run? A once-a-quarter task rarely earns its maintenance cost.
• Time saved per run — minutes of human toil removed each time. Two minutes × 1,000 runs beats an hour × 3.
• Error rate of doing it by hand — high manual error rate (typos, missed steps, missed SLAs) is often a bigger win than the time saved. Automation's real product is consistency, not just speed.
• Stability of the process — how often do the steps, the systems, or the rules change? An unstable process is the one thing that turns automation into a liability.

Rough gate: automate when it is frequent AND stable AND either saves meaningful time-per-run or removes a costly manual error rate. If it's frequent but unstable, or high-value but requires judgment on every run, do not automate yet — see below. Full scoring rubric with worked numbers: references/automate-decision-and-roi.md.

The trap: automating a broken or unstable process

Automating a bad process just makes you produce bad output faster, and now nobody can see the badness because a machine hides it. Fix and standardize the process first, then automate the standardized version. If the steps aren't written down the same way twice, if it "depends", if three people do it three ways — you are not ready. Standardize on paper, run it manually a few times against the written steps, then encode it. Automating chaos gives you automated chaos with a maintenance bill.

Human-in-the-loop: what you deliberately do NOT fully automate

Some steps should stay manual by design, wrapped in an approval gate rather than removed:

• Judgment calls — pricing exceptions, hiring decisions, content that carries brand/legal risk, anything where "usually right" isn't good enough.
• Irreversible or high-blast-radius actions — sending money, deleting data, emailing your whole list, publishing publicly, terminating accounts. Automate the preparation, require a human click for the commit.
• Low-frequency, high-stakes — the payoff is small and the cost of a silent wrong run is huge.

The pattern is assisted, not autonomous: the automation gathers, drafts, and stages; a human approves the commit. Cheap insurance against the day the automation is confidently wrong at scale.

2. ROI and build-vs-buy

Payback math

build cost      = hours to build  × loaded hourly rate
monthly saving  = (runs/month × time saved per run × loaded rate)
                  − monthly platform/run cost
                  − monthly maintenance cost   ← the line people forget
payback (months)= build cost / monthly saving

Two rules of thumb: if payback > ~12 months, the process is probably too rare or too cheap to bother; if maintenance eats > ~30–50% of the gross saving, you've built a pet, not a tool. Maintenance is not optional — APIs change, auth expires, edge cases surface. Budget it explicitly or the ROI is fiction. Worked examples: references/automate-decision-and-roi.md.

No/low-code platform vs custom code

The honest middle: platforms win on time-to-first-version and readability; code wins on complex logic, testability, and cost at scale. Many mature setups are hybrid — a platform orchestrates and a small custom service (or api-connector-builder client) does the hard part.

Total cost of ownership

TCO is not the sticker price. Count: the platform bill under your real volume and its billing unit (this is where surprises live — see §3), build time, ongoing maintenance, the cost of an outage when it fails silently, and the switching cost if you outgrow the platform. A "free" automation that a senior engineer babysits monthly is not free.

3. Platform selection

Pick on billing unit first — it's the axis that dictates cost at scale, and choosing on familiarity instead is the classic 10× mistake. Then filter on data residency, ecosystem, programmatic maturity, and portability. This is a routing decision: once chosen, hand off to that platform's skill.

Routing shortcuts: already living in Microsoft 365 → Power Automate (../power-automate/SKILL.md). Data must stay on your own infra, or high volume where execution-billing wins → n8n (../n8n/SKILL.md). Obscure app, non-technical owner → Zapier (../zapier/SKILL.md). Deep per-app modules, mid volume → Make (../make/SKILL.md).

Two capability limits to state honestly, not paper over: you can drive Zapier's actions programmatically and via MCP, but you cannot create a Zap through a public API — Zap authoring is UI-only. Power Automate exposes flow management and solution deployment, but there is no clean public API to author an end-user's personal "My flows". If a plan depends on API-creating either, the plan is wrong. Full matrix, MCP notes, and caveats: references/platform-selection-matrix.md.