Proposal Builder

# Proposal Builder

Turn discovery into a document the customer can sign.

The pain here is blunt: owners describe spending a two to three hour evening per lead turning voice notes and photos into a proposal, with the format coming out different every time. Services businesses grow by quoting, and quoting is the bottleneck.

## Step 1 — Ask where the discovery lives, then read it

Many connectors can feed this skill, so do not sweep them all. **Open with one question: where should the material come from?** List only what is actually connected as the choices — for example Zoom (call transcripts), Notion (meeting notes and transcripts), Drive or M365 (documents), Gmail (a forwarded thread) — and always include "upload or paste it here" as a first-class option. The owner picks; only the picked sources get searched. This is faster for them and stops the skill rummaging through tools that have nothing to do with this job.

Take whatever form the discovery arrives in. All of these are normal inputs:

- A call or meeting transcript, from Zoom or a recording. Zoom is read-only and reaches only meetings the owner hosted or attended, and a recordings search covers a one-month window per call — so ask for one month at a time and walk back rather than requesting a range it will not return - A call transcript or meeting notes kept in Notion, when connected — search only the page or database the owner points at, read-only - A voice memo recorded walking back to the truck - Jobsite photos, drawings, or plan sheets - An RFP, RFQ, or solicitation document - A few lines of notes typed on a phone, pasted straight into chat

Extract into a structured picture: what the customer wants, what constraints exist, what's ambiguous, what's explicitly out of scope, and any date or budget mentioned. See `reference/discovery_extraction.md` for how to read each input type, including what photos and drawings can and cannot tell you.

**Name the gaps out loud.** A proposal built on a guessed square footage is a proposal that loses money. List what's missing and either ask or state the assumption in the document itself.

### Optional — research the lead (Apollo)

With Apollo connected, offer once before pricing: "Want me to research [company] first?" This is the owner's call — on a no, or with Apollo not connected, skip silently and build from the discovery inputs alone.

On a yes, pull the company's profile: size, industry, location, growth signals like hiring or a new opening, and the right contact with their title. Use it two ways — sharpen the proposal's framing (a 12-person shop reads a different pitch than a 300-person operation), and confirm the document is addressed to the right person. Report what was found in two or three lines before drafting, and name Apollo as the source.

**Research is context, never pricing.** No Apollo signal changes a rate — pricing comes only from Step 2's comparables. And nothing found in research goes into the customer-facing document as a claim about them; it shapes tone and framing, not content.

## Step 2 — Price it from history, not from scratch

Read `reference/pricing_method.md`. The core rule: price from what this owner has actually charged for comparable work, not from a general estimate.

Pull comparable jobs:

- **The connected ledger** (MYOB, NetSuite, QuickBooks, Xero, or Zoho Books) — past invoices for similar work, with line detail. Zoho Books: `list_invoices` and `list_estimates` by customer or item, with `list_items` for the catalogue rates. Ledgers are peers (`../../shared/connector-neutrality.md`) - **A payments connector** (PayPal, Square, or Stripe) — charge history by customer when no ledger is connected; amounts only, no line detail - **Uploaded price list or rate card** — the common case - **Past proposals** — from Drive, M365, Confluence, or uploaded; a connected store is read only once it is confirmed as the owner's (`../../shared/tenant-scope.md`)

Find two or three genuinely comparable jobs and build from them, adjusting for what's different. Show the owner what you compared against, because that is what lets them trust the number in ten seconds instead of rebuilding it.

**Never invent a rate.** If there is no comparable and no rate card, leave the line at a placeholder, say clearly that it needs the owner's number, and build everything else around it. A proposal with one blank the owner fills in beats one with a fabricated figure they have to hunt for.

## Step 3 — Build the document on their template

Use the owner's existing proposal template when one exists — from Drive, M365, Confluence, or uploaded. Matching their format matters more than improving it. A proposal that looks like their other proposals gets sent; a beautiful unfamiliar one gets rebuilt by hand.

**Confluence, when Atlassian is connected, is a template and historical-document source.** Search spaces by CQL for past proposals, scope boilerplate, standard terms, and rate pages, and read the pages directly. Th