AI Prompts for Operations Managers: SOPs, Checklists, Incident Summaries and Shift Handovers

It's 5:50 am, the night lead is leaving, and the handover is a scrap of paper that says "line 2 running ok, check the sealer." The day lead spends forty minutes finding out that the sealer was running hot, that a maintenance job was promised for 7:00, and that two pallets are on hold for a label problem nobody wrote down.

Operations work runs on documents that most people write badly under time pressure: SOPs, checklists, incident summaries and handovers. AI prompts for operations managers help most with the part you're slow at, which is getting messy knowledge into a consistent shape. They help least with the part that matters, which is whether the content is true for your site. So the rule for this post is simple: the model structures, the people who do the work verify.

These are untested templates. I haven't run them on a live operation, and every example here is invented and illustrative. The one thing I did run is a small script, described below, that flags vague SOP steps. If your process is about project delivery rather than daily operations, prompts for project managers cover status and risk reporting, which this post doesn't repeat.

How do I draft an SOP with AI?

Start from what people actually do, not from what the model thinks a good process looks like. A model asked to "write an SOP for closing the packing line" will produce a plausible, generic document. It will not know that your sealing station needs ten minutes to cool before cleaning.

Record the person who does the job explaining it, transcribe it, and paste the transcript in.

You are helping me write a standard operating procedure (SOP).

PROCESS: [NAME]
WHO PERFORMS IT: [ROLES]
WHERE / WITH WHAT: [EQUIPMENT, SYSTEMS]
SOURCE MATERIAL (use only this):
[PASTE transcript, old checklist, or notes]

Write the SOP with these sections:
1. Purpose (one sentence)
2. Scope: what this covers and what it does not
3. Roles: who does what, by role name only
4. Before you start: tools, materials, preconditions
5. Steps: numbered, one action per step
6. Stop-and-escalate conditions: when to stop and who to call
7. Records: what must be written down and where

STEP STANDARD (apply to every step):
- Starts with a verb.
- Names the role in [square brackets].
- Has a number, a time, or a visible result a second person could check.
- No "as needed", "properly", "ensure", "regularly", "as required".

If the source does not say something (a temperature, a time, a name), write
[MISSING: what is needed] instead of guessing. After the SOP, list every
[MISSING] item as a question for the person who does the job.

Two parts earn their place. The step standard gives the model something to hit and gives you something to check against. And the MISSING list turns the draft into an interview guide. The first time you run it you will probably get ten or fifteen questions, and the answers are the valuable part of the exercise, because that is knowledge that only lived in someone's head.

Then do a walk-through. Hand the draft to someone who does the job and ask them to perform it, reading each step aloud, while you watch. Every place they hesitate, improvise or say "well, actually" is an SOP bug. No prompt replaces this.

Can I check an SOP mechanically before a human reads it?

Partly, and it's worth doing because it's cheap. I wrote a short Python script (about 30 lines, nothing clever) that reads a numbered SOP and flags steps with a vague phrase, no [role] owner, no number and no check or record verb, or more than 35 words. Save the script below as sop_lint.py and run python3 sop_lint.py sop.txt, where sop.txt has one numbered step per line (1. [Role] Do the thing.). The word lists are mine; edit them to suit your site.

import re
import sys

VAGUE = ["as needed", "appropriate", "properly", "ensure", "make sure", "asap",
         "when necessary", "if required", "etc", "as required", "regularly"]
CHECK_WORDS = ["confirm", "verify", "check", "record", "log", "sign", "photo", "scan", "tick"]
OWNER = re.compile(r"\[(\w[\w /]*)\]")

steps = [l.strip() for l in open(sys.argv[1]) if re.match(r"\s*\d+\.", l)]
flags = 0
for s in steps:
    n = s.split(".")[0]
    s = s.split(".", 1)[1].strip()
    low = s.lower()
    msgs = []
    for v in VAGUE:
        if re.search(r"\b" + re.escape(v) + r"\b", low):
            msgs.append(f"vague phrase '{v}'")
    if not OWNER.search(s):
        msgs.append("no [role] owner")
    if not re.search(r"\d", s) and not any(c in low for c in CHECK_WORDS):
        msgs.append("no number and no check/record verb")
    if len(s.split()) > 35:
        msgs.append("over 35 words, probably two steps")
    for m in msgs:
        print(f"step {n}: {m}")
        flags += 1
print(f"{len(steps)} steps, {flags} flags")

I ran it on an invented six-step SOP for closing a packing line, written to be bad on purpose. Output:

step 1: no number and no check/record verb
step 2: vague phrase 'properly'
step 2: no [role] owner
step 2: no number and no check/record verb
step 4: vague phrase 'as needed'
step 4: vague phrase 'ensure'
step 4: no number and no check/record verb
step 4: over 35 words, probably two steps
step 6: no [role] owner
step 6: no number and no check/record verb
6 steps, 10 flags

Be honest about what that shows. The script found the planted problems (step 2 "clean the sealing station properly" has no owner and no result; step 4 is three steps glued together). It also flagged step 1, "Stop the conveyor and press the red stop button," which is actually fine for a physical action, so a flag is a candidate for a human decision, not a verdict. The script can't tell you a step is true. It only finds the writing habits that make steps unverifiable.

You can do the same without code. Search the document for the vague words, and look for any step without a role. Then use the model for the reverse job:

Here is an SOP. Act as a new starter on their first day who has never seen
this process. For each step, list what you would have to guess or ask. Do
not rewrite the SOP. Output a table: step number | what I'd have to guess |
question to ask.

This "naive reader" framing finds ambiguity better than asking "is this clear?", which models almost always answer yes.

How do I turn an SOP into a checklist that people will actually use?

An SOP explains; a checklist triggers. If the checklist is a copy of the SOP, nobody reads it. Ask for the shortest version that still prevents the known failures.

From this SOP, create a one-page checklist for use at the point of work.

Rules:
- Maximum [12] items. Each item is a check someone can tick, written as
  an observable state ("Guard in place"), not an instruction to remember.
- Separate DO-CONFIRM items (do the thing, then tick) from READ-DO items
  (read the item, do it, tick).
- Mark the 3 items where a mistake causes the worst outcome with [CRITICAL].
- Put a "Stop if" line at the top with the conditions where the person
  should stop and escalate.
- Do not add checks that are not in the SOP.

SOP:
[PASTE]

After the checklist, list any SOP step you left out and why.

The last line matters. Leaving something out is a judgement call and you want to see it. Choose the [CRITICAL] items yourself if the stakes are real; use the model's picks as a second opinion, not the answer.

How do I write an incident summary quickly?

Incident summaries go wrong in two ways. They get written days later from memory, or they get written fast and blame a person. Use the model to get a timeline and a neutral first draft from raw notes, within hours.

Raw notes from an operational incident are below (messages, call notes,
log excerpts). Create an incident summary.

Output:
1. One-sentence summary: what happened and the impact so far.
2. Timeline: time | event | source (quote or note the line it came from).
   Times exactly as given. If a time is unclear write [TIME?].
3. Impact: customers, units, hours or money, ONLY if a number appears in
   the notes. Otherwise [IMPACT NOT KNOWN].
4. What we did to contain it.
5. What is still open, with owner and next check time.
6. Questions we cannot yet answer.

Rules: describe actions and systems, not blame. Say "the order was released
without a label check", not "John forgot". Do not state causes; list
"possible contributing factors" separately and label them hypotheses.
If notes conflict, show both versions.

NOTES:
[PASTE, with names replaced by role names]

Replace names with roles before pasting. For incidents involving injury, safeguarding, data loss or a regulator, there's usually a mandatory reporting route with its own form and deadline, and an AI summary does not replace it. Ask your safety or compliance lead which applies. When the incident is software, the fuller LLM feature incident postmortem template has fields worth borrowing.

What does a good shift handover look like?

Start with the mess at the start of this post and give the outgoing person two minutes of dictation or typing at end of shift. The model reshapes it, and, more usefully, asks about the gaps.

Turn these rough end-of-shift notes into a handover for the incoming
[ROLE]. Notes:
[PASTE]

Format:
RUNNING NOW: line/equipment | state | anything unusual
PROBLEMS TODAY: what, what was done, status
OPEN ITEMS: item | owner | due time. If no owner is stated write
  [NO OWNER] and list it again at the bottom under "Needs an owner".
FIRST HOUR: things the incoming person must do before anything else
HOLDS AND RISKS: stock on hold, safety notes, people absent
CONTACTS: who to call and for what, only if named in the notes

Then ask me up to 5 questions about anything ambiguous, such as a
promised job with no time, or "ok" with no detail. Do not assume.

The questions are the real product. "You said the sealer needs checking. What exactly did you see, and when was maintenance told?" is the exchange that saves forty minutes at 6:30 am.

Keep the format identical every shift. Consistency lets the reader skim to the section they need, and it makes missing sections obvious.

A worked example (illustrative)

Invented input from a night lead, typed in under two minutes: "line 2 ok mostly. sealer hot again maint said they'd come. 2 pallets of the blue SKU on hold label wrong, QA knows. forklift 3 battery low. Ravi off sick so only 4 packers."

Expected output shape:

RUNNING NOW: Line 2 | running | sealer temperature high (second time, per notes)
PROBLEMS TODAY: Label error on blue SKU, 2 pallets on hold; QA informed.
OPEN ITEMS:
- Sealer inspection | Maintenance (stated) | [TIME?]
- Forklift 3 charge | [NO OWNER] | -
FIRST HOUR: Confirm maintenance time for sealer; assign forklift charge.
HOLDS AND RISKS: 2 pallets blue SKU; staffing 4 packers (1 absent).
Questions: When did the sealer first run hot, and what temperature? Did
maintenance give a time? Who releases the held pallets, and on what check?

Nothing in it is new information, and that's the point. The note now has a shape, two open items are visible and four questions are waiting for the outgoing lead before they go home.

Where this goes wrong

What not to automate

• Safety content. Lockout steps, chemical handling, guarding and emergency procedures need the safety lead's sign-off, not a model's fluency.
• Approval of an SOP. The person accountable for the process signs it, after the walk-through.
• Regulatory or injury reporting. Use the official route and its form.
• Judging fault. The summary can list contributing factors; deciding responsibility is a human conversation.
• Deciding what's safe to hand over. The model reformats the note. The outgoing lead is accountable for what it says.
• Replacing the walk-through. The best test of an SOP is someone new following it while you watch.

For the underlying habits, giving context explains why the source material matters more than the instruction, and avoiding hallucinations covers the "use only this" pattern. If you hand a built process to a client or another team, the handover runbook template shows the same discipline for automations. More ready templates are in the prompt library.