System SOP · Confidential

The SOP Library &
Dashboard

How Merj creates, stores, publishes, and maintains every internal SOP — and how the team finds them. This is the operating manual for the knowledge system itself.

Version 1.0 · July 2026 Owner Chief of Operations Applies to every Merj SOP

Read this first — the one rule

One source of truth for each thing. Every SOP file lives in exactly one place (the repo). The catalog of all SOPs lives in exactly one place (the Dashboard). Basecamp only ever links — it never stores a second copy or a second list. If you ever find yourself pasting a SOP into two places, stop: link instead. This single rule is what keeps the whole library from rotting into stale duplicates.

Acronym Guide

SOP Standard Operating Procedure
DRI Directly Responsible Individual
HQ The Merj HQ Basecamp project
URL The web address a SOP lives at
DNS Domain settings (points the subdomain)
CI/CD Auto-publish on save (Git → Netlify)
KB Knowledge Base
Repo The Git repository (master files)

01 · What This System Is

Three jobs, kept separate, each with one home. That separation is the whole design.

A knowledge system dies when the same information lives in two places and quietly drifts apart. We avoid that by splitting the library into three distinct jobs and giving each exactly one home. Nothing is ever duplicated — everything else is a link.

LayerIts one jobWhere it lives
StorageHold the master copy of every SOP, with full version historyThe Git repo (source of truth)
Index & searchThe searchable map of every SOP — title, owner, version, linkThe Dashboard
WorkflowWhere the work actually happens; surfaces SOPs in contextBasecamp

The mental model

The file lives once. The catalog lives once. Basecamp links. Get those three straight and everything else in this SOP follows.

02 · Where Everything Lives (The Toolchain)

Six pieces, each with a clear owner. Most of it runs itself once set up.

PieceToolWhat it doesOwner
AuthoringClaude (Cowork)Creates & edits the SOP as branded HTML from the master templateClaude + the SOP's DRI
Source of recordGit repository (merj-sops)Holds every master file with dated, reversible version historyKarina
PublishingNetlify (CI/CD)Watches the repo and auto-deploys every change in secondsAutomatic
The siteteam.merj.marketingThe password-gated home of the live SOPs + the DashboardKarina
Index / searchThe DashboardSearchable catalog + new-hire onboarding tracks — the front doorKarina
WorkflowBasecampWhere work happens; links out to the SOPs it needsWhole team

Why a separate site instead of WordPress or Basecamp

The live SOPs sit on their own subdomain (team.merj.marketing) served by Netlify — not on the WordPress marketing site and not stored inside Basecamp. That keeps the public site untouched, lets Claude-authored HTML publish the instant it's saved, and keeps one clean, searchable home for the team. WordPress stays at www; Basecamp stays the place work happens.

03 · The Lifecycle: Create → Store → Publish → Update

Because publishing is automatic, the whole loop collapses to "Claude edits the file and saves it."

StepWhat happensWhere
1 · CreateClaude drafts the SOP from the master template; the DRI reviews the contentClaude (Cowork)
2 · StoreThe finished HTML is committed to the repo — this is the versioned masterGit repo
3 · PublishNetlify sees the commit and deploys automatically — live in ~20 seconds at a stable URLNetlify → team.merj.marketing
4 · IndexThe SOP's entry (title, owner, version, link) is added to the Dashboard catalogDashboard
5 · LinkBasecamp tasks that use the SOP link to its URL; HQ pins the DashboardBasecamp
UpdateEdit the HTML → commit → auto-republishes at the same URL, new versionClaude → Git → Netlify
Definition of "Published & Live"every SOP
A SOP is not "done" until all of these are true
  • Built from the master template, with its ID, owner, and version set
  • Committed to the repo — the source of truth is updated
  • Netlify deploy succeeded — it opens at its stable URL
  • Its entry exists (or is updated) in the Dashboard catalog
  • It's linked from Basecamp wherever the work actually uses it

04 · How the Dashboard Works

The single front door: one page where the team searches, filters, and self-serves — including new hires.

The Dashboard is the only catalog of Merj SOPs. It doesn't store the documents — it maps them. Open it and you can:

Doubles as the team onboarding hub

The Dashboard carries role-based "Start Here" tracksNew Strategist, New Account Manager, New Content Producer — each an ordered path through the SOPs that role needs in its first two weeks, plus the brand assets and this system SOP. A new hire lands on one page and runs their own onboarding.

05 · How Basecamp Fits In (Link, Don't Duplicate)

Basecamp is where work happens — not a second catalog. It links; it never copies.

The temptation is to rebuild the SOP list inside Basecamp. Don't — that's the exact duplication this system avoids. Basecamp connects to the library in just two ways:

1

One pinned door

The Merj HQ project pins a single link to the Dashboard, front and center. That's the team's one shortcut into the whole library.

Rule: exactly one Dashboard link in HQ — never a re-typed SOP list.
2

Contextual deep-links

Inside the specific task that needs a SOP, link straight to that SOP's URL — e.g., the onboarding to-do "Build the strategy deck" links to the Strategy Deck Build SOP.

Rule: a link inside the task that uses it is context, not duplication.

Why this isn't "replicating references"

A full catalog in two places is duplication you have to keep in sync. A link inside the exact task that uses a SOP belongs there — and it's a pointer, not a copy. Update the file once and every link still resolves, because the URL never changes.

06 · Making a New SOP

The repeatable checklist. Claude handles the technical steps; the DRI owns the content.

New SOP Checklist~1 session
Claude drafts the SOP from the master templateClaude
Assign an ID (SOP-AREA-###), an owner (DRI), and version 1.0Karina + DRI
DRI reviews the content for accuracyDRI
Commit the HTML to the repo → Netlify auto-publishesClaude
Add the catalog entry to the Dashboard (title, owner, version, link)Karina
Link it from Basecamp wherever a task uses itDRI

07 · Updating a SOP

The reason the whole system is safe to change often: updates never break links.

Update Checklistminutes
Claude edits the SOP's HTMLClaude
Bump the version tag in the file (e.g., 1.0 → 1.1)Claude
Commit → Netlify auto-republishes at the SAME URLClaude
Update the version + "last reviewed" date in the Dashboard catalogKarina

Links never break

Because a SOP keeps the same URL across every update, every Basecamp link and every reference stays valid forever. The version tag inside the file and the Git history are the record of what changed — you never re-share a new link.

08 · Naming, IDs & Versioning

Stable identifiers so links last and every SOP is unambiguous.

ConventionFormatExample
SOP IDSOP-[AREA]-[###]SOP-ONB-001
Area codesONB, SALES, SYS, PLAN, BRAND, SVCSYS = systems
Filenamestable slug — never changesonboarding-playbook.html
Versionlives inside the file, not the filenamev3.7 in the footer
URLteam.merj.marketing/[area]/[slug]…/onboarding/onboarding-playbook

Why the version isn't in the filename

Putting "v2" in a filename changes the URL every update and breaks every link. Instead the filename (and URL) stay fixed forever; the version tag inside the file and Git history track the changes.

09 · Access & Permissions

Internal by default. The library is not public.

10 · Governance & Review

A little discipline keeps the library trustworthy. These are the standing rules.

1

One library owner

The Chief of Operations (Karina) owns the repo, the Dashboard catalog, and the review cadence. One throat to choke keeps it coherent.

Rule: every SOP change flows through the owner or Claude.
2

Every SOP has a DRI

Beyond the library owner, each individual SOP has a named subject-matter owner responsible for its accuracy.

Rule: no SOP is published without a named DRI.
3

Quarterly review

Once a quarter the owner runs the catalog: still accurate? still owned? Update the "last reviewed" date on each. Because there's one catalog and one file store, it's a 30-minute pass.

Rule: a SOP unreviewed for two quarters is flagged on the Dashboard.
4

Single source, always

The file lives once, the catalog lives once, Basecamp links. Any time content is copied instead of linked, it's a bug in the system — fix it by replacing the copy with a link.

Rule: link, never duplicate. Where things come together.

Companion documents

This SOP pairs with the Merj SOP Master Template (what every SOP is built on), the Brand System spec, and the Companion SOP Roadmap (what's built and what's next). Together they define how Merj's knowledge is authored, stored, and found.