Introduction
Claude can run a full cross-tab analysis: compare a survey outcome across segments, and flag any comparison too thin on data to trust before reporting it. The engineered prompt excludes non-numeric or missing values explicitly, rather than letting a tool's default handling decide by accident, and recomputes every number through a genuinely different method before reporting it. This guide runs the same request two ways on identical data, plain against engineered. The gap isn't one version being wrong: the same blind spot, a non-numeric marker sitting inside a column that looks purely numeric, turned out harmless down one reasonable analytical path and silently wrong down another. Whether a plain prompt gets this right depends on which of several equally natural approaches gets taken, not on the prompt itself. Code execution needs to be on for the verification step to run.
What is a cross-tab
A cross-tab (cross-tabulation) is a table that breaks a survey result down by group instead of reporting one overall number for everyone. If 60% of respondents rate something highly, a cross-tab answers the next question: is that true across the board, or is it 80% for one group and 40% for another?
It's the standard tool for turning a single average into something actionable, and it's the most common analysis request in survey work..
When should you use a cross-tab
Use a cross-tab when the real question is "did different groups say different things," not "what did people say overall." Three common triggers:
- A stakeholder asks whether a result holds for a specific segment, like enterprise customers
- A metric needs to be compared across plan tiers or company sizes
- A topline number feels like it's hiding something once you consider who's behind it
What's the difference between attribute-based and open-text cross-tabs?
Attribute-based cross-tabs compare a variable you already have, like a rating, plan tier, or yes/no response, across segments. This is what most cross-tab requests actually are, and it's what this guide covers.
Open-text cross-tabs start from open-ended responses. Before you can cross-tab something like "what's your biggest frustration," you first have to read the responses and sort them into themes, a separate and more involved prompt covered in the advanced version of this guide.
A note on the data: the example below runs on a synthetic dataset of 300 fabricated survey responses about AI use in the workplace, built specifically to demonstrate the prompt. It is not real Sprig customer or employee data and does not reflect actual workplace AI adoption trends.
The Study We Built for This Guide
We surveyed 300 respondents about AI use at work, asking how productive they feel using AI tools, whether their organization encourages that use, and whether they've received adequate training, each on a 1-to-5 agreement scale. We split the sample by whether the respondent's company has a formal policy governing AI use: yes, no, or not sure.
Ours is synthetic, built from scratch for this guide. If your own survey data already lives in Sprig, getting it in front of Claude doesn't need an export step: Sprig MCP connects your surveys and responses directly, so the analysis runs on current data rather than a CSV you pulled earlier.
Claude can run this analysis two very different ways, and that gap is what the rest of this guide is actually about. Ask plainly, attach the data, and you'll get something back in seconds: a table, a comparison, an answer that looks complete. Engineer the prompt instead, and you'll get something that takes longer to produce and checks its own work along the way. Both count as "Claude ran a cross-tab." What differs is whether you'd know, either way, if the answer was wrong.
What a Plain Prompt Gets You
We gave Claude nothing but the data and a plain question, the way most people actually ask for this:
I have survey results about AI use at work. The data's attached. Can you run a cross-tabs analysis and tell me whether productivity, feeling encouraged to use AI, and feeling adequately trained differ depending on whether a company has a formal AI policy?
The first attempt failed before producing anything at all. Two of the three columns Claude needed, productivity and org encouragement, contain the literal text "SKIPPED" mixed in with numeric ratings, for respondents who'd said they never use AI at work in the first place. Averaging that column the obvious way threw a type error immediately. The reflexive fix for that specific error, converting anything unparseable into a missing value, happened to be the statistically correct move here: it excluded exactly the respondents who had no rating to average, and produced the right numbers. Productivity, org encouragement, and training adequacy all came back matching what the engineered prompt below also finds.
We didn't take that on faith from one run. A second, independent attempt, standard-library Python instead of pandas, took "cross-tab" at its more literal meaning: a frequency table instead of a means comparison. That table doesn't error either. "SKIPPED" just sits in it as if it were a sixth response option, next to 1 through 5. Turning that table into an actual answer means computing a percentage, and the natural way to do that, respondents who rated 4 or 5 divided by everyone in that group, silently counts the never-used-AI respondents in the denominator. Across the two outcomes affected by this, that understates real agreement by 7.5 to 17.5 percentage points, in the same direction every time. Training adequacy, which has no "SKIPPED" values at all, shows almost no gap under the identical calculation, which is the tell: the distortion tracks the specific quirk, not the method of computing a percentage in general.
Neither run told the same story twice, exactly. What replicated wasn't one wrong number reproduced, and it wasn't even two different wrong numbers from the same cause. It was something more specific: the exact same blind spot, not knowing this column has a valid non-numeric value sitting in it, was completely harmless down one reasonable path and silently wrong by double digits down another. Whether a plain prompt gets this right isn't really about the prompt. It's about which of several equally natural paths Claude happens to take on a given run, and nothing about a clean-looking answer tells you which one you got.
What an Engineered Prompt Gets You
Here's the prompt. Copy it as written, and swap in your own column names where indicated.
I have a survey dataset with a categorical or rating-scale outcome question and one or more segment/attribute variables (for example, plan tier, company size, department, or customer segment). I want to run a cross-tab analysis.
What this prompt does:
- Compares [OUTCOME VARIABLE] across the segments you specify
- Checks whether any segment has enough respondents to draw a real conclusion from
What it returns:
- A table of counts and percentages (or means, for rating-scale questions), broken out by segment
- A list of any segment comparisons that don't have enough data to trust
- A plain-language summary of the differences worth paying attention to
- A saved image of the table you can download and reuse
Please:
1. Cross-tab [OUTCOME VARIABLE] against [SEGMENT VARIABLE(S)]. These are column headers from your data file, exactly as they appear in the header row, like `plan_tier` or `nps_score`. They are not spreadsheet cell references or column letters, like "C" or "G2". For a categorical outcome, show counts and row percentages. For a rating-scale or numeric outcome, show the mean and the full distribution across scale points.
2. Use code to calculate this, not estimation. Exclude any missing, blank, or non-response values from the calculations rather than treating them as zero.
3. Flag any cross-tab cell with fewer than [N, e.g., 10] respondents. A cell with ZERO respondents also counts as under the threshold, not just small nonzero counts. Report the total flagged as a single number computed directly from the full table, not calculated in parts and combined.
4. Before giving me the final answer, recompute every number you're about to report directly from the underlying table one more time, using a genuinely different method than you used the first time, for example a manual count instead of a formula-based one. Simply re-running the same calculation again doesn't count as a check. Correct anything that doesn't match rather than keeping your first-draft number.
5. Summarize 2-3 patterns, and be explicit about which differences look meaningful versus likely noise given sample size. Don't overstate findings from a small dataset.
6. Save the table itself as an image file I can download, formatted so it's easy to read at a glance.
Setup: Turn on Code execution and file creation in Claude or ChatGPT settings, or step 2's "use code, not estimation" won't hold. It's on by default for Team and Enterprise accounts; Free, Pro, and Max users enable it under Settings > Capabilities.
If your survey data lives in Sprig, skip the export step: Sprig MCP connects live surveys, responses, and themes directly into Claude or ChatGPT, so you work from current data instead of a CSV exported an hour ago.
Running this prompt on the test data, comparing whether a formal AI policy relates to productivity, encouragement, and training adequacy, produces the table below.
| Metric | Formal policy | No policy | Unsure if policy exists |
|:-----------------------------:|:-------------:|:---------:|:-----------------------:|
| Org encouragement (mean, 1–5) | 3.75 | 3.28 | 3.16 |
| Training adequacy (mean, 1–5) | 3.24 | 2.49 | 2.63 |
| Productivity (mean, 1–5) | 3.81 | 3.65 | 3.56 |
Org encouragement and training adequacy both show a real difference by policy status: 3.75 versus 3.28 versus 3.16 for encouragement, and 3.24 versus 2.49 versus 2.63 for training. Productivity does not move the same way. All three groups land close together, and the gap isn't large enough to call meaningful at this sample size.
Every group in this analysis had at least 49 respondents, well above the 10-person flagging threshold, so nothing here was flagged as too thin to trust. Step 2 is also why the "SKIPPED" quirk from the plain-prompt section never becomes a problem here: missing and non-response values get excluded before any calculation runs, on purpose, rather than getting handled by accident or not at all.
Comparing the Two, and Which One We'd Trust
| | Plain prompt | Engineered prompt |
|---|:---:|:---:|
| Handling the "SKIPPED" marker | One path fixes it by accident. The other doesn't fix it at all. | Excluded on purpose, in step 2, before any calculation runs |
| Failure visibility | One attempt crashes and forces a fix. The other runs clean and reports a wrong number with no warning. | Designed to catch this before anything gets reported |
| Resulting numbers | Correct on one attempt, understated by 7 to 17 points on the other | Matches the correct numbers every time |
| Verification | None on either attempt | Independent recompute, a genuinely different method, required before answering |
| Reproducibility | Two honest attempts, two different outcomes depending on approach | Same data, same result, every run |
The plain version isn't uniformly wrong here, and that's worth sitting with rather than smoothing over. One of the two attempts landed on exactly the right numbers, by accident rather than by design. But "sometimes right, with no way to tell which time" isn't something you can build a decision on. The actual finding in this guide isn't a bug to patch. It's that a plain prompt's reliability depends on which of several equally reasonable paths Claude happens to take on a given run, and none of those paths announce themselves as the risky one before you've already trusted the answer.
The engineered prompt exists to remove that coin flip, not to make Claude smarter. Step 2 excludes anything that isn't a real number before any calculation happens, so the answer doesn't depend on which path got taken to get there.
Lessons for Your Own Prompts
The built-in checks catch a lot, but a few things are still worth verifying yourself:
- Do the group sizes add up to your total sample? Sum the segment counts and compare to your full dataset.
- Does at least one number match a manual check? Spot-check one percentage or mean with a filter or pivot table.
- Is any segment very small? Treat anything reported for it as unreliable, even if it wasn't explicitly flagged.
- A calculation that runs without an error isn't the same as a calculation that's correct. The clearest case in this guide didn't crash at all. It just quietly counted the wrong people in a percentage's denominator. Ask explicitly what should and shouldn't be excluded from any calculation, rather than trusting that an absence of errors means an absence of problems.
FAQ
Why not just ask Claude to run this directly, the way most people would? That's exactly what the plain-prompt section of this guide tested. One attempt landed on the right numbers by accident. A second, equally reasonable attempt understated real agreement by 7 to 17 percentage points, with nothing in the output suggesting a problem. Asking Claude for a cross-tab gets you something back either way. Whether it's something you can act on depends on which path it happened to take, and the output alone won't tell you which one you got.
Do I need to know how to code to use this? No. Paste the engineered prompt into a Claude conversation with your data file attached, and Claude writes and runs the analysis. You only edit the bracketed placeholders, like [OUTCOME VARIABLE], with your own column names.
What if my survey has open-ended questions too? This prompt handles rating, yes/no, and other categorical answers only. For open-ended questions you want to sort into themes first, use the advanced version of this guide.
How do I know if my sample size is big enough? You don't need to guess upfront. The prompt flags any segment with fewer than 10 respondents rather than reporting a number it can't support. If most groups come back flagged, combine categories into broader groups or collect more responses.
Can I trust the numbers without checking them myself? The engineered prompt's verification steps catch a lot, including exactly the kind of silent miscount the plain-prompt section found. That's not the same as a guarantee. Spot-check at least one number yourself before you publish or present anything, the same as you would for any analysis, human or AI.
Is this a Claude-specific problem, or would other AI tools hit the same issues? We only tested Claude, so we can't say for certain about others. The actual failure here, a non-numeric marker sitting inside a column that looks purely numeric, comes from how the data gets read and interpreted, not from anything specific to Claude's training. Any tool or analyst working from this kind of export without checking for it would plausibly hit the same landmine.
How do you know the plain version wasn't quietly set up to fail? We ran it twice, independently, actually changing the approach rather than running the same mistake through a different function name: pandas with a type-error fix on the first attempt, standard-library Python with a literal frequency-table reading on the second. One of those two attempts produced entirely correct numbers. If this were rigged to fail, it wouldn't have.
Does this mean a quick, unengineered Claude analysis is never worth trusting? No. One of the two plain attempts here got the numbers exactly right, and both took seconds to run. For a fast first look, that's genuinely useful. The gap shows up once you need to know, in advance, whether you got the version that worked.
Can I use the dataset from this guide for my own testing? No. It's synthetic and built specifically to illustrate this prompt. Use your own survey data with the template above instead.
