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

MEMORY.md

Language Markdown9.7 KB48 lines

MEMORY.md

  1. ---
  2. type: project-memory
  3. scope: project-root
  4. tags: [claude, outreach, memory]
  5. created: 2026-06-16
  6. updated: 2026-08-10
  7. ---
  8. # MEMORY: Quarterly Outreach
  9. ## Durable facts
  10. - Owner: Matt Guerra (Client Success / Display Consultant, Meridian Display Co.).
  11. - **Shared vault:** Matt and Hazel both work here via separate Cowork projects synced over Obsidian. Every change is logged to [[LEDGER]] with the actor, attributed by session email (`hello@meridiandisplay.example` = Matt; `accounts@meridiandisplay.example` = Hazel). Logging on any vault change is a session requirement in [[CLAUDE]].
  12. - **Scale (since 2026-07-23):** the vault covers the full partner base (Palladium and up by lifetime spend) in `03-Clients/client-stubs/`, and the master list (`partner-client-master-list.xml`) is a **complete partner census**: one chunk per partner client, not-in-pipeline clients carry `<pipelines count="0" />`, keyed `pl-<Plinth user_id>`. The shipped sample book has 381 Plinth accounts, 130 of them partner clients: 130 stubs and 130 chunks (see [[README]]).
  13. - **The weekly run now produces TWO spreadsheets (2026-08-10):** the Drive-swap partner roster (`Complete-Partner-Clients-List_updated-<date>.xlsx`, Stage F2) **and** the per-pipeline outreach audit (`05-Outputs/Bitrix_Pipeline_Outreach_Audit_<date>.xlsx`, Stage F5: one sheet per outreach funnel, each client with Plinth locating details + the date they were last actually reached out to). F5 resolves Plinth identity out of F2's workbook, so **F5 must run after F2**. Bitrix is READ ONLY in F5: reading is not routing; deal creation and stage moves stay human-gated.
  14. - **Audit scope is FOUR funnels: 24 Partner Tier Upgrade, 26 Winback, 36 Quarterly Check-In, 16 Abandoned Carts (Matt, 2026-08-10).** An earlier pass also swept 28 (7 Days Delivery Up-Keep) and 30 (Cold Outreach) off the back of a one-off "all the pipelines" question; those are out. `AUDIT_FUNNELS` in the driver is the one place scope is defined. Changing it is a decision, not a tweak.
  15. - **Contact is defined by `SEND_TOKENS` in `07-Automation/partner_pipeline/stages.py`, not by stage name.** Only stage entries with a real outbound email/call/DM behind them count. Cat 26 `FINAL_INVOICE` is named "Pre-Call Email" and IS a send, while an out-of-scope funnel uses that same label for its creation stage, which sends nothing. Never key on the display name.
  16. - **Six retired stage ids** (cat 24 `PREPARATION`/`UC_CEAGAV`/`UC_V6JARB` = sends, `UC_N4JCMW` = bulk move; cat 26 `UC_PMLDJW`/`UC_GDHDJR` = the Feb 2026 feedback-survey send + reminder) are deleted from Bitrix and return bare tokens. `RETIRED_STAGE_NAMES` keeps them named. Deleting that map makes clients reached only through those stages read as never contacted when they were emailed.
  17. - **`07-Automation/data/outreach_touch_cache.json` holds every in-scope deal** (54 in the sample book). Deals in a terminal stage whose stage has not changed are reused instead of re-pulled: the sample's second run needed 18 history pulls, not 54.
  18. - **The XML census is not an activity log.** `<entered_date>` holds only the *current*-stage entry, so it reported zero activity for the week of 07-27, a week in which clients were emailed. Use stage history / the audit workbook.
  19. - **Weekly Partner Client Pipeline is LIVE:** Mondays 06:00 America/Chicago, autonomy `through_vault` (stubs + XML only; no enrichment, no Bitrix writes, routing only proposes). LTV = local `07-Automation/data/order_history.json` (Ines's roster baseline + weekly deltas); never trust a raw Plinth all-time query (`orders.fetch` truncates at ~70 orders/response).
  20. - **Ines's roster workbook is the seed** (never modify). On the live book its baseline was as of 2026-07-20; the shipped sample seeds from `07-Automation/sample/inputs/Partner-Clients-Roster_2026-09-07.xlsx`. Refreshed copies for the manual Google Drive swap go to `05-Outputs/partner-runs/Complete-Partner-Clients-List_updated-<date>.xlsx`: refresh only Plinth columns + append newly-qualified; human columns and the curated "2026 Partner Working List" tab stay untouched.
  21. - **Superseded seed:** the original founding-cohort spreadsheet (the 2026-06 Check-In + Winback cohorts) was superseded by Ines's workbook at the 2026-07-23 partner backfill and **deleted from the vault 2026-08-12**. It is not included here; older [[LEDGER]]/[[CHANGELOG]] entries that mention it are history. See [[Source-Documents]].
  22. - Segmentation axes that matter: `user_group_correct` (pipeline-computed tier; always filter on this, since raw `user_group` is blank on every sample stub) and `outreach_pipelines` (which Bitrix funnels the client sits in). `outreach_type` is retired: 0 stubs.
  23. - Partner Program tier definitions are Ines's (config in [[partner-thresholds]]): Palladium $2.5K to $8K, Platinum $8K to $25K, Iridium $25K to $75K, Rhodium $75K+, lifetime. Once a client is in the program they stay in it (per Ines).
  24. - Email/call templates are verbatim from the original outreach design doc (Check-In and Founder/CEO copy; not included). **Winback needs no vault template: the copy lives in Bitrix's cat-26 automation.** Routing only parks the client in the non-automated first-stage bucket; automation fires when Nora advances the deal. Her stage move is the send and the throttle (Matt, 2026-08-06).
  25. - Booking link in the Success Team template: https://book.meridiandisplay.example/intro-call.
  26. - **Pipeline rename (2026-08-06):** the Bitrix funnel "Partner Outreach" is now **"Partner Tier Upgrade"**: same categoryId 24, same `partner_outreach` XML/stub key. Scope: first touch + tier upgrades.
  27. - **Merge registry (2026-08-06):** `07-Automation/data/merge_registry.json` holds Matt-approved Plinth account merges; the weekly driver folds absorbed accounts into their survivor at classify time, drops absorbed `pl-` chunks from the XML census, and never re-adds them. Entries only on Matt's explicit approval + a LEDGER entry. Sample entry: [[Imogen Radcliffe]] (40374 → 40373, same person across an organisation's domain change).
  28. - **`client-enrich` is the one enrichment skill, shared not forked (Matt, 2026-08-11).** It is pipeline-aware across all four in-scope funnels, resolves cohorts from `outreach_pipelines` frontmatter, and checks the suppression list before spending Apollo credits. `client-enrich-hazel`, a byte-identical fork that froze 2026-07-15, is retired. Rationale + the lesson on forking in [[DECISIONS]].
  29. - **Never-contact domains (Matt, 2026-08-12).** `data/suppression_list.json` now carries a `domains` list, and `route` excludes any client whose email domain matches. **`harlowridge.example`**: Harlow Ridge Homes is a directly-partnered account (Hazel works with them directly). The mailboxes Matt re-tiered are **Rhodium regardless of per-mailbox spend** (a per-email override in [[partner-thresholds]], deliberately not domain-wide), and **no mailbox on the domain ever receives outreach email**. **`meridiandisplay.example`**: internal staff; name-shaped role screening missed a staff mailbox that ranks #6 by LTV among the dormant partner clients. Rationale in [[DECISIONS]]. Adding a domain is Matt's call, never inferred from data.
  30. ## Conventions
  31. - Stubs live flat in `03-Clients/client-stubs/` (one .md per client). The `03-Clients/` root holds only [[CLAUDE-clients]] and `partner-client-master-list.xml` (the Partner Program master list, schema 3.0; each client carries `<bitrix_id>` + `<plinth_id>`).
  32. - `08-Planning/` is a human-only planning space (Matt, Hazel, Ines). Claude reads it for context only, never writes there.
  33. - Scraped data is appended under `## Research`; human notes live under `## Human Notes` and are never overwritten by automation.
  34. - All in-vault references use wikilinks.
  35. ## Open items
  36. - **[2026-08-10] Two parked stages cannot be fully enumerated:** `C26:UC_JUUNES` ("Client") and `C16:NEW` each hold more deals than one call returns: date-filtered `list_records` returns max 200 rows/call and ignores sub-day time bounds. Matt is raising the client retrieval limit; once that lands, drop the caveat in [[Weekly-Partner-Pipeline-SOP]] Stage F5 and re-run to pick them up.
  37. - **[2026-08-10] The 2026-08-06 cat-36 stage rename was recorded against the wrong tokens** and is corrected in the driver: `C36:NEW` = "Active Check-In List", `C36:UC_LXCMAV` = "Dormant" (there is no "Partnership Flags" stage). The 08-06 reconcile wrote "Dormant" onto census blocks that are really Active Check-In List; the next `reconcile-deals` overwrites them.
  38. - ~~Fill Winback email copy [TBD]~~ **Moot 2026-08-06**: Winback is fully automated inside Bitrix; see [[pipeline-routing-rules]].
  39. - Enrichment is sparse for many Winback rows (no LinkedIn/title/location), so scraping should prioritize them; the partner-backfill stubs from 2026-07-23 (in the sample, every stub except the ten with hand-written research) are entirely unenriched (`## Research` = [TBD]).
  40. - ~~Watch/outreach pipeline entry rules are undecided~~ **RATIFIED 2026-08-06**: canonical rules in [[pipeline-routing-rules]] (07-Automation). The `route` stage (SOP Stage F4) only writes a candidate list; nothing routes into Bitrix automatically; Bitrix stays human-gated (candidate list → approval → partner-pipeline-push).
  41. - ~~[2026-07-24] XML census chunks carry no pipeline blocks yet~~ **RESOLVED 2026-08-06:** full three-funnel reconcile (every deal in cat 24/26/36) wrote placement onto the census (in the sample: 43 chunks, 45 blocks), closed deals included (they evidence "previously contacted" / "winbacked this spell" for routing). `bitrix_id` now holds ONLY verified deal-linked contact ids (every wrong Plinth/tracker value blanked). Review leftovers were worked in a 04-Working note (not included).
  42. - **[2026-07-24] Some legacy pipeline-mapped XML chunks have an empty `id` attribute** (pre-`pl-` convention). Left alone: renumbering desyncs their `client_ref`s; separate cleanup if wanted. (The shipped sample has none.)