Every revenue team is asking the same question right now:
“We have thousands of call recordings, years of email threads, a CRM full of deal history. Why don't we just point Claude at them and extract the insights ourselves?”
We sat down with Octave’s technical team to understand why not. What makes Claude, RAG, call recorders like Gong, and DIY solutions get it so wrong?
Here’s a preview of 8 things under the hood of Octave that are most difficult to build.
Lost revenue and untrained reps: the cost of not knowing what "good" looks like
Gong might give a sales call an “A” grade because customer sentiment, talk time, and question counts look good.
But actually, the call was a miss. The rep failed to bring up the standard kill-shot for a common objection. Or they showed a financial services case study to a healthcare buyer.
This happens because Gong doesn't know what “good” really looks like in your GTM.
Call recorder software often offers just a text box to describe your company. That can't possibly capture all the good answers to all the objections by all the personas!
Another problem: Tools also tend to look for what they know.
Imagine you ask Claude to find objections in your last 20 call transcripts. It may skew toward finding pricing objections, but you might not realize that customers are describing security concerns with phrases you don’t realize you should scan for. If security objections are what’s actually killing your deals, you may never find out.
Octave solves these problems with catch-all annotations and a library that holds what “good” looks like. Let's take a look at the toughest things to build, ranging from “annoyance” to “technical hornet’s nest.”
Integration maintenance
Ingesting source material: Medium difficulty
It’s not technically difficult, but do you really want to maintain integrations with Fathom, Gong, Salesforce, HubSpot, Notion, Google, Linear, Snowflake, Databricks, GitHub, and more?
True intelligence means pulling from many customer-interaction sources, including meetings, emails (sent/replies), CRM changes (opportunities created, deals won, deals lost), LinkedIn messages, ads, and product telemetry from your data warehouse.
This means staying on top of the format of data coming in, and standardizing the messy upstream inputs into something that your downstream engines can process consistently.
They break constantly, because vendors change their data schemas and API’s deprecate. It takes a lot of opinions, testing, and seeing it break a lot.
Customer interactions are just one half of the equation. The other half is "what good looks like" for your GTM.
To get this, Octave also indexes (and refreshes) resources like your website, Notion, Google Drive, Linear, and GitHub. More integrations to maintain!
Filtering irrelevant convos
Scenario understanding: Medium-to-hard difficulty
A transcript arrives. Is this a sales call or a support escalation? A prospect or an existing customer? Net new or upsell? Which product?
People assume that they can figure this out by attaching transcripts to an opportunity in your CRM. But in practice, CRMs are rarely clean enough to support this.
Octave has strong logic to detect what’s what. For example, we filter out internal calls, or if someone on a call mentions a certain phrase, we drop it. We're a "bouncer" that turns away conversations that aren't eligible for analysis.
We created this logic by hand-building it over time. Half of that comes from our time spent in the narrow domain specialty of B2B GTM, and half comes from referencing your company’s Octave library to increase the bouncer’s comprehension. Your GTM ontology is like giving the bouncer glasses with the right prescription to see clearly.
Resolving speaker identities
Speaker attribution: Medium difficulty
If you know that a speaker's title is CMO, you can start detecting patterns across all CMO’s. If you know their company too, then you can start saying, “executives at companies with over $100M in funding tend to worry about X.”
But if your call transcript only gives you the speaker’s name or email, how do you know which Mary at Microsoft is mary@microsoft.com?
Octave maintains a database of people and companies to quickly resolve identities. This includes firmographic and funding data, which helps match companies to segments. This isn’t super challenging to build, but the data expense can add up, and making mistakes can poison your intelligence.
Call annotation
Annotating findings: Extremely difficult
We tag every conversation with extracted findings and match them to entities in your library.
Octave casts a wide net to annotate snippets. We maintain a quickly growing set of over 150 extraction types to label meaningful snippets.
We tag findings in your transcripts with rich information like the speaker, their email, a persona ID, a company domain, the segment IDs, deal outcome, opportunity ID (like HubSpot ID), an event ID (for example, a specific call), sentiment, window of the call, entity IDs (if the snippet is about a competitor, use case, objection, etc), and more.
Your Octave library of specific personas, use cases, and product information informs the extractors on what to look for. That's what makes it accurate, and what lets you query for patterns later.
What's missing from Claude DIY versions, and Gong-type tools, is that knowledge of your GTM strategy.
When you have such rich annotation on transcript findings, you can ask so many more questions!
- Find all the objections on our deal with Acme Co.
- Find everything that CTOs and CISOs say about security reviews
- Find anything related to switching costs and rip-and-replace, organized by size of company talking about it
- Figure out why customers switched away from Competitor A to us, divided by persona
And what happens when you add a persona (or another strategy change)?
Don’t you want to go back and re-label yesterday's calls to understand them in a new light?
Transcript updates
Updating call transcript annotations: Difficult
Octave updates transcript annotations automatically when you make a change to your Octave library, retroactively extracting new intelligence you didn't get from originally processing the transcript.
If you add a new competitor to your strategy, or launch a new product use case, you would need to manually re-run all the transcript processing if you were doing this in Claude alone.
Context graph
GTM ontology (Octave Library): Medium difficulty
Creating a library of your GTM strategy (or type 2 context) is not a technically difficult task. But the way it's built is more than just a Karpathy wiki context graph. It's opinionated, which leads to better answers.
Your DIY context should know:
- What counts as a persona, and what doesn’t?
- What are its edges?
- Why is this persona subordinate to that segment, but not another?
- How do you know when your product feature “solves” a common problem for that persona — versus just “relates” to it?
We’ve baked years of our accumulated judgment into these opinions.
Reality vs. strategy
Reconciling call insights with Library: Difficult
Octave’s secret sauce is that it constantly compares your library with the real conversations that are happening. Your library is like your hypothesis of what your GTM strategy should be, while the conversations are reality. Octave is always checking one against the other.
If you're talking to a CISO and they complain about regulations, then Octave will check the library's CISO persona, look at the Pains section, and see that the regulation complaint is already there.
It'll link the real transcript snippet with the library entities for the relevant Pain, CISO persona, and also the segment their company is in. It'll also link the closest match entities so that you can keep an eye on whether that Pain belongs on a different persona, too.
But if the regulation pain is not in your Library yet, it'll go into a holding pen. If more CISOs say the same thing, that holding pen will accumulate more and more evidence that CISO's really suffer from this. It can create a suggestion to update your library. You now have a new definition of what good looks like: sales reps and marketing material that speak to the regulation pain.
It's a challenge to build and maintain these thresholds, especially because Octave's thresholds are "smart." They're higher or lower depending on your company's unique situation, like call volume.
Orchestration
Connective tissue: Extremely difficult
You not only need to build the machines we've mentioned. You have to keep them running together.
And keeping up with the volume is tough to DIY. Hundreds or thousands of findings stream in from the 10 calls your sales reps had in the last 15 minutes alone. Octave is annotating them, attributing them to speakers, and then checking them against the library.
If a finding exists, it’s linking to the entity, and if it doesn’t, it’s putting the finding into a holding pen. Batch jobs are deciding whether the accumulating evidence would warrant a suggested update to the library to fill in that gap. But while that's decision’s being made, five more calls come in — and their findings are either strengthening the case, or they're not.
So what do you do about the suggestion? Do you have look-back windows to help with that decision making?
Then imagine that you update an entity in your library. Your competitor announces a new feature, so you add it to that competitor's entity in your Octave library. This change cascades to all the other entities it touches — personas, playbooks, use cases, pains, and more.
There’s a Cambrian explosion of relationships to maintain. One deal in your CRM is attached to the findings database through every annotated snippet from calls and emails with that company. It’s also attached to a database of library entities (segment, personas, use cases, objections they raised, etc). And it's attached to the identity resolution database. And holding pens for potential suggestions.
To complicate things, a deal is also attached to the outside world: the market that company plays in.
Octave pulls in news about your market and competitors from the great world wide web, and has a different set of databases for potential suggested updates to your library based on outside information.
To summarize, Octave is built on two context streams:
- Internal stream: everything your business generates, like calls, emails, deals, documents, etc.
- External stream: news from the market, competitors, customers, their markets, industry shifts, micro and macro trends, etc.
The learning loops for each of these are constantly checking against your library: does your GTM's hypothesis hold up to reality? How might it need to change? Are your reps executing what "good" looks like?
Then, every accepted suggestion to update the library updates what the extractors look for in your call intelligence. The next calls are read more sharply, and all the calls that came before it.
Nothing in the graph is static, and that’s the machine you’d be signing up to build.
Bonus: Time
Don't forget our 4 years of edge cases solved
Not to be too cheeky, but the hardest thing to replicate isn't even on this list. It's the years of brain cells dedicated to ironing out accurate labels and entity relationships specific to the B2B GTM ecosystem.
Our team has been — and we say this with affection — unreasonably tenacious at whack-a-mole’ing edge cases over the last 4 years. You have to build something, wait for a deal that breaks it, design new logic, wait for more deals to confirm or break those decisions, and repeat.
You can’t compress years of iteration cycles.
This is just a peek of what’s under the hood of Octave. If you have questions for our technical team, please get in touch — we love hearing how people have been figuring out DIY!
