Send Conversation Intelligence to HubSpot Without Corrupting Your CRM

The gap for most RevOps teams isn’t better call analysis; it’s CRM-ready call signals, mapped to the right HubSpot properties and delivered reliably via webhooks. The product is the set of deal and contact properties that RevOps can query, filter, and build automations on top of, not the dashboard of call scores and activity summaries. If the signals never reach HubSpot properties, they can’t drive routing, pipeline health reporting, or coaching at scale, regardless of how good the underlying analysis is.

This guide covers the step-by-step RevOps workflow for sending structured conversation intelligence into HubSpot without corrupting the CRM: how to define the property schema, how to set up the webhook delivery, how to wire the transformation and write-back with n8n or Make, and how to prevent duplicate processing from introducing inconsistencies.

Step 1: define the property schema

Before any automation is built, decide which call signals will become HubSpot properties and what type each property should be. The signals worth capturing are the ones that change how deals are managed: buyer-stated facts that affect pipeline stage decisions, risk flags that trigger follow-up automation, and scores that feed into coaching workflows. Properties that nobody queries and no workflow depends on are technical debt rather than enrichment.

For each signal, specify: the property name (what it will be called in HubSpot), the property type (boolean, number, dropdown, or single-line text), the allowed values for dropdown properties, and the update rule. The update rule matters: for most qualification signals, a non-null extracted value should overwrite a null property, but a null extracted value should leave the existing value intact, so the property retains the best evidence from any call in the deal. For time-sensitive signals like the most recently mentioned competitor, the latest value should always win.

Create the custom properties in HubSpot before the automation is built. Deal properties for pipeline signals, such as whether the economic buyer was named or whether a decision timeline was identified, live on the Deal object. Contact properties for buyer-role signals, such as whether a contact was identified as an economic buyer on a specific call, live on the Contact object. The internal property name assigned by HubSpot when the property is created is what the automation will use in the write-back, not the display label.

Step 2: set up extraction with Semarize

Each call signal that will become a HubSpot property needs a corresponding Brick in the extraction schema. A boolean Brick for "economic buyer named" returns true or false against a defined evidence criterion, a score Brick for "discovery quality" returns a number on a defined scale, and a string extraction Brick for "competitor mentioned" returns the competitor name or null. The Brick output type and the HubSpot property type must match: a boolean Brick maps to a boolean property, a score Brick to a number property, and a categorical Brick to a dropdown property with matching options.

The Bricks are grouped into a Kit that is versioned and deployed via the Semarize API. Sending a transcript to the API with the Kit ID returns a JSON object with one typed field per Brick, within a few seconds, ready to be mapped to HubSpot properties without further parsing.

Step 3: wire the webhook and automation layer

The trigger for the automation is a webhook from the call recording platform fired when a transcript becomes available. For Zoom, this is the recording.completed event. For Gong, transcripts are retrieved via the Gong API after a polling trigger. For other recording platforms, the equivalent transcript-ready event should be used.

In Make or n8n, the automation flow is: receive the webhook, extract the transcript text and call metadata, send the transcript to the Semarize API with the Kit ID, receive the typed JSON output, validate each field value, look up the HubSpot deal associated with the call, and write each validated property to the deal record using a HubSpot module.

The deal lookup is the step that requires the most care. The most reliable approach is to embed the HubSpot deal ID in the meeting metadata when the call is scheduled: include it in the meeting subject or a calendar field so the webhook payload already contains it. When that is not possible, an attendee email lookup provides a fallback: match the attendee emails to HubSpot contacts and find the open deal associated with those contacts. The automation must handle the case where no matching deal is found and log it rather than failing silently.

Step 4: validation and idempotency

Before writing to HubSpot, validate each extracted value against the property schema. Check that boolean values are true or false (not string representations), number values are within the declared range, and dropdown values are one of the allowed options. If a value fails validation, skip the write for that property and log the failure. The rest of the call’s properties can still be written.

Idempotency prevents duplicate processing from overwriting valid property values with incorrect ones. If the webhook fires twice for the same call, the second processing run should detect that the extraction has already been written and skip the write rather than overwriting. Storing the call ID and Kit version as a processed-call record, and checking it at the start of each automation run, is the simplest way to implement this without modifying HubSpot property values.

Step 5: measure against properties, not transcript review

Once the pipeline is running, success is measured by whether the HubSpot properties are populated reliably and whether RevOps is using them in reports and automations. Field-level fill rates, what percentage of calls produce a non-null value for each property across deals where the topic is typically discussed, tell you whether the Brick criteria are working as intended. A fill rate below expectations on a core qualification property is a signal that the Brick definition needs tightening, not that the pipeline is failing.

The value of the pipeline is measured not by how often the automation runs successfully but by whether deal progression decisions, coaching conversations, and forecast reviews are grounded in buyer-stated evidence from HubSpot properties rather than rep memory or post-call summaries. The RevOps enrichment playbook covers the schema design decisions and update policies that make a CRM enrichment programme reliable over time.

Common questions