Operations is the highest-leverage role for AI in a small business — every recurring process is a candidate. But that's also the trap: it's easy to spread thin across twelve half-improved processes. This page is the opposite. One bi-weekly ritual that compounds, one project that holds every SOP, twelve prompts you'll actually use, and one fully wired workflow you can have running by Friday.
Block 60 minutes every other Wednesday afternoon. Pick one process that's still in someone's head, sit down with Claude inside your SOP Library project, and document it. Twenty-six SOPs a year. That's how operations leverage actually compounds.
The temptation is to do this in bursts — a quiet week, you bang out six SOPs, then nothing for three months. That's the wrong rhythm. Burst documentation produces SOPs nobody uses because nobody felt the pain that justified writing them. Steady documentation, two per month, lets the writing follow the friction.
Pick the process from your "Master process list" that's caused the most ops overhead in the last two weeks. That's almost always the right one. Below are six recurring ones every small business has — start with whichever is the most tribal in yours.
The first 30 days after a contract is signed. Who does what, when, in what order. The SOP that has the highest ROI of any you'll write — every new client touches it.
Not generic hiring. The hiring process for the role you've hired three times and keep doing differently. Sourcing, screening, the test, the offer, the first week.
The 60-day countdown before any vendor renewal. What to audit, what to ask, what to negotiate, when to walk. Saves you from auto-renewing into another year of inertia.
When a routine complaint becomes a real problem — who owns it, what the response time is, what we can offer, when the owner gets pulled in. Most businesses improvise this. Stop.
The 8-day process that should be 4. Document it first, optimize it second. You can't fix what isn't written down.
The hardest SOP to write and the one you most want in place before you need it. Final paycheck, IT access, equipment, comms to team, comms to clients.
Why this works. Every documented process is a piece of the business that no longer requires you to make work. After a year of SOP Hours, you have 20+ processes that run without your involvement. That's the entire job of operations: making yourself unnecessary for the work that doesn't need you, so you're available for the work that does.
For the owner, the project is "My Business." For operations, it's "SOP Library." Same idea — load Claude with everything it needs to know once, then stop re-explaining. Every prompt below assumes this Project exists.
Download the template. Fill it in honestly — 45 to 60 minutes the first time. Open Claude → Projects → New Project → name it "SOP Library." Paste the completed file into custom instructions. Upload any existing SOPs as knowledge files (any format works — Word docs, screenshots, voice memos).
Now every Ops conversation starts with Claude knowing every process you run. When you ask "should this go in the onboarding SOP or the kickoff SOP?", Claude knows what's in each. When you ask "what's missing from the close process?", Claude can answer because it has the close SOP loaded.
The "what's broken right now" section is the ops secret. Owners avoid hard conversations; ops managers avoid hard documentation. The honest list — the close that takes too long, the response time that's slipping, the supply ordering that three people think they own — is what gives Claude license to push back. Without it, you'll get a polite assistant. With it, you'll get something closer to a co-pilot.
Used inside your SOP Library Project, so Claude already has the org chart, the process list, and the existing SOPs in context. Fill in the [bracketed] specifics and copy-paste.
I'm going to describe a process we run. Turn it into a clean SOP using our standard structure:
- Purpose (one sentence)
- Trigger (when this runs)
- Owner (role, not name)
- Prerequisites
- Steps (numbered, each one a single concrete action)
- Decision points (any branching logic, explicit)
- Outputs / deliverables
- Success criteria — how we know it worked
- Common failure modes and what to do
Here's the process: [PASTE OR DESCRIBE]
If anything is unclear from my description, ask me before writing. Don't invent steps I didn't mention. Write for the new hire on a tired Wednesday — not the polished version for the website. Attached is one of our existing SOPs: [NAME]. Audit it as if you're a new employee trying to execute it for the first time, alone, on a Wednesday afternoon.
1. What steps would you not be able to do without asking someone?
2. What decisions are mentioned but not actually explained?
3. What's missing entirely that someone would need to know?
4. What's over-specified or could be cut without loss?
5. What's the one change that would make the biggest difference?
Be the new employee. Don't be polite about it. End with the single edit you'd make today if you only had 10 minutes. Attached is our SOP for [PROCESS]. Generate the checklist version — what someone executing this process would actually print out or paste into a ticket.
Rules:
- Every line starts with a verb
- Every line is something that could be checked off in under 5 minutes (if not, break it down)
- Decisions become "if X, do Y; if Z, do W" — not free-form prose
- Group by phase if there's a natural one
- End with the "done" criteria — what we visually confirm before we call it done
If the SOP is fuzzy in any spot, make the checklist explicit about the ambiguity so the human notices and resolves it. End of week. Here are this week's inputs: [TICKETS, INCIDENTS, COMPLETED WORK, EXCEPTIONS, ANY CONTEXT]
Draft my weekly ops update for the owner. Structure:
- Throughput: jobs/clients/deliverables completed this week vs. plan
- Exceptions: what didn't follow the SOP, why, what we did about it
- Risks emerging next week and what I'm doing about each
- One ask for the owner — the thing I need a decision on
- One thing the owner should know but won't otherwise hear
Length: under 350 words. Be honest about what didn't work. The owner trusts me more when I name problems before they have to ask. Generate this month's client report for [CLIENT]. Inputs attached: this month's activity, last month's report, any commitments we made last month.
Structure (matches our standard):
- What we did this month (3–5 specifics, with numbers where they exist)
- Outcomes / metrics they care about
- What we're carrying into next month
- One recommendation from us — proactive, not reactive
- Two questions for them, if any
Tone: matches our voice for this client (in the project). If we missed a commitment from last month, name it directly. Don't bury it. Length: under 600 words. Attached are this month's exceptions — instances where something didn't follow the SOP. Analyze: 1. Are these one-offs, or is there a pattern? 2. Which exceptions point to a real gap in the SOP vs. a gap in execution? 3. Which exceptions are actually fine — the SOP should have allowed them, and we should loosen it? 4. The one process change that would have prevented the most exceptions 5. The one change I should NOT make — because the exception cost is lower than the rigidity cost Be specific: which SOP, which step, which change. Don't write a process to fix a person.
We're starting [INITIATIVE]. The people involved: [LIST WITH ROLES]. Build the RACI: - Decompose the initiative into 8–12 concrete tasks (not vague areas like "planning" or "execution") - For each task: who's Responsible, Accountable, Consulted, Informed - Flag any task with multiple Accountables — that's a problem - Flag any person who's RACI-empty across all tasks — they're probably not needed - End with the single most likely failure mode for this RACI and how to prevent it Be willing to say "this initiative doesn't need [person]." RACI bloat kills initiatives.
We've decided to [INITIATIVE]. Target completion: [DATE]. Build the implementation plan: 1. Decompose into phases (3–5 max) 2. For each phase: deliverables, owner, target date, dependencies 3. The first concrete action for next Monday morning — what does the person who owns step 1 actually do at 9am? 4. The three things most likely to slip and why 5. The 30-day check-in question that tells us if we're actually on track Don't pad with "consider X" or "explore Y." Every line should be something a specific person does on a specific date.
[PERSON] is going on leave / leaving on [DATE]. They own: [LIST RESPONSIBILITIES OR PASTE JOB DESCRIPTION]. Help me build the handoff: 1. Who picks up what — using the team in this project, distribute responsibilities and flag anything that has no obvious owner 2. For each handed-off responsibility: what the new owner needs to know that isn't documented anywhere 3. The customers / vendors / external parties who need to be told, and what we say 4. The 5 things most likely to fall through the cracks in the first 30 days 5. The check-in cadence for the first 60 days Treat this like a real handoff. Things slip when nobody owns them — name every gap before this person leaves the building.
This process keeps failing in the same way: [DESCRIPTION OF RECURRING FAILURE]
Help me think about it:
1. Is this a process problem, a people problem, or a tool problem? (Be honest — don't default to process.)
2. Where in the process is the failure actually happening?
3. What would a fix that takes 30 minutes look like?
4. What would a fix that takes a week look like?
5. What's the cost of NOT fixing it — both obvious and hidden?
Don't recommend a big rebuild if a small fix would work. And if this is actually a people problem, say so directly. I'm comparing [N] vendors for [SERVICE]. Their proposals are attached. Our requirements: [WHAT WE NEED]. Build the comparison: 1. A table: vendor / monthly cost / contract length / what's included / what's extra / red flags 2. Honest "what each one is best at" — even the ones I'm leaning against 3. The non-obvious differences (most comparison shopping misses these) 4. The 5 questions I should ask each vendor before deciding 5. Your recommendation — if forced to pick today, which and why I won't be offended if you disagree with where I'm leaning.
[VENDOR] is up for renewal in [TIME]. Current spend: [$X/period]. They've been with us [DURATION]. Audit the relationship: 1. What are we actually using vs. what we're paying for? 2. What's our utilization trend over the last 12 months? 3. Has the relationship deteriorated, stabilized, or improved? Cite specifics from the data I've shared. 4. Three asks for renegotiation, ranked by likelihood of getting them 5. The "walk away" scenario — what would we need to have in place to switch, realistically? If we should just leave them, say so. Inertia is the most expensive vendor.
Where to save these. Save them as Custom prompts inside your SOP Library project — Claude makes them one click away. Star this page as a backup. The worst version is reading the prompts once, nodding, and never copying any; the best version is the one where prompt 04 is muscle memory by Friday week three.
The integration that pays back fastest for operations: when a deal closes, the entire first-week onboarding spins up from one prompt. Folder structure, kickoff email, internal ticket, calendar invite — all drafted, all ready for you to review and send. Total setup: 45–60 minutes.
In your SOP Library project → Connect apps → connect both HubSpot (read access on Deals + Contacts) and Google Workspace (Drive, Calendar, Gmail). If you're on Microsoft 365 instead, the M365 connector works identically.
Read access for HubSpot, write access for Drive and Calendar. Claude needs to read who the client is and create their folder + meeting; it doesn't need to send mail on your behalf (you'll review and send those yourself in step 3).
This is the only prompt you'll use for new clients. Save it inside the project as "New client onboarding." It should reference your existing onboarding SOP (uploaded to the project as a knowledge file). The skeleton:
We just closed [CLIENT NAME] on [DATE] for [SERVICE / PRODUCT]. The HubSpot deal record is attached (or pull it from connected HubSpot). Using our standard onboarding SOP in this project, do the following: 1. **Create the Drive folder structure** under /Clients/[CLIENT NAME]/ matching our SOP. Include the standard subfolders and place the templated docs from /_Templates/ into the right ones. Reply with the folder URL. 2. **Draft the kickoff email** from me to the client's primary contact. Voice: our standard client voice (in this project). Include: warm welcome, the named team they'll be working with, what they need to send us before the kickoff (the list is in the SOP), what we'll send them after, the proposed kickoff time. 3. **Draft the internal kickoff ticket** in our standard format: which team members are on this client, what each owns, the week-1 deliverables (5 items, mapped to days). 4. **Propose 3 kickoff meeting times** in the next 5 business days that work across me, [OTHER TEAM MEMBERS], and avoid existing client conflicts. Don't create the invite yet — wait for me to pick. 5. **Flag any risks specific to this client** based on the HubSpot notes from the deal cycle. If anything in our standard playbook doesn't fit this client, name it. Reply with all four sections in order. I'll review, then approve each step before you take action.
Don't wait for a real new client. Run the prompt against a recent deal (or a test one you create). Walk through the output. Verify two things:
1. Drive folder created: /Clients/Acme Corp/ with subfolders 01_Contracts, 02_Kickoff, 03_Deliverables, 04_Comms, 05_Billing. Templated MSA and SOW dropped into 01_Contracts. (URL)
2. Kickoff email draft: "Hey Maria — thrilled to have Acme on board. Your dedicated team for the engagement: Sarah leading delivery, Reggie on finance ops, me as your point on anything that doesn't fit cleanly elsewhere…" (full draft in thread)
3. Internal ticket draft: Acme Corp — Week 1. Owner: Sarah. Sub-owners: Reggie (billing setup, day 2), Jordan (calendar & comms, day 1)… (full ticket in thread)
4. Proposed kickoff times: Tue 2pm, Wed 10am, Thu 3pm — all confirmed against your, Sarah's, and Reggie's calendars.
5. Risk flags: The HubSpot notes mention Acme had a bad experience with their last vendor on response times. Our standard 48-hour SLA may need a Week 1 conversation. Also: their billing contact in HubSpot is empty — we need to ask Maria who handles AP before billing setup on day 2.
When a deal closes, you run one prompt. Claude does the prep, you review and approve each step, and what used to be 90 minutes of clicking around is now 20 minutes of judgment. Multiply by every new client you sign this year — that's the integration paying for itself.
Important: keep yourself in the loop on the email send and the calendar invite. The Drive folder you can let Claude create directly; those are easily reversible. Outbound communication and external meetings stay human-approved. That's the right amount of automation for this.
What this isn't. It isn't an autonomous onboarding agent. It's a workflow where the boring middle is automated and your judgment is concentrated where it matters: this client's specific risks, this email's tone, this kickoff's timing. The operations principle: automate the typing, keep the deciding.
Once L1–L3 are real, L4 is where Claude operates on a schedule, surfaces patterns proactively, and runs workflows across systems without you holding the prompt. Two L4 sketches for an ops manager.
Every Friday at 4pm, Claude scans the week's tickets, time-tracking entries, support emails, and the exception log. It cross-references against your master process list and operating principles. It posts one Slack message to you with: the patterns it found, which SOPs they implicate, and one proposed SOP edit for next week — ready to discuss in the SOP Hour.
Pattern this week: Three onboarding kickoffs scheduled outside the 5-business-day target. All three involved Reggie's calendar — he's at 92% utilization this month and is the rate-limiter on onboarding velocity.
SOP implicated: New client onboarding, step 4 (scheduling). Currently says "within 5 business days." Doesn't account for Reggie's capacity.
Proposed edit: Add a check at deal-close: if Reggie's calendar utilization >85% for the week, escalate to me before proposing times. Draft language attached.
Other this week: Two billing setup exceptions (both day-2-of-week-1, both around contact info gaps in HubSpot) — worth a conversation, not yet a pattern. One vendor invoice anomaly (logged for Reggie).
The Client Onboarding workflow above runs end-to-end on a schedule, with three human checkpoints: (1) you approve the kickoff email before send, (2) you pick the meeting time, (3) you approve the internal ticket before it's posted. Everything else — folder creation, template population, calendar holds, day-2 billing reminder, day-5 check-in draft — happens automatically.
This is the right L4 ambition. It's a real build — not the kind you ship in an afternoon, but the kind you ship over a quarter once L1–L3 are habit. Skip the foundation and you'll have an orchestrator that confidently onboards a client into a folder structure that no longer matches your process.
If you're reading this and thinking I want both of these now — the honest answer is: spend a quarter at L2–L3 first. By month 3, you'll know exactly which L4 build matters most for your business and which one would be a toy. When you're at that point, a 30-minute call is the right next step.
Operations is the role where AI has the most leverage and the most ways to misfire. The leverage and the misfires share the same root: ops touches everything, so it's easy to spread thin. Here's what kills it.
The quiet week where you bang out 14 SOPs in two days. They're polished. Nobody uses them — because nobody felt the friction that justified writing them.
The SOP Hour is fortnightly for a reason. Two real SOPs per month, written when the pain is fresh, beats fourteen aspirational SOPs that sit unread.
The most expensive ops mistake. Someone keeps screwing up the same step — so you write a more detailed SOP. Six months later, the SOP is 14 pages and they still screw it up.
Tell Claude when something is a people problem. The "How to talk to me" section in your project should include "if I'm describing a problem that's actually a people problem, say so."
Every chat starts with re-explaining your team, your tools, and your existing SOPs. Within two weeks, the friction overtakes the value and you drift back to old habits.
The SOP Library project is the one-time tax that makes every prompt after it cheap. Pay it once.
You read about agents and try to build the autonomous onboarding orchestrator before a single SOP is solid. The orchestrator confidently runs a process that's still half-tribal — and now the breakage is automated and at scale.
L3 first. The Client Onboarding workflow above is the right ambition for month 1 — not month 1's stretch goal.
An auto-sent onboarding email that addresses the wrong contact, references the wrong product, or carries a tone wrong for that specific client. One bad onboarding email costs more than a year of saved minutes.
Drafts auto-generate. Sends stay human. That's the rule.
L1–L3 is absolutely solo work — this page is enough. When you start building the Exceptions Agent or the Onboarding Orchestrator, and you're debugging an integration at 11pm on a Tuesday, that's the moment to ask for help.
Not because you can't figure it out. Because your time is better spent on the parts of operations only you can do.
Download the template. Build the project. Save the prompts. Wire the onboarding flow. Run the SOP Hour. In 90 days your business will run on documented processes instead of tribal knowledge — and you'll be the reason.