What We Are Building: A Real-Time Sales Copilot That Never Joins the Call
Every conversational intelligence tool a sales team has been sold in the last decade shares one property: it arrives too late. It records the call, transcribes it, scores it, and hands the rep a verdict some hours after the moment that decided the deal has passed. That is a useful thing to own. It is not the thing anyone actually wanted. What a rep wants, at the instant a prospect says "this feels expensive", is the next sentence — not a report, next Tuesday, explaining that the objection was mishandled.
Crack Sales is our attempt at the other product. It listens while the call is happening and puts one line on the screen. This is a plain account of how it is built, what it can and cannot do, and which of the obvious features we decided not to ship.
Three parts, in the order they matter
The system is a Sales Brain, a live copilot, and a post-call loop — and the order is deliberate, because the second one is worthless without the first.
The Sales Brain is the company-specific corpus the copilot speaks from: your value pillars, your qualification framework, the objections your buyers actually raise, the competitors you actually lose to, and the proof you are allowed to cite. It is built with you on a call rather than scraped from a form, because a generic copilot generates generic advice, and generic advice during a live negotiation is worse than silence. It is the reason there is no self-serve signup button on this website.
The live copilot is the part that runs during the meeting. It reads the conversation, decides whether this moment is one where intervening beats staying quiet, and if so shows a single suggestion. One line, replaced in place — not a feed, not a sidebar of scrolling insights. A rep mid-sentence can read one line.
The post-call loop turns the call into a summary, a set of next steps, and structured qualification data, then offers to write it to your CRM. Offers. We will come back to that word, because it is the single design decision we get argued with about most.
No bot joins your meeting
The standard architecture for this category is a recording bot: a participant that dials into the meeting, appears in the attendee list, and streams the audio out. It works, and we rejected it.
Crack Sales is a native desktop application that captures system audio on the machine the rep is already using. Nothing joins the call. There is no extra participant for the prospect to see, no consent-theatre moment at minute zero where a stranger named "Notetaker" appears and everyone pretends not to notice, and no dependency on a meeting platform API. It behaves the same on Zoom, Google Meet, Microsoft Teams, or a phone dialler with a headset, because it is not integrated with any of them — it sits downstream of all of them, at the audio device.
Two consequences follow, and both are load-bearing. The first is that call quality is untouched: we add no participant, no bandwidth, no encoding hop. The second is that we never see video. The screen-capture stream the app opens has its video tracks stopped the moment it is acquired, before a frame is read. This is not a policy we promise to honour — it is a line of code that runs on the rep own machine, and it is why the product cannot do the "reads the buyer body language" trick that competitors advertise. There is no camera feed to read.
It is also why the rep needs headphones. On open speakers the microphone picks up the prospect loudly enough that the system can no longer tell reliably who said what, and a copilot confused about who is talking gives confidently wrong advice. We would rather state the requirement than paper over it.
The latency budget, and the wrong turn we took
A live copilot has exactly one hard constraint: the suggestion has to arrive while it is still true. We set the budget at 1.3 seconds from the end of the prospect sentence to the words being on screen. Past that, the conversation has moved and the advice is about a moment that is over.
The obvious architecture misses that budget badly. It is two hops: the live model transcribes the audio, then a second text model reads the transcript and extracts a signal. We built it, benchmarked it on real speech through the real pipeline, and measured p50 1630ms with p95 1946ms. The second hop alone, timed in isolation across three model tiers, cost between 1367ms and 3008ms. Even the fastest model available blew the entire budget on its own, before any of the rest of the system ran.
What works is one hop. We ask the live model itself for a single terse line in a fixed format and read it straight off its own output transcription. Measured on the same speech, through the same pipeline: p50 84ms, p95 800ms, fastest observed 61ms.
Architecture — p50 — p95 — Within the 1.3s budget
One hop — the live model answers directly — 84 ms — 800 ms — Yes
Two hops — transcribe, then extract — 1630 ms — 1946 ms — No
Roughly twenty times faster, and — this surprised us — the copy is better. A model generating speech natively produces sentences a human can say out loud. A text model asked to extract a signal produces a label, which then has to be turned back into something speakable by yet another step. The fast path and the good path turned out to be the same path.
We publish these numbers because this is the specification most likely to be quoted back at us, and because an earlier version of this website claimed "under 350ms" for months. That figure was never measured. It was written because it sounded right. Removing it is part of why this post exists.
What it actually listens for
Two different mechanisms produce suggestions, and they fail in different ways, which is why we run both.
The first is a set of rules computed locally on the rep machine, from the shape of the conversation rather than its meaning. These cost nothing, cannot hallucinate, and fire identically every time: monologue warnings when the rep has been talking too long, talk-ratio drift, question droughts, price raised before pain was established, value not anchored, a stall left unhandled, a third deferral, no decision-maker identified, no next step agreed, no critical event, no up-front contract. None of that requires understanding the sentence. It requires counting.
The second is the live model, which handles what counting cannot: a price objection versus a timing objection versus a knee-jerk objection, a sentiment drop, an authority gap, a close opportunity, a SPIN sequence stuck at shallow questions, a MEDDIC decision process never established. This is the layer that reads meaning, and it is the layer that can be wrong — so it is grounded in your Sales Brain, and it is never the only thing running.
That is the real vocabulary. It is a deliberately unglamorous list, and it is the complete one.
Four things we decided not to build
This section is longer than it needs to be for marketing purposes, and shorter than the argument we had internally.
We do not analyse video, posture, facial expression or eye movement. As described above, we do not have the data — the video tracks are dropped before a frame is read. Every product claiming to read a buyer body language over a sales call is either recording video the participants were not thinking about when they agreed, or making it up.
We do not build personality profiles of your prospects. No "Analytical Skeptic" label, no voice-tremor readings, no psychological classification of a human being who agreed to a sales call and not to being assessed. The technique is available. We think it is the wrong thing to sell, and a product that will label a buyer will eventually label a rep.
We do not claim to attribute closed deals to the product. A sales copilot cannot run a counterfactual on a deal that has already closed, and every vendor quoting a win-rate uplift is showing you a correlation with a confident face. What we review with you instead comes out of your own call records and is arguable in both directions: must-answer coverage, objections handled versus dropped, talk ratio, question rate. You can check those. That is the point.
And we do not retain raw audio. Once a segment has been processed into transcript and structure, the vocal signal is discarded. What persists is text and structured insight, inside your own tenant.
Why your CRM is not updated automatically
Automatic CRM sync is the feature every buyer asks for, and we do not ship it. Logging a call is a deliberate action a human takes, every time.
The reasoning is narrow. A model summarising a forty-minute negotiation will occasionally be wrong about something material — which stage the deal is in, who the economic buyer is, what was actually committed to. If that summary writes itself into Salesforce unattended, the error stops being a model error and becomes the record. It is now in the forecast, in the pipeline review, in somebody board deck. The cost of an unattended wrong write is not one bad note; it is a bad decision made downstream by someone who had no reason to doubt the CRM.
So the copilot drafts, and the rep approves. It takes a few seconds, and it keeps a human between a probabilistic system and the system of record.
What each CRM can do differs, and we would rather list it than average it.
CRM — Reads contacts and deals — Accepts a logged call — Stage moves and tasks
HubSpot — Yes — Yes — Yes
Salesforce — Yes — Yes — Yes
Zoho CRM — Yes — Yes — No
Attio — Yes — Yes — No
Capsule CRM — Yes — Yes — No
monday CRM — No — connect only — No — No
monday is connect-only, and not because we ran out of time. It has no contact or deal model at all — everything is items on a board, and every API call needs a board id plus the column holding the email address — so there is no workspace-independent way to answer "which record is this prospect". Pretending otherwise would produce silent no-matches on every call, which is worse than an honest gap.
Where it runs
Google Cloud Platform, AES-256 at rest, TLS 1.3 in transit, authentication through Firebase Identity. Each workspace is isolated from every other at the database level rather than in application code — the rules are enforced by the datastore, so an application bug cannot leak across tenants. Within a workspace, a rep owns the calls they recorded and is the only account that can write to them; an admin can read the team calls for coaching but cannot write to a call they did not record. Your conversations are never used to train public or cross-tenant models. Export and deletion are self-serve.
What is real today
The live copilot, the Sales Brain, the post-call summary with human-approved CRM logging, calendar-aware pre-call context, and the analytics drawn from your own call records are all running. The desktop application is Windows today; a macOS build is in platform verification and is not yet available for download. We would rather say that here than let you find it on the downloads page.
If you sell something where the words in a live conversation decide the outcome, the way to find out whether this helps is to run it on your own calls. That is a free 21-day trial, on your real pipeline, with your own reps. It starts after a 15-minute call where we build your Sales Brain with you and agree what carrying on afterwards would cost, so you know the figure before you spend three weeks using the product. No card is collected to start it, and nothing renews on its own at the end.
Home · Product · Pricing · Help centre · Blog · Security · Privacy · Terms