Writes a standard operating procedure (SOP) for a specific process, covering purpose, scope, steps, roles, and quality checks. Use it when you need a repeatable, written procedure that anyone on the team can follow without asking you for help.
ORGANIZATION AND DEPARTMENT ·PROCESS NAME ·PURPOSE ·SCOPE ·PROCESS STEPS ·ROLES ·TOOLS AND SYSTEMS ·QUALITY CHECKS ·EFFECTIVE DATE
## Context
You are an operations documentation assistant helping a logistics, operations, or project management professional write a standard operating procedure (SOP). The SOP will be used by staff performing the process and by supervisors verifying compliance. It must be clear enough for a new team member to follow without additional instruction.
Organization and department: [ORGANIZATION AND DEPARTMENT]
Process name: [PROCESS NAME]
Purpose of the process: [PURPOSE]
Scope (who performs it, what it covers, what it excludes): [SCOPE]
Step-by-step description of the process as currently performed: [PROCESS STEPS]
Roles involved and their responsibilities: [ROLES]
Tools, systems, or forms used: [TOOLS AND SYSTEMS]
Key quality checks or compliance requirements: [QUALITY CHECKS]
Effective date: [EFFECTIVE DATE]
## Task
Write an SOP with these sections: Purpose, Scope, Roles and Responsibilities, Required Tools and Systems, Procedure (numbered steps), Quality and Compliance Checks, and Document Control (version, effective date, owner).
## Standards
- Procedure steps are numbered and written in the imperative voice: 'Log in to the system,' not 'The operator should log in.'
- Each step is one action. Do not combine multiple actions in one step.
- Role assignments use the titles provided in [ROLES], not invented titles.
- Quality and Compliance Checks name the specific check, the person responsible, and the frequency.
- Do not invent step details, system names, form numbers, or compliance standards not provided in the inputs.
- If a step from [PROCESS STEPS] is ambiguous about the actor, system, or outcome, insert a bracketed note: [CLARIFY: who performs this step?] rather than guessing.
- Do not invent dates, percentages, dollar figures, cycle times, or error rates. If a metric is relevant, use [INSERT METRIC FROM YOUR RECORDS].
- This SOP is a documentation tool. It does not substitute for regulatory compliance review, safety review, or legal approval.
- If any required input is missing or unclear, ask before drafting.
BEFORE YOU RUN IT
- A step-by-step description of the process as it is actually performed today, not as it is supposed to work in theory
- The roles involved, using the exact job titles your organization uses
- All tools, systems, and forms touched during the process, including software names and form numbers
- Any quality checks, compliance requirements, or approval steps built into the process
- Confirm that all dates, metrics, cycle times, and compliance references come from your own records and policies, not from the AI
- Confidentiality: keep proprietary system credentials, customer data, and personnel details out of the prompt
VERIFY BEFORE IT LEAVES YOUR HANDS
- Every procedure step matches how the process is actually performed today: walk through the SOP against the real process before publishing
- Role titles in the SOP match your organization's actual titles: a mismatch creates confusion about accountability
- No metric, cycle time, or error rate appears in the SOP that you did not provide: delete or replace any AI-inserted figure
- All [CLARIFY] flags resolved before the SOP is used: an unresolved ambiguity in a published SOP is a gap in your process
- Quality and compliance checks verified against your current policy or regulatory requirement, not assumed to be correct
- Document Control section reviewed: version number, effective date, and owner must reflect your actual document management practice
Sample output
Sample output. Generated by AI from sample inputs:
STANDARD OPERATING PROCEDURE
Organization: Northwind Distribution | Department: Warehouse Operations
Process: Inbound Freight Receiving
Version: 1.0 | Effective Date: July 1, 2026 | Owner: Warehouse Manager
Purpose
This SOP defines the process for receiving inbound freight shipments at the Northwind Distribution Center to ensure accurate inventory counts, timely exception reporting, and correct staging for putaway.
Scope
Covers all inbound freight from carrier delivery through system confirmation. Applies to all Receiving Technicians and the Receiving Lead. Does not cover returns processing or inbound transfers from other Northwind sites.
Roles and Responsibilities
- Receiving Technician: performs physical receipt, count verification, and system entry.
- Receiving Lead: reviews exceptions, approves discrepancy reports, and signs off on daily receiving log.
- Carrier Driver: provides bill of lading (BOL) and waits for receipt confirmation before departure.
Required Tools and Systems
- Warehouse Management System (WMS): Atlas WMS v4.2
- Mobile barcode scanner: Northwind model RS-9
- Receiving Discrepancy Report form (Form WH-12)
- Bill of lading from carrier
Procedure
1. Verify the carrier appointment in Atlas WMS before opening the dock door.
2. Check the BOL against the expected purchase order (PO) in Atlas WMS: confirm supplier name, PO number, and item count.
3. If the BOL does not match an open PO, do not unload. Notify the Receiving Lead immediately.
4. Unload the shipment onto the designated receiving dock area.
5. Count all cartons and pallets. Record the physical count on the BOL.
6. Scan each item barcode using the RS-9 scanner to confirm item and quantity against the PO in Atlas WMS.
7. If count matches the PO within tolerance [INSERT TOLERANCE FROM YOUR RECORDS], confirm receipt in Atlas WMS and print the receiving label.
8. If count does not match, complete Form WH-12 and notify the Receiving Lead before confirming receipt.
9. Stage confirmed freight in the designated putaway lane for the item category.
10. Have the carrier driver sign the BOL. Retain the original; provide a copy to the driver.
11. Log the completed receipt in the daily receiving log.
Quality and Compliance Checks
- Receiving Lead reviews all Form WH-12 discrepancy reports daily before end of shift.
- Receiving Technician verifies item barcodes at 100% of line items, not spot checks.
- Receiving Lead signs the daily receiving log each day.
Document Control
Version 1.0. Effective July 1, 2026. Owner: Warehouse Manager. Review annually or when process changes.
CUSTOMIZATION For regulated industries (food, pharma, government contracts), add a References section citing the applicable regulation or standard. If your organization uses a specific SOP template with a fixed header format, adjust the Document Control section to match. For complex processes with decision branches, add a Decision Points subsection under Procedure to call out the branch conditions. Veterans with logistics or supply chain experience can map their unit-level receiving procedures directly into [PROCESS STEPS].
Process Map Description
OPEN SAMPLE Describes a process flow step by step in a format ready to hand to a diagram tool or a team member building a flowchart. Use it when you need to document a process for training, improvement analysis, or a deliverable and do not have the steps written down clearly.
ORGANIZATION AND PROCESS NAME ·START TRIGGER ·END STATE ·PROCESS STEPS ·DECISION POINTS ·ROLES ·SYSTEMS AND FORMS ·PAIN POINTS
## Context
You are an operations documentation assistant helping a logistics, operations, or project management professional describe a process flow clearly enough to build a process map or flowchart. The output will be used to create a visual diagram, train staff, or analyze the process for improvements.
Organization and process name: [ORGANIZATION AND PROCESS NAME]
Process start trigger (what kicks it off): [START TRIGGER]
Process end state (what does 'done' look like): [END STATE]
Step-by-step description of the process: [PROCESS STEPS]
Decision points and their outcomes (if/then branches): [DECISION POINTS]
Roles performing each step: [ROLES]
Systems or forms used: [SYSTEMS AND FORMS]
Known pain points or rework loops: [PAIN POINTS]
## Task
Produce a numbered process flow description with these components:
1. Process overview: one paragraph covering purpose, start trigger, and end state.
2. Step list: each step numbered, with the role, action, system or form touched, and output of the step.
3. Decision points: each branch labeled with the condition, the yes path, and the no path.
4. Rework loops: each known loop identified with the step it returns to.
5. Diagram notes: a short bulleted list of guidance for whoever builds the visual diagram.
## Standards
- Number steps sequentially. Decision points get a letter suffix: step 3 with a decision becomes 3A (yes path) and 3B (no path).
- Every step names the role performing it and the output produced.
- Do not invent steps, decision branches, or systems not described in the inputs.
- If a step in [PROCESS STEPS] is unclear about the actor, output, or sequence position, flag it as [CLARIFY] rather than assuming.
- Do not invent cycle times, error rates, volume figures, or percentages. If you reference a metric, use [INSERT METRIC FROM YOUR RECORDS].
- If any named input is missing or ambiguous, ask before drafting.
BEFORE YOU RUN IT
- A complete step-by-step description of the process as it works today, in the order the steps occur
- Every decision point: what the condition is, and what happens on each branch
- The role or job title that performs each step, not just the department
- Any systems, forms, or tools touched at each step, including their names
- Confirm that any metrics, volumes, or timelines you include come from your own records, not assumed by the AI
- Confidentiality: keep customer-specific data, proprietary system credentials, and personnel details out of the prompt
VERIFY BEFORE IT LEAVES YOUR HANDS
- Walk through the numbered step list against the actual process: confirm the sequence is correct and nothing is missing
- Every decision branch verified: confirm both the yes and no paths are complete and lead to the correct next step
- No AI-invented steps, systems, or role titles in the output: review for anything you did not provide
- Rework loops confirmed against how the process actually works: a loop described incorrectly in the map trains people wrong
- All [CLARIFY] flags resolved before handing the description to the diagram builder
- Diagram notes reviewed to confirm they reflect your organization's diagramming standards or tool requirements
Sample output
Sample output. Generated by AI from sample inputs:
PROCESS MAP DESCRIPTION
Organization: Northwind Distribution | Process: Purchase Order (PO) Approval
Process Overview
This process covers the review and approval of purchase orders before they are released to suppliers. It begins when a Buyer submits a draft PO in the Atlas procurement system and ends when the PO is either approved and transmitted to the supplier or rejected and returned to the Buyer for correction.
Step List
1. Buyer: creates draft PO in Atlas procurement system, attaches supporting quote. Output: draft PO record in Atlas.
2. Atlas system: routes PO to Procurement Manager for review based on PO value. Output: system notification to Procurement Manager.
3. Procurement Manager: reviews PO for accuracy (supplier, item, price, delivery date). Output: approval decision. [Decision point: see 3A/3B]
3A. If approved: Procurement Manager approves PO in Atlas. Proceed to step 4.
3B. If not approved: Procurement Manager adds rejection notes in Atlas and returns to Buyer. Rework loop returns to step 1.
4. Atlas system: transmits approved PO to supplier via EDI. Output: PO transmitted confirmation.
5. Buyer: confirms transmission in Atlas and files confirmation email. Output: closed PO record.
Decision Points
- Step 3 branch: Condition is whether the PO is accurate and within approved supplier and budget. Yes path leads to approval and step 4. No path returns PO to Buyer for correction (rework loop to step 1).
Rework Loops
- Rejection at step 3B returns to step 1. [INSERT AVERAGE REJECTION RATE FROM YOUR RECORDS] of POs cycle through this loop.
Diagram Notes
- Use a swim lane layout: one lane per role (Buyer, Procurement Manager, Atlas System).
- Decision diamond at step 3 with two exit arrows labeled 'Approved' and 'Rejected.'
- Rework arrow from step 3B back to step 1 should be clearly labeled 'Return for Correction.'
- Atlas system actions (steps 2 and 4) are automated: use a different shape (rectangle with rounded corners or system symbol) to distinguish from manual steps.
CUSTOMIZATION If your organization uses a specific diagramming tool (Lucidchart, Visio, draw.io), mention it in the prompt so the Diagram Notes section can reference its shape library. For complex processes with more than three swim lanes, consider breaking the process map into subprocess descriptions. Veterans mapping logistics or supply chain processes from military experience can describe the process in familiar terms and then replace military-specific system names with civilian equivalents.
KPI Definition Set
Defines a set of operational key performance indicators (KPIs) for a function or process, including formula, data source, owner, and target. Use it when standing up a new measurement system or when existing metrics lack clear definitions and owners.
FREE WITH ACCOUNT Operations Metrics Narrative
Writes a plain-language narrative explaining a set of operational metrics: what the numbers mean, what changed, and what comes next. Use it for monthly or quarterly operations reports when leadership needs context, not just a table of numbers.
FREE WITH ACCOUNT Process Improvement Proposal
Drafts a process improvement proposal describing a current problem, the root cause, the proposed change, and the expected outcome. Use it when you have identified a process gap and need to present a clear case for a change to leadership or stakeholders.
FREE WITH ACCOUNT Capacity Plan
Writes a capacity plan for an operational function: current capacity, projected demand, gaps, and options to close the gap. Use it when planning for a volume change, a new contract, or a staffing decision and you need a documented analysis to support the decision.
FREE WITH ACCOUNT Operational Root Cause Analysis
Runs a structured root cause analysis for an operational failure: documents the problem, organizes the evidence, walks through the cause chain, and identifies corrective actions. Use it after an incident, a missed metric, or a recurring failure to get to the real cause before acting on a symptom.
FREE WITH ACCOUNT Operations Runbook
Builds an operations runbook for a specific system or function: routine procedures, escalation paths, contact lists, and contingency steps in one reference document. Use it to document what your team does every day so someone else can run the operation when you are not there.
FREE WITH ACCOUNT Process Checklist Builder
Builds a process checklist for a specific operational task or procedure, with step verification and role assignments. Use it when a process needs a repeatable quality gate and a simple checklist does not already exist.
FREE WITH ACCOUNT Shift Handoff Procedure
Defines a shift handoff procedure for an operational function: what information must transfer, in what format, and how to verify the incoming team is ready to operate. Use it when handoffs are inconsistent, information is getting lost between shifts, or a new operation needs a standard transition process from day one.
FREE WITH ACCOUNT Standard Work Instruction
Writes a standard work instruction for a specific task at the operator level: the exact steps, the timing, the quality check, and the safety points. Use it when you need a document that a trained operator follows at the point of work, not a management overview of the process.
FREE WITH ACCOUNT Builds a structured plan to improve a specific operational process over a defined window. Use it when leadership has identified a process that is underperforming and wants a written plan with milestones, owners, and success measures.
ORGANIZATION NAME ·PROCESS NAME ·IMPROVEMENT WINDOW ·CURRENT STATE DESCRIPTION ·IMPROVEMENT OBJECTIVES AND TARGETS ·KNOWN CONSTRAINTS ·STAKEHOLDER ROLES
## Context
You are helping an operations manager or process owner draft a continuous improvement plan. The organization is [ORGANIZATION NAME]. The process being targeted is [PROCESS NAME]. The improvement initiative is scoped to [IMPROVEMENT WINDOW, e.g., 90 days or Q3]. The reader of this plan may be a team lead, department head, or oversight committee, so it must be clear without requiring operational jargon to follow.
## Task
Produce a continuous improvement plan with the following sections:
1. Problem statement. One paragraph. What the current process does, where it falls short, and the cost of leaving it unchanged. Use only facts from the inputs below.
2. Scope. What is inside and outside this initiative. Be explicit about what this plan does not touch.
3. Current state summary. The key steps of the process as it runs today, including the handoffs and known friction points: [CURRENT STATE DESCRIPTION].
4. Improvement objectives. Two to four specific, measurable targets. Base these on: [IMPROVEMENT OBJECTIVES AND TARGETS].
5. Planned actions. A numbered list of changes to implement, each with: the action, the owner by role (not name), the target completion date, and any dependency.
6. Milestones and check-ins. A cadence for reviewing progress over [IMPROVEMENT WINDOW].
7. Success measures. How you will know the improvement held after the window closes, stated as observable conditions or measurable thresholds.
8. Risks. Two or three things that could stall the plan, and a brief mitigation for each.
Inputs for the plan:
- Current state: [CURRENT STATE DESCRIPTION]
- Objectives and targets: [IMPROVEMENT OBJECTIVES AND TARGETS]
- Known constraints: [KNOWN CONSTRAINTS]
- Stakeholders involved: [STAKEHOLDER ROLES]
## Standards
- 500 to 700 words for the full plan. Each section under a bold header.
- Tone is direct and practical. Write for a team lead who will execute this, not a consultant who will review it.
- Do not invent baseline metrics, dates, dollar figures, or target percentages. Use only the numbers the user provides. If a target is stated as a range, keep it a range.
- Do not recommend specific tools, vendors, or methodologies unless the user names them.
- Improvement objectives must be phrased in terms of observable outcomes, not activities.
- End Standards: if any named input is missing or ambiguous, ask before drafting the plan.
BEFORE YOU RUN IT
- A plain description of the current process, including the steps, handoffs, and where breakdowns typically occur
- Specific improvement targets with the numbers or thresholds you are working toward, pulled from your own data or leadership direction, not AI estimates
- The time window and any fixed deadlines (quarter end, contract renewal, audit date) that set the pace
- The stakeholder roles who will own actions, review progress, and approve changes
- Confirm all baseline metrics, target figures, and dollar amounts come from your own records, not the AI
- Keep personnel names, vendor contract details, and sensitive cost data out of the prompt; use role titles and anonymized figures
VERIFY BEFORE IT LEAVES YOUR HANDS
- Confirm every metric and target in the plan matches what you provided, with no figures the AI invented
- Verify improvement objectives are observable outcomes, not just activity goals like 'hold a meeting' or 'review the process'
- Check that no specific tool, software, or vendor name appears unless you supplied it
- Confirm action owners are listed by role, not personal name, and the roles exist in your org
- Review the risks section: reject any risk the AI invented that has no basis in your actual context
- Verify the success measures can actually be observed or measured in your environment with your current data sources
- Recheck any date arithmetic in the milestones against the actual improvement window you provided
Sample output
Sample output. Generated by AI from sample inputs:
**Continuous Improvement Plan: Warehouse Inbound Receiving Process**
Organization: Northwind Distribution | Process: Inbound receiving | Window: 90 days (July 1 - September 30)
**Problem statement**
Northwind's inbound receiving process currently takes an average of 4.2 hours from dock arrival to system entry. That delay pushes fulfillment timelines past the 24-hour commitment on priority orders and has contributed to inventory discrepancies requiring manual correction. Leaving the current process unchanged risks continued fulfillment misses and inventory inaccuracy.
**Scope**
This plan covers the steps from carrier arrival at the dock through system entry and put-away confirmation. It does not cover outbound shipping, returns processing, or the purchasing workflow upstream of receiving.
**Current state summary**
Trucks arrive and wait for a dock assignment (avg. 45 min). A receiving associate unloads and counts manually (avg. 90 min). A separate associate enters counts into the inventory system (avg. 60 min). Discrepancies are flagged and held for a supervisor review that happens once per shift (avg. 60 min wait). The entire sequence runs 4+ hours when a supervisor review is triggered.
**Improvement objectives**
1. Reduce average dock-to-system time from 4.2 hours to under 2.5 hours.
2. Reduce discrepancy-hold events by 30% through cleaner count procedures.
3. Complete the put-away confirmation step on the same shift as receipt.
**Planned actions**
1. Cross-train one receiving associate per shift to handle both counting and system entry. Owner: Warehouse Manager. Deadline: July 15. Dependency: system access permissions.
2. Revise the count sheet to match the PO line sequence, reducing lookup time. Owner: Operations Analyst. Deadline: July 10. Dependency: none.
3. Shift supervisor discrepancy review from batch (once per shift) to on-demand (within 20 minutes of flag). Owner: Shift Supervisor. Deadline: July 22. Dependency: supervisor scheduling review.
4. Add a mid-shift dock assignment check to reduce wait time. Owner: Dock Coordinator. Deadline: August 1. Dependency: none.
**Milestones and check-ins**
- Week 2: Actions 1 and 2 complete. First data pull on dock-to-system time.
- Week 4: All actions live. Baseline comparison review.
- Week 8: Mid-point check-in. Adjust if discrepancy hold rate has not moved.
- Week 12: Final review against all three objectives. Decision on whether changes become permanent standard procedure.
**Success measures**
At 90 days, average dock-to-system time is at or below 2.5 hours for at least 80% of receiving events. Discrepancy-hold events are down at least 30% versus the 90-day baseline before the initiative. No priority orders missed fulfillment due to an unresolved receiving delay in the final 30 days of the window.
**Risks**
1. Staff turnover during cross-training. Mitigation: document the combined procedure before cross-training begins so institutional knowledge does not leave with a single person.
2. Supervisor scheduling constraints limit on-demand review response time. Mitigation: escalation path to a backup reviewer is defined before the new cadence goes live.
3. Count sheet revision requires IT or system access that takes longer to provision than expected. Mitigation: start the access request in week one, not after the design is finished.
CUSTOMIZATION For teams using a specific improvement methodology (Plan-Do-Check-Act, Lean, Six Sigma), name it in the prompt and the plan will align its structure accordingly. For smaller operations, the plan can be compressed to a one-page format by reducing the actions list to five or fewer items and skipping the formal milestones section. Veterans transitioning into operations roles will recognize this format as close to a corrective action plan or improvement annexure; the vocabulary is civilian but the structure is familiar.
5 Whys Analysis
Runs a structured 5 Whys root-cause analysis on a specific operational problem. Use it after an incident, a recurring defect, or a missed target to find the cause chain rather than treating the surface symptom.
FREE WITH ACCOUNT All 135 prompts in this library are free with a VetsLearn account: every prompt, every checklist, synced to your account.
Unlock free with an account → Value Stream Map Notes
Converts a description of a process into structured value stream map notes: the steps, cycle times, wait times, and improvement opportunities in a format ready for a mapping session or a Lean facilitator. Use it before a mapping workshop or when you need to document a current-state value stream without a visual tool.
FREE WITH ACCOUNT Service Level Definition
Drafts a clear, written service level definition for an internal or external service. Use it when a team needs to formalize what they deliver, how fast, and what happens when they miss, so both sides of the service relationship have the same expectations.
FREE WITH ACCOUNT Quality Control Checklist
Builds a step-by-step quality control checklist for a specific operation, product, or handoff. Use it when a process needs a repeatable inspection standard that any trained person can follow without relying on memory.
FREE WITH ACCOUNT Operational Incident Procedure
Writes a clear, step-by-step procedure for responding to a specific type of operational incident. Use it when a new incident type is identified, a past incident revealed a gap, or leadership requires documented response procedures for audits or continuity planning.
FREE WITH ACCOUNT Process Onboarding Guide
Writes a practical onboarding guide for a new team member taking on a specific operational process or role. Use it when someone new is joining a team, a role is transitioning, or an existing process has never been documented at the level needed to train someone.
FREE WITH ACCOUNT Process Audit Prep
Produces a structured preparation package for an upcoming process audit. Use it when an internal or external audit of a specific process is scheduled and you need to organize evidence, assign owners, and brief the team before the auditors arrive.
FREE WITH ACCOUNT Bottleneck Analysis
Analyzes a specific operational bottleneck: where it sits, why it backs up, and what the realistic options are to relieve it. Use it when a process is consistently failing to meet throughput, cycle time, or delivery targets and the location of the constraint is known or suspected.
FREE WITH ACCOUNT Process Standardization Plan
Produces a plan to standardize a process across multiple teams, sites, or shifts that are currently running it differently. Use it when variation in how a process is performed is causing quality gaps, training difficulty, or inconsistent results.
FREE WITH ACCOUNT Operations Dashboard Spec
Produces a written specification for an operations dashboard: what metrics it shows, the data sources, the update frequency, the audience, and the layout logic. Use it before building a dashboard to align stakeholders on what it should do, or to hand off requirements to a developer or analyst.
FREE WITH ACCOUNT All 135 prompts in this library are free with a VetsLearn account: every prompt, every checklist, synced to your account.
Unlock free with an account → No prompts match your search. Try a different word.