How to Write and Send Freelance Proposals with PayShield

A proposal is not a price quote in an email. It's a scoped document — one that sets expectations, demonstrates professionalism, and, inside PayShield, triggers a chain reaction the moment the client clicks Accept.

When that happens, the contract and project are created automatically. No re-typing scope into a separate contract. No copy-pasting milestones into a project tracker. No back-and-forth trying to remember whether you'd agreed on Net 30 or Net 14. The data you entered once flows forward, intact, into every downstream document.

That's the idea behind the proposal builder in PayShield: it's not a standalone document. It's the starting point for a complete engagement workflow. If you've been sending proposals out of Google Docs and then manually recreating the same information in your contracts, project boards, and invoices — this will feel like a significant shift. For the better.

Here's exactly how the proposal flow works, from blank page to active project.

Creating a proposal

Navigate to Proposals in the sidebar and click New. The first thing you'll do is associate the proposal with a client. If the client already exists in your account, select them from the dropdown. If this is a new client, you can add them inline — name, email, company, and timezone — without leaving the proposal form.

Project description

The description field is where you frame the engagement. Write it as if the client is reading it — because they will be. This is not an internal note. It's the narrative layer of the proposal: what the project is, why it matters, and what success looks like at the end of it.

Keep it specific. "Redesign the checkout flow to reduce drop-off on mobile" is better than "UX improvements." Specificity here does two things: it demonstrates that you understood the brief, and it makes scope creep easier to identify and push back on later, because both parties have agreed to a clearly stated objective.

Milestones and deliverables

Below the description, you'll break the project into milestones. Each milestone has a name, a description of the deliverable, and a due date (or a relative duration, if the project timeline isn't fixed yet).

This is the most important structural decision you'll make in the proposal. Milestones are not just organizational — they become the actual milestones in the project when the client accepts. The names you use here are the names that will appear in your project board, your client portal, and eventually your invoices if you're billing per-milestone.

Name them with that in mind. "Phase 1 — Discovery and wireframes" is a milestone name. "Draft stuff" is not.

Pricing models

PayShield supports three pricing structures, and you'll choose one per proposal:

• Fixed price — a single total for the entire engagement. Clean and predictable for both sides. Best suited for projects where scope is well-defined and you're confident in your estimate.
• Hourly — an estimated number of hours multiplied by your hourly rate. You set the cap, if any. Use this when scope is genuinely uncertain or when the client expects the work to evolve.
• Per-milestone — each milestone carries its own price. This is often the most client-friendly structure for larger projects: payments are tied to tangible outputs, and the client can see exactly what they're paying for at each stage.

You can mix per-milestone pricing with a retainer component if part of the work is ongoing — for example, a fixed fee for a one-time build phase plus a monthly retainer for support.

Timeline and payment terms

Set the estimated start date and project duration. If the project has a hard deadline, note it explicitly. Clients read this section carefully — it's often the first thing they check after the price.

Payment terms define when invoices are due relative to their issue date. Enter your terms as free text (e.g. Net 14 for most freelance work, Net 30 for larger clients with formal AP processes). Whatever you enter here becomes the default for all invoices generated from this engagement.

Add any special conditions in the terms field: late fee clauses, kill fees, revision limits, IP transfer conditions, travel expense policies. If it's important enough to negotiate, it belongs here — not buried in an email thread.

Case study references

The proposal builder includes a section for case study references: links or brief summaries of past work that demonstrates your experience with similar projects. Use it selectively. One or two directly relevant examples are more persuasive than a list of everything you've ever done.

Sending and tracking

Before you send, use the Preview button to see the proposal exactly as your client will see it — formatted, branded, with your contact details and their name at the top. Read through it once. Check the numbers. Confirm the milestone names are right. It takes two minutes and it's worth it.

When you're satisfied, click Send. PayShield delivers the proposal via email with a secure link that opens a read-only view in the client's browser. No login required on their end. They can review, accept, or decline directly from the link.

From that point, PayShield tracks the proposal's status automatically:

The Viewed status is useful. If a proposal has been viewed multiple times but not accepted after several days, that's a signal to follow up — the client is reading it, probably comparing you against alternatives. A brief, direct check-in at that point is often all it takes.

Proposal templates

Once you've sent a few proposals, you'll notice that the structure repeats. Save any proposal as a template and reuse it for similar engagements. Templates carry over the milestone structure, pricing model, and payment terms — all of which you'll customize per client. What you're skipping is the blank-page setup work.

Templates are especially useful if you offer tiered service packages. Build one template per tier, customize the client details and the project-specific scope, and you're ready to send in minutes instead of hours.

The auto-flow: proposal to contract to project

This is what makes the PayShield proposal different from a PDF you email someone.

When a client clicks Accept, three things happen automatically, in sequence:

1. A contract is created.

PayShield generates a contract pre-populated with the scope, milestones, pricing, payment terms, and special conditions from the proposal. Every field that you filled in is carried forward exactly as written. The contract is your legally structured version of the same agreement — not a translation, not a restatement, the same data in a document format designed for signature.

You'll receive a notification to review the generated contract before it goes to the client. Use this review step: read it as if you're seeing it for the first time. Confirm the payment schedule looks right. Confirm the milestone descriptions transferred cleanly. Then send it for e-signature.

2. A project is created.

Simultaneously, PayShield creates a project with the milestones from the proposal. Each milestone appears as a task on your project board, with the name, description, and due date you specified. The project is in a pending state until the contract is signed — but the structure is already there, ready to activate.

3. The project goes active when the contract is signed.

Once both parties have signed, the project flips to Active and the milestone timeline begins. From that point, you can track progress, log work, share updates with the client via the client portal, and trigger milestone-based invoices as deliverables are completed.

Why zero re-entry matters

The obvious benefit is time. You're not copy-pasting from proposal to contract to project board.

The less obvious benefit is accuracy. Every time a human manually transfers data between documents, there's a chance of drift — a milestone renamed slightly, a payment term misremembered, a due date entered wrong. When the proposal auto-flows into the contract and project, the three documents say exactly the same thing, because they're sourced from the same data.

That matters when there's a dispute. "The contract says Net 30 but the proposal said Net 14" is a conversation that shouldn't happen, and with PayShield's auto-flow, it can't happen. The proposal sets the terms. The contract reflects them. The project executes on them. The chain is unbroken.

Pro features

The proposal builder is a Pro-only feature. Free tier accounts cannot create proposals.

Unlimited templates. Pro accounts can save as many proposal templates as needed, which matters once you're running multiple service lines or targeting clients across different industries.

Custom branding. Pro proposals display your logo, your brand colors, and your custom domain — not PayShield's generic defaults. When the client clicks the proposal link, they see your brand, not ours.

Proposal analytics. Beyond the basic Viewed status, Pro accounts can see total time-on-page data: how long the client spent reading the proposal and how many times they returned to review it. This isn't surveillance — it's signal. A proposal that's been viewed multiple times without a response is a clear cue to follow up.

Tips for proposals that close

Scope tightly. The most common source of project friction is a proposal that was deliberately vague because narrowing the scope felt like losing the deal. It isn't. A scoped proposal that gets accepted creates a healthy project. A vague proposal that gets accepted creates a negotiation that never ends.

Every deliverable that's ambiguous in the proposal will become a point of contention during the project. "Design the website" is not a milestone. "Design five page templates: homepage, services, about, blog index, and contact — with one round of revisions per template" is a milestone. The client knows what they're getting. You know what you're delivering. Everyone is protected.

Include a kill fee clause reference. If the client cancels mid-project, what do you get? This should be stated in the proposal's terms and carried forward into the contract. The contracts guide covers kill fee structures in detail — but the principle belongs in the proposal, so the client agrees to it before the contract is even generated. No surprises, no renegotiation.

Use case study references strategically. Clients at the proposal stage are evaluating risk. Their core question is: have you done something like this before, and did it go well? A brief, relevant case study — one paragraph, a specific outcome, a recognizable industry or problem type — answers that question more effectively than a general list of past clients.

Keep the proposal length proportional to the project size. A three-page proposal for a $600 logo design is too much. A one-page proposal for a six-month, multi-deliverable engagement is too little. Match the depth of the proposal to the complexity and value of the engagement.

For a full overview of how proposals fit into the broader PayShield workflow — contracts, invoicing, escalation, client portals — see How to Use PayShield.