Real Time Brand Alerts: Which Mentions Deserve an Immediate Notification?

Both failure modes are common

Alerting has two ways to fail and most organisations manage to demonstrate both within a year. Either nothing notifies anyone and a problem is discovered when a customer phones about it, or everything notifies everyone and the notifications are muted within a fortnight — which produces the first failure by a different route.

The muted-channel outcome is the more common and the more insidious, because the system appears to be working. Alerts are configured, they fire, and nobody reads them. Discovering this usually happens during the incident the alerts existed to catch.

Good alert design is therefore mostly about restraint. The question is not what could be alerted on but what genuinely requires a person to stop what they are doing — which is a much shorter list than any tool's default configuration suggests.

The test every alert must pass

Before configuring anything, apply this to each proposed condition. Most proposals fail it.

1. 1

   Would someone act differently in the next hour?

   If the answer is that they would look at it tomorrow, it is not an alert. It belongs in the daily queue. This single question eliminates most candidate conditions.

2. 2

   Is there a defined action?

   An alert with no corresponding action is an interruption. If nobody knows what to do when it fires, either define that or remove the alert.

3. 3

   Is there a named recipient who is actually available?

   Alerting a team distribution list at 2am notifies nobody. A rota with a named person is the difference between an alert and a log entry.

4. 4

   Would it have fired usefully in the past?

   Test the condition against historical data. Conditions that would have fired forty times last month for nothing will do the same next month.

5. 5

   Can a person distinguish it from noise in five seconds?

   An alert that requires investigation to determine whether it matters is a task, not a notification. It should carry enough context to be triaged immediately.

Conditions that genuinely warrant an alert

A short list, which is the point. Most organisations need fewer than eight active conditions.

• Safety-related content: anything suggesting harm, a dangerous fault, or a risk to people. Alerts regardless of volume, sentiment or source.
• Legal or regulatory language: references to regulators, legal action, formal complaints or enforcement. Low volume, high consequence, and a category where delay is expensive.
• Named-account mentions: a defined list of accounts whose mentions matter — significant customers, major media, relevant public figures. Maintained deliberately rather than aspirationally.
• Velocity above baseline: mentions accelerating past a threshold derived from your own history rather than a fixed number, then triaged with a defined procedure.
• Coordinated patterns: similar wording, similar timing, new accounts. Worth knowing early and worth handling differently from organic reaction.
• Specific high-risk keywords: terms drawn from your own past incidents — product names combined with failure language, particular complaint phrases.
• Response-time breach on an item already in the queue: an operational alert rather than a monitoring one, and frequently the most useful of the set.
• Complete data silence: no mentions collected for an unusual period, which usually means the collection broke rather than that the world stopped talking.

The last one is routinely omitted and catches a real failure mode. A monitoring system that has quietly stopped collecting looks identical to a quiet week.

Conditions that should not alert

These are the defaults most tools enable and the main source of fatigue.

• Any single negative mention. Individual complaints belong in the queue, handled within the normal response time.
• Sentiment crossing a threshold. Automated sentiment is too unreliable on individual items to justify interrupting someone, for the reasons covered separately.
• Volume above a fixed number. Fixed thresholds are wrong for every brand except the one they were set for, and they become wrong for that one as it grows.
• Competitor mentions. Almost never require an immediate response, and they generate constant noise.
• Any mention at all, which is the tool's default and the fastest route to a muted channel.
• Scheduled summaries labelled as alerts. A daily digest is useful and it is not an alert; mixing them trains people to ignore both.
• Keyword matches without context, which fire on unrelated usage of common words — a query precision problem surfacing as an alerting one.

Severity tiers and what each means

Not every alert needs the same response. Three tiers is usually enough and more than three is rarely maintained.

1. 1

   Tier one — notify, no interruption

   Appears in a channel the owner checks periodically. Named-account mentions, moderate velocity changes, coordinated patterns. Reviewed within the working day.

2. 2

   Tier two — interrupt the owner

   A direct notification to a named person, during working hours or via the rota outside them. Legal language, sharp velocity acceleration, high-risk keyword combinations. Acknowledged within a defined period.

3. 3

   Tier three — convene

   Safety matters, rapidly spreading allegations, anything the organisation would need to make a statement about. Notifies a predefined group through a channel that reaches people out of hours.

4. 4

   Define the acknowledgement expectation per tier

   An alert nobody has to confirm receiving is an alert that can be missed silently. Tiers two and three should require acknowledgement.

5. 5

   Define the escalation if unacknowledged

   Who gets notified next, and after how long. This is what makes the rota real rather than nominal.

The acknowledgement and escalation rules are what separate an alerting system from a notification feed. Without them, tier three depends on somebody happening to look.

Preventing fatigue

Alert fatigue is the normal end state of an unmanaged alerting system. These practices prevent it.

• Start with three conditions and add only when a real miss demonstrates a gap. Starting broad and narrowing does not happen in practice.
• Set thresholds from your own baseline and revisit them as the baseline changes. A threshold set at launch is wrong within two quarters of growth.
• Suppress duplicates. Fifty alerts about one event is one alert.
• Group related alerts into a single notification with a count.
• Add a cooldown per condition, so a continuing situation does not re-notify every few minutes.
• Include enough context in the alert to triage without opening a tool — what fired, the volume, an example, and a link.
• Review every firing monthly: was it useful? Conditions that produce no action for three consecutive months should be removed or retuned.
• Track the false-positive rate per condition and treat a high rate as a defect rather than as background noise.

What the alert should contain

The design of the message determines whether it can be acted on or merely noticed.

• Which condition fired, named clearly rather than as a rule identifier.
• The severity tier, so the recipient knows what is expected of them.
• Current volume and the comparison to baseline, not a raw number alone.
• One or two representative examples, verbatim. This is what allows a five-second judgement.
• A direct link to the full set, so investigation starts immediately rather than with a search.
• The time it started, since the age of a situation changes the response.
• Who else has been notified, to prevent duplicated effort and to make ownership obvious.
• What the recipient is expected to do, particularly for conditions that fire rarely and whose procedure will not be remembered.

The last point matters for tier three specifically. Conditions that fire twice a year are exactly the ones whose procedure nobody remembers, and the alert itself is the right place to carry it.

Data and configuration requirements

What the alerting layer needs to be reliable.

• Baselines per query, so velocity conditions mean something.
• Historical data for backtesting conditions before enabling them.
• Deduplication and grouping.
• Per-condition cooldowns and thresholds as configuration, not code — they will be tuned repeatedly.
• Delivery to a channel people genuinely monitor, which varies by organisation and is worth asking rather than assuming.
• An out-of-hours rota with named people and a tested escalation path.
• Acknowledgement tracking for the higher tiers.
• A log of every firing with what happened afterwards, which is the input to the monthly review.
• Monitoring of the monitoring: an alert when collection stops.
• Consolidation across channels, so one situation appearing on three platforms produces one alert rather than three — which a single monitoring platform handles and separate tools do not.

The firing log is the item most often missing and the one that makes tuning possible. Our automation services page covers building this layer around existing collection.

Testing the alerting itself

Alerting is a safety system and untested safety systems have a poor record.

• Backtest every condition against historical data before enabling it.
• Fire a test alert through each tier, including out of hours, and confirm someone receives and acknowledges it.
• Test the escalation path by not acknowledging deliberately.
• Verify the collection-failure alert by disabling a source in a controlled window.
• Re-test after any change to channels, rota or platform.
• Run the test quarterly. Delivery paths break silently when people change roles or tools change configuration.
• Review whether tier three would reach the right people at a weekend, which is when it will be needed.

The quarterly test is the difference between an alerting system and a configuration file. Most failures found by testing are delivery failures rather than condition failures.

What alerting cannot do

Worth stating to whoever expects alerting to prevent incidents.

• It cannot catch what is not collected, and coverage is never complete.
• It cannot tell you whether something is true, only that it is being said.
• It cannot judge whether a situation matters, which is why triage remains a human step.
• It cannot prevent anything; it shortens the time to noticing.
• It cannot compensate for a missing response process. An alert reaching someone with no defined action produces anxiety rather than resolution.
• It cannot distinguish a genuine spike from a query change, which is why ruling out your own systems is the first triage step.

Alerting buys time. What is done with that time depends on the wider operating model, which is a separate piece of work.

Decision framework and next step

Four questions before configuring.

1. 1

   Which conditions would have needed action in the last year?

   Look at real past incidents rather than imagining categories. This produces a much shorter and more accurate list.

2. 2

   Who receives each tier, and are they genuinely available?

   Named people and a rota, not a distribution list.

3. 3

   Have you backtested against historical data?

   Conditions that fire constantly are identified in minutes this way.

4. 4

   Who prunes conditions, and when?

   Without a named owner and a cadence, the condition list only grows and fatigue follows.

Start with three conditions — safety language, legal language, and a velocity threshold from your own baseline — plus a collection-failure alert. Add conditions only when a genuine miss demonstrates a gap, review firings monthly, and test delivery quarterly. Our AI solutions overview covers how this sits alongside the rest of a monitoring capability.

Frequently asked questions

1. 1

   Which mentions deserve a real-time alert?

   A short list: safety-related content, legal or regulatory language, mentions from a maintained list of named accounts, velocity accelerating past your own baseline, coordinated patterns, specific high-risk keyword combinations, response-time breaches, and a failure of collection itself.

2. 2

   What should never trigger an alert?

   Individual negative mentions, sentiment crossing a threshold, volume above a fixed number, competitor mentions, and keyword matches without context. Alerting on every negative mention is the most damaging default and the most commonly enabled.

3. 3

   How many alert conditions should there be?

   Fewer than eight for most organisations. Start with three, add only when a real miss demonstrates a gap, and remove any condition that has produced no action in a quarter.

4. 4

   How is alert fatigue prevented?

   Backtesting conditions before enabling them, thresholds derived from your own baseline and revisited as it changes, duplicate suppression, grouping, per-condition cooldowns, enough context to triage in seconds, and a monthly review that deletes unproductive conditions.

5. 5

   How should alerting be tested?

   Backtest each condition against history, fire a test through every tier including out of hours, test the escalation path by deliberately not acknowledging, verify the collection-failure alert, and repeat quarterly — most failures found are delivery failures rather than condition failures.

Good alerting is defined by what it does not send. A channel that fires three times a quarter and is read every time is worth more than one that fires daily and is muted.