# Social media crisis plan: what your team needs to record

> Decide who verifies facts, who publishes and when the next update is due while the response is still underway.


**A social media crisis plan is the operating agreement that assigns who verifies each fact, who can publish an update and how the team keeps communicating until there is evidence to close the incident.** It coordinates operations, customer support and the community manager when service status and public questions move at different speeds.

The plan organizes social message coordination from activation through documented closeout.

## What the plan handles

A critical conversation may surface before the team knows its cause or scope. The plan says who checks those details, who turns them into a public update and when the team will report again. It also defines how to hand responsibility to another person and what evidence supports saying the incident is over.

Each task has a different purpose. [Social listening](/en/guides/social-listening-examples/) helps detect and analyze conversations as a group. [Comment moderation](/en/guides/social-media-comment-moderation/) handles a decision about an individual comment. A [content approval workflow](/en/guides/social-media-content-approval-workflow/) reviews planned posts before publication. A crisis plan coordinates messages after a confirmed issue calls for a shared response.

Agree in advance on the fact that activates the plan, who makes that call and who can take over. The trigger should fit the operation and the team’s actual capacity. A fixed mention count or a promise to respond within ten minutes cannot serve as a universal rule for every brand.

## Assign an owner to each fact

The team needs someone to lead coordination and someone who can verify each claim. In a small team, one person may cover more than one function; the record should still show who owns each task at that moment.

| Function | What they verify or decide | What they record |
| --- | --- | --- |
| Operations | Service status, confirmed scope and signs of recovery. | Source of the check, time and responsible person. |
| Customer support | Incoming questions and help options that are confirmed. | Repeated questions, current reply and open cases. |
| Community manager | Drafting and publishing updates on agreed channels. | Published copy, link, time and questions routed elsewhere. |
| Incident lead | Activation, next update time, handoff and the promotional content decision. | Decision, reason, owner and review time. |

The person posting should not fill in details that operations is still checking. If the cause, number of affected bookings or recovery time is unknown, mark it as open and assign someone to review each question.

## State what is known and when you will update

This is a fictional case. The team has confirmed that its booking service is unavailable. It does not yet know the cause, which requests may be affected or when the service will return.

**Two updates for the same incident**

**No next step**

We’re looking into a booking issue. More soon.

**Status and a set time**

We’ve confirmed that our booking service is unavailable. The cause and scope are still being checked. We’ll post the next update on 6 October 2026 at 14:30 UTC.

*Fictional case. The time says when the team will communicate again, not when service will be restored.*

The second update separates confirmed information from open questions and sets the next communication time with a date, time and explicit zone. Choose a time the team can keep even if the investigation is still open. That commitment sets an update time, not a recovery deadline. If the team confirms a new fact earlier, it can post sooner and keep the next check-in time.

## Keep a record of facts, decisions and handoffs

The working record holds the current version of the incident. Each fact needs a source and a verification time. Each open question needs an owner and a time for its next check.

| Entry | What to record | When it is closed |
| --- | --- | --- |
| Confirmed fact | Exact detail, operations source and time with zone. | When a new check confirms or corrects it. |
| Open question | Question, owner and next check. | When the responsible source provides evidence. |
| Public update | Copy, channel, link and publication date and time. | When the next update is recorded. |
| Promotional content | Continue, pause or resume; reason, owner and next review. | When the owner confirms the decision. |
| Handoff | Last update, current facts, open questions, next time and incoming owner. | When the incoming owner confirms receipt. |
| Closure | Agreed criteria, evidence, demonstrated scope, verifier, time and open follow-up. | When operations confirms the criteria for the stated scope and the team posts a closeout. |

Pausing or resuming promotional content is a separate operational decision. Record which items the team reviewed, who decided and when the decision will be checked again. Resume an item after its owner confirms it still fits the current situation; the plan does not need to order an automatic pause for every brand.

At shift change, the outgoing owner passes along the latest public update, its sources, open facts, the agreed next update and the incoming owner’s name or role. The incoming owner acknowledges the handoff. That keeps the time commitment in place even when the person posting changes.

## Close after the team verifies recovery

Before an incident, agree with operations on which signals count as recovery and which part of the service each check covers. In the example, one test booking demonstrates only the path that was tested. Record the result, time and scope; leave untested flows open. The community manager communicates that exact status.

The incident record’s closeout includes the agreed criteria, evidence, demonstrated scope, who checked it, the last public update and any remaining follow-up. Communicate recovery only for the scope supported by the checks. Keep unverified flows open. A quieter social conversation does not confirm that the service is back.

The UK Government Communication Service presents PRIMER as a framework to plan, rehearse, implement, maintain, evaluate and recover emergency communications. It is written for public-sector communication; here it informs continuity and review, rather than setting a requirement for brands. [Read the Emergency Planning Framework Primer](https://www.communications.gov.uk/publication/emergency-planning-framework-primer/).

The Government Digital Service Social Media Playbook describes its escalation process and scenario exercises. It is a coordination reference from UK government, not a universal rule for commercial teams. [See the Social Media Playbook](https://www.gov.uk/guidance/social-media-playbook).

## Download and adapt the template

The template keeps fields for owners, confirmed facts, open questions, the next update, promotional decisions, handoffs and evidence of closure. Adapt it to your team’s channels and roles before you need it. You can also [download the editable crisis plan as a text file](/blogs/social-media-crisis-plan/plan-en.txt).

#### Complete the plan for your team

```text
Incident and activation time: [name, date, time and zone].
Activation trigger: [fact that starts the plan and decision owner].
Incident lead and backup: [role, internal contact and backup].
Agreed channels: [accounts and formats to use].
Operations: [who confirms status and where they record evidence].
Operational recovery criteria: [signals agreed with operations and their scope].
Customer support: [who verifies replies and help options].
Community manager: [who publishes and records updates].
Confirmed facts: [detail, source, owner and verification time].
Open questions: [question, source to check, owner and next check with zone].
Public update: [confirmed facts, open details, verified help option, channel and copy].
Next public update: [date, time and explicit zone].
Publication: [owner, link and time].
Promotional content: [items reviewed, decision, reason, owner, review time and condition for resuming].
Handoff: [last update and link, current facts, open questions, next update time, incoming owner and receipt confirmation].
Closeout: [agreed criteria, evidence and demonstrated scope, verifier, time, link and follow-up owner with next check].
```

The example and template are HeyMark editorial work. Edit the file in any text editor; it does not create posts or connect to the product.

## Plan your next post in HeyMark.

Keep the idea, review the draft with your team, and see how it performed in the accounts you connected.

[Start free](https://app.heymark.ai) · [See how it works](https://heymark.ai/en/#product)

## Developer and agent resources

- [HeyMark MCP documentation](https://heymark.ai/en/mcp/)
- [llms.txt](https://heymark.ai/llms.txt)
- [Full site content for language models](https://heymark.ai/llms-full.txt)
- MCP protocol endpoint: `POST https://mcp.heymark.ai`
- OAuth protected-resource metadata: [/.well-known/oauth-protected-resource](https://mcp.heymark.ai/.well-known/oauth-protected-resource)
- MCP server card: [/server-card](https://mcp.heymark.ai/server-card)