The three failure modes.
One pattern, three ways it goes wrong.
Yes-without-spec. A strategic customer drops an AI ask into a renewal meeting. Sales says yes because the alternative is losing the account. Engineering hears the words but not the constraints. Six months later the customer has a feature that technically meets the verbal request and does not meet the actual need. The renewal renews. The next one does not.
No-without-recourse. The same ask, the opposite reflex. Engineering scopes it, decides it is too far from the existing architecture, and the answer goes back through sales as "we cannot build that". The customer hears: this vendor cannot help with the part of the problem they actually need help with. Renewals walk. Worse, they walk telling the rest of the buying market they walked.
Pilot-that-becomes-product. The most expensive of the three. Sales agrees a small "exploration", engineering ships something that works in a demo, and the customer treats it as committed product. There is no rollback path. The pilot is now load-bearing, untested at scale, and the customer expects roadmap support for it indefinitely. The technical debt and the customer expectation become permanent at the same moment.
The reframe.
The AI ask is not a feature request. It is a strategic signal. The right response treats it as a scoping problem, not a build-or-decline binary.
Four things have to happen in the same week.
- Name the outcome the customer is buying. Not the model, not the API, not the UI. The decision or workflow the AI is supposed to change. "Cut review time on bid documents from three days to three hours" is an outcome. "Add an LLM to the document module" is a wish.
- Draw the data and policy boundary. Which data does the model see, which does it not, where does it live, who audits it, what happens when the model is wrong. This is the bit that decides whether the feature is a feature or a compliance incident.
- Write the smallest credible version. The smallest thing that demonstrates the outcome on one workflow, with one data source, with one user role, that the customer will sign acceptance criteria against. Not a prototype: a feature with a switch the customer can turn on and the engineering team can support.
- Get the criteria signed before the build starts. Three to five acceptance lines, plain English, the customer's signatory. If the customer cannot put their name to those lines, the spec is not finished.
None of this slows the project down. It moves the slow part to the front, where it costs less.
What this looked like.
The last time we ran this pattern at scale was for a strategic enterprise renewal. The client presented ten requirements that cut across product, UX, APIs, and commercial expectation. Treating the list as a feature backlog would have produced ten half-features against the wrong outcomes. Treating it as a strategic signal produced an AI-driven WebUI architecture (integrating OpenAI and the platform's own API) that solved eight of the top ten requirements and got the renewal across the line in six months.
The work was not "add AI to the product". The work was: name what the customer was buying, define the data boundary, ship the smallest version that worked end-to-end, and get acceptance signed before the major industry showcase. The £1.8m pipeline that followed is the lagging indicator. The leading indicator was the signed acceptance criteria.
When the answer is genuinely no.
Sometimes the right answer is no. The reframe does not change that; it just sharpens when no is honest.
No is honest when the outcome the customer is buying cannot be delivered with the data they have, the privacy posture they need, or the architecture you actually run. No is dishonest when it is shorthand for we did not feel like scoping this properly.
If no is the honest answer, name the two consultancies who could help. That is the costly signal. The renewal might still walk. It will walk telling the buying market that you were straight with them. Some percentage of that market will come back.