AI Prompts for Operations and Process Documentation

Create a Standard Operating Procedure (SOP) document.

Process name: [NAME OF THE PROCESS]
Purpose: [WHY THIS PROCESS EXISTS]
Who performs it: [ROLE/TEAM RESPONSIBLE]
Frequency: [HOW OFTEN IT'S DONE]

Current steps (rough):
[LIST THE STEPS AS YOU UNDERSTAND THEM]

Tools/systems used:
[SOFTWARE, EQUIPMENT, OR RESOURCES NEEDED]

Create an SOP that includes:
1. Purpose and scope
2. Roles and responsibilities
3. Prerequisites (what needs to be in place before starting)
4. Step-by-step procedure (numbered, clear actions)
5. Quality checkpoints
6. Troubleshooting common issues
7. Related documents or resources

Write for someone who has never done this before. Each step should be one clear action. Use screenshots or diagram placeholders where helpful.

Create a checklist for a recurring process.

Process: [WHAT PROCESS IS THIS FOR]
Used by: [WHO USES THIS CHECKLIST]
Frequency: [DAILY / WEEKLY / PER PROJECT / ETC.]

Key steps to include:
[LIST THE MAIN THINGS THAT NEED TO HAPPEN]

Critical items (must not be missed):
[HIGHLIGHT THE MOST IMPORTANT STEPS]

Format the checklist with:
- Clear, action-oriented items (start with verbs)
- Logical grouping by phase or category
- Space for checkmarks/completion
- Notes field for any items that need it
- Date/name fields if it needs to be signed off

Keep items specific and verifiable. "Review document" is vague; "Check document for spelling errors and broken links" is checkable.

Create a meeting agenda.

Meeting purpose: [MAIN OBJECTIVE OF THIS MEETING]
Meeting type: [STANDUP / PLANNING / REVIEW / BRAINSTORM / DECISION]
Duration: [LENGTH IN MINUTES]
Attendees: [WHO'S ATTENDING AND THEIR ROLES]

Topics to cover:
[LIST THE TOPICS/ITEMS TO DISCUSS]

Decisions needed:
[ANY DECISIONS THAT MUST BE MADE IN THIS MEETING]

Pre-work required:
[ANYTHING ATTENDEES SHOULD PREPARE BEFOREHAND]

Create an agenda with:
1. Meeting objective (1 sentence)
2. Timed agenda items with owners
3. Discussion topics vs. information-sharing clearly marked
4. Time for questions
5. Action items capture section
6. Next steps

Total times should add up to meeting length. Include buffer for discussion.

Create a status report template.

Report type: [PROJECT STATUS / TEAM UPDATE / EXECUTIVE SUMMARY]
Audience: [WHO READS THIS]
Frequency: [WEEKLY / MONTHLY / ETC.]
Project/team: [WHAT THIS COVERS]

Information to include:
[LIST WHAT NEEDS TO BE REPORTED ON]

Create a template with:
1. Report header (period, author, date)
2. Executive summary (3 bullets max)
3. Overall status indicator (On Track / At Risk / Off Track)
4. Progress highlights
5. Challenges or blockers
6. Key metrics (if applicable)
7. Upcoming milestones
8. Decisions or input needed
9. Resource needs

Design it to be scannable. Busy readers should get the key points in 30 seconds. Include formatting guidance.

Create an onboarding guide for new team members.

Role: [JOB TITLE/ROLE]
Team: [TEAM OR DEPARTMENT]
Company: [COMPANY NAME]

Key things new hires need:
[LIST ESSENTIALS—ACCESS, TOOLS, KNOWLEDGE]

First week priorities:
[WHAT SHOULD THEY ACCOMPLISH IN WEEK 1]

Key people to meet:
[IMPORTANT CONTACTS AND THEIR ROLES]

Create a guide that covers:
1. Welcome and role overview
2. First day checklist (access, setup, introductions)
3. First week roadmap with daily goals
4. Key tools and how to access them
5. Important contacts and what they help with
6. Essential reading/documentation
7. 30-60-90 day expectations
8. FAQ for common new hire questions
9. Who to ask for what

Write in a welcoming tone. Reduce anxiety by being clear about expectations.

Document a workflow.

Workflow name: [NAME]
Purpose: [WHAT THIS WORKFLOW ACCOMPLISHES]
Trigger: [WHAT STARTS THIS WORKFLOW]
End state: [WHAT INDICATES IT'S COMPLETE]

People/roles involved:
[LIST ROLES AND THEIR PART IN THE WORKFLOW]

Systems/tools used:
[LIST TOOLS INVOLVED]

Current flow (rough):
[DESCRIBE THE STEPS AS THEY HAPPEN NOW]

Create documentation that includes:
1. Workflow overview and purpose
2. Trigger conditions (when does this start?)
3. Step-by-step process with role assignments
4. Decision points and criteria
5. Handoff procedures between roles
6. Expected timeframes for each stage
7. Exception handling (what if X goes wrong?)
8. Completion criteria
9. Diagram placeholder/description

Write for clarity. Someone unfamiliar should understand how work flows through the process.

Build a RACI matrix for a project or process.

Project/process: [NAME]
Goal: [WHAT THIS WORK IS MEANT TO ACHIEVE]

Key activities or deliverables:
[LIST THE MAJOR TASKS OR DECISIONS THAT NEED OWNERSHIP]

Roles/people involved:
[LIST EACH ROLE OR PERSON BY TITLE — NOT NAMES — AND WHAT THEY GENERALLY DO]

Known ambiguity:
[ANY ACTIVITIES WHERE OWNERSHIP IS CURRENTLY UNCLEAR OR CONTESTED]

Produce:
1. A RACI table — rows are activities, columns are roles, cells contain R / A / C / I (or blank)
2. A definition row explaining R/A/C/I in plain language for first-time readers
3. A rules checklist applied to the table:
   - Each activity has exactly one A (Accountable)
   - Every activity has at least one R (Responsible)
   - No role is loaded with A on more than ~30% of activities
   - Flag any row that violates these rules with a brief note on the fix
4. A short "decision rights" summary — for the 3 most critical activities, one sentence each on who decides and who must be consulted before the decision lands
5. Suggested cadence for revisiting the RACI (every quarter / when team changes / etc.)

Bias toward clarity over politeness. If the input suggests two roles both want to own something, name the conflict and propose a resolution.

Create a process improvement plan.

Process being reviewed: [NAME OF THE PROCESS]
Current pain: [WHAT'S NOT WORKING — DELAYS, ERRORS, COST, MORALE, ETC.]
Frequency: [HOW OFTEN THIS PROCESS RUNS]
Stakeholders: [WHO TOUCHES THIS PROCESS AND WHO IS AFFECTED BY ITS OUTPUT]

Current process as it actually runs:
[DESCRIBE THE STEPS HONESTLY, INCLUDING WORKAROUNDS]

Constraints:
[BUDGET, HEADCOUNT, SYSTEMS THAT CAN'T CHANGE, COMPLIANCE REQUIREMENTS]

Produce a structured improvement plan:
1. Current-state summary — process map in words (trigger → steps → end state), with cycle time and handoff count
2. Root-cause analysis — apply a 5-Whys pass on the top pain point; surface the actual driver vs the symptom
3. Improvement options — list 3 distinct approaches (e.g. eliminate a step, automate a handoff, change the trigger) with cost / effort / impact for each
4. Recommended path — pick one option and justify it against the constraints above
5. Implementation steps — sequenced tasks with owners, dependencies, and a realistic timeline
6. Success metrics — name 2–3 measurable indicators (cycle time, error rate, NPS, hours saved/week) with a baseline number and a target
7. Risks and mitigations — what could go wrong with the new process, and how to catch it early
8. Review checkpoint — when to assess whether the change worked

Default to small, reversible changes over large rebuilds unless the input specifically calls for a redesign.

Build a risk register for a project or initiative.

Project: [NAME AND ONE-SENTENCE DESCRIPTION]
Timeline: [START → KEY MILESTONES → END]
Budget / resources: [HEADCOUNT, BUDGET CEILING, KEY SYSTEMS INVOLVED]
Known concerns: [ANY RISKS THE TEAM HAS ALREADY VOICED]

External factors to consider:
[REGULATORY, MARKET, VENDOR, TECHNOLOGY DEPENDENCIES]

Generate a risk register with the following structure:
1. Risk inventory — at least 8 risks across these categories: technical, schedule, budget, people/resourcing, vendor/external, scope, compliance, organizational. Each risk gets a one-sentence description.
2. Scoring — for each risk, rate Likelihood (1–5) and Impact (1–5), and compute a Risk Score (L × I). Sort the register by score descending.
3. Mitigation strategy — for each risk, name the strategy: Avoid / Reduce / Transfer / Accept. One-line justification.
4. Action plan — for each High risk (score ≥ 12), specify: owner, mitigation action, trigger condition (what tells us this risk is materializing), and contingency plan (what we do if it does).
5. Monitoring cadence — how often the register is reviewed, who runs the review, and how new risks get added.

Be specific. "Resource constraints" is useless; "lead engineer is single point of failure on auth module" is actionable. Where the input is thin, name the gap rather than fabricating a risk.