Available now
In build
The whole team
Nineteen specialists, each with a defined job and an honest status label.
See all nineteen“I have numbers in four different places, and I still don't have an answer to a question as simple as 'are we actually busier than last month'.”
Contacts live in one place, conversations in another, leads somewhere else, and the answer to an ordinary question needs someone to open three tabs and do arithmetic by hand. The category's usual fix — type a question, get a number back — trades that problem for a worse one: a wrong join or a misread column produces a confidently wrong answer that looks exactly like a right one. Ank will not generate SQL from what you type — that is this category's own documented failure mode, and this page treats refusing it as the strongest thing Ank does.
How it works
Three steps, and none of them involve trusting a number you can't trace back to a query.
Pick from a catalogue of reviewed questions about your workspace's own Wavy, Jeet and Socie data — contacts, conversations, leads, campaign sends, posts published. Ask something outside that catalogue and Ank says 'I cannot answer that' and lists what it can, instead of generating a plausible-sounding query on the fly.
Every answer carries the exact SQL that produced it and a plain sentence of what was counted — in the number, in its time series, in the rows behind it, and inside the CSV export too. Nothing here asks you to trust a black box.
A metric compares cleanly against the immediately preceding equal-length window, with both values and both queries returned. A percentage against a previous zero comes back as null with the reason stated, never as an invented number.
The meeting where someone asks “are we actually busier than last month” and three different tabs get opened to find out.
A closed catalogue
Every metric is a declaration — entity, workspace filter, time column, row projection — derived once so the count, the series, the comparison and the drill-through can never quietly disagree with each other. There is no path here that writes; every metric is a read.
This period vs last
The same query, run over the immediately preceding equal window — equal length, closed at both ends, so neither side is a partial period. A percentage against a previous zero returns null with the reason rather than an undefined-but-displayed number, and a point-in-time metric is refused rather than compared against today's rows as if it were windowed.
The central failure mode, refused
This is the deliberate, structural choice behind the whole product: no natural-language-to-SQL step exists to be subtly wrong. A question outside the reviewed catalogue returns 'I cannot answer that' plus the list of what Ank actually can, every time, rather than a number dressed in the same confident tone as a correct one.
Take it with you
A metric's value, its series, or the rows behind it exports to CSV with the counted-what sentence and the SQL written directly into the file — because the covering context is exactly the part that doesn't survive being forwarded to someone else. Rendered per request, never stored.
What it does
Each label is derived from the backend's own capability module — not written on this page.
Thirteen questions answered from real queries over your own Wavy, Jeet and Socie data, each also available as a series and as the rows behind it. Outside the catalogue: 'I cannot answer that,' plus what it can.
Works todayEvery answer carries the query that produced it and a plain statement of what was counted — including inside the CSV export and the drill-through rows.
Works todayEqual-length windows, both values and both queries returned. A previous-zero comparison is null with the reason, never an invented percentage.
Works todayThe counted-what sentence and the SQL are written into the file itself. Rendered per request and never stored.
Works todayComposed over the period-over-period deltas, each sentence carrying the numbers it was built from. No language model — nothing here to hallucinate, and no cause is ever stated.
Works todayAn owner or admin composes a metric from a whitelist of tables, aggregations and operators, with a mandatory statement of what it counts. Nothing typed is compiled; editing a definition afterward is not built.
Works todayAdd cards pinned to a metric slug, arrange them, and set one dashboard-wide day-range filter every card without its own dates follows. A card whose custom metric was deleted is flagged stale rather than silently misrepresenting a changed schema. Filtering by an individual field across cards isn't built yet.
Works todayWhat Ank will never do
Every leading vendor in this category's own documentation admits some version of these problems. Ank's answer is to refuse the shape of query that causes them.
This is the one thing the whole category gets wrong, named directly in the module that builds every metric: a subtly wrong join or a misread column produces a confidently wrong number. Ank offers a fixed, reviewed catalogue instead — nothing typed by a user is ever compiled into a query.
Every metric function takes a workspace id and builds its own filter from it. One employee reaching another workspace's numbers through a different feature isn't prevented by a rule somewhere — it's unrepresentable, because nothing in the query construction has anywhere else to point.
Every metric is an aggregate. None returns a named person's behaviour, so there is nothing in any answer to build a health, legal, financial or employment conclusion from — not because a rule forbids it, but because the shape of the data never carries it.
Still needed
The first one below is the boundary most worth reading if you assumed Ank already connects to your POS or spreadsheets — the code is there, this deployment just hasn't turned it on.
This is the boundary most worth reading if you assumed Ank already connects to your POS or spreadsheets. CSV upload (schema inferred server-side, capped at 5,000 rows) and a read-only Postgres connector both work end to end in code, but this deployment hasn't supplied what they need to turn on — object-storage credentials for CSV, a vault key to encrypt a database connection string for Postgres. MySQL and Google Sheets are refused by name rather than offered and failing on first use.
Recurrence validation, due-checking, rendering a dashboard or metric with the recipient's own row-level access applied, and an in-app bell notification all work today with no credential. Reaching a manager's email inbox without opening Ank needs an email provider key this deployment hasn't set; no WhatsApp channel is wired at all yet.
Seven fixed operations — trim, normalise case, parse common date formats, drop duplicates, drop empty rows, replace a value, rename a column — apply through reviewed code with no credential at all, and applying one always writes a new data source rather than overwriting the original. Translating an English sentence into that list of operations needs an LLM key.
Before you switch
Tell us which of your numbers you check most often, and we'll tell you plainly whether it's in Ank's catalogue today or still on the list above.
Questions
No, and that's deliberate. Ank answers from a fixed catalogue of thirteen reviewed questions — each a query written and checked once — rather than generating SQL from whatever you type. A question outside that catalogue gets 'I cannot answer that' plus the list of what Ank can, not a plausible-sounding guess.
The code is there but this deployment hasn't turned it on. A CSV upload (schema inferred automatically, capped at 5,000 rows) and a read-only Postgres connector both work end to end; they're waiting on object-storage and vault credentials this workspace hasn't supplied. MySQL and Google Sheets aren't offered at all — refused by name rather than left to fail on first use. Two already-connected CSV sources can be blended today.
Within limits, yes. A linear trend fit over a fixed lookback, with every point given as a low/mid/high range from the historical spread rather than one invented number. It refuses below four complete periods and refuses a horizon longer than the real history available — it will not project a business further ahead than it has ever been observed.
Every answer carries the exact SQL that produced it and a plain sentence of what was counted — in the number itself, in its time series, in the rows behind it, and inside the CSV export. You don't have to trust it; you can read the query.
No. Every metric function takes a workspace id and builds its own filter from it — there is no shared query path that could leak across workspaces, because nothing in how a metric is built has anywhere else to point.
No. Every metric is an aggregate — a count, a sum, a series — and none returns a named person's individual behaviour. There is nothing in any answer that could be used to draw a health, legal, financial or employment conclusion about someone.
