# What the call transcript sees The CRM holds scoped evidence with uncertainty, and almost none of the public evidence has come from it yet. > By Saad Bin Shafiq, Founder of Nodes ยท Aug 2, 2026 > Canonical: https://www.nodes.inc/blog/what-the-call-transcript-sees --- Nodes' positioning names the three primary Systems of Record in a fixed order: CRM first, HRIS second, ATS third. The stated reason is that call transcripts carry scoped evidence with uncertainty about how a producer actually performs in the field. Almost none of the public evidence Nodes has published backs that ordering. The ramp numbers, the screening study, the funnel analysis: all of it comes from the other two systems. Either the order is wrong, or the evidence has been sitting in the right system the whole time and nobody labeled it that way. It is the second one. ## Three systems, one order a16z's [piece on the System of Intelligence](https://a16z.com/from-system-of-record-to-system-of-intelligence/) used the CRM as its example: an account executive's morning, rebuilt around a ranked feed instead of a database. [Workday is the friend graph](/blog/workday-is-the-friend-graph) carried the same argument into talent and named the same three primary Systems of Record for that domain: the ATS, the HRIS, and the CRM, in that order. Nodes' positioning reverses it, putting the CRM first, ahead of the HRIS and the ATS. The CRM is the one holding calls instead of fields, the actual exchange between a producer and a prospect, word for word, months of it, sitting in a system built to log outcomes rather than preserve conversations. That ordering was a positioning claim, written before the company had a body of production evidence built specifically from CRM data to match it. The 10,765-agent study, the one with the arXiv paper, is built from three inputs and states them plainly: ATS screening data, a behavioral assessment score, and HRIS production outcomes. No CRM. [Your HRIS is the friend graph](/blog/hris-is-the-friend-graph) extended the same pattern to the system HR teams open every morning, and it stayed inside Hire & Develop too. Neither piece drew on a transcript directly. The claim that call transcripts are scoped evidence subject to customer-specific historical validation was true before anyone had proven it, which is a different problem than being wrong. The proof still has to be assembled, and assembling it starts with being specific about what a transcript contains that the rest of the CRM does not. ## What a transcript records that a disposition code cannot A standard CRM activity log after a sales call contains an outcome tag, a duration, and maybe a free-text note a producer typed in the ninety seconds before her next meeting. Call disposed. Follow-up scheduled. Not interested. The record proves a call happened and states what the producer decided it meant. It does not contain what was said. The transcript contains what was said, in the order it was said, including the parts a busy producer would never think to summarize. Where the customer's voice changed when a price came up. Whether the producer let five seconds of silence sit after a hard question, or filled it with a script instead. Whether a required disclosure was read in full or clipped short because she was confident the prospect already knew it. None of that survives translation into a dropdown menu. A disposition code is a producer's summary of her own call, written by the person with the least incentive to notice her own patterns. An intelligence layer reading across CRM, HRIS, and ATS can connect transcript evidence to later governed outcomes such as ramp, retention, or production. [Workday is the friend graph](/blog/workday-is-the-friend-graph) describes that evidence question without proving that transcript behavior caused an individual outcome. The permitted use is to show associations, uncertainty, and supporting records for named-human review without reproducing how a selected producer works. By capturing what a disposition code cannot, the system relies on customer-owned outcome evidence rather than using a selected employee as a template. It never establishes an individual outcome, and a named human always decides. ## Where the argument runs out Extending the friend graph pattern this far runs into a limit the HRIS version did not have. An HRIS record is structured by design: a field for title, a field for pay, a field for tenure. A transcript is not structured at all. It is an hour of speech that has to be turned into something an agent can reason over before any of the above is possible, and the translation step introduces its own error. A transcript that mishears a number, drops a name, or garbles an objection produces a record that looks authoritative and is not. The richer the source, the more damage a bad transcription does downstream, because nobody double checks a field that already looks like ground truth. The second limit is sensitivity, and it cuts a different direction than performance or compensation data does. A candidate record describes one person. A sales call describes two: the producer, and whoever she was talking to. Every transcript carries a customer's voice, their words, sometimes their account number, read out loud and stored indefinitely. The same caution that governs a candidate's personal record has to extend to a customer's, and a customer never applied for anything or signed anything with Nodes, and never agreed to have the call read by a model. Permission has to travel with the recording and cannot be assumed because the CRM already stores the file. None of this is a reason to leave the signal alone. It is a reason the CRM extension of the pattern has to earn its production evidence more carefully than the HRIS extension did. [Your HRIS is the friend graph](/blog/hris-is-the-friend-graph) could point at four years of hiring outcomes the day it published. This piece cannot yet point at four years of transcript-driven sales outcomes measured as their own study. What it can point at is where the transcript's fingerprints already show up in evidence filed under a different name. ## The boundary for transcript evidence Call transcripts can contain a customer's voice, account details, and objections. Raw recordings, transcripts, extracted context, outcomes, and Decision Traces therefore stay inside the customer's single-tenant environment. A customer may approve a PII-stripped weight artifact only after a second verification and only for same-industry learning. Any returned calibration candidate is tested on synthetic data, then run in shadow against the local incumbent. A named human decides whether it is promoted. Transcript evidence has no separate production result yet. For this workflow, the Decision Trace should record the transcript source, recording-permission state, redaction policy, extraction version, evidence used, and named reviewer. That makes a later dispute inspectable without treating the transcript as ground truth. ## The proof that is not there yet The strongest number for this argument is not proof. The 10,765-agent study does not include CRM transcripts; it states its ATS, assessment, and HRIS inputs plainly. The ramp result from the same deployment has no dedicated transcript methodology in what Nodes has published. [Workday is the friend graph](/blog/workday-is-the-friend-graph) therefore cannot establish that selected producers' call behavior caused the outcome. A transcript-specific claim remains Ready for historical validation until that study exists. The honest description of where things stand: the CRM is absent from the registered study, and the ramp result's own public description already reaches for transcript-shaped language it cannot yet back with a methodology. Closing that gap does not need a new metaphor. It needs the CRM added to the fusion model the same way the ATS, the HRIS, and the assessment score were added, with a report on what changes. That study does not exist yet. The methodology behind the evidence that does exist is published: [Decision Traces](https://arxiv.org/abs/2604.19819). The transcript is still absent from the study, even though the language describing the results already talks as if it were there. The next piece of public evidence from this cohort should either add the CRM to the fusion model or stop describing the result as if it already had. The System of Intelligence pattern does not care which System of Record it starts from. It cares whether the layer above it can read all three at once, and whether the evidence keeps pace with the description. CRM first was always the right instinct. It is not a proven one yet. Before any replay, the customer must define recording permission, permitted use, retention, access, redaction, and the outcome against which transcript evidence will be evaluated. ## Sources - [Decision Traces: What Multi-System Data Fusion Reveals About Institutional Knowledge in Enterprise Hiring](https://arxiv.org/abs/2604.19819) - [From System of Record to System of Intelligence](https://a16z.com/from-system-of-record-to-system-of-intelligence/) --- *Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises. Methodology: [Decision Traces](https://arxiv.org/abs/2604.19819).*