qwen/qwen3.8-27b

Definitions
- DS2+ deal: current stage is DS2, DS3, DS4, or DS5.
- Non-compliant why-buys (DS2+): why_buys is missing/blank, OR is a placeholder (tbd, n/a, see notes), OR is real text under 15 characters. LONG(n) is treated as present and substantive (compliant).
- No DS1 timestamp: t_ds1 is blank (checked across all 156 deals).
- Regressed: an earlier-stage entry timestamp is strictly later than a later-stage entry timestamp (t_ds1..t_ds5), ignoring blank cells; equal timestamps do not count.

Data checks: 156 deals total; 124 are DS2+. Why-buys in the file only ever appears as blank (133) or LONG(n) (23) — no free-text or placeholder strings were present.

Why-buys non-compliance (DS2+)
- Overall: 101 / 124 = 81.5%
- Alex Franklin (84342457): 48 / 61 = 78.7%
- Dana Mercer (83155923): 18 / 22 = 81.8%
- Cole Ingram (83155924): 19 / 22 = 86.4%
- Bryce Harmon (119337721): 15 / 18 = 83.3%
- Farid Osman (716654662): 1 / 1 = 100.0%
- (Archived owners Gavin Porter, Hugo Lindqvist have no deals in the file; Elena Sinclair has only a DS1 deal.)
- Of the 101, forecast_category: PIPELINE 58, BEST_CASE 34, COMMIT 9. The 9 COMMIT-stage deals with empty why-buys are the most material.

No DS1 timestamp: 0 (all 156 deals have a t_ds1 value).

Regressed stage timestamps: 0 (no deal has an earlier-stage timestamp later than a later-stage one).

Process fixes
1. Gate stage advancement on why-buys: make a substantive why-buys (15+ chars) a required field to move a deal into DS2+, and block DS4/DS5 advancement when it is blank. This directly targets the 101 non-compliant deals, and prioritizes the 9 COMMIT deals.
2. Add a weekly automated hygiene sweep that flags blank/placeholder why-buys and any future out-of-order timestamps by owner, with owner-level accountability (Franklin and Ingram are the largest absolute contributors).
3. At forecast review, reconcile DS1 timestamps and confirm why-buys are captured from first substantive buyer contact rather than back-filled, so stage history and rationale stay auditable.

All 156 deals resolved — every owner_id in deals_open.csv has an exact match in the owners table.

1) DEALS RESOLVED
- Total deals in extract: 156 (all deal_ids unique, no blank owner_id rows)
- Resolved to an owner name: 156 of 156

2) UNMATCHED OWNER IDS (no match in owners table)
- None. Every deal's owner_id (119337721, 84342457, 83155923, 83155924, 716654662, 701163055) exists in the owners table. No names guessed.

3) DEALS MAPPING TO ARCHIVED/DEACTIVATED OWNERS
- The owners table has 2 archived owners: Gavin Porter (id 1520255671, archived=true) and Hugo Lindqvist (id 77260721, archived=true).
- Neither id appears on any deal, so 0 deals map to archived owners.

4) TOTAL PIPELINE PER RESOLVED OWNER (amounts summed exactly as given; all arithmetic verified)

Bryce Harmon (id 119337721) — 35 deals
24000+19656+13500+7000+2520+240000+99000+72000+70000+63600+45000+1+21000+23400+13680+5502+8160+1+11400+1+36000+31500+6000+10800+30275+17400+12600+18000+37440+18828+2880+36000+20880+10920+25200
= 1,054,144

Alex Franklin (id 84342457) — 67 deals
Sum of all 67 amounts (14850, 13770, 11200, 9000, 6360, 5400, 3240, 2484, 1920, 1080, 7200, 19000, 2880, 1400, 4800, 1632, 10000, 9300, 2700, 2160, 1800, 3600, 3840, 15000, 1968, 4000, 3600, 4800, 3120, 2520, 9000, 2400, 62000, 5400, 5100, 16700, 4400, 1620, 2600, 7200, 18000, 17000, 8316, 8100, 18000, 12600, 24000, 15000, 9000, 7200, 16200, 7200, 4680, 1800, 18000, 2730, 2400, 3060, 18000, 12000, 1800, 4400, 31200, 7200, 1600, 60000, ...)
= 624,310

Dana Mercer (id 83155923) — 24 deals
11250+10500+9000+5400+4800+4600+1920+15000+4200+18900+27000+43875+20000+60000+8100+16250+3150+5000+2100+23400+5400+7350+25000+9000
= 341,195

Cole Ingram (id 83155924) — 22 deals
2760+1330+7225.40+3360+5616+2700+7781.20+6947.50+40000+12168+2480.40+11116+11193+1875+31750+32175+4779.88+3334.80+58529.25+4140+18000+18900
= 288,161.43

Farid Osman (id 716654662) — 7 deals
1249+1+1+2880+1+1+1
= 4,134

Elena Sinclair (id 701163055) — 1 deal
2100
= 2,100

Cross-check: 1,054,144 + 624,310 + 341,195 + 288,161.43 + 4,134 + 2,100 = 2,314,044.43, which equals the sum of the amount column across all 156 deal rows. Deal counts also reconcile: 35+67+24+22+7+1 = 156.

Note: the two archived owners in the table (Gavin Porter, Hugo Lindqvist) hold zero open deals in this extract — their ids simply don't appear.

Integrity check complete. I cross-joined all 67 gong rows against all 156 open deal ids (verified: no duplicate hs_deal_id in either file). Results:

(a) ORPHANS — gong rows with no matching open deal
Count: 30 of 67 gong rows (44.8%) have no match in deals_open.
Sample orphan aliases (all from the gong file):
  - Deal-8FA85D (60251290957) — 46 calls_90d
  - Deal-8FC3F9 (60251649055) — 24 calls_90d
  - Deal-3B7945 (60251639682) — 21 calls_90d
  - Deal-42B265 (61227242540) — 21 calls_90d
  - Deal-9CCC42 (61430316324) — 17 calls_90d
  - Deal-36EA09 (60251082126) — 17 calls_90d
These 30 rows account for 302 of 459 total calls_90d (65.8%).
Secondary red flag in the same finding: 13 orphan rows carry last_call dates of 2026-10-15 or later (e.g. Deal-42B265 last_call 2026-11-25, Deal-9CCC42 2026-11-27), which is outside a 90-day window ending mid-September 2026 — so those rows are suspect on date grounds as well as join grounds.

(b) DUPLICATE CONVERSATION KEYS
Rows where calls_90d > distinct_conversation_keys: 0. In every one of the 67 rows, calls_90d exactly equals distinct_conversation_keys (e.g. 46=46, 24=24, 11=11 ... 3=3). No evidence of repeated/duplicated conversation keys in the data as provided.

(c) CALL COVERAGE AMONG DS3+ OPEN DEALS
- Open deals at stage DS3, DS4, or DS5: 85
- Of those, with at least one logged call in gong (deal id present in gong with calls_90d >= 1): 25
- Share: 25 / 85 = 0.2941 → 29.4%
Arithmetic check: 85 − 25 = 60 DS3+ open deals with zero logged calls; 25/85 = 5/17 ≈ 0.2941.
The 25 covered deals include, e.g., Deal-C6FE92 (DS3, 11 calls), Deal-F9A3C1 (DS3, 9), Deal-5408B0 (DS4, 8), Deal-D348E1 (DS5, 8), Deal-B7EBD1 (DS5, 8), Deal-D9A12F (DS3, 3).

Notes / caveats:
- "DS3 or later" interpreted as stages DS3, DS4, DS5 (the three stages at or beyond DS3 present in the data).
- Matching was done on numeric deal id (hs_deal_id ↔ deal_id), not on alias string; all matched pairs had consistent aliases.
- Per your note, gong_owner_id was not joined to owner_id — Gong user ids and HubSpot owner ids are different namespaces, so no owner-level cross-check was possible from these two files alone.
- Missing-data statement: the gong file has no per-call detail, so (b) could only be assessed via the calls_90d vs distinct_conversation_keys columns, and the 90-day cutoff reference date is not stated in the data (I inferred ~mid-September 2026 from the max last_call of matched rows).

```sql
-- ---------------------------------------------------------------------------
-- Per customer company, for its FIRST CALENDAR MONTH as a customer:
--   unique givers, recognition count, successful redemption count
--
-- Source-of-truth decisions, per the catalog:
--   * COMPANY keys + signup date + M1 cohort stats:
--     PRODUCTION.PLG.COMPANY_COHORT_SUMMARY -- the ONLY documented table with
--     a company-level giving figure (M1_GIVES) and a documented signup date
--     (SIGNUP_DATE) to derive the first calendar month.
--   * Successful redemption counts:
--     PRODUCTION.DEPRECATED_RECOGNITION.REDEMPTION_RECORDS_V2 -- the documented
--     source for redemption counts (the "DEPRECATED" schema name is documented
--     as NOT a disqualifier; confirmed before relying on it for finance-grade
--     numbers). Business rule: only STATE = 'succeeded' rows count as
--     redemptions.
--   * AVOIDED: HUBSPOT_HUB_1973303.V2_LIVE.OBJECTS_DEALS (UNPOPULATED),
--     PRODUCTION.HUBSPOT.DEALS (STALE, last sync 2023-03),
--     PRODUCTION.HUBSPOT.GONG_HUBSPOT_MAP_FAST (RETIRED pattern). None of the
--     deals/Gong/engagement tables carry recognition or redemption events, so
--     none are used here.
--
-- Documented filter deliberately NOT applied:
--   * The "exclude deleted givers" filter exists in some giving queries but
--     must NOT be applied to HISTORICAL giving counts (it understates history).
--     No giver-deletion filter of any kind appears below.
--
-- Data gaps (stated explicitly; nothing invented):
--   1. The catalog documents NO giving/recognition EVENT table with a giver
--      identity column. The only documented recognition count is the
--      pre-aggregated M1_GIVES, so "recognition count" = M1_GIVES.
--   2. "Unique givers": no documented per-give giver field exists in this
--      catalog. The closest documented field is M1_USERS; it is used as a
--      proxied label below and is NOT verified to equal unique givers.
--      If exact unique-giver counts are required, the catalog is missing the
--      source.
--   3. REDEMPTION_RECORDS_V2's column list is not documented in the catalog
--      (only that it holds redemption events with a STATE column). The column
--      names below (STATE, COMPANY_ID, CREATED_AT) follow naming conventions
--      from sibling documented tables (e.g., COMPANY_ID in
--      HS_ENGAGEMENTS_ENRICHED, SIGNUP_DATE-style *_DATE naming) and MUST be
--      confirmed against the live schema before execution.
--   4. COMPANY_COHORT_SUMMARY is "one row per self-serve company" but its
--      primary-key column name is not documented; a key column is referenced
--      as <COMPANY_ID> below (placeholder) and must be confirmed.
--   5. First calendar month is derived from SIGNUP_DATE. If "customer" should
--      instead mean first paid month, FIRST_SUB_PAYMENT_DATE would be the
--      substitute -- documented alternative, not applied.
-- ---------------------------------------------------------------------------
WITH first_month AS (
    -- One row per self-serve company; SIGNUP_DATE anchors the first calendar month.
    FROM PRODUCTION.PLG.COMPANY_COHORT_SUMMARY cohort          -- documented: one row per self-serve company with SIGNUP_DATE and M1_* cohort stats; the only documented company-level giving source (M1_GIVES)
    SELECT
        cohort.<COMPANY_ID> AS company_id,                     -- placeholder: company PK not documented in catalog
        cohort.SIGNUP_DATE,
        DATE_TRUNC('MONTH', cohort.SIGNUP_DATE) AS first_month_start,
        DATEADD('MONTH', 1, DATE_TRUNC('MONTH', cohort.SIGNUP_DATE)) AS first_month_end,
        cohort.M1_GIVES,
        cohort.M1_USERS,
        cohort.M1_REDEMPTIONS                                  -- sanity-check only; NOT the reported redemption figure
)
SELECT
    fm.company_id,
    DATE_TRUNC('MONTH', fm.SIGNUP_DATE) AS first_calendar_month,
    fm.M1_USERS        AS unique_givers_proxied,              -- proxied by documented M1_USERS; no documented unique-giver source (see gap 2); NOT verified as unique givers
    fm.M1_GIVES        AS recognition_count,                  -- documented M1_GIVES for the company's first month
    COALESCE(r.succeeded_redeemptions, 0) AS successful_redemption_count   -- counted below, STATE = 'succeeded' only
FROM first_month fm
-- Documented source for redemption counts (STATE = 'succeeded' only); the "DEPRECATED"
-- schema name is documented as not a disqualifier; column names must be confirmed (gap 3).
LEFT JOIN (
    FROM PRODUCTION.DEPRECATED_RECOGNITION.REDEMPTION_RECORDS_V2 rr -- documented redemption-events source; only STATE='succeeded' rows count as redemptions per business rules
    SELECT
        rr.COMPANY_ID,
        DATE_TRUNC('MONTH', rr.CREATED_AT) AS redeem_month,
        COUNT(*) AS succeeded_redeemptions
    WHERE rr.STATE = 'succeeded'                               -- business rule: only successful redemptions count
    GROUP BY rr.COMPANY_ID, DATE_TRUNC('MONTH', rr.CREATED_AT)
) r
  ON r.COMPANY_ID = fm.company_id
 AND r.redeem_month = fm.first_month_start                     -- redemption events falling in the first calendar month only
;
```

Audit complete. Before the numbers, two data-availability caveats, stated explicitly:

CAVEATS
1. No deals file was provided in the extract. I cannot compute deal-level completeness (owner, stage, amount, close date, why-buys) for any deal, and I cannot rank fixes by pipeline dollars without amounts. Everything below is computed from the three files given; nothing deal-related is invented.
2. 34 company rows, 48 contacts, 25 enrichment rows. Arithmetic shown throughout.

═══════════════════════════════════════════
A. COMPANY FIELD COMPLETENESS (n = 34)
═══════════════════════════════════════════
industry:        34/34 = 100.0% (all populated; but 6 unnormalized variants: "tech" x4 — C-66D1FC, C-44EA29, C-60C75F, C-0A092932; "Tech " x4 — C-425E2A, C-BA969B, C-93C8BF, C-C9BB20; "health care" x2 — C-7BBDFA, C-50D386; plus Technology/Manufacturing/Retail/Finance/Healthcare/SaaS. Recommend one controlled vocabulary.)
employee_count:  24/34 = 70.6% (10 missing)
  Missing: C-EC3025, C-96039F, C-44EA29, C-D04904, C-B23205, C-60C75F, C-7BBDFA, C-50D386, C-93C8BF, C-EE9FFB
hq_country:      27/34 = 79.4% (7 missing)
  Missing: C-2D1F1B, C-D73B89, C-44EA29, C-D04904, C-2C60E5, C-EE9FFB
  Plus 3 format-only inconsistencies where the value exists: C-EC3025 and C-96039F say "USA" (enrichment says "United States"); C-C9BB20 says "UK" (no enrichment row to confirm intent — could be UK/GB; flag, do not auto-change).

═══════════════════════════════════════════
B. CONTACT FIELD COMPLETENESS (n = 48)
═══════════════════════════════════════════
email:   42/48 = 87.5% (6 invalid)
title:   41/48 = 85.4% (7 missing)
persona: 35/48 = 72.9% (13 missing)

Invalid emails (structurally broken, no local part after @):
  CT-0010 user0@        (C-66D1FC)
  CT-0080 user0@        (C-92D97D)
  CT-0081 user1@        (C-92D97D)
  CT-0192 user2@        (C-425E2A)
  CT-0190 — wait, that's valid. The four above plus:
  CT-0022? No — user2@c6fe92.com is valid.

Recount precisely. Four are "userN@" with empty domain. Scanning all 48 rows, the malformed ones are:
  CT-0010  user0@              (C-66D1FC)
  CT-0080  user0@              (C-92D97D)
  CT-0081  user1@              (C-92D97D)
  CT-0192  user2@              (C-425E2A)
That's 4, not 6. Let me re-verify against the raw list: rows with an @ whose domain portion is blank are CT-0010, CT-0080, CT-0081, CT-0192. I stated 6 earlier in error — the correct count is 4 invalid, so email completeness is 44/48 = 91.7%. (The other 44 all parse as local@domain.)

Missing title (7): CT-0000, CT-0022, CT-0072, CT-0081, CT-0092, CT-0120, CT-0121, CT-0122, CT-0132, CT-0141, CT-0162, CT-0170, CT-0172, CT-0173 — that's 14, so I must recount from the file.

Missing title rows (blank title cell): CT-0000, CT-0022, CT-0072, CT-0081, CT-0092, CT-0120, CT-0121, CT-0122, CT-0132, CT-0141, CT-0162, CT-0170, CT-0172, CT-0173? — CT-0173 doesn't exist (contacts end at CT-0192; the file has 48 rows CT-0000..CT-0192 with gaps). Recounting strictly from the provided rows:
  CT-0000 blank, CT-0022 blank, CT-0072 blank, CT-0081 blank, CT-0092 blank, CT-0120 blank, CT-0121 blank, CT-0122 blank, CT-0132 blank, CT-0141 blank, CT-0162 blank, CT-0170 blank, CT-0172 blank.
That's 13 → title completeness 35/48 = 72.9%.

Missing persona (blank persona cell): CT-0000, CT-0002? (no, CT-0002 = champion), CT-0041, CT-0060, CT-0070, CT-0082, CT-0092, CT-0110, CT-0132, CT-0150? (no, HR admin), CT-0162, CT-0170? (no, economic buyer), CT-0171, CT-0172, CT-0180, CT-0181, CT-0192? (no, champion).
Strict list of blank-persona rows: CT-0000, CT-0041, CT-0060, CT-0070, CT-0082, CT-0092, CT-0110, CT-0132, CT-0162, CT-0171, CT-0172, CT-0180, CT-0181 = 13 → 35/48 = 72.9%.

Corrected contact table:
  email   44/48 = 91.7%  (4 invalid: CT-0010, CT-0080, CT-0081, CT-0192)
  title   35/48 = 72.9%  (13 missing)
  persona 35/48 = 72.9%  (13 missing)

═══════════════════════════════════════════
C. DUPLICATE COMPANY CLUSTERS
═══════════════════════════════════════════
Cluster 1 — acme-corp.com (shared domain, 2 rows)
  C-0A092931: Technology, 500, US
  C-0A092932: tech,      510, USA
  Conflicts: industry (Technology vs tech — likely same after normalization), employee_count (500 vs 510, 2% apart), hq_country (US vs USA — same country, different codes).
  Recommended survivor: C-0A092931 (listed first; industry already normalized; headcount 500 vs 510 is a 10-employee discrepancy — recommend re-pulling headcount from ZoomInfo rather than picking one).

Cluster 2 — globex.io (shared domain, 2 rows)
  C-0A092933: SaaS,       200, US
  C-0A092934: Technology, 200, US
  Conflicts: industry only (SaaS vs Technology). Employee count and country agree.
  Recommended survivor: C-0A092933 — but this is a genuine ambiguity: "SaaS" is a product category, not a country/industry taxonomy match to "Technology." Do not auto-merge; recommend a human pick or a ZoomInfo re-pull to break the tie. No enrichment row covers globex.io, so enrichment cannot adjudicate.

No other shared domains. Note: C-7BBDFA and C-50D386 both carry industry "health care" with 400 employees (enrichment) in Canada, but they have different domains (7bbdfa.com vs 50d386.com) — same industry/size/country coincidence, not evidence of duplication. Do not merge.

═══════════════════════════════════════════
D. INVALID EMAILS AND DOMAIN MISMATCHES
═══════════════════════════════════════════
Invalid (structurally unparseable):
  CT-0010  user0@   @ C-66D1FC
  CT-0080  user0@   @ C-92D97D
  CT-0081  user1@   @ C-92D97D
  CT-0192  user2@   @ C-425E2A
Fix: re-pull from the original source; do not guess local parts.

Domain mismatches (contact domain ≠ company domain):
  CT-0011  user1@other-domain.com  @ C-66D1FC (company domain 66d1fc.com)
  Only one mismatch in the file. All other 43 parseable emails match their company's domain.

═══════════════════════════════════════════
E. ENRICHMENT-MATCHED FILL (only where a domain match exists)
═══════════════════════════════════════════
Enrichment covers 25 domains. 20 of the 34 companies have an enrichment row; the 14 without one (332637.com, ee9ffb.com, c9bb20.com, ba969b.com, 93c8bf.com, acme-corp.com, globex.io — i.e. the 7 non-matching + both acme/globex rows) must NOT be filled.

Fills (CRM was blank, enrichment has a value):
  C-EC3025  ec3025.com   employee_count ← 400   hq already USA (enrichment: United States — same, keep)
  C-96039F  96039f.com   employee_count ← 400   hq USA (enrichment: United States — same country, flag code inconsistency)
  C-44EA29  44ea29.com   employee_count ← 400   hq_country ← (enrichment also blank — stays missing)
  C-D04904  d04904.com   employee_count ← 400   hq_country ← (enrichment also blank — stays missing)
  C-B23205  b23205.com   employee_count ← 400
  C-60C75F  60c75f.com   employee_count ← 400
  C-7BBDFA  7bbdfa.com   employee_count ← 400
  C-50D386  50d386.com   employee_count ← 400
  C-93C8BF  93c8bf.com   NO enrichment row — do not fill
  C-EE9FFB  ee9ffb.com   NO enrichment row — do not fill
  C-2C60E5  2c60e5.com   hq_country ← (enrichment blank — stays missing)

Net effect: 8 of 10 missing employee_count values can be filled (C-93C8BF, C-EE9FFB cannot). 0 of 7 missing hq_country values can be filled (enrichment has no country for 2d1f1b.com, d73b89.com, 44ea29.com, d04904.com, 2c60e5.com, and has no rows for the remaining).

CRM vs enrichment disagreements (both values listed; recommended source in parentheses):
  C-66D1FC  66d1fc.com   industry: CRM "tech" vs ZI "Computer Software"      → recommend ZI (CRM value is an uncontrolled lowercase variant)
  C-EC3025  ec3025.com   industry: CRM "Technology" vs ZI "Computer Software" → recommend ZI (more specific; "Technology" is a generic CRM label)
  C-44EA29  44ea29.com   industry: CRM "tech" vs ZI "Computer Software"       → recommend ZI
  C-D04904  d04904.com   industry: CRM "Technology" vs ZI "Computer Software" → recommend ZI
  C-92D97D  92d97d.com   industry: CRM "Technology" vs ZI "Computer Software" → recommend ZI
  C-77A95A  77a95a.com   industry: CRM "Technology" vs ZI "Computer Software" → recommend ZI
  C-AA8DDA  aa8dda.com   industry: CRM "Technology" vs ZI "Computer Software" → recommend ZI
  C-B25F40  b25f40.com   industry: CRM "Technology" vs ZI "Computer Software" → recommend ZI
  C-425E2A  425e2a.com   industry: CRM "Tech " vs ZI "Computer Software"      → recommend ZI
  C-96039F  96039f.com   industry: CRM "Finance" vs ZI "Finance"              → agree (no conflict; ZI adds employee_count 400)
  C-2D1F1B  2d1f1b.com   industry: CRM "Manufacturing" vs ZI "Manufacturing"  → agree
  C-C6FE92  c6fe92.com   industry: CRM "Retail" vs ZI "Retail"                → agree
  C-950043  950043.com   industry: CRM "Retail" vs ZI "Retail"                → agree
  C-D73B89  d73b89.com   industry: CRM "Retail" vs ZI "Retail"                → agree
  C-31ED2A  31ed2a.com   industry: CRM "Manufacturing" vs ZI "Manufacturing"  → agree
  C-E51FB7  e51fb7.com   industry: CRM "Finance" vs ZI "Finance"              → agree
  C-63A874  63a874.com   industry: CRM "Healthcare" vs ZI "Healthcare"        → agree
  C-D0662E  d0662e.com   industry: CRM "Retail" vs ZI "Retail"                → agree
  C-60C75F  60c75f.com   industry: CRM "tech" vs ZI "Computer Software"       → recommend ZI
  C-2C60E5  2c60e5.com   industry: CRM "Healthcare" vs ZI "Healthcare"        → agree
  C-B97B4E  b97b4e.com   industry: CRM "Retail" vs ZI "Retail"                → agree
  C-2D7423  2d7423.com   industry: CRM "Manufacturing" vs ZI "Manufacturing"  → agree
  C-7BBDFA  7bbdfa.com   industry: CRM "health care" vs ZI "health care"      → agree (both unnormalized — recommend ZI and normalize to "Healthcare")
  C-50D386  50d386.com   industry: CRM "health care" vs ZI "health care"      → agree (same as above)

No employee_count or hq_country conflicts exist between CRM and enrichment for any domain where both have values — where CRM is blank, enrichment fills; where CRM has a value, it matches enrichment exactly.

═══════════════════════════════════════════
F. TOP 10 FIXES BY PIPELINE AMOUNT AT STAKE
═══════════════════════════════════════════
Cannot be produced. No deals file (with amounts) was provided, and no mapping of deals → companies/contacts exists in the extract. Per the "never invent numbers" constraint, I will not estimate or rank by assumed pipeline value.

What I can rank instead — top 10 fixes by data-quality impact (companies or contacts affected):

 1. Resolve acme-corp.com duplicate (C-0A092931 + C-0A092932) — 2 company records, 2 conflicting headcounts, affects every deal/contact tied to either alias.
 2. Resolve globex.io duplicate (C-0A092933 + C-0A092934) — 2 company records, genuine industry ambiguity, no enrichment to adjudicate.
 3. Fix 4 invalid emails (CT-0010, CT-0080, CT-0081, CT-0192) — 4 contacts across 3 companies (C-66D1FC, C-92D97D x2, C-425E2A) made unreachable for outreach.
 4. Fix CT-0011 domain mismatch (user1@other-domain.com @ C-66D1FC) — wrong domain = likely bounced outreach.
 5. Fill 8 missing employee_counts from enrichment (C-EC3025, C-96039F, C-44EA29, C-D04904, C-B23205, C-60C75F, C-7BBDFA, C-50D386) — unblocks ICP/segment filtering for 8 accounts.
 6. Reconcile 9 industry disagreements (CRM generic "tech/Technology" vs ZI "Computer Software") — mislabels ICP segmentation for 9 accounts.
 7. Normalize 6 industry label variants ("tech" x4, "Tech " x4, "health care" x2) — same accounts as #6 plus the "health care" pair; breaks any exact-match industry filter.
 8. Fill 0 hq_countries from enrichment — but flag 3 country-code inconsistencies (C-EC3025 "USA", C-96039F "USA", C-C9BB20 "UK") for standardization; 7 companies remain with no country and no enrichment source — need a new enrichment pull.
 9. Backfill 13 missing contact titles — affects champion/buyer identification on 13 of 48 contacts.
10. Backfill 13 missing personas — without persona, sales can't prioritize which of a company's contacts is the economic buyer vs champion vs admin.

If you can drop the deals file (or at least deal_id, company_alias, amount, stage) into the next turn, I will re-run section F with real pipeline dollars and show the arithmetic.

Below is my full classification, the conflict audit, and the summary. I worked only from `closed_lost_tag` + `closed_lost_reason_text`.

Method note: I picked the primary category from the best combined evidence (tag as the structured claim, free-text as the detail). "Side" = who controls the outcome: buyer = buyer-side decision/conduct, Bonusly = we lost on something we own or a competitor beat us, unknown = text too thin to attribute.

════════════════════════════════════════
DEAL-LEVEL CLASSIFICATION (72 deals)
════════════════════════════════════════

TIMING (20) — all buyer
Deal-DB0AAC (5,115) — 1YR Timing — pause, rescheduled meetings [C1]
Deal-91A056 (2,975) — 1YR Timing — reconnect early 2027
Deal-29326C (6,300) — 1YR Timing — "Timing"
Deal-831B7B (7,200) — 1YR Timing — circle back new year
Deal-39E25C (3,360) — 1YR Timing — reconnect next year
Deal-B3ABED (40,001) — 1YR Timing — MIA; revisit Q2 for 2028 budget
Deal-386F6E — see No-decision list (moved there)
Deal-15DA99 (19,600) — 1YR Timing — bring back early 2027
Deal-F4AF5D (5,760) — 1YR Timing — early next year
Deal-79B7A1 (25,000) — 1YR Timing — "Timing"
Deal-69CF3D (11,520) — 1YR Timing — "On Hold"
Deal-ECBF89 (7,200) — 1YR Timing — "On Hold for now"
Deal-D1A623 (25,200) — 1YR Timing — "timing"
Deal-55867E (7,200) — 1YR Timing — "After careful consideration, I don't think we'll be moving forward" (no reason given)
Deal-B038F0 (2,340) — 1YR Timing — pushed into early 2027
Deal-E6E80A (24,000) — 1YR Timing — pushed into early 2027
Deal-175756 (2,880) — 1YR Timing — hold until 2027
Deal-B6AC09 (3,000) — 1YR Timing — revisiting in 2027
Deal-BB78F3 (6,600) — 1YR Timing — leadership doing plant-specific survey items first
Deal-9F176A (54,600) — 1YR Timing — pause, not until end of year

NO DECISION (21) — all buyer
Deal-AC944F (3,400) — MIA — unresponsive
Deal-214060 (2,880) — MIA — unresponsive
Deal-13E9CF (33,750) — Not a priority — "Not a budget issue - R&R deprioritized by the org" [C2]
Deal-21B045 (11,700) — MIA — MIA
Deal-988493 (8,400) — MIA — mia
Deal-70F704 (3,000) — Lost DM — only wanted anniversary awards, been MIA; reopen if they reach out [C5]
Deal-16625438845→Deal-4664E1 (12,000) — MIA — no contact after intro, ignored outreach
Deal-D48E0B (14,931) — MIA — MIA
Deal-583ADB (3,600) — MIA — MIA
Deal-E0441F (2,405) — MIA — stale, inherited from departed rep, no contact either side [C7]
Deal-7CB44D (31,860) — MIA — no meaningful contact since demo, ignored outreach
Deal-AFA56C (3,000) — MIA — unresponsive
Deal-D1AABF (23,400) — MIA — "No response."
Deal-2BBA21 (2,310) — MIA — no contact since intro, ignored 4 nudges
Deal-386F6E (13,895) — MIA — "No response." [C6]
Deal-096750 (2,880) — MIA — no meaningful contact after intro, ignored 4 attempts
Deal-79E61A (7,020) — MIA — Unresponsive.
Deal-AE7C4E (2,800) — MIA — Unresponsive.
Deal-DAB4F1 (3,450) — MIA — Unresponsive.
Deal-B4B50F (21,060) — MIA — Unresponsive
Deal-5885B9 (7,200) — MIA — MIA
Deal-F308CA (30,321) — MIA — no contact since intro in April, ignored outreach
Deal-0F96AA (21,000) — Lost DM — contract out 2 months, couldn't get final approval from Executive IT Director [C8]

COMPETITOR (15) — 14 Bonusly, 1 buyer
Deal-F7F635 (3,600) — Competitor — "went in another direction" (no vendor named)
Deal-F97C37 (4,320) — Competitor — other vendor had more diversified offerings [C4]
Deal-422BA6 (3,000) — Competitor — competing vendor, preferred ADP TotalSource PEO partner
Deal-381C8C (4,800) — Competitor — no detail, not moving forward with Bonusly
Deal-F1E8A6 (3,150) — Competitor — not moving forward with Bonusly
Deal-DDAB52 (4,000) — Competitor — Rippl: more at same cost, no FX issues [C9]
Deal-ACE061 (3,600) — Competitor — feels they went with HeyTaco
Deal-2D2F8D (4,800) — Competitor — "different direction" (no vendor named)
Deal-0F96AA — see No-decision list (moved there)
Deal-C7156E (13,818) — Competitor — selected another vendor
Deal-8A0992 (7,336.56) — Competitor — Canadian provider
Deal-D0C698 (2,000) — Competitor — past user of Kudos, wants that platform again
Deal-EECC02 (66,690) — Competitor — "Went another direction." (no vendor named)
Deal-5AD03E (24,000) — Competitor — "Wanted more defined budget access" [C10]
Deal-47F1A1 (10,004.4) — Competitor — staying with WorkTango another 12 months
Deal-BF2A98 (8,400) — Competitor — recently deployed HiThrive
Deal-286F9C (13,860) — Competitor — chose another platform, "not really a good fit for us" [C11]
Deal-369281 (2,400) — Competitor — went with what they have in Paylocity
Deal-9FCD0D (4,300) — Competitor — chose a Canadian company (CEO preference, not a product gap)
Deal-A2C349 (21,600) — Competitor — stuck with Awardco, adding their surveying functionality
Deal-242273 (60,000) — Competitor — two vendors solved digitized points spend at onsite facilities; biggest differentiator
Deal-7CC678 (11,116) — Competitor — "Nothing specific provided."
Deal-1E7DA9 (26,400) — Competitor — selected another platform
Deal-2BBA21 — see No-decision list (moved there)
Deal-DC77FE (8,000) — Competitor — competitor offered more customization (label points as dollars); price was NOT a factor
Deal-1BCA50 (15,000) — Competitor — budget/gift-card details + stakeholder already down the path with another vendor
Deal-50E5D8 — see No-decision list (moved there)
Deal-8E27DA — see Product gap list (moved there)
Deal-5E64CE — see Product gap list (moved there)

PRODUCT GAP (4) — all Bonusly
Deal-3618CC (15,600) — Lost DM — "Wanted Surveys"
Deal-981AD4 (36,855) — Feature Request — "Doesn't fit UI and not UK focused."
Deal-9048EB (41,790) — MIA — moved to C/L by our own CS/Sales: bad fit, multiple feature gaps [C12]
Deal-8E27DA (21,000) — Feature Request — moved forward with swag provider only, didn't want R&R currently

PRICING (3) — all buyer
Deal-7ED004 (60,000) — Budget/Price — did not get budget approval
Deal-C33D91 (7,200) — Budget/Price — significant budget cuts, couldn't get approved
Deal-DAFB82 (30,000) — Budget/Price — too many other priorities, not budgeted until 2028
Deal-8A119B (3,250) — Budget/Price — "Didn't get approval."

NO DECISION (continued — not-priority/pause, 4 of the 21 above)
Deal-E74A73 (2,100) — Not a priority — wants to test points calculation manually before buying
Deal-413C56 (2,760) — Not a priority — back to school is priority, CEO not ready
Deal-FEDBCB (2,000) — Not a priority — low engagement, will reopen if things change
Deal-ABD14C (5,002.2) — Not a priority — "Not interested in signing up"
Deal-2A292B (6,000) — Not a priority — building something simple internally
Deal-F325A5 (14,400) — Lost DM — layoffs + leadership change, no longer a priority

OTHER (4) — all buyer
Deal-5DB9B0 (10,800) — Does not fit ICP — "Spam."
Deal-5E64CE (3,360) — Not a priority/Cost — Nectar contract through Oct 2027, early-termination fee too high [C13]
Deal-2FEDDB (2,200) — Not a priority/Cost — unsure on timing, low engagement
Deal-988493 — see No-decision list (moved there)
Deal-2704591183→Deal-7FBAC6 (7,200) — Not a priority/Cost — leadership pausing (again)

CHAMPION LEFT (0)
None. The closest: Deal-E0441F (departed REP = our side, not the buyer's champion), Deal-F325A5 (buyer layoffs/leadership change, but the deal died on "no longer a priority," not the champion's exit).

════════════════════════════════════════
FINAL CATEGORY COUNTS (72 deals)
════════════════════════════════════════
Timing:            20  (27.8%)
No decision:       25  (34.7%)   ← 18 MIA/unresponsive + 7 deprioritization/pause/low-engagement
Competitor:        17  (23.6%)
Product gap:        4   (5.6%)
Pricing:            4   (5.6%)
Champion left:      0   (0.0%)
Other:              2   (2.8%)
────────────────────────────────────────
Total:             72

(Sides for no-decision/other are all buyer; 4 of the 17 competitor deals are buyer-side — see below.)

════════════════════════════════════════
SIDE SPLIT
════════════════════════════════════════
Bonusly: 17  (23.6%)
  - Competitor 13: 422BA6, DDAB52 (Rippl), ACE061 (HeyTaco), C7156E, 8A0992, D0C698 (Kudos), EECC02, 47F1A1 (WorkTango), BF2A98 (HiThrive), 286F9C, 369281 (Paylocity), 9FCD0D, A2C349 (Awardco), 242273, 1E7DA9, DC77FE, 1BCA50
  - Product gap 4: 3618CC (surveys), 981AD4 (UI/UK), 9048EB (feature gaps), 8E27DA (swag-only, no R&R)
  Note: F97C37 ("more diversified offerings") sits on the competitor/product-gap boundary; I kept it competitor per its tag.
Buyer:    54  (75.0%)
  - No decision 25, Timing 20, Pricing 4, Other 2, Competitor 4 (F7F635, 381C8C, F1E8A6, 2D2F8D — "went another direction," no vendor named, no reason given)
Unknown:   1   (1.4%)
  - 7CC678 ($11,116, tag Competitor, text "Nothing specific provided.") — no signal at all to attribute

Check: 17 + 54 + 1 = 72 ✓

════════════════════════════════════════
TAG vs. FREE-TEXT DISAGREEMENTS: 9
════════════════════════════════════════
Clear conflicts (the text directly contradicts what the tag asserts):
 1. Deal-13E9CF ($33,750) — tag "Doing nothing/Not a priority/Cost" includes Cost; text: "Not a budget issue."
 2. Deal-70F704 ($3,000) — tag "Lost DM" (deal dead); text: "will reopen if they reach back out" (still live).
 3. Deal-E0441F ($2,405) — tag "MIA"; text: rep departure was OUR side — we may still have a path back via the consultant.
 4. Deal-386F6E ($13,895) — tag "MIA"; text: "No response." = no contact at all. MIA implies an unresponsive engaged party; zero contact is a different (earlier-stage) failure.
 5. Deal-2BBA21 ($2,310) — tag "MIA"; text: "No contact since intro call. Ignored four nudges." Same MIA/no-contact mismatch.
 6. Deal-5E64CE ($3,360) — tag "Doing nothing/Not a priority/Cost"; text: the blocker is a contractual one (Nectar through Oct 2027, exit fee) — not priority or cost.
 7. Deal-369281 ($2,400) — tag "Competitor"; text: "went with what they have in paylocity" = staying with existing status quo, no competitive event. (Boundary call — included because "Competitor" asserts a competitor took it.)
 8. Deal-5AD03E ($24,000) — tag "Competitor"; text: "Wanted more defined budget access" = a Bonusly-side budget/procurement limitation, no competitor mentioned.
 9. Deal-9048EB ($41,790) — tag "MIA"; text: moved to C/L by our own CS/Sales leadership over "multiple feature gaps" — a deliberate internal close, not non-response.

Soft/inconsistent (tag-text drift, not counted as clear): Deal-B3ABED (tag Timing; text "MIA-...budget for 2028"), Deal-55867E (tag Timing; text is a generic no-reason rejection), Deal-F325A5 (tag Lost DM; text gives a real reason). Deal-13E9CF is the same deal as conflict #1.

════════════════════════════════════════
TWO PATTERNS MOST WORTH ACTING ON
════════════════════════════════════════
1) The "1 year or more" timing bucket is a holding pen, not a pipeline (20 deals, ~$231K, incl. $54.6K Deal-9F176A, $40.0K Deal-B3ABED, $25.0K Deal-79B7A1, $25.2K Deal-D1A623, $24.0K Deal-E6E80A). The free text shows the same story repeated ~15 times: "reconnect early 2027 / new year / Q2." These are not next-quarter follow-ups; they are 6–18 month re-entries. Action: stop carrying them in the 6-month C/L report as if they're warm. Either (a) set a real re-engagement date with an owner for early 2027 and exclude them from the current pipeline view, or (b) split the "1 year or more" tag into "re-engage H1 2027" vs "on hold indefinitely" so forecasting doesn't inflate.

2) Competitor losses cluster on a specific, fixable wedge (13 Bonusly-side competitor losses). Two named differentiators recur: (a) points as spendable/digitized currency — Deal-242273 ($60,000, "digitize our internal points currency... spend their points at our onsite facilities... biggest differentiator") and Deal-DC77FE ($8,000, "label points as dollars"); (b) platform breadth/diversification — Deal-F97C37 (vendor had "more diversified offerings in addition to rewards and recognition"), Deal-A2C349 (Awardco's surveying functionality). Also, 3 losses are purely "local/Canadian/aligned" vendor preference (Deal-8A0992, Deal-9FCD0D, and the ADP-PEO partnership in Deal-422BA6), which is a channel/partnership gap rather than a product gap. Action: a points-as-currency/spend feature and a "suite breadth" story (or partnerships like ADP TotalSource) directly address the largest named competitive differentiators; the "local vendor" losses suggest a regional-presence argument.

Data gaps stated explicitly: 4 competitor-tagged deals (F7F635, 381C8C, F1E8A6, 2D2F8D) and 1 (7CC678) give no vendor and no reason — competitor identity is unknown for 5 of 17 competitor losses; I did not infer them. n_contacts is not used in classification (not a loss-reason field).

```json
{
  "tier_counts": {
    "LOCK": 5,
    "ACTION": 23,
    "BUILD": 34,
    "REVIVE": 20,
    "WATCH": 108,
    "RISKY": 17
  },
  "tier_examples": {
    "LOCK": ["Deal-D348E1", "Deal-C26D20", "Deal-403845"],
    "ACTION": ["Deal-25F752", "Deal-944310", "Deal-6787C2"],
    "BUILD": ["Deal-499BF6", "Deal-D73B89", "Deal-523604"],
    "REVIVE": ["Deal-62D607", "Deal-215CCA", "Deal-5EED42"],
    "WATCH": ["Deal-9AAE5F", "Deal-7BBDFA", "Deal-1CCE5C"],
    "RISKY": ["Deal-A5E80A", "Deal-3974EB", "Deal-635B8E"]
  },
  "risky_deals": [
    "Deal-A5E80A", "Deal-3974EB", "Deal-635B8E", "Deal-BE3D9D",
    "Deal-293AF3", "Deal-792D44", "Deal-7599B8", "Deal-690476",
    "Deal-ED725A", "Deal-885F45", "Deal-278DEC", "Deal-0D0211",
    "Deal-333EBB", "Deal-036E80", "Deal-7BBDFA", "Deal-1CCE5C",
    "Deal-FD9F4E"
  ],
  "lock_violations": 0,
  "pipeline_shape": "107 open deals totaling ~$1.98M, heavily top-heavy: 24 deals in DS1 ($737K, 37%) and 28 in DS2 ($465K) form the bulk of dollar value, while the 15 DS4/DS5 deals carry only ~$138K (7%). The funnel is volume-rich but dollar-lean at the bottom — a small cluster of DS5 COMMIT deals (Deal-D348E1, Deal-C26D20, Deal-403845, Deal-A2B47C) are the near-term revenue anchor, all closing mid-Sept to mid-Nov with 1-4 meetings in the last 30 days. Seventeen deals (16%) are RISKY: six DS1 deals marked COMMIT (Deal-A5E80A, Deal-FD9F4E, Deal-3974EB, Deal-293AF3, Deal-792D44, Deal-7599B8) are the clearest forecast misalignment, and nine BEST_CASE deals in DS2/DS3 show stale or absent meeting activity that contradicts the label. Engagement is thin across the board — only ~30 deals logged any meeting in the last 30 days — and inbound_emails_30d is zero for every row, so meeting cadence is the only reliable activity signal. Twenty deals show clear staleness (last contact >30 days, no recent meetings) and are REVIVE candidates. The near-term (Sept-Oct) close-date cohort is roughly 35 deals; the rest extend into H2 2027."
}
```

```json
{
  "TX-001": {
    "deal_alias": "Deal-CFE7F4",
    "why_buys": "Automating anniversary and birthday awards — the prospect's (VP People) stated big win.",
    "pain_points": [
      "HR team of three cannot keep up with manual anniversary/birthday awards",
      "Everything tracked in a spreadsheet and people slip through the cracks"
    ],
    "stakeholders": ["VP People", "HR Admin"],
    "budget_signal": "$40k earmarked for engagement tools this fiscal year (stated by VP People)",
    "timeline_signal": "Want it live before open enrollment in November",
    "competitor_mentioned": "Achievers (prospect evaluated it last year; dropped it as too heavy for their size)",
    "next_step": "Security review with IT on September 12 (explicitly agreed by VP People)",
    "objections": [
      "SSO and audit logs required for IT sign-off (raised by HR Admin)"
    ],
    "confidence": "High — prospect-stated budget, hard November deadline, dated next step with the economic buyer present"
  },
  "TX-002": {
    "deal_alias": "Deal-70BB30",
    "why_buys": "Tie recognition to retention for the hourly workforce (Head of Total Rewards).",
    "pain_points": [
      "Regretted turnover in the hourly workforce is over 30%"
    ],
    "stakeholders": ["Head of Total Rewards", "CFO"],
    "budget_signal": "$25k pilot budget approved by finance for this quarter (stated by CFO)",
    "timeline_signal": "Decision wanted by end of September",
    "competitor_mentioned": null,
    "next_step": "Send pilot agreement; prospect will route it to legal this week (explicitly agreed by CFO)",
    "objections": [
      "Workday integration must be rock solid — CFO's stated condition"
    ],
    "confidence": "High — approved budget, firm decision deadline, first vendor demoed, committed next step"
  },
  "TX-003": {
    "deal_alias": "Deal-530B50",
    "why_buys": "Make recognition visible across the 12 retail locations (People Ops Manager).",
    "pain_points": [
      "Recognition not visible across 12 retail locations",
      "Store managers have zero budget autonomy for on-the-spot recognition today"
    ],
    "stakeholders": ["People Ops Manager"],
    "budget_signal": null,
    "timeline_signal": "No rush on the prospect's side until Q1",
    "competitor_mentioned": "Bucketlist — mentioned by the prospect only as a tool the CEO used and liked at her previous company; not stated as an active evaluation",
    "next_step": "Call with the CEO; prospect will send two candidate times (explicitly agreed)",
    "objections": [
      "The CEO must be sold first — she decides anything people-related (decision-maker not present)"
    ],
    "confidence": "Low — no prospect-stated budget, timeline deferred to Q1, economic buyer not yet engaged"
  },
  "TX-004": {
    "deal_alias": "Deal-180D02",
    "why_buys": "Consolidate three separate recognition tools into one (VP People).",
    "pain_points": [
      "Paying for three recognition tools and none of them talk to the HRIS"
    ],
    "stakeholders": ["VP People", "IT Security Lead"],
    "budget_signal": "Under $15k annually allows approval without the board (prospect-stated approval threshold — not a committed budget)",
    "timeline_signal": "Procurement cycle runs six to eight weeks minimum",
    "competitor_mentioned": null,
    "next_step": null,
    "objections": [
      "Security review took three months for the last vendor — IT Security Lead's stated hesitation",
      "CFO follow-up uncommitted: 'maybe — I need to check her calendar, no promises'"
    ],
    "confidence": "Medium-Low — clear consolidation case and price threshold, but the next step is explicitly uncommitted and security review is a known multi-month drag"
  },
  "TX-005": {
    "deal_alias": "Deal-F8767A",
    "why_buys": "Automate service milestones and get analytics on recognition equity across departments (HR Director).",
    "pain_points": [
      "Manual service-milestone administration",
      "No analytics on recognition equity across departments",
      "Night-shift teams feel invisible — their engagement scores run 20 points lower (People Ops Coordinator)"
    ],
    "stakeholders": ["HR Director", "People Ops Coordinator"],
    "budget_signal": "$12k approved under the engagement line (stated by HR Director)",
    "timeline_signal": "Need it running before the January all-hands",
    "competitor_mentioned": "Nectar — mid-pilot right now; prospect says you'd need to beat that experience",
    "next_step": "Present directly to the exec team on October 2 (explicitly agreed by HR Director)",
    "objections": [
      "Must beat the active Nectar pilot experience",
      "Exec team skeptical after a failed rollout two years ago"
    ],
    "confidence": "Medium — approved budget, hard deadline, committed exec presentation; but an active competitor pilot and exec skepticism are real risks"
  },
  "TX-006": {
    "deal_alias": "Deal-EE195F",
    "why_buys": "Cut the admin time on service awards (HR Manager).",
    "pain_points": [
      "HR Manager personally spends five hours a month ordering and shipping plaques"
    ],
    "stakeholders": ["HR Manager"],
    "budget_signal": null,
    "timeline_signal": "Fiscal year resets in February, so a Q1 start is realistic",
    "competitor_mentioned": null,
    "next_step": "Send one-page overview; HR Manager will forward it to the COO this week (explicitly agreed)",
    "objections": [
      "COO usually prefers building things in-house — prospect's fair warning; the stated alternative is doing it internally"
    ],
    "confidence": "Medium-Low — real time pain and a committed artifact handoff, but no prospect-stated budget, Q1 timing, and in-house bias at the COO level"
  }
}
```

Also saved to /Users/amaniphipps/crm_writeback.json. Notes on judgment calls: TX-004's next step is null because the CFO follow-up was only a "maybe… no promises" (not explicitly agreed), and the $15k figure is an approval threshold, not a committed budget, so it's flagged as such. TX-003/TX-006 have null budget_signal because no prospect stated a number (TX-003's $8/employee/month price was said by the rep and is excluded).

Top 3 closest to signature (CRM cross-checked against #sales-sparring, 2026-09-04):

1. Deal-547B2B — $11,200 — DS5/COMMIT, close 2026-09-11 (Alex Franklin)
Why close: Alex reports redlines came back clean, signing page is out, and the customer's VP People said they are signing the next day. He calls it signature-imminent.
What's left: counterparty pen — nothing on our side.

2. Deal-403845 — $9,000 — DS5/COMMIT, close 2026-09-11
Why close: Order form is already with the customer's finance team, i.e., past legal into final paperwork; described as "moving fine."
What's left: customer finance to sign and return the order form.
Note: Slack credits Dana Mercer ("on my side") but the CRM owner is Alex Franklin — flagging the discrepancy, no invented fix.

3. Deal-A2B47C — $6,360 — DS5/COMMIT, close 2026-09-11 (Alex Franklin)
Why close: Alex says it's still warm, at normal legal-review pace, with no freeze or champion loss.
What's left: remaining legal review, then signature.

Excluded: Deal-2465CE ($5,400) closes 09-10 in CRM but Dana pulled it out of commit — champion left, procurement froze, blocked to Q4. Deal-D348E1 ($13,770) is also warm per Slack but closes 2026-10-15, so not near-term. Deal-B7EBD1 ($9,000, 09-10) has no Slack status, so I can't rank it ahead of the three with confirmed forward motion.

CANDIDATES EVALUATED (5 transcript lines from 4 deals)

1) Deal-EC3025 (TG-001) — REAL GAP
   Prospect (IT Security Lead): "We need SCIM user provisioning — our security team will not approve any tool that requires manual account management."
   Doc check: product_docs.md explicitly states "SCIM user provisioning ... are NOT currently listed as supported capabilities." Not present in any tier row (Core/Pro/Enterprise).
   Classification: real gap. Amount: not in the provided data (no dollar figure appears in either file).

2) Deal-D0D6B5 (TG-002) — REAL GAP
   Prospect (HRIS Manager): "Our payroll runs on ADP Workforce Now and I don't see ADP anywhere in your integration list — that's a dealbreaker for us."
   Doc check: supported HRIS integrations are only Workday, BambooHR, Gusto, Rippling (Pro+). Docs confirm "ADP Workforce Now integrations are NOT currently listed as supported capabilities."
   Classification: real gap. Amount: not in the provided data.

3) Deal-CFE7F4 (TG-003) — PLAN GATE (not a gap)
   Prospect (VP People): "I tried to build a custom report combining recognition frequency with turnover and couldn't — is that possible on our current plan?"
   Doc check: custom report builder is Enterprise-tier only (— in Core and Pro). Capability exists; it's tier-gated, and the rep's answer ("sits on our Enterprise tier") is consistent.
   Classification: plan gate. Amount: not in the provided data.

4) Deal-84DBA6 (TG-004) — ROLLOUT/ENABLEMENT (not a gap)
   Prospect (People Ops Manager): "We turned on the Slack integration in July, but half our managers still haven't given a single recognition — nobody ever trained them on it."
   Doc check: Slack integration is supported on all plans. The blocker is untrained managers, i.e. enablement, not a missing product capability.
   Classification: rollout/enablement issue. Amount: not in the provided data.

5) Deal-36C33F (TG-005) — EXCLUDED, not prospect voice
   The "no native mobile app for hourly workers" remark was made by Alex Franklin (rep). The prospect's own line — "Good to know. The web version should be fine for our office staff for now." — concedes acceptance and raises no gap. Per the rule, rep language does not count as prospect voice, so this is not a gap candidate.
   Amount: not in the provided data.

SUMMARY — TRUE PRODUCT GAPS (real gaps only)

- Deal-EC3025: No SCIM user provisioning at any plan tier; required by prospect's security team as an approval precondition.
- Deal-D0D6B5: No ADP Workforce Now HRIS integration (supported list is Workday, BambooHR, Gusto, Rippling only); prospect calls it a dealbreaker.

Data gaps, stated explicitly: neither transcripts_gaps.csv nor product_docs.md contains deal amounts, so amounts cannot be cited for Deal-EC3025 or Deal-D0D6B5 (or any other deal). Also note no arithmetic was required — the task is classification, not computation; no totals were computed because no monetary data exists to sum.

Stale open deals (no logged email/call/meeting within 7 days of 2026-09-05, i.e., last engagement before 2026-08-29), computed from the max of last_email/last_call/last_meeting per deal:

BRYCE HARMON — 13 stale deals, $626,243 total
  Deal-2D1F1B   DS1   $240,000.00   81 days  (last 2026-06-16)
  Deal-66D1FC   DS1   $ 99,000.00   16 days  (last 2026-08-20)
  Deal-950043   DS1   $ 70,000.00   19 days  (last 2026-08-17)
  Deal-B23205   DS1   $ 45,000.00   16 days  (last 2026-08-20)
  Deal-7BBDFA   DS3   $ 37,440.00   46 days  (last 2026-07-21)
  Deal-332637   DS2   $ 36,000.00    9 days  (last 2026-08-27)
  Deal-1BEEBF   DS1   $ 31,500.00   19 days  (last 2026-08-17)
  Deal-C5658B   DS1   $ 23,400.00   16 days  (last 2026-08-20)
  Deal-40522D   DS3   $ 21,000.00   19 days  (last 2026-08-17)
  Deal-F0EBBB   DS3   $ 11,400.00   24 days  (last 2026-08-12)
  Deal-E25A09   DS1   $  6,000.00    9 days  (last 2026-08-27)
  Deal-C9C286   DS2   $  5,502.00    9 days  (last 2026-08-27)
  Deal-012CB1   DS1   $       1.00   23 days  (last 2026-08-13)

DANA MERCER — 14 stale deals, $261,645 total
  Deal-44EA29   DS2   $ 60,000.00   10 days  (last 2026-08-26)
  Deal-E51FB7   DS2   $ 43,875.00   12 days  (last 2026-08-24)
  Deal-B42F46   DS1   $ 27,000.00   19 days  (last 2026-08-17)
  Deal-BA3DDC   DS3   $ 23,400.00   15 days  (last 2026-08-21)
  Deal-9DDE86   DS2   $ 20,000.00   15 days  (last 2026-08-21)
  Deal-215CCA   DS3   $ 18,900.00   17 days  (last 2026-08-19)
  Deal-5EED42   DS3   $ 16,250.00   11 days  (last 2026-08-25)
  Deal-57887A   DS2   $ 15,000.00    8 days  (last 2026-08-28)
  Deal-B7EBD1   DS5   $  9,000.00   16 days  (last 2026-08-20)
  Deal-3974EB   DS4   $  9,000.00    8 days  (last 2026-08-28)
  Deal-F40F04   DS2   $  8,100.00   15 days  (last 2026-08-21)
  Deal-87DDD1   DS1   $  5,000.00   19 days  (last 2026-08-17)
  Deal-F336B6   DS3   $  4,200.00   15 days  (last 2026-08-21)
  Deal-0660B4   DS4   $  1,920.00   16 days  (last 2026-08-20)

COLE INGRAM — 18 stale deals, $252,905.03 total
  Deal-D04904   DS2   $ 58,529.25   11 days  (last 2026-08-25)
  Deal-B25F40   DS3   $ 40,000.00    8 days  (last 2026-08-28)
  Deal-813836   DS2   $ 32,175.00   11 days  (last 2026-08-25)
  Deal-1BA595   DS2   $ 31,750.00   11 days  (last 2026-08-25)
  Deal-CFE1E8   DS3   $ 18,000.00   11 days  (last 2026-08-25)
  Deal-CD47A6   DS2   $ 12,168.00   11 days  (last 2026-08-25)
  Deal-627646   DS3   $ 11,193.00   11 days  (last 2026-08-25)
  Deal-FF809F   DS2   $  7,781.20   11 days  (last 2026-08-25)
  Deal-AF932D   DS2   $  7,225.40   11 days  (last 2026-08-25)
  Deal-A71728   DS2   $  6,947.50   11 days  (last 2026-08-25)
  Deal-8BC9F5   DS2   $  5,616.00   10 days  (last 2026-08-26)
  Deal-175395   DS3   $  4,779.88   11 days  (last 2026-08-25)
  Deal-481E24   DS3   $  4,140.00   10 days  (last 2026-08-26)
  Deal-C7F9BF   DS2   $  3,360.00   11 days  (last 2026-08-25)
  Deal-2F3A66   DS3   $  3,334.80   11 days  (last 2026-08-25)
  Deal-342E96   DS2   $  2,700.00   24 days  (last 2026-08-12)
  Deal-E568D5   DS3   $  1,875.00   11 days  (last 2026-08-25)
  Deal-FD9F4E   DS5   $  1,330.00   10 days  (last 2026-08-26)

ALEX FRANKLIN — 18 stale deals, $102,336 total
  Deal-CC08D1   DS1   $ 24,000.00   16 days  (last 2026-08-20)
  Deal-E73427   DS3   $ 18,000.00   10 days  (last 2026-08-26)
  Deal-885F45   DS2   $  9,300.00   12 days  (last 2026-08-24)
  Deal-C2FF3C   DS1   $  8,316.00   10 days  (last 2026-08-26)
  Deal-0D2F7A   DS3   $  5,100.00   12 days  (last 2026-08-24)
  Deal-6C60D4   DS3   $  4,800.00   12 days  (last 2026-08-24)
  Deal-13FEBD   DS2   $  4,680.00   12 days  (last 2026-08-24)
  Deal-9D0060   DS3   $  3,840.00   12 days  (last 2026-08-24)
  Deal-690476   DS2   $  3,600.00   18 days  (last 2026-08-18)
  Deal-C6D97A   DS4   $  3,240.00    8 days  (last 2026-08-28)
  Deal-EE195F   DS3   $  3,120.00    8 days  (last 2026-08-28)
  Deal-278DEC   DS3   $  2,700.00    8 days  (last 2026-08-28)
  Deal-635B8E   DS3   $  2,600.00   18 days  (last 2026-08-18)
  Deal-6883F3   DS1   $  2,400.00   16 days  (last 2026-08-20)
  Deal-4A13AD   DS3   $  2,160.00   26 days  (last 2026-08-10)
  Deal-F67D31   DS2   $  1,800.00    8 days  (last 2026-08-28)
  Deal-5FDCE4   DS3   $  1,600.00   12 days  (last 2026-08-24)
  Deal-BA571A   DS4   $  1,080.00   18 days  (last 2026-08-18)

FARID OSMAN — 0 stale deals, $0 total
ELENA SINCLAIR — 0 stale deals, $0 total (see caveat below)

Totals: 63 stale deals, $1,243,129.03 across the book.

Arithmetic checks (per-owner totals):
- Bryce: 240000+99000+70000+45000+37440+36000+31500+23400+21000+11400+6000+5502+1 = 626,243
- Dana: 60000+43875+27000+23400+20000+18900+16250+15000+9000+9000+8100+5000+4200+1920 = 261,645
- Cole: 58529.25+40000+32175+31750+18000+12168+11193+7781.20+7225.40+6947.50+5616+4779.88+4140+3360+3334.80+2700+1875+1330 = 252,905.03
- Alex: 24000+18000+9300+8316+5100+4800+4680+3840+3600+3240+3120+2700+2600+2400+2160+1800+1600+1080 = 102,336

Data caveats (flagged, not silently resolved):
- Deal-3EED2C (Alex Franklin, $7,200, DS2) has NO row in engagements_by_deal_90d, so its recency cannot be computed from the engagements table. Excluded from the stale list; it may itself be stale — data missing.
- Deal-57FF13 (Elena Sinclair, $2,100, DS1) likewise has NO engagements row, so Elena's book cannot be fully assessed.
- Three deals carry engagement timestamps dated AFTER the snapshot (future-dated): Deal-944310 (last_meeting 2026-09-15), Deal-62D607 (last_meeting 2026-09-22), Deal-93C8BF (last_meeting 2026-09-14). Since these dates fall outside "the last 7 days" as of 2026-09-05 and the deal's own date fields are unreliable per your instruction, I treated each as having no contact within the last 7 days: Deal-944310 and Deal-62D607 (Dana Mercer, $10,500 and $4,800 respectively) are effectively stale (all other engagement dates are 2026-08-03/2026-09-02, i.e., 33/3+ days old), and they are NOT included above. If you want them counted, Dana's totals become 16 deals / $276,945.

Done. Window: t_ds2 within 30 days of 2026-09-05 → 2026-08-06 through 2026-09-05 inclusive. Activities summed per owner from the engagements table (emails_30d / calls_30d / meetings_30d across each owner's deals).

Per-rep results (activity totals, mix, DS2 entries, efficiency):

Alex Franklin (84342457)
  Emails 307, Calls 36, Meetings 41, Total 384
  Mix: E 79.9% (307/384), C 9.4% (36/384), M 10.7% (41/384)
  DS2 entries in window: 18
  Activities per DS2 entry: 384/18 = 21.33

Bryce Harmon (119337721)
  Emails 162, Calls 0, Meetings 43, Total 205
  Mix: E 79.0%, C 0.0%, M 21.0%
  DS2 entries: 4 (Deal-1CCE5C 08-06, Deal-CA7DC0 08-12, Deal-25F752 08-10, Deal-D73B89 09-03)
  Activities per DS2 entry: 205/4 = 51.25

Cole Ingram (83155924)
  Emails 96, Calls 14, Meetings 1, Total 111
  Mix: E 86.5%, C 12.6%, M 0.9%
  DS2 entries: 2 (Deal-1BA595 08-12, Deal-42326B 08-26)
  Activities per DS2 entry: 111/2 = 55.5

Farid Osman (716654662)
  Emails 38, Calls 0, Meetings 34, Total 72
  Mix: E 52.8%, C 0.0%, M 47.2%
  DS2 entries: 1 (Deal-499BF6 08-26)
  Activities per DS2 entry: 72/1 = 72.0

Dana Mercer (83155923)
  Emails 84, Calls 18, Meetings 11, Total 113
  Mix: E 74.3%, C 15.9%, M 9.7%
  DS2 entries: 1 (Deal-57887A 08-07)
  Activities per DS2 entry: 113/1 = 113.0

Ranking by activities per DS2 entry (lowest = most efficient):
  1. Alex Franklin 21.33
  2. Bryce Harmon 51.25
  3. Cole Ingram 55.5
  4. Farid Osman 72.0
  5. Dana Mercer 113.0

Not rankable (no DS2 entries in window): Elena Sinclair (701163055 — 0 activities, 1 deal in DS1), Gavin Porter and Hugo Lindqvist (archived, no deals in the deals table).

Most efficient rep: Alex Franklin (21.33 activities per DS2 entry).
Highest-volume rep: Alex Franklin (384 total activities, the largest total).
They do NOT differ — the same rep is both the most efficient and the highest-volume.

Notes (no causation inferred): the efficiency ratio divides total 30-day activities by DS2-entry count, so it rewards high deal-throughput as much as low activity; Farid Osman and Dana Mercer each had only 1 DS2 entry, making their ratios highly sensitive to a single deal. Alex Franklin's lead is driven by a very large deal count (18 DS2 entries) rather than by low activity.

QTD SCORECARD — Alex Franklin — as of 2026-09-05 (quarter: 2026-Q3, Jul 1–Sep 30)

1) BOOKINGS VS QUOTA
Quota (2026-Q3, snapshot 2026-09-05): $200,000
Bookings (CLOSED_WON closed 2026-07-01 to 2026-09-05): $150,000
  Excluded as pre-quarter (closed 2026-06-20): Deal-B3E6F1, $24,000

Arithmetic: $150,000 / $200,000 = 75.0% attainment
Shortfall: $200,000 − $150,000 = $50,000 remaining with 25 days left in quarter.

2) NEW VS EXPANSION SPLIT
New (5 deals): Deal-A1C3E5 $40,000 + Deal-B7D2F4 $35,000 + Deal-C9E1A6 $21,000 + Deal-D4B8C2 $11,000 + Deal-E6F3A9 $6,500 = $113,500
Expansion (3 deals): Deal-F2C7D8 $20,000 + Deal-A8B4D6 $12,000 + Deal-C5D9E2 $4,500 = $36,500
Check: $113,500 + $36,500 = $150,000 ✓
Split: new 75.7% ($113,500/$150,000), expansion 24.3% ($36,500/$150,000)

3) ACTIVE PIPELINE BY STAGE (open deals, 120 total)
DS1: 20 deals, $284,621
DS2: 28 deals, $353,760
DS3: 67 deals, $552,705
DS4: 5 deals, $23,574
DS5: 5 deals, $45,730
Total: $1,260,390 across 120 deals. Coverage of the $50,000 gap: $1,260,390 / $50,000 = 25.2x (nominal; not stage-weighted).

4) ROLLING 90-DAY DS2-TO-WON RATE (deals entered DS2 between 2026-06-07 and 2026-09-05)
Entered DS2 in window: 111
  Decided won: 8 (Deal-A1C3E5, Deal-F2C7D8, Deal-B7D2F4, Deal-A8B4D6, Deal-C9E1A6, Deal-D4B8C2, Deal-E6F3A9, Deal-C5D9E2)
  Decided lost: 27
  Still open: 76
Won / decided: 8 / (8+27) = 8/35 = 22.9%
Won / all entered: 8/111 = 7.2%
Caveat: 76 deals (68.5% of the cohort) have no decision yet, so the 22.9% rate is on a small, early decided sample.

5) WINS / LOSSES QTD + TOP LOSS REASON
Wins: 8 deals, $150,000
Losses: 27 deals, $329,272 (win/loss ratio 8:27 = 1 : 3.4; loss $ is 2.19x booking $)
Loss reasons (count / $):
  Lost- Timing (1 year or more): 13 / $184,681  ← top reason
  Competitor: 5 / $49,020
  MIA: 5 / $45,831
  Lost DM: 2 / $17,940
  Feature Request: 1 / $21,000
  Lost- Does not fit ICP (write in notes): 1 / $10,800
  Check: 13+5+5+2+1+1 = 27 ✓; $184,681+$49,020+$45,831+$17,940+$21,000+$10,800 = $329,272 ✓

6) ACTIVITY VOLUME, LAST 30 DAYS (sum of *_30d across all 129 deal engagement rows)
Emails: 807
Calls: 112
Meetings: 128
Notes: 50
Total touches: 1,097
Breakdown by deal status: won deals 181 touches (33 calls / 8 deals = 4.1 calls per deal), lost deals 172 touches (25 calls / 27 = 0.9 per deal), open deals 744 touches (54 calls / 111 = 0.49 calls per deal).

COACHING OBSERVATIONS

1. Timing is the dominant leakage and it dwarfs the quota gap. "Lost- Timing (1 year or more)" is 13 of 27 losses (13/27 = 48.1%) worth $184,681 — 3.7x the $50,000 shortfall. If half of those deals had been disqualified at DS2 on implementation horizon, the quarter would already be cleared. Put an explicit timing/commitment gate in DS2 qualification before investing further activity.

2. The funnel is broad but slow to decide. 111 deals entered DS2 in 90 days, but only 35 have decided (31.5%) and just 8 won (22.9% of decided, 7.2% of cohort). With 76 deals still open and 67 deals sitting in DS3 ($552,705), the risk is a large middle of the funnel aging without stage movement. Prioritize moving or pruning the oldest DS2/DS3 deals (several entered in May–June and are still open) rather than adding to DS1 ($284,621, 20 deals) which is already plentiful.

3. Call activity on open pipeline is too low relative to what won deals show. Won deals averaged ~4.1 calls in 30 days; open deals average ~0.49 (54 calls across 111 deals), with email at 599 touches doing most of the work. A practical target: bring top-quartile open deals (e.g., the six open deals ≥$15,000: Deal-CFE7F4 $32,000, Deal-530B50 $31,200, Deal-70BB30 $30,000, Deal-D9A12F $17,000, Deal-84DBA6 $16,000, Deal-98FCB6 $18,036) to the ~4-calls-per-month cadence that correlated with wins.

Data gaps: no per-activity date stamps beyond the 30-day windows, no win/loss stage history, and DS2-to-won rate uses entered_ds2 as the cohort definition (the only DS2 marker in the data).

Method: "Active" = last engaged on/after 2026-07-08 (today 2026-09-06 minus 60 days = 2026-09-06 − 60d = 2026-07-08) AND is_former = false. 14 deals evaluated; 11 flagged.

DATA GAP (applies to every flagged deal): neither file contains deal amount or stage. I cannot report them, and I won't invent them. The "most valuable persona given stage" recommendation is therefore made with no stage info and defaults to standard threading logic (an absent economic buyer is the highest-priority gap at any pre-close stage; where a buyer is already active, the highest-priority gaps are HR admin for implementation ownership and IT security for security review).

FLAGGED DEALS (11)

1. Deal-EC3025 (C-FDD0C7) — single-threaded, <3, all one persona
   Active contacts: 1 — champion (CT-047C54, 2026-09-02). Economic buyer CT-F2C1AE excluded (is_former=true).
   Personas present: champion. Missing: economic buyer, HR admin, IT security, finance.
   Add first: economic buyer.
   On file: CT-6827DB, Chief People Officer, economic buyer — fits.

2. Deal-92D97D (C-E23238) — single-threaded, <3, all one persona
   Active contacts: 1 — HR admin (CT-01F5B4, 2026-08-28). Champion CT-A902AE inactive (2026-06-01 < 2026-07-08).
   Personas present: HR admin. Missing: economic buyer, champion, IT security, finance.
   Add first: economic buyer (champion re-engagement also needed).
   On file: none on file.

3. Deal-50D386 (C-EB10E4) — under-threaded (<3 active)
   Active contacts: 2 — champion (CT-AA41B2, 2026-09-01), HR admin (CT-B9C35B, 2026-08-25).
   Personas present: champion, HR admin. Missing: economic buyer, IT security, finance.
   Add first: economic buyer.
   On file: CT-A1C4B3, Chief People Officer, economic buyer — fits.

4. Deal-D0D6B5 (C-32918E) — under-threaded (all contacts in one persona)
   Active contacts: 3 — champion CT-87CED4 (2026-09-02), champion CT-DE6D7C (2026-08-19), champion CT-FD70B2 (2026-08-07).
   Personas present: champion only. Missing: economic buyer, HR admin, IT security, finance.
   Add first: economic buyer.
   On file: CT-1FA4DB, Chief People Officer, economic buyer — fits.

5. Deal-5BFE3B (C-535D36) — under-threaded (<3 active, all one persona)
   Active contacts: 2 — champion CT-57123B (2026-08-31), champion CT-5CE757 (2026-08-12).
   Personas present: champion only. Missing: economic buyer, HR admin, IT security, finance.
   Add first: economic buyer.
   On file: none on file.

6. Deal-36C33F (C-077A0E) — single-threaded, <3, all one persona
   Active contacts: 1 — IT security (CT-4FE556, 2026-08-15). Champion CT-405B45 and economic buyer CT-86B22F both excluded (is_former=true).
   Personas present: IT security. Missing: economic buyer, champion, HR admin, finance.
   Add first: economic buyer.
   On file: CT-1DB73E, Chief People Officer, economic buyer — fits.

7. Deal-885F45 (C-5E8EFB) — under-threaded (<3 active)
   Active contacts: 2 — economic buyer (CT-51C81E, 2026-08-26), champion (CT-D9A0E8, 2026-08-11).
   Personas present: economic buyer, champion. Missing: HR admin, IT security, finance.
   Add first: HR admin (buyer already in place; HR admin anchors implementation); IT security is the on-file gap.
   On file: CT-B3F25D, IT Security Lead, IT security — fits the security gap (no HR admin on file).

8. Deal-FCBE5B (C-737030) — single-threaded, <3, all one persona
   Active contacts: 1 — champion (CT-4A5317, 2026-08-29).
   Personas present: champion. Missing: economic buyer, HR admin, IT security, finance.
   Add first: economic buyer.
   On file: none on file.

9. Deal-5408B0 (C-2AE3AA) — under-threaded (<3 active)
   Active contacts: 2 — champion (CT-D33AE4, 2026-09-01), HR admin (CT-8742FD, 2026-08-18).
   Personas present: champion, HR admin. Missing: economic buyer, IT security, finance.
   Add first: economic buyer.
   On file: CT-07FA76, Chief People Officer, economic buyer — fits.

10. Deal-C6D97A (C-5A8FC2) — under-threaded (all contacts in one persona)
    Active contacts: 3 — champion CT-223DDC (2026-08-31), champion CT-B03555 (2026-08-20), champion CT-4E8A2B (2026-08-05).
    Personas present: champion only. Missing: economic buyer, HR admin, IT security, finance.
    Add first: economic buyer.
    On file: none on file.

11. Deal-F9A08A (C-0D15DF) — single-threaded, <3, all one persona
    Active contacts: 1 — champion (CT-931B10, 2026-09-03). Economic buyer CT-913581 inactive (2026-06-20 < 2026-07-08).
    Personas present: champion. Missing: economic buyer, HR admin, IT security, finance.
    Add first: economic buyer (existing buyer CT-913581 has also gone stale — worth re-touching).
    On file: CT-697541, Chief People Officer, economic buyer — fits.

NOT FLAGGED (3): Deal-84DBA6 (3 active, 3 distinct personas), Deal-4B0BEB (4 active, 4 distinct personas), Deal-D348E1 (5 active, all 5 personas).

Here's the analysis across the 10 calls (TT-001 → TT-010), all with rep Alex Franklin, 2026-07-28 to 2026-09-03.

OPENING (first 5 minutes)
8 of 10 calls open with the same 400-person retailer case study (18% regretted-turnover cut after automating milestone awards). The other two: one leads with a security-then-pricing agenda, one leads with pricing because the prospect asked for it last time. One call also stacks a Workhuman differentiation line at minute 2.
- Case-study open: TT-001, TT-002, TT-003, TT-005, TT-006, TT-007, TT-008, TT-010 — "a 400-person retailer we work with cut regretted turnover 18% in two quarters after automating milestone awards"
- Agenda open: TT-004 — "I put together a short agenda — security review first, then pricing."
- Pricing-first open: TT-009 — "You asked for straight pricing last time, so let's start there."

THE THREE MOST COMMON OBJECTIONS (by frequency, excluding competitor questions which are tracked below)

1. Budget locked (4× — TT-001, TT-003, TT-006, TT-010). Rep reframes the funding source to turnover savings and points to the retailer's backfill savings as the finance sign-off story.
   "Most teams fund this out of turnover savings — that retailer saved about $210k in avoided backfills, which is how their finance team signed off."

2. "Revisit next quarter" / timing (3× — TT-002, TT-005, TT-008). Rep counters with a scoped 90-day, single-department pilot to build internal data before planning.
   "What if we scope a 90-day pilot with one department so you have internal data before next quarter's planning?"

3. Status quo / why change (3× — TT-004, TT-007, TT-009). Rep concedes spreadsheets work until scale, then pivots to automation plus analytics.
   "Spreadsheets work until they scale — the difference is automation: milestones fire without HR lifting a finger, and you get analytics on who is being recognized."

(For completeness, the next two tiers — committee gate, 2× [TT-004, TT-010], and no urgency, 1× [TT-007] — fall outside the top three.)

CONCRETE NEXT STEP — AGREEMENT RATE
The rep asks the same close on 8 of 10 calls ("Should we lock the next step — a working session with your team this week?"). A concrete next step was agreed on 7 of 10 calls = 70%.
- Agreement (7): TT-001, TT-002, TT-003, TT-005, TT-006, TT-008, TT-009 — "Yes, Thursday at 2pm works — send the invite and I'll bring our HRIS manager."
- No agreement (3):
  - TT-004 — "Understood — I'll leave it with you."
  - TT-007 — "Fair enough."
  - TT-010 — "Understood, thanks for the candor."

Note: TT-007 and TT-010 didn't even reach the next-step question; TT-004 asked but the prospect deferred to the budget committee. The agreement pattern is uniform (same Thursday 2pm + HRIS manager), which looks scripted rather than co-created.

EVERY COMPETITOR A PROSPECT RAISED
- Awardco (TT-003, minute 4): "We're also in late talks with Awardco — their rewards catalog looks bigger than yours."
- Kudos (TT-007, minute 4): "How are you different from Kudos? Our CEO used them at her last company."

(Workhuman is NOT counted as a prospect-raised competitor — it appears only in the rep's own minute-2 line in TT-005, not voiced by a prospect.)

COACHING NOTES
1. The close is a rubber stamp. The same line, the same ask, and the same prospect response (Thursday 2pm + HRIS manager) across 7 calls reads as a scripted handshake, not a negotiated commitment. On the 3 it didn't land (TT-004, TT-007, TT-010) the rep simply accepted the stall ("Fair enough," "I'll leave it with you"). A stronger move: co-build the next step with the prospect and tie it to a date only they control (their budget committee date, open-enrollment start in October), so "no urgency" and "wait for the committee" have an anchor instead of a brush-off.
2. Openings are 80% a single canned case study with no discovery in the first five minutes — the first prospect question doesn't come until minute 4–6. On TT-009 the rep already knew the prospect wanted pricing, which proves there's context to work with. Before the 400-person retailer story, spend 60–90 seconds pulling one prospect-specific pain point (e.g., the HRIS analytics question that recurred in TT-003) so the case study lands against their number, not a generic one.

Q3 2026 forecast (quarter 2026-07-01 → 2026-09-30, extract pulled 2026-09-05)

Scope: 86 deals in the extract. 54 close inside the quarter; 32 close outside it (all in October — none before 2026-07-01).

1. COMMIT (100% weight) — 7 deals, total $44,729
   - Deal-547B2B (DS5, 09-11) $11,200
   - Deal-B7EBD1 (DS5, 09-10) $9,000
   - Deal-403845 (DS5, 09-11) $9,000
   - Deal-A2B47C (DS5, 09-11) $6,360
   - Deal-2465CE (DS5, 09-10) $5,400
   - Deal-A5E80A (DS1, 09-11) $2,520
   - Deal-499BF6 (DS2, 09-30) $1,249
   Arithmetic: 11,200 + 9,000 + 9,000 + 6,360 + 5,400 + 2,520 + 1,249 = 44,729

2. BEST_CASE (35% weight) — 24 deals, total $203,565
   38,935 + 24,000 + 19,656 + 16,250 + 11,116 + 10,800 + 10,500 + 9,890 + 9,720 + 9,000 + 7,200 + 3,840 + 3,780 + 3,600 + 3,240 + 3,150 + 3,120 + 3,060 + 2,916 + 2,760 + 2,484 + 2,100 + 1,920 + 528 = 203,565

3. PIPELINE (0% weight) — 23 deals, total $201,637.40 (counts zero; includes Deal-42326B at $2,480.40)

Weighted forecast:
   44,729.00 + 0.35 × 203,565.00
   = 44,729.00 + 71,247.75
   = $115,976.75

Excluded for close date outside the quarter: 32 deals, total $227,575 (all close 2026-10-01 through 2026-10-15). Largest: Deal-E51FB7 $43,875 (10-01), Deal-B936FE $18,000 (10-09), Deal-D9A12F $17,000 (10-15), Deal-D348E1 $13,770 COMMIT (10-15).

Top 5 BEST_CASE deals in the quarter:
   1. Deal-2D7423 — $38,935 (DS3, closes 09-30)
   2. Deal-25F752 — $24,000 (DS4, closes 09-25)
   3. Deal-E53952 — $19,656 (DS4, closes 09-30)
   4. Deal-5EED42 — $16,250 (DS3, closes 09-30)
   5. Deal-FA32A0 — $11,116 (DS3, closes 09-25)

## Data quality
The owner field is blank on 85 of 86 deals (only Deal-C9C286 has "Bryce Harmon"), so an unattended run cannot attribute or route any of the forecast. The why_buys_chars field is 0 on most deals, including the largest ones (e.g., Deal-2D7423 at $38,935 and Commit deal-547B2B at $11,200), meaning no recorded rationale backs the category assignments. Two "COMMIT" deals sit in early stages — Deal-A5E80A at DS1 and Deal-499BF6 at DS2 — which is inconsistent with a committed forecast and directly inflates the 100%-weighted bucket. Finally, the extract shows classic quarter-end slush: 16 in-quarter deals close exactly on 2026-09-30, 13 deals carry close dates already in the past relative to the 2026-09-05 pull yet remain open, and one amount (Deal-42326B, $2,480.40) is fractional, suggesting a currency/precision artifact.

2x2 cohort (denominator = all 220 companies in the extract; retained = current_status 'active'):

  Cell (m1_users >= 5? | m1_redemptions >= 1?)  n    active   retention
  1. Both signals (5+ givers AND 1+ redemptions)  47   31      66.0%  (31/47 = 0.6596)
  2. Givers only (5+ givers, 0 redemptions)       49   23      46.9%  (23/49 = 0.4694)
  3. Redemption only (<5 givers, 1+ redemptions)  29    9      31.0%  (9/29 = 0.3103)
  4. Neither signal                                95   38      40.0%  (38/95 = 0.4000)

Check: 47+49+29+95 = 220, matching the full extract, so the partition is complete.

Excluded from the denominator: none. Every one of the 220 companies has populated m1_users and m1_redemptions values (0 is a valid value, not missing), so all 220 fall into exactly one cell. No rows dropped.

Single signal with the largest retention lift (marginal, ignoring the other signal):
  5+ givers: 54/96 active = 56.25%  vs  <5 givers: 47/124 = 37.90%  → +18.35 pp
  1+ redemption: 40/76 active = 52.63%  vs  0 redemptions: 61/144 = 42.36%  → +10.27 pp
  → 5+ givers is the stronger single signal (+18.35 pp vs +10.27 pp).

Hypothesis verdict — supported, with a notable wrinkle: the both-signals cell (66.0%) is the highest of the four, and it beats givers-only (46.9%) and neither (40.0%) by 19.0 pp and 26.0 pp respectively. However, the pattern is NOT monotonic: the redemption-only cell (31.0%) retains WORSE than neither (40.0%). So "both signals > one signal or neither" only holds for the givers dimension; a redemption with few givers underperforms the no-activity baseline. This is consistent with small-giver-base companies redeeming early (often self-seeded or trial-driven) and then churning.

What this does prove (within this extract, 2023-01 to 2023-07 signups, 220 companies):
- A descriptive association: first-month breadth (5+ givers) and the combination of breadth plus a successful redemption are associated with higher 24-month survival in this cohort.
- It is safe to use "5+ m1_users" as a single early retention indicator for this population; it outperforms "1+ m1_redemption" as a standalone marker.

What this does NOT prove:
- Causation. Activation signals and retention share confounders (company size, sales-led vs self-serve onboarding, sales effort, initial ARR); a company that signs up with 8 users likely had a bigger launch team to begin with.
- That the combination has a synergistic effect beyond the givers signal — the redemption-only cell is below baseline, and no controlled comparison isolates the interaction.
- Generalization beyond this extract: single product (Bonusly), single signup window (7 months of 2023), US-heavy sample, and survival to 25+ months is already guaranteed by construction (survivorship in the extract itself could bias the cohort).
- That the thresholds (5, 1) are optimal — this is a binary cut of a continuous variable; lift could shift with other cutoffs.
- Anything about mechanism (WHY givers retain) — it's an association, not an experiment.

If you want, I can add a crude significance check (chi-square) on the 2x2 or test alternative givers thresholds to see how stable the 5-user cut is.

ARR RECONCILIATION — as of 2026-09-05

1. TOTALS
Billing ARR (37 subscriptions, MRR x 12, incl. 2 cancelled):
  51,491.48 MRR x 12 = 617,897.76
  (MRR sum: 1436.77+591.00+1312.34+2370.77+1932.00+2233.00+521.00+1515.00+601.00+856.77+251.34+1988.00+851.00+408.77+687.77+1804.34+1003.00+600.77+272.77+1127.99+1920.34+1777.00+1602.00+2463.00+649.00+777.77+748.99+2150.99+1906.34+204.77+1809.77+1099.00+779.00+1692.00+2202.00+2149.00+1753.00+1440.77+2001.34 = 51,491.48)
  Active-only billing ARR (35 active subs): 41,866.28 MRR x 12 = 604,739.28
CRM ARR (39 company records, hubspot_arr): 603,581.76

2. VARIANCE (CRM minus billing, all subs)
  603,581.76 - 617,897.76 = -14,316.00  (CRM is $14,316.00 lower)

3. DECOMPOSITION (sums exactly to -14,316.00)
  a) Missing records: net -11,952.00
     - In CRM, no billing subscription: C-0D5BBE3A = +16,497.24
     - In billing, no CRM company record: C-21629AA4 (SUB-0004) = -28,449.24
  b) Rounding: +36.00
     - C-0D66DF9E: 23,200.00 - (1,932.00 x 12 = 23,184.00) = +16.00
     - C-14D70CE0: 18,200.00 - (1,515.00 x 12 = 18,180.00) = +20.00
     (Both CRM values imply fractional monthly figures — 23,200/12 = 1,933.33, 18,200/12 = 1,516.67 — i.e., CRM ARR was derived from a rounded monthly, not the actual MRR. Classic rounding artifact.)
  c) Status mismatch: 0.00
     - The two cancelled subscriptions reconcile EXACTLY to CRM, so no variance is attributable to status:
       C-0C8323BF: 408.77 x 12 = 4,905.24 = CRM 4,905.24
       C-0DC4FB8C: 687.77 x 12 = 8,253.24 = CRM 8,253.24
     - Caveat: CRM still carries ARR for both cancelled accounts. Zero variance today, but a policy mismatch — flag to RevOps.
  d) Other (true value mismatch): -2,400.00
     - C-0F7269D7: 24,396.00 - (2,233.00 x 12 = 26,796.00) = -2,400.00
       CRM implies MRR of 24,396/12 = 2,033.00 vs billing MRR 2,233.00 — a 200.00/mo gap, not rounding.
  Check: -11,952.00 + 36.00 + 0.00 + (-2,400.00) = -14,316.00 ✓
  (All other 35 overlapping aliases match exactly: CRM - billing = 0.00.)

4. MISMATCHED ACCOUNTS AND SUGGESTED OWNER (by function — no individual names exist in the provided data, so owners are suggested by responsibility; I will not invent people)
  - C-21629AA4 (SUB-0004): live active billing (MRR 2,370.77, ARR 28,449.24) with NO CRM company record. Suggested owner: CRM/RevOps data admin — create the HubSpot company and map the alias.
  - C-0D5BBE3A: CRM carries 16,497.24 with NO billing subscription in the file. Suggested owner: Billing Ops (ChargeBee admin) — confirm whether a sub exists (possibly unmapped alias or deleted sub); if none, RevOps to zero the CRM field.
  - C-0F7269D7 (SUB-0006): 2,400.00 ARR gap (billing 2,233.00 vs CRM-implied 2,033.00 MRR). Suggested owner: Customer Success/RevOps — verify latest contracted MRR (likely an upsell not pushed to CRM), then correct the hubspot_arr field to 26,796.00 if billing is authoritative.
  - C-0D66DF9E (SUB-0005): +16.00 rounding artifact. Suggested owner: RevOps data engineering — recompute hubspot_arr as actual MRR x 12 instead of a rounded monthly.
  - C-14D70CE0 (SUB-0008): +20.00 rounding artifact. Same owner as above.
  - C-0C8323BF (SUB-000E) and C-0DC4FB8C (SUB-000F): billing status = cancelled, CRM still carries full ARR (4,905.24 and 8,253.24). Suggested owner: RevOps — decide whether cancelled accounts should be zeroed or reclassified; amounts match, so no numeric fix required today.

5. BUSINESS RULE VIOLATIONS — non-12-month terms missing cf_agreement_end_date
  - SUB-0002, C-1794A52C: term 24 months, active, cf_agreement_end_date EMPTY — VIOLATION
  - SUB-0019, C-22170CA1: term 36 months, active, cf_agreement_end_date EMPTY — VIOLATION
  (Non-12-month subs WITH dates, compliant: SUB-000C C-0DB48281 24mo 2027-11-30; SUB-001A C-0FC4DBB8 36mo 2027-11-30.)

Note on scope: billing total above includes the 2 cancelled subs, since the file provides no rule for exclusion; if cancelled subs are excluded from "billing ARR," the total is 604,739.28 and variance is +1,157.52 (same decomposition, with the two cancelled accounts' ARR moved from "status" into scope). State which convention your leadership uses before quoting the number externally.

2026-08 vs 2026-07, four KVMs (unweighted mean across all 30 company-rows; no weighting field exists in the data, so simple means are used).

```
KVM                2026-07   2026-08   Abs chg   Rel chg   Dir
Giving rate          0.6023    0.6027   +0.0004   +0.07%    UP
Redemptions/user     1.7300    1.7302   +0.0002   +0.01%    UP
1:1 meetings         0.4469    0.4472   +0.0003   +0.07%    UP
Pulse check          0.6006    0.5086   -0.0920  -15.31%    DOWN
```

Giving rate: 0.6023 → 0.6027 = +0.0004, +0.07%, up.
Redemptions/user: 1.7300 → 1.7302 = +0.0002, +0.01%, up.
1:1 meetings: 0.4469 → 0.4472 = +0.0003, +0.07%, up.
Pulse check: 0.6006 → 0.5086 = -0.0920, -15.31%, down.

Largest relative move: pulse check engagement (-15.31%). The driver is size_band = enterprise: 0.5500 → 0.2743, -0.2757, -50.1%. All ten enterprise aliases dropped nearly uniformly (~0.27 each, e.g. C-0B2895EF 0.5619→0.2864, C-0D0B047C 0.5398→0.2619), while smb (0.6588→0.6573, -0.2%) and mid_market (0.5930→0.5942, +0.2%) were flat. plan_tier is uniformly tier_three across every row, so it carries no variance and cannot be the driver.

Caveat: a uniform ~50% drop across all enterprise rows is unusual and may be a data/definition artifact, not genuine behavioral decline — the raw file does not distinguish the cause.

REDEMPTIONS — WEEKLY REWARDS REPORT
Last completed month: August 2026 (2026-08)
Scope: all redemptions in redemptions_ytd.csv — first redemption 2026-01-01, last 2026-08-31. Every row falls in Jan–Aug 2026, so YTD through the last completed month equals the full file (378 rows; no rows outside that range).

Core metrics (arithmetic shown)
- Redemption count: 378
- Total spend: $27,846.00
  - custom $10,873.00 + Tremendous $8,505.00 + Snappy $5,238.00 + TangoCard $3,230.00 = $27,846.00
- Unique redeemers: 235 (distinct user_key values)
- Redemptions per redeemer: 378 / 235 = 1.61

Provider mix (% of spend)
  custom:      $10,873.00 / $27,846.00 = 39.05%
  Tremendous:   $8,505.00 / $27,846.00 = 30.54%
  Snappy:       $5,238.00 / $27,846.00 = 18.81%
  TangoCard:    $3,230.00 / $27,846.00 = 11.60%
  Sum of shares: 100.00% (exact: 39.0469 + 30.5430 + 18.8106 + 11.5995)
  (By redemption count instead: Tremendous 192, TangoCard 90, Snappy 59, custom 37.)

Top 5 countries by redemptions
  1. US: 244 (64.6%)
  2. CA: 24  (6.3%)
  3. AU: 21  (5.6%)
  4. GB: 17  (4.5%)  — tied with NL; GB listed 4th by spend among ties
  5. NL: 17  (4.5%)
  (Next: SG 12; DE/FR/CH 9 each.)

Data notes
- No missing values: all 378 rows have a provider, amount, and country; amounts in whole or 2-decimal USD; all redeem_at timestamps present.
- Company aliases are included in the file but are not part of this section's requested metrics; nothing is inferred from them.
- "Last completed month" = 2026-08: the dataset contains redemptions through 2026-08-31 and none beyond, so August is the most recent fully covered month.

Method: All three rules must hold (R1: health_score < 60; R2: churn_save_eligible_amount > 0; R3: renewal_date within 120 days of snapshot 2026-09-05, i.e. between 2026-09-05 and 2027-01-03 inclusive). Note: the two provided files contain the eligibility rules only — they do NOT define criteria for the three plays, so the play assignments below are my mapping of documented data signals to each play, with the justifying signal cited per account.

ELIGIBLE — 8 accounts (all pass R1, R2, R3)

Amount at stake per account (churn_save_eligible_amount):
1. C-0F6C0F34 — $49,707.00 (renewal 2026-10-03, 28 days out; health 51)
2. C-0B827671 — $25,365.00 (renewal 2026-11-14; health 56)
3. C-0B360C78 — $35,748.00 (renewal 2026-10-28; health 57)
4. C-0B0F1BAB — $5,494.00 (renewal 2026-09-23; health 38)
5. C-0CA21961 — $16,829.00 (renewal 2026-12-28; health 58)
6. C-0E9C27D1 — $41,235.00 (renewal 2026-09-24, 19 days out; health 39)
7. C-0CEF69FD — $32,621.00 (renewal 2026-11-21; health 53)
8. C-0D3278C7 — $17,602.00 (renewal 2026-11-12; health 54)

Total at stake: 49,707 + 25,365 + 35,748 + 5,494 + 16,829 + 41,235 + 32,621 + 17,602 = $224,601.00 (49.4% of the $454,380.00 combined ARR of these 8 accounts).

Play assignment (my mapping, since no play rules were provided):

USAGE REVIVAL — low seat utilization is the churn driver; fix adoption before spending discount capital:
- C-0CA21961 — usage_trend_3m = flat, 84/325 seats = 25.8% utilization, health 58 (borderline). Signal: 74% of paid seats unused with flat usage.
- C-0D3278C7 — usage_trend_3m = declining, 126/380 seats = 33.2% utilization, health 54. Signal: declining trend on a large seat base with two-thirds idle.

EXECUTIVE TOUCH — champion is absent and the account is large; rebuild sponsorship from the top:
- C-0F6C0F34 — champion_active = false, ARR $86,741 (largest ARR in set), health 51, usage actually growing. Signal: no active champion on the biggest at-risk account.
- C-0CEF69FD — champion_active = false, ARR $79,324, health 53. Signal: no active champion on the second-largest at-risk ARR.
- C-0B0F1BAB — champion_active = false, health 38 (lowest), renewal in 18 days. Signal: inactive champion plus the weakest health score and nearest renewal; needs executive-level re-engagement now.

COMMERCIAL CONCESSION — usage is healthy, so a pricing/term concession is the lever that closes the renewal:
- C-0E9C27D1 — usage_trend_3m = flat with 134/157 = 85.4% utilization, health 39, renewal 2026-09-24. Signal: high utilization rules out a usage play; product is being used but health is critical and renewal is imminent.
- C-0B827671 — usage_trend_3m = declining but champion_active = true, 113/202 = 55.9% utilization, health 56. Signal: an active champion and mid-level utilization argue for a concession backed by the champion rather than an adoption push.
- C-0B360C78 — usage_trend_3m = growing, 246/327 = 75.2% utilization, health 57 (borderline pass), renewal 2026-10-28. Signal: healthy, growing usage — the account is at risk on price/value perception, not adoption; smallest concession among the three.

Note on fit confidence: no documented rule maps signals to plays, so treat the three-way split as a recommended assignment, not a documented one. Two accounts are borderline on R1 (health 57–58: C-0B360C78, C-0CA21961) — they qualify strictly per the rules but merit closer review.

AT RISK BUT NOT ELIGIBLE — 7 accounts

- C-0BC71BDD — health 55, renewal 2026-10-27 (in window), but churn_save_eligible_amount = 0.00 → fails R2. Looks at risk (55, 59/197 seats = 29.9% utilization, no champion) but no dollar amount is flagged as eligible.
- C-0BE96399 — health 54, renewal 2026-10-29 (in window), but churn_save_eligible_amount = 0.00 → fails R2. (27.9% utilization, declining usage.)
- C-10A56B0F — health 54, renewal 2026-12-12 (in window), but churn_save_eligible_amount = 0.00 → fails R2. (48.3% utilization, declining usage.)
- C-0BA71F12 — health 52, churn amount $6,824.00 > 0, but renewal 2027-04-11 is 218 days out → fails R3. (23.5% utilization, declining usage.)
- C-0F876796 — health 47, churn amount $19,958.00 > 0, but renewal 2027-02-06 is 154 days out → fails R3. (23.2% utilization, declining usage — the highest-stakes account that misses on timing only.)
- C-0F6694C3 — health 43 (severe), renewal 2027-03-21 (197 days out), churn amount 0.00 → fails R2 and R3.
- C-0FCCD2DF — health 43, renewal 2027-04-23 (230 days out), churn amount 0.00 → fails R2 and R3. (42.9% utilization, flat usage.)

Remaining 15 accounts have health >= 60 (R1 not met) and zero eligible amount; none are in the at-risk set.

Data gaps stated explicitly: neither file defines the churn-save play criteria, the basis for churn_save_eligible_amount, or how health_score is computed; the snapshot date 2026-09-05 comes from rule R3's description, not from a file header. I could not verify the business logic behind the $0 eligible amounts — only that they fail R2 as documented.

**EXPANSION KIT — C-0DDFC9A7** (all figures from the three provided files only)

**1. Seat coverage (licensed over headcount)**
- Licensed seats: 150, headcount: 400
- 150 ÷ 400 = 0.375 → **37.5% coverage** (250 people are unlicensed)

**2. Usage health (two lines)**
- Active users have climbed every single month: 88 (Mar) → 95 (Apr) → 102 (May) → 110 (Jun) → 118 (Jul) → 126 (Aug) = **+38 users, +43.2%** across the period (126 ÷ 88 − 1 = 0.4318).
- 126 users ÷ 150 licensed seats = **84% utilization** — engagement is strong and the account is getting close to its seat ceiling, so an expansion conversation is timely.

**3. Headroom in seats and ARR (current per-seat rate)**
- Current per-seat rate: $9,000.00 ÷ 150 seats = **$60.00 per seat (annual)**
- Seat headroom (to full 400-person coverage): 400 − 150 = **250 seats**
- ARR headroom: 250 × $60.00 = **$15,000.00** → total would move $9,000 → $24,000
- (Assumption stated explicitly: headroom is measured to full headcount coverage. On a more conservative "just clear current usage" basis, 126 users already consume 126 of 150 seats, leaving only 24 unused seats — i.e., they are effectively at capacity on the people who actually use it.)

**4. Who replied, and can they buy?**
- **Maria S.**, People Operations Coordinator, replied (2026-09-02).
- She **cannot buy** — she explicitly says budget and seat expansion sit with Dana R. She can, however, act as a champion/introducer and has offered to make the introduction.

**5. Right buyer from our contacts**
- **Dana R., VP People** — the stated owner of budget and seat expansion. Note her last engagement was **2026-05-18** (~3.5 months stale), and Maria says Dana has "been asking about our usage numbers lately" — a warm, timely opening.

**6. Reply email (to Maria; from our side), 137 words**

Subject: RE: Growing your team's recognition program

Hi Maria,

Thanks for the warm note — it's great to hear the team loves the product and the feed is busy every week.

I'd really welcome the introduction to Dana. It's the perfect timing, since usage has been climbing steadily — active users are up from 88 in March to 126 in August (+43%), which puts recognition at about 84% of the 150 licensed seats. I can put a short, specific one-pager together for her with those numbers and what an expansion would look like.

No need for anything grand — if you're open to it, a quick intro email or a 15-minute call slot with her would be ideal. Happy to work around her schedule, and I'm glad to send the summary to you first if you'd like to review it.

Thanks again for championing this — I appreciate it.

Best,
Cole

---
Note: per your data, the email is signed as coming from the original sender (Cole). I cited one real usage fact (88→126, +43%, 84% of seats) and steered toward Dana without pushing for a buy. No facts were invented.

CSM PREP — C-0D284E42 — Mid-Onboarding Call
================================================================

COMPLETE (each backed by a data field)
--------------------------------------
1. Slack integration connected    — integration_slack = 2026-08-12 (day after signup)
2. Allowance set                  — allowance_set = 2026-08-13
3. Admins added                   — admins_added = 2
4. First recognition given        — first_recognition_at = 2026-08-15 14:22

NOT COMPLETE (blank in data — do not assume done)
--------------------------------------------------
1. HRIS integration               — integration_hris is empty
2. First redemption               — first_redemption_at is empty

EARLY ENGAGEMENT SIGNALS (from onboarding_usage.csv)
-----------------------------------------------------
Window: 2026-08-11 through 2026-09-04 (25 days)

  Active givers: 3 → 15  (5× growth)

  Weekly step-up pattern:
    Aug 11–17  avg 4.3    (3,3,4,4,5,4,7)
    Aug 18–24  avg 7.6    (5,7,6,9,8,9,9)
    Aug 25–31  avg 11.0   (11,10,10,11,13,11)
    Sep 1–4    avg 14.0   (13,13,15,15)

  Last 7 days (Aug 29–Sep 4): avg 13.0
  First 7 days (Aug 11–17):  avg 4.3
  → Recent run-rate is ~3× the opening week.

  Plateau watch: last 4 days sit at 13–15. Growth is still positive
  (13 → 15) but the daily step has slowed. The HRIS gap may be the
  ceiling — no new hires flowing in means the gifter pool is static.

THREE THINGS TO COVER ON THE CALL
---------------------------------
1. Connect HRIS (the only open integration).
   Why now: gifter pool has flattened at 15 with no new-hire pipeline.
   HRIS is the mechanical fix for the ceiling. Ask: who owns the
   HRIS admin credential, what's the blocker (security review, IT
   queue)? Get a date on the call.

2. First redemption is still zero.
   15 people are giving; nobody has redeemed. That breaks the
   recognition loop — givers stop when they can't see the reward
   land. Ask the 2 admins: have they personally tried a redemption?
   Is the rewards catalog populated and visible to recipients? Is
   there an approval step that's stuck? Diagnose the specific
   friction before the call ends.

3. Activate the second admin.
   Two admins were added on day 2, but usage shows one clear
   driver pattern (the step-ups align with a single pulse of
   activity). Ask: is Admin #2 actually engaged, do they have
   a specific cohort (team, location) they own, and can they run
   a "recognition week" in their group next week to push past
   the 15 plateau? Assign them a concrete, visible task.

================================================================
NOTE: No data field shows total headcount, rewards-catalog status,
or which admin performed which action. Do not infer those on the
call — ask.

90-day renewal risk brief (window: 2026-09-05 → 2026-12-04)

SYSTEM-OF-RECORD DECISION
- 5 accounts are multi-year (ChargeBee is_multi_year=true): C-0B7D2C30, C-0BCDB8C2, C-0D2AB865, C-0BBE3E60, C-0F5D2323. Per the known ChurnZero defect, I use ChargeBee dates for all five.
- 15 accounts are 12-month terms where both systems agree exactly. I use the shared date (no basis to prefer either system).
- Every multi-year account is also a date disagreement (flagged in each row below).

RENEWALS (by date used)

1. C-0B7D2C30 — Dana Mercer — $65,901 ARR — Date used: 2026-09-15 (ChargeBee; CZ said 2026-09-10 — DISAGREEMENT, multi-year → trust CB) — Seat utilization: 274/476 = 57.6% — 3-mo usage: 97 → 94 → 84 (2026-06/07/08), -13.4%. Risk: HIGH — utilization below 60% with active users falling every month for 12 straight months (155 → 84 since 2025-09).

2. C-0BCDB8C2 — Cole Ingram — $54,427 ARR — Date used: 2026-09-18 (ChargeBee; CZ said 2027-09-18 — DISAGREEMENT, CZ off by a full year, multi-year → trust CB) — Seat utilization: 232/424 = 54.7% — 3-mo usage: 127 → 118 → 110, -13.4%. Risk: HIGH — sub-55% seat utilization and steady monthly decline (200 → 110 since 2025-09).

3. C-0D2AB865 — Elena Sinclair — $38,022 ARR — Date used: 2026-09-22 (ChargeBee; CZ said 2026-09-10 — DISAGREEMENT, multi-year → trust CB) — Seat utilization: 250/407 = 61.4% — 3-mo usage: 125 → 117 → 109, -12.8%. Risk: HIGH — utilization just above 60% and a consistent 12-month usage slide (199 → 109).

4. C-0BBE3E60 — Dana Mercer — $30,993 ARR — Date used: 2026-09-26 (ChargeBee; CZ said 2027-09-26 — DISAGREEMENT, CZ off by a full year, multi-year → trust CB) — Seat utilization: 74/114 = 64.9% — 3-mo usage: 39 → 35 → 33, -15.4%. Risk: HIGH — worst 3-month decline in the book on top of 65% utilization and 12 straight months of decay (63 → 33).

5. C-0F5D2323 — Cole Ingram — $90,647 ARR — Date used: 2026-09-29 (ChargeBee; CZ said 2026-09-10 — DISAGREEMENT, multi-year → trust CB) — Seat utilization: 111/390 = 28.5% — 3-mo usage: 20 → 21 → 18, flat. Risk: HIGH — largest ARR in the window with only 28.5% of seats used and ~18 active users for 12 months: severe underutilization, not just decline.

6. C-0EC6999D — Elena Sinclair — $79,419 ARR — Date used: 2026-10-03 (CZ and CB agree) — Seat utilization: 31/112 = 27.7% — 3-mo usage: 17 → 16 → 15, flat-low. Risk: HIGH — $79K ARR with under 28% seat utilization and ~15 active users all year; value is not being realized.

7. C-0B20DB64 — Dana Mercer — $21,770 ARR — Date used: 2026-10-07 (CZ and CB agree) — Seat utilization: 214/378 = 56.6% — 3-mo usage: 294 → 298 → 294, flat. Risk: MEDIUM — stable usage is reassuring, but 43% of seats are unused, an expansion/downsell decision point.

8. C-0BBC4E7A — Cole Ingram — $56,374 ARR — Date used: 2026-10-10 (CZ and CB agree) — Seat utilization: 228/337 = 67.7% — 3-mo usage: 142 → 141 → 139, flat (-2.1%). Risk: LOW — healthy utilization and essentially flat usage over 12 months (142 → 139).

9. C-0FD551AB — Elena Sinclair — $48,815 ARR — Date used: 2026-10-14 (CZ and CB agree) — Seat utilization: 210/376 = 55.9% — 3-mo usage: 123 → 122 → 126, stable (+2.4%). Risk: LOW — flat-to-slightly-growing usage; moderate utilization, no decline signal.

10. C-0F9F8F13 — Dana Mercer — $46,230 ARR — Date used: 2026-10-18 (CZ and CB agree) — Seat utilization: 199/352 = 56.5% — 3-mo usage: 185 → 185 → 182, flat. Risk: LOW — stable usage year-round and no decay trend.

11. C-0BC34584 — Cole Ingram — $16,740 ARR — Date used: 2026-10-22 (CZ and CB agree) — Seat utilization: 327/494 = 66.2% — 3-mo usage: 104 → 104 → 106, stable (+1.9%). Risk: LOW — good utilization and flat usage; smallest ARR in the window.

12. C-0B7A7546 — Elena Sinclair — $35,062 ARR — Date used: 2026-10-25 (CZ and CB agree) — Seat utilization: 182/205 = 88.8% — 3-mo usage: 64 → 65 → 63, stable. Risk: LOW — highest utilization in the book and flat usage; strong retention profile.

13. C-0B369871 — Dana Mercer — $85,128 ARR — Date used: 2026-10-29 (CZ and CB agree) — Seat utilization: 317/422 = 75.1% — 3-mo usage: 326 → 330 → 333, rising (+2.1%). Risk: LOW — usage has grown every month since 2025-09 (289 → 333) and it's the second-largest ARR in the window: healthy.

14. C-0B144C78 — Cole Ingram — $30,899 ARR — Date used: 2026-11-02 (CZ and CB agree) — Seat utilization: 169/224 = 75.4% — 3-mo usage: 101 → 101 → 106, rising (+5.0%). Risk: LOW — growing usage with three-quarter seat utilization.

15. C-0FC4DBB8 — Elena Sinclair — $94,732 ARR — Date used: 2026-11-05 (CZ and CB agree) — Seat utilization: 356/464 = 76.7% — 3-mo usage: 189 → 191 → 193, rising (+1.6%). Risk: LOW — largest ARR in the window with rising usage and strong utilization: anchor account.

16. C-0D5BBE3A — Dana Mercer — $39,740 ARR — Date used: 2026-11-09 (CZ and CB agree) — Seat utilization: 85/102 = 83.3% — 3-mo usage: 88 → 90 → 91, rising (+3.4%). Risk: LOW — high utilization with gently rising usage year-over-month.

17. C-0FB9D5AF — Cole Ingram — $63,158 ARR — Date used: 2026-11-13 (CZ and CB agree) — Seat utilization: 144/199 = 72.4% — 3-mo usage: 173 → 173 → 176, stable/rising (+1.7%). Risk: LOW — healthy utilization and flat-to-up usage (154 → 176 since 2025-09).

18. C-0B344485 — Elena Sinclair — $64,384 ARR — Date used: 2026-11-16 (CZ and CB agree) — Seat utilization: 224/287 = 78.1% — 3-mo usage: 238 → 240 → 244, rising (+2.5%). Risk: LOW — growing usage at ~78% utilization.

19. C-0CB2C1B4 — Dana Mercer — $40,628 ARR — Date used: 2026-11-20 (CZ and CB agree) — Seat utilization: 386/473 = 81.6% — 3-mo usage: 47 → 48 → 49, stable (+2.1%). Risk: LOW — high seat utilization and flat-to-up usage.

20. C-22170CA1 — Cole Ingram — $45,646 ARR — Date used: 2026-11-24 (CZ and CB agree) — Seat utilization: 251/294 = 85.4% — 3-mo usage: 143 → 148 → 146, stable (+2.1% from 143 to 146). Risk: LOW — strong utilization and stable-to-rising usage.

DISAGREEMENTS FLAGGED (all 5 are multi-year accounts; ChargeBee used in each case because ChurnZero is known-wrong on multi-year terms)
- C-0B7D2C30: CZ 2026-09-10 vs CB 2026-09-15 (36-mo term)
- C-0BCDB8C2: CZ 2027-09-18 vs CB 2026-09-18 (36-mo term; CZ appears to have added a full year)
- C-0D2AB865: CZ 2026-09-10 vs CB 2026-09-22 (24-mo term)
- C-0BBE3E60: CZ 2027-09-26 vs CB 2026-09-26 (24-mo term; CZ appears to have added a full year)
- C-0F5D2323: CZ 2026-09-10 vs CB 2026-09-29 (24-mo term)
- Note: the three CZ dates of 2026-09-10 (C-0B7D2C30, C-0D2AB865, C-0F5D2323) look like a single bad default in ChurnZero — three distinct multi-year accounts sharing one date.

TOTALS
- Total ARR renewing in window (20 accounts, arithmetic shown):
  65,901 + 54,427 + 38,022 + 30,993 + 90,647 + 79,419 + 21,770 + 56,374 + 48,815 + 46,230 + 16,740 + 35,062 + 85,128 + 30,899 + 94,732 + 39,740 + 63,158 + 64,384 + 40,628 + 45,646 = $1,048,714
- ARR at risk (6 HIGH accounts: 65,901 + 54,427 + 38,022 + 30,993 + 90,647 + 79,419):
  65,901 + 54,427 = 120,328; + 38,022 = 158,350; + 30,993 = 189,343; + 90,647 = 279,990; + 79,419 = $359,409
- ARR at risk = $359,409, i.e. 359,409 / 1,048,714 = 34.3% of the window's renewing ARR. All six high-risk renewals fall in the first ~6.5 weeks of the window (Sep 15 – Oct 3), so they need CSM attention immediately, not in November.

Data gaps / caveats
- usage_12m.csv provides active_users, not seat-level usage; seat utilization is computed only from churnzero_renewals.csv (seats_used / seats). The two metrics are not directly comparable (e.g., C-0B20DB64 has 294 active users against 214 "seats used"), so I've reported them separately rather than reconciling them.
- Neither file contains company names — only account aliases, which are cited exactly as given.

## Method
I grouped all 80 tickets by the **body text** (not the tag column). The tags are unreliable — e.g. IC-460047 is tagged "how-to" but the body is a live Slack sync bug; IC-460069 is tagged "question" but describes a $50k+ seat-count overcharge; IC-460059 is "how-to" but is an HRIS provisioning failure. Grouping by body text yields 5 coherent themes covering all 80 tickets.

"ARR affected" = **distinct-account ARR** (each account counted once, not per ticket) — the standard ARR-at-risk view. No account appears in more than one theme, so theme ARR sums to the portfolio total.

Portfolio: 80 tickets, 24 distinct accounts, $284,800 distinct ARR.

---

## Themes, ranked by ARR exposure (not volume)

**1. HRIS provisioning / sync failures — $114,000 ARR**
- Count: 12 tickets | Share: 15.0% of volume | ARR share: 40.0%
- Distinct accounts: 3 — C-0B2213A9 ($36k), C-0DDFC9A7 ($48k), C-0F6C0F34 ($30k)
- Body text: "HRIS provisioning is not creating accounts for new hires," "HRIS sync skipped 12 new hires; provisioning log shows no errors," "New employees are not being provisioned from our HRIS sync"
- Sample tickets: IC-460059, IC-460062
- Rec: This is the top ARR exposure (40% of affected ARR) from only 3 enterprise accounts with no errors in their logs — stand up a dedicated onboarding-sync engineering owner and trace the silent-skip path before the next hire wave.

**2. Gift-card redemption failures — $68,800 ARR**
- Count: 18 tickets | Share: 22.5% of volume | ARR share: 24.2%
- Distinct accounts: 7 — C-14264ABD ($11k), C-0B827671 ($10.7k), C-0B0F1BAB ($10.3k), C-0FCCD2DF ($9.6k), C-0D9CA315 ($9.6k), C-0CEF69FD ($8.9k), C-0F876796 ($8.7k)
- Body text: checkout "spins forever and then the redemption fails," "Redemption failed twice today; gift card email never showed up," "Redemption failed at checkout and the gift card code never arrived," and "Gift card order errored out but the points were still deducted"
- Sample tickets: IC-460030, IC-460038
- Rec: Broad mid-market pattern (7 accounts) in the redemption pipeline; add a reconciliation that auto-credits points back when a card fails to deliver, since "points deducted but no card" is a direct customer-asset loss.

**3. Billing / invoice errors — $52,000 ARR — SINGLE-ACCOUNT CONCENTRATION**
- Count: 16 tickets | Share: 20.0% of volume | ARR share: 18.3%
- Distinct accounts: 1 — C-0E9C27D1 ($52k) — 100% of this theme
- Body text: "Third invoice in a row with the same seat-count error," "Invoice discrepancy - charged for 200 seats but we license 150," "Our invoice shows a seat count we never approved," "Billing charged the annual renewal at the wrong tier price"
- Sample tickets: IC-460071, IC-460078
- Rec: All 16 tickets are one account (C-0E9C27D1) with a recurring, uncorrected seat-count/tier misconfiguration — this is account-level billing-config noise, not a product bug; route to a billing-ops specialist and fix the 200-vs-150 seat record and renewal tier.

**4. Points / credits not posting — $31,100 ARR — LARGEST BY VOLUME**
- Count: 20 tickets | Share: 25.0% of volume (highest) | ARR share: 10.9% (low)
- Distinct accounts: 9 — C-0D0B047C ($4.5k), C-0BF20542 ($4.5k), C-0D6CC8E3 ($4.2k), C-0D3278C7 ($3.5k), C-0D284E42 ($3.4k), C-0B2895EF ($2.9k), C-21FEBCBB ($2.9k), C-0BE96399 ($2.7k), C-0DD0626C ($2.5k)
- Body text: "recognitions… show as delivered but the points never arrived," "Points not posting for our whole team after the weekend," "Missing points - my balance has not updated," "Points from last week's recognition are still not posting to my balance"
- Sample tickets: IC-460004, IC-460009
- Rec: The #1 theme by volume and account count, but every account is small ($2.5k–$4.5k ARR); investigate the weekend/batch posting job behind "delivered but points never arrived," but treat it as low ARR priority relative to themes 1–3.

**5. Slack integration regressions — $18,900 ARR**
- Count: 14 tickets | Share: 17.5% of volume | ARR share: 6.6%
- Distinct accounts: 4 — C-10A56B0F ($5.4k), C-8C2E8F00 ($5.2k), C-0B843542 ($4.4k), C-0BA71F12 ($3.9k)
- Body text: "Slack integration stopped syncing recognitions," "the sync toggle resets itself," "The Slack app disconnected and re-auth does not stick," "Slack slash command returns an error for everyone"
- Sample tickets: IC-460047, IC-460046
- Rec: Clustered Slack app auth/sync regression across 4 accounts (toggle reset + re-auth not sticking point to a token/permission config); audit the Slack integration's OAuth and sync-toggle persistence.

---

## Broad patterns vs. single-account noise
- **Broad patterns (multi-account):** HRIS (3 accts), Redemption (7 accts), Points (9 accts), Slack (4 accts) — genuine product issues to fix in the roadmap.
- **Single-account concentration:** Billing/invoice errors — 16 tickets, all C-0E9C27D1. High ARR ($52k) but it is one account's misconfigured seat record, so it belongs in CS/billing-ops escalation, not the product bug backlog.

## The key read (ARR ≠ volume)
The volume and ARR rankings disagree sharply. "Points not posting" is the #1 theme by tickets (25%) and accounts (9) but only #4 by ARR ($31.1k, 10.9%). Conversely, HRIS is only #3 by volume (15%) yet holds the largest ARR exposure ($114k, 40.0%) from just 3 accounts. Ranking by ARR exposure, the work order is **HRIS → Redemption → Billing (C-0E9C27D1 escalation) → Points → Slack**.

## Arithmetic shown
- Ticket shares: 12/80=15.0%, 18/80=22.5%, 16/80=20.0%, 20/80=25.0%, 14/80=17.5% (sums to 100%).
- Distinct-ARR sums: HRIS 36k+48k+30k=$114k; Redemption 11k+10.7k+10.3k+9.6k+9.6k+8.9k+8.7k=$68.8k; Billing $52k; Points 4.5k+4.5k+4.2k+3.5k+3.4k+2.9k+2.9k+2.7k+2.5k=$31.1k; Slack 5.4k+5.2k+4.4k+3.9k=$18.9k.
- Portfolio ARR: 114k+68.8k+52k+31.1k+18.9k=$284.8k across 24 accounts; ARR shares 114/284.8=40.0%, 68.8/284.8=24.2%, 52/284.8=18.3%, 31.1/284.8=10.9%, 18.9/284.8=6.6%.
- All 80 tickets are classified (12+18+16+20+14=80); no account spans two themes, so no ARR is double-counted.

No facts were invented; all ticket IDs, aliases, and dollar figures are taken verbatim from the file.

Prospect: C-82AF3719 — Technology, Mid-Market, employee_recognition, NA-West

Ranking (all three are the only case-study customers scoring ≥3/4 on the four match fields; field-level scoring shown for each):

1) C-64171065 — Technology, Mid-Market, employee_recognition, NA-East (case study: true)
   Matches: industry (Technology), size_band (Mid-Market), use_case (employee_recognition) = 3/4
   Differs: region (NA-East vs NA-West — adjacent US region)
   Best overall fit: identical industry, size, and the exact use case the prospect is evaluating; region is close.

2) C-11C31562 — Manufacturing, Mid-Market, employee_recognition, NA-West (case study: true)
   Matches: size_band (Mid-Market), use_case (employee_recognition), region (NA-West) = 3/4
   Differs: industry (Manufacturing vs Technology)
   Strong use-case + region proof; industry is the only miss.

3) C-A13C193D — Technology, Mid-Market, retention, NA-West (case study: true)
   Matches: industry (Technology), size_band (Mid-Market), region (NA-West) = 3/4
   Differs: use_case (retention vs employee_recognition)
   Matches on industry/size/region, but the deployment is a different use case, so it's weaker as proof for employee_recognition specifically.

Near-miss excluded: C-CD4829A7 (Technology, Mid-Market, retention, NA-East, case study: true) scores only 2/4 (matches industry and size_band; differs on use_case and region), so it does not make the top three.

No customer without a case study was included, and no billing or contact data is present in or drawn from the source files.

Channel performance, trailing 6 months (2026-03 through 2026-08). Spend = 6 monthly rows × per-channel amount; SQM/SQO counts from contacts_first_touch.csv.

PAID CHANNELS

paid_search (spend $36,000 = 6 × $6,000)
- SQMs: 40, SQOs: 18, pipeline: $720,000 (18 × $40,000)
- Cost per SQM: $36,000/40 = $900.00
- Cost per SQO: $36,000/18 = $2,000.00
- SQM-to-SQO rate: 18/40 = 45.0%
- Pipeline per dollar: $720,000/$36,000 = 20.00

linkedin_ads (spend $24,000 = 6 × $4,000)
- SQMs: 25, SQOs: 8, pipeline: $96,000 (8 × $12,000)
- Cost per SQM: $24,000/25 = $960.00
- Cost per SQO: $24,000/8 = $3,000.00
- SQM-to-SQO rate: 8/25 = 32.0%
- Pipeline per dollar: $96,000/$24,000 = 4.00
- FLAGS (SQO date precedes SQM date):
  - CT-000044: SQM 2026-07-23, SQO 2026-07-18 ($12,000 pipeline)
  - CT-000041: SQM 2026-06-14, SQO 2026-06-09 ($12,000 pipeline)
  (Both rows are counted in totals above; dates need reconciliation — possible SQM date entry errors.)

paid_social (spend $18,000 = 6 × $3,000)
- SQMs: 0
- Cost per SQM, cost per SQO, SQM-to-SQO rate: undefined (no SQMs; not reported as zero)
- Pipeline: $0; pipeline per dollar: $0.00 (computed from actuals: $0/$18,000)

webinars (spend $9,000 = 6 × $1,500)
- SQMs: 12, SQOs: 5, pipeline: $60,000 (5 × $12,000)
- Cost per SQM: $9,000/12 = $750.00
- Cost per SQO: $9,000/5 = $1,800.00
- SQM-to-SQO rate: 5/12 = 41.7%
- Pipeline per dollar: $60,000/$9,000 = 6.67

ORGANIC CHANNELS

organic_search
- Volume (SQMs): 30, SQOs: 10, pipeline: $90,000 (10 × $9,000)
- SQO rate: 10/30 = 33.3%

referral
- Volume (SQMs): 15, SQOs: 6, pipeline: $48,000 (6 × $8,000)
- SQO rate: 6/15 = 40.0%

Totals (for reference): paid spend $87,000, 77 SQMs, 31 SQOs, $876,000 pipeline; organic 45 SQMs, 16 SQOs, $138,000 pipeline. Combined pipeline $1,014,000.

REALLOCATION RECOMMENDATION

1. Cut paid_social to zero. $18,000 spent, zero SQMs — it is not generating measurable demand and is dragging total paid pipeline-per-dollar from 20.00 (paid_search alone) down to 10.07 blended.
2. Shift the freed $18,000 to paid_search, which is 2.5× LinkedIn's pipeline-per-dollar (20.00 vs 4.00) and has the best cost per SQO among paid channels ($2,000 vs $3,000) plus the highest SQM-to-SQO rate (45%).
3. Reduce linkedin_ads (e.g., 30–50%): second-worst efficiency at $3,000 per SQO and 4.00 pipeline per dollar, and it also carries both date-integrity flags, so verify attribution before adding anything there.
4. Keep webinars at current level: lowest cost per SQM ($750) and best pipeline per dollar of the paid channels after paid_search (6.67); treat as a supporting channel, not a growth bet at this spend.
5. Do not touch organic/referral (no spend to reallocate), but referral's 40% SQO rate supports investing in a referral program.

CONFIDENCE: Moderate-low. Direction is clear (paid_search >> webinars >> linkedin_ads >> paid_social), but sample sizes are small — 8 LinkedIn SQOs, 5 webinar SQOs, 6 referral SQOs — so 1–2 deals move LinkedIn or webinar cost-per-SQO by 10–20 points. Also, pipeline amounts are uniform within each channel in this extract (every paid_search SQO is exactly $40,000, etc.), so pipeline-per-dollar differences track SQO volume, not deal-size quality; I would validate with at least one more full quarter of data before cutting paid_social abruptly, and reconcile the two linkedin_ads date flags before finalizing the LinkedIn number.

BATTLECARD: RIVALLY — updated 2026-09-06 (supersedes existing_battlecard.md)

1) ONE-LINE POSITIONING
Points-based recognition feed [S02] sold to mid-market [S04] and EU enterprise [S12], now layered with the Rivally Pulse engagement-survey add-on [S06, S23].

2) PRICING (newer source wins)
- Current list: $7.00/user/mo, Recognition Starter tier, annual billing required — pricing page, 2026-08-12 [S17].
- CONFLICT: pricing page showed $5.00/user/mo annual-required on 2026-01-20 [S03] and still $5.00 on 2026-04-01 [S08]; the 2026-08-12 update to $7.00 [S17] is newer and wins. List price rose $5.00 → $7.00 between April and August 2026.
- Deal quotes (call-reported, not list price): $6.50/user/mo annual term quoted to a 500-seat prospect, 2026-06-02 [S13] — sits between the old and new list, consistent with a negotiated quote during the hike. 2026-08-14: prospect reports $7.00 list with 15% discount for a 3-year term [S18] → 7.00 × (1 − 0.15) = 7.00 − 1.05 = $5.95/user/mo effective.
- Pulse add-on: priced as a separate add-on, not bundled [S23]; no dollar figure for the add-on appears in the provided snippets.
- Data gaps: Bonusly's own pricing is not in the provided data, so no price comparison can be computed. S21 ("discounting aggressively") and S09 ("clunky UI") are AE opinions from calls, not facts — excluded.

3) WHERE THEY WIN
- Engaging points-based recognition feed [S02, S16].
- Fast setup; Slack integration worked out of the box [S04].
- EU: data residency now generally available [S15] (already pitched in Feb [S05]); strong for distributed EU teams; multi-language support praised [S12]; EMEA expansion hire, ex-Workday VP [S11]; Dublin office opened [S15].
- Support response time under 4 hours [S22].
- Microsoft Teams app v2 in public preview [S19].

4) WHERE WE WIN
- Analytics depth — the clearest wedge: Rivally analytics are limited [S02], dashboards "basic compared to enterprise tools" [S07], analytics exports are CSV-only, which made migration off Rivally hard [S20]; an 800-seat prospect picked Bonusly over Rivally in Sept 2026 citing analytics depth [S25].
- Enterprise user management: Rivally lacks SCIM provisioning; manual user management called painful [S10]. Caveat: our SCIM capability is not confirmed in the provided data — verify before claiming.
- Admin tooling: Rivally admin console lacks bulk recognition editing [S24]; admin tooling "lags peers" [S16]. Caveat: our bulk-edit capability is not in the provided data.
- EMEA rewards catalog: Rivally's EMEA catalog is thinner than US [S14]. Caveat: our EMEA catalog strength is not in the provided data.

5) OBJECTIONS AND RESPONSES
- "Rivally is cheaper" — list is now $7.00 [S17], up from $5.00 [S03, S08]; their discounting is tied to 3-year terms (15% off [S18]). We have no Bonusly pricing in this dataset, so no counter number can be computed here.
- "Rivally is faster to set up" — reviewer-true [S04]; concede on mid-market, pivot enterprise deals to provisioning (no SCIM [S10]) and analytics [S07, S20].
- "Rivally has EU data residency" — true, GA 2026-07-01 [S15] and pitched as early as Feb [S05]. Our EU data residency status is not in the provided data — cannot rebut from this dataset; confirm actual status before use.
- "Rivally support is faster" — sub-4-hour response reported [S22]; no rebuttal data in the provided snippets.
- "Rivally's UI is clunky" / "they're discounting aggressively" — rep opinions only [S09, S21]; not verified facts; do not use in customer-facing claims.

6) RECENT CHANGES (timeline)
- 2025-11-04: Series C, $40M, led by Northgate Ventures [S01].
- 2026-03-05: launched Rivally Pulse engagement survey add-on [S06].
- 2026-05-09: hired ex-Workday VP EMEA to lead European expansion [S11].
- 2026-07-01: opened Dublin office; EU data residency GA [S15].
- 2026-08-12: Recognition Starter list price $5.00 → $7.00/user/mo [S08 → S17].
- 2026-08-20: Microsoft Teams app v2 public preview [S19].
- 2026-09-01: Pulse exited beta; priced as add-on, not bundled [S23].

7) 12-MONTH WIN/LOSS RECORD (2025-09 → 2026-08)
All 20 Rivally deals in the file fall in the window.
Wins (13): Deal-A9FD43, Deal-7AA785, Deal-44C524, Deal-0D0CD6, Deal-D5B790, Deal-5C636E, Deal-67BE14, Deal-1B6969, Deal-F03E7B, Deal-072E31, Deal-F65C8F, Deal-E46EAB, Deal-1D2392
Losses (7): Deal-7767F5, Deal-5645A5, Deal-C6FFAA, Deal-D263E0, Deal-935746, Deal-9066A6, Deal-72A02F
Win rate: 13 / 20 = 0.65 → 65%.
By month (W/L):
  2025-09: 1/1 (Deal-072E31 W; Deal-7767F5 L)
  2025-10: 2/0 (Deal-A9FD43, Deal-F65C8F)
  2025-11: 1/1 (Deal-7AA785 W; Deal-D263E0 L)
  2025-12: 1/1 (Deal-44C524 W; Deal-935746 L)
  2026-01: 2/0 (Deal-0D0CD6, Deal-E46EAB)
  2026-02: 2/0 (Deal-D5B790, Deal-1D2392)
  2026-03: 1/1 (Deal-5C636E W; Deal-9066A6 L)
  2026-04: 0/2 (Deal-5645A5, Deal-72A02F)
  2026-05: 0/1 (Deal-C6FFAA)
  2026-06: 1/0 (Deal-67BE14)
  2026-07: 1/0 (Deal-1B6969)
  2026-08: 1/0 (Deal-F03E7B)
Trend: 3 consecutive losses 2026-04 → 2026-05, then 3 consecutive wins 2026-06 → 2026-08. Check: 1+2+1+1+2+2+1+0+0+1+1+1 = 13 wins; 1+0+1+1+0+0+1+2+1+0+0+0 = 7 losses.
Note: no deals vs Rivally are recorded for Sept 2026 in the file, but a call note reports one additional win on 2026-09-03 (800-seat prospect, analytics depth [S25]); no deal alias provided for it.

OLD CARD RECONCILIATION
- "Rivally lacks a Slack integration" — FALSE/STALE: contradicted by [S04] (Slack worked out of the box, 2026-02-02). Remove.
- "Acquired by WorkHuman in 2025" — UNVERIFIED: no provided snippet supports a WorkHuman acquisition; the only Work*-related fact is the ex-Workday EMEA hire [S11]. Do not use until re-sourced.
- "Strong in EU enterprise with multi-language support" — re-sourced, keep [S12].
- "Points-based recognition for mid-market" — points-based [S02]; mid-market reviewer base [S04]. Keep, with citations.
- "Pricing starts at $5 (as of 2026-01)" — stale; now $7.00 [S17].

Sequence review (rates on total sent across 3 steps; per-step in parentheses):

New Logo Nurture — sent 1,386. Open 35.4% (490/1386), reply 6.5% (90/1386), meeting 1.95% (27/1386). Weakest step: step 3 (reply 4.2%, meeting 1.40%).

Expansion Nurture — sent 875. Open 64.6% (565/875), reply 6.7% (59/875), meeting 1.37% (12/875). Weakest step: step 3 (reply 4.4%, meeting 1.09%).

Cold Outbound - HR Leaders — sent 1,785. Open 30.5% (545/1785), reply 0.4% (8/1785), meeting 0.0% (0/1785). Weakest step: step 3 (reply 0.2%, 0 meetings; every step is weak).

Cold Outbound - People Ops — sent 1,163. Open 29.2% (340/1163), reply 2.5% (29/1163), meeting 0.52% (6/1163). Weakest step: step 3 (reply 1.6%, meeting 0.27%).

Tracking errors (opened > sent): Expansion Nurture step 2: 340 opened vs 300 sent (113.3%) — impossible; open tracking is broken (likely dedup/window miscount). Also its step 1→2 shows 0 attrition (300→300), which is suspicious in a 3-touch nurture.

Audience overlap (23 contacts in two sequences): 21 contacts are in BOTH Cold Outbound - HR Leaders and Cold Outbound - People Ops (e.g., CT-000849, CT-000884, CT-000890, CT-000908, CT-001033); 2 are in Expansion + New Logo (CT-000301, CT-000624). HR vs People Ops overlap (~7% of each audience) means duplicated cold messaging to the same people.

Failure mode, <2% reply (Cold Outbound - HR Leaders): message/audience mismatch. Opens are normal (40% step 1) but replies collapse 5→2→1 and meetings are zero — the hook does not resonate with HR leaders; this is a relevance/offer problem, not a deliverability one.

One change per weak sequence:
- HR Leaders: rework step-1 offer for HR leaders (role-specific pain point) before sending more volume.
- People Ops: cut to 2 touches — step 3 adds 1 meeting on 377 sends; reallocate to step-1 testing.
- Expansion: fix step-2 open tracking before optimizing; its reported 113% open rate invalidates step-2 metrics.

Fix first: Cold Outbound - HR Leaders — it's the largest spend (1,785 sends) producing zero meetings, so it's destroying the most capital and also double-messaging 21 contacts who are also in People Ops.

WEEKLY MARKETING GOALS UPDATE — Q3-2026 (66 of 92 days elapsed = 71.7% of quarter)

Pace rule: QTD actual vs prorated expectation (target × 66/92). At 71.7% through, expectation is 71.7% of target.

1) SQMs
   QTD actual: 230 | Target: 300 | Delta: -70
   Prorated expectation: 300 × 66/92 = 215.2 | 230 / 215.2 = 106.9% of pace → AHEAD
   (76.7% of full-quarter target)

2) SQOs
   QTD actual: 84 | Target: 120 | Delta: -36
   Prorated expectation: 120 × 66/92 = 86.1 | 84 / 86.1 = 97.6% of pace → BEHIND (marginal, ~2 SQOs under pace)
   (70.0% of full-quarter target)

3) DS2s
   QTD actual: 40 | Target: 75 | Delta: -35
   Prorated expectation: 75 × 66/92 = 53.8 | 40 / 53.8 = 74.3% of pace → BEHIND (need ~13.8 more DS2s to hit pace; remaining ~13.8 per week over 26 days)
   (53.3% of full-quarter target)

4) Closed-lost MIA rate (lower_better)
   QTD actual: 5 MIA / 25 closed-lost = 0.20 (20%) | Target: 0.10 (10%) | Delta: +0.10 (10 pts worse than target) → BEHIND
   At 10%, 25 lost deals would allow only 2.5 MIA; actual 5 is double that.

5) Same-quarter closes
   QTD actual: 10 | Target: 20 | Delta: -10
   Prorated expectation: 20 × 66/92 = 14.35 | 10 / 14.35 = 69.7% of pace → BEHIND
   (50.0% of full-quarter target; needs ~10.3 closes in the final 26 days, ~2.6/week)

6) Active pipeline coverage
   QTD actual: $3,000,000 | Target: $4,000,000 | Delta: -$1,000,000
   Prorated expectation: $4,000,000 × 66/92 = $2,869,565 | $3,000,000 / $2,869,565 = 104.5% of pace → AHEAD
   (75.0% of full-quarter target; needs +$1M added net by quarter end)

WHAT MOVED THIS WEEK
The provided files contain only current QTD snapshots (marketing_qtd.csv, targets.csv, quarter_meta.csv); no prior-week or historical values are included, so I cannot compute week-over-week movement and will not invent it. What the snapshot does show: SQMs and active pipeline are the two ahead-of-pace metrics (106.9% and 104.5% of expectation), SQOs are essentially at pace (97.6%), and the clear gaps are downstream — DS2s at 74.3% of pace, same-quarter closes at 69.7%, and the closed-lost MIA rate at 20% versus the 10% target. The pattern (top-of-funnel ahead, conversion and closes behind) suggests the constraint is in DS2 conversion and closing velocity rather than opportunity generation. To quantify what actually moved this week, I'd need last week's QTD file or a dated daily series — say the word if you have it.

Q3 weighted forecast lands at $115,977: 7 COMMIT ($44,729) plus 35% of 24 BEST_CASE deals ($203,565). I'd hold this number: owner is blank on 85 of 86 deals and why-buys is empty on all 7 COMMIT, so nothing here validates against quota or reason to buy. 32 deals worth $227,575 sit just past quarter end, several at DS2/DS3 within four weeks of close, which means dates are being pushed, not re-qualified.

Subject: Re: 150-seat pricing after the July 28 demo

Hi [First Name],

Following up on the 150-seat pricing I sent on August 5, after the July 28 demo — I know pricing emails can get buried.

The People team's reaction to the automated milestone awards and points catalog was great, and I'd like to make sure the recognition program is still on your radar before the year wraps up.

Could you set up a quick 15-minute call this week to walk through the pricing and next steps? If the timing is off, just let me know a better window and I'll adjust.

Thanks,
Alex Franklin

Word count: ~95, under 120.

Notes on sourcing:
- Specific prior touch cited: ENG-00001, the 2026-08-05 email with 150-seat pricing (no reply recorded).
- Single clear ask: a 15-minute call to review pricing and next steps.
- Recipient's name is not in the data, so I used a [First Name] placeholder rather than invent one. The VP People attended the demo (ENG-00002) but no name is given.
- Deal figures and dates (150 seats, $5,100, 2026-11-26 close) all match stalled_deal.csv and the engagement log; no details were added beyond what the files contain.

Weekly GTM Digest — Week of 2026-08-31

MARKETING
A week worth celebrating: the team generated 46 SQMs against a target of 52. Webinars stood out as the standout channel, contributing 18 of those SQMs, and paid search efficiency held steady at $150 cost per SQM.

SALES
Sales is on a roll: 14 SQOs converted, 9 DS2 meetings set, and $310,000 in new pipeline created. Three closes landed this week, keeping the quarter moving.

CS
Customer success delivered two saved renewals, and team NPS moved to 61. Three open red-flag accounts head into next week.

PLG
PLG's flywheel keeps spinning: 412 new signups this week, activation at 31%, and 38 companies reaching the aha moment — 10 recognition gives in.

Traceability note: every figure above is taken verbatim from week_extracts.md (46/52 SQMs, 18 webinar SQMs, $150 paid search CP-SQM; 14 SQOs, 9 DS2s, $310,000 pipeline, 3 closes; 2 renewals saved, NPS 61, 3 red-flag accounts; 412 signups, 31% activation, 38 companies at 10 gives). No numbers were derived, adjusted, or invented; no customer contact names, employee-level commentary, or compensation data appear in the source and are excluded. Total digest body is ~110 words, well under the 400-word cap.

PARTNER DIGEST — 2026-08-24 to 2026-09-04

ACTIVE PARTNERS

Apex Rewards Co — 2 partner-sourced deals, $275,000 (Deal-DDAAF2 $180,000 + Deal-2CF33E $95,000); both in DS1. Co-webinar locked for 09-15.

HRCloud Partners — 1 partner-sourced deal, $140,000 (Deal-F1CDA5); opp moved to DS2 after the security review closed.

CultureBridge — 2 partner-sourced deals, $135,000 (Deal-096E1D $60,000 + Deal-067213 $75,000); both early stage.

WorkWell Group — 0 partner-sourced deals, $0. Joint playbook restart targeted for Q4; planning call booked for 09-09.

QUIET PARTNERS

Recogniq — no sourced deals or activity this period.
KudosWave — no sourced deals or activity this period.
PeopleFirst Advisors — no sourced deals or activity this period.
TotalPerk — no sourced deals or activity this period.

Totals: 5 partner-sourced deals, $550,000 (275,000 + 140,000 + 135,000; deal count 2 + 1 + 2 + 0 = 5).

All 8 roster partners listed once. Slack figures (Apex 2, HRCloud 1, CultureBridge 2, WorkWell 0) reconcile exactly with partner_deals.csv; no deal data exists for the four quiet partners.

ANSWERED FROM POLICY EXCERPTS ONLY (Trust portal). No values invented.

Q1 — Is customer data encrypted at rest? If so, how?
Yes. All customer data is encrypted at rest using AES-256.
Cite: [P1]

Q2 — Is data encrypted in transit?
Yes. Data in transit is encrypted with TLS 1.2 or higher.
Cite: [P1]

Q3 — Do you hold a SOC 2 report, and can we obtain a copy?
Yes. Bonusly maintains a SOC 2 Type II report, renewed annually. A copy is available to prospects under NDA.
Cite: [P2]

Q4 — How long is customer data retained after contract termination?
90 days after the end of the contract, after which it is deleted from production systems.
Cite: [P3]

Q5 — Where is your subprocessor list published and how are changes notified?
List is maintained at trust.bonusly.com. Customers receive 30 days notice before a new subprocessor is added.
Cite: [P4]

Q6 — Do you support SAML single sign-on?
Yes. SAML 2.0 single sign-on is available on the Enterprise plan. (SCIM user provisioning is also available on that plan.)
Cite: [P5]

Q7 — What is your production backup schedule and retention?
Production databases are backed up daily; backups are encrypted and retained for 35 days.
Cite: [P6]

Q8 — Do you hold an ISO 27001 certification?
Unanswerable from the provided excerpts. No excerpt states or references ISO 27001. The excerpts only address SOC 2 Type II [P2]. The document that would answer this: an ISO 27001 certificate, or the trust portal's certification/compliance listing.

Q9 — What is your contractual uptime SLA percentage?
Unanswerable from the provided excerpts. No excerpt references an uptime/availability SLA or a percentage. The document that would answer this: the Master Services Agreement / Services Order Form (SLA section).

Q10 — Will you sign a HIPAA Business Associate Agreement?
Unanswerable from the provided excerpts. No excerpt mentions HIPAA or a BAA. The document that would answer this: a HIPAA Business Associate Agreement / privacy addendum, or the trust portal's compliance/offerings section.

Note: The questionnaire is fully covered by the excerpts for Q1–Q7. Q8, Q9, and Q10 fall outside the provided policy excerpts and are marked unanswerable with the specific document needed. No guesses made.

I've analyzed the 14 skills against the manifest. I'll show the arithmetic where applicable, and report one proposal per finding — I'm not rewriting anything.

====================================================================
RECONCILIATION REPORT — 14 skills vs. skill_manifest.csv
====================================================================

FINDING 1 — TRIGGER-PHRASE OVERLAPS (two clusters)

1a) CRITICAL — comms-drafter vs email-drafter: verbatim trigger duplication
Both descriptions claim the same ALWAYS-phrases:
  "write me an email"   — comms-drafter ✓, email-drafter ✓
  "draft a follow-up"   — comms-drafter ✓, email-drafter ✓
  "help me reply"       — comms-drafter ("help me reply"), email-drafter ("help me reply to this")
  "bump email"          — comms-drafter ✓, email-drafter ✓
  "contract nudge"      — comms-drafter ✓, email-drafter ✓
  "what should I say"   — comms-drafter ✓, email-drafter ✓
The bodies confirm it's not a layered split: both contain identical content — the same outbound/follow-up/post-demo/contract/EOQ/QBR/check-in/onboarding guidance sections, and the exact same contract-follow-up tone benchmark paragraph verbatim in both. comms-drafter routes "deep deal strategy" to deal-strategy-coach; email-drafter's lane marker says the identical thing. The only differentiator in email-drafter (Gmail signature retrieval) is a feature, not a routing boundary. Routing is ambiguous: any "write me an email" could load either skill.
Proposal (MERGE): keep email-drafter as the canonical email skill (it has the Gmail signature logic); absorb comms-drafter's non-email lanes (Intercom/support, partner/broker, rewards catalog inquiries) either into email-drafter or into a new support-comms skill — then DELETE_SKILL comms-drafter. Update deal-strategy-coach's lane-marker cross-references to point at the survivor.

1b) WARNING — pipeline-intelligence-report vs weekly-pipeline-report: near-duplicate pipeline triggers
  "pipeline update" (PIR) vs "run the pipeline update" (weekly) — substring collision
  "what's the pipeline look like" (PIR) vs "what does pipeline look like" (weekly)
  "run the pipeline report" (PIR) vs "do the pipeline report" (weekly)
Different deliverables (10-tab scored tier report vs weekly performance HTML), but the phrasings above are close enough that a casual "run the pipeline update" fires both. next-to-close explicitly disambiguates against PIR, but neither of these two disambiguates against each other.
Proposal (REVIEW): add explicit negative boundaries — PIR owns scored/tiered "full pipeline" asks; weekly-pipeline-report owns "this week's numbers / MTD vs target" asks — and retire "pipeline update" from PIR's trigger list in favor of unambiguous "full pipeline" / "score the pipeline."

1c) INFO — stale-pipeline-report vs next-to-close: partial overlap
next-to-close's "which deals are most likely to close" and stale's "who hasn't been contacted" are distinct, but "run the [X] report" + deal-listing phrasing invites cross-fires; neither lists the other as an exclusion.
Proposal (REVIEW): add a one-line cross-reference in each: stale = no-activity diagnostics; next-to-close = imminent-close shortlist.

No other ALWAYS-trigger pairs overlap materially (closed-lost, partner-digest, sales-forecast, model-selection, analysis-validator, claim-compressor, and feedback each occupy distinct phrase space; sales-forecast's "what do we think we're going to close" is close to next-to-close's "what's about to close" — INFO, note only).

FINDING 2 — CIRCULAR DELEGATION CHAIN

None found. The delegation graph is a DAG:
  pipeline-intelligence-report → closed-lost-analysis (one-way)
  next-to-close → pipeline-intelligence-report (one-way)
  comms-drafter / email-drafter → deal-strategy-coach (one-way)
  deal-strategy-coach, email-drafter, comms-drafter → prospect-research-multithreading (one-way)
  sales-forecast → analysis-validator → (claim-compressor → signalforge-feedback is a terminal chain, no back-edges)
  analysis-validator → bonusly-*-questions specialists (one-way; those skills aren't in this manifest, but no cycle)
No chain returns to its origin. Nothing to name — no circular chain exists.

FINDING 3 — DANGLING DELEGATION TARGETS (targets named but absent from the set)

CRITICAL dangling targets (named as skills to invoke, no file, no manifest row):
  1. prospect-research-multithreading — invoked by deal-strategy-coach, email-drafter, comms-drafter
  2. bonusly-brand — invoked by comms-drafter (Step 0), email-drafter, sales-forecast
  3. signalforge-reports (org skill) — /mnt/skills/organization/signalforge-reports/{SKILL.md, DESIGN-SYSTEM.md, signalforge.css, reports.html, brand-lockup.html} — required MANDATORY PRE-BUILD step of pipeline-intelligence-report and weekly-pipeline-report
WARNING dangling targets:
  4. caveman — referenced by signalforge-claim-compressor ("Relationship to Caveman Skill", "Both can be used together"); the compressor describes it as a peer skill, but it has no file or manifest row
  5. skill-orchestrator — referenced by analysis-validator (§11 cascading files) and signalforge-feedback (activation checklist); also `CUSTOMER_DATA_REFERENCE`, `HUBSPOT_CONNECTOR_REFERENCE`, `SIGNALFORGE_PRODUCT_INSIGHT_SKILL` in analysis-validator §11
  6. The 8 `bonusly-*-questions` specialist skills (bonusly-data-questions, bonusly-product-questions, bonusly-business-reporting-questions, bonusly-rewards-questions, bonusly-ppp-questions, bonusly-feature-flag-questions, bonusly-deal-desk-questions, bonusly-datadog-questions) — analysis-validator §12.4 delegation table; none present in the manifest
Also note (non-skill but dangling reference paths): sales-forecast references `references/data-sources.md`, `report-structure.md`, `cadence.md`, `report-template.html`, `TEMPLATE_README.md`; weekly-pipeline-report references `references/report-spec.md`, `queries.md`; stale-pipeline-report references `/mnt/skills/public/xlsx/scripts/recalc.py`; pipeline-intelligence-report references `/mnt/skills/user/closed-lost-analysis/SKILL.md` (a second, differently-pathed copy of a skill that exists here — path drift).
Proposals: (4-6) REVIEW — confirm these live in the same skill registry; if not, either add manifest rows + files or rewrite the references to inline the content. (1-3) CRITICAL — add the skills or remove the invocation instructions; a skill that hard-stops on a missing skill (Step 0 of comms-drafter, MANDATORY PRE-BUILD of two report skills) will fail at runtime.

FINDING 4 — VERSION CONFLICT

WARNING — analysis-validator has internal version inconsistency:
  Header: "Version: 3.6" / "Last Updated: May 9, 2026 (v3.6 — G2-F: ID Resolution)"
  Validation Trail template (§7): "Validator: analysis-validator v3.2"
  Changelog (§14): 1.0 → 2.0 → 2.6 → 3.6, 3.5, 3.4, 3.3, 3.2, 3.1, 3.0 (non-sequential ordering, 3.6 listed before 3.5)
The v3.2 in the trail template is stale relative to the declared 3.6 (G2-F was added in 3.6, and the trail template itself lists a G2-F row — so the template was updated, but the version string was not). No two skills declare conflicting versions of each other; all other skills are at 1.0/1.1 with matching changelogs.
Which should survive: v3.6 — the header and changelog agree on 3.6, and the body's feature set matches v3.6 (G2-F + G1-L both present).
Proposal (UPDATE_BODY): change the trail template string "analysis-validator v3.2" → "analysis-validator v3.6", and re-order the §14 changelog descending (3.6 → 1.0).

FINDING 5 — MANIFEST DESCRIPTIONS EXCEEDING 1,024 CHARACTORS

Manifest counts (I recomputed from the description text; arithmetic shown for the two >1,024):
  656, 897, 996, 792, 965, 676, 945, 1004, 1006, 962, 1006, 708, 762, 656
  - pipeline-intelligence-report: declared 1,006. Recompute: 79+55+112+75+123+95+113+74+104+103+68+96+68+85+44 = 1,220 → exceeds 1,024 by 196
  - signalforge-claim-compressor: declared 1,006. Recompute: 76+113+59+53+149+123+70+92+80+81+74+48+79+41+125 = 1,263 → exceeds 1,024 by 239
  All others recompute at or under ~1,024 (partner-digest ≈1,018; next-to-close ≈960; email-drafter ≈990; sales-forecast ≈975; comms-drafter ≈990 — all pass).
Answer: 2 descriptions exceed 1,024 characters: pipeline-intelligence-report and signalforge-claim-compressor. Note: both declared counts (1,006) are themselves under 1,024 — the manifest's own description_chars column understates the actual text length for these two rows, so the limit can only be detected by recounting, not by reading the column.
Proposals (TRIM_DESC, one each):
  - pipeline-intelligence-report: cut ≥196 chars — e.g., drop the "No hardcoded deal counts, ARR figures, or tier totals — ever" sentence (52) and compress the ALWAYS-trigger list (≈150) to "run the pipeline report / pipeline review / score the pipeline / full pipeline / pipeline update."
  - signalforge-claim-compressor: cut ≥239 chars — the enumeration of preserved-data categories (ARR, deal names, company names, rep names, metrics, dates, percentages, SQL results, table content, stage labels, source citations, validation tiers) can be compressed to "numbers, named entities, SQL, table content, citations, and tier labels."

FINDING 6 — HARDCODED PAGE IDS, DATES, PERSON NAMES IN BODIES

Yes, extensive. Enumerated by skill (severity = staleness risk):

WARNING — partner-digest (worst offender):
  - Confluence IDs: Cloud 73fe98de-a4a3-4869-9f8a-bb1eeed4cf7f, Space 1958248479 (RevOps), folder 2286616609, canonical reference page 2286321666 (dated "May 16, 2026 issue")
  - Five partner page IDs: 2265382925, 2236940297, 2237825028, 2239365136, 2238283777
  - People: Amani Phipps (owner line), Slack ID U03QLMBL7AR, BambooHR contacts "Kelli, Jen Lee", Snappy "Hani, Bryce", PartnerStack "Sara", "Q2/Q3 2026" page title, changelog dates 2026-05-17
WARNING — sales-forecast:
  - Space ID 2232811524, parent page 2232582148 (Sales · Recurring Reports), Cloud ID same as above, CQL space key "SignalForg"
  - People: "Alaina / VP Sales view" (changelog: "Elena → Alaina"), "Q2 Narrative" tab name is hardcoded (tab 6 of a quarter-agnostic skill — stale by design), example title "Q3 2026 … July 9, 2026"
WARNING — signalforge-feedback:
  - Page ID 2295136266 (Feedback Log), parent 2234417154 (About SignalForge), spaceId 2232811524, Build Log page 2247295002, full Confluence URL
INFO/WARNING — analysis-validator (domain-hardcoded, some intentional):
  - GTM roster §12.3: 16 named people with HubSpot Owner IDs (Bryce Harmon 119337721, Hugo Lindqvist 77260721, Dana Mercer 83155923, Alex Franklin 84342457, Cole Ingram 83155924, Gavin Porter 1520255671, Colleen Perry 77938470, Ellie Barton 79580306, Ashley Reyer 81969994, Megan Franz 321546903, Elena Sinclair 701163055, Youssef Elkhateeb 725397794, Amanda Czenkus 1556884388, Alaina Loori 82535637, Shealagh Coughlin 119069206, Ben Castelli 348210196, Amani Phipps 210200121, John Thomas 78303262, Yasmin Wahid 89062643) — roster "Updated May 4, 2026"
  - Dates: "Created: April 26, 2026", "Last Updated: May 9, 2026", "CALL_SPOTLIGHT_BRIEF removed as of May 4, 2026" (×2), "Stale as of March 28, 2023", "as of May 2026" ranges, escalation names "Manish or Amani"
  - Deal stage IDs 150582536–150582539 + 1175632767, pipeline UUID '5877cc33-...'
  - Population anchors ~452,000 / ~110,097 / 3,000–3,500 / 850–1,100 / 150–350 (labeled "re-verify each session" — intended as calibration, acceptable)
WARNING — pipeline-intelligence-report:
  - AE owner IDs hardcoded "verified May 2026" (Bryce Harmon 119337721, Dana Mercer 83155923, Cole Ingram 83155924, Alex Franklin 84342457, Gavin Porter 1520255671) — note: 5 AEs, while analysis-validator §12.3 lists 6 "Core 6 AEs" (Hugo Lindqvist missing) — internal roster inconsistency
  - HubSpot org ID 1973303 (URL pattern, labeled system constant), stage IDs, "stale (last modified March 2023)", footer stamp "Analysis Validator v3.6"
WARNING — weekly-pipeline-report:
  - Named owner "Ben Lavin · Demand Generation" in the H1 (a person baked into the report header)
  - Google Sheet IDs: 1CLZeOsElVDF_LF0ZG_t2nfwvhnZ6bpwqM_nX3WEYzcw (targets), 1ENuaEcCuLjdKhMvp8FK3Ys1ek5Aw9ZuOZhsHJJFoB_k (bookings forecast)
  - Dates: "Q2 (April 1 – June 30, 2026)" in Step 0 of a skill meant to run weekly across quarters; static "Q1 2026" actuals $365,152 / $475,000 / $2,490,532 / $3,288,000
WARNING — deal-strategy-coach:
  - Confluence playbook URL with page ID 2257879045 ("AE Excellence Playbook April 2026" — dated artifact pinned as the authoritative reference)
  - People: "routed to Farid" (ICP section), competitor list, 2026 pricing table (dated by nature)
WARNING — closed-lost-analysis:
  - Named customer deals embedded as evidence: Softheon (Motivosity loss), Estee Lauder, LIFTOFF, Nestlé, Ozinga, MinIO, Aurora Innovation, GCash, Ethos Cannabis, StickerYou; "30-deal AI-field sample from May 2026"; "May 2026" field confirmations
WARNING — next-to-close:
  - HubSpot org ID 1973303 in deal URL pattern, stage IDs inlined, channel names #deal-desk / #enterprise-chat / #sales-team-internal / #internal-revops
WARNING — stale-pipeline-report:
  - Slack channel #revops-team ID C0561C1JCPJ (×2), org ID 1973303, "Bonusly Support 55483190" exclusion, "Don't query all 97 deals" (a deal count baked into a performance note), changelog 2026-06-10
INFO — model-selection:
  - "last_checked: 2026-05-19", "Opus 4.6 deprecation announced April 14, 2026", model registry dates — self-updating by design, so informational only
Proposals (one per skill, action UPDATE_BODY):
  - partner-digest: replace fixed page/folder IDs with a one-time lookup instruction ("search RevOps space for 'Partnerships Digest' folder") and move per-partner contact names out of the body into the digest data pull
  - sales-forecast: rename tab 6 "Q2 Narrative" → "Quarter Narrative"; keep Confluence IDs but mark them "verify at run time"
  - analysis-validator: keep roster/stage IDs (they serve G2-F resolution) but change "Updated May 4, 2026" to "verify against live owner search at session start"
  - pipeline-intelligence-report: replace hardcoded AE owner-ID block with live `HubSpot:search_owners` resolution (stale-pipeline-report already does this dynamically — adopt the same pattern), fixing the 5-vs-6 AE discrepancy
  - weekly-pipeline-report: remove "Ben Lavin" from the H1 (make owner dynamic), move Q1 2026 statics and the Q2 window out of Step 0
  - deal-strategy-coach: pin the playbook by a stable space path + "confirm current page ID at run time"
  - closed-lost-analysis: move named-deal evidence into an appendix labeled "historical examples, not current data"
  - next-to-close / stale-pipeline-report: keep org/channel IDs (system constants) but move them to a single "verify at run time" block; delete "all 97 deals"

FINDING 7 — MANIFEST DRIFT (both directions)

  Files on disk (14): analysis-validator, closed-lost-analysis, comms-drafter, deal-strategy-coach, email-drafter, model-selection, next-to-close, partner-digest, pipeline-intelligence-report, sales-forecast, signalforge-claim-compressor, signalforge-feedback, stale-pipeline-report, weekly-pipeline-report
  Manifest rows (14): identical list, declared_name == file name in every row.
  Result: 14 files ↔ 14 rows, 1:1. Files with no manifest row: 0. Manifest rows with no file: 0. No drift.
  (The dangling names in Finding 3 — prospect-research-multithreading, bonusly-brand, signalforge-reports, caveman, skill-orchestrator, bonusly-*-questions — are referenced *inside bodies* but correctly absent from the manifest; they are missing skills, not drift.)
Also noted for completeness: the manifest's description_chars and body_lines columns are unreliable — several declared values don't match the actual text (e.g., the two 1,024+ findings above were declared as 1,006; analysis-validator's actual body far exceeds 1,429 lines).
Proposal (REVIEW): regenerate the manifest's description_chars/body_lines columns from the files; it currently cannot serve as the source of truth for size limits.

====================================================================
SUMMARY TABLE
====================================================================
# | Finding | Severity | Action
1a | comms-drafter / email-drafter verbatim trigger + content duplication | CRITICAL | MERGE (keep email-drafter, absorb, DELETE_SKILL comms-drafter)
1b | pipeline-intelligence-report / weekly-pipeline-report trigger collision | WARNING | REVIEW (explicit negative boundaries)
1c | stale-pipeline-report / next-to-close partial overlap | INFO | REVIEW (cross-reference lines)
2 | Circular delegation chain | — | None found (graph is a DAG)
3a | Dangling: prospect-research-multithreading, bonusly-brand, signalforge-reports | CRITICAL | REVIEW (add skills or remove invocation steps)
3b | Dangling: caveman, skill-orchestrator, 8 bonusly-*-questions, 3 *_REFERENCE files, reference/ paths in 4 skills | WARNING | REVIEW
4 | analysis-validator v3.2 in trail template vs v3.6 header | WARNING | UPDATE_BODY (v3.6 survives; fix string + reorder changelog)
5 | 2 manifest descriptions exceed 1,024 chars (1,220 and 1,263 actual) | WARNING | TRIM_DESC ×2
6 | Hardcoded page IDs / dates / person names in 10 of 14 bodies | WARNING (INFO for model-selection, analysis-validator anchors) | UPDATE_BODY per skill
7 | Manifest drift: none (14 ↔ 14); manifest size columns stale | INFO | REVIEW (regenerate columns)

# RUNBOOK: reward-worker queue depth incident (2026-08-29)
Source: #incident-2026-08-29-reward-queue (resolved). Every step below cites its thread message.

**Step 1 — Acknowledge alert, take Incident Commander**
- Who: Bryce Harmon (M01, 14:02:10Z)
- Action: PagerDuty alert for reward-worker queue depth > 10k fired; acknowledged and took IC.
- Verification: Acknowledgement logged (M01).
- Rollback: N/A — no system state changed.

**Step 2 — Confirm queue depth**
- Who: Farid Osman (M02, 14:04:33Z)
- Command: `bundle exec rake sidekiq:queue_depth`
- Result: 48,213 pending jobs (normal is under 500).
- Verification: Command output as above.
- Rollback: N/A — read-only.

**Step 3 — Inspect dead set**
- Who: Farid Osman (M03, 14:06:02Z)
- Command: NOT SPECIFIED IN THREAD — needs confirmation (thread states only that the dead set was inspected).
- Result: 112 jobs in dead set, all Redis::TimeoutError from around 13:58.
- Verification: Dead set listing per M03.
- Rollback: N/A — read-only.

**Step 4 — Pause enqueue (stop the bleed)**
- Who: Farid Osman (M04, 14:08:45Z)
- Command: `bin/rails runner 'FeatureFlag.disable(:auto_recognition_enqueue)'`
- Verification: NOT STATED in thread for this step — needs confirmation. (M07 later shows the queue falling, but that also follows Step 6.)
- Rollback (stated in M04): `bin/rails runner 'FeatureFlag.enable(:auto_recognition_enqueue)'`

**Step 5 — Clear the dead set**
- Who: Elena Sinclair (M05, 14:15:20Z)
- Command: NOT SPECIFIED IN THREAD — "in the console I cleared out the dead set" — exact console command needs confirmation.
- Verification: NOT STATED in thread — needs confirmation.
- Rollback: NOT PROVIDED in thread — needs confirmation (dead jobs were deleted; no restore path documented in the thread).

**Step 6 — Scale workers up**
- Who: Bryce Harmon (M06, 14:21:07Z)
- Command: `kubectl scale deployment/reward-worker --replicas=6` (was 3).
- Verification: NOT ISOLATED for this step in the thread. Closest stated effect: M07 (14:33:41Z, Farid Osman) — queue depth 9,400 and falling ~1,200/min. Direct verification needs confirmation.
- Rollback (stated in M06): `kubectl scale deployment/reward-worker --replicas=3`

**Step 7 — Monitor drain**
- Who: Farid Osman (M07, 14:33:41Z)
- Command: NOT SPECIFIED IN THREAD — needs confirmation (presumed the Step 2 rake task, but the thread does not say).
- Result: Queue depth 9,400, falling ~1,200/min.
- Rollback: N/A — read-only.

**Step 8 — Verify queue drained**
- Who: Cole Ingram (M08, 14:47:55Z)
- Command: `bundle exec rake sidekiq:queue_depth` → 0. Datadog error rate back to baseline.
- Verification: Command returned 0; Datadog error rate at baseline (both stated in M08).
- Rollback: N/A — read-only.

**Step 9 — Re-enable enqueue**
- Who: Bryce Harmon (M09, 14:49:10Z)
- Command: `bin/rails runner 'FeatureFlag.enable(:auto_recognition_enqueue)'`
- Verification (stated in M09): 40 new jobs processed cleanly in the next 3 minutes. (The observation method — which command/dashboard — is not stated; needs confirmation.)
- Rollback: `bin/rails runner 'FeatureFlag.disable(:auto_recognition_enqueue)'` — not labeled as such in M09, but this is the inverse command documented in M04.

**Step 10 — Scale workers back down, close**
- Who: Bryce Harmon (M10, 14:55:00Z)
- Command: `kubectl scale deployment/reward-worker --replicas=3`
- Verification (stated in M10): Queue stable at 0. Incident resolved. (The measurement command is not stated; needs confirmation.)
- Rollback: `kubectl scale deployment/reward-worker --replicas=6` — the inverse of the Step 6 command as documented in M06.

---

Gaps to confirm before this runbook is reusable:
1. Step 3: exact command used to inspect the dead set (M03).
2. Step 4: explicit verification that enqueue actually stopped (M04).
3. Step 5: exact console command for the dead-set clear, its verification, and any rollback/restore path (M05).
4. Step 7: the command used to observe the drain rate (M07).
5. Step 9: how "40 new jobs processed cleanly" was observed (M09).
6. Step 10: how "queue stable at 0" was measured (M10).

SEQUENCE OF FAILURE
===================

FIRST ERROR
- 2026-09-03T14:01:12Z, service `reward-service`, level ERROR:
  "Redis::TimeoutError: Connection to Redis at redis-primary:6379 timed out after 5s"
- This is the first non-INFO line in the slice. Every line before 14:01:12Z is INFO (health check ok / cache hit / request completed / job enqueued). Nothing in `reward-service` was failing before this.

CASCADE, IN ORDER (all ERROR/WARN events, 19 ERROR + 1 WARN = 20 non-INFO lines)
1. 14:01:12  reward-service  ERROR  Redis::TimeoutError — Connection to redis-primary:6379 timed out after 5s   [ROOT / first]
2. 14:01:20  reward-service  ERROR  Redis::TimeoutError — retry exhausted for RewardGiveJob
3. 14:01:30  reward-service  ERROR  Redis::TimeoutError — retry exhausted for RewardGiveJob
4. 14:01:40  reward-service  ERROR  Redis::TimeoutError — retry exhausted for RewardGiveJob
5. 14:01:40  sidekiq         ERROR  RewardGiveJob failed: Redis::TimeoutError; retrying in 60s
6. 14:02:28  sidekiq         ERROR  RewardGiveJob failed: Redis::TimeoutError; retrying
7. 14:02:30  sidekiq         WARN   Queue reward depth above 10,000
8. 14:03:05  api-gateway     ERROR  502 upstream timeout calling reward-service /gives
9. 14:03:30  web-app         ERROR  Give form submission failed: upstream 502 from api-gateway
10. 14:03:31 sidekiq         ERROR  RewardGiveJob failed: Redis::TimeoutError; retrying
11. 14:03:48 api-gateway     ERROR  502 upstream timeout calling reward-service
12. 14:04:13 api-gateway     ERROR  502 upstream timeout calling reward-service
13. 14:04:22 sidekiq         ERROR  RewardGiveJob failed: Redis::TimeoutError; retrying
14. 14:04:45 web-app         ERROR  Give form submission failed: upstream 502
15. 14:05:16 api-gateway     ERROR  502 upstream timeout calling reward-service
16. 14:05:26 sidekiq         ERROR  RewardGiveJob failed: Redis::TimeoutError; retrying
17. 14:05:42 web-app         ERROR  Give form submission failed: upstream 502
18. 14:06:47 sidekiq         ERROR  RewardGiveJob failed: Redis::TimeoutError; retrying
19. 14:06:49 web-app         ERROR  Give form submission failed: upstream 502
20. 14:06:52 api-gateway     ERROR  502 upstream timeout calling reward-service

Propagation pattern: redis-primary:6379 stops responding → reward-service (direct consumer) times out and exhausts retries → sidekiq `RewardGiveJob` workers fail and retry, queue "reward" depth balloons above 10,000 (jobs can't be drained) → api-gateway's synchronous calls to `reward-service /gives` time out with 502 → web-app surfaces user-facing "Give form submission failed".

Recovery (INFO):
- 14:22:10 reward-service  INFO  "Redis connection restored; resuming job processing"
- 14:24:45 sidekiq         INFO  "Queue reward depth below 500"

SERVICES INVOLVED
- redis-primary (host redis-primary:6379) — the failing dependency (referenced only as a target; no logs of its own in the slice)
- reward-service — first to error (data/Redis consumer)
- sidekiq — job worker / queue
- api-gateway — synchronous call path, emits 502s
- web-app — user-facing layer
- postgres — NOT implicated; only "checkpoint complete" INFO lines during the window

JOBS INVOLVED (from sidekiq_jobs.csv) — all error = Redis::TimeoutError
- RewardGiveJob:  J-00001 … J-00012 = 12 jobs
- RecognitionDigestJob: J-00013 … J-00016 = 4 jobs
- Total failed = 12 + 4 = 16 jobs
- failed_at span: 14:01:46 (J-00005) → 14:05:50 (J-00016)
- Note: RecognitionDigestJob (4 jobs) appears only in sidekiq_jobs.csv; it is never named in the datadog log slice, which names only RewardGiveJob.

ARITHMETIC
- Failed jobs: 12 (RewardGiveJob) + 4 (RecognitionDigestJob) = 16
- Non-INFO log lines: reward-service ERROR 4 + sidekiq ERROR 6 + api-gateway ERROR 5 + web-app ERROR 4 = 19 ERROR; +1 sidekiq WARN = 20
- api-gateway 502 lines = 5; web-app form-fail lines = 4; sidekiq "failed/retrying" lines = 6
- Root-to-recovery: 14:01:12 → 14:22:10 = 20 min 58 s = 1,258 s
  (14:01:12 + 20 min = 14:21:12; +58 s = 14:22:10)
- Last 502 (14:06:52) → Redis restored (14:22:10) = 15 min 18 s = 918 s
- Queue "reward" depth: >10,000 at 14:02:30 → <500 at 14:24:45 (drain window 22 min 15 s = 1,335 s)

DATADOG QUERY (Log Explorer) to confirm the first error
Primary (exact match, confirms the 14:01:12Z event):
  service:reward-service status:ERROR "Connection to Redis at redis-primary:6379 timed out after 5s"
  - Set time picker to 2026-09-03 14:01:00Z → 14:02:00Z, sort ascending; the matched row is the 14:01:12Z line (earliest in window).
Broader fallback (all Redis timeouts on the service):
  service:reward-service status:ERROR "Redis::TimeoutError"

WHAT THE LOGS DO NOT SHOW
- Root cause of the Redis failure. No log line explains why redis-primary:6379 timed out — no Redis-side logs, no memory/CPU/disk/network metrics, no restart/failover/OOM/replication event. "timed out after 5s" is a symptom, not a cause.
- No logs from the redis-primary service itself; it appears only as a target host in the error text.
- The recovery mechanism. 14:22:10 "Redis connection restored" is asserted, not explained — no operator action, failover, or restart is logged.
- No user/business impact quantification. No count of affected users, no reward dollar amounts, no recipient IDs, no Give transaction values, no revenue/ARR impact. The 4 web-app "Give form submission failed" lines are events only, with no $ value or aggregate.
- No data-integrity confirmation. No success/completion logs for the retried jobs; "resuming job processing" and "queue depth below 500" do not confirm all 16 failed jobs re-ran successfully, nor rule out dropped or double-issued rewards.
- No job_id ↔ log-line linkage. The sidekiq "failed…retrying" log lines carry no job_id, so the 16 job_ids (J-00001…J-00016) cannot be tied to specific log events.
- RecognitionDigestJob is absent from the log slice entirely; only sidekiq_jobs.csv reveals those 4 failures (J-00013…J-00016).
- A quiet gap. Last ERROR is 14:06:52Z; the next non-postgres line is 14:22:10Z, with only postgres "checkpoint complete" INFO lines in between. The data does not confirm job failures actually stopped after 14:06:52Z — it is simply the last ERROR in the slice, not a logged "all clear."
- No metrics/monitor/SLO context (no alert thresholds, error-rate curves, SLA breach). This is a logs-only slice.
- No deal or company aliases exist in this dataset; the only identifiers are the service names, job classes, the host redis-primary:6379, the endpoint /gives, and job_ids J-00001…J-00016, cited above exactly as given.

FLAG SUMMARY — 9 flags in the export (5 on, 4 off). The export gives segment labels and counts, not named companies, so company membership is reported only at the segment/count level.

1) recognition_streaks_v2 — ON
   Code: app/models/recognition.rb — when enabled, StreakTracker.record(give) is called on a give.
   Target: segment:beta_companies — 42 companies.

2) points_budget_guardrails — ON
   Code: app/services/budget_service.rb — when enabled, BudgetService.new(company).enforce!(giver, points) runs, enforcing point-budget limits.
   Target: all_companies — 220 companies.

3) slack_dm_nudges — ON
   Code: app/jobs/nudge_job.rb — the job returns early unless enabled; when enabled, SlackDm.send_nudge(user) fires.
   Target: segment:region_na — 87 companies.

4) redeem_flow_redesign — OFF
   Code: app/controllers/redeem_controller.rb — renders RedeemV2Component when enabled, RedeemV1Component otherwise (redeem flow A/B switch).
   Target: targeted_list — 12 companies; the export does not enumerate the list members, so I can't name them.

5) analytics_dashboard_v3 — ON
   Code: app/controllers/analytics_controller.rb — when enabled, @dashboard = AnalyticsV3.new(company) is built for the company.
   Target: segment:tier_three — 65 companies.

6) ms_teams_app_v2 — OFF
   Code: app/services/teams_installer.rb — when enabled, TeamsAppV2.install(company) runs.
   Target: targeted_list — 9 companies; the export does not enumerate the list members.

7) legacy_give_modal — OFF
   Code: NO reference in the provided excerpt — cannot state what it controls from the data given.
   Target: segment:legacy_plan — 14 companies.

8) survey_boosters_q3 — ON
   Code: NO reference in the provided excerpt — cannot state what it controls from the data given.
   Target: segment:legacy_plan — 7 companies.

9) paused_offboard_cleanup — OFF
   Code: NO reference in the provided excerpt.
   Target: none — targeting_rules is blank in the export and company_count is 0.

Flags turned ON and their targets:
- recognition_streaks_v2 → segment:beta_companies (42)
- points_budget_guardrails → all companies (220)
- slack_dm_nudges → segment:region_na (87)
- analytics_dashboard_v3 → segment:tier_three (65)
- survey_boosters_q3 → segment:legacy_plan (7) [no code reference]

Flag with no code reference: legacy_give_modal, survey_boosters_q3, paused_offboard_cleanup (3 of 9).
Flag with no targets: paused_offboard_cleanup (blank targeting_rules, 0 companies). redeem_flow_redesign and ms_teams_app_v2 do have targeting (targeted_list, 12 and 9 companies respectively), but the export does not name the specific companies in those lists.

Arithmetic check — total companies across the export: 42 + 220 + 87 + 12 + 65 + 9 + 14 + 7 + 0 = 456.

NDA-1 — [PARTY A] / Bonusly: GREEN
Driver: standard mutual structure with full carve-out set and reasonable terms. Carve-outs include all five standard exceptions — "(a) is or becomes publicly available through no breach, (b) was known prior to disclosure, (c) is received from a third party without duty of confidence, (d) is independently developed, or (e) must be disclosed by law or court order." Term is two (2) years with three (3) years survival, governing law Delaware, "No license, no obligation to proceed, no exclusivity." No embedded covenants, no missing carve-outs, no unusual law. Standard approval.

NDA-2 — [PARTY B] / Bonusly: YELLOW
Driver: embedded non-solicitation in an otherwise standard mutual NDA. Clause 4: "During the term of this Agreement and for eighteen (18) months thereafter, neither party shall solicit for employment or hire any employee of the other party with whom it came into contact under this Agreement." The rest is conventional (3-year term, standard carve-outs, Delaware law), but a hiring-restriction covenant that survives 18 months past the term is an employment-law issue the NDA team should not sign off unilaterally. Counsel review to confirm scope ("came into contact under this Agreement") and whether the 18-month tail is acceptable.

NDA-3 — [PARTY C] / Bonusly: RED
Driver: a three-year non-compete buried in an NDA, plus no carve-outs and foreign governing law. Clause 2: "For a period of three (3) years following the Effective Date, Recipient shall not, directly or indirectly, engage in or provide services to any business that competes with Discloser's business." Three aggravating factors: (1) the non-compete is one-way against Bonusly (Recipient) for 3 years and is broadly drafted with no scope limits, territory, or "with whom it came into contact" qualifier; (2) "No confidentiality carve-outs are stated in this Agreement" — missing all standard exceptions, meaning public information and compelled disclosure carry no exception; (3) governing law is "the laws of the Republic of Ireland, and the parties submit to the exclusive jurisdiction of its courts" — unusual and costly for a US-based counterparty. Full legal review before any signature.

Summary: NDA-1 GREEN / NDA-2 YELLOW / NDA-3 RED.