Honey-Doers
← Links

Revenue Attribution — I14

Rendered at build time from REVENUE_ATTRIBUTION.md in the repo — edit the source file and rebuild to update this page.

Revenue Attribution — I14

Version 1.1.4 · 2026-09-06 · Status: Scoping — Phase 2's lead-push test shipped and verified live; Phase 0 (phone tracking) still open.
Objective Close the loop from a website visit or phone tap to a sold job in JobTread — track phone leads with the same confidence as form leads, get every lead (form or phone) into JobTread automatically tagged with source/city/service and a Lead ID, and layer in automated communication on both sides of the sale (status updates while a lead is being worked, newsletter/review/referral touches once it closes). Together these are the building blocks of a mature sales motion, not just a tracking fix — attribution tells you what happened, the communication layer is what actually improves the customer experience and the team's follow-up consistency.
Nature of work Three builds, in dependency order: (1) a static tracked phone number with call recording/connect data, wired through Cloudflare Pages Functions the same way functions/api/contact.ts already handles OpenAI/Ads server-side calls; (2) a JobTread API integration (app.jobtread.com/docs) so form and phone leads land in the CRM without manual re-entry; (3) automated post-lead and post-sale communication sequences keyed off that same Lead ID / pipeline-stage data. (3) depends on (2) existing first — there's nothing to trigger a sequence off of until leads and stage changes are actually landing in JobTread automatically. Not a recurring content lever — one-time infra, then it runs itself.
Trigger The 2026-08-24 "Where the Money Goes Dark" revenue-funnel review: phone is the larger channel (125 taps vs. 76 form submits) but the only signal past a tel: tap is that someone tapped it — no connect confirmation, duration, or recording. Separately, leads (form or phone) aren't confirmed to reliably reach JobTread at all — they can be worked entirely off email/voicemail and never become a CRM record. The same review also surfaced a third, undocumented gap: what happens to a lead's data and communication before and after the sale — automated status updates while a deal is open, and newsletter/review/referral activity once a project closes. All three block every question in the Business Questions register that depends on a closed lead→sale loop: B1, B3, B5, B6, B10, B15.
Progress Funnel review presented at the 2026-08-26 owner meeting (see MEETING_NOTES.md). Vendor-vs-build for phone tracking was not decided — framed to the owner as "confirm the phone gap, then decide" rather than a forced choice that day. Owner did commit to a first move on the intake question: send form leads to JobTread via API as a test (open TODO in MEETING_NOTES.md). Also discussed: the current lead-handling chain is Site → Shelly → Adam → IBT — worth confirming this is accurate (and where, if anywhere, a lead can currently fall out of it) before the intake/CRM phases below are scoped further.
Next action Still open: the Phase 0 vendor-vs-build decision (CallRail/WhatConverts ~$30–90/mo turnkey vs. Twilio build ~$5–10/mo usage-based). No phone-tracking code work starts before that call. Phase 2's JobTread lead-push test is shipped, live (JOBTREAD_LEAD_PUSH_ENABLED=true), and verified against a real submission — see Phase 3 below. Separately, a pre-existing gap surfaced during verification: LEAD_LOG KV diagnostic logging isn't writing despite a correctly-configured binding — tracked in MEETING_NOTES.md's Open TODO board for a future session, not blocking this initiative since the internal diagnostic emails cover the same information.

This file is self-contained. Ledger entry: I14 in Search_Strategy.md.

Problem

Every target in Search_Strategy.md — rankings, clicks, form submits, calls tapped — is a proxy for whether the work produces sold jobs. Nothing today actually traces a lead through to a dollar in JobTread, which is why B1, B3, B5, B6, B10, and B15 in the Business Questions register are all still open. Two specific breaks in the chain:

  1. Phone is under-instrumented. The only signal is a GA4 tel: click event — proof someone tapped the number, not proof the call connected, how long it ran, or who called. GA4 can't originate this data on its own; it's an analytics layer, not a phone system. Phone is also the larger channel (125 taps vs. 76 form submits per the Phase 2a baseline in Search_Strategy.md), so this is the bigger of the two gaps, not the smaller one.
  2. Leads don't reliably reach the CRM. The lead-log instrument (one sheet, one row per lead, keyed by the Lead ID contact.ts already mints) was designed to answer this, but nothing confirms it's being kept up — and even when a lead is worked, there's no guarantee it becomes a JobTread record rather than staying in email/voicemail. JobTread has a documented API (app.jobtread.com/docs) that's never been used for this.
  3. No documented communication layer, before or after the sale. There's no written answer for whether a lead gets any automated touchpoint while it's being worked (status update, quote-ready notification) or what happens to a customer's data once a project closes (newsletter opt-in, review request, referral ask). Some of this may already happen informally through JobTread or manually by staff — this initiative doesn't assume it's missing, only that it isn't documented or built on the same data backbone as the rest of the pipeline.

A known, deliberate limitation carried into this initiative: a static (non-rotating) tracked number fixes whether a call happened — it does not fix which channel drove it. Dynamic number insertion would solve attribution fully but was already rejected elsewhere in this project for conflicting with I9 Tier 1 NAP consistency. A static number preserves NAP (it's the same number published everywhere, permanently) at the cost of channel-level attribution for calls that originate off-site (a citation, a truck, GBP) — self-reported "how'd you find us" at intake remains the only source of truth for those.

Strategy

Phase 0 — vendor vs. build decision (business-owner, blocks everything else)

Confirmed pricing as of 2026-08-24: CallRail ~$50–55/mo entry tier, WhatConverts $30/mo (calls-only) to $60/mo (calls + forms unified). Both are turnkey — no engineering time, live dashboard, native form+call unification in WhatConverts' case.

The alternative: build the tracked number on Twilio, mirroring the server-side pattern already proven in functions/api/contact.ts for OpenAI/Ads conversions. Twilio's usage-based pricing at current call volume works out to roughly $5–10/mo (a local number ~$1.15/mo + inbound minutes ~$0.0085/min + recording ~$0.0025/min) — the tradeoff is engineering time up front and no vendor dashboard, in exchange for a much lower recurring cost.

Phase 1 — tracked number (if the Twilio build is chosen)

Phase 2 — JobTread lead push

Phase 3 — verification

Phase 4 — communication layer (post-lead + post-sale)

Depends on Phase 2 shipping first — there's no pipeline-stage data to trigger a sequence off of until leads are landing in JobTread automatically. Two sequences, same underlying mechanism (a JobTread stage-change or field-update triggers an outbound message):

Content and cadence for both sequences (what the messages actually say, how many, how far apart) is a business-owner call, not an engineering one — scope that decision separately once Phase 2 is live and this phase is actually being picked up.

Open decisions

  1. Vendor vs. build — the Phase 0 decision. Turnkey dashboard and no build time (CallRail/ WhatConverts) vs. lower recurring cost and full control (Twilio), decided 2026-08-26.
  2. Which conversion action/lead type in JobTread — needs a call in JobTread's UI/API docs, not just code; may need a dedicated "web lead" record type to keep it distinct from leads entered manually by staff.
  3. Whether the lead-log sheet survives — if JobTread becomes the automatic system of record, the manually-maintained sheet described in Search_Strategy_Rules.md may become redundant, or may remain useful for the quoted/sold/contract_$ fields JobTread doesn't natively expose the same way. Revisit once Phase 2 is live.
  4. Call-to-visit correlation — worth a cookie-based soft match (capture session/UTM context when a visitor taps the on-site tel: link, correlate to a Twilio call landing in the same window) to recover source data for web-originated calls specifically. Doesn't help off-site-originated calls (GBP, citations, signage) — those still depend on intake asking. Scope as a Phase 1.5 addition if Phase 1 ships and the gap turns out to matter in practice.
  5. Messaging channel and tooling for Phase 4 — SMS needs a sending number and carrier registration (A2P 10DLC, if built on Twilio, which would piggyback naturally on Phase 1's infrastructure) or a transactional-email service if starting with email only. Needs a decision on channel before Phase 4 scoping goes any deeper.
  6. JobTread-native automation vs. custom build for Phase 4 — RESOLVED 2026-09-05. Confirmed via JobTread's public docs/marketing: Workflows (no-code trigger → filter → action) support a "job status changes to Closed" trigger with a text/email action requesting a Google review, bundleable with a survey, final billing task, and completion summary in the same workflow. Appears included in the standard ~$20/mo-per-user plan, not a paid add-on (not fully confirmed — would need a JobTread account or sales call to verify plan-gating and whether the review ask is Google-specific or configurable). Decision: build Phase 4's post-sale review ask on JobTread's native Workflows, not a custom send or a third-party review platform — see the review-platform comparison and configuration options below. Post-lead status-update messaging (the other half of Phase 4) still needs its own channel decision (open item 5 above) since it fires mid-pipeline, not on close.

Review solicitation — platform comparison

Surveyed 2026-09-05 against the Phase 4 post-sale review ask. Directional pricing/features from public docs and marketing pages, not verified via vendor sales calls — re-check before any purchase decision.

Platform Core service Strengths Weaknesses Pricing model Fit for Honey-Doers
JobTread Workflows No-code trigger→action automation already inside the CRM we plan to run leads through (I14 Phase 2) Zero extra tool/login; fires directly off the same "Closed" status that already carries Lead ID/source/city/service; bundles with survey + billing + doc tasks in one workflow Review-gen is a side feature of a PM tool, not its focus — no listings sync, no review monitoring/response aggregation, no competitor benchmarking; unconfirmed whether it's Google-specific or multi-platform Included in JobTread's ~$20/mo-per-user plan (unconfirmed whether workflows are plan-gated) Best fit for the core "ask" once Phase 2 ships — no added cost, no added system, and it's already keyed to the same Lead ID/source data the rest of I14 depends on
NiceJob Standalone review generation + basic reputation widget, auto social posts from reviews Cheap end of category, easy embeddable widgets, simple SMS/email review requests Thin CRM/reporting; would duplicate what JobTread's Workflows already do for the ask itself ~$75–175/mo, annual contract Redundant with JobTread once Phase 4 ships, unless we want its widget/social layer specifically
Podium Review management + unified inbox (SMS/webchat/Google/FB), payments, light CRM Strong on lead-intake conversations (missed-call text-back, webchat) — overlaps I14's phone-tracking/CRM scoping, not just reviews Pricier; contract-locked; review-gen is good but not best-in-class standalone; largely duplicates JobTread for the ask Custom quoted, ~$300–500+/mo, annual contract Only worth it if we want to consolidate lead-intake messaging (not just reviews) into one tool — evaluate against I14's phone-tracking decision, not as a review tool alone
Birdeye Full reputation suite — reviews, listings/local SEO, competitor benchmarking, surveys, referrals Most full-featured; strong competitor comparison dashboards; multi-location support Most expensive; aggressive sales/upsell; overkill for a single-market home-services business Custom quoted, ~$300–1000+/mo, annual contract Not a fit at our size/footprint; competitor-benchmarking angle is the only thing not replicated elsewhere
GatherUp Review generation, widgets, listing sync Lighter/cheaper than Birdeye/Podium; decent SEO schema output Smaller company/ecosystem; largely duplicates JobTread for the ask ~$100–300/mo tiered Redundant with JobTread; only relevant if listings-sync becomes its own need
Broadly Review generation + basic webchat, built for trades (ServiceTitan/Jobber integrations) Vertical fit for home services; simple onboarding No confirmed JobTread integration; largely duplicates JobTread for the ask; mixed reviews on support ~$300–400/mo, contract required Redundant with JobTread unless its webchat/lead-capture layer is independently wanted
Manual (staff sends the ask by hand — text/email/call) No tooling — a person remembers to ask after each closed job Zero cost, no vendor risk, personal touch Depends entirely on staff remembering, at the exact moment I14 is trying to fix ("no documented communication layer" was the original problem); no Lead ID/source tie-back; no consistency or reporting $0 The status quo I14 was scoped to replace — not a real configuration, listed as the baseline

Strategic configurations

Three ways to resolve Phase 4's post-sale review ask, ranked by recommendation:

  1. JobTread-only (recommended). Build the review ask, survey, and completion tasks as a single JobTread Workflow triggered on "Closed." No new vendor, no new monthly cost, and it inherits the Lead ID/source/city/service data Phase 2 already pushes into JobTread — so a review can be traced back to the job and channel that produced it, same as the referral ask. Downside: no review monitoring/aggregation, no listings management, no competitor benchmarking — if any of those become separate needs later, they'd be a separate, additive tool, not a replacement for this.
  2. JobTread + standalone layer (only if a gap shows up in practice). Keep JobTread's Workflow as the trigger/ask mechanism, add a standalone tool (most likely NiceJob for cost, or Podium if the lead-intake/webchat overlap with I14's phone-tracking decision makes it worth bundling) purely for review monitoring, response aggregation, or listings sync — capabilities JobTread doesn't have. Don't adopt this configuration pre-emptively; it's an upgrade path if JobTread-only proves insufficient, not a starting point.
  3. 3rd-party standalone (not recommended). Route the review ask entirely through a platform like NiceJob/Podium/Birdeye instead of JobTread, decoupled from the Lead ID/source data Phase 2 builds. Loses the free, already-integrated trigger for a paid one that would need its own integration work to recover the same source tie-back JobTread gives for free. Only worth revisiting if JobTread's Workflows turn out to be plan-gated behind a much higher tier than documented, or if the review ask needs to fire off an event JobTread can't trigger on.
  4. Manual (rejected — this is the current state). Listed for completeness, not as a real option: this is the exact "no documented communication layer" gap I14 Phase 4 exists to close. Retaining it as the mechanism would mean Phase 4 doesn't ship.

Version history