Overview

You write a prompt. The AI spits back something. You read it and think: "This isn't usable. It's too generic. It's missing details. It's written for someone else's company, not mine." Then you iterate. Three prompts in, you finally get something worth keeping. That's waste.

The problem isn't that AI can't help. The problem is you're not setting it up to help you specifically. You're asking for "an SOP" and getting a template. You're asking for "a vendor comparison" and getting bullet points that could apply to any industry. You're asking for "process improvements" and getting advice you can't afford to implement.

This lesson teaches you how to extract output that actually works in your operation, before you have to iterate it five times. We're going to focus on three things: specifying format so the output fits your use case, providing enough org context that the AI isn't operating blind, and iterating strategically when you do need to refine.

The Format Problem and How to Solve It

Operations work has very specific format needs. A process document for your training manual looks completely different from a process document for your wiki. An approval checklist for a new hire is different from a checklist for compliance auditors. You know this. The AI doesn't, unless you tell it.

Most operations professionals skip the format specification. They assume "everyone knows" what a status report is, or what an SOP looks like. They don't. And the AI will give you something that isn't quite right for what you need, then you spend time reformatting it.

Format Types That Matter in Operations

Numbered Steps: Used for SOPs, training, checklists. "1. Do X. 2. Do Y." Simple and clear. Specify: "8-12 steps" or "15-20 steps" depending on process complexity. Include owner, input, action, output.

Tables: Used for comparisons, RACI matrices, risk registers, capacity plans. Specify the columns upfront. "Create a table with columns: Step | Owner | Department | Time Estimate | Approval Gate Yes/No."

Narrative with inline decisions: Used for context-dependent processes where decision-making matters. "Write this as a flowing paragraph, but mark decision points with [DECISION: If X is true, go to step 5. If not, go to step 8.]"

Flowchart (text-based): Used for complex processes with many branches. The AI can't draw, but it can structure logic. "Create a text-based flowchart using arrows (→) and decision branches ([Decision Node] → Yes → Step A, No → Step B)."

Checklist with phases: Used for implementation projects, audits, deployments. "Create a checklist organized by phase (Planning, Execution, Verification). Use checkboxes (☐) so it can be printed and completed by hand."

Comparison matrix: Used for vendor evaluation, tool selection, implementation approach comparison. "Create a matrix: Columns are Vendor A, B, C. Rows are Price, Lead Time, Support, Integration, Risk. Score each 1-5 with brief justification."

Here's the key: pick the format based on how you'll actually use the output. If you're printing it for a training room, a checklist format works. If you're embedding it in a wiki, a narrative with inline links works. If you're presenting to stakeholders, a comparison matrix works. Different formats, different purposes.

The Format Specification You Actually Need

When you specify format, include three things: the shape, the level of detail, and the intended use.

Weak format spec: "Create a checklist for onboarding."

Strong format spec: "Create an onboarding checklist formatted for printing on one page (8.5x11 in portrait). Group items by day (Day 1, Day 2, Day 3). Include checkboxes so the onboarding buddy can check off items as they're completed. Keep each item to one short sentence. Assume the person reading this has no context. They're handed this on day one."

See the difference? The strong spec tells the AI the actual constraints: one page (it needs to be concise), print format (that's a technical constraint), day grouping (that's a useful structure), checkbox format (that's a physical/digital requirement), short sentences (that's about the reading level), no context assumption (that's the audience).

Now the AI will give you something you can actually print and hand to your onboarding buddy, not a 3-page document you have to reformat.

Organization Context: The Information You Must Provide

The biggest reason operations professionals get generic output is they don't provide organizational context. You think it's obvious, but it's not to AI.

Here's what context actually includes:

1. Organization Size and Structure

"We're a 150-person manufacturing company" is different from "We're a 150-person SaaS company" is different from "We're a 150-person staffing firm." The processes, compliance requirements, and resource constraints are completely different. Name it explicitly.

Also specify reporting structure if it matters: "The Operations team reports to the COO. We're separate from Finance. We don't have hiring authority, all hiring goes through HR."

2. Current State

This is critical. Don't just say "We need a better approval process." Say: "Today, approvals happen via email chains on a spreadsheet we maintain in a shared drive. We have no audit trail. We can't trace who approved what or when. Last year, we had a compliance audit that flagged this."

Why? Because the AI needs to understand the problem. It won't suggest you implement a sophisticated software system if you've told it you're bootstrapped and can't buy new tools. It won't suggest hiring people if you've told it you're understaffed and can't add headcount.

3. Constraints and Non-Negotiables

These are the rules you're operating under. Name them:

• "We can't buy new software. We use: Salesforce, Google Drive, Excel, email."
  - "We can't hire additional staff this year."
  - "All processes must be completable by one person without escalation (except final approval)."
  - "This must be HIPAA-compliant."
  - "We have 20 locations, and not all of them have reliable internet."
  - "Our customer contracts require 48-hour turnaround, no exceptions."

These aren't excuses. They're the actual operating environment. The AI's job is to work within them, not ignore them.

4. Stakeholders and Decision Rights

Who's involved? Who has to approve? Who will hate this and block it?

Example: "The VP of Finance will need to approve because it involves spend tracking. The Regional Directors will need to execute this daily, so they need to buy in. The CEO cares about this becoming a compliance risk. It's on their risk register."

This tells the AI whose perspective matters and what trade-offs might exist. It prevents suggesting a beautiful process that the VP of Finance will reject because it doesn't integrate with the general ledger.

5. The Actual Problem You're Solving

Not the symptom. The problem.

Symptom: "Our invoicing is slow."

Problem: "It takes 3 weeks from customer invoice to payment processed. That's because we don't have a clear process for approval. Finance receives invoices but can't find POs. They ask Sales, Sales doesn't respond for days. We lose track of invoices. Customers call asking for payment status. Meanwhile, we're missing early-payment discounts."

The problem tells the AI why the current state is broken. It prevents the AI from suggesting something that doesn't address the actual issue.

Real Example: The Org Context That Changes Everything

Let's say you need an SOP for handling customer complaints. Here's how context changes the output:

Minimal context: "Write an SOP for handling customer complaints."

Output: Generic steps. Probably talks about "listening to the customer," "taking notes," "escalating if needed." Could apply to any business. Vague. Useless.

Rich context:

We're a 90-person managed services provider (IT support for small businesses).

Current state: Complaints come in via email, phone, and ticketing system. There's no consistent way complaints are handled. Sometimes they get escalated to me, sometimes they don't. Some customers are ignored for days. Last month, we lost a customer worth $8K/month because a complaint wasn't addressed.

Key facts:
- We have 12 account managers, 1 support manager, 8 technicians.
- Most customers pay $2K-5K per month.
- Complaints are usually about "slow response times" or "tech didn't fix the issue."
- Our SLA says we'll respond within 4 hours during business hours.
- We track everything in our ticketing system (Zendesk).

The problem: We don't have a escalation path. An angry customer can email a tech, or call their account manager, or file a ticket, and there's no trigger that says "this is a real problem that needs immediate attention."

Goal: Create a clear process that:
- Ensures every complaint is acknowledged within 4 hours
- Identifies complaints that indicate a deeper problem (repeated issues from one customer, repeated issue across customers)
- Creates a clear escalation path so the account manager knows when to call the customer back
- Prevents complaints from falling through cracks

Now the output will be completely different. The AI will write something like: "When a complaint comes in (email, phone, or ticket), it goes into Zendesk. The support manager reviews Zendesk daily and flags complaints. For complaints about unresolved tech issues, create a new ticket and assign to original tech with instruction to follow up within 24 hours. For complaints about response time, flag to account manager who calls customer within 4 hours." Specific to you. Actionable.

The context checklist

Before you ask AI for any operations process, checklist these five context questions: (1) What's our size and structure? (2) How are we doing it today? (3) What tools/resources do we have? (4) Who has to approve/execute this? (5) What actual problem are we solving? If you can answer all five, you have enough context.

Iteration Strategy: How to Refine Without Starting Over

Sometimes you will need to iterate. The first output isn't quite right. Rather than starting from scratch, use targeted follow-ups.

Types of Iteration

Refinement ("Make it more X"): The output is in the right direction, but needs adjustment. "The steps are good, but they're too detailed for non-technical staff. Simplify the language so a high school graduate could follow them." Or: "This is too vague. I need decision criteria. How does the account manager decide if a complaint is 'serious' vs 'routine'?"

Addition ("Add X"): You're missing something. "This covers the happy path. What happens if the customer's original ticket is lost? Add a step for that." Or: "I need a compliance angle, add what records we keep for audit purposes."

Removal ("Remove X"): There's stuff you don't need. "This suggests we notify customers at every step. We don't have budget for that. Remove notification steps."

Redirection ("Focus on X instead"): The output went in the wrong direction. "You focused on how to escalate to senior management. I actually need you to focus on how to prevent complaints in the first place, what early warning signs do we watch for?"

Format adjustment ("Reformat as X"): It's good content, wrong shape. "This is a narrative. Can you convert it to a checklist format with phases?" Or: "This is a checklist. Can you expand it into a detailed SOP that I can use for training?"

The key: be specific about what needs to change. Don't say "I don't like this." Say: "This is missing a decision criteria on when to escalate. Can you add that?" Now the AI knows exactly what to fix.

When to Stop Iterating

If you're more than three iterations in, you're probably iterating toward something the AI can't deliver. At that point, use the output as a draft and build your final version yourself. The AI helped you think through it. You're now refining, not creating.

Try This Now: The Full Workflow

Let's walk through a real example from start to finished output, showing iteration along the way.

Scenario: You're the Operations Manager at a 40-person staffing firm. You need a process for how you handle vendor invoices. Today it's chaos. Finance receives invoices, can't match them to purchase orders, asks Operations, Operations is slow to respond, Finance gets frustrated, invoices are paid late. You want a clear process.

First prompt (what most people write):

Write an SOP for vendor invoice processing.

Output you'd get: Generic steps about receiving invoices, matching to POs, approving, paying. Nothing about your specific problem (Finance can't match to POs).

Better prompt (with context):

Role: You are an operations manager at a 40-person staffing firm.

Context:
- Organization: We're a staffing firm placing candidates with corporate clients.
- Current problem: Finance receives vendor invoices (for things like background check services, job posting sites, recruiting software). Finance can't match invoices to purchase orders. They contact Operations. Operations (that's me) is slow to respond because I don't have a clear tracking system. Invoices end up sitting for 2-3 weeks before approval. We're missing early payment discounts. Vendors are starting to complain about payment timing.
- Tools: We use Quickbooks for accounting, email, Google Drive for documentation, Asana for task tracking.
- Headcount: Me (1 Operations Manager), 1 Finance Manager, 1 Finance Coordinator. Operations doesn't have additional staff.
- Current state: When I need a vendor, I request approval from the founder, get it (or don't), then verbally tell Finance "we signed up for XYZ." No documentation. No PO created.

Task: Create a process for vendor invoice approval that prevents the problem of Finance not being able to match invoices to approved vendors. This should include: how a vendor is approved in the first place, how we document that approval, how Finance matches invoices to that documentation, and how Finance knows something is approved for payment.

Format: Create a numbered SOP (6-10 steps). For each step: Who does it, What they do, Input (what they need to start), Output (what gets created/approved), Timeline (how long it should take).

Constraints:
- Assume Finance will not become a subject matter expert on each vendor. Keep their job simple.
- The process must be fast enough that we can respond to invoices within 1 business day.
- I don't want to create a formal "purchase order" system, that's overkill. I want something simpler that still gives Finance the info they need.

Output you'd get (first pass):

Vendor Invoice Processing SOP

Step 1: Identify Vendor Need
- Owner: Operations Manager
- Action: When a new vendor is needed, document the vendor name, purpose, and approximate monthly cost.
- Output: Vendor approval request (can be an email with details or a form)
- Timeline: Same day

Step 2: Request Approval
- Owner: Operations Manager
- Action: Submit vendor request to Founder with details
- Output: Approval email from Founder
- Timeline: 1-3 business days

Step 3: Create Vendor Record
- Owner: Operations Manager
- Action: In Google Drive, create a simple spreadsheet with: Vendor Name, Service, Approved Monthly Cost, Approval Date, Approval Email Link
- Output: Row added to "Approved Vendors" spreadsheet
- Timeline: Same day as approval

Step 4: Share with Finance
- Owner: Operations Manager
- Action: Email Finance Manager with new vendor details. CC the link to the spreadsheet.
- Output: Finance receives vendor notification
- Timeline: Same day

Step 5: Match Invoice to Approval
- Owner: Finance Coordinator
- Action: When invoice arrives, check Google Drive "Approved Vendors" spreadsheet. Match vendor name. Verify amount aligns with approved amount (allow 10% variance).
- Output: If match found, approve invoice. If no match, email Operations for clarification.
- Timeline: Same day invoice arrives

Step 6: Pay Invoice
- Owner: Finance Manager
- Action: In Quickbooks, record invoice and approve for payment if Finance Coordinator confirmed it's an approved vendor.
- Output: Invoice recorded in Quickbooks
- Timeline: 1 business day from Finance Coordinator approval

Your reaction: "This is close, but it's missing some things. What happens if the founder approves a vendor but then we change our mind? What if the vendor sends an invoice that's way higher than expected? Also, Finance said they want to know WHO approved it, not just that it was approved."

Your iteration prompt:

Good start. I need you to add three things:

1. What happens if a vendor sends an invoice that's significantly higher than the approved amount? (e.g., approved for $500/month but invoice is $800/month). Add a decision point.
2. How do we handle vendor cancellations? If we cancel a vendor, Finance needs to know. Add a step for that.
3. In the spreadsheet, Finance wants to see not just "Approved" but "Approved by [Name]" so they know who signed off. Update the spreadsheet format to include that column.

Updated output (second pass):

[Steps 1-4 remain same, with spreadsheet format updated to include "Approved By" column]

Step 5: Match Invoice to Approval
- Owner: Finance Coordinator
- Action: When invoice arrives, check "Approved Vendors" spreadsheet. Match vendor name. Verify amount aligns with approved amount (allow 10% variance).
- Input: Invoice from vendor, Approved Vendors spreadsheet
- [NEW DECISION POINT] If invoice amount is MORE than 10% above approved amount:
- Email Operations Manager with the variance
- Wait for Operations Manager response
- Operations Manager either approves the overage or asks vendor for credit memo
- Output: If approved, mark in email "Approved for payment"
- Timeline: Same day invoice arrives

Step 6: [NEW] Vendor Cancellation
- Owner: Operations Manager
- Action: If we're canceling a vendor, update "Approved Vendors" spreadsheet with cancellation date and "Status: Inactive"
- Output: Vendor marked inactive in spreadsheet
- Timeline: Same day decision is made
- Important: Email Finance to confirm they see the cancellation in the spreadsheet

Step 7: Pay Invoice
- Owner: Finance Manager
- Action: In Quickbooks, record invoice and approve for payment
- Output: Invoice recorded, payment scheduled
- Timeline: 1 business day from Finance Coordinator approval

Your reaction: "Perfect. This is usable. I can hand this to Finance on Monday and they'll know exactly what to do."

See what happened? You didn't need five iterations. You needed one solid prompt with context, got 90% of the way there, then refined with specific add-ons. That's how good iteration works.

The mistake: Over-iterating on words

Don't iterate on writing quality or tone. That's not what slows you down. Iterate on structure (missing steps, wrong format, unclear logic). If the AI's writing is too formal, just rewrite it yourself, that takes five minutes. If the logic is wrong, ask the AI to fix the logic, that takes a conversation.

The Specificity Principle

There's a pattern to getting useful output: the more specific you are upfront, the less iteration you need.

Vague: "Help me improve our recruitment process."

Specific: "Our recruitment process takes 6 weeks from job posting to offer. We want to cut it to 3 weeks. The bottleneck is the interview scheduling, candidates take days to respond to interview requests, and we have to chase them. Create a new process that speeds up scheduling without changing our interview panel structure."

The specific version tells the AI: what you're optimizing for (time), what the current state is (6 weeks), what the target is (3 weeks), where the problem is (scheduling), and what you won't change (panel structure). You'll get useful output the first time because the AI understands your actual situation.

What to Do Monday Morning

• Pick one process you need documented. Write out the five context elements (size/structure, current state, constraints, stakeholders, actual problem) before you write the prompt. Don't skip this.
  - Specify the exact format you need (numbered steps, table, checklist, narrative). Include the intended use (printing? embedding in wiki? training tool?).
  - Send the prompt and get the first output. Don't iterate unless something is structurally wrong. If it's just wording, rewrite it yourself.
  - If you do iterate, be surgical. Don't say "this isn't quite right." Say "Add a decision point for X" or "Remove the assumption about Y."
  - Stop after three iterations. If you're still not there, use the output as a draft and finish it yourself.

Key Takeaways

• Format matters as much as content. Specify how the output will be used (printed, embedded in wiki, presented to stakeholders). The format should match the use case.
  - Organization context is the difference between generic and useful. Tell the AI your size, current state, constraints, stakeholders, and the actual problem. Don't assume they'll infer it.
  - Iteration works best when it's targeted, not wholesale. Use "Add X," "Remove Y," "Clarify Z" rather than "Make it better."
  - Specify iteration rules upfront. If you know you'll need to iterate, say so. "This is a first draft. I'll want to iterate on decision points and exception handling."
  - Stop iterating when you hit diminishing returns. After three iterations, you're probably refining words, not structure. Do that yourself.
  - Save working outputs. The output is half the value. The process that generated it is the other half. Document both.

FAQs

How much context is "enough"?

Enough context is when a smart new hire could read it and understand your situation without asking follow-up questions. If you're still explaining verbally after they read the prompt, you didn't have enough context in writing.

What if I don't know the format I want?

Ask the AI: "What format would work best for this output and why?" Then choose one. Operations people sometimes think in narratives when they should be thinking in tables, or vice versa. Let the AI suggest, then decide.

When is iterating actually faster than redoing it myself?

If the AI got 70%+ right and you need to add 3-4 specific things, iterate. If it got 40% right and you'd need to rewrite most of it anyway, just use it as a draft and build from there. There's a crossover point where iteration stops being efficient.

Should I save every version of the output, or just the final one?

Save the final one. But save the prompt that created it. Next time you need something similar, you'll have the prompt as a template. The prompt is more reusable than the output.

What if the AI output creates problems when I implement it?

That's covered in the next lesson. Right now, focus on getting useful output. Once you implement it, you'll learn what to watch for. That's feedback for next time.