Verified against Gemini in Sheets · 2026-08-04
Turn a raw Google Sheet into a plain-English insight brief
A prompt that uses Gemini's @Sheets mention to analyze real spreadsheet data in place and return a structured insight brief with actual numbers attached, instead of a vague 'looks fine' summary that never grounds itself in the specific rows and columns.
The prompt
Ready to copy — highlighted parts are example details you can swap.
@Sheets the "Q3 Support Tickets" sheet in the Customer Ops folder Analyze the data in this sheet, specifically the "Raw Tickets" tab, columns A through H. QUESTIONS TO ANSWER Which ticket category is growing fastest month over month, and is response time correlated with ticket category? INSTRUCTIONS 1. State how many rows/columns you actually read, so I know if you saw the whole sheet or just a preview — this matters because a sheet with more rows than a preview shows can silently produce a 'complete' analysis that's actually based on the first page only. 2. Identify the 3 most significant trends or outliers, referencing exact column names and row ranges — not just "some values look high." A finding I can't check against the actual sheet isn't useful to me. 3. Flag any data quality issues you notice — blank cells, inconsistent formats, likely typos — before drawing conclusions from that data. A trend built partly on bad data needs that caveat attached, not silently absorbed into a clean-sounding number. 4. For each finding, state the actual numbers behind it, not just a qualitative claim. 5. End with 3 concrete next actions someone could take from this data, each tied to a specific finding above, not a generic action that any dataset like this could produce. Don't invent a trend from too few data points. If a pattern is based on fewer than 20 rows, label it explicitly as low-confidence rather than presenting it with the same certainty as a pattern backed by hundreds of rows. CORRELATION VS. CAUSATION If you report that two columns move together, say plainly that this is a correlation observed in this data, not a stated cause, unless the sheet itself contains information that supports a causal claim (an explicit before/after change with a documented cause). Don't let a correlation read as an explanation just because it makes for a cleaner-sounding insight. IF A FORMULA COLUMN LOOKS BROKEN If a column that appears to be a calculated field (a ratio, a running total, a percentage) contains values that don't seem to follow from the other columns in the same row, flag it as a possible formula or data error rather than incorporating those values into a trend as if they were reliable. SEASONALITY AND ONE-OFF SPIKES Before calling something a trend, check whether it might instead be a one-time spike or a seasonal pattern that recurs every year around the same period — if the sheet has enough history to check, say whether a similar spike happened at the same point in a prior period, since that changes whether this is a new development worth acting on or a predictable annual pattern.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
The @Sheets mention lets Gemini read live cell values rather than working from a description or a partial screenshot, so requiring it to state how many rows it actually read is a direct check against silent truncation on large sheets, which is the most common way a 'complete' analysis is actually based on the first visible page rather than the whole dataset it appears to have analyzed. Requiring exact numbers instead of qualitative claims — 'some values look high' — forces every finding to be independently checkable against the sheet rather than taken on faith, which matters because a brief someone acts on should be verifiable in thirty seconds by opening the sheet and looking at the referenced range. The data-quality-flagging instruction exists because a trend computed over a column with a dozen blank cells or inconsistent date formats can look statistically clean in the output while actually resting on data that wasn't cleaned first, and surfacing that caveat is the difference between a brief someone can act on and one that quietly launders a data problem into a confident-sounding conclusion. The minimum_sample_size rule specifically counters a well-documented tendency to describe a pattern found in a handful of rows with the same confidence as one backed by hundreds — labeling thin evidence as low-confidence keeps the brief honest about what the data actually supports, rather than flattening every finding into the same tone of certainty regardless of how much data actually backs it. The correlation-versus-causation instruction matters because a model summarizing a spreadsheet has a natural pull toward the more satisfying, story-shaped version of a finding — 'response time drives category growth' reads better than 'these two columns happen to move together' — and without an explicit instruction to hold the line at correlation unless the sheet itself supports a causal claim, an insight brief can quietly overstate what two moving numbers actually prove about each other. Flagging a calculated column whose values don't follow from the raw columns in the same row catches a specific and quietly common spreadsheet problem: a formula that broke after a row insertion, or a percentage column computed against the wrong denominator, produces numbers that look like ordinary data and will feed silently into any trend built on top of them unless something actively checks the internal arithmetic rather than just reading the numbers as given.
What you get back
Read 342 rows across 8 columns (full sheet, no truncation). Trend 1: "Billing" tickets grew from 34/month (July) to 61/month (Sept) — a clear upward trend, high confidence (n=95 rows). Trend 2: Average response time for "Bug Report" tickets (14.2 hrs) is roughly double every other category (avg 7.1 hrs) — worth investigating triage routing. Data quality: 11 rows have blank "Category" values — excluded from category-level trends above. Recommendation 1: Investigate why Billing ticket volume nearly doubled — check for a pricing or invoicing change in August.
Verified against
Gemini in Sheets Gemini 3 Pro · 2026-08-04
Changelog
- 2026-08-04 — Initial publish, verified against Gemini in Sheets on Gemini 3 Pro.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
