Print this, or open it on a second screen during the call. Every blank exists because a specific number needs to go there before you're allowed to quote a price. Fill it in while the client is still talking, not afterward from memory, because the exact figures fade fast once the conversation moves on.
The logic underneath the blanks is simple: cost is your floor, value is the client's ceiling, and your price lives somewhere between the two. This sheet walks you through capturing the inputs for both numbers, then gives you the checks that tell you whether the deal is sound before you put a figure in writing.
Step 1: capture the baseline
Get every field below filled in before you leave the discovery call. If a field is unknown, write "unknown" rather than skipping it. A gap you can see is safer than a gap you forgot existed.
- Process name and owner: ______________________
- Volume per period (per day, week, or month): ______________________
- Minutes or hours per item: ______________________
- People involved (how many, which roles): ______________________
- Loaded labor rate (not the salary alone: wages plus payroll costs, benefits, and management overhead): ______________________
- Failure frequency (how often the process breaks or a step is missed): ______________________
- Cost per failure (rework, refunds, missed deadlines, churn, rush shipping): ______________________
- Current cycle time (start to finish, one full pass): ______________________
- Current capacity limit (the point at which the process breaks under volume): ______________________
- Current software and infrastructure cost: ______________________
If the client doesn't know an exact rate or cost, write down a conservative range and label it as an assumption. You'll carry that label into the proposal rather than presenting a guess as a fact.
Step 2: calculate the value
Work through each line that applies. Not every project touches every line. Use the ones the baseline actually supports, and don't force a number where the client has no basis for one.
Annual labor capacity Volume per period × time per item × loaded labor rate × periods per year This is usually your easiest, most defensible number, because it's built entirely from data the client already has.
Avoided error cost Incidents per month × average cost per incident × 12 × expected reduction Error cost can include refunds, rework, missed appointments, scheduling failures, penalties, churn, rush shipping, or the time spent on customer recovery. Use documented history where it exists. Don't treat every possible incident as a guaranteed one.
Revenue capacity Additional qualified opportunities × contribution per outcome × realistic conversion rate Use contribution (what's left after variable cost) rather than gross revenue, whenever margins are meaningful. A deal worth several thousand dollars in revenue might carry only a fraction of that in contribution, and the smaller number is the one that will hold up under questioning.
Hiring cost avoided Avoided annual loaded cost + recruiting, onboarding, and management cost Be precise with the language here. Recovered capacity rarely means a role gets eliminated outright. More often it means the same team absorbs more volume, or a hire gets postponed. Present the version of the benefit that's actually expected, not the most dramatic one.
Confidence adjustment Estimated value × confidence level Not every value line deserves equal weight. Direct labor time backed by reliable volume and rate data earns high confidence. Avoided errors supported by a few months of records sit in the middle. Future revenue that depends on adoption or market conditions belongs at the low end. A $60,000 projected benefit at half confidence contributes $30,000 to your conservative case. Show the full, unadjusted figure separately if it's useful context, but build your price on the adjusted number.
Watch for double counting. If recovered staff time is what lets the business serve more customers, you may be counting the same capacity twice: once as labor savings, once as new revenue. Ask whether each value line could happen on its own. When two lines clearly overlap, keep the stronger one as your primary case and treat the other as supporting color, not an addition.
Step 3: calculate your floor
Value sets the ceiling. Cost sets the floor, and the floor is what keeps the engagement responsible for your business regardless of how large the ceiling looks. Total up:
- Expected delivery labor (design, development, testing, documentation, training).
- Testing and evaluation.
- Specialists and contractors (security, legal, data, or industry expertise).
- Project management and client communication.
- Temporary tools and infrastructure.
- Risk reserve for known uncertainty.
- Required profit.
The margin check Required price = delivery cost ÷ (1 - target margin) Express your target margin as a decimal when you divide: 0.6 for a 60 percent target margin. Worked example: if delivery is expected to cost $6,000 and your target margin is a 60 percent target margin, the required price is $15,000. If the client's credible value only supports $10,000, the project needs to change: smaller scope, a different delivery model, or walking away, not a price that makes professional delivery impossible.
Step 4: set the corridor
You now have two numbers: your cost floor from Step 3, and your credible value ceiling from Step 2. The corridor between them is where a real price lives.
- Starting range: 10% to 20% of credible first-year value is a reasonable opening point, not a rule. Scope, risk, proof, competition, and the client's alternatives all move you inside that range.
- The 10:1 sanity check: divide credible first-year value by your proposed price.
- 10:1 or better: usually easy to explain in one sentence.
- 5:1 to 10:1: can still be a strong project if the value is reliable and the work is strategic.
- Below 5:1: revisit scope, price, or your value evidence before you quote.
- The decision: if the value ceiling clears the cost floor with healthy room between them, proceed. If the corridor is thin, reduce scope until it isn't. If you can't see the corridor clearly yet (the data's too soft, the risk too unclear), sell a paid discovery phase before you commit to a fixed number.
The discovery question bank
Bring these into the call itself. Let the client talk first; these questions are for pointing the conversation, not for reading off a script.
Current state
- Which department is currently the most expensive in terms of manual labor?
- If your team gained five extra hours each week, what would they focus on?
- How long does this take today?
- How many people touch it?
- How often does it happen?
- What systems are involved?
- How long does one cycle take?
- How many cycles happen each week or month?
- What is a reasonable loaded rate for that team?
- What happens when it goes wrong?
- How often does failure happen?
- What does one failure cost?
Future state
- If your leads doubled tomorrow, what would break first?
- What process is currently limiting your ability to grow?
- Where are you turning away work, delaying customers, or adding headcount?
- What becomes possible if this bottleneck disappears?
Urgency and alternatives
- Why is this important now?
- What happens if nothing changes for another year?
- Why not buy an existing tool?
- Why not build it internally?
- Who else needs to approve this?
Milestone quality checklist
Before you write a milestone into a proposal, run it through every field below. If you can't fill in all seven, the milestone isn't ready to attach a payment to.
- Artifact: What exists at this point?
- User: Who can access and test it?
- Input: What exact event or prompt starts the test?
- Behaviour: What must the system do?
- Threshold: What measurable bar must it meet?
- Evidence: What log, recording, report, or test result proves it's done?
- Exclusions: What is intentionally reserved for a later milestone?
The difference this checklist protects against is objective versus subjective language. "A proof of concept is available to the business owner. When the owner submits a question, the system retrieves information from the agreed database and returns a response within one minute" is testable. Anyone can check it and get the same answer. "The inbox agent is working as expected" is not; it's an opinion waiting to become an argument, and arguments are what stall payment.
Pre-send proposal checklist
Run through these five groups before a proposal leaves your inbox.
Business case - Opens with the client's current state, in their words and numbers. - Client-supplied assumptions are visible, not buried. - The desired outcome is measurable. - Guaranteed scope is clearly separated from projected upside.
Scope - Systems, data, users, volume, and environments are named. - Included functionality is explicit. - Exclusions are explicit. - Client responsibilities and access deadlines are explicit.
Commercial terms - Each option has a clear outcome and price. - Payment dates or milestone events are clear. - Production utilities (API usage, hosting, tokens) sit in the client's account. - Estimated run cost includes a volume assumption and is labeled as an estimate. - Maintenance and new functionality are priced and described separately.
Acceptance - Every milestone can be tested. - Success thresholds are objective. - Evidence required for completion is named. - Response windows and what happens if the client goes quiet are defined.
Proof - Baseline metrics are recorded before the build starts. - Launch, 30-day, and later reviews are already scheduled. - The client knows exactly how results will be measured.
Common pricing mistakes
A quick scan before you hit send:
- Quoting before discovery. A fast number feels helpful and gets expensive later.
- Pricing only from hours. Your effort sets your floor. It says nothing about the client's ceiling.
- Counting only labor. Check errors, delay, capacity, retention, contribution, and risk too.
- Treating gross revenue as guaranteed value. Use contribution, and discount uncertain projections with a confidence adjustment.
- Double counting. The same recovered capacity can't be both a labor line and a revenue line unless they truly happen independently.
- Selling one vague package. Give distinct options, and make the scope and value difference between them explicit.
- Writing subjective milestones. "Expected," "intuitive," "complete": each one is an argument waiting to happen unless it has a measurable definition attached.
- Discounting instead of reducing scope. A lower price for the same scope teaches the client your numbers are negotiable. Offer a smaller complete result instead.
- Calling unlimited improvements maintenance. Maintenance keeps agreed behavior working. New functionality is a new scope, priced separately.
- Skipping the after-state. A successful project with no measured proof is a weaker asset than it should be. Put the review dates on the calendar before launch, not after.