The Vendor Proposal That Looks Like a Solution But Is Not

Vendor proposals for AI implementations follow a predictable structure. The problem statement is articulate. The proposed solution maps neatly to it. The timeline has phases. The pricing is tiered. It looks like a solution because it is structured like one. That structure is not the same thing as a solution.

The gap: what the proposal describes is capability, not fit. It says what the tool can do. It rarely says what your business needs to have in place for that capability to translate into an actual outcome. The process documentation, the stakeholder alignment, the data quality, the decision authority — these are conditions, not features. A proposal that does not name them is selling a capability into an environment that may not support it.

The diagnostic questions that separate real solutions from capability presentations: what happens when the input is not what the demo assumed? Who on our team is accountable for making this work after your implementation team leaves? What does 'complete' look like in operational terms — not technical terms? What is the cost of maintaining this, not just buying it?

Vendors who have done this before will answer these directly. Vendors who have not will deflect — typically toward customisation, additional services, or a phased approach that defers the hard questions. The deflection is the signal. A vendor who cannot describe what failure looks like in your specific context has not thought hard enough about your specific context.

The companies that avoid this trap add one step to their procurement: they run a small paid pilot before any major commitment. Not a demo — a pilot on real work, with real conditions, measured against real outcomes. The pilot costs money. It costs significantly less than a full implementation that fails because the conditions were never right.