Guide
How to Compare AI Automation Proposals
Questions for comparing what each firm will build, what the buyer must provide, how acceptance works, and what the system will cost to run.
Two firms can read the same project brief and return totals for different work. A sample-file demonstration, a limited pilot, and a system expected to run every day should have clear labels before their prices are compared.
Put each proposal into the same worksheet. Mark every item included, excluded, or unknown, then send the unknowns back to the firm in writing.
The workflow each firm priced
Start with one paragraph describing the current process. Name where the work begins, which records are involved, who makes the decision, and what should happen afterward.
Send the same paragraph to every firm and ask them to correct any difference in their understanding. Material answers should appear in the revised proposal or statement of work. A verbal assurance can be forgotten when the project begins.
Discovery, prototype, pilot, or production
Each stage carries different responsibilities. Ask the firm to label the work and describe what the buyer will have at the end.
Extra scope deserves the same review as the core work. A larger proposal still has to connect every component to an operating requirement or a named risk. A proposal calling its result production-ready should explain access control, monitoring, recovery, acceptance checks, and support.
- Discovery: workflow map, constraints, and a recommended approach
- Prototype: a working example used to test the main idea
- Pilot: a limited version used by a defined group or on a controlled set of records
- Production: an operating system with agreed testing, access, monitoring, and support
Buyer responsibilities and access
List who will confirm API access, obtain vendor approval, buy licenses, create service accounts, prepare sample records, and answer workflow questions. API access that nobody has checked should remain marked unknown.
The proposal should say when production access is expected, which access remains after launch, and who stores, rotates, and revokes service credentials. Early discovery can often begin with a screen share, sample export, or read-only report.
Add one security and privacy row to the worksheet. Record what data leaves the buyer's systems, which providers or subprocessors receive it, training-use terms, retention, deletion, credential storage, production logs, incident handling, and who may inspect production records.
Deliverables, exclusions, and evidence
Translate phrases such as AI integration and workflow automation into concrete deliverables. Record exclusions beside the included work. Broad exclusions inside a fixed-price proposal can move ordinary implementation work into later change orders.
Ask for evidence that matches the proposed responsibility. A live walkthrough can demonstrate a comparable technical capability. Sample documentation can show how the firm records setup and support. A polished demo does not establish that production permissions, exception handling, and recovery are complete.
- Systems and records included in each connection
- Data cleanup, migration, and field mapping
- Review screens, reports, alerts, and automated actions
- Deployment, administrator setup, documentation, and training
- Testing, monitoring, recovery, and known failure handling
- Correction period and support included after launch
Acceptance checks for AI behavior
Agree on a set of ordinary examples, failures, and edge cases from the real workflow. The buyer and firm should record the expected result for each example before the test runs. Count false positives and false negatives separately when they create different risks.
Decide whether a person reviews every result at first or only exceptions. Record which error pauses the workflow, who approves corrections, and whether the firm can reproduce the evaluation later.
Save the examples and expected results. The proposal should say when those checks will run again, including after changes to the model, prompt, source data, or connected system. Accuracy or savings claims need a stated test set, baseline, and measurement plan.
Ownership, handoff, and recurring charges
Check the contract for ownership of custom code, configuration, documentation, prompts, workflow definitions, and data mappings. Confirm what the buyer receives, its format and license, and whether another team can use it without the supplier's private account or proprietary platform. Record any handoff assistance and fee.
Request running-cost estimates at the expected volume and at a plausible higher volume. Include model calls, document processing, storage, integration platforms, logging, and human review. The proposal should identify who may change the selected model or provider and how the workflow will be retested afterward.
- Source repositories and deployment configuration
- Schemas, field mappings, prompts, and workflow definitions
- Test cases and expected results
- Credential inventory without the secret values
- Administrator and support documentation
- Current limitations, known issues, and open work
The comparison worksheet
Create one row for every requirement or question. Copy the proposal's wording into the sheet instead of interpreting a vague sentence as included. Keep unknown as its own status and avoid a weighted score unless the weights reflect a documented business priority.
Some columns will not apply to every row. Leave them visible so buyer-owned work, missing evidence, and later costs do not disappear from the total.
- Requirement or question
- Answer from each proposal
- Included, excluded, or unknown
- Work owned by the buyer
- Evidence supplied
- Acceptance check
- Initial project cost
- Expected recurring cost
Before choosing
Send the same completed sheet to each firm and ask them to fill every blank or mark it excluded. Compare unresolved assumptions before comparing totals, then place the confirmed answers in the proposal or statement of work. Keep the worksheet with the signed agreement so it records what each firm said was included.