Insights

Capturing a Signal and Routing It Are Different Jobs

A recording, ticket, or decision log proves that evidence exists. It does not prove the right person received it with enough context and time to act.

A company records every sales call and still leaves marketing unaware of the objection that keeps stopping deals.

Support stores every ticket and still launches a campaign built around a promise customers regularly misunderstand. Product documents a decision and still lets an old claim remain on the website.

Nothing was lost at the source. The evidence was captured. The failure happened after capture, when the company assumed storage had completed the handoff.

A Captured Record Only Proves Existence

Capture answers a narrow question: did the source event become available in a form the system can preserve and inspect?

A transcript, ticket, product note, churn interview, or decision record can satisfy that requirement. The source should remain attached, the event time should be known, and the evidence should be retrievable. That is meaningful infrastructure. It still says nothing about whether the item matters to marketing.

Routing answers the next set of questions. What kind of signal is this? Which decision can it change? Who should receive it? What context do they need? When will delivery still be useful? What happens if no normal route applies?

These jobs belong in one pipeline, but they need separate definitions and measures. A healthy capture layer can sit in front of a broken route for years.

Technical Pipelines Already Separate These Jobs

The distinction is familiar in data infrastructure. The OpenTelemetry Collector defines receivers that collect data, processors that transform or filter it, and exporters that send it to destinations. Receiving is one component. Deciding what happens next and sending the result are separate components.

Amazon EventBridge uses a similar division. Its event bus documentation explains that an event arrives on a bus, rules evaluate whether it matches, and matching events go to specified targets. An event may match several rules or none.

Marketing intelligence is not telemetry or a cloud event bus. The operating lesson still holds: arrival at a collection point does not identify the right destination or complete delivery.

The Source System Is Not the Destination

A source system is designed around the work that creates the record. Sales call platforms serve sales workflows. Support tools help teams resolve tickets. Product systems organize product work. Their records may carry value for marketing, but marketing is rarely the primary destination.

Giving marketing access does not create a route. It gives a person another place to search. A weekly reminder does not create a route either. It makes the handoff depend on memory, available time, and somebody noticing the pattern before the meeting.

The guide to using call recordings for marketing makes this problem visible at one source. The same failure occurs anywhere a company confuses an available record with a delivered signal.

Routing Begins With Eligibility

Sending every captured event to marketing would move the failure downstream. The recipient would receive a large feed with no distinction between routine activity and evidence that can change the work.

Define the eligible signal before defining the notification. A direct buyer objection may qualify when it affects an active decision. A support event may qualify when it changes a public promise or joins a recurring pattern. A product decision may qualify when it changes the truth of a published claim.

The rule can use event type, subject, recurrence, consequence, or a named decision window. It should also record why the event qualified. A label without the reason forces the recipient to repeat the classification work.

Every Route Needs a Contract

A route should be explicit enough to test without asking who normally handles it.

Define the eligible event. Keep the original evidence attached. State the classification rule. Name the destination or owner. Set the delivery timing from the decision window. Add a fallback for anything the normal route cannot deliver.

The destination should match the decision. A repeated objection may belong in a content queue. A changed product boundary may need the owner of a live page. A pattern across churn interviews may belong in a positioning review with the underlying sources available.

A shared channel can be one destination, but it cannot be the owner. The route is incomplete until a person, role, or governed queue owns what happens next.

Preserve Evidence Through the Handoff

Routing should add context without replacing the source. Keep the original passage or stable reference, event time, account or segment context, classification, and reason for delivery on the same record.

This protects the signal from two common failures. The first is compression, where a specific buyer statement becomes a vague summary. The second is detachment, where the recipient sees a claim but cannot inspect the evidence behind it.

The earlier article on finding AEO content inside the company separates evidence, explanation, proof, and public claim. The same separation belongs inside the route. A clean notification cannot silently become the source of truth.

Failed Routes Need Visible States

Some events will not classify. Some will match a rule but have no active owner. Some deliveries will fail. Some recipients will reject a signal because the evidence is incomplete or the destination was wrong.

Do not hide those items inside one generic error count. Keep distinct queues for unclassified, unowned, undelivered, and returned signals. Preserve the source and record why the route stopped.

Each state needs a fallback owner and an age. A signal that cannot be routed today may expose a missing decision right, a stale rule, or a source-quality problem. Closing it deliberately is valid. Letting it disappear is not.

Measure Capture and Routing Separately

Capture coverage measures whether eligible source events entered the system. Classification rate measures whether captured events reached a defined signal state. Delivery success measures whether the intended destination received the record. Route latency measures the time from capture to that usable delivery. Unowned backlog shows work with no accountable destination.

Do not compress these into one completion rate. A high capture rate can hide a classification queue. A high delivery rate can exclude unowned items. Fast latency can describe only the easy signals that completed the trip.

The marketing intelligence latency metric provides the time model. Pair it with stage-specific coverage so a missing route cannot improve the speed score by disappearing from the denominator.

Build the Handoff Around the Decision

Start with one source and one marketing decision. Define what counts as an eligible event, the evidence required, the route, the owner, the delivery window, and the fallback state. Run real records through it and inspect where they stop.

Northstar's Listening Engine handles capture, classification, and routing as distinct stages. The Glass Dashboard keeps the source, rule, destination, owner, status, age, and failure queue visible. The core system is complete at that point. The Pinnacle remains optional for companies that want a wider operating layer.

Capture preserves what the company learned. Routing puts that learning in front of the person who can still use it. Treating those as separate jobs is how a collection of records becomes a working intelligence system.

Frequently asked questions

What is the difference between capturing and routing a signal?

Capture makes a source event available and preserves its evidence. Routing determines whether it matters, adds the context required for use, and delivers it to a named owner or destination on the right cadence.

Why is a source-system record not enough?

A record can exist without anyone in marketing knowing it exists, understanding why it matters, or owning the next action. Storage solves retrieval. It does not complete the handoff.

What should a marketing signal routing contract include?

Define the eligible event, evidence that stays attached, classification rule, destination or owner, delivery timing, and fallback when the normal route fails.

Should every captured event be sent to marketing?

No. Routing should select events that can change a marketing decision or contribute to a meaningful pattern. Sending everything transfers the filtering burden to the recipient and creates noise.

How should failed routes be handled?

Keep failed, unclassified, and unowned signals visible in explicit queues. Record the failure reason, preserve the source, assign a fallback owner, and track the age until the item is resolved or deliberately closed.

How should capture and routing be measured?

Measure capture coverage at the source. Measure classification rate, delivery success, route latency, and unowned backlog separately. One blended completion rate hides the stage that failed.

How does Northstar Stack separate capture from routing?

The Listening Engine captures source evidence, classifies eligible signals, and applies routing rules. The Glass Dashboard shows the source, destination, owner, status, latency, and unresolved queues without requiring a separate strategic layer.