Creation of Workaround Support Matrices for Known Issues

Building on the previous article: any organization will always have that list of common repetitive tasks which are in the development pipeline to be corrected, but still causing issues in production. In the mean time you need to ensure you are operating smoothly and are able to quickly work around these issues to stay functional. What is the easiest way to ensure your team has a complete list of how to quickly identify and easily workaround the issues?

Create support matrices for customer facing and internal issue identification with workarounds to ensure timely resolution of your known issues.

Types of Support Workarounds

---

Empower Tier 1 / 2 with solutions they can give to customers on first contact. External customers will be contacting you about known issues in your software. The goal of any efficient support organization is to try and fix their issues the first time they reach out. One way to do this is by having a list of known issues where there are support workarounds. If the support teams are familiar with these lists and are updated daily on new items added, you stand a stronger chance of fixing during a first contact. Example data points to display on this list might be:

• Customer complaint / symptoms of the problem

• Workarounds (differentiate those which can be done by customers vs. need engineering help)

• Development ticket to start tracking

• ETA (if known)

Give Tier 3 and your NOC team a documented list of the backend workarounds. There will be some fixes which need to happen on the backend and cannot be completed by customer facing support teams. Also internal workarounds which need to be completed by operational teams crop up over time which must be completed by those with systems or database access. These tasks merit their own documentation to ensure these are easy to find and understand by the backend support teams. By creating this list it allows your operational support teams to quickly respond to known issues which arise. The data points for this list should be:

• Description of the issue / repetitive task

• Source of task (customer complaint tickets / known system issue)

• Steps or actions to perform to workaround and fix the issue

• Schedule to run or check (if applicable)

Dynamic Data Sourcing

---

The list you are developing here does not need to be manually managed. If you have an integrated and customizable bug tracking system, you can pull this data out of the list of issues you have already tracked.

Each of these items is a bug! Make sure it is logged as one, any part of the system which does not operate without human intervention is a problem. This lets you visualize in one place all of your issues which need manual intervention to be fixed.

Capture the data points from above. Add the data points you capture for these as custom fields in the development / fix tickets. As part of the triage process ensure these fields are required as part of the escalation process.

Create a report of these tickets using just these custom data points using the source of the report as the bug list. Make sure and tie the status of the tickets to their presence in the report so as tickets are opened or closed, they automatically appear and disappear from the report. You want this report to be as up to date as possible so people have faith in its data.

Keep people educated on these issues. Allow people to subscribe to this report to be notified of changes to it so support teams are up to date with the latest issues they need to support and how to quickly workaround. You can also host a daily training on the new issues which come in to ensure there is an understanding of the new issues.