Use Cases · Recurring Business Questions
“How are we tracking on the number?” isn't a new question — it's the same question, every Monday, every month-end, every quarter-close. And every cycle it re-enters the analyst queue, gets re-derived by whoever's free, and comes back looking slightly different from last time. Spotonix is the AI analyst that interprets before it queries: it exposes the plan behind the recurring question, and scheduled reports and alerts can run recurring work. Stable plan identity and automatic plan reuse remain proof criteria, not blanket website promises.
The alternative
The question comes back on a schedule, but the plan behind it doesn't persist anywhere the next cycle can reuse — so you either re-ask a person or lean on a query nobody fully trusts.
Re-ask an analyst
Every cycle, the recurring question lands back in the queue. Whoever picks it up re-derives the joins, re-applies the filters, and re-decides the edge cases — often differently from the person who ran it last month. The work repeats; the answer wobbles.
A scheduled query
Someone once wrote a scheduled query to automate it. It still runs — but the definitions live buried in SQL only its author could explain, and when the number looks off, no one can say whether the business changed or the query drifted. So it gets checked by hand anyway.
Reconciling versions
Because each cycle's answer was built independently, small definitional differences pile up. The review spends its first ten minutes reconciling two versions of the same metric instead of deciding what to do about it.
Cost of delay Every cycle you run the recurring question as fresh work, an analyst pays the re-derivation tax again — and the number arrives late, inconsistent, and open to dispute in the one meeting it was built for.
The outcome
A visible plan gives the team something concrete to review before putting a question on a schedule. The recurring workflow should then be tested for plan identity, change control, current-data execution, failure handling, and alert delivery.
01
Scheduled reports and alerts are live surfaces. Use them for an agreed recurring question, while retaining an owner for definition changes and exceptions.
02
The visible Segments, Calculations, filters, and scope make definition changes discoverable. Spotonix does not currently guarantee identical generated SQL across cycles.
03
If your workflow requires persisted plan identity or automatic reuse, include it in the proof with a retrieval path, version behavior, and audit evidence. Do not infer it from a repeat result.
How it works
Pose “how are we tracking on X” in plain language. Intent Algebra resolves the Segments, Calculations, and Analysis Patterns into a visible plan, surfacing any ambiguity instead of guessing at it.
In Copilot mode, you review the plan and sign off before query generation continues. The resulting SQL is checked against material plan bindings before execution.
Name what must persist: the business definitions, plan identity, schedule, query linkage, result, and owner. Verify each artifact in the evaluation.
Configure the recurring report or alert, then test fresh-data behavior, failures, delivery, definition changes, and re-approval expectations.
Representative questions
Each is a candidate for the same operating pattern: expose the interpretation, assign an owner, schedule the work, and verify how changes are reviewed.
Every Monday
“How are we tracking on new bookings versus plan, week to date?”
Segment New bookings Calculation Actual vs. plan, WTD Pattern Weekly tracking plan
Every month-end
“Where did we land on active customers and net revenue retention this month?”
Segment Active customers Calculation Net revenue retention, MoM Pattern Month-end close plan
Every quarter
“What's churn by cohort this quarter, on the same cut we used last quarter?”
Segment Churned cohort Calculation Churn rate, QoQ Pattern Prior accepted plan
Proof
Inspect the plan, schedule the question, change a definition, trigger a failure, and verify the resulting history. A repeated result can come from caching and is not sufficient proof of plan reuse. Worked traces use the public TPC-DS schema and are illustrative.