RAG over our sales-call transcripts: a 3-day build that stuck

I built it on a Friday. By Wednesday everyone on the team was using it. By the following Monday, it had changed how we ran our discovery calls.

The problem

Six months of Zoom recordings. Transcripts in Notion, but ungrep-able. Every time a prospect said something like "Base44 won't let me export my AWS keys," we wanted to know how often we'd heard that before, what we'd said in response, and whether the prospect had signed.

The naive build (day 1)

pgvector in our existing Postgres. Embeddings from text-embedding-3-small. One row per transcript, chunked at 800 tokens with 200 overlap. UI was a single search box.

Worked for two queries. Then we hit the recall problem: a prospect's pain point was on line 240 of an 800-line transcript, and the chunk containing it didn't have enough surrounding context for the embedding to score well.

The actual build (days 2-3)

Three changes that fixed it.

• Chunk size dropped to 250 tokens with 100 overlap — five times more rows, much better recall
• Each chunk got speaker metadata as a filter — "find me what we said" vs "find me what they said"
• Each chunk got an outcome metadata field — "signed", "ghosted", "passed" — so we could filter by what actually converted

The metadata was 80% of the value

The embeddings did the rough sort. The metadata filters did the precision. Most queries the team runs now look like: "what did we say about AWS access when the prospect was a Base44 user and they signed?"

That's not really RAG. That's a structured filter with embedding-assisted ranking. We could have built half of this with a `WHERE` clause and `tsvector`.

What we use it for now

• Pre-call: search prior conversations with similar prospects, pull the patterns that converted
• Post-call: tag new transcripts with outcome and pain points so they're useful to the next person
• Quarterly: aggregate the top objections, write essays about them — this is one