Guru SOPs: Write, Review, and Maintain Team Procedures

A useful Guru SOP is a maintained standard operating procedure: it tells someone when to start, which steps to follow, when to stop, and how to check the result. Write a small procedure, test it with someone who did not author it, and assign responsibility for keeping it accurate.

Tools like fenbs keep the approved working rules and improvement tasks available to connected AI assistants, while the procedure itself can stay in Guru. That distinction helps an assistant follow today’s instructions without treating a proposed change as already approved.

How do you draft the first procedure in Guru?

1. Choose one repeatable activity with a recognizable starting point and result.
2. Write the required inputs, the person responsible, and the conditions where the procedure applies.
3. List the actions in order, including checks and escalation points.
4. Place the draft in the appropriate Guru Collection and ask a reviewer to walk through it.
5. Publish the approved version and record how changes and exceptions will be handled.

For example, a small design studio could document how it prepares a client deliverable for review. Start when a draft is ready; finish when the correct reviewer has the files, the review request, and a clear decision to make. Exclude creating the design itself if that is a separate process.

Guru’s Card documentation↗ (opens in a new tab) explains drafting, collaboration, and publishing. It also describes requesting publication approval when that workflow is enabled. Confirm your workspace setup before making a particular approval route part of the procedure.

What information makes a procedure executable?

Give the reader enough detail to act without relying on unwritten experience. “Send for approval” is incomplete if the person does not know who approves, what to send, or how approval is recorded. Name the input, action, expected result, and next step for each point that could cause confusion.

Use a SOP template when a blank page is slowing you down, then remove fields that do not help this particular activity. A template supplies prompts, not evidence that your process works. The best test remains a person performing the task from the instructions.

Keep the procedure close to the knowledge it depends on. Guru’s Collections documentation↗ (opens in a new tab) explains its top-level organization. Choose a clear home and link to related policies instead of maintaining several slightly different copies of the same instruction.

How do you test a draft before approving it?

Ask someone unfamiliar with the procedure to explain what they would do first, which inputs they need, and when they would stop. Then have them work through a safe example while the author observes. Do not fill every gap aloud; record the missing instruction so the document improves.

Test an ordinary case and an exception. In the studio example, the ordinary case has a complete review package; the exception has a missing requirement or conflicting feedback. A procedure that works only when nothing goes wrong leaves the most consequential judgment undocumented.

• Record the exact point where the reader needed extra explanation.
• Check that every required source opens for the intended audience.
• Verify that the named reviewer can actually perform the approval.
• Compare the final result with the stated completion condition.
• Resolve important gaps before treating the procedure as ready.

Save the check result with the improvement task. fenbs can keep that task and the human decision behind the accepted procedure in the same project record; its shared work workflow makes the reasoning available to the next assistant.

Who owns review after the procedure is published?

Name a process owner, even when several people contribute. That owner should know what changes make the procedure unsafe to rely on, such as a new approval authority or a different required input. The person editing the wording need not be the person authorized to change the underlying process.

Guru’s verification guide↗ (opens in a new tab) describes assigned verifiers and configurable review intervals. Use those settings deliberately. Also establish event-based review in your working practice: when the real process changes, inspect the affected instruction rather than waiting for a periodic review.

Ask the reviewer what they checked. “Reviewed the escalation contacts against the current responsibility list” is more useful than “looks fine.” A recent review date cannot explain whether anyone checked the step that actually changed.

How should teams handle exceptions and improvement ideas?

Record an exception separately from a new rule. A manager might authorize a particular deliverable to skip an internal review under specific circumstances. That does not establish that all future deliverables can skip it. Keep the scope and approving person explicit so the next assistant does not generalize the exception.

For a proposed improvement, record the problem, the suggested change, and what would test it. Leave the proposal open until a person decides. After approval, update the procedure and the work record together so an assistant does not read a new decision beside an obsolete instruction.

How to do this with fenbs

1. Create a free account, free for one person with no credit card, and add the project whose procedure you want to improve.
2. Add a task for the draft, test, or revision, with a link to the appropriate Guru source and the unresolved problem.
3. Record the human-approved requirements in Decisions and rules. Leave suggested changes open until a person decides.
4. Connect a supported AI app through Integrations, ask it to read the rules before working, and save the checked results and next step.

fenbs does not connect to Guru or monitor its procedures for changes. It is not the right fit when you only need a place to publish reference instructions. Use it when assistants also need the decisions, lessons, and unfinished work around those instructions.

How do you prevent procedures from becoming shelfware?

Make feedback part of using the procedure. Ask the person completing the work to flag a missing input, confusing action, or unnecessary handoff. Review those observations with the process owner and revise the smallest useful part, then check the result on the next run.

A readable procedure supports your agile workflow, while workflow automation tools address execution only after the steps are clear. See Guru onboarding for introducing procedures to new teammates and the Guru Slack workflow for capturing discussion. More shared-work practices are in the team brain library.