The missing step is a decision on that exact revision. Feedback on version 1 does not approve version 2, and requesting changes does not approve either version.
This marketing SOP template gives a content team a procedure for intake, factual and asset checks, drafting, review, revision, and release preparation. The original fictional example uses one campaign asset with two revisions. Keep the actual procedure, approval decisions, and release records in your team's required document or tracker.
Start with an intake brief you can check
In the fictional Maple Studio example, Mia drafts campaign asset A01 rev1. Its copy says “Workshop November 21.” The maintained brief, B01, says the date is TO CONFIRM. The draft also uses a reference image whose permission record, R01, is absent.
Neither a confident sentence nor an attached image resolves those gaps.
| Intake field | Example entry |
|---|---|
| Asset ID and revision | A01 rev1 |
| Purpose | Draft workshop announcement |
| Audience and channel | TO CONFIRM before channel-specific release review |
| Author | Mia, fictional example role |
| Maintained factual brief | B01; event date TO CONFIRM |
| Date claim in draft | November 21; unsupported by B01 |
| Image permission basis | R01 absent |
| Assigned content reviewer | Jo, fictional example role |
| Actual release authority | TO CONFIRM |
Use the intake brief to identify the job and its evidence, not to fill gaps with plausible details. A reviewer assignment also does not establish who is authorized to release the asset. Supply that authority through the team's actual process.
Define the procedure's scope and records
Give the SOP an ID, revision, owner, approval status, and effective date in the native document. Leave approval and effective-date fields unresolved until the responsible owner supplies them. The procedure itself should not appear approved merely because its sample is filled in.
Its scope is a content asset moving from intake to authorized release preparation. Define the outputs as an intake brief, claim-and-source checklist, asset-permission checklist, revision decision log, and pre-release record. Scheduling, posting, and advertising actions remain subject to the team's authorized workflow.
Use explicit review decisions: approve, request changes, or reject, with a reason and responsible reviewer. Asana's own guidance distinguishes these decisions and recommends explaining the outcome. The template below adopts that process distinction, rather than requiring Asana or its controls. Asana, Giving Feedback and Approvals.
Follow a revision-bound sequence
| Step | Responsible function to confirm | Record produced | Condition before advancing |
|---|---|---|---|
| 1. Capture intake | Request owner | Brief, audience, channel, asset ID | Purpose and relevant inputs identified |
| 2. Check claims and assets | Author with evidence owners | Claim/source and permission checklist | Gaps visible; no unsupported fact treated as confirmed |
| 3. Submit draft | Author | Exact revision and artifact reference | Reviewer can identify the submitted content |
| 4. Record review | Assigned reviewer | Decision, revision, reason, actual record reference | Decision is explicit rather than “reviewed” |
| 5. Address feedback | Author | Change log and new revision | Each requested change has a response |
| 6. Re-review | Assigned reviewer | Decision on the revised artifact | Earlier decision has not been carried forward |
| 7. Prepare release | Authorized release function | Pre-release evidence check | Exact revision approved, evidence and authority resolved |
| 8. Record actual release | Authorized publisher | Actual published artifact reference, if released | A planned release is not recorded as completed |
The functions are placeholders for team appointments. The SOP should specify the actual owners, required checks, and exception route before operational use.
Walk the two revisions without inventing a pass
Jo records C01: request changes for A01 rev1. The reason identifies the unsupported November 21 date and missing R01 permission evidence. Preserve rev1 and that decision in the history.
For rev2, Mia can remove the unconfirmed date. If a verified lookup destination and approved lookup wording are supplied, she can use that instead. Otherwise she should leave the replacement unresolved or omit the claim; she should not invent a registration link, confirmed date, or “approved” instruction.
For the image, the revision needs the actual permission basis for the intended use, or the image must be omitted. “Permission requested” does not mean permission obtained. This checklist records evidence for review; it does not make a legal determination.
| Record | Revision | Recorded decision or state | What remains unresolved |
|---|---|---|---|
| A01 rev1 | rev1 | Draft contains unsupported date and image evidence gap | Date basis and R01 |
| C01 | rev1 | Changes requested by fictional reviewer Jo | Author response and revised review |
| A01 rev2 | rev2 | Submitted for re-review in the illustrative sequence | Actual final artifact, evidence, reviewer decision, release authority |
Rev2 is awaiting review. Even if it removed both problem elements, that revision still needs its own decision. Keep actual confirmation fields blank in the example. Do not turn a proposed correction into proof it was accepted.
Use a pre-release checklist with evidence references
Before someone advances the exact revision, ask:
- Does the approval identify A01 and rev2, including the actual artifact reviewed?
- Does every retained factual claim point to its current basis?
- Does every retained image or other asset have the required evidence for its intended use?
- Are unresolved comments and conditions visible to the reviewer?
- Is the intended channel and audience confirmed?
- Is the actual release owner and authority established?
Store the decision and evidence references in the native record. If anything is missing, describe the missing input and route it to the confirmed owner. Do not change the state to approved just to clear a queue.
A completed pre-release check is also different from an actual publication. Retain the actual published version or reference only after the authorized release occurred. This template makes no claim about campaign results or performance.
Copy this prompt to prepare the complete SOP
Create one complete, self-contained US-English HTML companion for “A01 revision-bound content review”. Return the full HTML document, with inline CSS and any JavaScript needed for the local interactions. Use the original scenario, named records, numbers and expected cases below.
Design the page for this task: use clearly labeled input or source records, a readable result or worked example, and an adjacent explanation of the evidence. Use a restrained visual hierarchy, left-aligned text, readable tables or stacked records, and a responsive layout at 720px and 360px. Provide meaningful labeled controls for A01 rev1; C01 · feedback; A01 rev2; Select text. Use keyboard-accessible native controls and visible focus. Keep the complete content readable without an external dependency.
The following brief supplies the substantive content and constraints. Native-format requests describe the material to represent or copy manually; this HTML must not pretend to create DOCX, XLSX, PDF, PPTX, H5P or another native file, run Python/Flask/Django/Snowflake/Power BI, connect a live service, send messages, or perform an authorized real-world action. Where the task requires a native source, actual observation or separate approval, retain that requirement and leave unsupplied evidence blank.
Create an original marketing content approval SOP in US English. Use our native procedure document and record format: [enter]. Actual procedure owner, approval status, effective date: [enter]. Audience/channel standards: [enter]. Reviewer and release authority: [enter actual roles and process]. Claim/asset evidence requirements and exception route: [enter]. Leave missing operational inputs TO CONFIRM, never invent them.
Include a controlled procedure header, scope, ordered steps,
responsibility/evidence matrix, intake brief, claim/source checklist,
asset-permission checklist, revision decision log, and pre-release
checklist. Keep actual release records separate from planned release.
Use this labeled fictional walkthrough:
Maple Studio asset A01 rev1, author Mia, reviewer Jo. Rev1 says workshop November 21. Maintained brief B01 says date
TO CONFIRM. Image permission record R01 is absent. C01 requests changes on rev1, identifying both gaps. For rev2, remove the unconfirmed date; use approved lookup wording
and destination only if actually supplied. For the image, obtain
the actual required permission basis or omit it. Do not invent a
link, permission, approved wording or confirmed date. Rev2 is awaiting its own review. Actual confirmations remain blank.
Each review row must identify asset ID, exact revision, artifact
reference, reviewer, explicit approve/request-changes/reject decision,
reason, conditions, and actual decision record. Preserve rev1/C01
and the response history. A rev1 decision cannot approve rev2. Changes requested is not approval; a proposed fix is not acceptance.
Release preparation requires actual approval on the exact revision,
resolved factual/asset evidence, confirmed audience/channel and
authorized release owner. If evidence is missing, record the gap
and route it through the supplied exception process. Do not claim
legal clearance, automatic approval, posting or marketing results.
Return complete editable procedure text and reusable blank records
in the requested native format. Include the walkthrough's unresolved
pre-release state and a manual check that no earlier decision was
carried onto a later revision. Do not send or publish anything.
COMPLETE AUTHORED SCENARIO AND EXPECTED CASES
The following is the supplied reading/teaching/calculation record to represent in the companion. Preserve its particular content, examples, source references and unknowns. Wording about a future native implementation refers to that native task, not permission to omit this HTML companion.
# Marketing SOP Template: Approve the Revision That Will Be Released
A reviewer asks you to remove an unconfirmed workshop date and check an image's permission record. You revise the draft. The tracking row still says “reviewed,” so someone assumes the new version is ready to publish.
The missing step is a decision on that exact revision. Feedback on version 1 does not approve version 2, and requesting changes does not approve either version.
This marketing SOP template gives a content team a procedure for intake, factual and asset checks, drafting, review, revision, and release preparation. The original fictional example uses one campaign asset with two revisions. Keep the actual procedure, approval decisions, and release records in your team's required document or tracker.
## Start with an intake brief you can check
In the fictional Maple Studio example, Mia drafts campaign asset **A01 rev1**. Its copy says “Workshop November 21.” The maintained brief, **B01**, says the date is **TO CONFIRM**. The draft also uses a reference image whose permission record, **R01**, is absent.
Neither a confident sentence nor an attached image resolves those gaps.
| Intake field | Example entry |
| --- | --- |
| Asset ID and revision | A01 rev1 |
| Purpose | Draft workshop announcement |
| Audience and channel | TO CONFIRM before channel-specific release review |
| Author | Mia, fictional example role |
| Maintained factual brief | B01; event date TO CONFIRM |
| Date claim in draft | November 21; unsupported by B01 |
| Image permission basis | R01 absent |
| Assigned content reviewer | Jo, fictional example role |
| Actual release authority | TO CONFIRM |
Use the intake brief to identify the job and its evidence, not to fill gaps with plausible details. A reviewer assignment also does not establish who is authorized to release the asset. Supply that authority through the team's actual process.
## Define the procedure's scope and records
Give the SOP an ID, revision, owner, approval status, and effective date in the native document. Leave approval and effective-date fields unresolved until the responsible owner supplies them. The procedure itself should not appear approved merely because its sample is filled in.
Its scope is a content asset moving from intake to authorized release preparation. Define the outputs as an intake brief, claim-and-source checklist, asset-permission checklist, revision decision log, and pre-release record. Scheduling, posting, and advertising actions remain subject to the team's authorized workflow.
Use explicit review decisions: **approve**, **request changes**, or **reject**, with a reason and responsible reviewer. Asana's own guidance distinguishes these decisions and recommends explaining the outcome. The template below adopts that process distinction, rather than requiring Asana or its controls. [Asana, Giving Feedback and Approvals](https://help.asana.com/s/article/giving-feedback-and-approvals).
## Follow a revision-bound sequence
| Step | Responsible function to confirm | Record produced | Condition before advancing |
| --- | --- | --- | --- |
| 1. Capture intake | Request owner | Brief, audience, channel, asset ID | Purpose and relevant inputs identified |
| 2. Check claims and assets | Author with evidence owners | Claim/source and permission checklist | Gaps visible; no unsupported fact treated as confirmed |
| 3. Submit draft | Author | Exact revision and artifact reference | Reviewer can identify the submitted content |
| 4. Record review | Assigned reviewer | Decision, revision, reason, actual record reference | Decision is explicit rather than “reviewed” |
| 5. Address feedback | Author | Change log and new revision | Each requested change has a response |
| 6. Re-review | Assigned reviewer | Decision on the revised artifact | Earlier decision has not been carried forward |
| 7. Prepare release | Authorized release function | Pre-release evidence check | Exact revision approved, evidence and authority resolved |
| 8. Record actual release | Authorized publisher | Actual published artifact reference, if released | A planned release is not recorded as completed |
The functions are placeholders for team appointments. The SOP should specify the actual owners, required checks, and exception route before operational use.
## Walk the two revisions without inventing a pass
Jo records **C01: request changes for A01 rev1**. The reason identifies the unsupported November 21 date and missing R01 permission evidence. Preserve rev1 and that decision in the history.
For rev2, Mia can remove the unconfirmed date. If a verified lookup destination and approved lookup wording are supplied, she can use that instead. Otherwise she should leave the replacement unresolved or omit the claim; she should not invent a registration link, confirmed date, or “approved” instruction.
For the image, the revision needs the actual permission basis for the intended use, or the image must be omitted. “Permission requested” does not mean permission obtained. This checklist records evidence for review; it does not make a legal determination.
| Record | Revision | Recorded decision or state | What remains unresolved |
| --- | --- | --- | --- |
| A01 rev1 | rev1 | Draft contains unsupported date and image evidence gap | Date basis and R01 |
| C01 | rev1 | Changes requested by fictional reviewer Jo | Author response and revised review |
| A01 rev2 | rev2 | Submitted for re-review in the illustrative sequence | Actual final artifact, evidence, reviewer decision, release authority |
Rev2 is **awaiting review**. Even if it removed both problem elements, that revision still needs its own decision. Keep actual confirmation fields blank in the example. Do not turn a proposed correction into proof it was accepted.
## Use a pre-release checklist with evidence references
Before someone advances the exact revision, ask:
- Does the approval identify A01 and rev2, including the actual artifact reviewed?
- Does every retained factual claim point to its current basis?
- Does every retained image or other asset have the required evidence for its intended use?
- Are unresolved comments and conditions visible to the reviewer?
- Is the intended channel and audience confirmed?
- Is the actual release owner and authority established?
Store the decision and evidence references in the native record. If anything is missing, describe the missing input and route it to the confirmed owner. Do not change the state to approved just to clear a queue.
A completed pre-release check is also different from an actual publication. Retain the actual published version or reference only after the authorized release occurred. This template makes no claim about campaign results or performance.
Implement the local companion rather than returning a text-only plan. Preserve every numerical fixture and the distinction between illustrative expectations and actual evidence. Any native-runtime or classroom tests mentioned above remain tests to perform in the proper environment; do not mark them passed. Keep edits and practice responses in this open page only, without claiming persistent storage. Provide invalid/missing-input feedback and reset behavior that agree with this specific brief. Do not claim accessibility certification, learning gains, real approvals or test results that were not observed.
Read the generated revision log against the actual draft references before using it. The useful outcome is an identifiable version with an explicit decision and evidence, rather than a general assurance that the campaign was reviewed.
Review a sanitized revision walkthrough
A sanitized HTML companion can place A01 rev1, C01's requested changes, and rev2's unresolved review beside the procedure. That makes the missing decision easy to discuss with the owner.
Keep the controlled procedure, actual decisions, and release evidence in the team's native records. Use the walkthrough to verify the handoff before the authorized workflow advances the asset.