How to review an automation proposal: eight warning signs in the fine print

The price is rarely what gives away a weak automation proposal. The questions it leaves unanswered are. An expensive quote can be sound, and a cheap one can turn expensive once the gaps show up on invoices. So when you review an automation proposal, look for what is missing first and compare totals second.

Reviewing an automation proposal: a worked example

Say a wholesaler wants orders that arrive by email to land in the ERP automatically. The proposal reads roughly like this:

> Order intake automation including AI recognition. Concept phase with three workshops, followed by implementation on our platform. Flat fee EUR 9,800. Additional requirements billed on a time-and-materials basis. Platform licence EUR 390 per month, minimum term three years. Support subject to availability.

This text is made up for illustration, and it looks perfectly professional. It also contains almost every one of the eight warning signs below.

1. The process is a heading, not a scope

"Order intake automation" names the process without describing it. What happens to an order with no item numbers? To "same as last time, but double"? To a different delivery address, or to an email that is really a complaint?

A solid proposal lists the cases it covers and the ones that get routed to a person. Without that list, the vendor priced the happy path. Every other case becomes an "additional requirement" later.

2. The price arrived before anyone looked at your systems

Whether your ERP has an API, offers a test environment or only exports files changes the effort a lot. A vendor who quotes a flat fee before asking has either padded the number or plans to renegotiate.

Ask which systems the price assumes. If the proposal does not name a single one, you have your answer.

3. The fixed price has a back door

"Additional requirements billed on a time-and-materials basis" turns any flat fee into an open-ended one. Who decides what counts as additional? The party writing the invoice. Combined with sign 1, this means every exception nobody wrote down is billed on top.

A real fixed price covers a written scope. Anything beyond it is quoted separately, again at a fixed price, and you decide whether you want it. Our piece on fixed price versus hourly billing explains why the estimation risk belongs with the vendor.

4. You do not own the result

"Implementation on our platform" often means the workflow lives in the vendor's account and stops when you cancel. Check whether you receive the source code or configuration, whose name the accounts are in, and whether documentation is part of the delivery. A three-year minimum term with nothing handed over is rent. More on that in our article on vendor lock-in.

5. Running costs are a fee with no contents

In the example, licence fees over the minimum term add up to EUR 14,040, well above the build price. The proposal does not say what that money buys.

Ask what the monthly fee covers. If it is compute and language model usage, it should be billed by consumption so you can see what your volume actually costs. If it is maintenance, the proposal should say what gets maintained: who notices when a connected system changes its interface, and who adapts the workflow when it does.

6. Acceptance is not tested on real cases

The example has no acceptance criterion. That means the automation counts as done when it runs, not when it books your orders correctly.

Useful acceptance works like this. You provide a set of real order emails from the past, including the awkward ones. The agent processes them, and you check together which orders were created correctly and which were cleanly flagged for review. The project is accepted when that result holds up.

7. A long concept phase comes before anything works

Three workshops, then a concept paper, then the build. You pay throughout and see nothing running until the end.

An agent for a clearly bounded process can be built in one to two days, with testing on real cases in the same week. The questions other vendors schedule workshops for are answered fastest with a working draft in front of you: you see what the agent made of your order email and point out what is wrong. Larger projects can be split into stages that each deliver something within days.

8. Nobody says what happens when something goes wrong

"Support subject to availability" does not tell you what happens when the agent cannot match an order, when the ERP is down, or when the same email arrives twice. A good proposal describes the exception path: where unclear cases go, who gets notified, and at which points a person approves before anything reaches a customer. It should also state where data is processed and include a data processing agreement.

What the alternative looks like

Sophera Consulting writes proposals that answer all eight questions. The fixed price comes after the selection step, once systems and exceptions are known, and it covers a written list of cases. You own the code, with no subscription. Every automation comes with a maintenance agent included in the fixed price, which checks the interfaces for changes and tests them against past cases. The only ongoing cost is AI model usage, billed directly to you. The starting point is the free automation check.

Our recommendation

Put the proposals you have side by side and go through the eight points. Wherever a proposal is silent, ask in writing and have the answer added to the document. A vendor who does that without fuss has done the math. One who dodges is counting on change requests. Compare prices only after that.