SOP writing for startups without bureaucracy

SOP (standard operating procedure) writing for startups is the habit of turning a repeated process into a short, owned page before the second person has to reverse-engineer it from Slack. Bureaucracy is a long wiki nobody opens. A useful SOP is a page someone follows on a busy Tuesday.

Keep the first version to one screen. Name an owner and a review date. Cut anything you cannot teach in five minutes.

Why SOP writing for startups starts with a trigger, not a wiki

Blank template libraries create empty folders. A trigger creates a page with a reason. When the same work appears twice in a month, or when a handoff fails twice, write five steps and an owner.

Illustrative miss (composite only): a shared drive full of "SOP - Draft" files; none named to a role; onboarding still happens in DMs.

Illustrative win (composite only): after the second refund exception, a one-page refund SOP with owner, steps, and a Friday proof of who followed it.

YC essential startup advice favors focus over process theater (Y Combinator Library, checkedOn 2026-11-01). Treat SOP writing for startups the same way: fewer pages, clearer owners, faster loops. The goal is repeatable execution, not a documentation scorecard for investors.

If a page does not change how someone acts tomorrow, delete the draft instead of "improving" the template library.

Write the trigger that caused the page at the top in one line. Future editors should know why the SOP exists without a meeting.

Use a trigger table before you open a blank doc

Illustrative trigger (composite only): two people ask how to publish a changelog; write the SOP the same day; delete three conflicting Notion pages.

If the table says no, do not create a draft SOP "for later." Later pages become wiki debt.

Founders often write SOPs after a painful week. That is fine. Still apply the trigger table so one bad week does not create twelve unused pages.

Share the draft with one operator before you publish it as final. A five-minute walkthrough catches missing steps faster than a polish pass alone.

Write the page so a stranger can finish the job

Structure every SOP the same way so people recognize the shape. Familiar structure lowers the cost of reading a new page:

1. Title named to the job, not the department ("Issue a refund under $200", not "Finance stuff").
2. Owner role (and backup role).
3. When this SOP applies / when it does not.
4. Steps in order, each starting with a verb.
5. Tools and links to the live system of record.
6. Definition of done and what to log.
7. Review date (30 or 90 days).

Illustrative page (composite only): "Publish weekly changelog"; owner Marketing lead; steps open repo → draft → review → post; done when the public URL is in the CRM note.

Keep screenshots sparse and dated. Prefer links into the live product over pasted UI that goes stale. When the UI changes, update the link the same week; do not leave a gallery of obsolete clicks.

Number steps. Letters and bullets hide order when two people work the page in parallel.

Name tools by the label people see in the product, not by internal nicknames. "Finance tool" forces a hunt; the real module name does not.

Illustrative stranger test (composite only): hand the draft to someone who never ran the job; if they stall twice, rewrite the stalled step before you call the page done.

Put ownership next to the page where work starts

Every SOP needs a named role that may edit it and a named role that must follow it. Name the owner by role, not by a person who might leave next quarter, so the page stays assignable when the team changes. Write the role the same way it appears in your org chart or hiring plan. If editor and follower are the same person forever, the page is still a founder diary. Assign a backup before the owner goes on leave.

Store SOPs where the work happens. If refunds live in your billing tool and chat, the SOP link belongs in both places. A binder nobody opens during the job is decoration.

Illustrative ownership (composite only): refund SOP owned by Finance; CS may propose edits; backup is COO; link pinned in the refund channel topic.

If two teams share a process, pick one owner role anyway. Shared ownership without a name is how conflicting edits appear.

When an SOP changes after a real result, record what you learned. In Nautis, finished work with a real result can become a learning event in Learning Engine: similar past actions, distilled lessons, and source-linked recommendations. Anyone with read permission can browse events and recommendations; update permission is needed to accept or reject recommendations and to record realized outcomes. Claims link back to source records. Use that loop when an SOP change followed a GTM experiment, a hire, or a completed outcome, not as a substitute for writing the SOP itself.

Keep SOPs short enough to rehearse

Cap body length. If you need appendices, link them. The operating page should be rehearse-able: read aloud in under three minutes. Prefer short steps, named tools, and explicit exits over narrative paragraphs that bury the action. A one-page SOP that people follow beats a ten-page manual that sits unread.

Cut policy essays. Policy belongs in a handbook section; the SOP is the how. Cut tool tours. Link the tool. Cut history. Put history in a changelog at the bottom with dates.

Illustrative cut (composite only): 1,800-word onboarding essay becomes 9 steps plus three links; history moves to a dated appendix.

Review on the date written on the page. If nobody used the SOP since the last review, archive it or merge it. Volume of pages is not a maturity metric.

During review, run the steps once. Reading is not rehearsal. Broken links count as a failed review until fixed.

Connect SOPs to real work without a parallel system

Use SOPs beside the systems you already run. For multi-step company goals that spawn boards and checkpoints, Outcome Workflows under Strategy & Planning can turn a declared goal into an ordered plan. After you click New outcome and Create outcome, the outcome starts as a Draft. Generate plan proposes steps (often including Task Board, Task, Document, Metric, Agent, Notify, and Checkpoint). Steps that touch the outside world pause for approval. Approve & start runs the plan in order. That machinery is for cross-module execution plans, not for replacing every five-step SOP. Create permission is required to declare an outcome; update permission to generate plans, edit, start, approve, or abandon. Plans lock once a workflow is running. If no matching workflow exists for a larger goal, note that gap beside the SOP and declare the outcome in the same week so the short page and the long plan do not drift apart.

Illustrative split (composite only): "Raise awareness this quarter" may become an Outcome Workflow; "Post the weekly changelog" stays a one-page SOP.

Do not invent a parallel SOP product inside chat. Link the page. When a step needs a durable decision, write the decision with an owner and date rather than a thumbs-up emoji.

If a Checkpoint or approval step appears inside an Outcome Workflow, keep the related SOP linked from that step description so operators are not guessing which page is current.

Ship one SOP this week, then stop

Pick the loudest trigger from the table. Write the seven-part page. Link it where the work starts. Rehearse it once with a second person. Set the review date.

Illustrative ship (composite only): refund SOP published Tuesday; CS runs it Wednesday on a live ticket; two edits the same day; review date plus 30 days.

Measure success by whether a second person completes the job without a founder call, not by word count or template count.

Stop after one shipped SOP this week even if the trigger table shows three candidates. Sequence beats a batch of drafts.

List open SOPs once a month in a single index with owner and review date. An index is not a second wiki; it is a roster so expired pages get archived. If the index grows past twenty active pages for a ten-person company, you are documenting theater instead of work.

Illustrative index (composite only): twelve active SOPs; three archived after unused reviews; owners listed by role; next review dates visible without opening each page.

SOP writing for startups compounds when each page earns its keep. Add the next SOP only when a new trigger fires. When Learning Engine shows a recommendation that conflicts with a live SOP, treat the SOP update as a deliberate edit with an owner, not an auto-merge. Accept or reject the recommendation with update permission, then change the page in the same sitting.

Count unused pages quarterly. If a SOP has had no opens and no edits in ninety days, archive it with a one-line reason. Archiving is honesty, not a sign that writing SOPs failed. Teams that never archive end up with a graveyard that trains people to ignore the whole folder.

Broader product docs sit in the Help Center. Plan limits for related modules appear in-product; see pricing for plan context.