mattrguerra.comHouston area
Matt Guerra
  1. 01AI & Automation
  2. 02Photography
  3. 03Design
  4. 04About
  5. 05Notes
  6. 06Contact
Back to the systems

mattrguerra/meridian-outreach-vaultmainPrivate on GitHub, published here in full

HEARTBEAT.md

Markdown5.8 KB44 lines

HEARTBEAT.md

  1. ---
  2. type: working-state
  3. scope: project-root
  4. tags: [claude, outreach, heartbeat]
  5. created: 2026-06-16
  6. updated: 2026-09-21
  7. ---
  9. # HEARTBEAT: In-flight state
  11. > [!NOTE] This vault ships a generated sample book, not a live client base. The numbers
  12. > below are the sample's state after the 2026-09-21 replay by
  13. > `07-Automation/sample/run_sample.py`. [[LEDGER]], [[DECISIONS]] and [[CHANGELOG]] carry
  14. > the history of the system running on the full book.
  16. ## Current state (2026-09-21)
  17. - **Weekly Partner Client Pipeline:** scheduled Mondays 06:00 America/Chicago, autonomy `through_vault` (stubs, census and roster workbook written unattended; Bitrix, enrichment and routing held for a human). Baseline seeded 2026-09-07 from `07-Automation/sample/inputs/Partner-Clients-Roster_2026-09-07.xlsx`. Runs replayed: 2026-09-14 and 2026-09-21. Last run: `verify` exit 0, nothing shrank. Transcripts in `05-Outputs/partner-runs/run-log_2026-09-14.txt` and `run-log_2026-09-21.txt`.
  18. - **Order history** (`07-Automation/data/order_history.json`): 381 Plinth accounts after the merge-registry fold (40374 → 40373, [[Imogen Radcliffe]]). The 09-21 pull added 93 orders; 2026-09-17 came back at `suspect_row_count` on its first page and converged on the third.
  19. - **Partner clients: 130.** Palladium 86 · Platinum 29 · Iridium 8 · Rhodium 7 (four of the Rhodium are Harlow Ridge mailboxes held there by `tier_overrides` in [[partner-thresholds]]). **130 stubs** in `03-Clients/client-stubs/`.
  20. - **Census** (`03-Clients/partner-client-master-list.xml`): 130 chunks, all `pl-` keyed; **43 carry pipeline placement (45 blocks)**; the rest hold `<pipelines count="0" />`.
  21. - **Bitrix, four audited funnels (24 / 26 / 36 / 16): 54 deals, 28 with a verified touch**, 26 never contacted, 3 with no Plinth match (the two known test carts 400017 / 400023 and one guest cart). Workbook: `05-Outputs/Bitrix_Pipeline_Outreach_Audit_2026-09-21.xlsx`. The touch cache holds all 54; the 09-21 run pulled 18 histories fresh and reused 36.
  22. - **Route (read-only, nothing pushed):** Winback 50 (one role-named account held for review), cat 24 first-touch 31, Dormant queue 4, excluded 45 (open deal 33 · winback already done this spell 4 · Harlow Ridge by domain 4 · opt-out 3 · staff account by domain 1). Candidates: `05-Outputs/partner-runs/routing-candidates_2026-09-21.json`.
  23. - **Roster workbook:** `05-Outputs/partner-runs/Complete-Partner-Clients-List_updated-2026-09-21.xlsx` is the copy to swap into Google Drive (by hand; the vault copy is not wired to Drive).
  25. ## Next actions
  26. - **Review the 09-21 routing candidates** (`05-Outputs/partner-runs/routing-candidates_2026-09-21.json`): 31 cat-24 first touches (two new since 09-14: [[Uma Ormsby]] and [[Wendell Pemberton]], both newly qualified Palladium), 4 in the Dormant queue, 50 Winback. Approve, then push with `partner-pipeline-push`. Every Bitrix write stays human-gated.
  27. - **Decide the held Winback row** in `05-Outputs/partner-runs/winback-role-review_2026-09-21.csv` ("Purchasing Dept"): find a named contact or leave it out. A role name behind Winback automation produces a "Hi Purchasing" greeting.
  28. - **Enrich the new stubs** once they are approved into a pipeline: Uma Ormsby and Wendell Pemberton (created 09-21) with `client-enrich`, cat-24 brief. Enrichment runs on outreach selection, not on the whole book.
  29. - **Keep the two dual-active check-ins parked** per `04-Working/dual-active-pipelines_2026-09-21.md`: [[Sunniva Westbrook]] and [[Florian Northcott]] each hold an open cat-24 deal at TIER CHANGE EMAIL SENT and a cat-36 deal already in Dormant (`C36:UC_LXCMAV`). Nothing to move this week; do not close a cat-24 deal mid-sequence to clear the overlap.
  30. - **Flag [[Mira Fenwick]] to Nora:** she ordered on 2026-09-18 while parked in the Winback Client bucket and crossed Palladium → Platinum, so she is no longer dormant and her Winback deal should not be advanced. The stage move is Nora's.
  31. - **Review the flagged stub** `03-Clients/client-stubs/Booth 214 c-o Riverside Expo.md`, created 09-14 from a ship-to string in the Plinth name field: rename it to the real contact, or confirm it.
  32. - **Swap the 09-21 roster workbook into Drive** (Matt).
  34. ## Waiting on decisions
  35. - **Winback bucket-fill pace (Matt + Nora).** How many deals move from the Client bucket to Activated each quarter. Nothing sends until Nora advances a deal to First Email, so her stage move is both the send and the throttle; the open question is the rate, not the mechanism.
  36. - **N per batch for the Dormant queue (Matt + Ines).** Matt feeds the Quarterly Check-In Dormant bucket N at a time, longest-since-last-outreach first; N is not set.
  37. - **Bitrix retrieval limit on the two parked stages** (Winback Client `C26:UC_JUUNES`, Abandoned Carts New `C16:NEW`). A list call caps at 200 rows. Sub-day windowing enumerates both stages completely, but why it works inside the connector is unconfirmed, so every run has to check that the union of windows equals the stage total. Decide whether to keep windowing or wait on Matt's open request to raise the retrieval limit.
  38. - **Counting rules (Nora).** Shipping in or out of lifetime value (`grand_total` vs `subtotal`), and whether cancelled or refunded orders count. Defaults stay roster-compatible (`grand_total`, statuses 27 and 28 excluded) until the leadership call.
  40. ## Known gaps
  41. - **Stub `## Order History` can lag.** The driver writes that body section only when it creates a stub; upgrades refresh frontmatter only. Frontmatter is the live record; read `ltv`, `total_orders_count` and `last_order_date` there.
  42. - **`plinth_id` is not in every stub's frontmatter.** The driver does not write it; stubs carry it only where it was backfilled. The census `<plinth_id>` is always set, so join on the census.
  44. When mid-task (e.g., enriching a batch of stubs), record here: which segment, how far, what is left, any blockers.