Per-query vs flat AI pricing - which is honest for Indian SMBs?

The first thing that happens when finance sees a per-query bill is a memo. Use the tool sparingly. Confirm with the team before running large queries. Justify each ad-hoc report. The memo is reasonable - finance has to control a variable cost - but it directly negates the reason you bought an AI analytics product. The whole point was to make asking questions cheap so the team asks more of them.

The second thing is selection bias in who uses the product. The senior people, who can defend a query, keep using it. The juniors, who would benefit most from cheap exploration, stop. The decisions that should be informed by data start relying on the senior person's memory again. Adoption looks fine on the dashboard (active users) and the value collapses (active questions per user trends to zero).

Not every metered model uses the word "query". Vendors have gotten more creative, but the meter is the meter regardless of what runs on the dashboard.

A useful test: read the contract and ask, can my bill go up this month if my user count, system count, and data scale do not change? If yes, you are on a metered model regardless of what the marketing says.

Per-query has unbounded upside for the vendor. If your team adopts the product enthusiastically, the bill grows in proportion to that enthusiasm. The vendor's revenue scales with your usage. The investor pitch loves it because revenue per customer compounds without new sales effort.

Per-query also lets the vendor advertise a low entry price. ₹10,000 per month plus usage looks better on a comparison page than a flat ₹1.5 lakh, even though the flat number is probably cheaper at real adoption levels.

A small honest sub-case: usage-based pricing makes sense for true infrastructure (cloud storage, network egress, GPU time) where the vendor's cost actually scales with your consumption. It is dishonest when applied to a finished analytics product, because the vendor's marginal cost of your tenth query this month is approximately zero.

Forecast accuracy collapses. A finance head needs to commit to next quarter's tooling spend within a few percent. A line item that varies 3x with usage breaks the forecast and attracts CFO scrutiny every cycle. The internal cost of managing that variability often exceeds the savings of the lower entry price.

The chargeback problem is worse. If finance allocates the AI tool cost to business units, per-query pricing means the most data-driven unit pays the most. That punishes good behaviour. Either finance accepts the misallocation or builds an internal allocation engine, both of which are worse than just paying flat.

Flat pricing names a number, attaches that number to a shape (users, systems, scale, deployment type), and tells you exactly what changes that number (more users, more systems, jump in data scale). The bill is the same in March and April. The team uses the product without asking. The vendor's incentive shifts from "drive your usage up" to "make sure you renew", which means making the product actually useful.

Flat pricing also gives finance permission to think about adoption rather than control. The conversation in the quarterly review changes from "why did this line item spike" to "are we getting our money's worth, and are adoption metrics climbing". That is a healthier conversation for everyone.

The behavioural change inside the team is the part most buyers do not budget for. On per-query pricing, a finance manager learns to batch questions, draft them carefully, and send them to a single power user who runs everything. On flat pricing, the same finance manager opens the tool when she has two minutes between meetings, asks a half-formed question to test a hypothesis, and discovers something the formal MIS would never have surfaced. The latter pattern is where most of the actual analytical value at Indian mid-market sits, and it only happens when the meter is off.

A real flat quote names one number per month, lists what that number includes (named users, named source systems, named data scale, deployment shape, support level), and names exactly the events that change the number. Adding a source system. Crossing a user count threshold. Jumping deployment shape (managed cloud to single-tenant). That is the entire price grammar.

A fake flat quote names one number and then has a paragraph of asterisks. "Subject to fair use", "subject to capacity tier", "premium connectors billed separately", "compute credits beyond the included pool charged at...". That is per-query in a flat dress. Read the fine print before you sign.