How to Build Signal-Based Systems: A Practical GTM Engineering Guide

Most go-to-market teams have access to more data than ever.

They know which companies are hiring, which accounts raised funding, which prospects visited their website, which technologies companies adopted, which executives changed jobs, and which customers are becoming more engaged with their product.

Yet having data does not automatically create a signal-based GTM system.

A signal becomes useful only when the system can recognize an important change, understand what that change means, determine whether the account matters, and trigger the right action at the right time.

That is the difference between collecting signals and building a signal-based system.

A modern signal-based system can be represented as:

DATA SOURCES
     ↓
SIGNAL DETECTION
     ↓
SIGNAL NORMALIZATION
     ↓
ENRICHMENT
     ↓
SIGNAL VALIDATION
     ↓
SCORING
     ↓
DECISION ENGINE
     ↓
ROUTING
     ↓
ACTION
     ↓
MEASUREMENT
     ↓
LEARNING

The objective is not to create more alerts.

The objective is to create a system that consistently identifies when something changed and what your GTM team should do because of that change.

This guide explains how to design that system from the ground up.

What is a signal-based system?

A signal-based system is an automated or semi-automated system that detects meaningful changes in accounts, contacts, markets, products, or customer behavior and converts those changes into predefined actions.

In a GTM environment, the system connects:

• data
• signals
• context
• intent
• account fit
• decision rules
• workflows
• human actions
• automation

Instead of asking:

Who should our sales team contact?

The system asks:

Which accounts have changed in a way that creates a reason to act now?

That distinction is important.

Traditional prospecting usually starts with a static list:

ICP List
   ↓
Find Contacts
   ↓
Write Sequence
   ↓
Send Outreach
   ↓
Wait for Response

A signal-based system reverses the process:

Market / Buyer Activity
        ↓
Signal Detected
        ↓
Is It Relevant?
        ↓
Does Account Fit ICP?
        ↓
How Strong Is The Signal?
        ↓
What Action Should Happen?
        ↓
Sales / Marketing / CS / AI Agent

The system therefore becomes event-driven rather than list-driven.

Why signal-based systems matter?

The fundamental problem with static targeting is that fit does not equal timing.

An account can perfectly match your ICP and still have no reason to buy today.

For example, imagine a company that matches your:

• industry
• employee range
• geography
• technology stack
• revenue range
• buyer persona

It may be an excellent potential customer.

But if nothing has changed, outreach may still be premature.

Now imagine the same company:

• receives new funding
• hires a new VP of Sales
• doubles its sales team
• adopts a new CRM
• posts about pipeline problems
• visits your pricing page
• starts a product trial

The account has not suddenly become a better ICP.

Its timing has changed.

That is where signals become valuable.

Clay describes signals as observable events that can indicate changes in buying likelihood, while modern GTM systems increasingly combine multiple signals rather than relying on a single event.

The practical model is:

ICP FIT
   +
BUYING SIGNAL
   +
RECENCY
   +
CONTEXT
   =
ACTIONABLE OPPORTUNITY

A signal-based system operationalizes that equation.

Signal-based system vs signal-based selling

These concepts are related but not identical.

Signal-based selling

Signal-based selling is a sales methodology.

It tells salespeople to prioritize accounts based on observable changes rather than contacting every account according to a static cadence.

Signal-based system

A signal-based system is the technical infrastructure that makes that methodology operational.

It determines:

• where signals come from
• how signals are detected
• how signals are interpreted
• how signals are scored
• where signals are stored
• who receives them
• what action is triggered
• how outcomes are measured

Think of it this way:

The system is therefore the infrastructure behind the motion.

The core architecture of a signal-based system

A mature signal-based architecture normally contains eight layers.

┌──────────────────────────────┐
│ 1. DATA SOURCES              │
│ CRM, website, product, news  │
└──────────────┬───────────────┘
               ↓
┌──────────────────────────────┐
│ 2. SIGNAL DETECTION          │
│ Events and behavioral change │
└──────────────┬───────────────┘
               ↓
┌──────────────────────────────┐
│ 3. CONTEXT + ENRICHMENT      │
│ Account, people, technology  │
└──────────────┬───────────────┘
               ↓
┌──────────────────────────────┐
│ 4. SIGNAL VALIDATION         │
│ Relevance, confidence, noise │
└──────────────┬───────────────┘
               ↓
┌──────────────────────────────┐
│ 5. SCORING                   │
│ Fit + signal + recency       │
└──────────────┬───────────────┘
               ↓
┌──────────────────────────────┐
│ 6. DECISION ENGINE           │
│ Determine next action        │
└──────────────┬───────────────┘
               ↓
┌──────────────────────────────┐
│ 7. ACTIVATION + ROUTING      │
│ CRM, Slack, email, ads, AI   │
└──────────────┬───────────────┘
               ↓
┌──────────────────────────────┐
│ 8. FEEDBACK LOOP             │
│ Outcomes → better signals    │
└──────────────────────────────┘

This architecture is more important than the specific software used.

You can build the system with different combinations of:

• CRM
• data warehouse
• enrichment platform
• workflow automation
• webhooks
• APIs
• product analytics
• intent data
• AI agents
• messaging platforms
• sales engagement tools

The tools can change.

The architecture remains.

Step 1: Define what the system is supposed to detect

Do not begin by buying a signal database.

Begin with the business problem.

Ask:

What change would make us want to take action?

This question forces the system to start with an outcome rather than a data source.

For example:

Sales

Which ICP accounts have entered a buying window?

Marketing

Which accounts are showing increasing category interest?

Customer success

Which customers are showing expansion or churn signals?

Recruiting

Which companies are likely to hire for a specific capability?

Partnerships

Which companies have recently entered a market where a partnership makes sense?

Product-led growth

Which free users are exhibiting behavior associated with expansion?

Each use case produces a different signal architecture.

Step 2: Define the signal

A useful signal has four components:

EVENT
+
ENTITY
+
TIME
+
MEANING

For example:

Event: Company hires VP of Sales
Entity: Target account
Time: Within the last 14 days
Meaning: New sales leadership may indicate changes to GTM strategy, systems, or pipeline requirements.

Another example:

Event: Prospect visits pricing page three times
Entity: Target account
Time: Within seven days
Meaning: Increased product evaluation activity.

The important point is that the raw event is not the complete signal.

The system needs to understand the event in context.

What are the different types of signals?

There is no universal signal taxonomy, but a useful GTM architecture can group signals into several categories.

1. Intent signals

Intent signals indicate that an account or buyer may be researching a problem, category, or solution.

Examples include:

• website visits
• pricing-page activity
• product-page engagement
• content consumption
• search behavior
• category research
• demo requests
• product trials

Intent signals are useful, but they should not automatically be treated as purchase intent.

Research is not the same as readiness.

2. Growth signals

Growth signals indicate that the company is expanding or entering a new phase.

Examples:

• funding
• rapid hiring
• geographic expansion
• new offices
• new product launches
• acquisitions
• increased headcount
• new business units

Growth often creates new operational requirements.

For example:

Funding
   ↓
Hiring
   ↓
Operational Complexity
   ↓
New GTM Requirements
   ↓
Potential Buying Window

3. Change signals

Change signals indicate that something important inside the account has changed.

Examples:

• new executive
• champion changes jobs
• leadership transition
• CRM migration
• technology adoption
• technology replacement
• organizational restructuring
• new department

These signals can be particularly powerful because change often creates a need to reassess existing systems.

4. Pain or distress signals

These signals indicate potential problems.

Examples:

• negative customer reviews
• layoffs
• declining performance
• complaints about existing vendors
• public discussions about operational problems
• regulatory pressure
• security incidents
• technology failures

Pain signals can create urgency, but they require careful interpretation.

A negative event does not automatically mean a company is ready to buy.

5. Hiring signals

Hiring behavior can reveal strategic priorities.

Examples:

• hiring SDRs
• hiring RevOps
• hiring sales leadership
• hiring data engineers
• hiring GTM engineers
• opening international sales roles
• building a new marketing team

The key is to interpret the role, not simply count job postings.

A company hiring 20 sales representatives may indicate a very different opportunity from a company hiring one operations analyst.

6. Technology signals

Technology changes can reveal infrastructure changes or strategic shifts.

Examples:

• adopting Salesforce
• migrating CRM
• implementing HubSpot
• adopting Snowflake
• replacing marketing automation
• adding a data warehouse
• adopting AI tools
• changing analytics platforms

Technology signals become especially powerful when your product integrates with or replaces the technology being adopted.

7. First-party signals

First-party signals originate from your own systems.

Examples:

• product usage
• trial activity
• CRM activity
• email engagement
• support conversations
• webinar attendance
• event attendance
• sales calls
• customer requests
• pricing-page visits

First-party signals can become a major competitive advantage because competitors generally cannot access your proprietary buyer history.

Clay has recently emphasized this distinction between externally available signals and signals generated through a company's own buyer interactions.

8. Third-party signals

Third-party signals originate outside your organization.

Examples:

• funding announcements
• hiring data
• technology changes
• news
• public posts
• company announcements
• industry activity

These signals are easier to operationalize because external providers can collect them at scale.

However, popular signals can become commoditized.

If every competitor receives the same funding alert, the signal itself is not a durable advantage.

Step 3: Separate signals from noise

One of the biggest mistakes in signal-based systems is assuming:

More signals = better targeting.

Usually, the opposite happens.

If your system generates 500 alerts per day, your sales team does not have a signal system.

It has an alert system.

The objective is to maximize:

Actionable Signal Density

rather than total signal volume.

A simple conceptual metric is:

Actionable Signal Density
=
Actionable Signals
÷
Total Signals Detected

A good system should continuously improve this ratio.

Step 4: Start with your best customers

The strongest signal systems are often built backward from customer outcomes.

Instead of asking:

What signals can our tools detect?

Ask:

What happened before our best customers bought?

Analyze:

• closed-won opportunities
• sales cycles
• customer interviews
• CRM notes
• call transcripts
• product adoption
• expansion events
• churn events
• lost opportunities

Then look for recurring changes.

For example:

Closed-won customers

Customer A → New VP Sales → Hiring SDRs → Bought
Customer B → Funding → New VP Sales → Bought
Customer C → CRM Migration → Hiring RevOps → Bought
Customer D → Funding → Expansion → Bought

You might discover that the strongest pattern is not funding alone.

It could be:

Funding
+
Sales Leadership Change
+
Hiring

That combination is much more informative.

Clay's current guidance similarly recommends identifying recurring observable events in closed-won deals before deciding which signals to monitor.

Step 5: Build a signal registry

Once you identify potential signals, create a central signal registry.

A signal registry is simply the system's definition of every signal you monitor.

This registry becomes the foundation of the system.

Without it, signals tend to become scattered across tools and workflows.

Step 6: Give every signal a defined action

This is one of the most important principles in signal engineering:

Never build a signal without defining what happens when it fires.

A signal without an action is just information.

For every signal, define:

IF
signal occurs

AND
account meets conditions

THEN
perform action

WITHIN
defined time window


For example:

IF
ICP account hires VP of Sales

AND
company has >100 employees

THEN
create sales research task

AND
identify VP Sales

AND
generate account brief

AND
notify account owner


Another example:

IF
existing customer increases product usage

AND
usage exceeds expansion threshold

THEN
calculate expansion score

AND
notify CSM

AND
create expansion opportunity

The signal therefore becomes a trigger inside a larger decision system.

Step 7: Add context through enrichment

Raw signals are rarely sufficient.

Suppose your system detects:

Company hired a new VP Sales.

That tells you something changed.

It does not tell you:

• company size
• revenue
• current sales team size
• CRM
• existing technology
• previous executive
• new executive's background
• existing relationship
• current opportunity
• current customer status

Enrichment adds this context.

A basic enrichment layer can include:

SIGNAL
  ↓
Company Data
  ↓
Contact Data
  ↓
Technographic Data
  ↓
Firmographic Data
  ↓
Relationship Data
  ↓
Historical CRM Data

Now the system can evaluate the signal properly.

Step 8: Connect signals to ICP fit

A signal should not be evaluated in isolation.

A strong signal on a poor-fit account may be less valuable than a moderate signal on an ideal account.

This is why signal-based systems should combine:

Fit + Signal + Recency + Context

For example:

This prevents your team from chasing interesting events that happen at companies that were never good customers.

Step 9: Score signal strength

Not all signals deserve equal treatment.

A simple scoring framework might be:

Signal Score
=
Signal Strength
×
Recency
×
ICP Fit
×
Confidence

You can also use a weighted model:

Total Score =
ICP Fit × 0.35
+
Signal Strength × 0.30
+
Recency × 0.20
+
Relationship × 0.10
+
Data Confidence × 0.05

The exact weights should come from your business rather than a universal formula.

The purpose of scoring is prioritization.

For example:

Low score

ICP fit: High
Signal: Weak
Recency: Low

→ Monitor

Medium score

ICP fit: High
Signal: Moderate
Recency: High

→ Research

High score

ICP fit: High
Signal: Strong
Recency: High

→ Act now

This transforms a stream of events into a prioritized queue.

Step 10: Use signal stacking

One signal can be ambiguous.

Multiple independent signals can provide stronger evidence.

For example:

Funding
   +
Hiring
   +
New VP Sales
   +
Pricing Page Visit
   ↓
High-Confidence Opportunity

Signal stacking does not mean blindly adding points.

The signals should tell a coherent story.

Consider:

New VP Sales
+
Hiring 15 SDRs
+
CRM migration

Together, these signals suggest a GTM transformation.

Compare that with:

Funding announcement

The second signal may be useful, but the first combination provides substantially more context.

Modern signal platforms increasingly support combining first-party, third-party, intent, and custom signals to distinguish real momentum from isolated events.

The signal stack

A mature system can be visualized as a layered stack.

┌──────────────────┐
                 │ BUSINESS OUTCOME │
                 └────────┬─────────┘
                          ↓
                 ┌──────────────────┐
                 │     ACTION       │
                 └────────┬─────────┘
                          ↓
                 ┌──────────────────┐
                 │ DECISION ENGINE  │
                 └────────┬─────────┘
                          ↓
                 ┌──────────────────┐
                 │ SIGNAL SCORING   │
                 └────────┬─────────┘
                          ↓
                 ┌──────────────────┐
                 │    CONTEXT       │
                 └────────┬─────────┘
                          ↓
                 ┌──────────────────┐
                 │ SIGNAL DETECTION │
                 └────────┬─────────┘
                          ↓
                 ┌──────────────────┐
                 │   DATA SOURCES   │
                 └──────────────────┘

This architecture creates an important design principle:

The bottom layers discover what happened.
The upper layers determine what to do about it.

Example: Building a signal-based outbound system

Imagine a B2B SaaS company selling RevOps software.

Its ICP is:

• B2B SaaS
• 100 to 2,000 employees
• growing sales organization
• Salesforce or HubSpot
• dedicated RevOps function
• complex GTM motion

The company wants to identify accounts entering a buying window.

Signals

It decides to monitor:

1. New VP Sales
2. New CRO
3. RevOps hiring
4. Rapid SDR hiring
5. Funding
6. CRM migration
7. Pricing-page visits
8. Product-category research
9. Competitor complaints
10. Existing relationship changes

The system then operates like this:

External + Internal Data
          ↓
     Signal Detection
          ↓
      ICP Matching
          ↓
       Enrichment
          ↓
     Signal Stacking
          ↓
      Score Account
          ↓
 ┌────────┼─────────┐
 ↓        ↓         ↓
High    Medium      Low
 ↓        ↓         ↓
Sales   Research  Monitor

A high-priority account might trigger:

CRM Update
   +
Slack Alert
   +
Account Research
   +
Contact Identification
   +
Personalized Message
   +
Sales Task

The system has now converted an external event into a GTM action.

Signal-based systems are event-driven systems

A useful way to understand signal engineering is through software architecture.

Traditional GTM automation often looks like:

Schedule
   ↓
Run Workflow
   ↓
Process Records


Signal-based automation looks like:

EVENT
  ↓
DETECT
  ↓
EVALUATE
  ↓
TRIGGER
  ↓
ACT

This is fundamentally event-driven.

The system does not ask:

What should I process today?

It asks:

Did something happen that requires action?

That change has major implications for GTM Engineering.

The GTM Engineer is no longer simply automating repetitive tasks.

They are designing event-driven revenue infrastructure.

The difference between a signal and a trigger

These terms should not be treated as synonyms.

A signal is evidence that something meaningful may have changed.

A trigger is the condition that causes the system to execute an action.

For example:

Signal:
Company hired 10 SDRs.

Trigger:
ICP fit > 80
AND
SDR hiring > 5
AND
event occurred within 14 days.

Action:
Create outbound play.

The signal is the observation.

The trigger is the decision condition.

The action is the response.

This distinction becomes extremely important as systems become more complex.

The signal lifecycle

Every signal should have a lifecycle.

Detected
   ↓
Captured
   ↓
Enriched
   ↓
Validated
   ↓
Scored
   ↓
Activated
   ↓
Acted Upon
   ↓
Outcome Recorded
   ↓
Model Improved

This creates the foundation for a feedback loop.

For example:

Signal:
New VP Sales

       ↓

Action:
Outbound outreach

       ↓

Outcome:
No response

       ↓

Learning:
Signal alone has weak predictive power

       ↓

System Update:
Require VP Sales + hiring signal

Over time, the system becomes smarter because it learns which signals actually correlate with revenue outcomes.

The most important principle: build backward from action

A common mistake is:

Find Data
   ↓
Collect Signals
   ↓
Build Dashboard
   ↓
Ask Sales What To Do


A stronger architecture is:

Desired Outcome
   ↓
Required Action
   ↓
Decision Rule
   ↓
Required Signal
   ↓
Data Source

For example:

Desired outcome

Increase qualified outbound opportunities.

Required action

Contact high-fit accounts during relevant buying windows.

Decision rule

ICP fit above threshold + strong recent signal.

Required signals

New executive, hiring acceleration, technology change, product intent.

Data sources

CRM + enrichment + intent + web + job data.

This approach prevents the organization from collecting signals simply because they are available.

Signal-based systems need a feedback loop

The first version of a signal system will not be perfect.

Some signals will produce:

• false positives
• false negatives
• duplicate events
• stale events
• weak opportunities
• irrelevant accounts

That is normal.

The goal is to create a system that improves.

Measure:

• signal volume
• qualified signal volume
• response rate
• meeting rate
• opportunity rate
• pipeline generated
• revenue generated
• time from signal to action
• false-positive rate
• conversion by signal type
• conversion by signal combination

Then identify:

Which signals actually predict the outcome we care about?

That becomes the basis for the next iteration.

What a mature signal-based system looks like?

At maturity, the system should not simply say:

Company X raised funding.

It should say:

Company X matches 91% of the ICP, raised funding 8 days ago, hired a new VP Sales 12 days ago, increased its SDR hiring activity by 40%, and currently uses a technology stack compatible with our solution. Recommended action: prioritize executive-level outbound within 48 hours.

That is the difference between data delivery and decision intelligence.

The goal of signal engineering is not to give humans more information.

It is to give them better decisions with less manual research.

How to build signal-based systems: From detection to automated GTM action?

A signal-based system becomes valuable when it moves beyond detection.

Finding that an account hired a VP of Sales is easy. The difficult part is determining whether that event matters, enriching it with context, deciding how urgent it is, routing it to the right person, and triggering the appropriate play.

The operational architecture therefore looks like this:

SIGNAL DETECTED
      ↓
CAPTURE EVENT
      ↓
NORMALIZE DATA
      ↓
ENRICH ACCOUNT
      ↓
VALIDATE SIGNAL
      ↓
CALCULATE FIT
      ↓
CALCULATE SIGNAL SCORE
      ↓
STACK RELATED SIGNALS
      ↓
DECIDE ACTION
      ↓
ROUTE
      ↓
EXECUTE
      ↓
MEASURE

This is where a signal-based system becomes a GTM operating system rather than a collection of alerts.

How to build a signal pipeline?

A signal pipeline is the infrastructure that moves an event from its original source into an actionable workflow.

A basic pipeline has five stages:

SOURCE
  ↓
DETECTION
  ↓
PROCESSING
  ↓
DECISION
  ↓
ACTIVATION


For example:

Job Board
   ↓
New RevOps Job
   ↓
Identify Company
   ↓
Enrich Company
   ↓
Check ICP
   ↓
Check Existing CRM Relationship
   ↓
Calculate Signal Score
   ↓
Assign Rep
   ↓
Generate Research Brief
   ↓
Notify Rep

The pipeline should be designed as a chain of transformations.

Each stage should have a clear input and output.

Step 1: Choose your signal sources

A signal-based system can combine many sources.

First-party sources

These are signals generated by your own business.

Examples:

• website visits
• product usage
• trial activity
• demo requests
• email engagement
• content downloads
• webinar attendance
• support conversations
• sales conversations
• CRM activity
• contract milestones

First-party signals are often particularly valuable because they are directly connected to your relationship with the account.

Third-party sources

Third-party sources provide information about what is happening outside your systems.

Examples:

• company news
• funding announcements
• hiring activity
• executive changes
• technology adoption
• job postings
• public websites
• social activity
• intent data
• industry databases

The best systems frequently combine first-party and third-party information.

For example:

Third-party:
Company hiring RevOps
        +
First-party:
Company visited pricing page
        ↓
High-confidence buying opportunity

This combination is more informative than either event by itself.

Clay's current signal architecture explicitly supports combining first-party, third-party, intent, and custom signals into GTM workflows.

Step 2: Decide between real-time and scheduled signals

Not every signal needs real-time processing.

This is an important architectural decision.

Real-time signals

Use real-time processing when timing has a major impact on the outcome.

Examples:

• inbound demo request
• pricing-page activity
• product-qualified lead
• high-intent website activity
• customer expansion event
• contract milestone

Architecture:

EVENT
 ↓
WEBHOOK
 ↓
PROCESS
 ↓
SCORE
 ↓
ROUTE
 ↓
ACTION

Scheduled signals

Scheduled processing is more appropriate when the event changes slowly.

Examples:

• funding
• hiring
• technology changes
• company headcount
• market expansion
• account research
• TAM refresh

Architecture:

SCHEDULE
 ↓
FETCH CHANGES
 ↓
COMPARE STATE
 ↓
IDENTIFY NEW SIGNALS
 ↓
SCORE
 ↓
ACT

The goal is not to make every workflow real-time.

The goal is to make the right workflows timely.

Step 3: Create a canonical account identity

Signal systems frequently encounter the same company from multiple sources.

One source might call it:

OpenAI


Another:

OpenAI Inc.


Another:

openai.com


Another:

OpenAI, Inc.

If the system cannot resolve these records to the same entity, signal stacking becomes unreliable.

You therefore need a canonical identity.

At minimum, maintain:

• company ID
• domain
• CRM account ID
• company name
• parent company
• subsidiaries
• country
• account owner

The system should ideally resolve:

Signal
   ↓
Canonical Company
   ↓
CRM Account
   ↓
People
   ↓
Opportunity

This prevents duplicate alerts and fragmented account histories.

Step 4: Normalize signals

Different sources describe similar events differently.

For example:

"VP of Sales hired"

"New Sales VP"

"Company appoints VP Sales"

"Joined as VP, Sales"


To the system, these should become a common event type:

EXECUTIVE_CHANGE

You can create a standardized signal schema.

For example:

Signal ID
Signal Type
Account ID
Person ID
Source
Event Date
Detected Date
Confidence
Signal Strength
Evidence
Expiration
Status

Now every signal follows the same structure.

This makes downstream scoring and reporting much easier.

Step 5: Store evidence with the signal

A signal should not simply say:

Company hired a VP Sales.

It should preserve the evidence that caused the system to believe this.

For example:

Signal:
New VP Sales

Account:
Example SaaS

Detected:
September 2

Source:
Public company announcement

Person:
Jane Smith

Confidence:
0.94

Evidence:
Executive announcement confirms Jane Smith joined as VP Sales.

Status:
Unreviewed

Evidence matters because sales teams need to trust the system.

It also creates an audit trail for debugging.

If a signal produces a bad recommendation, you should be able to answer:

Why did the system make this decision?

Step 6: Add signal confidence

Not every detected event is equally reliable.

A signal might be:

• directly verified
• inferred
• AI-generated
• partially verified
• stale
• ambiguous

A simple confidence model could look like:

This is particularly important when AI is used to interpret unstructured signals.

The system should distinguish:

What the source actually says

from

What the AI thinks it means.

Step 7: Add signal recency

A signal loses value over time.

A funding announcement from yesterday may be extremely useful.

The same announcement from eighteen months ago may be almost irrelevant.

This can be modeled as signal decay.

Conceptually:

Signal Value
100 |████████████████
 80 |██████████████
 60 |██████████
 40 |██████
 20 |███
  0 |________________
       Time →

A simple decay model is:

Current Signal Value
=
Initial Signal Value
×
Recency Factor

You do not need a mathematically sophisticated model at first.

You simply need rules such as:

0-7 days     → Full strength
8-30 days    → Reduced strength
31-90 days   → Low strength
90+ days     → Usually expired

The correct window depends on the signal.

A pricing-page visit may decay within days.

A funding event may remain relevant for months.

A technology migration may remain relevant for much longer.

Step 8: Create signal expiration rules

Signals should not remain active forever.

Every signal should have an expiration condition.

For example:

NEW_EXECUTIVE
Expires after 45 days

PRICING_VISIT
Expires after 7 days

FUNDING
Expires after 180 days

JOB_POSTING
Expires when position is filled or removed

This prevents stale events from continuously inflating account scores.

Step 9: Separate fit from intent

One of the most important design principles is to avoid combining everything into one opaque score.

Keep at least two dimensions:

ACCOUNT FIT
+
BUYING SIGNAL

For example:

This allows the GTM team to understand why an account is prioritized.

Modern scoring guidance similarly recommends separating fit from intent before combining them into a final prioritization model.

Step 10: Build a signal scoring model

A basic model might be:

Priority Score
=
ICP Fit
×
Signal Strength
×
Recency
×
Confidence


For example:

ICP Fit       = 0.90
Signal        = 0.85
Recency       = 0.95
Confidence    = 0.90

Priority
= 0.90 × 0.85 × 0.95 × 0.90
= 0.654

The exact mathematics is less important than consistency.

You can also use weighted scoring:

Priority Score =
Fit × 40%
+
Intent × 30%
+
Recency × 15%
+
Relationship × 10%
+
Confidence × 5%

As the system collects outcome data, these weights should be tested and adjusted.

Step 11: Stack signals

The real power of a signal system comes from combinations.

Suppose:

New VP Sales


has moderate predictive value.

Now add:

New VP Sales
+
20 SDR Job Openings
+
CRM Migration

The combined pattern may be much stronger.

This is called signal stacking.

A useful architecture is:

Signal A ─┐
Signal B ─┼──→ Account Signal Graph ──→ Score
Signal C ─┤
Signal D ─┘

The system should therefore store signals at the account level rather than treating every event as an isolated notification.

Clay's current buying-signal guidance recommends stacking signals to distinguish genuine momentum from isolated events.

Step 12: Build the decision engine

The decision engine answers:

Given everything we know, what should happen next?

A simple decision tree could be:

Signal Detected
      ↓
Is Account ICP?
   /       \
 No         Yes
 ↓           ↓
Ignore     Is Signal Strong?
             /       \
           No         Yes
           ↓           ↓
        Monitor    Is Existing
                   Opportunity?
                    /       \
                  Yes        No
                  ↓           ↓
             Alert Owner   Start Play

A mature system can contain hundreds of such rules.

But the rules should remain understandable.

Avoid creating a giant scoring formula that nobody can explain.

A complete signal-based GTM architecture

Putting everything together:

DATA SOURCES
                       │
        ┌──────────────┼──────────────┐
        ↓              ↓              ↓
   First Party    Third Party    Product Data
        │              │              │
        └──────────────┼──────────────┘
                       ↓
                SIGNAL DETECTION
                       ↓
                ENTITY RESOLUTION
                       ↓
                NORMALIZATION
                       ↓
                  ENRICHMENT
                       ↓
              SIGNAL VALIDATION
                       ↓
             ┌─────────┴─────────┐
             ↓                   ↓
          ICP FIT             INTENT
             │                   │
             └─────────┬─────────┘
                       ↓
                 SIGNAL STACK
                       ↓
                  SCORE
                       ↓
              DECISION ENGINE
                       ↓
                ROUTING LAYER
                       ↓
       ┌───────────────┼───────────────┐
       ↓               ↓               ↓
      CRM            Slack          AI Agent
       │               │               │
       └───────────────┼───────────────┘
                       ↓
                    ACTION
                       ↓
                   OUTCOME
                       ↓
                FEEDBACK LOOP
                       ↓
                SYSTEM LEARNING

This is the architecture a GTM Engineer should think about when designing a signal-based system.

The individual tools are implementation details.

The system is the important part.

Where Clay fits into the architecture?

Clay can act as a central orchestration layer for signal-based GTM workflows because it combines signal detection, enrichment, AI research, scoring, workflow automation, and activation.

Its current GTM engineering documentation describes a pattern of:

Signals
↓
Enrich + Score
↓
CRM + Outbound

and its newer Workflows product is designed to run GTM plays against account data and branch based on logic.

A typical implementation could therefore look like:

External Signals
       ↓
Clay
       ↓
Enrichment
       ↓
AI Research
       ↓
Scoring
       ↓
Decision Logic
       ↓
Salesforce / HubSpot
       ↓
Slack / Sales Engagement

The important point is that Clay is one possible implementation.

A signal architecture can also be built using:

• CRM automation
• APIs
• webhooks
• data warehouses
• enrichment platforms
• workflow tools
• custom code
• AI agents
• reverse ETL
• sales engagement systems

The architecture should determine the tool selection, not the other way around.

When to use a workflow vs an AI agent?

This distinction becomes increasingly important as GTM systems mature.

Use a workflow when:

IF X
THEN Y

is predictable.

Examples:

If score > 80 → assign AE
If demo request → enrich company
If customer usage > threshold → alert CSM

Use an AI agent when the system must reason about an open-ended question.

Examples:

Which accounts appear to be changing their GTM strategy?
Which accounts are showing evidence of a new operational problem?
Which accounts should receive this particular sales play?
What evidence suggests that this company is evaluating competitors?

The distinction can be visualized as:

DETERMINISTIC
↓
WORKFLOW

NON-DETERMINISTIC
↓
AI AGENT

Modern GTM engineering increasingly combines the two. Clay's current GTM infrastructure guidance describes workflows as event-triggered systems while agents can reason over broader account context and decide what deserves action.

What is the future of signal-based systems?

The next generation of signal systems will move from:

Detecting predefined events

toward:

Continuously understanding account state.

A traditional system might monitor:

Funding
Hiring
Job Changes
Website Visits

A more advanced system could continuously evaluate:

What is changing inside this account?
Why is it changing?
Does the change create a problem?
Is the problem relevant to our product?
Who owns the problem?
How urgent is it?
What evidence supports the conclusion?
What should we do next?

Conclusion

A signal-based system is much more than a collection of intent alerts.

It is an infrastructure layer that continuously observes changes, adds context, determines relevance, prioritizes opportunities, and activates the appropriate GTM response.

The complete system can be represented as:

DATA
  ↓
SIGNAL DETECTION
  ↓
ENTITY RESOLUTION
  ↓
ENRICHMENT
  ↓
VALIDATION
  ↓
SCORING
  ↓
SIGNAL STACKING
  ↓
ACCOUNT STATE
  ↓
DECISION ENGINE
  ↓
ROUTING
  ↓
ACTION
  ↓
OUTCOME
  ↓
LEARNING

The most effective systems combine first-party data, third-party signals, ICP fit, behavioral intent, company changes, signal stacking, recency, confidence, AI research, deterministic automation, and human judgment.

The goal is not to predict every purchase.

The goal is to recognize meaningful changes earlier and help the GTM team respond more intelligently.

This changes the traditional GTM workflow.

Instead of starting with a static account list and asking salespeople to find a reason to reach out, the system continuously searches for new reasons to act.

Instead of:

Account List
   ↓
Research
   ↓
Find Reason
   ↓
Outreach

the model becomes:

Market Changes
   ↓
Signal Detection
   ↓
Account Intelligence
   ↓
Priority
   ↓
Recommended Action
   ↓
Sales Conversation

That is the fundamental value of signal-based GTM engineering.

The system watches what changes.
The system determines what matters.
The system prepares the next action.
The GTM team focuses on execution and relationships.

As AI agents become better at interpreting unstructured data, signal-based systems will increasingly evolve from simple event-driven workflows into continuously updated account intelligence systems.

For companies building modern GTM infrastructure, this creates an opportunity to move from reactive automation to proactive revenue operations.

The competitive advantage will not come from having the most signals.

It will come from having the best system for turning those signals into timely, relevant, and measurable action.