AI Prompts to Automate Your Operations & SOPs Employees lose roughly 1.8 hours a day searching for information, according to 2026 knowledge management research cited in a guide on using AI prompts to automate operations and standard operating procedures (SOPs). The guide argues that experts cannot self-report their own processes because automatic judgments become invisible, and recommends using AI in interview mode—asking one question at a time—to surface unwritten steps and decision rules. It advises triaging documentation by risk × frequency and testing SOPs by having AI follow them literally as a new starter. AI Prompts to Automate Your Operations & SOPs Short answer: The reason your SOPs don’t exist isn’t discipline — it’s that experts can’t self-report their own processes . Once you’ve done something a hundred times, the judgments that make it work stop registering as decisions, so you leave them out. That’s why “write down how you do X” produces a five-step list nobody can follow. The fix: don’t ask AI to write the SOP. Instruct it to interview you, one question at a time , until it surfaces the steps you perform automatically and the “it depends” rules you’ve never articulated. Then let it write. TL;DR — Key Takeaways Interview mode beats generation mode. One question at a time, waiting for each answer. Ask for a full SOP up front and you get a template. Employees lose roughly 1.8 hours a day searching for information — about 9.3 hours a week — plus more recreating what they couldn’t find 2026 knowledge management research aiops-sources . Don’t document everything. Triage by risk × frequency. The task only one person can do, that happens weekly, is the urgent one. Chase the “it depends.” Every time you say it, there’s an unwritten decision rule. That rule is the SOP. Test the SOP before a human does. Have AI follow it literally as a new starter and report every point it would have to guess. ✔ Best for Founders and operators whose business runs on things only they know how to do, teams preparing to hire or hand over, and anyone whose “documentation” is currently a mix of memory and Slack history. ✕ Skip if You need compliance-grade documentation for a regulated audit start with your regulator’s framework , or you’re evaluating BPM and workflow automation platforms rather than prompts. On this page Why is it so hard to write down a process you do every day? Because expertise becomes automatic, and automatic means invisible. After the hundredth time, the small checks and judgments that make the process work stop registering as decisions. You skip them when describing the task — not through carelessness, but because you genuinely no longer notice them. This is why an expert asked to write a procedure produces a short list a new starter can’t follow, and why the same expert can answer forty specific questions about that process perfectly. The knowledge is there. It just isn’t retrievable by introspection. The cost is measurable and ongoing. Research puts information search at roughly 1.8 hours per day ~9.3 hours weekly , with studies finding employees spend around 21% of work time searching and another 14% recreating information they couldn’t find . A majority report regularly having to interrupt a colleague or book a meeting just to locate what they need. Undocumented process is a tax your business pays every week. Prompt 1 Triage What to document first, by risk × frequency Prompt 2 Extract Interview mode — the flagship Prompt 3 Hand off Turn the SOP into a real transfer Prompt 4 Decide Automate, delegate, or delete The operations context block One reusable block, pasted at the top of every operations prompt. Shorter than the ones in our other guides — operations prompts need situational context more than brand context. OPERATIONS CONTEXT paste at the top of every prompt : BUSINESS: WHAT WE DO, IN ONE SENTENCE SIZE: HEADCOUNT AND KEY ROLES TOOLS WE ACTUALLY USE: CRM, ACCOUNTING, PM, COMMS — name them, since steps depend on the tool WHO DOES WHAT TODAY: BRIEF — especially who is the single point of failure WHY I'M DOCUMENTING: HIRING / DELEGATING / GOING ON LEAVE / SELLING / REDUCING KEY-PERSON RISK READER OF THIS SOP: EXPERIENCED HIRE / JUNIOR / VA / CONTRACTOR — this changes how much you must explain RULES: - Never invent a step, tool, or policy I haven't described. If you need to know something, ask me. - Prefer plain language over process jargon. - If something I describe sounds like two separate processes, say so rather than merging them. The “reader of this SOP” line does more than it looks like. A procedure for an experienced hire and one for a new VA are different documents — most SOPs fail because they’re written for a reader who doesn’t exist. 1. Which processes should I document first? Rank by risk × frequency, and accept you won’t document everything. The task only one person can do, that happens weekly, is far more urgent than a complex process three people already know. Trying to document the whole business at once is the single most common reason these projects stall at 20% complete. PASTE OPERATIONS CONTEXT BLOCK Here's everything that happens in my business regularly: BRAIN-DUMP. Messy list is fine. Include anything you do weekly, monthly, or that clients/staff depend on. Help me triage. Return a table: | Process | Who can do it today | Frequency | | Risk if that person is unavailable H/M/L | | Effort to document H/M/L | Priority score | Then: 1. THE TOP 5 to document first, ranked. Priority = risk × frequency, NOT how easy it is. Say why each made the list. 2. SINGLE POINTS OF FAILURE — every process only one person can perform. Flag any where that person is me. 3. THE INVISIBLE ONES — based on what I've described, what processes probably exist that I forgot to list? Think about: what happens when something goes wrong, who handles exceptions, and what happens at month-end or year-end. 4. DON'T BOTHER — which of these aren't worth documenting, and why. Be willing to say "this happens twice a year and takes ten minutes, just do it." 5. THE UNCOMFORTABLE ONE — which process am I least likely to document because it's tangled, embarrassing, or I know it's broken? Name it. Why it works: point 3 catches the exception-handling processes almost nobody lists — the “what happens when a client complains” or “what we do when a payment fails” work that lives entirely in someone’s head and matters most under pressure. Get the SOP Generator + Template The full interview prompt, a structured SOP template with all seven required sections, the new-hire stress test, and the triage worksheet. Free. Get the template → aiops-lead-magnet 2. How do I use AI to write an SOP? Have it interview you — one question at a time — before it writes anything. This is the flagship prompt of the guide and the single technique that separates a usable SOP from a generic template. The constraint that matters is one question, then wait . Batch the questions and you’ll answer them shallowly. the flagship PASTE OPERATIONS CONTEXT BLOCK I need to document how I do PROCESS NAME so someone else can run it without me. INTERVIEW ME. Ask ONE question at a time. Wait for my answer before asking the next. Do not produce the SOP until I say "done" or you tell me you have enough. Start by asking me to walk through the last time I actually did this — the specific instance, not the general case. Then probe systematically for: - STEPS I DO AUTOMATICALLY and would forget to mention. If I jump from step 3 to step 7, ask what happened between. - DECISIONS I make, and what I base them on. Every time I say "it depends" — STOP and ask exactly what it depends on. Keep asking until the rule is explicit. - WHAT "DONE WELL" MEANS versus merely "done." How would I know if someone did this badly but plausibly? - WHAT GOES WRONG, how I notice, and how I fix it. - WHO ELSE I contact, when, and what I need from them. - WHAT I CHECK before considering it finished. - THE THING I'D WORRY ABOUT if a new person did this unsupervised. Interview rules: - One question at a time. Never batch. - If my answer is vague, ask a follow-up rather than moving on. - Ask for specifics: actual tool names, actual thresholds, actual wording where it matters. - If I mention an exception, chase it — exceptions are where the real knowledge lives. - Don't accept "I just know." Ask what tells me. When you have enough, produce the SOP with these sections: 1. PURPOSE — why this exists, what breaks without it 2. TRIGGER — what starts it, and how often 3. STEPS — numbered, each with the tool used 4. DECISION RULES — every "if X then Y" I described 5. QUALITY CHECKS — how to verify it was done properly 6. COMMON FAILURES — what goes wrong, how to spot it 7. ESCALATION — when to stop and ask, and who to ask Then list every question you still have — the gaps. Why it works: the “chase every it depends ” instruction is the core of it. Those two words are a flag that a decision rule exists in your head and has never been written down. That rule is usually the most valuable content in the finished document — and it’s exactly what a generic SOP template has no way to capture. 3. How do I actually hand a process over? A document isn’t a handover. Giving someone an SOP and assuming transfer has occurred is how processes quietly degrade. The handover needs a sequence, a competence check, and an agreement about what happens when something unusual appears. PASTE OPERATIONS CONTEXT BLOCK THE SOP: PASTE THE DOCUMENT FROM PROMPT 2 HANDING TO: ROLE, EXPERIENCE LEVEL, WHAT THEY ALREADY KNOW ABOUT OUR BUSINESS Build the handover plan: 1. WHAT THEY NEED BEFORE STARTING — access, tools, logins, permissions, context. List everything, because missing access on day one is the most common handover failure. 2. THE SEQUENCE — which parts to hand over first, and in what order. Don't give them everything at once. 3. COMPETENCE CHECK — 5 questions I should ask to confirm they actually understand, not just that they've read it. These should be scenario questions, not recall questions. 4. THE FIRST THREE EXCEPTIONS they'll hit that the SOP doesn't cover. Based on the document, predict where reality will diverge. 5. ESCALATION AGREEMENT — what they should decide alone, what they should flag, what they must never decide without me. Be specific with examples. 6. HOW I'LL KNOW IT'S WORKING — the observable signal, at 2 weeks and at 8 weeks, that this transferred successfully. And the signal it didn't. 7. WHAT I MUST STOP DOING for this handover to be real. Name the specific habit I'll fall back into. Point 7 is the one operators find uncomfortable. Most handovers fail because the original owner keeps doing the interesting parts — and the new owner never fully takes ownership. 4. What should I automate, delegate, or eliminate? Documentation should shrink your workload, not just describe it. Once a process is written down, the obvious next question is whether it should exist at all. A meaningful share of documented steps turn out to serve a reason that expired years ago — a report nobody reads, a check for a problem that was fixed. PASTE OPERATIONS CONTEXT BLOCK THE DOCUMENTED PROCESS: PASTE SOP TOOLS AVAILABLE TO ME: LIST — including whether you have Zapier/Make, your CRM's automation, spreadsheets, etc. Go step by step. Sort EVERY step into one of four: ELIMINATE — this step serves no current purpose. State what would actually break if we stopped. If nothing, say so. AUTOMATE — a tool could do this reliably. Name the specific tool and the trigger. Only if genuinely rule-based. DELEGATE — a person could do this at 80% quality. Name the cheapest role that could own it. KEEP — genuinely requires the current owner's judgment. Rules: - Be sceptical about AUTOMATE. A step needing judgment, exception handling, or relationship context is not automatable, however tempting. Say so plainly. - For anything you mark AUTOMATE, state what happens when the automation fails, and who notices. - Flag any step that exists only because of a past mistake or a person who has left. Then: - What % of this process genuinely needs a human? - What's the ONE change that would save the most time? - What would I be WRONG to automate, and why? ▼ Eliminate Serves no current purpose. The report nobody opens; the check for a bug that was fixed. ◆ Automate Genuinely rule-based, no judgment, no exceptions. Plus: what happens when it breaks? ▲ Delegate A person could do it at 80% quality. 80% by someone else beats 100% by you. ● Keep Needs your judgment, relationships, or accountability. Protect this; it’s the actual job. What separates a good SOP prompt from a bad one? | Move | ❌ Weak prompt | ✅ Strong prompt | |---|---|---| Mode | “Write an SOP for onboarding a client” | “Interview me one question at a time until you could hand this to a new hire” | Source | Model’s generic idea of the process | Your walkthrough of the last actual instance | Judgment | Accepts “it depends” and moves on | “Every time I say ‘it depends’, stop and ask what it depends on” | Structure | Steps only | Purpose, trigger, steps, decision rules, quality checks, failures, escalation | Quality bar | “Document the process” | “How would I know if someone did this badly but plausibly?” | Validation | Write it, file it, hope | Simulate a new hire following it literally; every guess is a gap | The through-line: weak prompts ask the model to generate a process. Strong prompts use the model to extract yours — because the model doesn’t know how your business works, and pretending otherwise is what produces documentation nobody uses. Can you show a real prompt with its actual output? Here’s the extraction interview in action — a studio owner documenting how she quotes projects. Note how quickly it finds knowledge she’d never have written down unprompted. AI Walk me through the last time you actually quoted a project. Not how you usually do it — the specific one. What came in, and what did you do first? You Tuesday. An enquiry came through the website for a brand refresh. I read it, looked at their site, then put together a quote. AI You said you “looked at their site.” What specifically were you looking for? You Whether they’ve got existing brand assets, roughly what stage the business is at. Whether it looks like they’ve paid for design before. AI How does “whether they’ve paid for design before” change the quote? You If they clearly haven’t, I add more hours for the education side — explaining decisions, more revision rounds. It depends on how DIY the current site looks. AI You said “it depends.” I need the rule. What specifically about a site tells you to add hours — and how many? You …I suppose if it’s a template with stock photos and mismatched fonts, I add about 20% to the hours. If it’s clearly been professionally done before, I don’t add anything, sometimes I take a bit off because they’ll be decisive. AI That’s a decision rule nobody else in your business could have guessed. Two follow-ups: what counts as “clearly professionally done,” and has the 20% ever turned out to be too little? You Consistent type, custom photography, proper spacing. And yes — twice. Both times the client had a committee. That’s the real signal, not the site. AI So the underlying variable is decision-making structure, not design maturity. Let’s capture that properly: how do you find out how many people will approve the work — and do you currently ask before quoting? 4. DECISION RULES — Quoting adjustments Design maturity: if the current site is template-based with stock imagery and inconsistent typography, add 20% to estimated hours for education and additional revision rounds. If professionally designed consistent type, custom photography, deliberate spacing , no uplift; consider a small reduction for decisiveness. Approval structure stronger predictor than design maturity : before quoting, establish how many people must approve the work. Three or more approvers, or any mention of a committee or board: add 35% , not 20%. Historically the two occasions where the 20% uplift proved insufficient both involved committee approval. How to establish this: ask in the first reply — “Who else will be involved in signing off the direction?” This question was not previously asked before quoting. Flagged as a process change during documentation. Note what happened in the last exchange: the interview didn’t just document the existing process — it improved it. The owner discovered that her real predictor was approval structure, not design maturity, and that she’d never been asking the question that would reveal it. That’s a common and underrated side effect of proper extraction: articulating a process exposes the flaw in it. Level-up: the new-hire simulation This is the part competitors’ SOP guides don’t have. Everyone tells you to write documentation. Almost nobody tells you how to test it — so gaps get discovered the expensive way, through a new hire’s mistakes in week two. Have the model follow your SOP literally, as a competent but uninformed new starter, and report every point where it would have to guess. PASTE OPERATIONS CONTEXT BLOCK THE SOP: PASTE THE FULL DOCUMENT You are a new starter on day three. You are competent and motivated, but you know NOTHING about this business beyond what's written in this document. You cannot ask anyone — they're all in a workshop today. Attempt to follow this SOP literally, step by step. At EVERY step, tell me: - What you'd actually do - What you'd have to GUESS, and what you'd guess - Where you'd get STUCK and stop - Where you'd confidently do the WRONG thing because the document is ambiguous but sounds clear - Any term, tool, or reference you don't understand Be literal to the point of pedantry. If the document says "check it looks right," say that you don't know what right looks like. If it says "notify the team," ask which team, by what channel, and how urgently. Do not use common sense to fill gaps — common sense is exactly what a new starter lacks about MY business. At the end: A. CRITICAL GAPS — where I'd get a wrong result and not know B. FRICTION GAPS — where I'd waste time or interrupt someone C. ASSUMED KNOWLEDGE — everything the document assumes I already know but never states D. THE STEP MOST LIKELY TO BE DONE WRONG, and what the consequence would be E. THE THREE QUESTIONS I'd ask on day one — which are the three biggest holes in the document Why this is the unlock: the instruction not to use common sense is doing the heavy lifting. Models default to filling gaps helpfully, which is exactly the wrong behaviour here — it hides the very ambiguity you’re testing for. Section D is the one that saves real money: it identifies where someone would proceed confidently and wrongly, which is more dangerous than getting stuck, because nobody notices until later. Setup tip: run this before the handover, fix the gaps, then run it again. A second pass typically finds a smaller but sharper set of issues — and by the third, you have a document a real person can genuinely follow alone. What should AI never document? | Don’t paste into a prompt | Why | |---|---| Customer personal data | Names, contact details, health or financial information belong in your systems, not in a chat window. Document the process shape; reference where the data lives. | Credentials & security procedures | Passwords, keys, access routines and incident-response detail should never enter a general AI tool. Reference the secure location instead. | Confidential commercial terms | Client pricing, contract specifics and supplier agreements may be contractually restricted. Check before pasting. | Regulated compliance procedures | Where a regulator specifies documentation format and content, start from their framework. Use AI to draft within it, not to invent it. | Anything you’d not email externally | A useful default test. Check your organisation’s AI and data-handling policy, and prefer tools with an enterprise data agreement for operational documentation. | The workable pattern: document the structure and the decision rules; reference sensitive detail rather than reproducing it. An SOP saying “retrieve the client’s account number from the CRM record” is just as usable as one containing the number — and far safer. Which model for which task? Prompts are model-agnostic. Practical notes as of July 2026 : | Task | Best fit | Why | |---|---|---| Extraction interview | Claude or ChatGPT | Both sustain a long multi-turn interview without collapsing into a generic template. This is the whole ballgame. | Interviewing by voice | Any model with voice input | Talking through a process surfaces more tacit detail than typing. Most people explain better than they write — which is the entire premise here. | New-hire simulation | Claude | Large context holds a long SOP plus supporting docs, and it sustains the literal-minded persona without helpfully filling gaps. | Process libraries | Any model with persistent projects | Keep one project per function so SOPs reference each other rather than contradicting. | Automation research | A model with live web search | Tool integrations change constantly; training data alone will suggest connectors that no longer exist. | We re-check these notes whenever a major model ships. If you’re reading this more than two weeks after the date above, verify your model versions still match. Frequently asked questions How do I use AI to write an SOP? Don’t ask the model to write the SOP directly — it will produce a generic template. Instead, instruct it to interview you one question at a time about how you actually perform the task, probing for the steps you do automatically and the decisions you make without noticing. Only once it has enough detail should it produce the structured document. Interview mode is what surfaces the tacit knowledge that makes an SOP usable. Why is it so hard to write down a process I do every day? Because expertise becomes automatic and therefore invisible to the expert. Once you’ve performed a task hundreds of times, the small judgments and checks that make it work stop registering as decisions, so you leave them out when describing the process. This is why an expert asked to write a procedure typically produces a short list a new starter can’t follow — and why being interviewed works better than being asked to write. What should a good SOP include? Seven things: the purpose, the trigger that starts it, the sequential steps, the decision rules for judgment calls, the quality checks that distinguish “done well” from merely “done,” the common failure modes and how to spot them, and the escalation criteria for when to stop and ask. Most written procedures contain only the steps, which is why they fail in practice. How much time do employees lose to missing documentation? Published research puts information search at roughly 1.8 hours per day — around 9.3 hours per week — with some studies finding employees spend about 21% of work time searching and a further 14% recreating information they couldn’t find. A majority of employees report regularly having to ask a colleague or book a meeting simply to locate what they need. Which processes should I document first? Document the processes carrying the highest risk if the person who knows them is unavailable, weighted by how often the work occurs. A task only one person can perform, happening weekly, is far more urgent than a complex process three people already know. Trying to document everything is the most common way these projects stall. Can AI actually automate my operations, or just document them? Documentation comes first, because you can’t reliably automate a process nobody has articulated. Once a process is written down, AI can help identify which steps are genuinely automatable, which should be delegated to a person, and which should be eliminated entirely. A significant proportion of documented steps turn out to exist for no current reason. How do I know if my SOP is actually good enough to hand over? Test it before a person does. Have a model follow the document literally as a competent but uninformed new starter and report every point where it would need to guess, stall, or would proceed incorrectly. Every guess is a gap in the document. This finds the missing context far more cheaply than discovering it through a new hire’s mistakes. Should AI document processes involving sensitive information? Be careful what you paste. Don’t include customer personal data, credentials, security procedures, or confidential commercial terms in prompts to a general consumer AI tool. Document the shape of the process and reference where sensitive detail lives, rather than reproducing the detail itself — and check your organisation’s data handling policy first. Download: The SOP Generator + Template The full extraction interview prompt, a structured SOP template with all seven sections, the new-hire stress test, the triage worksheet, and the automate/delegate/eliminate framework. One file. Send me the template → Enter your email and we’ll send the template plus a short monthly prompt update. Unsubscribe anytime. Written by the Narracomm team Narracomm is a communications and content strategy team that helps business owners, operators, and founders use AI to produce clear, credible, high-performing work. We build and test these prompt systems inside real client operations — documenting processes, running handovers, and reducing key-person risk — and revise them as models change. Add specific credentials, operations or COO experience, industries and company sizes worked with, and a named reviewer here to strengthen E-E-A-T. Sources & further reading Speakwise — Knowledge Management Statistics 2026 https://speakwiseapp.com/blog/knowledge-management-statistics Agility Portal — Time wasted searching for information: findings https://agilityportal.io/blog/time-wasted-searching-information Cottrill Research — Survey statistics on time spent searching for information https://cottrillresearch.com/various-survey-statistics-workers-spend-too-much-time-searching-for-information/ Augmentir — What is tribal knowledge and how do you capture it? https://www.augmentir.com/glossary/what-is-tribal-knowledge Process Works — The hidden costs of tribal knowledge https://www.process-works.com/the-hidden-costs-of-tribal-knowledge Elium — Streamlining SOPs: a guide to knowledge documentation https://elium.com/blog/streamlining-sops-a-comprehensive-guide-to-effective-knowledge-documentation/ Last reviewed and updated: July 25, 2026 · Research and model notes verified against current sources. Next review due within 14 days.