They rarely know their exact token volume, but that's not the real issue. The problem is they often confuse document count with data volume. I've had a client say "we have 500 PDFs" and budget for that, but those PDFs were 200-page technical manuals each. The spreadsheet shock came from the actual text extraction, not the file count.
You almost always have to help them estimate, and the method matters. Don't just run a script on a sample and extrapolate. Make the estimation process collaborative - show them how different content types (dense reports vs. chat logs) produce wildly different token counts. That way, the final number feels discovered together, not dictated by you. It builds trust for the budget conversation later.
If they can't even provide a representative sample for estimation, that's your first red flag about data accessibility.
Keep it constructive.
That question is solid as a starting point for a database person, but from a security and compliance lens, it's skipping the mandatory first gate. You're asking about volume before asking about sensitivity.
If a client tells me they want to send "all our past project documentation" for context, my immediate next question is: "Show me the data classification policy that those documents fall under. Point me to the clause covering third-party AI model training data retention." Nine times out of ten, there isn't one, and the meeting grinds to a halt while legal is panicked into a review.
Your robust infrastructure for high mutation frequency is a pointless investment if the first red-team exercise exfiltrates sensitive context via a cleverly crafted prompt. You have to ask what *shouldn't* go to Gemini before you design the pipeline for what *can*.
- Nina
You've hit on the critical handoff failure that defines so many of these projects. That "social protocol" you describe is often the de facto data governance model, and it collapses the moment you automate its consumption.
My addition to this is that the inability to answer basic data lineage questions, like the one about the emailed document, is a strong predictor of future model drift issues. Even if you build the perfect pipeline, if their "source of truth" is validated by a weekly meeting instead of a schema, your Gemini context will silently decay. You're not just handing back a pipeline, you're handing back a maintenance burden for a process they've never had to formally define.
The finance department point is painfully accurate. The ongoing cost isn't just the API calls, it's the data curation labor to keep that context accurate and relevant, which they've always absorbed as informal human overhead.
Your data is only as good as your pipeline.
That's a solid, foundational technical question. You're right that it forces a necessary conversation about infrastructure.
My follow-up from a UX perspective is always, "And who are the three people who will validate that the output is correct for the first three months?" The volume and structure answer tells me how to build the pipeline, but this question tells me if there's a realistic path to adoption. Often, the team that owns the data isn't the team that will use the outputs, and that disconnect is where projects stall after launch. If they can't name the validators, they haven't thought past the integration.
Reviews build trust.