Writing client proposals with AI

How the bot works

Nine steps. Reading the intake, assembling approved scope blocks, looking up rates and expense rules, and diffing what was carried over are ordinary code and cost almost nothing to run; the model is only asked to write the prose around material you have already approved.

1. It starts from the discovery you already did. The call notes, the intake form, the requirements the client sent, the transcript if you keep one. A blank document and a prompt describing the client is not an input.

2. Scope is assembled, not written. Each deliverable is a block out of your approved scope library — the words you have sold before and stand behind. A request with no matching block comes back as a question, not as a paragraph the model composed.

3. Every price is a lookup. Rates, minimums, unit prices, tiers and discounts off your rate card, read by ordinary code. The model never writes a number, because a plausible wrong price is worse than a line that is obviously missing.

4. A line with no approved rate is held. New work, a mix nobody has priced, a term outside your card. The line stays on the draft marked as held, with the question attached, so the proposal cannot go out with a number nobody chose.

5. Expenses, travel and terms come out of your rules. Travel, per diem, after-hours, mileage, pass-through costs and payment terms are rules you wrote once. They are applied, not reasoned about, and the rule that produced each line is named.

6. Nothing is carried over silently. A rate from an earlier proposal, a bio, a reference, another client's details. Anything reused is shown as a diff against the library so a reviewer can see what came from where before it is sent.

7. The assumptions and exclusions are written down. What the price assumes, what is out of scope, what changes it, and what happens when the client adds something later. A proposal that leaves those blank is one nobody can check a later request against.

8. A person approves the scope and the price together. The draft waits with the held lines, the assumptions and the diff on top. Somebody named approves the version they read, and that version is the file that goes out. The bot does not send it and does not request a signature.

9. It tells you which parts of your library are missing. The requests that had no scope block, the work with no rate, the terms that had to be written by hand every time. That list is the useful output in the first month, because it names the parts of the library that do not exist yet.

What you configure

It can be configured to run in any business. This is what that actually means — the list of things that are yours, not ours.

Your scope library

The approved blocks, what each one includes and excludes, which ones go together, and who may add a new one.

Your rate card

Rates, minimums, units, tiers, effective dates and which card is current — the only place a price may come from.

Your terms and expense rules

Payment terms, travel and per diem, after-hours rates, pass-through costs, and the clauses that go on every proposal.

Your assumptions and exclusions

The standing list, which ones are required on every proposal, and which are added by the kind of work in scope.

Your discount rules

Who may discount, within what limits, and what has to be true first. Nothing is discounted by a run — an out-of-limit request is held for a person.

Your document

The sections, the order, the template, the length, and what a one-page version leaves out when a client asks for a short one.

Your reuse rules

What may be carried from a past proposal, what must be re-approved, and how old a rate is allowed to be before it is a flag.

Your approvers

Who approves scope, who approves price, what thresholds need a second name, and who owns a held line.

Your release switches

Which proposals may be assembled automatically from an intake form, which wait for somebody to ask, and whether the finished file is delivered anywhere at all. Sending is off, and signature requests are not a feature.

Transparent, and configurable by you

The dark band below is what the system will not do. This is what you can see and change — and it is how we build everything, not something invented for this page.

You see what it did, and why

Every line on the proposal names where it came from — the scope block, the rate card entry and its effective date, the rule behind an expense line — and every draft records the intake it read, the lines it held, the diffs against the library, the questions it raised and who approved it.

Versioned prompts you can tune yourself

The scope library, the rate card mapping, the assumption list and the prompts behind the prose are yours to tune. A change is a reviewable diff, replayed against proposals you have already sent so you can see what it would have written differently, and rolled back the same way.

A human in the loop wherever judgment actually matters

Reading the intake, assembling scope, looking up every price and diffing the reuse are automatic. Deciding what to sell, what to charge, what to concede and whether this client is worth a custom answer are a person's — that boundary is a property of the system, not a promise about how carefully we'll use it.

Every run logged, along with what it cost

One row per draft and one per held line: the intake, the blocks used, every price with the rate card entry behind it, the assumptions applied, the questions raised, who approved the file and where it went — plus token usage and cost for that run.

It can be configured to run in any business. The library and the card are yours: your scope, your rates, your terms, your limits, your approvers. The proposals on this page are one configuration of it, not the limit of it.

Works with your tools

This writes proposals in the document your clients already receive, from the systems you already run. We're not selling you a proposal platform, and your rate card stays the record.

• A proposal or RFP tool
• HubSpot
• Salesforce
• Pipedrive
• A PSA or professional services tool
• Google Drive, SharePoint or Dropbox
• Microsoft 365 and Word
• A rate card in a spreadsheet

Works well for

• IT services and managed service providers — Scope and pricing tiers are standard, and the last proposal is where the next one starts.
• Consulting firms — Rates, roles and phases are already defined, and travel and expense terms sit on every proposal.
• Accounting and bookkeeping firms — Recurring service packages with add-ons, quoted over and over against the same rate card.
• Marketing agencies — Retainers and project work from the same list of deliverables, priced per client.
• Commercial cleaning companies — Scope depends on the site and the schedule, and the same lines come back in a different mix.

How a rollout works

Nothing is sent on day one and nothing is signed, ever. The first milestone is proposals you have already sent, rebuilt from your own library and card, so you can compare them line by line with what went to the client.

1. 01Discovery

   The quote call, then a working session. We go through the proposals you send today, which scope blocks you actually reuse, where the current rate card lives, your expense and payment terms, your standing assumptions, your discount limits and who approves what. You get the library map, the rate mapping and a written scope.

2. 02Dry run

   Proposals you have already sent, rebuilt. Nothing is delivered. You compare every price with the one that went out and read the held list — and the held list is where the work is, because every line on it is a price somebody is deciding by hand today.

3. 03Assisted mode

   Live on one kind of proposal. The bot assembles the draft, your approver reviews the scope and the price together, and the document goes out the way it always has. Who owns the client relationship does not change.

4. 04Optional limited automation

   Optional, and narrower than it sounds. A short list of proposal kinds you name, assembled from a completed intake form, still unapproved and unsent, with every hard stop in force and the kill switch. Plenty of teams stop at step 03, and that's a good place to stop.

What we don't claim

• No numbers we haven't earned. No win-rate claim, no proposals-per-week figure, no hours-saved number. We have not written your proposals. What a run takes and what it costs come out of the dry run, and they will be your numbers.
• No customer claims on this page. No names, no case studies, no logos.
• It will not tell you what to charge. Pricing is a decision about your business and your market. The bot reads the card you already maintain and refuses to improvise when the card is silent; building the card is a different kind of work.
• A proposal that assembles itself does not win the deal. The value shows up when the scope is the scope you sell, the price is the price on your card, and the assumptions are written down before delivery starts. What the client decides is still a human matter.
• If your scope and rates are not written down, this is library work first. A bot cannot assemble from a library that does not exist. Getting the blocks and the card written down is a real piece of work, and it is worth doing whether or not anything is automated afterward.

Questions people ask

Can AI write our client proposals?

Yes, from material you have already approved. An agent can turn your discovery notes into a scope made of blocks out of your own library, look every price up on your rate card, apply your expense and payment terms, write the assumptions and exclusions down, and hold the draft for a named approver. What it will not do is invent a price or write scope that is not in the library.

Where do the prices come from?

Your rate card, read by ordinary code rather than written by a model. Each line records the entry and its effective date, and a line the card has no rate for is held with the question attached instead of filled in.

Will it discount or negotiate?

No. A discount is a rule with a limit and an owner, and a request past that limit is held for the person who owns it. The bot does not negotiate, does not concede a term and does not talk to your client at all.

Can it write the statement of work?

It can assemble the scope section from your approved blocks, with the assumptions and exclusions attached, which is the part of a statement of work this design can assemble. The wording is yours and the approval is a person's; nothing is drafted from general knowledge.

What if the client asks for something we have never sold?

That comes back as a question rather than a paragraph. The draft shows the request, names the person who has to decide what it includes and what it costs, and holds the line until somebody answers.

Does it send the proposal or get it signed?

No. The approved file is handed to a person, delivery starts off, and requesting a signature is not a feature. Who sends the proposal and who answers for it does not change.

Is this the same as following up on a quote we already sent?

No, and they are deliberately separate. This writes the proposal. Chasing one that is already out and logging what the client said is a different bot with its own page, and so is answering a buyer's RFP from a sales answer library.

What if we don't have a rate card?

Then that is the first piece of work, and we would say so on the quote call. The design depends on a card somebody owns: without it there is no price to look up, and we are not going to let a model make one up.

Is there a record of how a proposal was built?

Yes, per draft: the intake it read, the blocks it used, every price with the rate card entry behind it, the lines it held, the diffs against anything reused, who approved the file and where it went - plus the token usage and cost for that run.