Why Generic AI Assistants Struggle With Enterprise PreSales

The short version

A general-purpose assistant is very good at the parts of presales that look like writing and reliably weak at the parts that look like evidence. The gap is not model quality — it is that enterprise presales answers have to be grounded in your documentation, scoped to one customer’s data, defensible after the fact, and correct about a product the model has never seen. Four requirements, none of which a chat window is designed to meet.

This is not an argument that generic assistants are bad. They are extraordinarily useful, and most SEs already use one daily. It is an argument about where they stop being useful, which is a more practical question than whether they are impressive.

Four things enterprise presales requires that a chat window does not provide

Grounding in your documentation

The answer has to come from your product documentation at its current version, not from the model's training data. Pasting documents into a context window is a manual, lossy version of retrieval that starts failing at the scale a real product's documentation reaches.

Scoping to one customer

A presales answer is about a specific deal, with that customer's constraints. A shared assistant with no tenancy model has no concept of which context belongs to which account, and no way to stop one leaking into another.

Defensibility after the fact

“Where did this answer come from and who approved it?” is a routine question six months later when the requirement resurfaces in a contract. A chat transcript is not an audit trail.

Currency

Products change. An assistant with no connection to your current documentation answers confidently from a snapshot, and confident staleness is harder to catch than an obvious gap.

The failure that costs the most

Of those four, the expensive one is grounding, and the reason is specific to this domain: RFP and questionnaire answers increasingly become contractual representations. A generic assistant asked whether your product supports a capability will produce a well-written, plausible, confident sentence. It has no way to know, so it infers from what products like yours usually do.

That inference is right often enough to be dangerous. The wrong answers are not obviously wrong — they are the ones where the general shape of the category is correct and your particular implementation differs.

The pattern to watch for

The riskiest generated answers are about capabilities that almost exist: scheduled sync described as automated, a supported protocol at the wrong version, a roadmap item described in the present tense. A model has no way to distinguish these from the truth. A person who works on the product does, instantly.

What generic assistants are genuinely good at here

It is worth being precise about this rather than dismissive, because the answer determines the sensible division of labour:

Rewriting and tightening text that a human has already made factually correct. This is the single highest-value use and it carries almost no risk.
Explaining an unfamiliar domain — a regulation, a protocol, an industry's vocabulary — before a call in a vertical you do not know well.
Structuring. Turning a messy set of notes into an outline, or a long document into a summary you will verify anyway.
Adversarial rehearsal. Asking it to play a sceptical evaluator and attack your positioning. Being wrong is not costly here, because the output is your own preparation rather than a claim to a customer.

Why “just paste the docs in” stops working

The common workaround is to paste product documentation into the context window. It works, up to a point, and the point arrives sooner than expected. Real product documentation is large, versioned, partly permissioned and partly wrong. Pasting it in flattens all of that: you lose which version you pasted, you cannot tell which passage an answer came from, and you silently include material the customer should not see.

What replaces it is retrieval with provenance — the answer cites the passage it used, so it can be checked rather than trusted. That is a system property rather than a prompt, which is a longer subject in its own right.

The practical division of labour

Use the general assistant for language, structure and understanding. Use a grounded system for anything that makes a claim about your product to a customer. The boundary is not about model capability — the same model may well sit underneath both — it is about whether the system around the model can tell you where an answer came from.

And in either case the human stays in the loop, for the reasons set out in the piece on hallucinations: the question is never whether the AI is right, it is whether the system makes it cheap to catch when it is wrong.

Bring the question you would not trust to a chat window

The interesting comparison is a requirement about your own product where the honest answer is “partial.” See what each approach does with it.

Request a Demo