Builder Delivery Handbook

The business in 60 seconds

stpierre.ai (the retired long-form company name never appears in copy) generates homeowner appointments for home-services contractors — concrete leveling, concrete flatwork, foundation repair, crawl space, basement waterproofing. The public face is the Alex St. Pierre persona; externally we position as growth consulting for seven-figure home-improvement companies.

Two sides of the machine:

• B2C (your side — delivery): Meta ads in a target market → Facebook Messenger bot captures the homeowner's phone number → automated text follow-up qualifies the project → the qualified appointment request is handed to the client. The client pays per appointment.
• B2B (Akash's side — sales): outreach to contractors (Loom video then phone call), sales calls, closing. Stripe is the source of truth for what's closed.

The model is pay-per-appointment: we front the ad spend, the client pays only for booked appointment requests. That means delivery quality — real phone numbers, real project details, fast follow-up — is the whole product.

How we got here — the last 13 weeks

Everything you're inheriting was built since June, across roughly 2,000 logged work sessions. The arc matters more than the details: exit the old agency → design the new model → build the machine → sign the first clients → discover delivery reliability is the real constraint → stop, audit, repair → split the company into sales (Akash) and delivery (you).

The takeaway for you: almost every rule in this handbook is a scar, not a preference. The deploy gate exists because unapproved deploys shipped. The watchdogs exist because rails died silently. The suppression gates exist because automation over-messaged real homeowners. When a guardrail seems paranoid, assume it's load-bearing.

Where things stand right now

You are not inheriting a humming machine — you're inheriting a machine mid-repair, with the diagnosis already done. This is the honest picture from a full audit of every active workstream (Sep 2–3).

The core problem being fixed: leads collected, not delivered

• A Sep 2 end-to-end audit found the delivery chain leaking: homeowners gave their info, then the handoff to the client stalled or never fired. A full repair program is approved and mid-execution — 8 root causes, 7 workstreams — covering the booking worker, follow-up rails, reconcilers, and handoff receipts.
• The rebuilt backlog report covers 158 leads: 64 turned out to already be with clients, ~50 are still mid-conversation with the bot, 22 sit in markets with no client, and a small number are true holes (e.g. first-name-only submissions the booking system refuses). Recovery is running; the ruling is recover the backlog manually before reactivating more ad automation.

The second problem just fixed: over-messaging

• Automated texts were going to people who had already given complete info, sometimes several in seconds. This is now blocked mechanically: suppression lists, one message per turn, a 45-day repeat block, mechanical STOP handling, and only pre-approved copy can send on guarded rails. Ruled: once a lead gives minimum viable info or is transferred, no automated chase — ever.
• A "humanity" pass removed AI tells from the rails (reply delays, no re-asking answered questions, no invented rep names). Treat re-asking a homeowner for something they already gave as a sev-1 defect.

What's live vs paused

• Ad campaigns are largely paused along with the client roster. All 514 Messenger ads were standardized to one universal phone-ask reply and locked under a launch contract — reactivation happens only through the signed launch controller, market by market, as recovery completes and clients turn back on.
• Real benchmarks to beat (Dallas, Aug): concrete leveling ~$13 per lead via Messenger, ~$10 via lead form; foundation repair ~$19–22 per lead. Lead-form leads always include a phone; Messenger converts about half to a phone number.
• Texting rails: the iMessage bridge (mycrmsim) is primary with Apple's ~50/day cap per line; LoopMessage is a parked backup with warm-up gates staged off.

The sales-side pivot (context for your workload)

• Akash is moving sales to outbound-first cold calling — a power dialer (Kixie) is being set up, and the front-end offer is being simplified toward a one-call close on a small paid trial. Expect delivery to follow closed deals fast: a new client means a market launch on short notice, through the launch-QA gate.
• Cold email volume is small (20–30/day) and stays manual; its target lists are being rebuilt after a wrong-service-targeting audit.
• Cash is tight and spend is gated — treat every dollar of ad spend as something that must be defensible at the huddle.

Deprioritized (recommended parks — Akash confirms)

• Synthetic-creative R&D (the "lift story" prototype and b-roll expansion) — the library stays, the project waits.
• LoopMessage limit increases, new dashboards or status surfaces, internal tooling hardening, and the sales tone-coach experiment.
• Rule of thumb for your builder blocks: if it isn't a sales conversation or a lead reaching a client, it waits.

Roles & responsibilities

Three-bucket rule for every status update: Akash's lane (only he can do it), needs his word (you're blocked on a decision), yours (execute and report). Never send one flat "waiting on you" list — "waiting on me" and "needs my approval" are different lists.

What always needs Akash's explicit go

• Any deploy of a public or client-facing page — plus the deploy gate (below) and an approved before/after contact sheet (screenshots of old vs new).
• Any new automated message to a human — new send rails, new scripts, new recipients. No automated sends without his word, ever.
• Money: spend changes beyond agreed budgets, refunds, anything billed.
• Offer language: prices, guarantees, and promises on any surface. These are ruled by Akash and change only when he rules again.
• Deletions of accounts, data, campaigns, or workflows.

Approval is per-action and per-surface. A yes on one deploy is not a yes on the next.

The daily rhythm

The exact huddle time is Akash's call — the page is ready from 6:30, so any slot before his sales block works.

Daily huddle process

The scorecard is the agenda. There is no separate prep doc. The huddle page at rooms.stpierre.ai/huddle is rebuilt every morning at 6:30 from the database and is designed to be readable cold in 60 seconds.

What the page shows

• Hero metrics — the few numbers that matter this week, actual vs target, with week-to-date pace.
• Blockers — open P0/P1 tasks (highest-urgency items) pulled straight from the task database.
• Commitments — what each person committed to yesterday and commits to today, filled verbally in the huddle.

How to run it (15 minutes max)

• Read the hero numbers: on pace or behind? Behind numbers get an owner and a same-day action.
• Walk the blockers: each one gets unblocked, reassigned, or scheduled — never re-admired.
• State today's commitments out loud. The EOD job grades them at 7:50pm — anything still "planned" is marked missed.

The Friday version of this is the weekly scorecard at rooms.stpierre.ai/scorecard — this week vs last, with red/amber/green status per metric. Targets live in exactly one place (the scorecard_metrics database table); if a number needs a new target, that row changes — nowhere else.

End-of-day process

Two layers — the automated job, and your report.

The 7:50pm automated job

Every evening eod_report.py runs and:

• Reads today's actuals against this week's targets and computes pace on the hero metrics.
• Grades today's commitments — anything not done is flagged missed, in writing.
• Builds tomorrow's plan from open P0/P1 tasks plus any behind-pace metrics, and writes tomorrow's commitment rows.
• Pushes a plain-English summary to Telegram HQ.

Your EOD report (Slack #daily-reports)

Short, honest, same shape every day:

• Shipped: what got done, with proof (link, screenshot, or number).
• Numbers: leads generated, appointments delivered, per live client.
• Broken or behind: anything red, with the fix already in motion and an ETA. A stale number behind a green badge counts as broken.
• Blocked: split into "needs your word" vs "your lane" (things only Akash can do).
• Tomorrow: the one delivery domino you'll knock down first.

The no-orphan rule: no lead ends the day without a next action, and no conversation ends the day uncaptured. That's the bar the shutdown pass has to clear.

Core KPIs & targets

Two principles above every metric: lead volume is the growth metric (never throttle lead generation to match sales capacity), and inputs are the daily accountability (activities done today, not lagging outcomes, are what get graded daily).

Delivery health

Paid media (B2C, per niche)

Target cost per lead = 0.525% of the niche's average ticket (that's our 10% fee × 50% margin × 10.5% lead-to-job rate). Live values from the database (query niche_economics, never hardcode):

Spend-waste guardrails (kill rules)

• $50 spent, fewer than 5 link clicks → kill the ad (creative is broken).
• $500 spent, zero booked appointments → kill (funnel is broken regardless of clicks).
• Performance reads always start with spend, ranked highest first — where Meta puts money is the leading signal; click rates are noise, not findings.

Weekly targets live in one place only: the scorecard_metrics table, surfaced on the huddle and scorecard pages. If a document and the scorecard disagree, the scorecard wins.

Current book of business (as of Sep 3)

Rules that shape delivery: leads are ours or the client's — never both, never a grey zone. Clients mark lead outcomes in the portal (client.stpierre.ai), which is the source of truth for lead status. Dan is always capitalized. Test markets need 1M+ population; service areas list suburbs, not the core city.

The offer (so delivery matches the promise)

You don't sell, but what you deliver must match what was sold.

• The pitch (current, ruled Aug 26): pure pay-per-appointment. No onboarding fees. Example pricing: concrete leveling $25–$50/appointment; foundation repair $150/appointment (10-block $1,500) or $125 bulk. Unqualified lead → replaced, no questions asked.
• Marketing surfaces say something different on purpose: ads and landing pages promise "10 jobs in 6 weeks, guaranteed — you only pay 10% of closed jobs." Both are true at once; never "correct" one to match the other.
• What a deliverable unit is: a qualified appointment request — homeowner with project details, address, and a preferred time window. The client's team calls to lock the exact slot. Phone number is the only must-have field; never collect homeowner email; geography never disqualifies a lead (non-English does).

The systems map

Code workflow: you never work in Akash's local workspace. Product repos use normal team Git — one branch per task, small commits, push often (3–8/day is healthy), PR for review, merge after proof.

Links directory

Daily surfaces

Portals

Docs & public

Hard guardrails

These have each been violated at least once and each violation cost real money or trust. They are not preferences.

• Never deploy without the gate. Every page/worker deploy runs the deploy-gate check (it verifies copy standards automatically: guarantee language present, no retired promise wording, no retired company name, no dark backgrounds, no internal build language, no unrendered template variables). Exit 0 plus Akash's approval of a before/after contact sheet — both, every time. Two unapproved deploys shipped in one day once; that's why the shim now runs the gate on every deploy command automatically.
• Never send without the word. No new automated outbound to any human without Akash's explicit approval of that exact rail and script. Automated B2B texting stops the moment a prospect books a call. One SMS script for everyone — never customized per lead.
• Never edit a launched ad set. New creative ships as a new pack in the same campaign. Respect the 50-ads-per-ad-set cap.
• Light, never dark. All client- and homeowner-facing pages and creatives use light backgrounds. House copy standard: no adjectives/adverbs in bot scripts, no acknowledgment openers after a gap, "rep" never "estimator", never "I run ads" in outreach.
• Never test against live data. Test rails against the fixture. Testing with your own phone number fakes a loop (self-sends echo as inbound). Real-traffic shapes only.
• Never throttle lead gen for sales. And never recommend fewer creatives — volume is the strategy.
• Backups never live inside a deploy directory. A .bak or BEFORE- file in an assets dir ships to production wholesale. Backups go in a backups/ folder beside it.
• Verify before "done". A live-system change isn't done until you ran it, opened the URL, or fired a test lead. "Should work" is not a status. Same for negatives: before claiming "no leads came in", check unfiltered data.

Monitoring & escalation

~50 scheduled jobs run on the host Mac. The ones you'll interact with:

Alert doctrine: fix before paging — an alert that reaches Akash should arrive with the fix already in motion. Before auditing an alert, check the alert register first (most "new" alerts are known). Escalate to Akash mid-day only for: leads not flowing, a client seeing breakage, or money at risk. Everything else goes in the EOD report.

Your first week

• Day 1 — Read & access. This page, then the onboarding hub and the operating brief. Collect access from Akash: rooms passcode, Slack, GHL, Meta Business Manager, Cloudflare, DripJobs, the database.
• Day 2 — Walk the funnel. Trace one lead end to end on the fixture: ad → Messenger → phone capture → text follow-up → qualified request → client handoff. Watch the B2C scoreboard while you do it.
• Day 3 — Learn the rails. GHL rebuild guide + visual atlas; find each watchdog's log; open every room on rooms.stpierre.ai.
• Day 4 — Shadow the rhythm. Run the huddle from the page; write your first EOD report in #daily-reports.
• Day 5 — First domino. Take one delivery task end to end — through the gate, with the contact sheet, verified live — and report it shipped.

Standing bar from day one: nothing breaks silently, nothing needs asking twice, and every number you report traces to a source. Say "I don't know" over guessing — always.