Ask your business data a question, in plain English

Can you really ask your data a question in plain English?

Yes — and the honest version of the answer is that the asking is the easy part; the trusting is the hard part. Natural-language analytics is a real, mature capability now. You type "how many customers churned last month?" or "what was revenue in July?" and a model turns your sentence into a query, runs it, and reads the result back to you in words. For anyone who has ever waited on an analyst or wrestled with a dashboard filter, that is a genuine relief. The barrier it removes — knowing the query language and the schema — was a real barrier.

So the technology is not the question. The question is whether you can act on what it tells you. A plain-English answer feels authoritative in a way a raw query result does not; it arrives as a confident sentence, with none of the caveats a careful analyst would attach. That confidence is exactly where the risk lives. The answer is only ever as good as the data the tool can reach and the joins it can make — and most of the time, the tool is reaching a single table and making no joins at all. Understanding that gap is the whole point of this guide, and it is worth getting right before you wire any tool into decisions you care about.

How natural-language analytics actually works

Under almost every "ask your data" feature is the same basic loop, usually called text-to-SQL. A language model is shown a description of your data — table and column names, roughly what they mean — and your question in plain English. It generates a database query it thinks answers the question, that query runs, and the model phrases the result back as a sentence. Modern versions dress this up with charts and follow-ups, but the core is unchanged: sentence in, query generated, query run, sentence out.

This works well when three things line up: the question is simple, the data it needs lives in one place, and the schema is clean enough for the model to map words to columns correctly. "How many signups yesterday?" against a well-named events table is close to a solved problem. The trouble starts when any of those three slips — when the question is compound, when the answer spans tables that were never joined, or when two columns mean subtly different things. And in a real business, those conditions slip constantly, because the interesting questions are almost never about one table.

There are two ways the loop then fails, and it is worth separating them because they are not equally common. The first is the famous one: hallucination. The model invents a plausible query or a plausible number that does not match your data. It is real, and good tools work hard to reduce it. But it is also the failure people expect, which makes it the one they check for. The second failure is quieter, more common, and far more damaging — and it is the subject of the next section.

The number was real, but the join was wrong

Here is the failure that catches careful people, because it survives every check they know to run. The model writes a valid query, against a real table, and returns an accurate number — as the answer to a question that actually needed data it could not see. Nothing looks wrong. The figure is correct. It is simply the wrong figure for the question, because the question spanned layers and the tool only touched one.

Take the question every founder eventually asks, and that we will return to for the rest of this guide: "Is MRR down this month, and is it tied to an error?" That is one sentence and two layers. The first half lives in your revenue data; the second half lives in your error data; and the link between them — which customers whose revenue moved also hit an error — lives in the join between the two. Point a copilot at your revenue table and it will answer the first half beautifully: yes, MRR is down, and by exactly this much. That number is real. But it has no path to the error data, so it does one of two things: it stays silent on the second half, or it guesses. Either way you have a true number attached to a false or absent story, and you make a decision on it.

This is why a real number on a missing join is worse than no answer. A blank makes you go and look. A confident, accurate figure with the wrong reasoning behind it makes you stop looking — you got a number, you move on. The failure is invisible precisely because the part you would check, the figure, passes. What does not pass is the part no single-table tool can even attempt: the join. This is the same structural gap we describe in why your app analytics should connect to revenue events — the data is all there, correct, and unjoined.

The bottom row is the whole story. A single-table copilot needs nothing special to produce a confident answer — which is exactly why it can be confidently wrong. Answering the real question needs the layers joined before the question is ever asked. That is not a smarter model; it is a different foundation.

The category, named fairly

None of this is a knock on the tools in the space — most are good at what they are built for, and the category is genuinely useful. It is worth naming them plainly so you can place Prism against them honestly rather than against a straw man.

BI copilots — the natural-language assistants now built into most business-intelligence and warehouse tools — are excellent when your data is already modelled in one place and the question fits that model. If you have invested in a clean warehouse with the joins pre-built, a good copilot on top of it is a real productivity gain. Product-analytics assistants, and things like PostHog's revenue MCP, let a model reach a specific slice of your data — product events, or revenue — and answer questions about that slice well. Text-to-SQL tools generalise the pattern to any database you point them at. Each of these is legitimately good within its boundary.

The boundary is the point. Every one of them answers well within the data it can reach, and the cross-layer question fails not because the tool is weak but because the join it needs was never made — it lives between systems no single tool owns. A BI copilot is only as joined as the warehouse beneath it. A revenue assistant sees revenue. The difference Prism makes is not a cleverer answer to the same question; it is that the join across revenue, errors, entitlements, behaviour and identity already exists, so a different class of question becomes answerable at all. We differentiate only there — on the join — and nowhere else.

Prism: asking across the joined timeline

Prism is Crossdeck's plain-English layer: you ask a question in words, and the answer is reasoned over your live, joined Crossdeck data. The reason it can answer the MRR-and-error question — the one that breaks single-table copilots — is not the model. It is what sits underneath: Crossdeck already joins revenue, entitlements, errors, behaviour and identity into one timeline, by identity. That join is the cross-match, and it is made continuously as your data arrives, not improvised at question time. So when you ask whether MRR is down and whether it is tied to an error, Prism is not trying to bridge two tables on the fly — it is reading one timeline where revenue and errors already sit against the same customers.

That changes what a plain-English answer can honestly contain. Instead of "MRR is down 4%" and a shrug about the cause, the answer can be "MRR is down this month, and a share of the drop traces to a set of paying customers who all hit the same checkout error before their renewal lapsed." Who, why, and what's at risk, in one read — because all three live on the same timeline. Every figure in that answer comes from live Crossdeck data, never an estimate; Prism reports recognised numbers or it does not report them. This is the natural-language expression of the whole cluster's idea, which the hub, real-time business monitoring, lays out in full, and which the complete guide to app revenue intelligence sets in its wider context.

It is also the same instinct as a good plain-English error summary: take something that would otherwise require correlating tools by hand, and state it in one clear sentence backed by real data. Prism does that for questions instead of alerts — you bring the question, the join brings the truth.

The privacy model is the feature

The most important thing about Prism is not how it phrases an answer. It is whose intelligence produces it and what happens to your data along the way — and here Crossdeck made a deliberate choice worth stating positively and clearly. Prism runs on your own connected AI model, using your own key. Crossdeck never runs its own AI on your data, and never trains on it.

Read that as three separate promises, because each one matters on its own. First, the model is yours: you connect it in the Prism tab, and from then on it is your model reasoning over your numbers — not a Crossdeck model you have to take on faith. Second, the key is yours: the intelligence runs on your account, under your control. Third, and most important, your data is never training material — not for Crossdeck, not for anyone. The join lives in Crossdeck; the reasoning is yours; the data stays yours. Privacy here is not a toggle buried in settings that you have to remember to switch on. It is the shape of the feature.

These are the questions worth asking of any tool you let near your business data, not only Prism. We list them because the honest answers are a feature, not fine print — and because "who runs the AI and what trains on your data" is precisely the question most ask-your-data pitches leave unanswered.

What you can actually ask

The point of a cross-layer join is a cross-layer question. The questions where Prism earns its place are the ones a single-table tool cannot touch — where the answer only exists once revenue, errors, entitlements, behaviour and identity are read together. A few illustrative shapes:

• "Is MRR down this month, and is the drop tied to an error?" The whole guide's example — revenue and errors, joined by customer, answered as one thing.
• "Which paying customers on the top plan hit a checkout error this week?" Revenue tier, entitlement and error, resolved to named customers. Closely related to error alerts that name the customer.
• "Did the customers who churned last month share an error the others didn't?" Churn, error and cohort in one question — the kind of thing you would otherwise reconstruct by hand across three tools.
• "How is MRR trending, and which movements are renewals versus new customers?" A revenue-shape question that pairs naturally with monitoring MRR.

None of these is exotic. They are the ordinary questions a founder asks about their own business — and they are exactly the ones that break when the tool can only see one layer. What makes them answerable is not that Prism is a stronger analyst; it is that the join they all depend on was already made.

Where Prism lives, and its one setup step

Prism is live today in two places, and it is worth being precise about both. In Telegram, you message /prism to the Crossdeck bot and ask your question in words, in private chat — the same place the alerts and hard-data commands already reach you, so the follow-up question lands where the signal did. And in the Crossdeck dashboard, the Prism view does the same over the same live, joined data. Ask in whichever fits the moment; both read the one timeline.

Two honest notes so expectations are exact. First, Prism is not zero-setup. You connect an AI model in the Prism tab once, with your own key — that is the step that makes it your model answering. After that, it is ready in both Telegram and the dashboard. Second, this runs in private chat by default. A shared team or group chat — where a whole team asks Prism together in one place — is on the roadmap, not shipped today. What is live now is the full single-operator loop: ask a plain-English question in Telegram or the dashboard, and get a truthful, cross-layer answer off your live data. If asking from your phone is the part you want, running your business from your phone covers it, and getting Stripe error alerts in Telegram is the step-by-step setup for the bot.

How to start

The way to test whether ask-your-data is trustworthy for you is not to read more about it — it is to ask it a question you already know the shape of the answer to, and see whether it reasons across layers or quietly answers off one table.

1. Connect Crossdeck so the layers are joined. The join is the prerequisite for every honest cross-layer answer; without it, any plain-English tool is back to single-table guessing. This is the cross-match doing its work before you ask anything.
2. Connect your model in the Prism tab. Your own model, your own key. This is the one setup step, and it is what keeps the intelligence — and the data — yours.
3. Ask the two-layer question first. Start with something like "is MRR down, and is it tied to an error?" — the question designed to expose a single-table tool. If the answer spans both layers and names the customers, the join is real.
4. Then ask from Telegram. Message /prism in private chat and ask a follow-up where the last alert reached you. The value is asking in the place you already are, about the numbers that are already live.

Ask-your-data is a real capability, and it deserves to be used with clear eyes: trust the plain English exactly as far as you trust the join beneath it. You can see how the cross-match works on cross-deck.com, explore the plain-English layer directly at Prism, or start free and ask your live numbers a question today.

Frequently asked questions