Turn Sales Call Transcripts Into CRM-Ready JSON: Schema, Extraction, Validation, and Scoring
A sales call transcript is unstructured data. A CRM opportunity record requires structured data: typed fields with specific names, specific value types, and specific ranges. The gap between the two is where most conversation intelligence programmes break down. Either the transcript stays in the recording platform and never reaches the CRM, or someone manually extracts notes and enters them into fields after the call, or an AI summary is pasted into a text field that nobody queries. None of these moves the transcript into a form the CRM can reason about.
The workflow that closes this gap has four steps: schema design, extraction, validation, and downstream delivery. Getting each step right produces a pipeline where every call becomes a structured update to the right CRM fields, automatically, without rep data entry or manual review.
Step 1: define the schema
The schema is the set of fields the pipeline will extract from each call and write to the CRM. Designing it requires answering a specific question about each proposed field: is this information something a buyer would say explicitly, or something a rep would interpret from context? The first category, explicit buyer statements, is evaluable from transcript content reliably. The second requires the model to infer, which introduces variance.
Fields that work well as transcript-extractable schema elements include: whether the buyer described a specific business problem with a consequence, whether a named competitor was mentioned, whether the buyer identified a decision timeline, whether the economic buyer was named, whether a specific next step was committed to with a date. Each of these has clear evidence in the transcript when it is present and a reliable null when it is not.
In Semarize, each schema element is a Brick with a declared output type. A boolean Brick for “competitor mentioned” and a string Brick for “competitor name” map cleanly to a checkbox field and a text field in Salesforce. A numeric score Brick for “discovery quality” maps to a number field. The schema design step is essentially mapping from business question to Brick type to CRM field type: the three-way alignment determines whether the extracted value can be written to the CRM field without transformation.
Step 2: extraction
Extraction is the step where the transcript text is evaluated against the schema and a typed value is produced for each field. The transcript arrives via webhook from the recording source, whether Zoom, Teams, Gong, Fathom, or any platform that delivers transcript text, and is sent to the Semarize API with the Kit ID. The Kit evaluates every Brick in the schema against the transcript content and returns a JSON object with one typed field per Brick. The response comes back within a few seconds and requires no further parsing: each field is already typed and named to match the downstream CRM field.
A well-designed extraction step produces output with high field presence rates: most fields have a non-null value on most calls where the relevant evidence is present, and null values appear only on calls where the evidence genuinely was not there. Measuring field presence rates on a sample of real calls before deploying to production is the quality check that confirms the Brick criteria are specific enough to find evidence when it exists.
Step 3: validation
Validation confirms that the extracted values are within expected ranges and of the correct types before writing them to the CRM. For a score field defined as a number between one and five, a validation step checks that the returned value is in that range. For a categorical field with defined options, validation checks that the returned value is one of the allowed categories. For boolean fields, validation confirms the value is true or false rather than a string representation.
In most well-designed pipelines, validation failures are rare and indicate either a Brick definition edge case or an unusually structured transcript. When they occur, the automation logs the failure and skips the CRM write for the affected field rather than writing an invalid value. This prevents corrupt data from entering the CRM while preserving the successful fields from the same call.
Step 4: downstream delivery
The final step writes the validated extracted fields to the CRM opportunity record. The automation looks up the opportunity by the CRM ID associated with the call, confirms the record exists and is in the right stage to receive an update, and writes each field value to its corresponding CRM field. For Salesforce, this is a PATCH to the Opportunity object using the field API names. For HubSpot, it is a PATCH to the Deal object using the property names.
Beyond CRM enrichment, the same extracted JSON can be routed to a warehouse table for BI analytics, a coaching dashboard for manager review, and an alerting system for specific threshold triggers: for example, a notification when a competitor is mentioned on a deal in the final stage, or when a deal’s discovery quality score falls below a defined threshold across three consecutive calls. The CRM enrichment playbook covers the field mapping patterns for both Salesforce and HubSpot in detail.
Applicable to any call source
The pipeline works with transcript text from any source. Teams using Zoom get transcripts via the Zoom API after each recording. Teams using Gong can retrieve transcripts via the Gong API. Teams using Fathom, Fireflies, or any other meeting recorder get transcripts via those platforms’ APIs or webhooks. Teams that have existing transcript archives can process them in bulk via the Semarize batch endpoint for historical backfill during onboarding.
The schema defined in the Kit is independent of the source: the same discovery Kit applied to a Zoom transcript and a Gong transcript of the same call evaluates the same criteria and returns the same field types. This source independence is what allows the pipeline to work across a team that uses different recording platforms for different call types without requiring separate schema definitions or extraction pipelines per source.
Semarize turns raw transcript text into typed JSON ready for CRM enrichment, from any call source, against a schema you define.
Common questions
How do we link the extracted fields to the right CRM opportunity?
The most reliable approach is to embed the CRM opportunity ID in the meeting metadata when the call is scheduled: include it in the meeting subject or a custom calendar field. When the transcript webhook fires, the automation reads the opportunity ID from the meeting metadata and uses it directly for the CRM lookup. For teams without a consistent naming convention, an attendee email lookup provides a fallback: match the attendee emails to contacts in the CRM and find the associated open opportunity.
What CRM field types map well to Brick output types?
Boolean Bricks map to checkbox fields. Numeric score Bricks map to number fields, with the scale defined to match the CRM field’s accepted range. Categorical Bricks map to picklist fields, with the Brick’s valid values matching the picklist options. String extraction Bricks map to text fields. Designing the Brick output types and the CRM field types to match during the schema design step avoids transformation logic in the automation layer.
How do we handle a call that produces low-confidence extraction on key fields?
A Brick that cannot find sufficient evidence for a criterion in the transcript returns a null rather than guessing. A null value on a key field is informative: it typically means the topic was not discussed on this call. The automation writes the null to the CRM field only if it should override a previously scored value, and otherwise leaves the existing field value intact. This means the CRM field retains the best evidence from any call in the deal rather than being overwritten by a null from a call that did not cover that topic.
Continue reading
Read more from Semarize
CRM Enrichment From Sales Calls: The RevOps Data Ops Playbook
Most CRM enrichment stalls at 30% field coverage because the output is unstructured - reps updating from memory, summaries stored as notes. The fix is a structured extraction pipeline: transcript to consistent fields to CRM to automation triggers. This playbook covers the schema, the routing, and the implementation in Salesforce and HubSpot.
Gong Captures the Transcript. Here’s What It Can’t Score.
Gong’s scoring runs against a fixed model — you can’t attach your product documentation, rate card, or qualification playbook to its evaluation layer. For four evaluations that matter — product accuracy, pricing audit, methodology A/B testing, and deal readiness scoring — knowledge grounding and KB isolation are the only architecture that works.
Conversation Data Warehouse: Consistent Call Fields for BI
BI teams can't query transcripts. They can't join AI summaries to CRM objects. To make conversation data useful for analytics, it needs to arrive as consistent typed fields - booleans, scores, text fields, lists - with join keys that connect calls to opportunities, accounts, and contacts. This is the pipeline, the schema, and the governance model that makes sales call analytics possible in your warehouse.