An AI automation project proposal brief that vendors can actually estimate

Three vendors receive the same request: “We need AI to automate our business.” One prices a chatbot, another proposes a CRM migration and the third suggests an autonomous agent. The estimates differ because the brief never established what the business was asking them to deliver.

A useful proposal brief describes the work, its boundary and the evidence that would establish completion. It allows providers to explain trade-offs without guessing the underlying process. It also gives the buyer a fairer basis for comparing proposals.

The template in this article is original VUZURAN guidance. It is a starting point for a project conversation, not a legal agreement or a promise of a fixed price.

Begin with the current process

Describe how the task works today, including the people involved and the systems they use. Give a representative input and the outcome it should produce. Use authorized or synthetic examples when sharing material externally.

Record frequency and effort as observed values or clearly labeled estimates. Explain the consequence of delay or error. A task may be frustrating without being important enough to justify a custom build.

The GOV.UK discovery guide offers a public-service reference for investigating a problem before committing to a solution. It is not a US procurement requirement. The relevant point is to give the provider evidence of the problem rather than only a preferred interface.

Use this original brief structure

The following fields can become a shared document. Complete them with specific information and preserve unknowns instead of filling every section with confident guesses.

Add a section for open questions. A provider should be able to say which assumptions affect the estimate and what discovery is needed to resolve them.

Define the first release and exclusions

List the smallest complete workflow that would be useful. Include the necessary access, interface, integrations and result confirmation. Do not call an isolated model response a complete business system.

State what is outside the release. Examples might include replacing the CRM, supporting additional languages or sending messages without review. These are illustrative boundaries, not standard exclusions for every project.

A proposal should make the first release and its exclusions equally easy to find.

If an excluded item is a likely future requirement, identify it as a later decision. That lets the team consider architecture without pretending the future work is already included.

Ask for acceptance cases, not vague quality claims

Request concrete examples of how the provider will verify the workflow. Include ordinary input, missing information, repeated events, unauthorized access and destination failure where relevant.

For an inquiry process, a useful case might confirm that the original request remains available, the right owner is assigned and the destination record exists. Another should show what happens when the CRM response is uncertain.

Ask who reviews the evidence and accepts the release. The provider can report test results, while the business owner confirms that the outcome meets the agreed operating need. Our evaluation guide provides a practical rubric for these discussions.

Request a data and permission map

Identify which providers receive information, which accounts the workflow uses and where credentials are managed. State any organizational constraints the implementation must respect.

Do not send production credentials in an initial proposal request. Use a controlled discovery process for access when appropriate. A provider can often assess the likely integration from documentation, sample structures and a scoped technical discussion.

Require the proposal to distinguish suggested output from authorized actions. A draft email, a sent email and a payment change have different consequences. The estimate should not hide those differences behind the word “automation.”

Make the estimate explain its assumptions

Ask for stages, dependencies and the basis of the estimate. Which parts are known, which require validation and what would change the scope? A range with explicit assumptions can be more useful than an unsupported exact figure.

Separate development effort from recurring platform costs, hosting and ongoing support. Include the business's own review and operating responsibilities. Our ROI guide explains why those costs belong in the business case.

Avoid comparing proposals only by the final number. One provider may include recovery and handover while another assumes those tasks are handled internally. Normalize the scope before deciding which offer is less expensive.

Ask how changes will be handled

A project can reveal new information. Define how the team records a proposed change, assesses its effect and approves it. Keep the current scope visible so a conversation does not silently become a new commitment.

Specify the review cadence and the form of evidence the team will see. A working journey with representative input is more useful than a progress percentage without a demonstration of behavior.

Include handover and maintenance questions before the final proposal. Who owns the code, provider accounts and deployment? Who handles an expired credential or a changed API after launch? The answers should describe the actual engagement rather than imply unlimited support.

Compare the responses against the same brief

Create a short comparison that records scope fit, assumptions, exclusions, evidence and operating responsibility. Note where a provider challenges the original solution for a reason supported by the workflow.

VUZURAN builds AI agents, custom tools and connected B2B software. You can bring this brief to a discovery conversation. It helps us assess whether an existing product, configured integration or custom release is the right response to the problem.