Overview

We offer Emergency Response services for our Core Coverage clients. When there is an “emergency flaw”, we promise to jump in and investigate within our Emergency Response SLA timeline.

We may or may not be able to fix the issue immediately or entirely within Core Coverage – some issues take longer or outside our scope.

Process

When we identify an emergency flaw

If someone on our team identifies an emergency flaw they should alert the Strategist immediately by phone, using the information in the .

If the Strategist cannot be reached, they should try the PM, then the lead developer, according to the hierarchy in the .

Once the Strategist is alerted they should confirm the issue and reach out to the relevant people on our side to fix.

If the issue turns out not to be an emergency or we need more time to fix it, it should be logged in Asana appropriately.

Once the resolution is in progress, the Strategist should alert the client using their emergency contact information in the . Try phone first, then texting, slack, and email, in that order. This alert should be relatively informal since time is of the essence. Highlight the specific issue that happened, what we believe caused it, what the steps to resolve are, and what our timeline is.

When the client reports an emergency flaw

The client should reach out first to the Strategist. If they can’t reach the Strategist they are advised to try and reach the PM, then the lead dev.

Whomever is able to answer should triage the problem. If it is confirmed, they should reach out to the rest of the team as appropriate to resolve. If the issue turns out not to be an emergency, the issue should be logged in Asana as appropriate.

Upon Resolution

After resolution, the Strategist should inform the client that we have solved the problem. The update should include the fixes put in place, the hours we spent doing so, and and expected ramifications or effects as a result of the issue (IE sporadic outages, loss of data, or similar).

We should also prepare the client for any potential side-effects moving forward - this includes but is not limited to slow build times, image inconsistencies, issues logging into things, delayed form responses etc. Anything we think is relevant to the client should be shared, but we should be careful not to unnecessarily confused, concern or panic our clients as a result.

The report should be informative without being potentially confusing - some clients will understand technical explanations best, others need layman's terms, so we should err towards the idea that simpler is better.

We should also ensure we are empowering our clients with the relevant information to allow them to take necessary steps - whether this is letting their stakeholders know of the issue or locking down email services/credit card details, there should be no reason for a client to be delayed or blocked from our end.

Please use the following template for incident reporting during emergency response situations.

Internal Debrief

After any emergency, we should carry out an internal debrief. This should be at least a Slack convo if not a full meeting for a major incident. We should go through the issue, our investigation, the resolution, and how we can avoid it in the future. This should be saved or documented (again internally) so that if the client, or a client with the same or similar setup, runs into this issue again, we have a quick way to resolve it.