The practical idea
Start from buyer value, not tool excitement.
A proposal should reduce uncertainty. The buyer needs to know what problem is being addressed, what they receive, what remains manual, what you need from them, and how acceptance will be decided.
Technical choices belong in a short implementation note unless they materially affect price, security, ownership, or ongoing cost.
Worked example
One narrow service, made inspectable.
- Buyer
- A boutique marketing agency
- Repeated pain
- Weekly campaign notes are copied from several sources into an inconsistent client update.
- Offer
- A pilot that prepares one standardized weekly update for account-manager review.
- Proof
- Three fictional campaigns produce drafts matching an agreed template and exception list.
- Human approval
- The account manager verifies numbers, claims, and client-facing language before sending.
Do this in order
A four-step operating path.
- 1
Open with the buyer problem
Use the buyer's language and describe the current friction without exaggerating it.
- 2
Define the result and proof
Name the output and the test cases that will demonstrate acceptance.
- 3
Make boundaries visible
List exclusions, human decisions, access assumptions, ongoing costs, and ownership.
- 4
Close with one decision
State price, timeline, payment terms, and the next approval step.
Prompt for your agent
Replace the brackets, then ask Codex to help.
Draft a one-page proposal for this AI automation pilot. Buyer: [BUYER] Current workflow and pain: [PAIN] Proposed result: [RESULT] Evidence already demonstrated: [PROOF] Estimated timeline and practice price: [TIMELINE_AND_PRICE] Use these headings: Current problem, Proposed result, Deliverables, Acceptance tests, Human approval and safety, Exclusions, Buyer responsibilities, Timeline, Price and payment assumptions, Ownership and handoff, Next step. Use plain English. Do not promise revenue, guaranteed savings, perfect accuracy, or production integrations that have not been tested. Flag every missing fact for me to confirm.
Ready check
Keep these five facts visible.
- Buyer problem is recognizable.
- Deliverables are countable.
- Acceptance tests are objective.
- Exclusions and approval are explicit.
- Price assumptions are visible.
Avoid
Common ways this goes wrong.
- Leading with tools instead of the problem
- Copying a broad agency template
- Leaving ownership or ongoing costs unclear
- Guaranteeing results you cannot control
Primary references
Review the source, not just our summary.
Products and platform rules change. These links are the starting point for the next source refresh.
Published by Agentic Systems Academy Team. Educational information only. No client, income, ranking, or platform outcome is guaranteed.