Use Cases · Customer Retention
You need to know which stores are losing their habitual buyers before it shows up in the quarter. But “habitual” isn't one thing — is it the shoppers who came often and stopped, or the ones who spent the most and drifted? Ask a tool to write the SQL and it quietly picks one, and may pick differently the next time you ask. Spotonix is the AI analyst that interprets before it queries: it spots that “habitual” is ambiguous, shows you the choice, and lets you settle it once — so every retention question after it means the same thing.
The alternative
The retention question is only hard because the words are ambiguous. Neither of the usual paths resolves the ambiguity in the open — one buries it in a queue, the other buries it in generated SQL.
Ask an analyst
A good analyst does resolve the ambiguity — they'll ask whether you mean visit frequency or spend. But the answer takes days, the reasoning ends up in a notebook only they can read, and the next person who asks a retention question starts the negotiation over. The definition was never written anywhere the business can reuse it.
Point an LLM at the warehouse
A frontier model writes fluent SQL, so it silently commits to one reading of “habitual” and hands you a confident number. Ask again next week, phrase it slightly differently, and it may pick the other reading. Two people, three answers, and no one can point to where the definition of “losing a customer” actually lives.
Cost of delay Every retention review you run on an unstated definition, you risk chasing the wrong stores — and you can't compare this quarter to last, because “losing a customer” may have meant something different each time you asked.
The outcome
The ambiguity is resolved in the open and represented as a Segment in the visible plan. Where persistence or cross-question reuse is required, test that behavior explicitly in the evaluation.
01
“Habitual buyer” becomes an explicit Segment you approved — say, shoppers with a minimum number of visits per quarter — instead of an assumption baked silently into a query. The choice is visible, and it's yours.
02
“Which stores are losing them?” then “which regions?” then “how much revenue is at risk?” — each shows the Segment it selected. That makes a changed definition visible instead of silently buried in a different query.
03
The plan shows the cohort, calculation, and comparison period behind the quarter-over-quarter read. Stable plan identity and automatic reuse are separate proof requirements.
How it works
This is the flagship example of interpret-before-you-query: one genuinely ambiguous word, resolved in the open before SQL executes.
It reads “which stores are losing habitual buyers?” and resolves the Segments, Calculations, and Analysis Patterns into a plan you can see — before any query is generated.
“Habitual” has two defensible readings — frequency (visits per quarter) or value (spend). Instead of guessing, it shows both and asks which one you mean.
You pick the definition. In Copilot mode, the workflow pauses for plan acceptance before query generation continues. Semantic checks validate material bindings before execution.
If the next retention question must automatically retrieve the chosen Segment, verify the persisted identity, retrieval path, version behavior, and audit trace during evaluation.
Representative questions
Once you've settled what a “habitual buyer” is, each of these resolves against that same accepted Segment — so the follow-ups line up instead of quietly redefining the cohort.
“Which stores are losing their habitual buyers this quarter?”
Segment Habitual buyers (accepted) Calculation Lapse rate, QoQ Pattern By store
“How much revenue is at risk from the ones who've lapsed?”
Segment Lapsed habitual buyers Calculation Revenue at risk Pattern Contribution
“Which regions are retaining them best versus worst?”
Segment Habitual buyers (accepted) Calculation Retention rate Pattern Regional ranking
Proof
The differentiator is a behavior you can watch, not a claim. In the demo, ask “which stores are losing habitual buyers?” and see the ambiguity gate surface frequency versus value before SQL executes. Then inspect the generated query and its validated bindings. The worked trace uses the public TPC-DS retail schema and is illustrative, not a customer result.