LearnGrokUse this method when the same operational job is done differently across teams or sites. You will turn rough notes, screenshots and staff comments into one procedure map, then produce a document the operations lead can approve, assign and maintain.
The aim is not a polished description of the current process. It is an agreed working procedure that states who does each step, what they need, where they work, what control applies and who receives the result.
Key point
Map the work before writing the procedure
A useful procedure records the hand-offs and controls, not just the clicks in a system.
1. Set the process boundary
Start with one recurring process, such as supplier onboarding, daily stock reconciliation or incident escalation. Do not map a whole department at once.
Write a short boundary statement before collecting evidence:
- Start event: the event that begins the process.
- End result: the result that proves it is complete.
- Scope: teams, sites and systems included.
- Out of scope: adjacent work that belongs in another map.
- Process lead: the person who can settle disagreements and approve the final version.
For example, a purchase order approval process may start when a requester submits an approved requisition and end when the order is released to the supplier. Supplier invoice matching is a separate process, even if the same team handles it.
Watch out
Do not start with a flowchart
A diagram can hide missing owners and unclear decisions. Get the evidence into a step table first.
2. Collect evidence in one pack
Create a folder and put all source material in it. Give each item a clear name, such as North-site-order-notes.docx, Approval-screen-01.png or Warehouse-comments-2026-08.txt.
Include:
- Existing process notes, checklists and work instructions.
- Screenshots that show fields, status changes and system messages.
- Staff comments from the people who do and receive the work.
- Templates, forms, reports and email wording used in the process.
- Examples of completed work, with sensitive information removed where required.
Ask each contributor the same four questions: what starts your work, what do you receive, what do you do, and what proves you can hand it on? Ask what happens when the normal route fails. Exceptions are often where process ownership is weakest.
Upload or paste the material into the model you are using. If your available upload features or document handling differ, check the current xAI documentation.
Use this prompt:
Read these process notes, screenshots and staff comments. Do not create a final procedure yet.
Extract every stated or implied process step into a table with these columns:
Step number | activity | stated owner | input | system or location | output | next recipient | evidence source | uncertainty
Keep conflicting accounts separate. Mark anything not supported by the source material as "not evidenced". Do not guess missing fields.
Save this first output as evidence-register. It is your audit trail when someone asks why a step was included.
3. Resolve conflicts with the people doing the work
Review the evidence register for gaps before asking for a procedure. Look especially for steps with no owner, no output, or no next recipient.
Make a short issue list and take it to a working session with representatives from each team or site. Keep the discussion on observable work. Ask, “Who does this?”, “What triggers it?” and “What record shows it happened?” Avoid accepting “the team handles it” as an owner.
Use the following rules:
| If you find | Ask | Record in the map |
|---|---|---|
| Two teams claim the same approval | Who has final authority? | One accountable owner and any reviewer |
| A step differs by site | Is the difference required or accidental? | A standard step or a named local variation |
| A screenshot shows an extra field | Is it mandatory, conditional or unused? | The field and its control rule |
| Work moves by email or chat | What must the recipient receive? | The hand-off record and recipient |
Check
You have enough evidence when every step has a trigger and a recipient
If a step ends with “update the system” but nobody uses that update, the hand-off is incomplete.
4. Build the procedure map
Once the issue list is resolved, ask for a controlled draft. Keep the map as a table first. It is easier to approve and update than a diagram.
Use this prompt:
Using the evidence register and these confirmed decisions, create a procedure map.
Use one row per action. Include these columns:
1. step number
2. trigger or timing
3. action
4. owner role
5. input or prerequisite
6. system, form or location
7. control or check
8. output or record created
9. hand-off recipient
10. exception and escalation route
Use role names, not named individuals. State controls precisely, such as "check supplier ID matches approved record". If a point remains unconfirmed, label it "approval required" rather than inventing a rule.
A control is the check that prevents, detects or records an error. It is not a vague instruction such as “be careful”. Write what is checked, against what, and what happens if it fails.
A hand-off is complete only when the receiving role, item passed and expected action are all named. “Send to finance” is incomplete. “Send the approved purchase order PDF to the Accounts Payable queue for invoice matching” is usable.
5. Turn the map into an approval document
Create a document called Procedure - [process name]. Put the map in the main section, then add only the material needed to run and govern it:
- Purpose and process boundary.
- Roles and ownership, including the process lead.
- Procedure map.
- Exceptions and escalation routes.
- Required records, forms and system locations.
- Local variations, if approved.
- Review owner, approval date and next review point.
Ask the model to draft this document from the agreed map, but keep the table intact. A prose-only procedure makes ownership harder to scan during routine work.
Note
Separate standard work from local variation
Put a site-specific rule in its own labelled section. Do not quietly alter the core procedure for one team.
6. Check the draft against real work
Test the document with one person who performs the process and one person who receives a hand-off. Give them a recent, anonymised example and ask them to follow the map without explanation.
The output is wrong if any of these happen:
- They cannot identify who owns the next action.
- They need an unwritten spreadsheet, inbox or personal contact.
- A required field or approval appears in the system but not in the map.
- The stated control cannot be evidenced by a record.
- Two sites interpret the same step differently.
- An exception has no named escalation route.
Record each failure as a change against the relevant step number. Do not patch the prose around it. Correct the map, then regenerate the procedure document from the corrected map.
7. Assign and maintain it
Send the final document to the operations lead with a short approval request: confirm the process boundary, named role owners, controls, local variations and review owner. Once approved, publish one controlled copy in the location staff already use for procedures.
Tell each role owner which rows they own. Schedule the first review after the process has been used across the intended teams or sites. Review earlier when a system field, approval route, supplier rule or hand-off changes.
Stop
Do not publish a draft as the standard process
If ownership or an exception route is still unresolved, label the document as pending approval and keep it out of routine use.
If the process still will not map cleanly, reduce the scope. Map one hand-off or one approval route first. Bring back the evidence register and ask the process lead to decide the unresolved owner, trigger or control before producing another draft.
