Best Prompts for Knowledge Management

Critical work often lives in an expert’s memory. The documented version, if it exists, may be a loose collection of meeting notes, screenshots, warnings, and exceptions. A new team member can read all of it and still not know where to start, what “done” means, or when to stop and ask for help.

Turning expert notes into a standard operating procedure can make the work easier to teach and review. The danger is producing a document that looks complete while quietly inventing missing steps.

Why ordinary prompting fails

“Turn these notes into an SOP” encourages an AI to smooth over gaps. It may choose an order the expert never intended, convert examples into universal rules, or omit the judgment calls that make the process work.

A reliable prompt must preserve source language where precision matters, distinguish required steps from suggestions, and mark every unresolved gap. It should treat the first draft as a document for expert validation, not as an approved procedure.

The prompt

Copy
ROLE
You are a knowledge-management specialist converting expert notes into a draft standard operating procedure. Your priority is faithful, usable documentation without inventing missing process knowledge.

REQUIRED INPUTS
- Expert notes, transcript, screenshots, or demonstration summary
- Process name and business purpose
- Intended user and assumed skill level
- Trigger for starting the process
- Systems, tools, templates, and access required
- Known inputs and expected outputs
- Approval, compliance, or quality requirements
- Known exceptions and escalation contacts
- Existing policies or related procedures

STEPS
1. Extract the stated purpose, trigger, prerequisites, inputs, outputs, roles, and completion criteria.
2. Arrange confirmed actions into a logical sequence while preserving dependencies from the sources.
3. For each step, identify the actor, action, system or artifact, expected result, and verification check.
4. Separate mandatory instructions, optional guidance, examples, warnings, and exceptions.
5. Identify decisions that depend on expert judgment and document the decision criteria if supplied.
6. Mark missing details as explicit questions. Do not fill them with typical practice.
7. Add checkpoints, failure handling, escalation paths, and evidence of completion where supported.
8. Produce a validation checklist for the expert and one for a first-time user test.

OUTPUT FORMAT
# [Process name]
## Document control
- Draft status:
- Process owner:
- Intended users:
- Source materials:
- Last reviewed:

## Purpose and scope
## Trigger
## Prerequisites and access
## Required inputs
## Roles and responsibilities
## Procedure
For each numbered step include:
- Owner
- Action
- Expected result
- Verification
- Warning or exception, if applicable

## Completion criteria and records
## Exceptions and escalation
## Troubleshooting
## Related policies and resources
## Open questions for the expert
## Expert validation checklist
## First-time user test checklist

EVIDENCE AND UNCERTAINTY RULES
- Use only supplied material for process facts.
- Cite the source note, timestamp, screenshot, or policy for consequential instructions.
- Mark inferred sequencing as “[Proposed order for expert review].”
- Mark missing information as “[Expert input required].”
- Do not convert one example into a general rule unless the source says it is standard.
- Do not claim the SOP is approved, compliant, or production-ready without documented review.

What to provide

Include more than a transcript if possible. Add the templates, screenshots, system names, policy links, example inputs, and example completed outputs used during the work. State who performs each part and who approves it. If access differs by role, document that too.

Ask the expert to explain exceptions and failure cases, not only the ideal path. Useful questions include: What commonly goes wrong? Which mistakes are reversible? What requires immediate escalation? Where does experience change the decision? These details often determine whether an SOP is genuinely usable.

How to review the output

Have the expert review every step for accuracy, sequence, and missing judgment. Pay particular attention to phrases such as “confirm,” “review,” or “process,” which can conceal several actions. Replace them with observable instructions.

Next, ask someone with the intended skill level to perform the procedure in a safe environment. Record where they pause, ask for clarification, or produce a different result. Update the SOP based on the test, then assign an owner and review date. A procedure without ownership will become stale.

Where it fails

Incomplete notes produce an incomplete SOP, even when the prose appears polished. The prompt also cannot determine whether a documented practice complies with law, policy, contractual terms, or system controls. Relevant specialists must review those requirements.

Some work resists strict standardization. If success depends on expert judgment, document the decision boundaries, examples, and escalation path rather than forcing a false checklist. Sensitive processes may also require careful handling of credentials, personal data, or confidential screenshots.

Practical takeaway

The goal is not to make expert work look simple. It is to make the known steps, checks, exceptions, and knowledge gaps visible. Use this prompt in Agentic Workers to create a structured draft, then validate it with both the expert and a first-time user before treating it as a working SOP.

<!-- X derivative: A polished SOP can still be wrong, so use a prompt that preserves expert evidence, flags missing steps, and requires a first-time user test. -->