Company memory pricing: why we avoid a seat tax

Per-seat pricing is the obvious starting point for business software. Count the people who can log in, multiply by a monthly price and the invoice is easy to explain. For company memory, that simplicity creates an awkward incentive.

Take a 30-person company. Six people search every day; the other 24 need an answer only when a customer asks something unfamiliar or they join a project midway through. Charging for 30 seats makes the occasional readers look wasteful. Charging for six keeps them dependent on the same six colleagues who already hold the context.

The product has not removed the bottleneck in either case. It has put a licence boundary around it.

The cost of running internal search is not free, of course. Sources must be fetched, parsed, stored, indexed and refreshed even on a quiet day. Some questions also use meaningfully more model work than others. The awkward part is choosing a meter that follows those costs without teaching people to avoid the product.

Charging for every question is a poor fit for that goal. People begin to ration quick checks, precisely the behaviour a company memory tool should encourage. We prefer retained knowledge as the main anchor because the shared body of material is the durable thing the service maintains.

“Retained knowledge” needs a real definition on the invoice. Does it mean source bytes, extracted text, chunks, attachments or old versions? Our answer should be specific enough that an administrator can estimate an import before starting it. A friendly label is not a substitute for a measurable unit.

The edge cases reveal whether the meter is fair. Re-indexing an unchanged file should not create more permanent usage. A failed import should not count. Two teams reading one stored document should not turn it into two documents. Deleted material needs a stated retention window and a clear date when it leaves the total.

Limits should not arrive as a surprise after the work is done. Before a large source crosses a tier, the product should show its estimated effect and let the administrator stop. Current usage should lead back to the sources responsible for it, so cleaning an obsolete archive is a practical option.

Query safeguards still have a place. Rate and concurrency limits can contain unusual workloads without making every occasional reader a paid seat. If a plan also charges for exceptional model usage, that usage should be visible before it becomes an invoice line.

I would compare plans with three numbers, not one: today's source set, the likely source set a year from now and the total after removing material nobody should search anymore. Then ask what happens at the boundary. Does indexing pause? Is an upgrade explicit? Can old sources be removed first?

This model is not guaranteed to be cheaper. A vast archive used by three specialists may cost more than three seats. A compact knowledge base used by an entire company may cost much less. That is the trade-off, and it should be stated plainly.

For us, broad access is the more important default. People should be able to verify a piece of company context without asking whether their occasional question deserves another licence.