By the end of this lesson you will be able to
- Turn scattered updates into a status report in minutes
- Compare vendor proposals against a consistent rubric
- Finally get the process documentation written down
Operations is the function where "I know what is happening, I just have not written it up" is a permanent condition. Almost all of that backlog is transformation work — turning things you already know into a format someone else can read.
Status reporting
The information exists across a dozen threads, calls, and half-finished spreadsheets. The report does not exist because assembling it takes an hour you do not have. Dump the raw material in and specify the format precisely.
I'm the PM on [project]. Here is this week's raw material —
notes, a few Slack threads, and the risk log.
[PASTE EVERYTHING]
Draft a one-page status report for the steering committee.
Format:
- Executive summary (2 sentences, no hedging)
- Status by workstream (table: workstream, RAG, one-line note)
- Risks needing a decision (only ones needing THEIR decision)
- Decisions needed this week, with owner and date
Tone: direct. Do not soften a red status into an amber one.
If something in the material is ambiguous, list it at the end
under "unclear" rather than guessing.Vendor and proposal comparison
Three proposals, each forty pages, each structured differently, each burying the terms that matter. Comparing them fairly is exactly the kind of tedious reading that gets done badly under time pressure.
Here are three vendor proposals for [contract].
[PASTE OR SUMMARISE EACH]
Compare them on: price (including anything conditional), SLA terms,
relevant experience, implementation timeline, and exit terms.
Format: a comparison table, then one paragraph per vendor on what
concerns me about them specifically.
Rules:
- Quote the actual wording for anything about price or termination
- If a proposal does not address a criterion, say "not addressed" —
do not infer it
- End with the three questions I should ask all three vendorsProcess documentation
Every operations team owns SOPs, runbooks, and training guides that are out of date. They stay out of date because updating them is unrewarding work that never becomes urgent. The blank page is most of the barrier.
Talk it through, roughly
Bullet points, out of order, with gaps. "First they email us, then someone checks the system, usually Dana, then..." — that is enough input. You are not writing the SOP, you are describing it.
Ask for the gaps
"List every step where my description is ambiguous or a decision rule is missing." This is where the real value is — the gaps in the written process are the gaps in the actual process.
Fill the gaps, then generate
Answer the questions it raised, then have it produce the SOP. The result is better than what you would have written, because it forced you to specify the parts you normally hold in your head.
Generate the training version too
Same source, different audience. A new-starter guide from an SOP is close to free once the SOP exists, and it is usually the version people actually read.
The most valuable thing about writing an SOP with AI is not the document. It is being asked, eleven times, "what happens if that step fails?"
Meetings
Here are my rough notes from the vendor kickoff.
[PASTE NOTES]
Produce two things:
1. A clean summary — decisions made, and action items as a table
(action, owner, due date). Mark any action with no clear owner.
2. A follow-up email to the vendor covering next steps on both
sides. Neutral, professional, no filler.
For the summary: if a decision was discussed but not actually made,
list it under "still open" rather than recording it as decided.A warning specific to operations work
Operations tasks involve big documents — full proposals, long policy manuals, months of notes. This is the function most likely to hit the context window, and the failure is quiet: the model reads what fits, ignores the rest, and answers confidently about the part it saw.
- Paste the relevant sections, not the whole document. Precision beats volume every time.
- For long comparisons, do one vendor at a time, then compare the summaries.
- If the answer seems to ignore something you supplied, assume it fell out of the window rather than that the model missed it.
Can it maintain our SOPs automatically?
It can regenerate them when you tell it what changed, which is most of the work. It cannot know that a process changed — someone still has to notice and say so. Tie the update to whatever already triggers a process change rather than to a calendar reminder.
Is it safe to paste a vendor contract in?
On a business tier with training disabled, this is a normal use. On a personal free account, check whether your agreement with that vendor restricts sub-processing. The tier is usually the whole answer.
What about the numbers in a spreadsheet?
Treat arithmetic with suspicion. Models are much better at describing and structuring data than at calculating over it. Use it to write the narrative around numbers your spreadsheet computed, not to compute them.
Key takeaways
- Operations work is mostly transformation — you already know it, you just have not written it up.
- Always ask for an "unclear" or "not addressed" section. It prevents confident gap-filling.
- The value in AI-assisted SOPs is the questions it asks, not the document it produces.
- Flag actions with no owner — the most common meeting failure, and easy to detect.
- This is the function most likely to overflow the context window. Paste sections, not manuals.