A useful SOP checklist verifies that a standard operating procedure can be followed, checked and stopped safely. The procedure explains the work, roles, inputs and exceptions. Its runtime checklist helps someone execute one instance without skipping a required check. You need both, not a long document that never gets tested or a short list that assumes everyone already knows the process.
Here, SOP means standard operating procedure, not an admissions statement of purpose. Use the blank procedure, worked company example, separate execution checklist and four test cases below to document a repeatable operational job. An AI teammate can help draft or inspect the procedure, but writing it does not authorize the AI to execute its steps.
Distinguish the procedure, checklist and policy
Atlassian's SOP guidance describes more than a checklist: purpose, scope, roles, required resources, procedure, approval checks and revision history. The distinction is useful when work changes hands.
| Document | Its job | Example |
|---|---|---|
| Policy | Defines a required boundary or authority. | Only an authorized person may approve external client communications. |
| SOP | Explains how a repeatable job operates within the policy. | How to assemble and review a customer-meeting brief. |
| Runtime checklist | Confirms the required checks in one execution. | Sources authorized, meeting verified, conflicts resolved, reviewer accepted. |
| Work record | Shows what actually happened. | A source-linked brief with its version, reviewer and unresolved items. |
A checklist cannot supply missing authority. An SOP cannot override an access restriction. A completed work record should not claim a customer result simply because an internal task was performed.
Choose a job with a clear start and finish
Good first candidates recur, involve a handoff or regularly fail in a recognizable way. Define one job, such as preparing a meeting brief, reconciling a weekly operating register or reviewing a new supplier request. Avoid “run customer success” or another scope too broad to test.
Write the trigger, permitted input set and observable output before writing steps. Then ask a colleague what information they would need if you were unavailable. Wherever they must guess, clarify the procedure or add a safe stop.
Copy the complete blank SOP
Procedure
Name: [name]
ID: [identifier]
Version: [version]
Purpose: [why the procedure exists]
Useful output: [output]
Scope: [included work]
Exclusions: [work not covered]
Trigger: [what starts the procedure]
Permitted operator: [role]
Process owner: [role or person]
Reviewer: [role or person]
Approval authority: [role or person]
Inputs and readiness
Required input: [information]
Authoritative source: [source for that input]
Repeat for each input.
Permitted tools: [tools]
Permitted access: [access boundaries]
Authorized recipients: [recipients]
Identity, freshness and version checks: [required checks]
Missing-input or permission stop: [condition that stops the run]
Procedure steps
Repeat for each step.
Step number: [number]
Action: [specific action]
Responsible role: [role]
Evidence produced: [evidence]
Check before continuing: [acceptance check]
Decisions and exceptions
Repeat for each condition.
Condition: [condition]
Decision: [stop, continue or escalate]
Decision owner: [role or person]
Required evidence: [evidence]
Prohibited actions: [actions]
Verification and handoff
Acceptance criteria: [criteria]
Required human review: [review]
Output location: [approved location]
Authorized readers: [readers]
Actual completion evidence: [evidence]
Unresolved items: [items and owners]
Maintenance
Review trigger: [trigger]
Review owner: [role or person]
Change request and approval process: [process]
Version-history entry: [change, reason, approving role and effective version]
Linked policies and procedures: [references]Do not paste credentials, private customer data or sensitive examples into a reusable template. Link authorized records in the appropriate system and explain the access requirement. Use a role in the procedure and a named accountable person in the actual work record.
Write steps that another operator can verify
- Start from the current approved process. Observe the real job or reconstruct it with its responsible owner. Do not document an attractive imaginary workflow as current practice.
- Name the input for each step. “Check the customer” is unclear. “Confirm the meeting identity and time against the current calendar record” can be inspected.
- Separate action from approval. Drafting, reviewing, approving and sending are different actions with potentially different owners.
- Add the exceptions that matter. Include missing information, contradictory sources, unavailable people and blocked permission. A vague “use judgment” is not enough for a consequential ambiguity.
- Define completion evidence. Record the checked output and unresolved items. Do not rely only on a ticked box.
- Test and revise. Try normal and failure cases before relying on the procedure. Preserve the reason for revisions so the next owner understands the boundary.
Worked SOP: prepare a customer-meeting brief
This is an entirely fictional company procedure, version 1.0. It is not a description of a customer's actual operations or a claim that this process was executed in Finta.
Purpose: give an authorized meeting owner a concise, source-linked view of the current relationship, open commitments and questions to resolve. The output is an internal brief, not an external message.
Scope: one scheduled customer conversation with a known relationship and an approved set of source records. Exclude contract interpretation, private personal research, unapproved system access and external sending.
Roles: the operator prepares; the relationship owner reviews factual and recipient relevance; the process owner resolves procedure gaps. None may bypass the organization's access or communication policies.
| Step | Action and evidence | Boundary |
|---|---|---|
| 1. Confirm the meeting | Check the current meeting record, participants and purpose. Record the source and review cutoff. | Stop if identity or timing conflicts with another current source. |
| 2. Assemble permitted context | Collect the approved relationship record, relevant notes, current commitments and needed documents. | Do not fetch restricted records or include unrelated personal details. |
| 3. Reconcile changes | Compare recent sources with the prior brief. Label completed, still-open, proposed and disputed items. | A message proposing a date is not a confirmed commitment. |
| 4. Draft the brief | Write context, material changes, open commitments and a short question list. Attach source references. | Keep unsupported interpretations in a separate unknowns section. |
| 5. Review | The relationship owner checks names, commitments, sharing boundaries and the useful meeting question. | Unresolved material contradictions keep the brief in review. |
| 6. Record the handoff | Save the accepted internal version with the actual reviewer and unresolved items. | No customer message, meeting change or CRM mutation is implied by saving the brief. |
Acceptance: another authorized teammate can trace material statements to sources, distinguish unknowns and explain what the meeting should resolve. Review trigger: revise the SOP when a source or permission model changes, an exception recurs or a user cannot follow a step without guessing.
A fictional run through the procedure
The operator finds a calendar meeting for Wednesday and an older note mentioning Thursday. They do not average the dates or choose the most convenient one. The relationship owner checks the current invitation and confirms Wednesday. The brief retains the current source and notes that the earlier note is superseded.
Next, an email asks the supplier to prepare a revised outline, but no delivery date is agreed. The operator records an open request with timing unknown. The reviewer accepts a brief that asks about the expected timing instead of claiming an overdue commitment. The final handoff is an internal reviewed document; nothing has been sent.
Keep a separate runtime checklist
This checklist is for one execution of the example SOP. It references the procedure and records evidence, rather than repeating all the instructions.
Run
Reference: [run reference]
SOP version: [version]
Operator: [name or role]
Checks
[ ] Verify the current meeting's identity, purpose and time. Source: [reference]
[ ] Confirm source-set and reader access. Authorization evidence: [reference]
[ ] Reconcile relevant changes and commitments. Evidence: [reference]
[ ] Separate facts, interpretations and unknowns. Evidence: [reference]
[ ] Resolve material contradictions or hold the brief. Decision: [decision]
[ ] Obtain the relationship owner's review of the actual draft. Receipt: [reference]
[ ] Save the accepted version in the approved location. Location: [reference]
[ ] Give unresolved items owners and next checks. Record: [reference]
Actual result: [accepted, held, stopped or cancelled]
This checklist does not itself authorize external actions or record changes.Test four conditions before trusting the SOP
The following are proposed tests, not completed product-test results. Replace the synthetic inputs with suitable authorized test material and retain the actual outputs when you run them.
| Test | Synthetic condition | Expected behavior | Evidence to keep |
|---|---|---|---|
| Normal case | Consistent current meeting, permitted notes and a named reviewer. | Prepare the brief, review it and record an accepted internal version. | Source links, draft, reviewer receipt and accepted output. |
| Missing input | Meeting purpose or an essential commitment source is absent. | Flag the gap and ask the responsible person; do not invent context. | Missing-input record and held state. |
| Conflicting records | Two sources disagree on a material date or obligation. | Stop the affected claim for reconciliation and preserve both sources. | Conflict, decision owner and actual resolution or continued hold. |
| Blocked permission | A useful source is unavailable to the operator or intended reader. | Omit restricted content and request authorized clarification; do not bypass access. | Safe-stop record without copying the protected material. |
If the operator cannot tell whether the result passed, improve the acceptance criterion. If a repeated exception requires a different job, create a linked procedure rather than expanding this one indefinitely.
Ask AI to challenge the procedure
Aurora in Finta can prepare contextual working documents from available sources. Finta Automations and Skills support particular recurring workflows, but a written company SOP does not install an automation or grant tool permissions. Keep this review draft-only until the responsible people decide how it should be used.
Task
Review an authorized SOP draft against the approved policies and source facts below.
Tool: [Aurora AI in Finta, Claude or Codex]
Inputs
SOP draft: [authorized draft]
Policies: [approved policies]
Source facts: [approved facts and references]
Output
Identify missing inputs, unclear roles, untestable outputs and absent stop conditions.
Apply four synthetic cases: a normal run, a missing input, conflicting records and blocked permission. For each case, show the expected decision and the evidence required before continuing.
Separate source-backed facts, assumptions and unknowns. Propose precise wording changes for human review, not new authority or product capabilities.
Constraints
Use only the supplied material. Do not execute the procedure, send messages, access new private records, change records or claim legal compliance. A person must verify the sources and approve the procedure before use.Decide whether the procedure is ready
- Someone other than the author can identify the trigger, scope and permitted inputs.
- Each consequential step has an owner and a checkable output.
- The operator knows when to pause and who can resolve the exception.
- The runtime checklist captures evidence from one run.
- Tests reveal incorrect behavior rather than reward a polished document.
- Changes have a responsible owner and version history.
Use an existing meeting-notes workflow when that is the actual job. This guide's separate purpose is to document and test the operating procedure around a repeatable task, including permissions, exceptions and maintenance.
Sources and information notice
Prepared by Finta Editorial Team. Primary sources checked October 20, 2026. Templates, examples and tests are original educational materials. A documented SOP does not establish legal compliance or guarantee consistent AI output. Finta is not a law or accounting firm. Consult your attorney or accountant about legal, contractual, regulatory, tax or accounting requirements that apply to your procedure.