Proposals

Principles⁠

Write the proposal once⁠

Most of what you send has been sent before. Keep your venue text, packages and prices in a library, then build the next proposal out of blocks you already trust instead of copying last month's file and hoping you caught every number.

A proposal is a document, not an email⁠

It has a number, a status, a version and an owner. When the proposal is a real object in the system, you can see what was sent, what changed and what the client agreed to, without reading back through a thread.

Let the numbers come from the calculation⁠

Price per person, margin and totals belong to a calculation, not to a typed line in a table. Change the guest count and everything downstream follows. Nobody has to remember which cell to update.

Signing should take one tap⁠

Your client should be able to read the proposal and agree to it on a phone, in one place, without printing, scanning or finding a desktop.

One editor at a time⁠

Two people editing the same proposal is how a price gets lost. Opening a proposal claims it, and your colleague sees who has it. Collaboration works better when it is explicit.

A signed proposal should become the work⁠

Agreement is a hand-off, not a filing action. A signed proposal turns into the event and into the invoice, carrying its line items with it, so nothing is retyped at the point where mistakes cost money.

Practices⁠

Build a block library⁠

Group your standard text, packages and products into categories and reorder them to match how you sell. Drag a block in and it arrives with its price and its description already correct.

Start from a draft, not a blank page⁠

Create a draft against an event, or standalone when the enquiry has not become an event yet. Either way you begin with your own structure rather than an empty document.

Keep calculation templates for what you repeat⁠

A dinner package, a bar package, a build day. Save the calculation once, apply it per event, and adjust the parts that actually differ.

Duplicate the proposal that worked⁠

Copy a proposal, change the client and the date, and send it. The fastest good proposal is usually a previous good proposal.

Decide what the client sees⁠

Line items can be visible or hidden per proposal. Show the package and keep your internal purchase references to yourself.

Let the draft come from the enquiry⁠

The assistant reads the enquiry and proposes a first version with blocks and quantities filled in. You edit and send. The blank page is the slowest part of quoting.

Send, then watch the status⁠

Sent, viewed, signed. The status lives on the proposal, so following up is a decision you make from a list rather than a memory you rely on.

Let proposals expire on their own⁠

A validity date makes the proposal expire without anyone chasing it, which keeps your pipeline honest and your prices current.

Turn agreement into an invoice⁠

A signed proposal converts to an invoice with its line items and numbers intact, and to an event with its own tasks and run sheet. One action, no re-keying.