SaaS PR beyond the launch is the work of keeping customers informed when the product breaks, changes or retires. Atlassian's post-incident review shows the stakes: on April 5, 2022, 775 customers lost access to their products, some for up to 14 days. A launch plan covers one day. A post-launch plan covers the days customers decide whether to renew.
What does SaaS PR cover after the launch?
SaaS PR after launch covers four moments when customers watch how a vendor behaves: an outage, a security failure, a product change and a product retirement. Each moment has a trigger, a first message, an owner and a document to publish. The table is the plan I would put in front of any software founder before the first renewal.
| Moment | Trigger | First message | Owner | Proof to publish |
|---|---|---|---|---|
| Outage | Customers lose access or data | Status page update plus direct email to account owners | Incident communications lead | Post-incident review |
| Security failure | Unauthorized access or a privacy lapse | Holding statement with a named next update time | CISO and general counsel | Dated remediation plan |
| Product change | New pricing, packaging or terms | Customer notice before the change takes effect | Head of product marketing | Plain-language change log |
| Retirement | An app, feature or integration is shut off | Notice with the date, the replacement and the data path | Product lead and support lead | Migration guide |
These four moments matter because customers judge a software vendor when something goes wrong, not when something ships. A renewal decision rests on what the account owner remembers about the last bad day. Fill the table in before launch, because the first test arrives without warning. My SaaS PR guide covers the launch and coverage side of the same work.
How fast should a SaaS company speak during an outage?
A SaaS company should post its first public acknowledgment within hours and write to affected customers on the first day. Atlassian's status page update came within hours, but its first broad public message and its apology email came later, and its own review says the company should have implemented broader communications much earlier.
The review gives a timeline of the outage that began on April 5, 2022. Times are UTC.
| Time | Channel | What Atlassian said or did |
|---|---|---|
| April 5, 09:03 | Status page | First update: the company was investigating |
| April 6, 17:30 | Media statement | Response to press inquiries |
| April 7, 00:56 | Social media | First broad public acknowledgment |
| April 8, 01:50 | Apology from co-founder and co-CEO Scott Farquhar to affected customers | |
| April 12 | Engineering blog | CTO update with technical detail and the two-week restoration estimate |
The first broad public message came about 40 hours after the first status page update. The company's new playbook commits to acknowledge incidents early, through multiple channels, and to release public communications within hours.
Every update after the first should answer the same six questions. Atlassian's playbook lists them: what happened, who was affected, the timeline to restoration, the share of sites restored, expected data loss with a confidence level and how to reach support. Repeat the answers in the same order each time so a customer can scan for the line that changed.
Why it works: Customers who cannot reach support will look for answers on the channels they already use. Atlassian's review explains that the deletion removed customer contact details and the Cloud URLs that its support form required, so many customers could not file tickets at all (Atlassian, April 2022). A public acknowledgment on social media and a status page reaches the people the email list cannot.
What did Atlassian's post-incident review get right?
Atlassian's post-incident review gave customers a complete written account of an outage, which is the document a security or procurement team asks for after a failure. The company published it on April 29, 2022, and opened with a letter from its two co-CEOs that said "The buck stops with us."
The review gave specific numbers, including the ones that cost the company credibility. It stated that the first estimate of about 400 affected customers was low and that the true count was 775. It also stated that no customer lost more than five minutes of data and that over 99.6 percent of customers kept using the cloud products without disruption.
A SaaS company should publish the same four parts after any serious incident:
- A timeline in clock times, not days.
- The cause, stated as a failure of process and not of a person.
- The count of affected customers, with a note when the count changes.
- A dated list of changes the company will make.
Why it works: A review with a revised number shows buyers the company reports bad news even when it hurts. Atlassian's review states that the customer count came in at close to double its first estimate, and the correction is what makes the other figures believable (Atlassian, April 2022).
How does a SaaS company rebuild trust after a security failure?
A SaaS company rebuilds trust after a security failure by publishing a time-boxed plan and then reporting against it on the dates it promised. Zoom did this in 2020. On April 1, 2020, CEO Eric Yuan announced a 90-day plan that froze work on every feature not tied to privacy, safety or security, according to TechCrunch's report on the freeze.
Yuan published the result on July 1, 2020. The 90-day report from Zoom lists seven commitments and a status for each one, starting with the feature freeze. Zoom also held weekly webinars and posted a recap each Wednesday.
Copy the structure, not the content. Set an end date, name the owner of each commitment and publish a status report on the date you promised. Skip any commitment you cannot measure, because a vague promise gives critics a vague target.
Why it works: A fixed end date turns an open-ended apology into a promise a customer can check. The July 1 report closed the loop on the April 1 pledge, and a reader could compare the two documents line by line (Zoom, July 2020).
When does a product change need its own PR plan?
A product change needs its own PR plan whenever engineering can change what a customer sees, owns or pays without the customer acting first. The Atlassian outage began as a retirement. In 2021 the company folded a standalone app into Jira Service Management and needed to delete the old app from customer sites.
According to the review, a communication gap between the team that requested the deletion and the team that ran it led to the wrong IDs going into the script. The script deleted 883 sites belonging to 775 customers in 23 minutes. The communications failure that followed was a second failure on top of the first.
| Change | Who must know before it ships | What the notice must contain |
|---|---|---|
| Price or packaging change | Account owners and finance contacts | The new terms, the effective date and the contract clause that governs it |
| Feature removal | Admins and daily users | The removal date, the replacement and how to export data |
| App or integration retirement | Admins and partner developers | The shutdown date, what is deleted and what is kept |
| Data migration | Admins and security contacts | The window, the expected downtime and the rollback plan |
Illustrative scenario: a software company plans to retire an integration at the end of a quarter. The product team schedules the shutdown script for that Friday, and the support team learns about it on Thursday. A communications sign-off step would have stopped the script until the admin notice, the migration guide and a support macro were live. The delay costs a few days. The alternative costs a renewal.
Make communications sign-off a step in the change checklist. No retirement script runs until the notice date has passed and a named person has confirmed it went out.
Who owns the customer message when engineering is firefighting?
One named incident communications lead owns the customer message, and that person can publish without a committee. Atlassian's review says it will use the DACI framework, which assigns a driver, approver, contributors and informed parties for each incident, and that it will keep 24/7 backups for each role.
The same review shows how large the support load grows. Atlassian mobilized more than 450 support engineers to run validation checks around the clock so restored sites could be returned to customers. Messages from customers arrived by email, phone, social media and support tickets at the same time, and separate tools slowed the response.
Software companies that want outside help building this structure can start with 5W's SaaS PR practice. For the security side of the same plan, see my guide to the first 24 hours of a breach, and for the full response structure see the crisis communication plan template.
Why it works: A single owner removes the approval delay that kept Atlassian quiet on public channels for about 40 hours. The review names the missing playbook and roles as the cause (Atlassian, April 2022).
What should a SaaS company have ready 30 days after launch?
A SaaS company should have five items ready 30 days after launch: the four-moment table, a status page with a named owner, a post-incident review template, a customer notice calendar for planned changes and a contact list stored outside the product.
Atlassian's own action list included the last item. It said it would back up authorized account contacts outside the product instance, because the incident deleted the contacts it needed.
Run one drill before the first renewal cycle. Pick a hypothetical outage, give the incident communications lead 60 minutes and measure the time to the first status page update. Fix whatever slows it down.
Measure the drill with three numbers: minutes to the first status page update, minutes to the first email to account owners and the number of customers who could not reach support. Write the results into the review template and repeat the drill each quarter.
Frequently asked questions
What is SaaS PR beyond the launch?
SaaS PR beyond the launch is the planned communication for outages, security failures, product changes and retirements after a product is in customers' hands.
Should a SaaS company publish a post-incident review?
Yes, after any serious outage or security incident. Atlassian published one 24 days after its April 2022 outage, with a timeline, a cause, a customer count and a list of changes.
How soon should a SaaS company apologize after an outage?
The company should acknowledge the problem in public within hours and write to affected customers on the first day. Atlassian's apology email went out on April 8, the third day of the outage, and its review says earlier public communication was needed.
Who should sign the customer message?
A senior leader should sign the apology and the incident communications lead should run the updates. Atlassian's review opened with a letter from its two co-CEOs, and Zoom's 90-day report came from its CEO.
What belongs on a SaaS status page?
A status page shows the current state of each product, the start time of each incident, the latest update with its time and the next update time. Atlassian's first status page update came 85 minutes after the deletion began.
Published October 2026.