How to choose enterprise search software when every demo looks the same

The short version

• Enterprise search indexes content from several separate systems and answers one query across all of them, which makes it a permissions problem before it is a search problem.
• Permission enforcement at query time is the first filter on any shortlist, because an index that ignores access control is a second copy of your content with no rules on it.
• Enterprise search platforms bill in different units, per seat, per search request and per cluster, so list prices are not comparable until you convert them to your own volume.
• A connector that exists is not the same as a connector that carries permissions, so ask what each one syncs, how often, and what it does when it falls behind.
• The only useful trial is a fixed set of real questions with known right answers, scored by the people who asked them.

What should you compare first when choosing enterprise search software?

Four things, in this order: whether it enforces your existing permissions at query time, whether it connects to the systems your answers actually live in, what unit it bills you in, and whether you can test it on your own questions before you commit. Everything else on a comparison matrix sits downstream of those four.

Feature lists converge. Every enterprise search platform on your shortlist will offer natural language queries, ranking, connectors, analytics and some form of AI summary. Those claims are mostly true and mostly similar. The differences that decide whether the thing works in your company are structural: how identity is resolved, how often permissions are reconciled, what happens when a connector falls behind, and what the invoice looks like in month nine.

The order matters because the later items cannot rescue the earlier ones. Excellent ranking with no permission model is unusable in a company that holds anything confidential. A perfect permission model with no connector to the system holding most of your documents is a search box over the wrong corpus.

What is enterprise search, and how is it different from intranet search?

Enterprise search indexes content from several separate systems and answers a single query across all of them. Intranet search covers one system, the intranet. If your staff can find the HR handbook but not the contract, the ticket history or the deal notes, you have an intranet search engine and an enterprise search problem.

An enterprise search engine has three parts. Connectors pull content out of source systems, an index stores it in a form you can query, and a query layer ranks results and increasingly writes an answer with citations. Workplace search, enterprise search tool, enterprise search solution: vendors use the terms interchangeably and they all mean roughly this.

The distinction matters commercially. Intranet search tools are usually sold as a module of the intranet, priced per seat and scoped to one content type. Enterprise search platforms are sold as infrastructure. Asking an intranet search product to also cover a CRM, a shared drive and a ticketing system is how projects acquire a second year.

How do you check whether a platform enforces your permissions?

Ask one question. Does the search run only against the documents this user is entitled to see, or does it run against everything and filter the results afterwards? The first is access control. The second is a display control, and by the time the filter runs the content has already crossed a boundary.

Then ask about currency. Permissions change constantly, and an index that captured them once at ingestion is wrong within weeks. A useful answer tells you how often entitlements are reconciled with the source system, and what the system does in the window between reconciliations when somebody changes team.

There is a third question most buyers never ask: what happens to a document whose restriction was written as a header or a label rather than an access control list? Splitting documents into chunks separates text from the markings that governed it, so a confidentiality note can end up in a different chunk from the paragraph it was protecting.

Which systems does it actually need to connect to?

Write that list before you look at vendors. Not the list of software you own, the list of places an answer could live: the document store, the email archive, the ticketing system, the CRM, the wiki, the shared drive nobody admits to, and the handful of files that exist only in one person's folder.

Then test each connector on three points. Does it carry permissions, how often does it sync, and does it read the whole object or only the metadata? A connector listed on a website is not the same as a connector that keeps a large library current with access control intact, and the gap between those two is where most of the implementation effort goes.

Published benchmarks for how many applications a company runs are worth less than your own count. The figures in circulation come from vendor product data: Okta's Businesses at Work 2025 analysis, for example, draws on anonymised product data across thousands of its own customers, states no explicit data window and gives no breakdown by company size. Your own list of ten systems is a better planning input than somebody else's average.

How do you compare pricing across enterprise search platforms?

You cannot compare the list prices directly, because they are quoted in different units. Convert every option into your own expected monthly volume first, then compare the totals.

Three published examples show the spread. Microsoft 365 Copilot lists at $30.00 per user per month paid yearly, with a separate licence for a qualifying Microsoft 365 plan required on top, so cost scales with headcount. Algolia's Grow plan includes 10,000 search requests a month and then charges $0.50 per additional 1,000 requests, so cost scales with query volume. Elastic Cloud Hosted lists Gold, Platinum and Enterprise at $114, $131 and $184 per month, with the Standard tier quoted 'as low as' a price footnoted to a 120 GB, two zone production configuration, so cost scales with infrastructure. All three were read from the vendors' own pricing pages on 5 November 2026 and change without notice.

Those units fail in different ways. Per seat is predictable and expensive once you want everybody to have it. Per request is cheap at pilot scale and surprising when search becomes a background call made by other software. Per cluster is indifferent to usage, which is comfortable until you have to size it. Ask every vendor what the bill looks like at three times your current volume, and get the answer in writing.

Which way of buying enterprise search fits which situation?

What does 'AI-powered enterprise search' actually change?

It changes the output, not the retrieval. AI powered enterprise search means the system writes a sentence instead of listing ten links, and it usually ranks better because the query is interpreted rather than matched. The passage it writes from still has to be the right passage, and that is a retrieval problem rather than a model problem.

This is why an AI driven enterprise search solution can be worse than a plain search box in one specific way. A list of ten links lets a reader see that none of them fit. A fluent paragraph assembled from the second best document reads as an answer. Citations are the mitigation: insist that every generated answer names the documents it used, and that a reader can open them in one click.

So score two things separately when you evaluate enterprise search AI. Did it retrieve the right source, and did it represent that source correctly? Vendors demo the second. The first is where the failures live, and it is the one your evaluation has to measure.

How should you run the trial?

Build a fixed question set before the first demo. Fifty questions your staff actually asked, each with the correct answer and the document containing it recorded by a human. Run the same set against every tool on the shortlist, in the same week, with the same corpus.

Score retrieval and answer quality separately, and keep a few questions whose honest answer is 'we do not have that documented'. A tool that invents something for those will invent things in production, and you want to find that out during the trial rather than after a partner quotes it back to you.

Then run the permission test. Take two accounts with different entitlements and ask the same question about something only one of them can open. If the restricted account receives the answer, a citation to the document, or even a confirmation that the document exists, the system is not ready, regardless of how well it scored on everything else.

Which enterprise search statistics should you not trust?

The ones with no methodology attached. Two are worth knowing about specifically, because both turn up in procurement documents and business cases.

The first is the 42% of information that fails employees, from Coveo's fifth annual EX Relevance Report, published on 29 April 2025. It is a real published figure. It is also a vendor commissioned survey of 4,000 US and UK adults at companies with 5,000 or more employees, with no fieldwork dates disclosed, so it describes large organisations and tells you nothing about a forty person firm.

The second is the figure widely attributed to Microsoft for the share of the working day employees spend searching for information. Microsoft's Work Trend Index titled 'Will AI Fix Work?' surveyed 31,000 workers across 31 markets between 1 February and 14 March 2023, and publishes no percentage of time spent searching. What circulates as that number is a share of respondents, or comes from somewhere else entirely.

This is not pedantry. A business case built on a borrowed number collapses the first time somebody checks the citation, and the project loses credibility exactly when it needs it. The mechanism argument is stronger anyway: people cannot find things across systems because nothing indexes across systems.

When is enterprise search software not worth buying?

When you run two or three systems, have a small team, and nobody has curated the content. Search makes existing content findable. It does not make poor content good, and a confident answer drawn from a policy that was superseded two years ago is worse than no answer, because it gets acted on.

In that position the cheaper move is to fix the inputs, use whatever search your existing suite already includes, and revisit the question in six months with a real question log in hand. That is a legitimate outcome of a buying process, not a failure of one.

What to fix before buying enterprise search software

• •Decide which system is authoritative for each kind of question, then archive the copies that are not.
• •Fix permissions in the source systems first, because search will faithfully surface whatever they currently allow.
• •Write down the twenty questions people ask most often, which doubles as the start of your evaluation set.
• •Check that the content answering those twenty questions exists in writing at all. A surprising amount of it does not.
• •Name an owner for the index and the content behind it, because unowned search degrades quietly and nobody files a ticket.