You're flying blind between CRM updates.

Most revenue teams conflate "alerts" with "signal infrastructure." An alert is a notification. A signal is a governed unit of information that has an owner, an action, and a resolution. The distinction matters because alerts produce noise; signals produce outcomes.

Four diagnostic questions separate a working signal infrastructure from an alert sprawl:

1. Can every alert be traced to a named owner within 60 seconds? If not, it's a shared-channel notification. Nobody owns it.
2. Does every alert have a defined action menu? If the receiving rep has to improvise what to do next, the alert isn't wired to a playbook.
3. Is there a defined resolution state that closes the loop? If "I saw it" counts as resolution, you're measuring acknowledgment, not intervention.
4. Does the outcome feed back into the detection logic? Without a feedback loop, your thresholds drift from reality and false-positive rates creep up until the team starts ignoring the channel.

Signal infrastructure is the discipline of answering yes to all four, at scale, across every signal family, with governance and audit. That works at 50 accounts. At 500 accounts, it is the only thing that works.

Signals are engineered, not discovered. A signal that violates any of these five principles will decay into noise within a quarter. The team will start ignoring the channel, and the infrastructure you built becomes a wiki entry nobody reads.

Good signal infrastructure is layered. Atomic signals detect events. Compound signals combine atomic signals with thresholds. Derived signals inject context from outside the composite. Each layer uses the one below it.

A common mistake: building Layer 2 signals without a clean Layer 1. The atomic events exist across five systems, none of them speak to each other, and every compound signal requires its own one-off integration. The architectural fix is a unified event stream, one place where atomic signals are captured, before compound signals are defined.

Every compound signal belongs to a family. The taxonomy gives you a shared vocabulary across teams and a routing rubric: who owns each family by default, what cadence slot it lands in, and what play library it pulls from.

Every signal is tagged with a severity level. The severity level drives the SLA, the routing, the escalation path, and which cadence slot the signal lands in. Teams that don't separate severity end up with either alert fatigue (everything is "urgent") or slow response (nothing is "urgent").

Two governance rules that prevent severity drift: the definition of critical is capped (no more than ~5% of active signals should carry critical, otherwise the level loses meaning), and severity is auditable (if too many warnings get downgraded or ignored, retune the threshold, don't let the field become aspirational).

Every signal infrastructure has a false-positive rate. The rate is not the problem. Not tracking and tuning it is. Untuned signals decay into noise, and the team quietly stops trusting the channel. Here's the loop that keeps signals credible:

1. Capture resolution outcomes. When a rep acts on a signal, the outcome field is mandatory: “confirmed risk,” “confirmed opportunity,” “false alarm,” “already handled,” “not applicable.”
2. Compute false-positive rate per signal family monthly. Flag any signal with >25% false-positive rate for review.
3. Diagnose the source of false positives. Usually one of three: threshold is too loose, scope modifier is missing (signal firing outside the segment it should apply to), or a Layer 1 atomic signal is unreliable.
4. Tune, don't delete. Raise the threshold, add a scope modifier, or deprecate the upstream atomic. Document the change and the reason in the signal-definition audit log.
5. Re-measure the following month. If the false-positive rate didn't move, the diagnosis was wrong. Iterate.

This is the part of signal infrastructure that most orgs skip, and it is why a signal system that was great in year one is noise by year three. Without a tuning loop, your thresholds drift from reality. With one, your signals get sharper every quarter.

If you run two products on shared infrastructure, do not duplicate your signal library. Share the definitions; scope the thresholds. A single-store-two-scopes architecture keeps the taxonomy coherent across motions and makes the flywheel work for both products.

1. One definition library. "Low adoption," "champion departed," "renewal risk" are defined once. Families and compound signal shapes are shared across motions.
2. Per-motion threshold overrides. The numbers that trigger the signal (days of inactivity, usage delta, renewal window length) are overridden per motion. Shared definition, different firing rules.
3. Cross-sell as its own signal family. Motion-A customer qualified for Motion B is a distinct signal family with its own routing (Motion B AE) and its own play library. Not a generic expansion signal.
4. Shared flywheel, scoped tuning. Resolution outcomes feed back into threshold-tuning per motion. The same signal can be well-tuned for Motion A and drifting on Motion B simultaneously. Tune each independently; share the infrastructure.

Twelve yes/no questions to pressure-test the signal layer. Count the no's by category. That's your rebuild punch list.

Build bottom-up (atomics first, then compound, then derived) and commit to a tuning loop from day one. Don't try to ship all eight families at once. Start with the three that matter most for the next quarter.

Two anti-patterns to avoid: building compound signals before the event stream is stable (every signal has its own integration debt and breaks constantly), and skipping the outcome loop (without it, quarter-three will be full of signals nobody acts on and nobody trusts).