.png){kind=small}
Direct answer: a signal-based RevOps system has three jobs, and you build them in this order. Signals in: pull buyer signals from Clay, intent data, product usage and call recordings into one place. Context attached: enrich and reason over each signal against a real sales method (SPICED feeding MEDDIC) so it becomes a scored, qualified next move rather than a raw event. Next move surfaced: write that move and its reason back into HubSpot, on the record the rep already works, as a task or property. On HubSpot the architecture is HubSpot as the system of record and where reps work, Clay as the signal and enrichment engine, a context store (we use Supabase) to hold everything joined up, and a reasoning layer (we use Claude) to decide the next move. The hard part is never the wiring. It is the scoring, the credit cost, and the discipline to surface one move instead of fifty.
This is the hands-on companion to the GTM engineering pillar. That page explains what a signal-driven system is and why the context gap costs you revenue. This one is how you actually build it on HubSpot and Clay, step by step, including the part everyone underestimates.
Published 17 July 2026. Reviewed quarterly.
A signal-based RevOps system is a setup where buyer signals do not just get collected, they get turned into a specific action for a rep and surfaced where the rep works. The old RevOps job was reporting: build the dashboard, show what happened, let someone else decide. A signal-based system does the deciding. A signal fires, the system works out what it means for that account, and the rep gets handed the next move with the reason attached.
The difference is the "now what". Most stacks are very good at producing signals and useless at acting on them. Clay flags a new VP of Sales, an intent tool shows a surge, a call recorder catches a buying objection nobody followed up, HubSpot logs a deal gone quiet for eleven days. Each one is a reason to do something. In most companies they all just sit there, in six different tools, and the rep never sees the one that matters this week. The distance between a signal firing and a rep knowing the right thing to do is the context gap, and closing it is the whole point of building this.
Keep the mental model simple. Four parts, each with one job. You can build it on HubSpot and Clay with a context store and a reasoning layer behind them, and everything else is detail.
1/ HubSpot, the system of record and where reps work. This is non-negotiable as the surface. The rep already lives in HubSpot all day. If the next move does not appear there, on the contact, company or deal, it does not exist as far as the rep is concerned. HubSpot holds the canonical deal and lifecycle data, and it is where the system writes the move back. We only work with HubSpot for exactly this reason: the writeback is the part that makes a signal system real, and you cannot do a clean writeback into a CRM you do not know inside out.
2/ Clay, the signal and enrichment engine. Clay is where most signals get sourced and enriched: firmographic, hiring, technographic, relationship signals like a champion changing jobs. It is also where you combine several weak signals into one strong one before anything downstream spends money on them. Think of Clay as the front door for external context.
3/ A context store, the place everything gets joined up. This is the part most people skip, and it is why their system stays brittle. You need somewhere that holds the account's full picture in one place: the signals, the CRM history, the call insights, the outcomes of past moves. We use Supabase as the context store. Without it, every signal is evaluated in isolation, blind to what you already know about the account, and you cannot do the one thing that makes scoring work: judge a signal relative to what is already true.
4/ A reasoning layer, the part that decides the next move. This is where a signal plus the account context becomes one scored, specific action. We use Claude here, running each signal against the account's context and a real sales method, then producing the move and the reason in plain language. This is the part you cannot buy as a feature. It is also the part worth getting right, because everything upstream is plumbing and this is the bit that produces the answer.
n8n sits in there too where you need glue between tools, but it is wiring, not a fifth pillar. Do not over-architect. Four parts, built in order, signals in then context attached then next move surfaced.
Build it back to front from the rep's point of view. The rep needs a next move in HubSpot, so work out what that move looks like first, then build the machinery that produces it. Here is the order I actually build in.
Pick your three highest-value signal types and, for each, write down the single next move it should produce and the reason that justifies it. A new VP of Sales at a target account earns "AE reaches out referencing the transition, route to the AE not the SDR sequence". A free-plan account hitting its usage ceiling earns "PLG-to-sales handoff with the specific usage pattern attached". Get these on paper first. If you cannot describe the move in one sentence, the system has nothing to produce, and no amount of tooling fixes that. This is the step people skip because it is not technical, and it is the most important one.
Decide where the move lands. For most teams that is a HubSpot task on the contact or company, plus a couple of custom properties: a "next move" property, a "signal reason" property, and a "signal score" property so reps and managers can sort by it. Build a simple view or dashboard that shows reps their accounts ranked by what needs doing now. You are not building reporting here, you are building a worklist. The rep should open one view and see the top thing to do, not go hunting across six tabs.
Bring your signals into Clay and enrich them. The critical move, and I will come back to this because it is where people burn money, is to put a cheap pre-qualification filter before any expensive enrichment. Check the obvious disqualifiers first (wrong geography, wrong size, already a customer, already in an open deal) using the data you already have, and only spend enrichment credits on what survives the filter. Most teams enrich everything and then filter, which is exactly backwards.
Push the enriched signals, plus the relevant HubSpot history, into a context store. We use Supabase. The job here is to hold the account's full picture joined up: every signal, the deal stage, the lifecycle, the last call insight, the outcome of the last move you made. This is what lets the reasoning layer score a signal relative to what you already know, which is the difference between "this account fits your ICP" (you knew that, worthless) and "the economic buyer just changed and there is now a critical event" (you did not know that, act today).
This is where the signal becomes an action. The reasoning layer (we use Claude) takes the signal plus the account context plus your sales method and produces three things: a score for how much this moves the deal, the single next move, and the reason in language the rep will trust. We run SPICED to build the account picture feeding MEDDIC for deal qualification, both grounded in Winning by Design's Revenue Architecture. The detail of how we score and prompt this is the proprietary part, and it is fully covered in the companion guide on turning buying signals into sales actions. What matters architecturally is that the output is a decision, not a data point.
Close the loop into the rep's world. The reasoning layer's output gets written back to the HubSpot record from Step 2: the task gets created, the next-move and reason properties get populated, the score gets set so the worklist sorts correctly. This is the writeback, and it is the step that separates a real system from a clever dashboard nobody opens.
Record what the rep actually did and what happened. Did the move book a meeting, advance the stage, go nowhere? Push that outcome back into the context store so the next time a similar signal fires on a similar account, the scoring is sharper. This is the step that makes the system compound instead of running the same blunt rules forever. It is also, predictably, the step everyone leaves for "later" and never builds.
Here is the lesson that catches almost everyone, and it caught us properly on a high-volume outbound build before we got religious about it.
Enrichment costs money per record. Clay credits, intent data, third-party APIs, all of it metered. When you are running signals across a large list, the instinct is to enrich first and qualify second, because enrichment is what tells you whether the account is good. That instinct will quietly drain your budget. On a big list you can spend the bulk of your credits enriching accounts you were always going to throw away, and only find out after the money is gone.
The fix is a pre-qualification gate, and it is boring and it works. Before you spend a single enrichment credit, run the record through the cheap checks you can do with data you already have: geography, company size band, is this already a customer, is there already an open deal, does it even fit the ICP on the obvious dimensions. Throw out everything that fails. Only enrich what survives. On a large list this is the difference between a system you can afford to run continuously and one you switch off after the first invoice.
The deeper version of the lesson: pre-qualification is not just cost control, it is signal quality. A signal on an account that was never going to buy is not a signal, it is noise that happens to have a timestamp. Filtering hard before you enrich makes the whole system cheaper and sharper at the same time. If I could give one piece of advice to anyone building this themselves, it is design the credit budget and the pre-qualification gate on day one, not after the first bill lands.
I am genuinely in favour of teams building as much of this as they can themselves. Plenty of it is within reach if you have a capable RevOps person and some patience. So here is the honest version of where it tends to fall over, so you can go in with your eyes open.
The reasoning layer is hard to get right and easy to get wrong. Wiring signals into Clay and writing tasks into HubSpot is achievable. Getting a reasoning layer to score a signal correctly against your method, account by account, and produce a move a rep actually trusts, is the part that takes real iteration. A reasoning layer that hands reps bad moves is worse than no system, because reps stop trusting it after the third dud and then ignore the good ones too. Protecting rep trust is the whole game and it is fragile.
The context store is real engineering, not a spreadsheet. Joining signals, CRM history and outcomes into one queryable picture, and keeping it current, is a proper data job. People try to fake it with a big Clay table or a Google Sheet and hit a wall fast, because you cannot reason over what you cannot join up.
The feedback loop almost never gets built. Teams build steps one to six in a sprint of enthusiasm and never build step seven, so the system never gets sharper. Without the loop you have a static rules engine, not a system that learns. It is the least glamorous step and the first one that gets dropped.
Credit cost gets out of hand without a gate. Covered above. This one specifically punishes the build-it-yourself crowd, because the pre-qualification discipline is something you usually learn by getting burned, and getting burned at scale is expensive.
It needs deep HubSpot knowledge to do the writeback cleanly. A messy writeback creates duplicate tasks, overwrites good data, and erodes trust in the CRM. Doing it cleanly means knowing HubSpot's object model, associations and automation properly.
None of that means do not build it. It means build the parts that are within reach, be honest about the two hard parts (the reasoning layer and the context store), design the credit budget up front, and get help on the bits where a mistake is expensive or erodes rep trust. Building three signals end to end yourself will teach you more about your own GTM than any audit.
Most of it. Capture, enrichment, scoring, the writeback into HubSpot and the outcome capture can all run automatically. The bit that stays human is the move itself: the email, the call, the personal note to a champion who just changed jobs. The system's job is to make sure the rep is always working the right account on the right thing with the reason in front of them. It is not to replace the selling. Signal-driven and system-led, but human-executed.
A rep opens HubSpot and sees, on the account they are working: what changed (the signal), why it matters (the method gap it fills), the one thing to do about it (the next move), and a score so they know where it sits against everything else on their plate. They do the move. The outcome gets logged. The scoring adjusts. Next time a similar signal fires, the system is a little sharper.
That is the intelligence layer between your tools and your revenue, built on HubSpot and Clay with a context store and a reasoning layer behind them. The stack you already own stops being a place data goes to die and starts deciding what happens next. You do not have to build all of it at once. Get three signals running end to end, surfaced in HubSpot, with the credit gate and the feedback loop in place. Three working signals beat thirty that fire into a void.
At a minimum: HubSpot as the system of record and the surface reps work in, and Clay as the signal and enrichment engine. To make it reason properly rather than just route raw signals, you add a context store (we use Supabase) to hold the account's full picture joined up, and a reasoning layer (we use Claude) to score signals and produce the next move. n8n is useful as glue between tools where needed. The two you cannot skip are HubSpot and a way to source signals.
Partly. HubSpot is the right place for the worklist, the next-move properties and the writeback, and you can do a basic version with HubSpot workflows and lists. But HubSpot is not a signal-sourcing engine or a reasoning layer. For real signal coverage you need Clay, and to score signals against a sales method relative to what you already know about an account, you need a context store and a reasoning layer outside HubSpot. HubSpot is the surface, not the whole system.
Because a signal is only worth scoring relative to what you already know about the account. Without a place that holds the account's full picture joined up (signals, CRM history, call insights, past outcomes), every signal is evaluated blind, and you cannot tell the difference between a signal that confirms something obvious and one that reveals a new critical event. The context store is what makes the scoring intelligent rather than a flat set of rules.
Enriching before you pre-qualify. Enrichment costs money per record, so if you enrich a whole list and filter afterwards, you spend most of your budget on accounts you were always going to discard. Put a cheap pre-qualification gate first (geography, size, existing customer, open deal, obvious ICP fit) using data you already have, and only enrich what survives. It controls cost and improves signal quality at the same time.
A focused first version, three high-value signal types running end to end from capture to writeback in HubSpot, is a few weeks of real work, not months, if you scope it tightly. The mistake is trying to build for thirty signals at once. Get three working, with the credit gate and the feedback loop in place, then add more. The architecture is the same whether you run three signals or thirty.
They use it if, and only if, the next move lands inside HubSpot where they already work, as a task or property on the record, with the reason attached. The failure mode is surfacing signals in a separate dashboard reps open once and never again. The whole design principle is to remove the step where the rep has to go looking. Put the move in their flow of work or do not bother building it.
Design the credit budget and the pre-qualification gate before you turn anything on. Filter hard on cheap, already-available data first, enrich only what passes, and combine several weak signals into one strong one in Clay before spending on deep enrichment. Cost discipline is not a tax on the system, it is part of what makes the signals sharper, because you stop spending on accounts that were never going to buy.
%20(1).jpeg)