LearnGrok
← Prompts
PromptIntermediateBuilding on the API

Process runbook from working notes

Build an approval-ready process runbook from frontline notes, interviews and screenshots. For operations leads standardising repeat work.

5 min read

You can turn scattered frontline material into a runbook that someone else can follow and a process owner can approve. This pack is for operations leads standardising a recurring internal process, such as supplier onboarding, daily reporting or case triage.

Start with the material people actually use. That usually includes interview notes, screenshots, a checklist copied between teams and notes explaining what happens when the normal route fails. Do not begin by asking for polished prose. You need evidence first.

Key point

Build the evidence before the procedure

A neat runbook built on assumptions is harder to fix than an incomplete draft that exposes its gaps.

1. Assemble one source set

Create a working folder or document for one named process. Give each item a source label, such as Interview: warehouse lead, 14 May or Checklist: month-end close v3. Keep the original wording where it describes an approval, a system field or an exception.

Collect these items before using the first prompt:

  • The process name and business purpose.
  • The accountable process owner and the roles doing the work.
  • Interview notes from at least the person performing the work and the person receiving its output.
  • The current checklist, however incomplete.
  • Screenshot images, or written descriptions of each screen and visible field.
  • Exception notes, incident summaries or messages that show where the routine process breaks.
  • Examples of inputs and completed outputs, with sensitive content removed where needed.

Paste the material into Source inventory and gap log. Its job is not to produce a runbook. It separates supported facts from conflicting accounts and missing information.

Watch out

Do not treat screenshots as proof of the rule

A screenshot can show a field or status. It may not show who is allowed to change it, when to use it or what happens next.

2. Draft the procedure from confirmed evidence

Resolve the high-impact conflicts from the evidence register first. A conflict about who approves an exception matters more than a difference in button labels. If the owner cannot answer immediately, leave the point open and label it clearly.

Then use First runbook draft. Paste the evidence register alongside the original notes, rather than only the register. The register tells you what is uncertain. The notes give the process owner the wording and context needed to decide.

The resulting procedure should make each action testable. A useful step names:

  • The role that performs it.
  • The input received or checked.
  • The system, spreadsheet or document used.
  • The action, including the field or status where known.
  • The expected result.
  • The record that proves the step happened.

Avoid instructions such as “process the request” or “check the details”. Replace them with the actual action, such as checking the supplier identifier against the request form and saving the approved form in the named case record. If the field name is not known, retain UNCONFIRMED and ask the owner.

3. Add controls before seeking approval

A runbook is not complete because it describes the happy path. It must show where an error is prevented, detected or passed to the right person. Use Control and exception review after the first draft.

Look especially for these gaps:

  • A request can be completed with no record of who checked it.
  • An operator has no rule for an incomplete or contradictory input.
  • The same person can create, approve and close an item without any stated review.
  • A handover has no named recipient or acceptance check.
  • An exception says “escalate” but gives no role, information pack or condition for resuming work.

Note

Keep controls proportionate

The control evidence should be something the team can retain during normal work, such as a status change, approval record or saved checklist.

Where an existing note describes a control, include it as an existing control. Where you recommend a new one, mark it PROPOSED. This distinction helps the owner approve a real operating procedure rather than accidentally approving assumptions.

4. Test it with a real case

Choose a recent, typical case. Remove personal, commercial or other sensitive details before pasting it. Include the input values, the documents available at the start and any screenshots that show the expected route.

Run Frontline walkthrough test. This is the fastest way to find the information that experienced staff carry in their heads. The tester should be able to identify which document to open, which fields to examine, which decision applies and where to save evidence.

Check

The procedure is usable when a trained colleague can complete the example without asking what a step means

If they must ask which queue, status, template, owner or exception route applies, the runbook still has a gap.

A walkthrough result of PASS WITH GAPS can be acceptable for a draft, but not for a procedure that is about to replace informal guidance. Fix every BLOCKER first. Record improvement work separately so it does not delay a decision on the critical path.

5. Put decisions in front of the owner

Use Owner approval pack once the draft, control review and walkthrough are available. Send the process owner the short approval summary, decisions requested and open questions, along with the full runbook. Do not ask them to infer the decisions from a long document.

The owner should explicitly confirm:

  1. The trigger and completion condition.
  2. Role ownership and approval authority.
  3. The required inputs and records to retain.
  4. Controls and escalation routes.
  5. The unresolved questions, their owners and the next review point.

For product behaviour, supported input formats and version-dependent capabilities, check the xAI documentation overview before setting a standard team workflow.

When the output does not work

Go back to the source that should answer the question. If roles are unclear, interview the person who receives the handover and the owner who accepts the result. If a screen instruction is unclear, capture the relevant screen and describe the visible labels. If exceptions are vague, use a real incident and ask who decided, what they needed and how normal work resumed.

Do not patch the runbook with confident wording. Add the missing evidence, rerun the relevant prompt, then repeat the walkthrough on the changed steps.

Copy-ready prompts

5 prompts. Open one to read it, or take the whole pack.

1Source inventory and gap logUse this first when your evidence is spread across interviews, screenshots, old checklists and exception notes.
You are preparing evidence for a process runbook. Review the source material below. Do not invent missing process details.

Process name: [process name]
Business purpose: [what the process is meant to achieve]
Process owner: [name or role]
Interview notes: [paste interview notes]
Existing checklist: [paste checklist]
Exception notes: [paste exception notes]
Screenshots and screen descriptions: [paste screenshots, OCR text, or descriptions]
Related documents: [paste links, extracts, or document names]

Return a Markdown evidence register with these sections:
1. Confirmed facts: a table with columns `Process area`, `Confirmed detail`, `Source`, and `Confidence`.
2. Conflicts: a table with columns `Topic`, `Statement A`, `Statement B`, `Sources`, and `Decision needed`.
3. Missing information: a table with columns `Runbook field needed`, `Why it matters`, `Question for`, and `Suggested owner`.
4. Screenshot findings: list visible screen names, fields, buttons, status labels and warnings. Mark any unreadable or uncertain text as `UNCONFIRMED`.
5. Proposed process boundary: state the likely trigger, completion condition, and items that appear outside scope.

Treat a detail as confirmed only where a source explicitly supports it. Where sources disagree, preserve both statements and ask a clear question. Do not write procedural steps yet.
2First runbook draftUse this after you have assembled the evidence and want a complete draft for the process owner to review.
Create a draft operational runbook from the evidence below. The audience is a trained colleague who must run this recurring internal process without relying on the original note-takers. Do not make up systems, timings, approval rules, owners or controls.

Process name: [process name]
Purpose: [business purpose]
Process owner: [role or name]
Evidence register: [paste completed evidence register]
Interview notes: [paste relevant notes]
Current checklist: [paste current checklist]
Exception notes: [paste exception notes]
System screenshots or descriptions: [paste material]

Return one Markdown document with exactly these sections:
1. `Process summary`: purpose, trigger, completion condition, frequency if evidenced, and scope.
2. `Roles and responsibilities`: a table with `Role`, `Responsibility`, `Decision authority`, and `Handover point`.
3. `Inputs and outputs`: a table with `Item`, `Source`, `Required fields or checks`, and `Recipient or storage location`.
4. `Procedure`: numbered steps. Every step must state the responsible role, action, system or document used, input, expected result, and evidence to retain.
5. `Controls`: a table with `Control`, `Step number`, `What to check`, `Evidence`, and `Control owner`.
6. `Exceptions and escalation`: a table with `Condition`, `Immediate action`, `Escalate to`, `Information to include`, and `Resume condition`.
7. `Open questions for approval`: numbered questions, each tagged `BLOCKER`, `IMPORTANT`, or `MINOR`.

Use `UNCONFIRMED` wherever the evidence does not establish a fact. Do not hide ambiguity inside a confident instruction. Keep instructions concrete, for example name the field to complete or record to save when that information is available.
3Control and exception reviewUse this when the procedure exists but you need to find weak checks, missing evidence and unclear escalation routes.
Review the draft runbook below for operational control gaps. This is an internal process review, not a policy or compliance opinion. Base findings only on the text supplied.

Process name: [process name]
Process owner: [role or name]
Runbook draft: [paste runbook]
Known incidents or exception notes: [paste incidents and exception notes]

Return Markdown with these sections:
1. `Control coverage`: a table with `Risk or failure mode`, `Related step`, `Existing control`, `Gap`, `Recommended control`, `Evidence to retain`, and `Owner`.
2. `Exception coverage`: a table with `Exception`, `Is the trigger clear?`, `Immediate action`, `Escalation route`, `Decision needed`, and `Missing detail`.
3. `Segregation and handover checks`: list any step where the same role appears to initiate, approve and close an item, or where an ownership handover is unclear.
4. `Priority fixes`: a numbered list of no more than 10 changes, ordered by operational impact.
5. `Questions for the process owner`: concise questions that can be answered with a fact, a named owner, or a decision.

If the runbook gives no evidence for a proposed control, label it `PROPOSED`, not existing. If a risk is plausible but not evidenced, label it `ASSUMPTION` and explain what source would confirm it.
4Frontline walkthrough testUse this before approval, with a realistic recent case, to test whether a colleague could follow the runbook.
Test this runbook against the worked example below. Act as a new trained operator who has the runbook and the stated inputs, but no access to the people who wrote it. Do not assume unstated knowledge.

Process name: [process name]
Runbook: [paste runbook]
Worked example or recent case: [paste anonymised case details]
Available inputs and screenshots: [paste files, field values, and screenshot descriptions]

Return Markdown with these sections:
1. `Walkthrough result`: state `PASS`, `PASS WITH GAPS`, or `FAIL`, followed by a two-sentence reason.
2. `Step-by-step test`: a table with `Runbook step`, `Can the operator perform it?`, `Evidence from the example`, `Missing instruction or input`, and `Suggested wording`.
3. `Field and document checks`: list every field, attachment, identifier, status and saved record the operator must use. Mark each as `AVAILABLE`, `UNCLEAR`, or `MISSING`.
4. `Decision points`: list each choice an operator must make, the information needed, and whether the runbook supplies a rule.
5. `Changes required before approval`: numbered list, separating `BLOCKER` from `IMPROVEMENT`.

Where the worked example differs from the documented procedure, report the difference. Do not alter the procedure to fit the example without flagging it.
5Owner approval packUse this when the draft has been reviewed and you need a short decision document for the accountable owner.
Prepare an approval pack for the process owner using the materials below. Keep the content factual and decision-focused. Do not claim that a control, owner or process detail is approved unless the material says so.

Process name: [process name]
Process owner: [role or name]
Runbook version or draft date: [version or date]
Current runbook: [paste runbook]
Control review: [paste review]
Walkthrough test: [paste test result]
Outstanding evidence gaps: [paste gaps]

Return Markdown with exactly these sections:
1. `Approval summary`: purpose, scope, trigger, completion condition, and intended users, in no more than 150 words.
2. `Decisions requested`: a table with `Decision`, `Why it is needed`, `Options`, `Recommended decision`, and `Approver`.
3. `Open questions`: a table with `Question`, `Priority`, `Impact if unresolved`, `Proposed owner`, and `Target response`.
4. `Approval checklist`: bullets covering roles, inputs, procedure, controls, exceptions, records to retain, training or handover, and review date. Mark each `READY`, `OPEN`, or `NOT EVIDENCED`.
5. `Approval record`: fields for `Approved by`, `Role`, `Date`, `Conditions of approval`, and `Next review`.

Use `NOT EVIDENCED` rather than guessing. If there are blockers, begin the approval summary with `Approval should be withheld until the listed blockers are resolved.`

Quick question about the API?

Short answers from the API pages here, with the page itself one tap below. Limits, models and prices go to xAI’s documentation, because those change and this does not chase them.

Last checked against xAI’s own pages on 2026-08-21. Grok changes quickly; anything version-specific should be confirmed upstream before you rely on it.

More in Building on the API

WorkflowIntermediate

Shift handover log for daily control

Create a checked shift handover log from notes, open issues and pending checks. For operations managers and shift leads.

Building on the API6 min read

WorkflowIntermediate

SOP update brief for process approval

Produce an SOP update brief from staff feedback and process changes, for operations leads keeping process documents current.

Building on the API6 min read

WorkflowIntermediate

KPI exception report for weekly review

Produce an evidence-led weekly exception report from an operations export, ready for analysts and managers to assign actions.

Building on the API7 min read

Found something out of date?

Grok changes quickly and this page is a snapshot. If something here is wrong, or you know a better resource, send it over.

Suggest a link →

Advertise on LearnGrok

$420.69one-time, for a 30-day run

Square works best. PNG, JPEG or WebP, up to 2 MB.

Stripe on the next step. Live once approved.