Intent-Based Marketing: A Reliable Workflow for Buyer Signals

Intent-based marketing uses observed or inferred research behavior to prioritize relevant marketing and sales actions. It does not prove that a particular person is ready to buy. A known contact who submits a demo request is different from a company inferred from an IP address visiting a pricing page; a third-party report that a company researched a topic is different again.

A reliable workflow keeps those evidence types distinct, checks each signal before acting, and records why an account qualified. Start by labeling the evidence grain: known-contact activity, inferred company activity, or external company research.

What intent-based marketing is, and what a signal proves

First-party activity is observed on your own properties or recorded through your CRM, such as a form submission or a known contact’s page visit. Third-party topic research is reported by an external provider from activity beyond your properties. Company-level inference associates activity with an organization without identifying the person who performed it.

These distinctions matter in practice. A demo request identifies a contact who took that action. A website visit identified through an IP lookup may indicate that someone at a company visited, but not who. A third-party topic surge can suggest research at the company level, but it does not identify an employee or confirm purchase readiness.

Define a signal contract before building a score

Store each observation as an event, then calculate account summaries separately. One event row should mean one observed action or signal detection, not a changing account score. A daily or weekly account summary should identify its aggregation window and the scoring and taxonomy versions used.

A proposed event record might include signal_id, company_id, contact_id_if_known, source_type, source_vendor, source_event_type, topic, observed_at, received_at, valid_until, taxonomy_version, evidence_reference, and processing_status. These are example fields, not HubSpot’s documented field names. Preserve the original event and its provenance even when an account score changes.

Do not use company ID plus date as a universal event key: a company can have multiple topics or actions on the same day. Prefer the source event ID when available. Otherwise, derive a stable key from the complete event-grain fields. For concurrent processing, enforce uniqueness in the database and use an atomic upsert. A lookup followed by create can allow two workers to insert the same event. HubSpot documents batch CRM object upsert using a unique property, but the integration still needs a suitable key. See the HubSpot batch upsert reference.

Teams defining their data fields, ownership, and CRM operating rules may find CRM systems consulting relevant.

Choose sources and understand their limits

Begin with a small set of observable signals tied to real buying questions: a known-contact demo request, pricing-page activity, or repeated visits to a high-value page. Add external account research when it fills a useful discovery gap, not simply because another data source is available.

HubSpot Buyer Intent can identify companies visiting a website, researching configured topics, or showing other intent signals. Website-based identification requires HubSpot tracking code. HubSpot describes Visitor Intent as IP-based company identification, which can take up to a few hours and identifies a company rather than an individual. Its tracking-code documentation also explains that collection depends on account settings and consent preferences. See HubSpot Buyer Intent setup and its intent and Custom Signals FAQ.

Before enabling a HubSpot feature, check the account’s feature access, permissions, tracking-code coverage, Credit limits, company criteria, and where signals will appear. HubSpot documents that tracking companies and adding companies can consume Credits and require appropriate permissions. It also documents a 30-day signal backfill for newly tracked companies. Custom Signals can research public web sources for configured company cues and may backfill selected-company matches from the previous 90 days; they also consume Credits. Check current product limits and account availability rather than assuming a feature or allowance is universal. See using intent signals, creating Custom Signals, and configuring Buyer Intent limits.

Score for a decision, not false precision

Normalize and check freshness before scoring. Use transparent rules that consider account fit, recency, signal type, and corroboration. The following is a proposed starting gate, not a HubSpot default: do not route an account to sales on a third-party surge alone. Require either one defined high-confidence first-party event or two corroborating signals from different source classes. Test whether that rule suits your sales cycle and data.

Route a known-contact demo request according to the team’s established response process. Route an inferred company signal to account review, a carefully scoped nurture audience, or no action until corroborated. A sales alert should state the evidence type, time observed, relevant page or topic, and the reason the gate fired. Retain the separate events that explain the score.

Build the operating workflow: validate, route, and own exceptions

Use the CRM as the system of record for approved account and contact actions, while preserving source events in an event store or suitable CRM record structure. Before activation, verify how each source actually delivers data. HubSpot documents that intent signals can appear on company or associated contact timelines and can be used in workflows, lists or segments, and lead scoring, subject to access and permissions. For an external provider, verify delivery method, data grain, event IDs, field mapping, authentication, usage rights, and write-back behavior with the provider. Bombora documents Company Surge and a developer portal, but detailed API documentation requires login; the public material does not establish a particular endpoint, schema, or connector. See Bombora Company Surge and its developer portal.

Trigger	Data received	Validation and decision	Destination and fallback
Known-contact demo request	Contact and company IDs, event type, observed time	Check association, freshness, permission, suppression, and duplicate key; route if valid	Create the permitted CRM task or workflow action; marketing operations handles malformed events
Inferred website visit or topic signal	Company ID, source, topic or page, observed time; contact remains empty unless separately known	Resolve company, check source and freshness, then apply corroboration gate	Use an eligible company workflow or review queue; marketing operations resolves ambiguous matches
External account topic surge	Provider event ID if available, company domain, topic, observed and received times	Verify actual delivery, identity, rights, mapping, and uniqueness before CRM write-back	Route qualified accounts to review or nurture; provider-mapping failures go to marketing operations

The practical chain is: receive the event, normalize its fields and timestamps, resolve the company, check permission, freshness, and duplication, apply the deterministic readiness gate, then write the allowed CRM action or send the record to a named exception queue. Assign unresolved identity and malformed records to marketing operations; assign uncertain contact-to-company relationships to sales operations. Set retry rules for transient API or rate-limit failures, and prevent retries from creating duplicate events.

Use AI for bounded interpretation, not authority

AI can help map ambiguous public text to a controlled topic taxonomy or summarize why a signal may match. It is not needed to route a structured demo request, enforce an opt-out, check a timestamp, or reject a duplicate. Keep source evidence distinct from model interpretation.

A proposed output contract for an AI classification step could be one classification result for one source record and one processing run:

{
  "classification_run_id": "run_example_17",
  "source_record_id": "source_example_442",
  "company_domain": "example.com",
  "proposed_topic": "workflow automation",
  "evidence_url": "https://example.com/news",
  "observed_at": "2026-10-11T14:05:00Z",
  "confidence": 0.82,
  "review_required": true
}

This is an illustrative schema, not a HubSpot or provider format. Validate the JSON structure, allowed topic values, URL and timestamp formats, company match, evidence presence, and confidence policy before any CRM update. Reject invalid output or send it to human review; do not silently coerce a guessed value into a controlled field. If the workflow stores prompt or citation observations separately, give each row its own run, prompt, engine, model, locale, and citation identifiers rather than collapsing them into a daily score.

Protect data and measure the pilot

Review the complete data flow: notice, lawful basis, consent where applicable, purpose, retention, vendor terms, sharing, opt-out, deletion, and jurisdiction. A consent banner alone does not establish compliance. HubSpot states that its tools do not replace organization-specific legal advice. Before activation, block records that are suppressed, opted out, outside the permitted purpose, stale, or unresolved. See HubSpot’s guidance on consent banners and tracking-code data collection.

Set a baseline before comparing results. Track qualified meetings, opportunity acceptance, time from qualifying signal to action, sales-rejected reasons, opt-outs, false-positive rate, and unresolved-match rate. Where feasible, compare similar cohorts or response-time treatments. Account for fit, territory, sales capacity, seasonality, and existing relationships; an increase after launch alone does not establish that intent targeting caused it. Choose pilot length and any response target as hypotheses that fit your sales cycle, not universal benchmarks.

A practical starting sequence

1. Choose a few signals tied to actual buying questions and name the owner for each action.
2. Document the event fields, evidence grain, freshness window, unique key, and scoring version.
3. Test sample records end to end, including duplicate replay, unresolved company identity, permission failure, and malformed input.
4. Start with one deterministic gate and one CRM destination. Review routed and rejected accounts with marketing and sales on a regular schedule.
5. Add another source only after its data grain, delivery path, usage rights, and operational owner are understood.

Teams reviewing HubSpot permissions, tracking, and CRM process design can explore HubSpot systems support. Keep the first workflow observable and supportable, then expand only when the team can explain what each signal means and why it triggered an action.