TL;DR — What Changed
- Every sales call now produces one consistent, automated record instead of notes that varied by rep and by day.
- Deal records share the same structure across the team, so leadership can compare call quality using system-produced data.
- The pipeline has run against real production call volume long enough to prove itself, not a pilot that quietly stopped.
Turning Sales Calls Into Scored, CRM-Ready Deal Data
A call analyser pipeline that takes every HubSpot meeting the client’s sales team books and turns it into a transcribed, scored, deal-linked record, hardened through a long stretch of production debugging most case studies don’t mention.
Overview
The client builds AI technology that helps commercial kitchens measure and cut food waste. Its sales team runs a steady volume of calls through HubSpot, which sounds like a solved problem until you look at what actually happened to the content of those calls after they ended. Calls were booked correctly. Nobody was skipping steps in the CRM. What wasn’t happening was getting what was actually said on the call back into a usable, structured record. We built a pipeline that closes that gap automatically, and we’re describing both the build and the debugging that came after it went live, because the debugging is where most of the real engineering time went, and that’s the part most write-ups of a project like this tend to leave out entirely.
The Problem
Deal records depended on reps logging notes after a call ended, which is a well-understood failure mode in sales operations generally, not specific to this client: note-taking after the fact is inconsistent by nature, because it depends on what a rep remembers, how much time has passed since the call, and how much they care about CRM hygiene that day. Some reps write detailed notes; some write “good call, follow up next week”; some forget entirely until a manager asks. None of that is a moral failing on the reps’ part, it’s just what happens when a manual process depends on someone’s discipline holding up across hundreds of calls a month. The consequence for the business was that there was no signal on call quality across the team. A sales leader couldn’t look at the pipeline and see which conversations were actually going well versus which deals were just sitting in a stage because nobody had gotten around to moving them, and coaching conversations with reps ended up relying on the rep’s own account of how a call went rather than anything closer to the source.
Our Solution
We built a call analyser pipeline that runs automatically from HubSpot’s own meeting data, so there’s no separate step for a rep to remember. A meeting gets booked and, once it happens, the pipeline picks up the recording without anyone having to trigger it manually. Transcription converts the call to text. An AI scoring step assesses that transcript against a defined rubric, rather than a generic sentiment score, so the output reflects the specific things that matter for this sales motion rather than a one-size-fits-all measure. The transcript and the score both land on the deal record in HubSpot, which was the design decision that mattered most: we didn’t build a separate dashboard the team would have to remember to check. The call intelligence lives exactly where the rest of the deal data already lives, so a sales leader reviewing a deal sees the call quality signal in the same place as everything else, not in a different tool with a different login.
We also scoped, but deliberately didn’t build in this phase, a revenue cockpit with an AI prospecting agent and a lookalike engine, extending the same call intelligence into prospecting rather than stopping at post-call analysis. We’re stating that as scoped and not built because it’s the honest state of that piece of work: it’s a defined next phase, not a live feature, and describing it as anything more finished would misrepresent what the client actually has today.
Deciding where to draw the line between what we built and what we scoped was itself a judgement call worth explaining. It would have been possible to pitch and build the full cockpit, the prospecting agent and the lookalike engine as one combined engagement from the start. We didn’t, because the call analyser pipeline needed to prove itself against real production call volume before it made sense to build further automation on top of it. Extending an unproven pipeline with more downstream automation compounds any bug in the base layer rather than isolating it, and given what we go on to describe in the deployment section below, that caution turned out to be justified.
How We Deployed It
The initial build worked in testing and then surfaced a string of production problems once it was running against real call volume, which is a normal part of shipping a pipeline that depends on an external transcription step and variable call lengths, not a sign the initial design was wrong. We’re including this because a case study that only describes the finished, working system leaves out the part that actually took the most engineering judgement.
The first class of problem was reliability at the transcription boundary: calls of unusual length, poor audio quality, or unexpected silence at the start or end of a recording occasionally produced a transcript the scoring step couldn’t parse cleanly. Rather than let a single malformed transcript silently fail the whole pipeline for that call, we built retry and fallback handling so a transcript that failed on the first pass got a second attempt, and a call that genuinely couldn’t be processed got flagged for manual review instead of just disappearing from the deal record with no explanation. The trade-off there was complexity against silent failure: it would have been simpler to let a bad call just not produce a score, but a sales leader looking at a deal with no score attached needs to know whether that’s because the call genuinely scored badly-adjacent-to-nothing or because the pipeline quietly dropped it, and those are very different situations.
The second class of problem was scoring consistency. Early on, we found the rubric-based scoring was more sensitive to how a call happened to be structured than to the substance of what was actually discussed, which meant two calls with similar content but different pacing could score noticeably differently. That’s not a useful signal for a sales leader trying to compare rep performance across calls. We iterated on the rubric and the prompting behind the scoring step specifically to reduce that structural sensitivity, testing against a set of calls we’d manually reviewed ourselves so we had a human judgement to check the automated score against, rather than just trusting the model’s output because it looked plausible.
A third, smaller issue came from call length at the extremes. Very short calls, the kind that end in under two minutes because a prospect wasn’t a fit, produced transcripts too thin for the scoring rubric to say anything meaningful, and the early version of the pipeline was still trying to force a full score onto them regardless. We added a minimum-length threshold below which the pipeline flags a call as too short to score meaningfully rather than generating a number that looked precise but wasn’t backed by enough content to justify it. That’s a small design decision, but it matters for the same reason the retry handling matters: a sales leader trusting this data needs every number on the dashboard to mean something, and a fabricated-looking score on a two-minute call would have quietly undermined trust in every other score next to it.
The Outcome
The sales team has one consistent, automated record of every call, rather than a patchwork of notes that varied in quality by rep and by day. Deal records carry the same structure across the whole team, which means sales leadership can compare call quality deal by deal using data the system produces automatically, not data that depends on which rep happened to write good notes that week. We’re stating the outcome as qualitative because that’s what it honestly is: there’s no single locked metric attached to this build the way there is for the sync-remediation work we’ve done elsewhere, and we’d rather say plainly that the change here is in consistency and visibility than attach a number that implies more precision than we actually have.
What we can say with confidence is that the pipeline has been running against real production call volume for long enough to have surfaced and worked through the reliability and scoring-consistency problems described above, and it’s still running. A pipeline that looked good in a demo and then quietly stopped being trusted after two weeks in production would not be something we’d want to put in front of anyone as evidence of what we build. This one held up under exactly the conditions that tend to break a first version: real call lengths, real audio quality, real edge cases nobody thought to test for up front.
Were reps skipping CRM steps before this build?
No. Calls were booked correctly and nobody was skipping steps. What wasn’t happening was getting what was actually said on the call back into a usable, structured record afterward.
How does the call analyser actually work?
It runs automatically from HubSpot’s own meeting data. Once a meeting happens, the pipeline picks up the recording without a rep triggering anything, transcribes it, scores it against a defined rubric, and writes both the transcript and the score onto the deal record in HubSpot itself.
Was a prospecting agent or lookalike engine built as part of this?
No, deliberately not in this phase. Both were scoped but not built, and that’s stated as scoped rather than delivered, not implied as done.
See What This Looks Like for Your Stack
Related: AI Deployment and RevOps Consultancy. More on the team behind this build: About Equanax.