top of page

Resources Tier 3 Should be Providing to Customer Care

  • Writer: David Peček
    David Peček
  • Jul 28, 2019
  • 3 min read

Updated: Sep 11, 2020


ree

This is intended to be a guide of the various sets of resources a Tier 3 or engineering organization should be providing to customer care teams: Tier 1 and 2. The goal here is to present a complete set of information about the status of applications and any issues that might exist with them. This should be part of a standard toolset provided to these teams. You want the support teams to be able to solve customer issues on the first contact, and this will help to make that possible.

Enabling customer support teams (tier 1 and 2) with application status and system issues allows them to solve issues by either being proactive or having fewer customer contacts driving down support costs.

Resource Goals

Lets start off by reviewing the knowledge we have from engineering. After that we will review how you present that information to the support teams.


Servers and application statuses. The monitoring tools you have currently report on the health of the servers and the applications running on them. While customer care does not need to know details of these, they do need to know if customer facing applications or processes will stop working as a result of problems with these components.


Applications experiencing internal or performance issues. Is the software you are monitoring experiencing a large number of exceptions? Are your monitoring tools reporting applications using a high amount of CPU usage or having slow response times? This will impact how the applications behave and should be communicated to support teams so they are ready for customer complaints about these issues before the first contact.


Known customer facing issues. You have a bug list from tickets entered by support teams which have been fully triaged and are awaiting development. You know all of the details about how the software will behave and who will be impacted. This is another key piece of information to provide.


List of known bugs from QA testing. While customers may not (yet) have called in about an issue, if QA has found this issue, its likely they will be calling in. Is this a list you can easily gather together?


Present the Data

Now that you are aware of which pieces of data should be made available to your teams, lets go over the gathering and effective display of this data. This list should be dynamically sourced from your list of active development issues. None of this should be manual or you risk losing trust in the data as it can easily become stale.


Most common ticketing systems have reporting abilities built into them which will allow you to construct this list easily and be able to present to internal support teams. Ideally the pages which serve this data should auto refresh so support teams have the most up to date data available when they re-visit the tab.


Application status and performance. The most common way of reporting these types of issues is via one of the status page applications. Pick one which works best with the monitoring vendor you use for proper alerting.


Known issues. In another post I have detailed out collection of this data from your bug tracking / development systems.


Inform / Train Teams

Final step in this process now that you know which data to present is to ensure the support teams are trained in how to use the data you are presenting to them.


Status dashboards. The status page vendor you choose will have a dashboard which can be up on computer screens of people working with customers or even up on a big monitor in a call center to assist with one glance system status and performance.


Searchable lists. Known issues should be on a page which has a search field where Tier 1 / 2 can type keywords based on customer complaints and quickly get information on the issue a customer has to know its symptoms as well as workarounds.


Daily informational quick update meeting. One of the more effective tactics which have worked for me is a very brief daily sync up at the beginning of the shift with support teams giving symptoms, workarounds, and ETAs on any major issues as well as new items pending development.

Comments


bottom of page