Procuring an AI implementation — a model-serving stack, an anomaly-detection layer for operations, a copilot integration — fails more often at the quotation stage than at the engineering stage. Teams solicit AI project estimates informally, receive proposals that answer different questions, and then select on charisma because nothing else lines up. The remedy is procedural, not technical: define the requirement once, distribute it unchanged, and force every vendor to respond inside the same frame. The following method produces estimates you can defend to a CFO.

Step 1: Freeze the requirement before any vendor call

Write a one-page specification: the business decision the system must improve, the data sources available (with volumes and refresh rates), the latency and accuracy thresholds that define “working”, the deployment environment, and the integration boundaries. Note what is explicitly out of scope. This document is the unit of comparability — every estimate that follows is only as comparable as this page is stable. Teams that have internalised how machine intelligence sharpens day-to-day business decisions usually find the “decision to improve” line the easiest to write; teams that cannot fill it in are not ready to buy.

Step 2: Decide your comparison axes in advance

Before a single number arrives, declare what you will score: total cost across build and first-year run, the vendor’s demonstrated depth in your problem class, geographic and timezone fit for the collaboration model you want, and the credibility evidence behind each claim. Fixing the axes first prevents the strongest proposal from redefining the contest around its own strengths. It is the same tetrad a patient uses on a healthcare bidding marketplace — price, institutional detail, location, confidence signals — transplanted into a procurement spreadsheet.

Step 3: Distribute the requirement to a deliberately wide pool

Send the identical document to five to eight candidates: two incumbents you already know, two specialists found through directories or communities, and at least one wildcard. Breadth here is cheap and information-rich. Healthcare shows how far this can be industrialised: on MyHospitalNow, the requirement-first marketplace for hospital treatment estimates, a patient files one description of what they need, the platform screens it, and multiple hospitals — institutions the platform itself characterises as verified — return written offers for the same case. Submitting the request costs the patient nothing; the breadth of responses is the product. An AI buyer can replicate that economics with a mailing list and discipline.

Step 4: Require a fixed response template

Ask every vendor to answer in the same structure: itemised cost by phase, named team members with relevant delivery history, assumptions they are making about your data quality, the metrics they will commit to, and a timeline with decision gates. Refuse free-form decks at this stage. A vendor who cannot populate a template is telling you how change requests will go later. For infrastructure-heavy scopes — say, the kind of pipeline described in this account of scaling visual processing without choke points — insist the template separates compute costs from services costs, because conflating them is the oldest margin trick in the industry.

Step 5: Normalise before you read a single total

When responses arrive, translate them onto one basis: same contract length, same assumed data-readiness, same support tier. Flag any estimate that quietly re-scoped the requirement — it is answering a different question and must be either corrected or excluded. Only after normalisation should you look at the totals. Done in this order, the spread between highest and lowest bid becomes interpretable: it reflects genuine differences in approach, not differences in what was priced.

Step 6: Compare, interrogate, then approve

Score each normalised response against the axes from Step 2. Interview the top two and probe exactly where their numbers diverge from the pool median — a vendor’s explanation of why they are expensive (or suspiciously cheap) is more diagnostic than the number itself. Then approve one in writing, referencing the frozen requirement and the vendor’s own template response as the contractual baseline. The pause between comparison and approval is the whole point of the exercise; MyHospitalNow builds that pause into its flow as an explicit stage before patient and provider are ever connected, and procurement teams should treat it with the same formality.

Step 7: Archive the losing bids

Keep every estimate you did not accept. They are your benchmark corpus: when the chosen vendor proposes a change order, the archived bids tell you what the market priced that capability at three months ago. They also seed your next requirement document, because the questions vendors asked reveal what your specification left ambiguous.

Why AI project estimates reward this much structure

AI work is unusually easy to misprice because the deliverable is probabilistic and the dependencies — data quality, labelling effort, infrastructure — are invisible in a demo. Unstructured quoting lets each vendor choose which invisible costs to surface. Structured quoting forces them all into the light at once. The healthcare comparison is apt precisely because the stakes there are existential and the information asymmetry worse: if a written requirement, multiple screened bids, and an enforced compare-before-commit stage are workable for choosing a hospital, they are trivially workable for choosing an inference stack. The method costs a week. Selecting the wrong AI partner on an unexaminable quote routinely costs a year.

One final calibration: rerun the exercise annually even for incumbent relationships. Vendor pricing in this market moves with GPU availability, model licensing, and talent supply, and a requirement document you already maintain makes the refresh nearly free. Standing competition keeps your incumbent honest and your benchmark corpus current.