The missing step is usually the one an expert stops noticing
Your colleague can handle an enquiry in five minutes. The written procedure takes a new starter twenty minutes and still leaves them asking for help. The difference is often a decision the experienced person makes without describing it: which record is current, when a request is unusual, or who can approve an exception.
AI can help organize an interview and turn it into a draft. It cannot supply the unwritten company rule merely because the transcript has a gap. A polished procedure with invented exceptions is worse than a rough note that identifies the right person to ask.
The conversation below is fictional. Mali and the equipment-rental business are teaching characters, not a reported DLVX project. The method is to extract a decision, test it, and revise the instruction until another colleague can use it.
Interview around a finished job
Interviewer: “Think of the last equipment booking you handled. What arrived first?”
Mali: “A message asking for Saturday delivery. I checked the sheet and confirmed it.”
A weak assistant turns that into two steps: check the sheet, confirm delivery. A useful interviewer asks which sheet, what “checked” means, and what would prevent confirmation.
Interviewer: “Which sheet? What did you check before replying?”
Mali: “The equipment register for the unit, then the dispatch calendar. A unit can be free even when the delivery team is full.”
Interviewer: “What if the customer already paid?”
Mali: “That still does not create a delivery slot. I ask the dispatch lead.”
Now the process has two constraints rather than one. Ask for a recent awkward case next. Do not ask the employee to invent the perfect policy while remembering everyday work. Record observations separately from rules needing a manager's decision.
The first draft should expose the unresolved rule
The assistant drafts: “Confirm equipment availability in the register. Confirm delivery capacity in the dispatch calendar. If either is unavailable, offer another date.” That is better, but it still assumes the person answering enquiries can offer a specific alternative.
Mali corrects it: “I can suggest that we check another day. I cannot reserve a slot without dispatch accepting it.” The verb changes from offer to request. This small correction prevents a customer promise that the next team cannot fulfill.
The draft now marks three states: requested, availability checked and confirmed. It also records the confirmation owner. A request does not become a booking because someone changed the wording in a message.
Ask who owns the two source records and how quickly they reflect changes. If the calendar can lag behind dispatch, the procedure must identify the confirmation route. Do not solve a source-quality problem by adding the sentence “ensure accuracy.”
A short procedure with a visible stopping point
- Open the enquiry and record the requested item, date, location and source message.
- If any required detail is missing, ask for that detail and leave the status as requested.
- Check the named equipment register and record the matching item reference.
- Check the named dispatch calendar for the requested delivery period.
- Send the proposed booking to the dispatch lead through the agreed queue.
- Confirm the booking to the customer only after dispatch accepts the slot and the authorized booking record is created.
- If either source conflicts or cannot be opened, assign the exception to the dispatch lead and tell the customer when the team will respond.
The exact tools and response promise would need to be filled in for a real company. An SOP with brackets still in those places is a draft. Its status should say so.
Add one example of a permitted acknowledgement: “I have your request for Saturday. Our dispatch team is checking the slot; I will confirm once that check is complete.” Use the organization's actual service promise rather than inventing a deadline.
Give it to someone who was not in the interview
A new colleague follows the draft using a synthetic booking. They find the equipment but discover two calendars with similar names. That is a documentation defect, not evidence they failed to read carefully. Add the precise approved link, access requirement and owner.
In a second test, the dispatch lead is away. The procedure names a role but no fallback. Add the accepted cover route, or explicitly hold the request until coverage is available. Do not invent a second person simply to make the document look complete.
In a third test, the customer changes the delivery location after dispatch accepted the slot. The original approval no longer covers the same request. Add a rule to reopen the capacity check when date, location or equipment changes materially.
Record each defect, the proposed correction and who accepted it. Stop when representative normal and awkward cases can be completed with the intended evidence and no invented authority.
Use AI to ask the missing questions
Turn this permissioned interview into a draft SOP. Separate observed practice, approved rule and unresolved question. For each step identify input, source, action, output and owner. Do not invent deadlines, permissions or exception rules. Ask about the last case that did not follow the normal path. Show the condition that pauses the process. Suggest three dry-run cases for a colleague who was not interviewed. Return a change log after we correct the draft.
Keep the transcript or approved notes with the draft when appropriate. If the interview contains customer details unrelated to the process, remove them before sharing it with an assistant. The example should preserve the operational difficulty without carrying unnecessary personal information.
The useful output is not the longest document. It is the shortest set of instructions that survives the dry run and points to the correct source when the world changes.
Decide who keeps it true
Publish an owner, an effective date and a reason to review the procedure. Useful triggers include a changed booking system, a changed permission, or repeated questions that the document does not answer. A monthly reminder alone can become a ritual in which nobody checks the actual work.
Keep previous versions as clearly marked history. Staff should reach one current procedure from the place where the work begins. When a rule changes, update the instruction and the examples together. Otherwise someone can follow an obsolete example while believing they obeyed the new rule.
This is an editorial method, not a claim that a framework certifies your SOP. NIST's AI Risk Management Framework provides broader risk-management context. For your next step, record one experienced colleague explaining one completed job, then ask a different colleague to execute the resulting draft on a synthetic case.
Sources and dates
Sources checked on 20 October 2026. Worked examples are teaching examples unless explicitly attributed. Provider documentation describes product behaviour; the operating recommendations are DLVX editorial judgement.
- NIST: AI Risk Management FrameworkA voluntary framework for managing AI risks; it does not certify the processes or examples in this guide. Checked 2026-10-20.