Hi everyone. I’m new to NotebookLM and trying to see if it can help my small team.
We have years of old sales call transcripts (text files and some Google Docs). I want to build a simple, actionable sales playbook from them—like key objections and how we answered them.
Has anyone done something similar? My main questions are:
What’s the best way to feed all those transcripts into NotebookLM? Should I just paste them into one big source?
How do you then ask it to find common patterns? Is it just asking natural questions, or are there specific prompts that work well?
Once you have the insights, what’s the easiest way in NotebookLM to format them into a step-by-step guide for new reps?
I’m on the free plan for now to test it. Any step-by-step tips or pitfalls to avoid would be really appreciated.
?^?
Still learning.
You're on the right track. Don't paste them into one big source. You'll hit context limits. Create separate sources for each transcript, or group them by year or salesperson.
For patterns, start with direct questions. Try prompts like:
"List the top five objections mentioned across all transcripts."
"What is the most common concern about pricing?"
"Extract the exact phrasing used by our team to handle the 'too expensive' objection."
Once you get the raw data, you'll still need to structure it manually. NotebookLM is good at finding the patterns, but you have to build the playbook outline yourself. Ask it to format a single section first to see if the output is usable.
Ask me about hidden egress costs.
That's exactly what I was about to try, glad you posted this. The part about hitting context limits is super helpful, I wouldn't have thought of that.
> Create separate sources for each transcript
I've got maybe 50 files. Is that too many sources, or does it not matter as long as they're grouped logically? Does it slow things down?
Also, can you just ask it to compare across all those sources at once, or do you have to pick them one by one?
That's a smart way to start. Creating separate sources, as user880 suggests, helps you work around the limits on each source's size. Fifty files is fine, especially if you group them logically, like by quarter or by product line.
To answer your question about working across sources, you can select multiple ones in the sources panel before you ask a question. NotebookLM will then pull from all the selected transcripts to find patterns.
A practical next step after grouping your sources is to start with a broad prompt. Instead of just "find objections," you might ask, "From all selected transcripts, what are the three most common obstacles mentioned between the discovery call and the demo?" It helps the tool focus on the specific phase you're trying to improve.
—HR
The multi-select feature is key, but it has a hidden cost. Selecting all fifty sources for every query will burn through your free plan's prompt allowance fast. Be tactical: use all sources for initial broad sweeps, but then filter down to a relevant subset for deeper dives on specific findings.
Beep boop. Show me the data.
Good point about the free plan's limits. Managing fifty sources separately will definitely make each prompt more expensive.
If you're comfortable with a bit of data work, a better pipeline might be: pre-process your text files locally to combine and clean them first, then feed NotebookLM a smaller number of higher-quality sources. For example, you could use a simple script to extract just the dialog, strip headers, and concatenate transcripts from the same year into single documents. This reduces the source count and token count per source, which should stretch your prompts further.
The core suggestion still works: ask natural questions. But feeding the model cleaner, structured text will give you more consistent answers.
Pre-processing locally is the smart move for anyone who can manage it, but it's a higher barrier to entry than most sales teams will tackle. For those who can't, the source grouping advice above is the next best thing.
My caveat on the "cleaner text for consistent answers" point: NotebookLM is surprisingly robust with messy data. Its core function is pulling signal from noise. Spending hours scrubbing perfect transcripts often yields diminishing returns compared to just asking it "Ignore the timestamps and summarize the customer's main concern" in your prompt.
The real efficiency win from cleaning, as you noted, is reducing the token count to stretch your plan.
Everyone's missing a security risk. You're about to feed years of sensitive sales conversations, potentially containing customer PII or deal specifics, into a third-party AI tool.
Before you upload anything:
- Scrub those transcripts. Remove names, companies, emails, specific figures. Use a local script or find/replace.
- Check your company's data policy. This might be a compliance violation.
The technical advice here is fine for the tool's limits, but you're solving the wrong problem first. Lock down your data. Then worry about prompts.
Trust but verify, then don't trust.
The advice you've gotten is mostly right, but it's too abstract. You're on a free plan and need a concrete first step. Don't even open NotebookLM yet.
First, pick five transcripts. Just five. Pick ones where you know the sale was successful.
Manually read them and mark up two things:
1. The exact moment the prospect said "no" or hesitated.
2. The next thing your rep said.
That's your raw data. Paste those two snippets pairs from each call into a single new Google Doc. That's your first NotebookLM source.
Now you have a real, bounded question: "From this source, list the prospect's reason for hesitating and the rep's immediate response. Group similar reasons."
You'll get a usable table in one prompt. That's your first playbook section. It proves the value before you burn cycles on 50 files and hit limits.
Ignore the scaling and data cleaning talk until you know the output is useful. Start small with a defined outcome.
shift left or go home
The advice to start with a five-transcript sample is the most practical thing here. You'll know in ten minutes if NotebookLM can actually pull signal from your specific data. But let me add a cost angle everyone's ignoring.
You said you're on the free plan. That's the right move, but treat it like a sandbox. The moment you start selecting "all sources" for broad pattern searches, you'll burn through your allowance on what's essentially exploratory data analysis - something you could do 80% as well with a local text search tool for zero cost. The real value is in the synthesis, not the search. Use the free prompts to ask "group these five objection-response pairs into themes" not "find all objections in 50 files."
If the synthesis works, then you've got a business case: paying for the tool might be cheaper than a junior sales ops person manually reading everything. But validate the synthesis quality first on a tiny sample. I've seen these tools invent convincing-sounding objections that never actually came up in the transcripts.
Your k8s cluster is 40% idle.
Absolutely, starting with the five-transcript sample is the most pragmatic first move. It instantly flips the project from overwhelming to actionable. I'd just add one tactical tweak based on my own tinkering: when you create that Google Doc with the objection-response pairs, structure it with a simple visual cue. For each pair, I do something like "OBJECTION: [the exact quote]" and then on the next line "OUR REPLY: [the response]". This little bit of formatting seems to help NotebookLM recognize the pattern immediately, making those first prompts like "group similar reasons" even more accurate right out of the gate. It shaves off a few of those precious free prompts for more interesting synthesis work later.
hugo
Formatting helps, but you're still manually labeling what's an objection and what's a reply. If you've already done that work by reading and tagging, you've done the hard part. At that point, you're just using the AI as a slightly fancier pivot table.
The real test is whether the tool can identify those pairs from raw, unlabeled transcripts. That's where the ROI might be. If it can't, all this structuring is just busywork for you, not intelligence from the tool.
trust but verify
Great questions, and you've already gotten a ton of solid tactical advice. I'll tackle your last one about formatting the insights into a guide. NotebookLM isn't great at spitting out a formatted doc for you, but it's excellent at generating the structured content. My method is to use it as a co-writer.
I'll ask it something like: "Using the objection-response themes we identified, draft a step-by-step guide for a new rep. Structure it with a clear header for each common objection, followed by a 'Best Response' subsection and a 'Key Principle' subsection." Then I copy that output into a real document editor to polish. It gets you 80% there, and you're not fighting with the tool's limited formatting options.
One pitfall on the free plan: doing this in multiple, iterative prompts (like asking for headers, then content, then principles) will cost you. Try to get the full skeletal draft in one prompt by describing the entire structure you want in your initial request.
Architect first, buy later
The point about structuring the output manually is crucial and gets missed in a lot of these "AI does everything" demos. I'd add that after you "ask it to format a single section first," you should immediately pressure-test the result for hallucinations. NotebookLM will sometimes generate plausible-sounding but entirely fabricated objections or responses if the data is ambiguous.
Take that first output and cross-reference it with the original transcript snippets. If even 10% of a "common objection" it found isn't actually in your source, you'll know your prompts need to be more constrained, like asking for direct quotes instead of paraphrases, before you scale up.
Measure twice, cut once.
That pressure-testing step is critical. I've seen similar hallucinations when using other tools to analyze logs or incident reports. Asking for direct quotes is a solid mitigation.
One more layer: even with quotes, the context can get stripped. A quote like "I need to check with legal" could be a genuine blocker or just a polite deflection. The model might group them together as one "objection," but the playbook response would be totally different.
Sometimes you need to go back and tag the surrounding context in your source doc, maybe with a [CONTEXT: ...] line before the objection. It's more manual upfront, but it trains the model on what actually matters.