How to compare AI automation proposals using one real workflow

Two AI automation proposals can use the same label while describing different work. One may configure a prompt inside software you already use. Another may prepare source data, connect several systems, design human review, handle exceptions, add monitoring, and hand the workflow to your team. Their totals do not become comparable merely because both proposals say “automation.”

Put every proposal against one real workflow before comparing price. By the end of this guide, you will have a common description of the work, a shared test boundary, and a clear view of what each proposal includes, assumes, excludes, or leaves unknown.

Start with the workflow your business runs today

Choose one recurring workflow, such as drafting a reply to a quote request, routing a support ticket, preparing an invoice exception for review, or updating an approved section of a website. Avoid a department-sized label such as “sales automation” or “customer-service AI.” A broad label lets each proposer solve a different problem.

Write the workflow from trigger to outcome. Name what starts it, the steps people perform now, the systems and source material they use, the decision or action at the end, the customer or financial consequence of a mistake, and the person who owns the result. If the workflow changes depending on the case, describe the important branches instead of presenting the easiest path as the whole job.

The current process is often the most useful baseline for a first comparison. NIST’s AI RMF Playbook Map guidance recommends documenting the intended context and considering performance against a human baseline or another suitable benchmark. For a proposal review, that means each proposer should respond to the same work as it exists now, including the manual checks and difficult cases that make the workflow expensive or consequential.

A compact workflow description can look like this:

Workflow: draft the first reply to an inbound quote request
Trigger: a customer submits the website form
Current owner: operations lead
Sources: form submission, approved service pages, prior email, selected CRM fields
Current steps: check fit, find missing details, draft reply, prepare CRM note, review, send
Difficult cases: rush requests, custom pricing, missing contact details, conflicting scope
Allowed first output: draft reply, missing-information list, proposed CRM note
Work that stays manual: pricing, delivery promises, CRM update, and sending
Consequence of a bad result: an unsupported promise reaches a customer or the record becomes inaccurate

This is a constructed example, not a BaristaLabs customer story. Replace it with a workflow and consequences from your own business.

Give every proposal the same test boundary

A proposal should explain how its approach handles the same representative inputs. An attractive sample is only one input to the decision. Give each proposer ordinary examples, difficult cases, and known exceptions from the workflow. Remove or protect sensitive data as your security, privacy, legal, or compliance requirements demand.

Define the expected output before the test. For the quote-request example, that may be a draft reply, a list of missing information, and a proposed CRM note with no automatic send or record update. Name the reviewer and what evidence that person must see, such as the original request, the approved service source, the proposed text, and any claim the system could not support.

Then ask what evidence you will receive after the test. Useful evidence can include the cases run, outputs produced, source references shown to reviewers, edits and rejections, exceptions that stayed manual, and an explanation of failures. The evidence should help your team judge the tested workflow; a demonstration alone cannot establish how untested cases will behave.

The SBA’s small-business AI guidance recommends starting small and testing whether a tool adds value. For businesses using free AI tools or software, it recommends having another person review AI products; it also says a person should assess AI-generated outreach. Apply the same review discipline to the bounded test whether the proposal comes from a software vendor, freelancer, consultancy, automation specialist, or internal team.

Mark what each proposal includes, assumes, excludes, or leaves unknown

Read the proposals line by line against the workflow and test boundary. Mark each work item with one of four plain statuses:

• Included: the proposal assigns the work, deliverable, or fee to a named party.
• Assumed: the estimate depends on a condition that has not been confirmed.
• Excluded: the proposal says the work will not be delivered.
• Unknown: the proposal does not say who does the work or how it will be priced.

An assumption is not automatically a flaw. A vendor may reasonably assume that your team will provide clean source files, system access, an available reviewer, or approved business rules. The comparison becomes useful when you can see that assumption and decide whether your team can meet it.

Constructed comparison: the same quote-request workflow

The table below illustrates two possible scopes. It does not describe actual vendors or imply that either pattern is common.

Neither proposal is the automatic winner. Proposal A may fit if your team only needs drafting inside an existing product and can own the sources, review, CRM entry, exceptions, and maintenance. Proposal B covers more of the workflow, but it still leaves questions about ongoing monitoring, support, and usage fees. The price comparison should wait until both proposers have answered the material unknowns or narrowed their scopes to the same job.

Separate the build from the work that continues afterward

A proposal total often covers a particular period or deliverable. Your comparison should distinguish one-time discovery, setup, configuration, source preparation, integration, testing, and handoff from the recurring work required to operate the workflow.

For every proposal, identify ongoing software or model fees, hosting, monitoring, source updates, prompt or rule changes, integration maintenance, reviewer time, exception handling, support, and retraining or documentation for staff. Also record the client responsibilities. Work does not disappear because it sits outside the vendor’s fee; it moves to your team or remains undone.

Keep manual work visible as well. A review step, pricing decision, sensitive exception, final send, or account update may stay with a person by design. That retained work can be the right boundary. It still belongs in the comparison because it affects staffing, response time, and the evidence needed to run the process well.

If the workflow uses sensitive data, credentials, external models, or actions that can change customer, financial, access, or public records, use the AI workflow security review worksheet before treating system access as a minor implementation detail.

Compare retained work and failure cost alongside price

Once the scopes use the same workflow and test boundary, compare what your business would still need to provide. A lower proposal total may leave more source cleanup, integration, review design, exception handling, monitoring, or maintenance with your team. A higher total may include some of that work, or it may simply price a different approach. The scope lines tell you which explanation applies.

NIST’s Map guidance asks organizations to consider expected benefits and monetary and non-monetary costs, including costs caused by failures. In this comparison, failure cost means the consequence your business would retain if the proposed workflow sends an unsupported promise, delays a customer response, changes the wrong record, exposes information, or creates correction work. These examples are local business considerations, not NIST estimates.

Do not turn the exercise into a false precision score. Write down the missing work, who would own it, and what would happen if it failed. Some unknowns affect only convenience. Others change whether the proposal is safe to test, whether the price is complete, or whether your team can operate the result after handoff.

Send materially different scopes back for clarification. Use the same short request for each proposer:

Please revise or clarify your proposal against the attached workflow and test boundary.
For each work item, state whether it is included, assumed, excluded, or not yet priced.
Name one-time and recurring fees, client responsibilities, work that stays manual,
the evidence delivered after the test, and who owns maintenance and exceptions.

This does not force every proposer into the same technical solution. It asks them to explain how their solution covers the same business work.

Let the comparable scope point to the implementation path

The proposal comparison may show that the approaches belong to different stages. If the workflow is contained inside one product, reversible, and owned by your team, a self-serve tool may be enough. If the owner, rules, data, or exceptions are unclear, discovery may be the useful next purchase because the team is not ready for a build estimate.

A pilot fits when the workflow is defined but important questions need evidence from representative cases. An automation platform can fit a stable, well-understood handoff between systems. Deeper integration, custom rules, sensitive access, or a handoff your team cannot maintain may justify implementation support. Keeping the work manual remains a valid decision when the review burden, failure cost, or maintenance need outweighs the expected value.

Use the AI implementation path decision matrix after you normalize the proposals. If one proposal sells planning while another sells a working test, compare AI discovery and an AI pilot before asking either side to revise its total.

Compare one workflow before choosing a proposal

A useful final comparison should fit on a few pages: the workflow as it runs today, the shared test boundary, the scope-status table, the recurring-cost and maintenance notes, the work that stays manual, and the material questions each proposer must answer. That is enough to determine whether the prices describe comparable work.

BaristaLabs uses AI consulting to help owners define one workflow, compare implementation paths, and name the evidence needed before a larger commitment. If you already have competing proposals, compare one workflow before choosing between totals that may describe different jobs.

Source note

The NIST AI RMF Playbook provides voluntary suggestions rather than a checklist or mandatory sequence. Its live pages currently note that AI RMF 1.0 is being updated and that the Playbook will be updated after the framework revision. The one-workflow proposal method in this article is BaristaLabs guidance informed by NIST’s context, baseline, third-party, and failure-cost considerations and by the SBA’s small-test and human-review guidance.