How to read an automation proposal, ignoring the number entirely

A proposal is a description of a system, not a sales document

The most useful reframe available to a buyer here is that a good proposal is a specification with a commercial section attached, and a bad one is a brochure with a total at the bottom.

You can tell them apart in about a minute. Read only the section that says what will be built, and ask yourself whether a competent stranger could take that section and build the thing described without phoning anyone. If yes, you are holding a specification. If it would raise twenty questions, you are holding a brochure, and every one of those twenty questions is a conversation you will be having later, under time pressure, with the meter running in whatever form your arrangement takes.

Scope: what is being built, and what finished means

Scope is where most disagreements originate, and they are nearly always visible in the proposal before anyone signs it. What you are looking for is whether each item names a behaviour or names a category.

• Every item should have a test attached. Not "missed call handling" but the condition that proves it works: every unanswered call receives a text within sixty seconds, verified across a full week including evenings.
• Ask what is explicitly out of scope. A proposal with no exclusions section has not been thought about. Every real project has boundaries and naming them is a sign of experience, not of meanness.
• Look for the order of work. A list of features is not a plan. Stages, each with something usable at the end of it, is a plan.
• Check whether anything depends on something not yet decided. If stage two needs a decision you have not made, that is a schedule risk sitting quietly in the middle of the document.

The words that hide scope

Certain terms appear in almost every proposal in this industry and mean almost nothing on their own. None of them are dishonest. They are just containers, and it is worth asking what is inside each one.

• Integration. The single largest source of unpleasant surprises. Which systems, in which direction, which fields, how often, and what happens when one of them is unavailable. Two way is much harder than one way and the word integration covers both.
• Support. Ask what it includes, what hours it covers, how you contact it, and what is specifically excluded. Support that means somebody will read an email eventually is a different product from support that means somebody is contactable when your booking system stops at six on a Friday.
• Optimisation. Usually means adjustments after launch. Ask how many, over what period, and who decides what counts as an optimisation rather than a new request.
• Training. Ask for the format and the audience. A recorded walkthrough for one person is not the same as a session with your whole team plus written material they can consult later.
• Maintenance. Ask whether it covers only keeping the existing thing working, or also the changes made necessary when a third party alters something. It is nearly always the first, which is reasonable, and it is worth knowing.
• Custom. Ask what it is custom relative to. A custom configuration of an existing platform and a custom-built system are both legitimate and are very different things to own.

Ownership: what you are actually holding at the end

This section is usually short or absent, which is itself informative. It determines whether the project leaves you with an asset or with a dependency, and both can be reasonable as long as the document says which.

• Whose accounts is this being built in. Platforms, domains, phone numbers, model access. If the answer is the vendor's, the proposal should say so plainly and explain what happens if you part ways.
• What do you receive at the end. Named artefacts: workflows, code, configuration, credentials, documentation. If a proposal does not list deliverables you can hold, it is describing a service.
• Is documentation a line item. If it is not written down, it will not exist, because it is the first thing to be squeezed when a project runs late. A proposal that names documentation as a deliverable is telling you something about how the firm works.
• Who owns the data the system produces. This should be you, without a discussion, and it should be exportable in a normal format.
• What is licensed rather than transferred. There is often something. Naming it is fine. Discovering it during an exit is not.

Clarity: could somebody else pick this up

This is the test that matters most in year two and that almost nobody applies in week one.

Imagine the firm that wrote the proposal is unavailable in eighteen months. Not through anything dramatic, just the ordinary attrition of small businesses. Could you hand this document, plus what it says you will receive, to another competent firm and have them understand what exists?

If the answer is no, you are not buying a system, you are entering a relationship with a single point of failure. That can still be the right decision, and plenty of good work happens that way. It should be a decision rather than a discovery.

1. Check that the stack is named. Which platforms, which services, which models. A proposal that will not itemise what it is made of cannot be handed to anybody.
2. Check that the workflows are described in terms of behaviour. Behaviour transfers between firms. Screenshots of a particular tool's interface do not.
3. Check for a handover section. What happens at the end of the engagement, in what format, over what period.
4. Ask whether they have taken over somebody else's build before. Firms that have done it write clearer documentation, because they have been on the receiving end of the alternative.

What is missing from almost every proposal

The most reliable way to judge one of these is by absence. These are the items that separate proposals written by people who have run systems in production from proposals written by people who have built demos, and most documents contain none of them.

• What happens when it breaks. Monitoring, alerting, who is notified and what falls back to a human. Its absence is the most common gap in the entire industry.
• What happens to work in progress during an outage. Does an enquiry arriving mid-failure get queued, lost, or routed to a person. Nobody asks this and it is where real money goes.
• Data retention and deletion. What is stored, where, for how long, and what happens on a deletion request. In Quebec this is not optional, and it is covered in the Law 25 guide.
• How success will be measured. A named measure, a baseline taken before the work, and a date to look at it. Without a baseline, every later conversation about whether it worked is a matter of opinion.
• What the model is allowed to say. For anything customer facing and model backed, the escalation rules are a deliverable in their own right, and a proposal that does not mention them has not thought about the part most likely to embarrass you.
• What you have to supply. Which brings us to the section people skip.

The dependencies clause, which is about you

Buried in most proposals is a short paragraph listing what the client will provide. It is usually read as boilerplate. It is the most predictive part of the whole document, because almost every automation project that runs late runs late here.

• Access to systems. Sounds trivial. In practice it means finding out who has the administrator password for something set up six years ago by somebody who has left.
• Answers to questions. The content the system will use, the policies it must follow, the rules for when it escalates. This is real work and it is yours. Doing it in advance is the single biggest thing a client can do to keep a project on schedule, and the artefact for it is in the context sheet.
• Decisions. Named people who can make a call within a stated time. A project waiting three weeks for a decision has not been delayed by the vendor.
• Testing and sign off. Somebody at your end has to look at it and say it behaves correctly, and that person needs the time to do it properly.
• Existing data in a usable state. Frequently the real project. If the proposal assumes clean records and yours are not, that assumption will surface in week two rather than in the document.

Comparing two proposals honestly

The most common mistake in comparing proposals is treating them as two answers to the same question. They are usually answers to two different questions, because each firm scoped the problem the way it understood it.

1. Write out what each one actually includes, in your own words, side by side. Not their headings, yours. Differences that were invisible in two documents become obvious in one list.
2. Mark what appears in only one of them. That is where the real difference lives. Monitoring, documentation, handover and testing show up in exactly one proposal remarkably often.
3. Check whether they are solving the same problem. One may be automating the whole enquiry path while the other automates the reply. Both are legitimate. They are not comparable.
4. Ask each firm to explain the other's approach. Not to criticise it, to describe it. A firm that can explain the alternative fairly and say why it chose differently is showing you judgement. One that dismisses it is showing you something else.
5. Only then look at the commercial section. By that point you know what each one buys, which is the only condition under which comparing totals means anything at all.

What this guide deliberately does not tell you

It does not tell you whether a number is reasonable, and it will not, for two reasons that are worth stating plainly rather than leaving as a curious omission.

We do not publish figures anywhere. No brackets, no ranges, no indicative numbers. A number without a scope is a guess, and a guess published on a website becomes the thing people compare against regardless of whether their project resembles the assumption behind it. Our own answer is the same in public as it is in a meeting: work is scoped per project, you get a fixed number after a discovery call, and we do not bill by the hour.

And the number is genuinely not where the risk is. The projects that go badly in this industry rarely go badly because the commercial terms were wrong. They go badly because the scope was a category rather than a behaviour, because nobody wrote down what happens when it breaks, because the documentation never existed, or because the thing was built in an account the client did not control. Every one of those is legible in the proposal before anybody signs anything.

The questions to ask about the firm rather than the document are in what to ask an automation vendor, and the two are meant to be read together.