Use Claude to Draft an SOP Without Inventing the Process

The procedure says the account manager approves every new project. Your account manager reads it and asks, “Since when?”

That is an expensive way to discover a missing decision. A tidy document can make an assumption look like company policy.

To use Claude for SOP creation, give it verified process notes, examples and rules. Ask it to draft only the steps those sources support, identify conflicts, and leave missing owners or approvals unresolved. Then have the people who do the work test the draft before anyone treats it as the operating procedure.

An SOP is a standard operating procedure: a repeatable set of instructions for completing a defined job. Its value is whether another person can use it to do the work correctly. A confident tone and a numbered list do not establish that.

Our previous guide compared Claude, ChatGPT and ClickUp AI using a defined business job. Here, the job is turning what your team knows into instructions someone else can follow.

Start with one handoff your team can describe

Choose a small process with a recognizable beginning and end. “Run client operations” is too broad. “Move an approved client request into the delivery queue” gives you something to inspect.

Before opening Claude, sit with the person who handles that handoff. Walk through a recent ordinary request, a request with missing information, and one that required an exception. Ask them to show the work rather than describe an ideal version from memory.

Collect the materials that explain those cases:

• The event that starts the process and the evidence that it is complete.

• The fields, files or messages the person needs before starting.

• The actions they take, in order, including where information is recorded.

• The current rule for approvals, exceptions and stopping work.

• A completed example and one example that should be returned for clarification.

Remove customer details the drafting exercise does not need. Use only material your business permits in the selected AI account and workspace.

If the team disagrees about the approval rule, record that disagreement. Do not resolve it by choosing the most polished sentence. Our process audit guide gives you a way to find unclear ownership before you document it.

Give Claude a small, current source packet

For a first draft, a few clearly named files are enough. For example: current process notes, approved rules, and anonymized example requests. Add an owner and last-reviewed date to each. Mark superseded instructions as historical, or leave them out of the active packet.

Claude supports document uploads including PDF, DOCX and TXT, and files can be attached to an individual chat or added to a project for reference across conversations. Check the current file-upload documentation for supported formats and restrictions.

If you will refine several related procedures, a Claude project can hold reference material and reusable instructions. Its documented setup lets you add project knowledge and set instructions for chats in that project. Put the source requirements in those instructions, and keep the active rules in project knowledge. See Claude’s project setup guide.

A filename such as “intake-rules-approved-2026-09-16” is more useful than “final-final-v3.” Give every source a short label too: S1 for interview notes, S2 for the approved checklist, and S3 for an example request. Ask for those labels beside draft steps so a reviewer can trace each instruction back to evidence.

Treat the labels as something to check. A model can attach a plausible source label to an unsupported statement.

A worked example: the approval that nobody agreed to

The following is a fictional service-business example, written to demonstrate the review method. It is not a client result or a measured Claude test.

The source packet contains three items:

• S1, current interview note: Jamie checks incoming requests for a client name, requested work and desired date. If anything is missing, Jamie asks the requester to supply it.

• S2, approved intake checklist: A request must contain those three fields before it enters the delivery queue. The desired date is a customer request, not a promised delivery date.

• S3, example request: A complete request was placed in the delivery queue. There is no recorded rule identifying who approves a delivery commitment or how quickly the queue must be reviewed.

A weak draft might say, “The account manager approves the request within 24 hours and confirms the delivery date.” That sentence invents an owner, a deadline and authority to make a customer commitment.

A useful draft would preserve what the sources establish:

Step 1: Check completeness. Jamie checks for client name, requested work and desired date. Source: S1 and S2.

Step 2: Return incomplete requests. If any required field is missing, Jamie asks the requester for the missing information. Source: S1. The sources do not establish a response-time target.

Step 3: Queue complete requests. Place the complete request in the delivery queue. Record the requested date as a preference, not a commitment. Source: S2 and S3. Confirm the queue-entry owner before approving this instruction for use.

Open decision: Commit a delivery date. The source packet does not establish the approval owner, capacity check or response target. Ask the process owner to decide these before the SOP authorizes a delivery promise.

That last item belongs in the draft. Removing it would make the document shorter and the handoff less trustworthy.

Use a prompt that separates evidence from suggestions

Here is a proposed prompt to adapt after you label your source packet:

Draft a standard operating procedure for [specific handoff], using only the attached sources S1, S2 and S3 for statements about our current process. First list missing decisions and conflicts that would prevent someone from following it. Do not invent owners, deadlines, approvals, system settings or customer commitments.

Then draft the supported steps. For each step, include its trigger or input, responsible role when established, action, expected output, exception or stop condition, and source label. Write “not established in supplied sources” where a required fact is missing. Keep proposed improvements in a separate section called Suggestions for the process owner. Do not present those suggestions as approved policy.

Finish with review questions and a short test checklist. Mark the entire document Draft: awaiting process-owner review. Do not send messages, change tasks or perform the procedure.

Read the missing-decision list before reading the prose. It may expose the most useful work you need to do together.

This prompt is a starting point, not a guarantee against mistakes. Compare each instruction with its cited source, especially words such as “always,” “must,” “approved” and “within.” Those words can quietly create obligations.

Test the draft with the person who will use it

Ask a teammate to follow the draft against a sample request while the usual process owner observes. Pause before any action that would affect a customer or live record. The aim is to find unclear instructions before relying on them.

Use at least these three cases:

• A complete request: can the reader identify the next action and record the right output?

• A request missing a required field: does the procedure explain where it waits and what information is needed?

• A request with an unrealistic desired date: does the procedure preserve the distinction between a request and a commitment?

Record every clarification the observer has to give. Also count unsupported steps, wrong actions and unresolved decisions. Fix the source packet and the draft together, so the next revision does not recreate the same ambiguity.

For a broader rollout, use the boundaries in the AI pilot planning guide: a small scope, a named reviewer and a way to stop or recover.

Publish one approved version where the work happens

Once the process owner accepts the tested procedure, record the approver, approval date, version and next review trigger. Useful triggers include a tool change, a new approval rule or a repeated exception. Keep a brief change log explaining what changed and why.

Put the approved SOP where staff already look for instructions. Link the relevant task template or checklist to that single source. A draft left in an AI conversation should not become an accidental second policy document.

If you want a downloadable document, Claude’s file-creation documentation describes creating Word documents and PDFs. Export after review, then inspect the exported file. Formatting a document does not validate its instructions.

Measure the whole effort: gathering sources, drafting, checking, testing and maintaining. Compare that with your usual method. A faster first draft is useful only if review and correction do not consume the saving or leave the team with worse instructions.

For more practical starting points, follow the Claude workflow reading guide.

Common questions about using Claude to create SOPs

Can Claude write an SOP from a recorded walkthrough?

You can supply an approved transcript or notes as source material. Check the transcription first, then have the process owner confirm the steps and exceptions. A walkthrough of one successful case may omit the rules for everything that goes wrong.

What if our process has never been documented?

Start by observing the work and interviewing the person who performs it. Claude can help organize those notes and surface questions. The team still needs to decide who owns unresolved steps and approve the procedure before use.

Do we need a Claude project for one SOP?

No. A chat with the necessary source files can support a first draft. A project becomes useful when you want a shared set of reference material and instructions for repeated drafting. Check access and visibility before adding business information.

How do we stop Claude from inventing steps?

Require source labels, explicit unknowns and a separate suggestions section. Then check the draft against the sources. Prompt instructions reduce ambiguity, but human review and a practical test are still needed to catch unsupported content.

Can Bell Consulting Solutions help with the process as well as the document?

Yes. I review how the work happens, help identify useful improvements, and implement AI where it fits the process and the people doing it. If your SOP project keeps uncovering unanswered questions, bring one handoff for a process review. A rough example is enough to start the conversation.