CRM Enrichment From Sales Calls: The RevOps Playbook for Salesforce and HubSpot

CRM enrichment from sales calls sounds straightforward until you try to run it in production. The transcript arrives, the extraction runs, and then the questions start: which fields should be populated, how should null values be handled, what happens when the same deal has three calls with conflicting signals, and who is responsible when the CRM field shows a value that doesn’t match what the rep remembers. Getting the answers right before the pipeline goes live is what separates an enrichment programme that compounds value over time from one that creates a new class of CRM data problems.

This playbook covers the RevOps decisions behind a reliable CRM enrichment pipeline: which fields are worth extracting, how Salesforce and HubSpot field types constrain the schema design, how the extraction-to-write-back flow should be structured, and how to keep the system reliable as the call volume and the evaluation schema evolve.

Which fields are worth enriching from calls

Not every piece of information that could be extracted from a transcript is worth writing to a CRM field. The fields that earn a place in the enrichment schema are the ones that change how deals are managed: they affect pipeline reviews, trigger automation, feed forecasting models, or drive coaching conversations. Fields that nobody queries and no workflow depends on are infrastructure cost without value.

The most reliable enrichment targets are buyer-stated facts with a clear null: whether the economic buyer was named on the call, whether the buyer identified a decision timeline, whether a specific competitor was mentioned, whether a business consequence was described, and whether a next step was committed to with a date. Each of these has a definite yes or no based on transcript content, produces a typed value that maps cleanly to a CRM field, and is relevant to how the deal is managed in the pipeline.

Fields that require interpretation rather than evidence extraction, such as deal sentiment or relationship quality, are harder to score reliably and produce values that managers don’t trust enough to act on. Starting with evidence-grounded fields and expanding the schema once the pipeline is established is more reliable than attempting to capture complex qualitative signals in the first iteration.

Salesforce and HubSpot field types: what constrains the schema

The enrichment schema isn’t designed in isolation from the CRM: the Brick output type and the CRM field type need to match, or the automation layer has to transform the value before writing, which introduces fragility. Designing the three-way alignment between business question, Brick output type, and CRM field type at the start prevents transformation logic from accumulating in the automation layer.

For Salesforce, boolean Bricks map to checkbox fields on the Opportunity object, numeric score Bricks to number fields with a defined range, categorical Bricks to picklist fields whose options match the Brick’s valid values exactly, and string extraction Bricks to text fields. The field API names used in the write-back are the Salesforce field API names, not the field labels, so the schema design should document both the label and the API name for every enriched field.

For HubSpot, the same type mapping applies but the terminology differs. Checkbox properties correspond to boolean Bricks, number properties to numeric score Bricks, dropdown properties to categorical Bricks, and single-line text properties to string extraction Bricks. HubSpot also requires that custom properties be created in the correct object: deal properties for pipeline signals and contact properties for buyer-role fields such as whether a contact was identified as the economic buyer. The write-back uses the HubSpot internal property name, which must be specified when the property is created.

The pipeline structure

The production pipeline has four stages. The first is transcript delivery: a webhook fires after each call is processed by the recording platform, delivering the transcript text to the automation layer. The second is extraction: the automation layer sends the transcript to the Semarize API with the Kit ID and receives a JSON object with one typed field per Brick. The third is validation: each field value is checked against its declared type and expected range before the write-back proceeds. The fourth is the CRM write: the automation looks up the opportunity or deal by the CRM ID associated with the call and writes each validated field to its corresponding CRM field.

The CRM lookup is the step that fails most often in production. The most reliable approach is to embed the CRM opportunity ID in the meeting metadata when the call is scheduled, so the webhook payload already contains the ID when it arrives. For teams that can’t enforce consistent naming conventions in meeting invites, an attendee email lookup provides a fallback: match attendee emails to contacts in the CRM and find the open opportunity associated with those contacts. Both approaches require the automation to handle the case where no matching record is found and log it for review rather than failing silently.

Handling updates and null values

Most deals have more than one call, which means the enrichment pipeline must have a clear policy for updates. The default that works well for most fields is that a non-null extracted value overwrites a null CRM field, and a null extracted value leaves the existing CRM field intact. This means the field retains the best evidence from any call in the deal, rather than being overwritten by a null from a call that didn’t cover the relevant topic.

For fields where the latest call should always win, such as a next-step commitment date or a competitor mentioned most recently, the update policy should be to overwrite regardless of the existing value. Documenting the update policy for each field in the schema prevents inconsistency when the automation is extended or handed over to a different team member.

Keeping the pipeline maintainable

The evaluation schema will change: new qualification criteria get added, old ones are retired, and the vocabulary of the playbook evolves as the team learns more about what predicts deal outcomes. A pipeline that treats the schema as fixed breaks when the schema changes, whereas one that treats it as versioned infrastructure handles changes without breaking downstream systems.

Kit versioning in Semarize handles this by locking the field names, output types, and valid values at a specific version. When the evaluation logic needs to change, a new Kit version is deployed and the old version continues to score any calls processed against it. CRM field mappings that reference a Kit version are not broken by a schema update in a different version, and historical call data retains the scores produced by the version it was evaluated against.

The CRM enrichment structured JSON playbook covers the field mapping patterns for both Salesforce and HubSpot in more technical detail, including the specific object models and API endpoints involved in each write-back step.

CRM enrichment works when RevOps treats call evidence as versioned data infrastructure: a defined set of fields, typed outputs that match Salesforce and HubSpot, explicit update rules, and traceable evidence for every value written back.

Start building →

Common questions