Proposal Pipeline Build Doc

Solo Marketing Agency — Inbound Text to Sent Proposal

---

Overview

This stack automates the gap between a homeowner texting you and a proposal landing in their inbox, cutting your involvement to a single Slack approval click. It's built for a one-person operation with a hard $100/month tooling ceiling, using HubSpot, Slack, Google Drive, Stripe, and Calendly — nothing new to buy or learn. The headline outcome: you stop composing proposals from scratch under time pressure and start confirming drafts the system already built.

---

Architecture

The pipeline runs as a linear chain with one parallel branch. Inbound texts hit two agents simultaneously: the Inbound Text Parser extracts structured job data, and the FAQ Auto-Responder checks independently whether the message is a repeat question. The Parser's output feeds the Template Selector, which pulls the right Google Drive template, then hands both the template and parsed details to the Proposal Drafter. Once the Drafter produces a draft, the Slack Review Notifier assembles everything — draft, price, client name, FAQ context if applicable — into a single Slack message for your approval. From there, the HubSpot Deal Updater and Stripe Invoice Creator run sequentially on approval, keeping your pipeline and invoicing current without re-entry. The most load-bearing agent is the Proposal Drafter: it sits at the convergence of every upstream output, handles pricing logic within the $200–500 band, and is the one place where a bad input from the Parser or a missing template field produces a proposal you'd actually have to rewrite. Get the Drafter's edge-case handling right before you touch anything downstream.

---

Per-agent build notes

Inbound Text Parser

• Role: Converts raw homeowner SMS into structured fields — service type, property info, availability hints, contact name — so every downstream agent works from clean data.
• Skills it uses: SMS Text Parsing, HubSpot API
• Implementation notes:
  • Use the HubSpot API read on contact record first; if the phone number matches an existing contact, pull the name from there rather than trying to extract it from the message body — homeowners often don't sign texts.
  • Define a fixed service-type taxonomy (e.g. lawn care, pressure washing, gutter cleaning, window washing, leaf removal) before building the extraction prompt. The Template Selector's match accuracy depends entirely on the Parser outputting values from that controlled list, not free-form labels.
  • Build a confidence flag into the output. If service_type can't be determined with reasonable confidence, set a low_confidence flag that triggers the fallback path in Slack (week 11 milestone) rather than letting an ambiguous value flow downstream.
  • Edge case: messages with multiple service requests ("can you do the gutters and power wash the driveway?") need a decision rule — either split into two jobs or pick primary service type. Pick one behavior and hardcode it; don't leave it to inference.
• Estimated effort: 24 hours (16h Week 2 + 8h Week 11 fallback)

Template Selector

• Role: Matches the parsed service type to the correct Google Drive proposal template and returns it with structured line items.
• Skills it uses: Google Drive Template Lookup
• Implementation notes:
  • Structure your Google Drive template library as a folder with exactly one file per service type, named to match the taxonomy tokens the Parser outputs (e.g. lawn_care_template.gdoc). The selector logic can then be a direct string match rather than fuzzy lookup — simpler and less likely to grab the wrong file.
  • Template line items (labor, materials, markup) need to be in a machine-readable format the Proposal Drafter can consume — a table in the Google Doc is not enough. Consider maintaining a parallel JSON or Google Sheet that maps service type to line item structure, and have the Selector return that, with the Doc serving as the human-readable source of truth.
  • If the Parser outputs a service type with no matching template, the Selector should return a null match and surface that in the Slack message rather than defaulting to a generic template silently.
• Estimated effort: 18 hours (10h + 8h Week 3)

Proposal Drafter

• Role: Fills the selected template with job details, contact name, a Calendly link, and a priced line-item total in the $200–500 range.
• Skills it uses: Proposal Generation
• Implementation notes:
  • Pricing logic needs to be explicit rules, not left to model inference. Define a pricing matrix per service type with scope modifiers from parsed_job_details (e.g. property size flag, "urgent" language, multi-story indicator). Store this in a Google Sheet the Drafter can read from so you can adjust prices without touching the agent config.
  • When a field from parsed_job_details is missing or ambiguous, the Drafter must insert a visible placeholder (e.g. [CONFIRM: property size]) in the draft rather than guessing. This is what separates a draft you can safely skim from one you have to read line-by-line.
  • Wire the Calendly link in as a static variable — one link, injected at the template level. Don't try to generate dynamic scheduling links; that's scope creep that will break.
  • Week 5's edge-case testing (10 incomplete-input scenarios) is where this agent earns its keep. Don't skip it.
• Estimated effort: 50 hours (16h + 12h Week 4, 14h + 8h Week 5)

FAQ Auto-Responder

• Role: Detects repeat questions in the inbound SMS and fires a pre-written answer immediately, without touching your attention.
• Skills it uses: FAQ Matching
• Implementation notes:
  • The FAQ answer library needs to be written and locked before you build the matching logic — the matcher is only as good as the answer set it's returning. Week 1's 6-hour milestone covers this; don't shortcut it.
  • Matching should be conservative. A false positive (sending an FAQ answer to someone who asked a real job question) is worse than a miss. Set the confidence threshold high and let unmatched texts flow to the proposal pipeline normally.
  • The faq_matched_flag output is consumed by the Slack Review Notifier to append context. Make sure the flag is a clean boolean, not a string or null — this is a common handoff breakage point in Make/Zapier.
  • FAQ responses should be sent automatically back to the homeowner via whatever channel the SMS came in on. Confirm that your SMS integration (Twilio, or whatever sits under HubSpot's conversation inbox) supports outbound replies in the same thread.
• Estimated effort: 18 hours (12h Week 2, 6h Week 9)

Slack Review Notifier

• Role: Posts the assembled proposal draft, price, and client name to your Slack channel with an approve/edit prompt.
• Skills it uses: Slack Posting
• Implementation notes:
  • Use Slack Block Kit for the message layout — a plain text post won't support the inline approve button. The approve action needs to write operator_approval_status = approved back to your automation layer (Make/Zapier) via a webhook; the edit prompt should open the Google Drive draft directly.
  • When faq_matched_flag is true, append the FAQ question and the auto-sent answer as a collapsed section at the bottom of the Slack message. You want full context in one view without the FAQ content dominating the proposal review.
  • The approve button is the only human step in this pipeline — which means it also needs to be the fail-safe. If the proposal has flagged placeholders from the Drafter, surface a warning in the Slack message so you don't click approve on an incomplete draft.
  • Error alerts (week 11 milestone) route through this same Slack channel, so keep the message format distinct enough that error posts don't look like review requests.
• Estimated effort: 26 hours (10h + 6h + 10h Week 6)

HubSpot Deal Updater

• Role: Creates or updates a HubSpot deal on your approval, setting stage to "Proposal Sent" with job details and quoted amount.
• Skills it uses: HubSpot API
• Implementation notes:
  • Always search for an existing contact record by phone number before creating a deal. If a returning homeowner texts in, you want the deal attached to their existing record, not a duplicate contact. The 10-case test in week 7 should include at least 4 returning-contact scenarios.
  • Map quoted_price to a custom HubSpot deal amount field, not the default "Amount" if you're using that for something else. Check your existing HubSpot field structure before you build the mapping.
  • Deal stage "Proposal Sent" needs to exist in your HubSpot pipeline before this runs. Create it manually in HubSpot settings first; don't rely on the API to create pipeline stages.
• Estimated effort: 20 hours (12h + 8h Week 7)

Stripe Invoice Creator

• Role: Generates and dispatches a Stripe invoice to the homeowner using the quoted price from the approved proposal.
• Skills it uses: Stripe Invoice API
• Implementation notes:
  • This agent fires on a separate operator trigger after job completion — not immediately on proposal approval. Build that second trigger point explicitly in your Make/Zapier workflow; it should be a manual Slack button or a HubSpot deal stage change to "Job Complete."
  • Pull the quoted_price from the HubSpot deal record (via hubspot_deal_id) rather than passing it directly from the proposal step. This ensures the invoice always reflects whatever price is in your system of record, not a value that might have drifted.
  • Run all initial testing in Stripe test mode. Week 8's validation milestone calls this out — don't skip it. Stripe's test invoices are indistinguishable from live ones in the logs, so label test runs clearly in your Google Drive run log.
  • Return stripe_invoice_url and write it back to the HubSpot deal record as a custom field so you have a direct link from deal to invoice without hunting through Stripe.
• Estimated effort: 24 hours (14h + 10h Week 8)

---

Implementation order

Weeks 1–3 are entirely setup and scaffolding — credentials, templates, FAQ copy — because none of the agents can be tested without real inputs and real files to work against. The Inbound Text Parser and FAQ Auto-Responder build in parallel in week 2 since they share no dependencies and the FAQ path is independent of the proposal chain. The Template Selector comes next because the Proposal Drafter can't be built without knowing what structure the templates will produce. The Drafter gets two full weeks (4–5) because it's the most complex agent and the quality bar here determines whether the whole system saves you time or creates a new editing burden. Slack, HubSpot, and Stripe follow in sequence because each depends on the one before it having a confirmed output format. Weeks 9–10 are real-data runs and tuning — expect to find two or three field extraction patterns the Parser gets wrong on real homeowner messages and adjust there. Weeks 11–12 are error handling, logging, and documentation: the parts that make this maintainable six months from now when you've forgotten how you wired it.

---

Operational concerns

• Failure alerting routes to Slack. Any agent step that errors or returns a low-confidence output should post a "needs manual triage" message with the raw SMS text to the same channel you use for proposal review. Nothing should fail silently — a dropped inbound text is a dropped lead.
• The run log in Google Drive is your audit trail. Each execution should write a row: timestamp, contact name, service type, quoted price, approval status, Stripe invoice URL. This is also how you spot pricing drift or template mismatch patterns before they compound.
• HubSpot contact deduplication needs a rule, not hope. Phone number is the safest deduplication key for this audience. Codify it in the HubSpot Deal Updater logic before go-live, or you'll end up with a contact list full of duplicates within a month.
• Budget discipline: Make's base plan handles this pipeline volume comfortably under $20/month. HubSpot Starter and Stripe's standard transaction fees are your other line items. Stay away from any add-on that bills per API call at the volume of a solo agency — that's where costs creep. Review Make operation counts after the first two weeks of live traffic.
• The Stripe invoice trigger is manual by design. Don't automate invoice dispatch on proposal approval — the

The problem you're solving

Every inbound text from a homeowner kicks off the same 20-minute task: read the message, pull up a template, write a quote, add a Calendly link, send it — all while you're already mid-job on something else. You're not short on leads. You're short on the uninterrupted time to convert them, and the same 5-10 questions keep eating what little margin you have. The pipeline works; the manual labor inside it doesn't.

---

What you'll get

• An Inbound Text Parser that reads a homeowner's raw SMS and pulls out the job type, property details, availability hints, and contact name — so everything downstream starts from structured facts, not free-form guessing.
• A Template Selector that matches the job type against your Google Drive proposal library and returns the right starting point every time, without you touching a folder.
• A Proposal Drafter that fills the selected template with job specifics, a price in your $200–500 range, and your Calendly link — producing a near-finished quote that needs your eyes for 30 seconds, not your hands for 20 minutes.
• An FAQ Auto-Responder that detects repeat questions and fires your pre-written answer immediately, before the message ever reaches your attention.
• A Slack Review Notifier that drops the draft proposal into your Slack with the client name, quoted price, and a single approve prompt — review happens where you already are.
• A HubSpot Deal Updater that creates or updates the deal record and sets the stage to "Proposal Sent" the moment you approve, with no separate data entry.
• A Stripe Invoice Creator that generates and sends the invoice to the homeowner after the job closes, using the agreed price from the approved proposal — no retyping numbers.

---

How we'll build it

Weeks 1 through 3 are about getting the foundation right before anything gets built on top of it. I'll connect HubSpot, Google Drive, Slack, Calendly, and Stripe through your automation layer, verify every credential is live, and build out your template library — five service-type proposal templates in a standardized format you control. I'll also document your repeat FAQ questions and draft the pre-approved answers that will power the auto-responder. The Inbound Text Parser and FAQ Auto-Responder both go live in Week 2, tested against real and realistic inbound texts before anything else depends on them.

By Week 4, the Proposal Drafter is running. It takes the parsed job details, selects the right template, applies pricing logic calibrated to your scope signals, and produces a draft. Week 5 is about quality and edge cases — specifically making sure the drafter flags ambiguous fields rather than filling them with invented values. That matters at your ticket size, where a pricing error on a $300 job is not a rounding problem.

Week 6 closes the review loop with the Slack notifier and the approve-to-send trigger. Weeks 7 and 8 wire in HubSpot and Stripe so the pipeline runs all the way from inbound SMS to sent invoice. Weeks 9 and 10 put real inbound texts through the full sequence and tune against whatever the data surfaces. The final two weeks add error alerts, a fallback path for texts the parser can't confidently read, a Google Drive run log, and a one-page runbook so you know exactly how to add a template or update an FAQ answer yourself.

---

What this is worth

Right now, a single inbound text costs you roughly 20–30 minutes of composed time: reading, drafting, pricing, formatting, sending. At a modest five new inbound texts per week, that's close to two hours of proposal work — plus another 30–60 minutes fielding the repeat questions. This pipeline cuts your active involvement per lead down to a single Slack approval click, which runs under a minute once the draft is in front of you. That's conservatively 2–3 hours per week returned to billable work. At your current job volume, recovering that time is the difference between staying at capacity and taking on two or three more clients. The FAQ auto-responder alone stops the bleed on questions that were never worth your direct attention.

Given your stated budget ceiling, this engagement is designed to run entirely within that range on tooling — no new software required beyond what you already have.

---

Timeline

You said this week, so that's when we start. Kickoff is a single 30-minute call to confirm API access and walk through your existing templates. From there I'll move in weekly increments, with a standing check-in each week to review outputs and unblock anything that needs a decision from you.

---

What I need from you

• API access and credentials for HubSpot, Google Drive, Slack, Calendly, and Stripe — ideally before the kickoff call so Week 1 isn't blocked.
• 10–20 real inbound texts (anonymized is fine) to test the parser against actual language your homeowners use, not invented samples.
• Your five core service types and at least one existing proposal or quote per type, so the template library starts from formats you already trust.