Three proposals, three different purchases

A workshop, a prototype and a running service can all appear under “AI onboarding project”. Imagine a professional-services firm receiving those three proposals for help with new clients. Their headline prices do not buy the same result. Start a comparison sheet with the outputs the firm needs: an approved checklist, access to the named document sources, a queue for staff to review and a record of each decision. Those rows give the suppliers a common job to price.

Ask each bidder to mark every row included, separately priced, dependent on you or outside scope. Keep the bidder’s wording beside your reading of it. Add the environment, people using it and actions it may take. A prototype using prepared files is different from a service connected to everyday work. If an offer stops short of the minimum you can use, compare the full route to that result or rule it out on scope. Do not treat the shorter job as a cheaper equivalent.

Nexus says deployed agents have measurable business KPIs. Brainpool describes its initial validation as a check of project feasibility. Fifty One Degrees describes a production system as the result of its engagements.^1,2,3

Turn the promised result into a list of cases you can check. For the onboarding example, include an ordinary application, missing evidence, contradictory documents and a case the service has no permission to handle. Write the expected result and name who judges it. Uncertainty should reach a person instead of becoming an invented answer. Use approved test material in a controlled environment, and put responsibility for preparing and keeping the evidence in the proposal.

Check usefulness as well as whether the software runs. A working connection does not prove the checklist is correct; a correct checklist does not prove staff can manage the queue. Compare quality, review effort and recovery with starting measures your team supplies. Agree which faults stop acceptance, which limits you could accept in writing and who has authority to do so. That gives both sides something clearer than a demand for perfection or a promise to improve later.

Valliance says most fees are paid when it creates value. Brainpool says intellectual property in project assets transfers to the client and describes Cortex as proprietary middleware. Fifty One Degrees says the client owns what it builds.^4,5,6,7

Take those statements into the contract discussion. Link each payment to a defined result or an agreed measurement. If fees depend on value, settle the starting measure, what caused the improvement, timing, disputes and a fee cap. For ownership, list project code, settings, test examples, documents and third-party components separately. Have the appropriate legal reviewer read the actual terms. A public statement about ownership is useful evidence of the offer, but it does not settle your rights under the agreement.

Show what happens after the first delivery. Do you have something you can use, enough evidence to stop, or another purchase you must make? Ask what declining expansion would mean. A promise that you own the result does not necessarily pay for the work of moving or maintaining it. Include the cost of handing it back and continuing licences where you need them. These details help explain why two apparently similar proposals can leave your business in different positions.

Supercharge lists ongoing support and says its work continues after launch. Nexus describes improving the first version with the customer.^8,9,10

Ask both sides to work through a failure: the onboarding service loses access to a source while applications are waiting. Who notices, who pauses it, how is the queue kept and how do staff return to the manual process? Write down response expectations, access and responsibilities. Then ask how a policy change or model update would be checked before affecting new applications. These are exercises to propose to an agency; Marchmont has not run them.

Finish with a decision note naming the proposal you chose, the alternatives you rejected, assumptions, open conditions and the people who can accept the work. An unanswered detail can remain a condition that must close before the purchase proceeds. It should not vanish from the comparison. Keep the signed scope, agreed checks, ownership details and support plan together. When someone later asks for a change, the team can compare it with what the business approved instead of reconstructing the sales conversation.