How to Build a Buying Signal Database for B2B: A 7-Step Operational Playbook

The 7-Step Signal Database Build

Step 1: Inventory your existing signal sources

Deliverable. A spreadsheet listing every existing source of buyer-behavior data in your stack, even the ones currently ignored.

Time estimate. One to two weeks, mostly in interviews.

What to do. Interview Sales, SDRs, Marketing, RevOps, and Customer Success. Ask each function two questions: “When you know an account is in-market, what is the evidence you trust?” and “What signals do you wish you could see but can’t?” Write every answer down. The first list is current sources. The second list is the gap.

Typical current sources at a $100M ARR B2B company:

– CRM events (opportunity stage changes, last-activity dates, email opens if tracked) – Marketing automation activity (campaign clicks, form fills, page views on key pages) – Sales engagement platform activity (reply rates, sequence completion rates) – Contact enrichment alerts (job changes via LinkedIn Sales Navigator or Champify) – Funding announcements (Crunchbase, PitchBook) – Hiring signals (job posts matching ICP profiles) – Review-site activity (G2 or TrustRadius category interest) – Third-party intent data (Bombora, 6sense, Demandbase if owned) – Technographic changes (BuiltWith, HG Insights, Slintel)

Most teams find 8 to 12 current sources. Most are not actively instrumented. That is the starting point.

The anti-pattern. Skipping this step and starting with “we need to buy Bombora.” The tool is the last thing to buy, not the first. You cannot evaluate whether Bombora is the right addition until you know what you already have. The number of teams that have bought a $60K per year intent data tool while ignoring their own G2 Buyer Intent feed is higher than anyone wants to admit.

At Growleads we ran a pilot in 2023 where the client’s existing marketing automation data contained a two-month-old high-intent signal on an account that had since closed lost. The signal had fired. The SDR team had never seen it. The account had gone to a competitor. We did not add a new source. We instrumented the source that was already there. Revenue increase without new data spend was measurable by month three.

Step 2: Define the signal schema

Deliverable. A written schema document with five required fields plus two optional fields. One page. Reviewed by RevOps, Sales, and Marketing.

Time estimate. One week. Do not skip.

The five required fields.

Field	Type	Example
event	string (from a controlled vocabulary)	“funding_announcement_series_b”
entity	account or contact ID (FK to CRM)	“0018X00002abc123”
timestamp	ISO 8601 datetime	“2026-04-18T14:32:00Z”
confidence	integer 1 to 5	4
source	string (which tool surfaced this)	“bombora”

The two optional fields that are useful but should not block v1:

Field	Type	Example
signal_value	JSON blob for event-specific payload	{“topic”:”customer data platform”,”amount”:”$40M”}
decay_halflife_days	integer	90

The Signal Schema: 8 Required Columns

Why these five. Event is what happened. Entity is who it happened to. Timestamp is when. Confidence is how much you trust the signal. Source is where it came from. Every reporting question you will ever ask can be answered from those five fields. Most scoring models can be built with just these five.

The controlled vocabulary for event types. Start with 10 to 15 event types. Not 30. Not 50. Ten to fifteen. Examples:

– funding_announcement_any (with amount and stage as signal_value) – hiring_event_relevant_role (controlled by matching job title to a list) – g2_category_research (with category name as signal_value) – g2_comparison_page_view (competitor comparison specifically) – bombora_surge (with topic list as signal_value) – website_pricing_page_view (first-party) – website_demo_request (first-party) – crm_opportunity_reopened (first-party) – technographic_add (with tech name as signal_value) – technographic_remove (with tech name as signal_value) – review_site_comparison_view (TrustRadius equivalent) – linkedin_engagement_target_persona

You will add event types over time. Do not start with more than 15.

The anti-pattern. The schema gets over-engineered in week one. A team adds 12 optional fields (“let’s track the UTM source, the campaign ID, the original referrer, the geography, the device type…”) and then spends three months trying to populate them all. Six months in, 80% of signal rows have 40% of fields null. The scoring model becomes untrustworthy because nobody knows which fields are reliable.

Start with five fields. Add optional fields only when a specific use case justifies them.

“We had a client in 2024 who insisted on a schema with 14 fields. I pushed back. We compromised at 11. They never populated the last 6. The scoring model the data science team built was weaker than it would have been with five well-populated fields. I was right to push harder. Every schema decision past field five should be defended with a specific, named use case. No use case, no field.”

Malay Gupta, Partner and Head of Operations and Growth, Growleads

Step 3: Choose the storage model

Deliverable. A storage decision with named infrastructure, owner, and first-write date.

Time estimate. Two weeks of decision-making. Implementation follows the decision.

Three options in practice.

Option A: Structured signal table inside the CRM. A custom object in Salesforce or a custom table in HubSpot, populated by Zapier, Workato, or native integrations. Signals live alongside accounts. Reporting uses native CRM tools.

– Pros. Fast to build. No new infrastructure. Sales team already trusts the CRM. – Cons. Volume ceiling (Salesforce custom objects start to strain above roughly 1 million signals per month). CRM is not designed as an analytical store. – Best for. $20M to $150M ARR B2B. Signal volume below 100K per month. Stage 2 to Stage 3 maturity. This is the right starting point for most teams.

Option B: Data warehouse + reverse ETL. Signals land in Snowflake, BigQuery, or Redshift via ETL. A reverse-ETL tool (Census, Hightouch, Polytomic) syncs scored accounts and signal summaries back to the CRM.

– Pros. No volume ceiling. Analytical power. Signals can be joined with product usage, billing, and support data. – Cons. Requires a data platform investment and a data engineering function (or a very capable RevOps team). Three to six-month build. – Best for. $150M to $1B ARR B2B with existing data warehouse investment. Stage 3 to Stage 4 maturity.

Option C: Purpose-built signal platform. 6sense, Demandbase, or similar aggregates signals in its own platform and pushes scored accounts to the CRM.

– Pros. Fastest time-to-signal (weeks, not months). Built-in scoring. ABM orchestration included. – Cons. Expensive ($100K to $400K per year). Lock-in. Platform roadmap drives your architecture, not yours. – Best for. Enterprise B2B ($300M+ ARR) with mature RevOps and an ABM motion already running. Stage 3 to Stage 4 maturity.

Starter Signal Scoring Weights

The contrarian recommendation. Most $50M to $300M ARR teams should start with Option A, a structured signal table inside the CRM. Prove the scoring model works. Prove the outcome loop closes. Prove the motion produces pipeline. Then migrate to Option B or C only if the volume or sophistication actually requires it. Most teams never need the migration. The CRM signal table scales further than most teams expect, because for most teams the bottleneck is never signal volume. The bottleneck is consumption.

This is the single biggest decision in the entire build, and the one where teams are most likely to get it wrong. The fashion in 2024-2026 has been to buy Option C first. The result has been a lot of shelfware and a lot of second implementations starting from scratch. An analogy from customer support infrastructure: teams that start with Zendesk Enterprise before they need it produce the same shelfware pattern. Start with what you need. Grow into what comes next.

The anti-pattern. Choosing the storage model by vendor visit and demo polish rather than by ops capacity. The right question is “what can our team actually operate in 90 days?” not “what is the best tool?”

Step 4: Instrument the sources

Deliverable. Each event type from step 2 has a working integration writing rows into the signal table from step 3.

Time estimate. Four to eight weeks, depending on how many sources and the storage model chosen.

The typical source-to-integration map.

Source	Integration pattern
Salesforce opportunity events	Native Salesforce flows or Apex triggers write to the signal table
HubSpot marketing automation	Native HubSpot workflows + webhook to signal table
Outreach/Salesloft/Apollo activity	Native SEP webhooks or API polling
Bombora surge topics	Daily CSV import via Workato, or native integration if using 6sense/Demandbase
G2 Buyer Intent	Native G2 integration to CRM, or CSV export into signal table
Funding announcements (Crunchbase)	API polling via Workato or Zapier, filter by ICP
Hiring signals	LinkedIn Sales Navigator alerts + manual or Champify automation
Technographic (BuiltWith, HG Insights)	Monthly snapshot import via CSV or API
Website behavior	Segment events → reverse ETL → signal table

Not every source is worth instrumenting in v1. Start with the 5 highest-ROI sources for your motion. For most B2B SaaS companies at Stage 2, that list is: CRM events, HubSpot or Marketo activity, G2 Buyer Intent, Bombora, and hiring signals.

The anti-pattern. Instrumenting 15 sources in parallel and having none of them fully working at the end of 60 days. Sequence the sources. Get one working end-to-end (source → signal table → dashboard) before starting the next. Demonstrating value from 3 sources by week 8 produces more political capital than 15 half-integrated sources at week 16.

Step 5: Build the scoring model

Deliverable. A scoring function that assigns an account-level score from 0 to 100 based on signal density, type, recency, and confidence.

Time estimate. Two to four weeks for v1. Ongoing refinement thereafter.

The starter scoring model. Resist building something clever. Build the simplest model that uses the data. A weighted sum that decays over time. Five signals, three weight tiers, time decay over 90 days.

Signal type	Base weight	Time decay half-life
website_demo_request	30	30 days
g2_comparison_page_view	25	14 days
bombora_surge	15	60 days
hiring_event_relevant_role	10	90 days
funding_announcement_any	10	180 days

The account’s score is the sum of decayed weighted signals. Accounts above 50 are in-market. Accounts between 25 and 50 are warming. Accounts below 25 are noise.

Why this works. The model is transparent. A sales team that asks “why is this account scored at 72?” gets a readable answer: 30 from last week’s demo request + 25 from G2 comparison view + 17 remaining from a Bombora surge from 3 weeks ago. Sales trusts what it can explain. The model does not need to be more sophisticated than this in year one.

What to avoid in v1. Machine learning. Neural networks. Clever embeddings. Save those for Stage 4 (see the maturity model). A weighted linear model that your RevOps lead can explain in a whiteboard session will outperform a black-box ML model that nobody trusts. You get to the ML model later, once the linear model has earned trust and revealed the data patterns that a more sophisticated model would exploit.

The anti-pattern. Over-engineering the scoring model before the data is trustworthy. A scoring model is only as good as its inputs. If signal source instrumentation is uneven in week 10, refining the scoring algorithm in week 12 is premature. Fix the inputs first.

Step 6: Route signals to humans

Deliverable. Every account that crosses the scoring threshold produces a task in the relevant SDR’s or AE’s queue within 24 hours, with signal context attached.

Time estimate. Two weeks if Salesforce Flow or HubSpot workflow is the mechanism. Four weeks if a custom middleware is needed.

The routing logic. Three rules, no more.

1. Ownership first. If the account has an owner, route to the owner. Never route around ownership. 2. Territory second. If the account has no owner, route to the SDR whose territory it falls in. 3. Strategic account override. If the account is on a named-account list, route to a specific AE regardless of territory.

The task itself contains: account name, score, top 3 signals with timestamps, suggested opening line that references the signal, and a one-click path to the account’s record in the CRM.

Integration with the sales engagement platform. The task appears in Outreach, Salesloft, or Apollo as a task on the account, with priority matching the score. This is non-negotiable. Tasks that live only in the CRM are ignored. Tasks that live in the rep’s daily working tool (SEP) get actioned.

Which Route: Hot / Warm / Monitor

The 24-hour rule. The signal that fired yesterday is already weaker today and much weaker next week. Routing latency is a revenue-leak that teams underestimate. If your routing depends on a human triaging a queue, the latency is usually 3 to 7 days. Automate it. The rep’s first action on the signal should happen within 24 hours of the signal firing.

The anti-pattern. Over-personalizing the routed task. A task that demands 20 minutes of rep prep time to action will be skipped. The task should be actionable in 5 minutes or less from opening it. The signal context + the suggested opening + the CRM link is enough. If the rep wants to go deeper, the CRM record is one click away.

Step 7: Close the outcome loop

Deliverable. Every meeting booked and every opportunity created is tagged with the signal stack that triggered it. The scoring model is retrained (or reweighted manually) at least monthly against the tagged outcomes.

Time estimate. Three weeks of engineering to build the tagging. Ongoing forever.

Why this matters. Every tool on the market will rank accounts by signal density on day one. The difference between a team that gets pipeline from it and one that does not is whether outcomes feed back into the scoring model. Most do not. This is the single most common stall point between Stage 3 and Stage 4 in the maturity model, and it is the step that separates buying-signal theater from working Demand Intelligence.

The tagging logic. When a meeting is booked, the meeting record in Salesforce is linked to the top N signals (typically 3) that contributed to the account’s score at the time of booking. Same for opportunities created. Same for opportunities closed won or lost. This is a foreign-key relationship between the meeting object and the signal table.

The monthly review. Every month, RevOps pulls a report showing signal-to-meeting and signal-to-opportunity conversion by signal type. High-converting signals get weight increases. Low-converting signals get weight decreases or retirement. The model evolves on real data, not on intuition.

The failure mode that kills this step. Attribution debates. “Which signal actually triggered this meeting?” Teams get stuck trying to attribute the meeting to a single signal. The answer is: attribute to all the signals active on the account within the 30 days before the booking, weighted by their recency and base weight at booking time. Do not try to attribute to one signal. The signal stack is the unit of attribution, not the individual signal.

At Growleads we ran this loop for 2 years without mentioning it in sales conversations. Prospective clients asked how our outbound motion worked, and we described it without mentioning the outcome loop. That was a mistake. The outcome loop is the single most valuable artifact in the entire build, and the one competitors are least likely to have. We lead with it now, and it has moved the close rate on enterprise RFPs measurably.

The anti-pattern. Building the entire system through step 6 and declaring victory. The scoring model calcifies around first-quarter signal quality. The system gets worse over time because the signal-source mix changes but the model does not adapt. Teams that ship step 6 and skip step 7 produce a working system for 90 days and a deteriorating system for the 9 months after that.

Common failure modes

The seven-step process looks linear. The failure modes are where the sequence fights back.

Failure mode 1: skipping step 2. The schema is the foundation. Teams that skip it and start with “let’s put intent data in the CRM” produce a signal table with inconsistent event types, sparse timestamps, and no trusted source-of-truth. Reporting becomes impossible. Scoring becomes arbitrary. The fix is painful: redefine the schema in month 6 and backfill 6 months of history. Easier to get it right in week 2.

Failure mode 2: buying a platform in step 3 before validating the schema in step 2. The platform choice is easier to undo than most teams think, but only if the schema is right. A team with a working schema can switch platforms in 8 to 12 weeks. A team with a broken schema cannot switch platforms at all because the schema-to-platform mapping is itself the broken piece. Schema first, platform second.

Failure mode 3: over-instrumenting in step 4. 15 parallel integrations produce 0 working integrations. 3 sequential integrations produce 3 working ones. The sequence matters more than the parallelism.

Failure mode 4: premature machine learning in step 5. The starter model (weighted sum with decay) is sufficient for the first year. ML is a step-4 investment in the maturity model, not a step-5 investment in this playbook.

Failure mode 5: routing to CRM only, not SEP. Tasks in the CRM get ignored. Tasks in the SEP get actioned. This is a 5x difference in signal-to-meeting conversion. Route to the rep’s working tool.

Failure mode 6: skipping step 7. The outcome loop is the infrastructure that makes the scoring model improve over time. Without it, the system deteriorates. This is the single most common reason buying-signal projects fail. The platform is fine. The tooling is fine. The loop is missing.

Failure mode 7: not telling anyone. Teams that ship the full 7-step build and do not communicate it internally watch the build slowly get ignored as priorities shift. Publish monthly updates to the revenue leadership. Show signal-to-meeting trends. Show pipeline sourced through the signal layer. Make the system visible or it becomes invisible.

For the strategic question of where this 90-day build sits in the longer Demand Intelligence arc, the maturity model is the frame. For the category explainer, the Demand Intelligence Framework and signal-based outbound are the pair of cornerstones you want to read in sequence after this one.

FAQ

Next steps

1. Run step 1 this week. Interview five functions. Write the inventory. 2. Draft the signal schema in step 2 next week. Keep it to five fields. Get RevOps, Sales, and Marketing to sign off on one page. 3. Make the storage decision in step 3 with the question “what can our team operate in 90 days?” not “what is the best tool?” 4. Sequence steps 4 through 7 over 90 to 120 days. Do not parallelize beyond what the team can actually execute.

If you want the strategic frame that sits above this build, the Demand Intelligence Maturity Model describes the 5 stages this build moves you through. If you want the tool-selection context, best B2B intent data tools 2026 is the scorecard.

If you want Growleads to run this build for you or alongside your RevOps team, the Demand Intelligence service page has our scope. Contact us and bring the inventory from step 1.