Proposals
What belongs in an AI automation proposal.
Eight sections, in the order each one becomes answerable. It works for an n8n workflow, a hosted agent or something you wrote yourself, and it does not require any particular software — including this one.
The structure
Eight sections, in this order.
The order matters more than the wording. Each section is unanswerable until the one above it has been answered, which is also why proposals written back-to-front end up as a price with a paragraph of hope attached.
Where the usage number comes from →The outcome, in their words not yours
One sentence naming what changes for the client. Not “an n8n workflow with an OpenAI node” — the thing their colleague would notice. Clients are not buying workflows; they are buying a result, and a proposal that opens with an architecture has already lost the reader it needed.
The problem, quantified by them
How often it happens now, how long it takes, and who does it. Ask them for the number rather than supplying one — a figure they gave you is a figure they cannot dispute later, and it is the only honest basis for talking about value.
What is in scope, and explicitly what is not
The out-of-scope list is the more valuable half and the one usually missing. Every case you have thought of and decided not to handle belongs there, in writing, before anybody hits one.
What it may reach, and what it may never do alone
Which systems it reads, which it writes to, and which actions require a person to approve first. A buyer with a security team will ask for this; a buyer without one should be given it anyway.
The price, as three separate numbers
A one-time build, a recurring amount for keeping it running, and the usage the client pays for on top. Folding them into one figure makes every later conversation — a change, a busy month, a renewal — a renegotiation of the whole thing.
A band, not a number, for usage
An included volume with a stated rate above it. Predictable for them, and it means a heavy month is arithmetic rather than an awkward email.
What happens when it breaks, and what counts as broken
Who to contact, what you will do, and the line between fixing what you built and building something new. This is the paragraph that decides whether maintenance is a retainer or an argument.
What they are agreeing to, and when
A dated scope they accept before you start. The single most repeated piece of advice among people who do this work is that a scope agreed in writing beforehand is what makes “one quick extra thing” stop happening.
Five ways it goes wrong
The ones that cost money later, not now.
- Leading with the tools. The stack is an implementation detail and it dates the document — the client cares what changes on Tuesday morning, not which nodes are in the canvas.
- One number for everything. It hides the recurring revenue you are trying to build, and it turns the first change request into a fight about the whole price.
- No out-of-scope list. Everything you did not write down is, by default, something the client thinks they bought.
- No ceiling at all. An automation with no ceiling is a bill with no ceiling, and the person who eats the difference is you.
- Sending a PDF. It cannot be updated after it is sent, you cannot tell whether it was read, and the version they quote back at you in four months is whichever one they downloaded.
In Tolavo
The parts that should not be retyped for every client.
None of this writes the proposal for you. What it removes is the retyping, and the two places retyping goes wrong: a figure that drifts between documents, and a set of terms that quietly changed after somebody read them.
One product, priced once
Define the system, its plans and its limits once. Every proposal after the first starts from that rather than from an empty page, and the publish gate refuses a product with no pricing, no stated limits or no support contact.
A page the client opens, not a file they download
The proposal is a link to a private page with no account and no login behind it. It is addressed by a token that is a credential — stored only as a hash, shown to you once, and reissuing it retires the old one immediately.
Terms freeze the first time the buyer opens it
The figures they are reading, the price per extra run included, are snapshotted at that first visit with a fingerprint, and from then on an edit to them is refused rather than warned about. Acceptance records who agreed, their email and the address they agreed from, against exactly the terms that were frozen and their fingerprint. Change your price later and it changes what you offer next — never what they already read.
They pay you, directly
The payment request carries your own rail — your payment page, your invoice, your bank details. Tolavo never collects, holds or routes your client’s money, takes no cut, and has no mechanism that could. A link pointing back at Tolavo is refused rather than discouraged.
Access follows the money
Nothing is provisioned until a receipt has actually been recorded, and it can only happen once.