Roughly 95% of AI pilots produce no measurable P&L impact. The usual explanation is the technology. It is not. By the time an RFP is issued, the solution has already been chosen — usually by the party least equipped to choose it — and every supplier who responds is competing to deliver the wrong thing well. This page is how to write an AI RFP that does not do that, and what to settle before you issue one.
Three independent research programmes arrive at the same place. Read together, they describe a procurement failure rather than a technology failure.
If pilots failed because models were weak, better models would have fixed it by now. They have not, because the binding constraint sits earlier — in how the work was specified and how the supplier was paid.
A well-run procurement takes a written specification and finds the best price for it. That process is sound when you know what you need — a building, a fleet, a payroll system. It breaks for AI transformation for three structural reasons.
You know your business better than any supplier ever will. What a system could do for that business is a different question, and it depends on operating experience you do not yet have — that is the whole reason you are buying. Asking you to name the platform, the model and the integration scope inverts the expertise. It should have come from the supplier; instead the supplier is handed your guess and asked to price it.
The moment the RFP names a solution, responsibility for that choice is yours. If the system is built exactly as specified and the operation does not improve, no supplier has breached anything. You carry the design risk because you specified, and the delivery risk because the contract pays for effort. This is why programmes end with what the deck calls an accepted compromise: a settlement on the original problem, signed off because the money was already spent.
Consultants bill days. Development shops bill headcount-months. AI vendors bill seats and credits. Every one of those models earns more when the scope grows, so every one of them must price change requests — and every discovery becomes one. The overrun is not a failure of the supplier's professionalism. It is what the contract rewards.
Fixing this after the RFP is issued is close to impossible: the specification is now the contract. It has to be fixed before.
Talking to capable suppliers while you do this is not a probity problem. Speak to several, document what you learn, and put the resulting problem statement into the RFP rather than any one vendor's answer. What you must not do is let the first supplier you speak to write the specification you then tender.
Relabelled rule engines, thin wrappers over a third-party API, and in some cases human work presented as automation, all survive a normal RFP process comfortably. These four questions do not need a technical evaluator to be useful.
Xamun is built to be answerable to the questions above rather than to survive them. Three commitments, all verifiable before you sign anything.
Twenty-five years of delivery sit behind that: systems still in production after two decades, over $500M in transactions processed on a platform we built, clients in more than ten countries. A three-year commitment is only credible from a delivery engine old enough to have honoured one.
Talk to capable vendors before the RFP is written, not after it is issued. An RFP is a specification document: the moment you issue it, the solution is fixed and every respondent is competing to deliver the thing you already named. If the named thing is wrong — and research on AI programmes suggests it usually is, because the buyer is asked to specify a technology they have not yet operated — then the procurement runs perfectly and still produces a failure. Pre-RFP conversations are not a probity risk if you speak to several suppliers, document what you learn, and put the resulting problem statement into the RFP rather than any single vendor's answer.
Because they specify means instead of outcomes. MIT's NANDA study of more than 300 AI deployments found roughly 95% produced no measurable P&L impact, and McKinsey's survey of about 1,993 organisations found only around 6% attribute more than 5% of EBIT to AI. The common thread is not model quality — it is that the work around the system was never redesigned. An RFP that lists a platform, a model and an integration scope buys exactly those three things and leaves the operation unchanged.
Ask for a business outcome with a baseline, and make the supplier own it. Specify the operation to be fixed, the metric that must move (cycle time per case end to end, error rate against governing rules, throughput at constant headcount), the date by which it must be running, and who carries the cost if it is not. Let suppliers propose the architecture. Requiring a named technology stack in an AI RFP transfers the design risk to you while leaving the delivery risk with you as well.
Ask four questions that a wrapper cannot answer well. First: what does the system do that a decision tree could not? Second: whose model is it, and what happens if the upstream API provider disappears tomorrow? Third: what is deterministic and what is generated — specifically, can the language model alter the ledger, the entitlements or the audit trail? Fourth: show a live operation and its measured before-and-after numbers, not a demo. Vendors relabelling rule-based automation, or wrapping a third-party API, answer these in marketing language rather than architecture.
Require one operation running end to end in production within 30 days, and judge the supplier on that before committing to anything further. Long discovery phases are where AI programmes quietly die: every month of specification is a month in which the business changes and the spec ages. A supplier who cannot put a single bounded operation into production inside a month is describing a research project, not a delivery.
Treat the change-request line as a diagnostic. Suppliers who bill for effort — day rates, headcount-months, seats — earn more when scope grows, so they must price change requests, and the overrun is structural rather than accidental. Ask each respondent directly: what does a change cost, and who decides whether something is a change or a defect? Xamun's answer is one problem, one price, unlimited changes: no rate card, no timesheets, and no change request has ever been invoiced.
Yes — that is the point at which help is worth most. Xamun Intelligence reads the business and maps where the value actually sits, so the RFP you issue describes the right problem with a measurable baseline attached. That work is useful even if Xamun never bids: you keep the problem statement, the baseline and the opportunity map. If Xamun does deliver, the engagement is judged on one live operation in 30 days, and if it is not live you owe nothing under Usage pricing.
Half a day. We read the business, map where the value actually sits, and leave you with a problem statement and a measured baseline you can put into any tender — whether or not Xamun ever bids. You keep the work either way.