How to use this resource
A Telegram campaign postmortem compares the approved hypothesis and controls with what actually happened. It separates facts from interpretations, analyzes source, selection, message, delivery, replies, handoff, outcomes, and harm signals, identifies system causes, and assigns a small set of testable corrective actions.
A retrospective that celebrates reply rate teaches very little. A retrospective that blames the sender teaches people to hide weak signals.
The postmortem should improve the next decision, even when the campaign met its commercial target.
Included in the template
01A copy-ready review structure.
02A seven-layer campaign analysis.
03Root-cause prompts that avoid hindsight bias.
04An action register with effectiveness checks.
1. Executive record
- Campaign and owner: [link to approved brief]
- Period and scope: [sources, cohort, accounts, messages]
- Hypothesis: [copied exactly from launch]
- Primary outcome: [result with numerator, denominator, and window]
- Control outcome: [incidents, restrictions, complaints, suppression, backlog]
- Decision: continue, revise, stop, or run a new controlled test.
2. Timeline
| Time | Observed event | Decision and evidence |
|---|---|---|
| T0 | Approval and launch | Version, reviewers, assumptions |
| T1 | First delivery and replies | Early signal and interpretation |
| T2 | Material change or threshold | Who acted and why |
| T3 | Pause, completion, or incident | Control response |
| T4 | Outcome window closed | Final dataset and exclusions |
3. Analyze seven layers
| Layer | Question |
|---|---|
| Source | Did the groups contain the expected roles and intent? |
| Selection | Were eligibility and exclusions reliable? |
| Message | Was identity, relevance, value, and ask clear? |
| Execution | Did delivery follow approved accounts, proxy routes, and limits? |
| Reply | What did positive, negative, and ambiguous replies reveal? |
| Handoff | Were useful replies owned and resolved on time? |
| Outcome and control | Did value persist without unacceptable harm or risk? |
4. Find system causes
- What assumption proved false?
- What signal was available but ignored or hidden?
- Which control existed only in documentation?
- Why did the action make sense to the operator at the time?
- What dependency, incentive, interface, or ownership gap contributed?
- Where else could the same condition exist?
5. Commit to fewer, stronger actions
| Action | Owner | Due | Evidence of effectiveness |
|---|---|---|---|
| [Specific control or workflow change] | [Name] | [Date] | [Test or metric] |
| [Detection improvement] | [Name] | [Date] | [Alert exercise] |
| [Documentation or training] | [Name] | [Date] | [Observed behavior] |
Close only after verification
Shipping an action is not proof that risk fell. Schedule an effectiveness review and reopen the issue when the test fails.
Research note
This template combines experiment review with blameless incident-learning principles. Adapt the depth to campaign risk and preserve privacy when discussing recipient data.
Use it in the next review
The postmortem is where campaign activity becomes organizational knowledge. Keep the facts precise, the analysis humane, and the actions measurable.
Preserve the evidence behind every campaign decision
TeleBoost connects campaign configuration, contacts, conversations, tickets, teams, and analytics so reviews start from an owned operational record.
Continue the operating system