CRITICAL CLIENT SUPPORT

When a client experiences a critical issue and needs immediate support, our team needs to react in a systematic, focussed manner and ensure that the client is receiving regular updates.

What is a critical issue?

From our clients’ perspectives, everything is critical and needs our immediate, undivided attention. But from our perspective, as described in our SLA agreement, this is how“critical” is defined:

The client’s website is not loading for multiple users
The website is loading, but showing an error instead of content or the content is significantly malformed or out of place
The website appears to have been defaced/hacked in some manner
Any urgent security-related matter

Realistically, it would be impossible to describe all of the possible issues that would be considered critical. The guiding principle behind determining whether or not something is considered an emergency and/or a critical issue is quite simple: if the problem represents imminent harm to the client’s organization or brand, it’s an emergency. If not (or if you’re not sure), it’s probably not an emergency.

The critical support process

When a client issue has been identified as critical by either the president, project manager or CTO in consultation with the lead developer on the project, here are the steps to follow:

Project manager (PM) provides a quick response to the client via their regular mode of communication (Slack/phone/email/Bugherd) to

Let them know we are in the process of investigating the issue.
Ask for additional information or clarifying questions
- - The URL for the specific page
  - Steps taken prior to the issue appearing
  - Screenshots or recordings of the issue occurring
  - Any other steps to help the team understand the scale/scope of the issue

PM provides these initial findings to the lead developer on the project in the internal Slack channel.
Lead developer conducts an initial investigation of the issue and reports back to the PM with any findings. If required, PM and developer will identify additional internal (other devs) or external resources (partners, subject matter experts) to consult with. The PM will arrange a quick huddle with those resources if required.
PM and lead developer work together to write a description of those initial findings with appropriate detail (layperson/non-technical or technical) and next steps to be shared with the client. PM shares this information with the client and assures them that this issue is receiving our attention.
If required, PM arranges a Zoom meeting with the developer and client to discuss the issue and perhaps do a screen share to further diagnose the issue.

Repeat steps 3 to 5 until the resolution is identified.

PM updates the client with details of the identified resolution and provides a timeline when that resolution will be implemented. If site downtime will be required, PM will work with the client to schedule this and advise the developer.
Developer implements the fix and advises the PM when the issue is resolved.
PM updates the client that the issue has been resolved and asks the client to review the fix and advise if any other support is required.

After the issue is resolved

In the days following the resolution of the critical issue, the PM should check in with the client to ensure that the issue has not reappeared. Depending on the nature of the issue, it may be beneficial to have a post-mortem with the team to highlight any learnings from the resolution and identified best practices or, indeed, how the resolution process itself could be improved.

Page updated

Report abuse