Why we don't publish per-message pricing

By Samir Shukri, Founder · 4 min read

The first question on most procurement calls is "how much per message?" — and the honest answer is that we don't price that way. Not because we're trying to be evasive. Because the per-message model breaks the incentives we want in a long deployment.

Every other AI-chatbot product in the comparison set prices by usage volume — per resolution, per message, per conversation. It's a clean billing model. It's also quietly hostile to the customer's actual goal.

What's wrong with per-message

It penalizes the conversations you want most. A long, engaged conversation that ends in a qualified lead costs you more than a fast deflection. The pricing model nudges your bot designers toward shorter, more terminal replies — the opposite of what improves conversion.

It breaks budgets unpredictably. Most teams have no idea what their visitor traffic looks like at message granularity. A viral mention, a product launch, an outage that drives support volume — any of these can blow through a monthly cap on the wrong week.

It quietly shapes bot design. Once a customer is on a per-message tier, every cap-hit becomes a reason to throttle. Bot responses get shorter. Escalations get more aggressive. The bot starts steering visitors toward "open a ticket" not because that's the right outcome but because tickets are cheaper than another reply.

It ties revenue to volume, not value. The vendor's incentive is to maximize the number of messages, not the number of resolved questions. That misalignment compounds across years of a deployment.

What we do instead

AxiomAI is priced as a flat monthly fee, scoped to what your deployment actually contains. Scope is three things:

• Integrations Which systems we connect to — SSO providers, CRMs, knowledge bases, custom webhooks. More integrations means more setup and ongoing support; that's what the price reflects.
• Tenants and users How many separate workspaces you need (one site vs many) and how many team members get portal access. Multi-tenant agencies scope differently from single-site companies.
• Data residency Default deployment is on our shared infrastructure. EU-residency, US-only, or single-tenant infrastructure changes the cost. Most customers don't need it; the ones who do, do.

After a fifteen-minute scope call we send a fixed monthly number — same number whether you run 1,000 conversations or 100,000 in any given week. You can plan around it. Your finance team can sign off on it. Your bot designer doesn't have a meter to watch.

What this costs us

We lose some sales we'd otherwise get. Buyers who want a 30-second per-message price comparison can't make that comparison and move on. We lose customers who would have churned out of a metered tier in month two anyway — but at the cost of also losing the ones who would have grown into something durable.

We also have to actually scope each deployment. That means a real call before we sign. It's slower than self-serve. It's why our trial path is separate from our paid path: anyone can spin up a 14-day free workspace through /register with no card and no scoping call. Only the paid relationship asks for the conversation.

The customers who land through this funnel are the ones we want — teams thinking about a multi-year operations platform, not teams testing whether AI works. That self-selection is a feature, not a bug.

Why we still think it's right

Three years from now we want the same conversation with a customer we had on day one: "What does your bot do, what's it missing, how do we make the next quarter better?" Not "You're 12% over your message tier this month, please approve the overage."

Scope-based pricing forces both sides to think about the deployment as a long-term relationship instead of a meter to watch. It costs us some velocity at sign-up. It buys us the kind of customer relationship the rest of the platform is designed for.