Define the scope of an AI automation project.

The scope of an AI automation project depends on the process, available system access, quality of the inputs and consequences of mistakes. Define those first. A useful proposal explains the work, your team’s responsibilities and how you will decide whether the result is ready.

The factors that change the work

Factor	What to establish before a proposal
Process	The beginning, expected result, exceptions and decision owner
Systems	Supported access, subscriptions, read and write permissions, and connection limits
Inputs	Document formats, versions, missing fields and representative examples
Review	Who approves which actions and how the decision is recorded
Testing	Expected answers, unacceptable mistakes and a comparison baseline
Operations	Monitoring, incident response, changes, support and handover

A draft-only process has different controls from a workflow that changes records. A clean document collection requires different preparation from scanned files with conflicting versions. A tool’s API being available does not establish that every required action is supported.

Separate the first check from the full rollout

Agree a defined first use case and the evidence needed to continue. Start with approved examples; confidential material should wait until access, permission and data handling are settled. Review the outputs and exceptions before extending the workflow to a larger set of records or more systems.

The guide to choosing a first workflow provides a practical starting checklist. Where existing software already covers the job, AI implementation and adoption may fit better than a custom build.

Ask what you receive at handover

• Configuration and operating instructions for the agreed workflow.
• The test inputs and results, with failures and limitations visible.
• Ownership and access arrangements for code, prompts and connections.
• The procedure for reviewing changes, pausing work and recovering from failures.
• The responsibilities for future software, model and document changes.

These items should be explicit in the agreed scope. Do not infer ongoing support or an ownership arrangement from a demonstration alone.

Compare proposals on the same assumptions

Use the same process, input sample and acceptance criteria when assessing options. Ask which subscriptions and usage charges sit outside implementation, whether a third-party licence is required, and which dependencies can change the schedule. A generic savings estimate cannot replace your own baseline.

There is no universal project price or delivery time. Establish the process and software involved before comparing proposals.