An internal communication SOP template should answer two questions before choosing a channel: what is the update's actual status, and who needs to act on it? After a message is sent, it should answer a third: what evidence shows the required recipients acknowledged it?
The original fictional Cedar Team example below follows a file-format proposal through those checks. It gives you a routing matrix, message brief, and acknowledgement/exception log to adapt in the team's native document or tracker. It does not send any messages.
Confirm the change before announcing it as active
In the supplied scenario, U01 proposes changing draft submissions from PDF to DOCX. Mia is the author; Leo is an affected writer and Jo an affected reviewer. The required approval record A01 is absent.
The correct current status is Proposed. There is no basis for saying the DOCX requirement is active.
| Update field | Fictional example |
|---|---|
| Update ID | U01 |
| Subject | Proposed draft file-format change |
| Current requirement in scenario | |
| Proposed requirement | DOCX |
| Author | Mia |
| Affected roles | Leo, writer; Jo, reviewer |
| Approval basis | A01 absent |
| Decision owner | TO CONFIRM |
| Agreed channel and response expectations | TO CONFIRM |
First ask the actual decision owner to confirm the status and supply the decision reference. Keep the proposal and the approval record separate. A discussion about the proposal is not evidence that it took effect.
The procedure itself also needs a controlled header: ID, revision, owner, approval status, and effective date. Supply those through the team's existing process rather than treating this filled example as an approved company policy.
Build a route from the team's working agreements
Define each channel's purpose, audience, and communication standards. Atlassian's working-agreements guidance asks teams to make those choices and define escalation ownership and how decisions will be communicated. It supports a team-agreed route, rather than one universal channel or response time. Atlassian, Working Agreements.
Use this original matrix to capture those decisions:
| Event | Intended audience | Route to confirm | Required evidence |
|---|---|---|---|
| Proposal needing a decision | Confirmed decision owner and necessary contributors | Team's agreed decision route | Proposal reference and actual decision |
| Approved operational change | Roles whose work changes, including writer and reviewer | Team's agreed update channel | Exact approved version and actual message reference |
| Missing required acknowledgement | Recipient and confirmed escalation owner | Team's agreed follow-up route | Required acknowledgement status and escalation decision |
| Restricted or confidential update | Authorized recipients only | Approved restricted channel | Confirmed classification and audience |
For U01, the applicable decision route is still TO CONFIRM. Do not select a public channel simply because it is convenient. Confirm the update's confidentiality classification, recipient roles, and channel rules before drafting a message for distribution.
Avoid “send to everyone” as a substitute for identifying affected roles. Leo needs to understand what to submit; Jo needs to understand what to review. The confirmed owner decides whether other roles are affected and how acknowledgement is required.
Write a message brief before a message
The reusable brief should include update ID, status, exact decision or proposal reference, audience, requested action, timing basis, channel, confidentiality, and acknowledgement requirement.
For the current proposal, a draft request could read:
U01 is a proposed change from PDF to DOCX for draft submissions. A01 is not present in the supplied record. Please confirm the responsible decision owner, approval status, and the reference governing any change. Leo's submission work and Jo's review work are affected. The communication route and response expectations remain to be confirmed.
That wording asks for a decision; it does not announce a new active format. It is an original draft for adaptation, not an actual message sent to Cedar Team.
Only after the actual approval is supplied should the operational-update brief identify the approved version, governing reference, effective timing if supplied, affected roles, and required action. Leave missing fields unresolved. Do not borrow a proposed date or response deadline and present it as approved.
Follow the procedure through distinct evidence states
- Identify the event and check confidentiality.
- Confirm its actual status and source reference.
- Map the affected roles and intended recipients.
- Select the route from the team's supplied standards.
- Prepare the message against the exact proposal or approved change.
- Record actual sending with its message reference, when it occurs.
- Collect the acknowledgement required by the team agreement.
- Route unresolved decisions or missing acknowledgements through the confirmed escalation process, then retain the actual outcome.
Each step produces a different record. An intended recipient is not proof a message was sent. A sent message is not proof it was read, understood, or acknowledged. Define the acknowledgement evidence your team actually requires rather than inferring it from a notification or an empty checkbox.
Preserve an unresolved acknowledgement
Use a separate illustrative communication-log case, L01, to practice the later states. Its fictional record says a message was sent, but Leo's acknowledgement field is blank. The actual approval reference, channel, and other confirmations are not supplied by that one sent-state entry.
| Evidence field | L01 illustrative state | Interpretation |
|---|---|---|
| Intended recipient | Leo | Audience identified in this case |
| Sent state | Recorded as sent in the fictional log | Does not establish approved content or acknowledgement |
| Actual message reference | Blank example field | Supply the operational reference before verification |
| Leo acknowledgement | Missing | Acknowledgement unresolved; do not infer a read receipt |
| Escalation record | E01 proposed exception record | No completed escalation established |
| E01 decider, deadline, channel | TO CONFIRM | Follow-up authority and route unresolved |
This later-state example does not advance U01 from Proposed to Approved. Keep it distinct from the current approval gap so a demonstration of sending does not become an invented approval chain.
For E01, record the missing acknowledgement, attempted follow-up if any, actual decider, agreed route, supplied deadline, decision reference, and outcome. Keep actual-action fields blank until there is evidence. A deadline cannot be called missed while the deadline itself is unknown. Likewise, opening an exception row does not mean escalation reached a decision owner.
Copy this prompt to prepare the complete procedure
Create one complete, self-contained US-English HTML companion for “Cedar Team • communication procedure”. 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 U01 · Proposal; L01 · Sent log / acknowledgement gap; Proposal needing a decision; Approved operational change; Missing required acknowledgement; Restricted or confidential update; Review the record gaps; Prepare separate review brief; 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 internal communication SOP in US English using
our native procedure and tracker format: [enter]. Actual owner, procedure revision, approval/effective status: [enter]. Channel purposes/audiences/standards: [enter team agreement]. Confidentiality and authorized recipient rules: [enter]. Required acknowledgements and evidence: [enter]. Escalation decider, route, timing and decision-record rules: [enter]. Leave missing details TO CONFIRM; do not invent channels or SLAs.
Return a controlled header, scope, ordered procedure, event-routing
matrix, reusable message brief, acknowledgement log, escalation log,
and records checklist. Separate proposal, approval, message and
acknowledgement references, with exact update/version identity.
Use this labeled fictional current example:
Cedar Team U01 proposes PDF -> DOCX for draft submissions. Author Mia; affected writer Leo and reviewer Jo. A01 approval absent. U01 stays Proposed; do not announce DOCX as active. Decision owner,
route, timing and acknowledgement requirements are TO CONFIRM. Provide a draft request for status/owner/approval evidence, not an
actual message. Show a blank approved-update brief for use only
after actual approval and its exact reference are supplied.
Keep this later-state audit case separate:
Illustrative L01 has a sent-state entry and Leo acknowledgement
missing. Actual message-reference/approval/channel fields remain
blank unless supplied. Sent does not prove read or acknowledged. E01 exception has decider/deadline/channel TO CONFIRM; no completed
escalation or missed deadline may be claimed. Do not use this case
to advance U01's actual approval state.
Steps: identify event/confidentiality; confirm status/source; map
affected roles; use agreed route; draft exact referenced message;
record actual send; collect required acknowledgement; handle gaps
through the confirmed escalation process and retain actual outcome.
Preserve unknowns and separate intended, sent and acknowledged
states. Do not invent private data, approvals, read receipts,
response times, sent messages, integrations or completed outcomes. Return complete editable text and blank reusable records in our
requested format. Do not contact anyone or send 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.
# Internal Communication SOP Template: Separate a Sent Update From an Approved Change
“Please submit DOCX instead of PDF” sounds like a new instruction. But if the change is still a proposal, that message can send people to work under a requirement nobody approved.
An internal communication SOP template should answer two questions before choosing a channel: what is the update's actual status, and who needs to act on it? After a message is sent, it should answer a third: what evidence shows the required recipients acknowledged it?
The original fictional Cedar Team example below follows a file-format proposal through those checks. It gives you a routing matrix, message brief, and acknowledgement/exception log to adapt in the team's native document or tracker. It does not send any messages.
## Confirm the change before announcing it as active
In the supplied scenario, **U01** proposes changing draft submissions from PDF to DOCX. Mia is the author; Leo is an affected writer and Jo an affected reviewer. The required approval record **A01** is absent.
The correct current status is **Proposed**. There is no basis for saying the DOCX requirement is active.
| Update field | Fictional example |
| --- | --- |
| Update ID | U01 |
| Subject | Proposed draft file-format change |
| Current requirement in scenario | PDF |
| Proposed requirement | DOCX |
| Author | Mia |
| Affected roles | Leo, writer; Jo, reviewer |
| Approval basis | A01 absent |
| Decision owner | TO CONFIRM |
| Agreed channel and response expectations | TO CONFIRM |
First ask the actual decision owner to confirm the status and supply the decision reference. Keep the proposal and the approval record separate. A discussion about the proposal is not evidence that it took effect.
The procedure itself also needs a controlled header: ID, revision, owner, approval status, and effective date. Supply those through the team's existing process rather than treating this filled example as an approved company policy.
## Build a route from the team's working agreements
Define each channel's purpose, audience, and communication standards. Atlassian's working-agreements guidance asks teams to make those choices and define escalation ownership and how decisions will be communicated. It supports a team-agreed route, rather than one universal channel or response time. [Atlassian, Working Agreements](https://wac-cdn.atlassian.com/team-playbook/plays/working-agreements).
Use this original matrix to capture those decisions:
| Event | Intended audience | Route to confirm | Required evidence |
| --- | --- | --- | --- |
| Proposal needing a decision | Confirmed decision owner and necessary contributors | Team's agreed decision route | Proposal reference and actual decision |
| Approved operational change | Roles whose work changes, including writer and reviewer | Team's agreed update channel | Exact approved version and actual message reference |
| Missing required acknowledgement | Recipient and confirmed escalation owner | Team's agreed follow-up route | Required acknowledgement status and escalation decision |
| Restricted or confidential update | Authorized recipients only | Approved restricted channel | Confirmed classification and audience |
For U01, the applicable decision route is still TO CONFIRM. Do not select a public channel simply because it is convenient. Confirm the update's confidentiality classification, recipient roles, and channel rules before drafting a message for distribution.
Avoid “send to everyone” as a substitute for identifying affected roles. Leo needs to understand what to submit; Jo needs to understand what to review. The confirmed owner decides whether other roles are affected and how acknowledgement is required.
## Write a message brief before a message
The reusable brief should include update ID, status, exact decision or proposal reference, audience, requested action, timing basis, channel, confidentiality, and acknowledgement requirement.
For the current proposal, a draft request could read:
> U01 is a proposed change from PDF to DOCX for draft submissions. A01 is not present in the supplied record. Please confirm the responsible decision owner, approval status, and the reference governing any change. Leo's submission work and Jo's review work are affected. The communication route and response expectations remain to be confirmed.
That wording asks for a decision; it does not announce a new active format. It is an original draft for adaptation, not an actual message sent to Cedar Team.
Only after the actual approval is supplied should the operational-update brief identify the approved version, governing reference, effective timing if supplied, affected roles, and required action. Leave missing fields unresolved. Do not borrow a proposed date or response deadline and present it as approved.
## Follow the procedure through distinct evidence states
1. Identify the event and check confidentiality.
2. Confirm its actual status and source reference.
3. Map the affected roles and intended recipients.
4. Select the route from the team's supplied standards.
5. Prepare the message against the exact proposal or approved change.
6. Record actual sending with its message reference, when it occurs.
7. Collect the acknowledgement required by the team agreement.
8. Route unresolved decisions or missing acknowledgements through the confirmed escalation process, then retain the actual outcome.
Each step produces a different record. An intended recipient is not proof a message was sent. A sent message is not proof it was read, understood, or acknowledged. Define the acknowledgement evidence your team actually requires rather than inferring it from a notification or an empty checkbox.
## Preserve an unresolved acknowledgement
Use a separate illustrative communication-log case, **L01**, to practice the later states. Its fictional record says a message was sent, but Leo's acknowledgement field is blank. The actual approval reference, channel, and other confirmations are not supplied by that one sent-state entry.
| Evidence field | L01 illustrative state | Interpretation |
| --- | --- | --- |
| Intended recipient | Leo | Audience identified in this case |
| Sent state | Recorded as sent in the fictional log | Does not establish approved content or acknowledgement |
| Actual message reference | Blank example field | Supply the operational reference before verification |
| Leo acknowledgement | Missing | Acknowledgement unresolved; do not infer a read receipt |
| Escalation record | E01 proposed exception record | No completed escalation established |
| E01 decider, deadline, channel | TO CONFIRM | Follow-up authority and route unresolved |
This later-state example does not advance U01 from Proposed to Approved. Keep it distinct from the current approval gap so a demonstration of sending does not become an invented approval chain.
For E01, record the missing acknowledgement, attempted follow-up if any, actual decider, agreed route, supplied deadline, decision reference, and outcome. Keep actual-action fields blank until there is evidence. A deadline cannot be called missed while the deadline itself is unknown. Likewise, opening an exception row does not mean escalation reached a decision owner.
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.
Check the generated procedure against one proposal and one missing acknowledgement. If it can show what remains unresolved without changing either into a completed state, the records are doing their job.
Review a sanitized routing walkthrough
A sanitized HTML companion can display U01's missing approval, the affected roles, and L01's separate acknowledgement gap beside the procedure. That helps the owner examine which evidence is needed at each handoff.
Keep actual decisions, messages, and acknowledgements in the team's native records. Confirm the route and authority before taking the next communication action.