Two proposals can both promise an AI assistant and describe very different purchases. One may cover a demonstration using a small document set. Another may include account permissions, a connection to your business system, review screens, acceptance evidence and the operating handover.
Understand that difference before comparing the price. A useful proposal shows the work needed for the result you want, the assumptions behind it and the costs your business takes on after launch.
This guide provides a way to compare that scope. If the business task is still unclear, the first AI project guide can help you select it. If you are comparing a purchased product with a custom solution, use the build-versus-buy guide alongside the proposal.
Price a complete business task
Describe the trigger, the information used, the output and the action that follows. “Draft an answer from approved support material for a staff member to review” is a different scope from “send a reply and update the customer record.”
The second task needs decisions about recipients, record access, approvals, failed actions and recovery. Those requirements change the design, implementation and testing work even when the visible chat screen looks similar.
Ask each supplier to mark what the proposed first release does, what remains a manual step and what has been left for a later phase. A clear first release gives you a basis for comparing the work and deciding what is worth funding now.
Separate the main parts of the investment
An implementation proposal should explain the relevant parts of the job:
- Discovery and decisions: the workflow, alternatives, dependencies and conditions that could change the approach.
- Information preparation: approved sources, document quality, record identifiers, access and the updates those sources will need.
- Application and integration: the interface, connections, permissions, review steps and exception handling.
- Evaluation and release: representative cases, observed results, repairs, release approval and recovery preparation.
- Handover: the agreed source and accounts, operating instructions, responsibilities and known limitations.
The right balance depends on your starting point. A clean, accessible data source is different from information scattered across restricted files and inconsistent records. An existing supported integration is different from a system whose interface or permissions still need investigation.
NIST's voluntary AI Risk Management Framework treats evaluation and management as continuing activities across the system's life. Include the relevant work in the project discussion rather than leaving its ownership unclear at launch.
Ask what drives the operating cost
The build fee is one part of the investment. Identify the recurring services, licences and human work needed to keep the application useful.
Depending on the design, that can include model or API use, hosting, storage, document processing, connected-system charges, monitoring, source updates and the time people spend checking or correcting results. Establish who receives each bill and which costs are included in the supplier's continuing service.
For a usage-based estimate, ask for the assumptions: expected tasks, information processed per task, repeat attempts, document refreshes and any existing provider minimums or allowances. Ask how actual use will be reviewed and who may approve a change to the operating budget.
Google Cloud's AI and ML cost guidance discusses measuring costs throughout the lifecycle and assigning responsibility. Its platform guidance does not set a price for your project; the proposed architecture and supplier terms determine the relevant charges.
Put two proposals on the same page
Planning example: A fictional business wants staff to prepare answers from approved service documents. It receives one proposal for a document-based demonstration and another for a connected review workflow. The comparison below identifies the questions to settle before treating the offers as alternatives.
The demonstration proposal
- Inputs: A selected document set in a review environment. Confirm who prepares and refreshes it.
- Next action: Staff copy the draft into their existing process.
- Evidence: Example answers. Ask which evaluation cases and limitations will be recorded.
- After handover: Confirm whether the environment remains available and what it costs.
- Unresolved decision: Whether the demonstration is useful enough to justify implementation.
The connected-workflow proposal
- Inputs: Approved documents plus specified customer information. Confirm the access rules and permitted records.
- Next action: A reviewer approves a defined action. Confirm the destination and failed-action behavior.
- Evidence: Task, permission and action checks. Agree the exact cases and release-blocking failures.
- After handover: Confirm hosting, usage, source maintenance and support responsibilities.
- Unresolved decision: Whether the proposed access, integrations and operating arrangements can be accepted.
A demonstration can be the right purchase when the important uncertainty is whether the task is useful or feasible. A connected implementation serves a different decision. Compare the scope you need and keep the next investment conditional on what the earlier work establishes.
Make uncertainty and changes visible
Some work cannot be priced responsibly until an interface, dataset or permission has been examined. Ask the supplier to identify that uncertainty and propose a bounded investigation with a clear decision afterward.
For the implementation, agree the included scope, your required inputs and how changes are approved. Explain what happens if a dependency is unavailable, the source material needs substantial preparation or the business requests another workflow.
Also settle the difference between correcting a defect against agreed behavior and adding a new requirement. Those decisions belong beside the allowance for planning, testing, releases and support, particularly in an ongoing development partnership.
Agree the evidence for accepting the work
Name the person who will review the application and the task they need to complete. Include routine cases, missing information, inappropriate access and failures in connected services where they apply.
Specify the record you receive: the version tested, the expected behavior, the observed result and the decision on unresolved issues. Our AI acceptance guide explains how to make that review practical without relying on a final presentation alone.
Ask for the handover at the same time. Your proposal should identify the source and account access, licences, documentation and operating responsibilities the agreement provides. That makes the price easier to understand as a purchase your business can use and maintain.
Turn the comparison into a sensible first project
Choose the proposal that addresses the business task, exposes the important assumptions and gives you a useful way to judge the result. Where the uncertainty is still large, an assessment or focused investigation can establish the next scope.
Butler Agency can help define the application, integration and evidence behind an AI implementation. Discuss the workflow and proposals you are considering, or explore the engagement options for a focused first project and any continuing work.