Operations and SOP Prompts

You cannot automate, delegate, or scale a process you have not specified

Gartner predicted in June 2025 that more than 40% of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. Its assessment of the current crop was blunt: most are early-stage experiments driven by hype and often misapplied.

That prediction is a useful lens on operations generally, because the failure it describes is not really about AI. It is what happens when you try to automate a process nobody ever wrote down. The automation project becomes a specification project halfway through, discovers that the process has undocumented branches and three exceptions everyone handles differently, and dies over budget.

The same logic applies to every form of leverage. You cannot hand a process to a new hire, an agency, a vendor, or a model until you can state what it does, what correct means, and what happens when it goes wrong. Specification is not paperwork you do after the fact. It is the prerequisite for every way of getting a process off your desk.

So the editorial rule for this pack: every prompt produces an artifact that outlives the conversation — an SOP, a process map, a runbook, a decision record, a check. Nothing here ends with advice.

Write it down, then look at it

Write an SOP for Something Only You Know How to Do is the entry point, and the title is the diagnostic. Every business has several of these, and each one is a constraint on growth and a risk sitting on one person's shoulders.

Map a Process Before You Try to Fix It comes before any improvement work. The map almost always reveals that the real process differs from the official one — including the workarounds people invented, which usually encode a real constraint nobody documented.

Find the Bottleneck That's Limiting Your Output applies the one piece of operations theory that pays for itself immediately: improving anything other than the constraint produces no additional output at all. Most improvement effort goes to whatever is most visible or most annoying, which is rarely the constraint.

Cut the Time a Process Takes Without Cutting Corners attacks wait time before work time, because in most processes the elapsed duration is dominated by handoffs and queues rather than by anyone working slowly.

Work Out Your Real Capacity Before You Promise a Deadline prices commitments against actual available hours rather than theoretical ones, which is the difference between a plan and a hope.

Decide what to automate, buy, or leave alone

Decide What to Automate and What to Leave Alone is where the Gartner finding becomes operational. It works through frequency, stability, error cost, and — critically — whether the process is specified well enough to automate at all. A high-variance process with unclear success criteria is the one that generates a cancelled project.

Decide Whether to Do It In-House or Buy It In covers the build-versus-buy question with the ongoing costs included, which is where most of these decisions go wrong.

Choose Software or a Vendor Without a Six-Month Evaluation is scoped to proportionality: the evaluation should cost less than the decision is worth, and most do not.

Renegotiate a Vendor Contract Before It Auto-Renews is the highest-return prompt here per minute spent. Auto-renewal is a pricing strategy that depends on you not diarising the notice date, and the leverage exists only before it passes.

Most operational failure is a repeat

The second thread: when something goes wrong, the fix usually lands on the instance rather than the condition. The order gets corrected, the customer is apologised to, and the thing that produced the error is untouched — so it produces another one next month, and the organisation experiences a permanent background rate of preventable failure that everyone has stopped noticing.

Fix a Problem That Keeps Coming Back is built to break that pattern by separating the instance fix from the condition fix and requiring both.

Build a Quality Check That Catches Errors Before Customers Do puts the check where it is cheapest — as close to the point of creation as possible, since the cost of an error rises with every step it survives.

Write a Runbook for When Something Breaks produces the document you cannot write during the incident. Run a Post-Incident Review Without Blaming Anyone makes the review produce changes rather than a narrative, and is blameless for a practical reason rather than a cultural one: people who expect blame withhold the information the review needs.

Find the Single Points of Failure in Your Business is the audit worth doing annually — the person, system, supplier, or account whose absence stops everything, most of which are invisible until they are not.

Shared with other packs

Several prompts here are operations problems that live in other domains. Decide Which Customers Get a Human and Which Get a Playbook is a capacity-allocation decision from customer success. Set Deal Registration Rules That Prevent Channel Conflict, Build Partner Enablement That Survives Their Sales Team and Design a Partner Tier Structure Worth Climbing are governance artifacts from partnerships. Build a Program Budget That Includes What It Really Costs and Build a Volunteer Program That Doesn't Burn People Out come from nonprofit, where the specification discipline matters more because the labour is voluntary.

Where this stops

These prompts produce drafts for your judgement. An SOP for regulated work, a runbook touching personal data, or a quality check in a safety-critical process needs review by whoever carries that responsibility in your organisation. Vendor contract terms — liability, indemnity, termination, data processing — are commercial-legal questions, and the renegotiation prompt covers leverage and economics rather than clause language.

Sources

• Gartner, Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027, June 2025