Deployed Works Guide
How To Write A Short Proposal After The First Call
Use this guide to write a short proposal that helps the buyer decide without burying the first deployment in unnecessary detail.
How To Write A Short Proposal After The First Call guide trailer
A short walkthrough for this guide will appear here.
Audience
Providers writing proposals after a first call
Time
9 minutes
Outcome
A concise first-phase proposal template
Share this guide
PDF guide
Download and share with your friends and colleagues.
Download this guide as a PDF and share it with your friends, colleagues or team. The web guide remains the canonical version.
Related guides
Before / after transformation
Turn a role-shaped advert into a capability brief.
Use this sequence when a need starts as a job title but the real requirement is deployed capability.
Start
Role label
Senior developer, automation consultant or product manager. Useful shorthand, but not enough to brief the work.
Diagnose
Current problem
What is manual, blocked, risky, slow or unclear today? Preserve concrete workflow details.
Shape
Deployment brief
Outcome, scope, must-haves, timeline, budget signal and what good looks like.
Review
Human-reviewed shortlist
Use fit indicators and human review to start fewer, better conversations.
Guide summary
What this guide helps you do
Who it is for
Best fit readers
- Providers following up after a first discovery call.
- Consultants and specialist teams proposing a diagnostic or small deployment.
- Providers who want commercial clarity without a long deck.
- Anyone writing a first proposal from a capability profile conversation.
The problem
CV language hides deployable value.
Providers often overbuild proposals because they want to look professional. Buyers usually need something clearer: restated problem, first phase, outputs, boundaries, price, assumptions, risks and the next decision.
Step by step
Build the profile around capability.
Keep it short
Aim for one to three pages. The proposal should help the buyer decide the next step, not document every possible future phase.
Restate the problem
Start with the buyer's situation in their language. Show that you understood the capability brief and first call.
Define the first phase
Name whether the next step is a paid diagnostic, scoped delivery, audit, implementation, advisory phase or handover-focused work.
Describe outputs and boundaries
List what the buyer receives, what is out of scope, what access you need and what assumptions affect delivery.
State price and assumptions
Give a price, range or commercial model that matches the scope. Include assumptions that would change the price rather than hiding them.
Set timeline
Show the expected start, duration, review points and buyer response needs. Timeline should include the buyer's decisions, not only your work.
Name risks and exclusions
Write down known risks, proof gaps, data issues, access dependencies and exclusions. Clarity builds more trust than pretending there are no risks.
Use the proposal template
Close with the decision required: approve, clarify, run a diagnostic, change scope or pause.
Example
Use this on Deployed Works
After a first call, a provider sends a two-page proposal for a five-day diagnostic. It restates the workflow problem, lists outputs, includes the fixed fee, names access needs and says a build proposal will only follow if the diagnostic shows automation is sensible.
Template
Short provider proposal template
Proposal for: Buyer: Provider: Date: 1. Problem as understood 2. Recommended first phase - Diagnostic / scoped delivery / advisory / handover: - Why this is the right first step: 3. Outputs - - 4. Boundaries and exclusions - - 5. Price and assumptions - Price/model: - Assumptions: - Buyer inputs needed: 6. Timeline - Start: - Duration: - Review point: 7. Risks and open questions 8. Decision needed
Common mistakes
Avoid these traps
- Writing a long proposal before the buyer has agreed the first phase.
- Hiding assumptions that change price or scope.
- Skipping exclusions because they feel negative.
- Promising outcomes that depend on buyer access or data quality.
- Leaving the buyer unclear on how to say yes.
Checklist
Ready to publish when
- The proposal is short.
- The buyer problem is restated.
- The first phase is clear.
- Outputs, boundaries and exclusions are visible.
- Price and assumptions are stated.
- Risks and next decision are included.
FAQ
Questions this guide usually raises
Should I send a deck?
Only if it helps the buyer decide. A concise written proposal is usually better for a first deployment because it makes scope and assumptions easier to inspect.
Can I propose a diagnostic instead of delivery?
Yes. If the work is not clear enough to price responsibly, propose a paid diagnostic and explain what it will produce.
Should I include proof again?
Include the most relevant proof briefly, especially if it supports confidence in the proposed first phase.
Take it with you
Download and share with your friends and colleagues.
Download this guide as a PDF and share it with your friends, colleagues or team. The web guide remains the canonical version.
Share this guide
Use the canonical page link. No social scripts or tracking widgets are loaded.
Use the guide
Turn your work into a capability profile.
A provider guide for turning a first buyer call into a concise proposal with scope, price, assumptions, risks and next step.