Alerts are Killing Us – And What to Do Instead

Françoise Tourniaire

Founder and Owner, FT Works

Most support managers have a hidden-away email folder full of alerts they never look at, never wanted in the first place, or never took the time to turn off. Every day, the case-tracking system creates oodles of automated alerts and their email system faithfully routes them to the folder of shame and willful ignorance.

What is wrong with these alerts?

• They rely on crude indicators such as case priority or customer name. So if a third-party implementor working with a VIP customer runs into a critical issue, no alert will fire, most likely, because the alert was created against the customer name, not the third-party’s.
• They miss crucial dynamic changes. Yes, some support-tracking system can create alerts for missed SLAs, but time-based events are not ideal predictors. For instance, if a customer repeatedly asks for an update but the case is within the general update SLA target, no alert will be generated.
• They ignore the content of cases. Continuing on the example above, if the customer is asking for an update using angry or salty language, the support-tracking system literally cannot tell that there is urgency behind the request. And it cannot tell, either, that the last update from the support engineer was full of danger phrases.
• They are useless to outside teams. There is often a crowd of onlookers for support issues: customer success managers (CSMs), sales reps, engineering managers, product owners. While they can receive alerts, they are often barred by restrictive licensing rules from actually seeing the details of the cases—so we create alerts that (1) rely on not very relevant criteria (2) do not reflect the actual content of the situation and (3) alarm onlookers without giving them actual data. It’s a recipe for chaos, tangled threads, and wasted internal resources.
• They cannot be turned off. Well, they can, theoretically, but since they are created in a piecemeal manner and there is rarely a good dashboard to review them, the email folder of shame is a much more rational solution to the onslaught.

My Prescription

We can do better!

Alerts can be invaluable to catch issues before they become escalations, before they become stuck in black holes, before they create internal dissension. It allows Support to move to just-in-time actions rather than just reacting to outside events.

Here’s my prescription for better alerts:

• Targeted. If I need to know about cases from a particular contact at the Nashville site of Customer X or from the Hyderabad site of their implementation partner, I should be able to do that without having to resort to strange contortions in the underlying database structure.
• Content-based. I want the system to be smart enough to detect customers’ frustration, awkward phrasing by the support engineers, unusual product requests, or unexpected flurries of activity, not just the standard triggers case opening, closing, and update cadence.
• Useful to non-support actors. I want to be able to send targeted, content-based alerts to anyone who may want them and to allow outside actors to interact with the underlying cases at will. Better-targeted alerts are already very useful, but being able to see case details (and add notes!) will calm anxious outsiders.
• Easy to manage. I want to be able to create sophisticated alerts without having to read a manual or watch a video. I should be able to adopt suitable alerts created by others. And I want to receive alerts wherever I’m working, be it Slack or text messages or a workflow engine.

The case-tracking vendors have not delivered on the prescription. AI vendors can, perhaps?

For more information about FT Works or to read insightful customer support blog posts Françoise has written and posted to her website, check out https://www.ftworks.com/.

Editor’s note: Learn about new SupportLogic Intelligent Predictive Alerts.