z-ai/glm-5.3-prime

DEFINITIONS (as applied)
- DS2+ deal: current stage is DS2, DS3, DS4, or DS5. Population = 124 of 156 deals (39 DS2, 61 DS3, 14 DS4, 10 DS5).
- Compliant why-buys: value is non-empty, 15+ characters, and not a placeholder (tbd / n/a / see notes); LONG(n) counts as present and substantive per the rule. Non-compliant = blank, placeholder, or <15 chars.
- No DS1 timestamp: t_ds1 is blank.
- Regressed: some pair of present stage timestamps with an earlier stage dated later than a later stage (t_ds_i > t_ds_j for i < j).

RESULTS

1) Why-buys non-compliance, DS2+ deals: 101/124 = 81.45% (≈81.5%).
Of the 124 DS2+ deals, 23 carry LONG(n) values and 101 are blank — none contain placeholder text, so all non-compliance is missing values, not junk values.

By owner (non-compliant / DS2+ deals):
- Alex Franklin (84342457): 48/61 = 78.7%
- Dana Mercer (83155923): 18/22 = 81.8%
- Bryce Harmon (119337721): 15/18 = 83.3%
- Cole Ingram (83155924): 19/22 = 86.4%
- Farid Osman (716654662): 1/1 = 100.0%

Check: 48 + 18 + 15 + 19 + 1 = 101; 61 + 22 + 18 + 22 + 1 = 124.

2) Deals with no DS1 timestamp: 1 — Deal-57FF13 (Elena Sinclair, DS1). Caveat: that row is malformed in the file (17 fields instead of 18; last_contacted_field and source are truncated), and t_ds1 is blank, so it is counted as missing. All 124 DS2+ deals have a DS1 timestamp.

3) Regressed deals: 0 of 156. Every pair of present stage timestamps is chronologically in order for all deals.

4) Related data gap (not a rule violation): all 10 DS5-stage deals have blank t_ds5 — the current-stage date exists only in entered_current_stage. Missing ≠ out of order, so this triggers no regression count, but it means DS5 entry timing is not auditable from the t_ds columns.

THREE PROCESS FIXES
1. Gate stage entry: block or flag the move into DS2 until why_buys is populated with 15+ substantive characters. This attacks the 81.5% gap at the source, since the problem is entirely blank fields at DS2 and beyond.
2. Weekly hygiene exception report per owner listing (a) DS2+ deals with blank why_buys — prioritized for COMMIT deals (e.g., Deal-499BF6 sits at DS2/COMMIT with no why-buys) — and (b) deals missing any stage entry timestamp. All five owners are above 78% non-compliant, so this is a team-wide process gap, not an individual one.
3. Backfill and enforce stage timestamps at write time: auto-populate t_ds1–t_ds5 from stage-transition history (including t_ds5, currently empty for every DS5 deal), and validate chronological ordering on every stage change so gaps and regressions are caught in the CRM rather than at audit time.

All 156 open deals resolved — every owner_id in deals_open.csv matched a row in owners.csv. No names were guessed.

DEALS RESOLVED: 156 of 156

UNMATCHED OWNER IDS: none. Every owner_id present in the deal file (119337721, 84342457, 83155923, 83155924, 716654662, 701163055) has a match in owners.csv.

ARCHIVED/DEACTIVATED OWNERS WITH DEALS: none. The two archived owners in owners.csv (Gavin Porter, id 1520255671; Hugo Lindqvist, id 77260721) have zero open deals. All six owners with open pipeline are archived=false.

PIPELINE PER RESOLVED OWNER (sum of amount for that owner's deals):

Bryce Harmon (119337721): 35 deals, 1,054,144.00
  e.g. 240,000 (Deal-2D1F1B) + 99,000 (Deal-66D1FC) + 72,000 (Deal-C6FE92) + 70,000 (Deal-950043) + 63,600 (Deal-D73B89) + 45,000 (Deal-B23205) + 37,440 (Deal-7BBDFA) + ... 35 deals total.

Alex Franklin (84342457): 67 deals, 624,310.00
  e.g. 62,000 (Deal-EC3025) + 60,000 (Deal-92D97D) + 31,200 (Deal-530B50) + 24,000 (Deal-CC08D1) + 19,000 (Deal-60C2C2) + ... 67 deals total.

Dana Mercer (83155923): 24 deals, 341,195.00
  e.g. 43,875 (Deal-E51FB7) + 27,000 (Deal-B42F46) + 25,000 (Deal-F9A3C1) + 23,400 (Deal-BA3DDC) + 20,000 (Deal-9DDE86) + 18,900 (Deal-215CCA) + ... 24 deals total.

Cole Ingram (83155924): 22 deals, 288,161.43
  58,529.25 (Deal-D04904) + 40,000 (Deal-B25F40) + 32,175 (Deal-813836) + 31,750 (Deal-1BA595) + 18,900 (Deal-99A240) + 12,168 (Deal-CD47A6) + ... 22 deals total.

Farid Osman (716654662): 7 deals, 4,134.00
  2,880 (Deal-8BA24E) + 1,249 (Deal-499BF6) + 5 x 1 (Deals-03BA69/117863/F17780/2B39B0/8FDCD2) = 4,134.00

Elena Sinclair (701163055): 1 deal, 2,100.00
  Deal-57FF13 = 2,100.00

Arithmetic 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 amount across all 156 rows.

All checks computed against the two CSVs exactly as provided (join on hs_deal_id → deal_id; gong_owner_id not used, per note). No data was missing for these calculations.

(a) Orphaned gong rows (deal id absent from deals_open): 30 of 67
- Arithmetic: 67 gong rows total; 37 ids match deals_open; 67 − 37 = 30 orphans (30/67 = 44.8%).
- Sample orphan aliases: Deal-8FA85D (60251290957), Deal-8FC3F9 (60251649055), Deal-3B7945 (60251639682), Deal-B038F0 (54322940958), Deal-AC944F (63327490589).

(b) Duplicate conversation keys: 0
- Checked all 67 rows for calls_90d > distinct_conversation_keys; in every row the two values are equal, so no row shows duplicate conversation keys.

(c) Share of open deals at DS3 or later with at least one logged call: 25/85 = 29.4%
- Arithmetic: stage counts in deals_open: DS3 = 61, DS4 = 14, DS5 = 10 → 61 + 14 + 10 = 85 open deals at DS3+.
- Of those 85, 25 have a row in the gong table (every gong row has calls_90d ≥ 3, so all 25 have at least one call; the 60 DS3+ deals without a gong row have zero logged calls in this table).
- Share: 25 ÷ 85 = 0.294 → 29.4%.

Verification notes: totals cross-checked row-by-row (37 matched gong ids split into 25 at DS3+ vs 12 at DS1/DS2, which reconciles 25 + 12 = 37); no duplicate deal ids within either file (67 unique gong ids, 156 unique open ids).

```sql
-- ============================================================================
-- Per customer company, for its first calendar month as a customer:
--   unique_givers, recognition_count, successful_redemption_count.
--
-- Source choices and definitions (catalog-documented only):
-- * Customer company = self-serve company in PRODUCTION.PLG.COMPANY_COHORT_SUMMARY with a
--   non-null FIRST_SUB_PAYMENT_DATE (first subscription payment = became a customer).
--   Sales-sourced customers (HubSpot closed-won deals) and Chargebee-only subscriptions have
--   NO documented per-company giving data in this catalog -- that data is missing, so those
--   companies cannot be included.
-- * First calendar month as a customer = DATE_TRUNC('month', FIRST_SUB_PAYMENT_DATE),
--   the calendar month containing the first subscription payment.
-- * unique_givers = M1_USERS. The catalog documents only M1_USERS ("users", month 1) and no
--   event-level giver table, so a strict unique-giver count is not available; M1_USERS is the
--   closest documented measure and may include users who never gave.
--   NO deleted-giver exclusion is applied anywhere: the documented business rule states that
--   filter must NOT be applied to historical giving counts (it understates history), and no
--   giver-level table is documented here from which such a filter could even be built.
-- * recognition_count = M1_GIVES, the only documented recognition (giving) count.
-- * successful_redemption_count = COUNT(*) of REDEMPTION_RECORDS_V2 rows with
--   STATE = 'succeeded' in the company's first calendar month. Per the catalog, only
--   STATE = 'succeeded' rows count as redemptions, and this table -- despite its DEPRECATED
--   schema name -- is the documented source for redemption counts. M1_REDEMPTIONS is NOT
--   used because the catalog does not document whether it applies the STATE filter.
--
-- Columns NOT documented in the catalog excerpt (assumed, verify before running):
--   COMPANY_ID on both COMPANY_COHORT_SUMMARY and REDEMPTION_RECORDS_V2 (no company/join
--   key is documented for either table) and CREATED_AT as the redemption event timestamp
--   (following the CREATED_AT convention documented on HS_ENGAGEMENTS_ENRICHED).
--   The M1 window definition is also undocumented; it is assumed to equal the calendar month
--   of FIRST_SUB_PAYMENT_DATE. If M1 is a rolling window instead, unique_givers and
--   recognition_count cover a slightly different window than successful_redemption_count.
-- ============================================================================

WITH company_first_month AS (
    SELECT
        COMPANY_ID                                  AS company_id,           -- assumed key, see header
        DATE_TRUNC('month', FIRST_SUB_PAYMENT_DATE) AS first_customer_month,  -- month of first payment
        M1_USERS                                    AS m1_users,              -- month-1 users (giver proxy)
        M1_GIVES                                    AS m1_gives               -- month-1 recognitions
    -- PRODUCTION.PLG.COMPANY_COHORT_SUMMARY: the only catalog table with per-company,
    -- first-month (M1) giving metrics (M1_USERS, M1_GIVES) and a documented customer-start
    -- date (FIRST_SUB_PAYMENT_DATE); one row per self-serve company. Avoided per catalog
    -- notes: HUBSPOT_HUB_1973303.V2_LIVE.OBJECTS_DEALS (unpopulated),
    -- PRODUCTION.HUBSPOT.DEALS (stale, last sync 2023-03), and
    -- PRODUCTION.HUBSPOT.GONG_HUBSPOT_MAP_FAST (retired) -- none document giving data.
    -- PRODUCTION.CHARGEBEE.SUBSCRIPTIONS is also not used: CURRENT_TERM_START is the
    -- CURRENT term (not the first), and it carries no giving data.
    FROM PRODUCTION.PLG.COMPANY_COHORT_SUMMARY
    -- No first subscription payment => not yet a customer => no first calendar month.
    WHERE FIRST_SUB_PAYMENT_DATE IS NOT NULL
),

redemptions_first_month AS (
    SELECT
        COMPANY_ID                       AS company_id,       -- assumed key, see header
        DATE_TRUNC('month', CREATED_AT)  AS redemption_month,  -- assumed event timestamp
        COUNT(*)                         AS successful_redemptions
    -- PRODUCTION.DEPRECATED_RECOGNITION.REDEMPTION_RECORDS_V2: redemption events; the
    -- catalog designates it the documented source for redemption counts despite the
    -- DEPRECATED schema name, so it is used here.
    FROM PRODUCTION.DEPRECATED_RECOGNITION.REDEMPTION_RECORDS_V2
    -- Documented rule: only STATE = 'succeeded' rows count as redemptions; every other
    -- state is excluded so the count reflects successful redemptions only.
    WHERE STATE = 'succeeded'
    GROUP BY COMPANY_ID, DATE_TRUNC('month', CREATED_AT)
)

SELECT
    c.company_id                          AS customer_company,
    c.first_customer_month                AS first_calendar_month_as_customer,
    c.m1_users                            AS unique_givers,
    c.m1_gives                            AS recognition_count,
    COALESCE(r.successful_redemptions, 0) AS successful_redemption_count
-- LEFT JOIN (not INNER) so companies with zero successful redemptions in their first
-- calendar month still return one row. Arithmetic: successful_redemption_count =
-- COUNT(*) over rows with STATE = 'succeeded' whose event month
-- (DATE_TRUNC('month', CREATED_AT)) equals the company's first calendar month
-- (DATE_TRUNC('month', FIRST_SUB_PAYMENT_DATE)); COALESCE(..., 0) when no such rows exist.
FROM company_first_month c
LEFT JOIN redemptions_first_month r
    ON  r.company_id       = c.company_id
    AND r.redemption_month = c.first_customer_month
;
```

AUDIT REPORT — CRM EXTRACT (companies.csv: 34 rows; contacts.csv: 52 rows; zoominfo_enrichment.csv: 25 rows)

══════════════════════════════════════
1. MISSING DATA DECLARATION
══════════════════════════════════════
No deals file was provided. Deal fields (owner, stage, amount, close date, why-buys) cannot be audited — completeness unknown, not zero. Consequence: "pipeline amount at stake" cannot be computed in dollars for any fix. The top-10 list at the end is ranked by records affected and blocking impact, with that limitation stated.

══════════════════════════════════════
2. COMPLETENESS PER FIELD
══════════════════════════════════════
COMPANIES (34 rows)
- domain: 34/34 = 100.0%
- industry: 34/34 = 100.0% (populated, but 14 raw spellings collapse to 6 values — see §3)
- employee_count: 25/34 = 73.5% — missing 9: C-EC3025, C-96039F, C-44EA29, C-D04904, C-B23205, C-60C75F, C-7BBDFA, C-50D386, C-93C8BF
- hq_country: 28/34 = 82.4% — missing 6: C-2D1F1B, C-D73B89, C-44EA29, C-D04904, C-2C60E5, C-EE9FFB

CONTACTS (52 rows)
- email: populated 52/52 = 100.0%; structurally valid 48/52 = 92.3% (4 malformed — see §5)
- title: 39/52 = 75.0% — missing 13: CT-0000, CT-0022, CT-0072, CT-0080, CT-0081, CT-0092, CT-0120, CT-0121, CT-0122, CT-0132, CT-0141, CT-0162, CT-0170
- persona: 37/52 = 71.2% — missing 15: CT-0000, CT-0022, CT-0041, CT-0060, CT-0070, CT-0081, CT-0082, CT-0092, CT-0110, CT-0132, CT-0162, CT-0171, CT-0172, CT-0180, CT-0181
- title+persona combined: 22 contacts missing at least one (13+15=28 cells, 6 contacts missing both: CT-0000, CT-0022, CT-0081, CT-0092, CT-0132, CT-0162)
- company_alias FK: 52/52 resolve to a company row — 0 orphans

DEALS (owner, stage, amount, close date, why-buys): not computable — no file provided.

COVERAGE GAP (not a field): 14 of 34 companies have zero contacts: C-2C60E5, C-B97B4E, C-2D7423, C-7BBDFA, C-50D386, C-BA969B, C-332637, C-93C8BF, C-EE9FFB, C-C9BB20, C-0A092931, C-0A092932, C-0A092933, C-0A092934.

══════════════════════════════════════
3. VALUE CONSISTENCY (populated but non-canonical)
══════════════════════════════════════
Industry — 14 raw values collapse to 6: Technology 9 + tech 4 + "Tech " 4 = 17; Healthcare 4 + "health care" 2 = 6; Retail 5; Manufacturing 3; Finance 2; SaaS 1 (17+6+5+3+2+1 = 34 ✓). 10 rows carry variant spellings (4 "tech", 4 "Tech ", 2 "health care").
hq_country — US 9 + USA 6 + United States 2 = 17 rows needing one canonical; Canada 8; UK 3; blank 6 (17+8+3+6 = 34 ✓). Zero factual conflicts after normalization.

══════════════════════════════════════
4. DUPLICATE COMPANY CLUSTERS
══════════════════════════════════════
Company "name" is an opaque alias, so name-variant detection reduces to shared domain. 32 unique domains across 34 rows → 2 clusters:

CLUSTER 1 — domain acme-corp.com (no contacts attached)
- C-0A092931: Technology, 500, US
- C-0A092932: tech, 510, USA
- SURVIVOR: C-0A092931 (first-created, canonical industry spelling). Fold C-0A092932 in and delete.
- Unresolved within cluster: 500 vs 510 employee_count — acme-corp.com has no ZoomInfo row, so no tiebreaker in the provided data. Keep 500 on the survivor pending manual verification; do not pick 510 by assumption.

CLUSTER 2 — domain globex.io (no contacts attached)
- C-0A092933: SaaS, 200, US
- C-0A092934: Technology, 200, US
- SURVIVOR: C-0A092933 (first-created). Fold C-0A092934 in and delete.
- Unresolved within cluster: industry SaaS vs Technology — no ZoomInfo row for globex.io. Retain both values on the merge record until confirmed; recommend the more specific "SaaS" only if the team's picklist has it.

LOOKALIKE, NOT A DUPLICATE: C-7BBDFA (7bbdfa.com) and C-50D386 (50d386.com) share industry "health care", blank employee_count, Canada, and identical ZoomInfo values (400, Canada) — but have distinct domains and distinct aliases. No evidence in the data they are one company; do not merge without confirmation.

══════════════════════════════════════
5. INVALID EMAILS & DOMAIN MISMATCHES
══════════════════════════════════════
Malformed (no domain — 4):
- CT-0010 (C-66D1FC): user0@
- CT-0080 (C-92D97D): user0@
- CT-0081 (C-92D97D): user1@
- CT-0192 (C-425E2A): user2@
Note: 48 valid emails all follow the pattern userN@<company domain>; these 4 look like truncated entry of the same pattern. That is an observation, not a value — verify before writing anything; no email may be reconstructed as fact from this extract.

Domain mismatch (valid email, wrong domain — 1):
- CT-0011 (C-66D1FC): user1@other-domain.com vs contact row domain 66d1fc.com and company domain 66d1fc.com.
All other 47 valid emails match both their row domain and their company's domain.

══════════════════════════════════════
6. ENRICHMENT JOIN (by domain) — fills, conflicts, recommendation
══════════════════════════════════════
Join coverage: 25 of 34 company rows match a ZoomInfo row (73.5%); 25 of 32 unique domains covered. No ZI row for: ba969b.com, 332637.com, 93c8bf.com, ee9ffb.com, c9bb20.com, acme-corp.com, globex.io.

FILLS — CRM blank, ZI populated (8, all employee_count = 400; verified no industry or hq_country fills are possible):
- C-EC3025, C-96039F, C-44EA29, C-D04904, C-B23205, C-60C75F, C-7BBDFA, C-50D386
Effect: employee_count 25/34 (73.5%) → 33/34 (97.1%). Sole remaining blank: C-93C8BF (93c8bf.com, no ZI row — no source in provided data).
hq_country: 0 fills. Every CRM-blank case is also ZI-blank (2d1f1b.com, d73b89.com, 44ea29.com, d04904.com, 2c60e5.com) or has no ZI row (ee9ffb.com). hq_country stays 28/34 = 82.4%.

CONFLICTS — both populated, values differ (10, all industry; 0 on employee_count across 17 both-populated rows; 0 on hq_country across 20 both-populated rows after US/USA/United States normalization):
- C-66D1FC: tech vs Computer Software
- C-EC3025: Technology vs Computer Software
- C-44EA29: tech vs Computer Software
- C-92D97D: Technology vs Computer Software
- C-D04904: Technology vs Computer Software
- C-77A95A: Technology vs Computer Software
- C-AA8DDA: Technology vs Computer Software
- C-B25F40: Technology vs Computer Software
- C-60C75F: tech vs Computer Software
- C-425E2A: "Tech " vs Computer Software

RECOMMENDED SOURCE: ZoomInfo for these 10 — it is internally consistent across all software rows and more granular ("Computer Software" vs a generic "Technology"), while CRM's industry column is demonstrably ungoverned (14 spellings, 6 values). Caveats stated, not invented: (a) if the CRM picklist standard is "Technology", map Computer Software → Technology instead — the fix is adopting ONE taxonomy, not picking per row; (b) ZI itself uses "health care" (lowercase) on 7bbdfa.com and 50d386.com, so ZI is not uniformly clean either; (c) 9 companies have no ZI row, so CRM values + normalization remain the fallback there. Where both files agree (all 17 employee counts, all 20 countries), either source validates the other — no action needed beyond spelling normalization.

══════════════════════════════════════
7. TOP 10 FIXES — RANKED BY AMOUNT AT STAKE
══════════════════════════════════════
Caveat repeated: no deals extract exists, so dollar amounts at stake cannot be computed for any fix. Ranking below is by records affected and blocking impact. Every dollar figure becomes computable only after fix #1.

1. Obtain the deals extract. The audit's own target fields (owner, stage, amount, close date, why-buys) are 100% unauditable, and no fix can be dollar-ranked without it. Blocks everything downstream.
2. Merge duplicate cluster acme-corp.com: survivor C-0A092931, fold C-0A092932. Resolve 500 vs 510 manually (no ZI tiebreaker). Any deals hanging off the secondary alias would miscount pipeline until merged — unmeasurable today.
3. Merge duplicate cluster globex.io: survivor C-0A092933, fold C-0A092934. Same pipeline double-count risk; resolve SaaS vs Technology on the merged record.
4. Fill 8 employee_count values from ZI (C-EC3025, C-96039F, C-44EA29, C-D04904, C-B23205, C-60C75F, C-7BBDFA, C-50D386 = 400). Largest single completeness gain: 73.5% → 97.1%. 8 of 34 companies (23.5%).
5. Normalize industry taxonomy across all 34 rows (14 spellings → 6 canonical values; 10 variant rows) and adopt one source for the 10 CRM-vs-ZI conflicts. Affects every company record and any industry-based routing/reporting.
6. Normalize hq_country across 17 rows (US/USA/United States → one value). Affects half the file (17/34) and any territory assignment or rollup.
7. Fix 4 malformed emails (CT-0010, CT-0080, CT-0081, CT-0192) — 7.7% of contacts (4/52) currently unusable for sequencing. Verify actual addresses; do not synthesize from the observed pattern.
8. Resolve CT-0011 domain mismatch (user1@other-domain.com vs 66d1fc.com): personal vs corporate mailbox question — affects deliverability and correct company affiliation for 1 of 52 contacts (1.9%).
9. Backfill contact title (13 missing) and persona (15 missing; 28 cells, 22 contacts, 42.3% of the contact file missing at least one). No contact enrichment source was provided — this requires a new enrichment pull or sales follow-up; it cannot be fixed from the given files.
10. Fill hq_country for the 6 blank companies (C-2D1F1B, C-D73B89, C-44EA29, C-D04904, C-2C60E5, C-EE9FFB) and employee_count for C-93C8BF. Zero of these are fillable from the provided enrichment export (ZI blank or absent in every case) — a fresh enrichment run or manual entry is required; no values may be invented here.

Explicitly unfixable from provided data: 6 hq_countries, 1 employee count (C-93C8BF), 28 title/persona cells, all deal fields, and the two intra-cluster value conflicts (acme 500/510, globex SaaS/Technology).

```json
{
  "tier_counts": {
    "LOCK": 5,
    "ACTION": 37,
    "BUILD": 90,
    "REVIVE": 5,
    "WATCH": 14,
    "RISKY": 5
  },
  "tier_examples": {
    "LOCK": ["Deal-25F752", "Deal-D348E1", "Deal-C26D20"],
    "ACTION": ["Deal-C6FE92", "Deal-F9A3C1", "Deal-BA3DDC"],
    "BUILD": ["Deal-66D1FC", "Deal-D73B89", "Deal-EC3025"],
    "REVIVE": ["Deal-2D1F1B", "Deal-7BBDFA", "Deal-F0EBBB"],
    "WATCH": ["Deal-950043", "Deal-B23205", "Deal-332637"],
    "RISKY": ["Deal-547B2B", "Deal-B7EBD1", "Deal-A2B47C"]
  },
  "risky_deals": ["Deal-547B2B", "Deal-B7EBD1", "Deal-A2B47C", "Deal-2465CE", "Deal-FD9F4E"],
  "lock_violations": 0,
  "pipeline_shape": "Top-heavy on unproven upside: 90 of 156 deals (58%) sit in BUILD, 37 (24%) in ACTION, and only 5 (3.2%) qualify as LOCK — all five LOCK deals have >=1 meeting in 30d, so zero violations. 101 of 156 deals (65%) have zero meetings_30d, which caps the trustable pipeline at ~$70,770 in LOCK plus ~$341,626 in ACTION out of $2,314,044 total. The 11 COMMIT deals total ~$75,399, and 5 of them ($33,290, 44%) are tiered RISKY — DS5 with zero meetings and no or thin recent calls (e.g. Deal-547B2B, Deal-A2B47C, Deal-2465CE), meaning nearly half the committed forecast lacks meeting-level validation. The single largest deal, Deal-2D1F1B ($240,000, 10% of total pipeline), is REVIVE — stale since mid-June with no meetings, calls, or recent emails, joined there by Deal-7BBDFA ($37,440, BEST_CASE but silent since 2026-07-21). Data gaps: 2 of 156 deals (Deal-3EED2C, Deal-57FF13) have no engagement row (tiered WATCH by default), 8 deals carry $1 placeholder amounts that understate total value, inbound_emails_30d is 0 everywhere per the stated defect, and 2 close dates (Deal-333EBB, Deal-57FF13) already lag the 2026-09-04/05 snapshot implied by the engagement data."
}
```

Extraction notes (applies to all six):
- Source contains no company names — only deal aliases and speaker roles, cited exactly as given.
- Alex Franklin is the rep: excluded from stakeholders and never used as a source for any field.
- No arithmetic performed — every figure ($, %, dates, durations) is quoted verbatim from a prospect statement.
- Rep-sourced figures excluded per instructions (TX-003 "$8 per employee per month"; TX-006 "I can flex on pricing").

```json
[
  {
    "transcript_id": "TX-001",
    "deal_alias": "Deal-CFE7F4",
    "why_buys": [
      "'The big win for us would be automating anniversary and birthday awards' (Prospect (VP People))"
    ],
    "pain_points": [
      "HR team of three cannot keep up with manual anniversary and birthday awards (Prospect (VP People))",
      "Tracking in a spreadsheet — 'people slip through the cracks' (Prospect (HR Admin))"
    ],
    "stakeholders": ["Prospect (VP People)", "Prospect (HR Admin)"],
    "budget_signal": "About $40k earmarked for engagement tools this fiscal year (Prospect (VP People))",
    "timeline_signal": "'Ideally we would have this live before open enrollment in November' (Prospect (VP People))",
    "competitor_mentioned": "Achievers — 'We looked at Achievers last year, but it was too heavy for a team our size' (Prospect (VP People))",
    "next_step": "Security review on September 12 — agreed: 'Yes — let's do the security review on September 12' (Prospect (VP People))",
    "objections": [
      "'One concern: we need SSO and audit logs for IT to sign off' (Prospect (HR Admin))"
    ],
    "confidence": {
      "level": "high",
      "basis": "Prospect-stated budget, timeline, and dated agreed next step; sole objection is a named technical requirement, not stated reluctance"
    },
    "missing_data": []
  },
  {
    "transcript_id": "TX-002",
    "deal_alias": "Deal-70BB30",
    "why_buys": [
      "'We want to tie recognition to retention for our hourly workforce' (Prospect (Head of Total Rewards))"
    ],
    "pain_points": [
      "Regretted turnover in the hourly workforce is over 30% (Prospect (Head of Total Rewards))"
    ],
    "stakeholders": ["Prospect (Head of Total Rewards)", "Prospect (CFO)"],
    "budget_signal": "$25k pilot budget approved for this quarter (Prospect (CFO))",
    "timeline_signal": "'We want a decision by end of September' (Prospect (CFO))",
    "competitor_mentioned": null,
    "next_step": "Send pilot agreement; prospect routes it to legal this week — agreed: 'Yes — send the pilot agreement and we'll route it to legal this week' (Prospect (CFO))",
    "objections": [
      "'Integration with Workday has to be rock solid — that's my one condition' (Prospect (CFO))"
    ],
    "confidence": {
      "level": "high",
      "basis": "CFO-stated approved budget, decision deadline, and agreed next step; prospect states no other vendor demos to date"
    },
    "missing_data": ["No competitor raised — 'You're the first vendor we've had a real demo with' (Prospect (Head of Total Rewards))"]
  },
  {
    "transcript_id": "TX-003",
    "deal_alias": "Deal-530B50",
    "why_buys": [
      "'We need to make recognition visible across our 12 retail locations' (Prospect (People Ops Manager))"
    ],
    "pain_points": [
      "Store managers have zero budget autonomy for on-the-spot recognition (Prospect (People Ops Manager))"
    ],
    "stakeholders": ["Prospect (People Ops Manager)"],
    "budget_signal": null,
    "timeline_signal": "'Honestly there's no rush on our side until Q1' (Prospect (People Ops Manager))",
    "competitor_mentioned": "Bucketlist — 'My CEO used Bucketlist at her last company and liked it' (Prospect (People Ops Manager))",
    "next_step": "Schedule call with CEO; prospect to send two times — agreed: 'Yes, let's schedule a call with our CEO — I'll send two times' (Prospect (People Ops Manager))",
    "objections": [
      "'The CEO has to be sold first — she decides anything people-related' (Prospect (People Ops Manager))"
    ],
    "confidence": {
      "level": "medium",
      "basis": "Agreed next step and timeline stated, but no prospect-stated budget, CEO is the gatekeeper, and CEO has positive prior experience with Bucketlist"
    },
    "missing_data": ["No prospect-stated budget — rep's '$8 per employee per month' figure excluded (rep-stated)"]
  },
  {
    "transcript_id": "TX-004",
    "deal_alias": "Deal-180D02",
    "why_buys": [
      "'We want to consolidate three separate recognition tools into one' (Prospect (VP People))"
    ],
    "pain_points": [
      "'We're paying for three tools and none of them talk to our HRIS' (Prospect (VP People))"
    ],
    "stakeholders": ["Prospect (VP People)", "Prospect (IT Security Lead)"],
    "budget_signal": "Approval threshold only: 'If it's under $15k annually, I can approve it without going to the board' (Prospect (VP People)) — no allocated amount stated",
    "timeline_signal": "'Our procurement cycle runs six to eight weeks minimum' (Prospect (IT Security Lead)) — no decision or go-live date stated",
    "competitor_mentioned": null,
    "next_step": null,
    "objections": [
      "'The security review took three months for our last vendor — that's my hesitation' (Prospect (IT Security Lead))"
    ],
    "confidence": {
      "level": "low",
      "basis": "No agreed next step ('Maybe — I need to check her calendar, no promises'), 6-8 week procurement minimum, and security-review hesitation; only a budget threshold is stated"
    },
    "missing_data": [
      "No agreed next step — prospect said 'Maybe — I need to check her calendar, no promises'; rep's 'I'll follow up' excluded (rep-stated)",
      "No competitor raised by the prospect (the three existing recognition tools are unnamed)",
      "No target decision or go-live date"
    ]
  },
  {
    "transcript_id": "TX-005",
    "deal_alias": "Deal-F8767A",
    "why_buys": [
      "'Two things: automate service milestones, and give us analytics on recognition equity across departments' (Prospect (HR Director))"
    ],
    "pain_points": [
      "'Our night-shift teams feel invisible — their engagement scores run 20 points lower' (Prospect (People Ops Coordinator))"
    ],
    "stakeholders": ["Prospect (HR Director)", "Prospect (People Ops Coordinator)"],
    "budget_signal": "$12k approved under the engagement line (Prospect (HR Director))",
    "timeline_signal": "'We need this running before our January all-hands' (Prospect (HR Director))",
    "competitor_mentioned": "Nectar — 'We're mid-pilot with Nectar right now, so you'd need to beat that experience' (Prospect (HR Director))",
    "next_step": "Present to exec team on October 2 — agreed: 'Yes — come present to our exec team on October 2' (Prospect (HR Director))",
    "objections": [
      "Active competitor pilot: 'you'd need to beat that experience' (Prospect (HR Director))",
      "'Our exec team is skeptical after a failed rollout two years ago' (Prospect (HR Director))"
    ],
    "confidence": {
      "level": "medium",
      "basis": "Prospect-stated budget, timeline, and dated agreed next step, offset by an active Nectar pilot and a skeptical exec team"
    },
    "missing_data": []
  },
  {
    "transcript_id": "TX-006",
    "deal_alias": "Deal-EE195F",
    "why_buys": [
      "'I'd love to cut the admin time on service awards' (Prospect (HR Manager))"
    ],
    "pain_points": [
      "'I personally spend five hours a month ordering and shipping plaques' (Prospect (HR Manager))"
    ],
    "stakeholders": ["Prospect (HR Manager)"],
    "budget_signal": "No amount stated — 'Budget isn't the issue — time is' (Prospect (HR Manager))",
    "timeline_signal": "'Our fiscal year resets in February, so a Q1 start is realistic' (Prospect (HR Manager))",
    "competitor_mentioned": null,
    "next_step": "Send one-page overview; prospect forwards it to COO this week — agreed: 'Yes — send the one-page overview and I'll forward it to our COO this week' (Prospect (HR Manager))",
    "objections": [
      "'Fair warning, our COO usually prefers building things in-house' (Prospect (HR Manager))",
      "'We're comparing this against just doing it internally' (Prospect (HR Manager))"
    ],
    "confidence": {
      "level": "medium",
      "basis": "Quantified pain, agreed next step, and prospect-stated unconstrained budget, offset by COO's in-house preference and only one prospect stakeholder engaged"
    },
    "missing_data": [
      "No budget amount stated",
      "No competitor vendor raised — 'Nobody else — we're comparing this against just doing it internally' (internal build, not a named vendor)"
    ]
  }
]
```

Top 3, ranked by signature proximity. Combined: $11,200 + $9,000 + $6,360 = $26,560.

1. Deal-547B2B. $11,200. DS5/COMMIT, Alex Franklin, close date 2026-09-11.
Why close: Slack (Alex, 2026-09-04) says redlines came back clean, the signing page is out, and the buyer's VP People committed to signing "tomorrow." Explicitly called signature-imminent.
Left: only the executed signing page returning. No other open items appear in either source.

2. Deal-403845. $9,000. DS5/COMMIT, close date 2026-09-11.
Why close: Slack (Dana Mercer, 2026-09-04) says it is "moving fine" and the order form is with their finance team.
Left: finance signature/countersign on the order form. Note a data conflict: CRM lists Alex Franklin as owner, but Dana posted the status as "my side." Unresolved in provided data.

3. Deal-A2B47C. $6,360. DS5/COMMIT, Alex Franklin, close date 2026-09-11.
Why close: Slack (Alex, 2026-09-04) confirms it is "still warm, just normal legal-review pace." Among warm commits with no stronger signal, it has the nearest close date (2026-09-11 vs Deal-D348E1's 2026-10-15, a 34-day gap: Oct 15 minus Sep 11).
Left: legal review completing. No specific outstanding item is given in the data.

Excluded:
- Deal-2465CE ($5,400, CRM COMMIT): Slack overrides CRM. Champion left, procurement froze new vendors, Dana pulling it from commit. Blocked until re-staff, realistically Q4. CRM is stale.
- Deal-D348E1 ($13,770, COMMIT): same "warm" Slack signal, but far later close date.
- Deal-B7EBD1 ($9,000, COMMIT): no Slack mention; missing signal, cannot rank.

Neither source confirms any deal actually signed yet.

MISSING DATA, STATED UP FRONT
- Amounts: neither file contains deal amounts (no amount column in transcripts_gaps.csv, no amounts in product_docs.md). Every "amount" below is reported as not provided — none invented.
- Deal status: no stage/active flag exists in the data. All five deal aliases are treated as the deal set given; "active" cannot be independently verified from the files.

SCREENING ARITHMETIC
5 transcripts → 5 prospect lines. TG-005's prospect line raises no gap (acceptance, see below) → 4 prospect-voiced gap candidates. 4 candidates = 2 real gaps + 1 plan gate + 1 rollout/enablement. 0 rep-voiced items counted (TG-005's gap statement is rep language).

CANDIDATE 1 — Deal-EC3025 (TG-001) — SCIM user provisioning — amount: not provided
Prospect (IT Security Lead): "We need SCIM user provisioning — our security team will not approve any tool that requires manual account management."
Classification: REAL GAP.
Docs basis: "SCIM user provisioning and ADP Workforce Now integrations are NOT currently listed as supported capabilities." SCIM appears in no tier column (Core/Pro/Enterprise) — the capability does not exist anywhere in the product, so it cannot be a plan gate (no tier unlocks it) or an enablement issue (nothing to train on).

CANDIDATE 2 — Deal-D0D6B5 (TG-002) — ADP Workforce Now integration — amount: not provided
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."
Classification: REAL GAP.
Docs basis: supported HRIS integrations are "Workday, BambooHR, Gusto, Rippling (Pro and above)"; ADP Workforce Now is explicitly not supported on any tier. Capability is absent product-wide → real gap, not plan gate or enablement.

CANDIDATE 3 — Deal-CFE7F4 (TG-003) — custom report (recognition frequency × turnover) — amount: not provided
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?"
Classification: PLAN GATE.
Docs basis: capability matrix shows "Custom report builder | — | — | yes" — Enterprise only. The functionality exists in the product; access is tier-gated. (The rep's "Enterprise tier / upgrade paths" line is rep language and is not used as evidence; the docs table alone establishes the gate. The prospect's current tier is not stated in the data.)

CANDIDATE 4 — Deal-84DBA6 (TG-004) — managers not using Slack recognition — amount: not provided
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."
Classification: ROLLOUT/ENABLEMENT ISSUE.
Docs basis: "Slack and Microsoft Teams integration | yes | yes | yes" — available and supported on all plans, and the prospect confirms it was turned on and works. The stated problem is training ("nobody ever trained them"), i.e., adoption, not missing functionality.

CANDIDATE 5 — Deal-36C33F (TG-005) — mobile app for hourly workers — amount: not provided
Classification: EXCLUDED — NOT A PROSPECT-RAISED CANDIDATE.
The only gap statement is the rep's: "we don't have a native mobile app for hourly workers yet" — rep language does not count as prospect voice. The prospect's own line, "Good to know. The web version should be fine for our office staff for now," raises no unmet need; it accepts the current state, and it addresses office staff, not the rep's hourly-worker scenario. (Corroborating note: the docs excerpt contains no mobile-app entry, so the rep's claim also could not be verified against docs.)

SUMMARY — TRUE PRODUCT GAPS (prospect-voiced, confirmed against product docs)
1. SCIM user provisioning — Deal-EC3025 — amount: not provided in the data.
   Prospect (IT Security Lead): "our security team will not approve any tool that requires manual account management." Docs: SCIM "NOT currently listed as supported" on any tier.
2. ADP Workforce Now integration — Deal-D0D6B5 — amount: not provided in the data.
   Prospect (HRIS Manager): "I don't see ADP anywhere in your integration list — that's a dealbreaker for us." Docs: supported HRIS list is Workday, BambooHR, Gusto, Rippling (Pro and above); ADP not supported.

No other real gaps. Deal amounts for all five aliases are absent from both files.

QTD SCORECARD — Alex Franklin, 2026-Q3, as of 2026-09-05
Data: ae_deals.csv (161 rows), ae_engagements.csv (161 rows), quota.csv. All rows reconciled 1:1 (no duplicate or orphan IDs).

EXCLUSION APPLIED
Deal-B3E6F1 ($24,000, CLOSED_WON 2026-06-20) is dated before Q3 and excluded from bookings. No other pre-quarter wins exist; no wins are dated after 2026-09-05.

1) BOOKINGS VS QUOTA
QTD booked (8 closed-won, 2026-07-01 to 2026-09-05): $150,000
Quota (2026-Q3): $200,000
Attainment: 150,000 / 200,000 = 75.0%
Pace: 67 of 92 days elapsed (72.8%) → attainment is running slightly ahead of time elapsed.
Gap: 200,000 − 150,000 = $50,000 with 25 days left.
Booked deals: Deal-A1C3E5 $40,000 (07-15), Deal-F2C7D8 $20,000 (07-24), Deal-B7D2F4 $35,000 (07-31), Deal-C9E1A6 $21,000 (08-12), Deal-A8B4D6 $12,000 (08-19), Deal-D4B8C2 $11,000 (08-21), Deal-E6F3A9 $6,500 (09-02), Deal-C5D9E2 $4,500 (09-03). Average won deal: 150,000 / 8 = $18,750.

2) NEW VS EXPANSION SPLIT
New: 5 deals, $113,500 (113,500 / 150,000 = 75.7% of bookings)
Expansion: 3 deals, $36,500 (36,500 / 150,000 = 24.3%)
Check: 113,500 + 36,500 = 150,000 ✓
Caveat: deal_type is populated only on won deals; all 27 lost and all 125 open deals have it blank, so a new/expansion split exists for bookings only.

3) ACTIVE PIPELINE (open deals, snapshot)
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: 125 deals, $1,260,390
Timing note: only 21 deals / $108,088 carry a Q3 close date after 2026-09-05 (Sep 6–30); 103 deals / $1,151,027 (91% of pipeline $) close beyond Q3. Only 2 open DS2 deals ($5,760) close in-quarter. Closing the $50,000 gap from the $108,088 remaining in-quarter requires ~50,000 / 108,088 ≈ 46% conversion.

4) ROLLING 90-DAY DS2-TO-WON RATE
Literal window 2026-06-07 to 2026-09-05, cohort = deals with entered_ds2 in window (all statuses; open counts against the rate): 111 entered DS2, 8 won, 27 lost, 76 still open.
Rate = 8 / 111 = 7.2%
With a 14-day buffer (cutoff 2026-08-22, window 2026-05-24 to 2026-08-22) per the canonical methodology: 8 / 92 = 8.7%. Either way, under 9%.

5) WIN / LOSS COUNTS (QTD, 2026-07-01 to 2026-09-05)
Wins: 8. Losses: 27 (lost $ = $329,272).
Win rate by count: 8 / (8 + 27) = 8 / 35 = 22.9%.
Top loss reason: "Lost- Timing (1 year or more)" — 13 deals (13/27 = 48% of losses), $184,681.
Rest of the loss table: MIA 5 deals $45,831; Competitor 5 deals $49,020; Lost DM 2 deals $17,940; Feature Request 1 deal $21,000; "Lost- Does not fit ICP (write in notes)" 1 deal $10,800.

6) ACTIVITY VOLUME, LAST 30 DAYS
(sum of per-deal columns across all 161 deal rows)
Emails: 807
Calls: 112
Meetings: 128
Notes: 50
Caveat: ae_engagements.csv carries per-deal "30d" counts with no explicit window end date; I assume the 30-day window ends at the 2026-09-05 snapshot.
Mix detail: emails are 807 / (807 + 112 + 128) = 77.1% of live (non-note) touches. 114 of 161 deals had 0 calls logged in 30 days. Won deals averaged 3.67 calls and 2.78 meetings in 30 days; lost deals averaged 0.93 calls and 0.48 meetings.

COACHING OBSERVATIONS
1. Mid-funnel is where the quarter dies, not the top: $353,760 sits in DS2 (28 deals) but only 2 DS2 deals ($5,760) close before Sep 30, and DS2-to-won is 7.2% (8/111) — the $50,000 quota gap needs ~46% conversion of the $108,088 left in-quarter, roughly 6x the demonstrated rate. Coaching focus: pull close dates and proof points forward on the freshest DS2 cohort (13 deals $150,140 aged ≤30 days in DS2) rather than working the 5 deals >90 days stale ($51,100, 14% of DS2 $).
2. Three-quarters of lost dollars are prioritization failures, not product defeats: timing (13 deals $184,681) + MIA (5 deals $45,831) + Lost DM (2 deals $17,940) = 20 of 27 losses and 248,452 / 329,272 = 75% of lost $, versus Competitor at 5 deals $49,020. Coaching focus: qualify a compelling event and budget window before deals leave DS2, and set explicit next-step dates to keep deals from going MIA.
3. The activity mix mirrors the loss profile: 807 emails vs 112 calls and 128 meetings, with zero calls on 114 of 161 deals in 30 days — and the closed-won cohort ran 3.67 calls / 2.78 meetings per deal versus 0.93 / 0.48 on losses. Coaching focus: swap email volume for live conversations on late-stage and recently-stalled deals, since the won deals' engagement pattern is the only one in this data that converts.

Method, verified by execution: reference date = 2026-09-24; 60-day window = engaged on or after 2026-07-26 and is_former = false. Every date was day-diffed (e.g. 2026-07-26 -> 60d before today; 2026-07-30 -> 56d; 2026-06-20 -> 96d). 14 deals in file, 36 rows. 11 flagged (7 single-threaded, 4 under-threaded), 3 clean.

DATA GAP (applies to every deal below): amount and stage are not present in either file (deal_contacts.csv columns are deal_id, deal_alias, company, contact_key, title, persona, last_engaged_date, is_former only). Amount: not in file. Stage: not in file, for all 11.

SINGLE-THREADED (active contacts < 2)

1. Deal-EC3025 (C-FDD0C7) — 1 active / 2 on file
   Active personas: champion (CT-047C54, engaged 2026-09-02)
   Missing: economic buyer, HR admin, IT security, finance
   Add: economic buyer — replaced when CT-F2C1AE (economic buyer) went former (last engaged 2026-08-15, is_former = true)
   On file, unengaged, fits: CT-6827DB, Chief People Officer, economic buyer

2. Deal-92D97D (C-E23238) — 1 active / 2 on file
   Active personas: HR admin (CT-01F5B4, engaged 2026-08-28)
   Missing: champion, economic buyer, HR admin aside — i.e. champion, economic buyer, IT security, finance
   Add: economic buyer (champion CT-A902AE also lapsed, 2026-06-01 = 115 days, far outside the window)
   On file, unengaged, fits: none on file

3. Deal-36C33F (C-077A0E) — 1 active / 3 on file
   Active personas: IT security (CT-4FE556, engaged 2026-08-15)
   Missing: champion, economic buyer, HR admin, finance
   Add: economic buyer — champion CT-405B45 and economic buyer CT-86B22F both is_former = true
   On file, unengaged, fits: CT-1DB73E, Chief People Officer, economic buyer

4. Deal-FCBE5B (C-737030) — 1 active / 1 on file
   Active personas: champion (CT-4A5317, engaged 2026-08-29)
   Missing: economic buyer, HR admin, IT security, finance
   Add: economic buyer
   On file, unengaged, fits: none on file

5. Deal-F9A08A (C-0D15DF) — 1 active / 2 on file
   Active personas: champion (CT-931B10, engaged 2026-09-03)
   Missing: economic buyer, HR admin, IT security, finance
   Add: economic buyer — the incumbent EB (CT-913581) lapsed at 2026-06-20 = 96 days, outside window
   On file, unengaged, fits: CT-697541, Chief People Officer, economic buyer

UNDER-THREADED (2+ active but < 3, or all in one persona)

6. Deal-50D386 (C-EB10E4) — 2 active / 2 on file
   Active personas: champion (CT-AA41B2, 2026-09-01), HR admin (CT-B9C35B, 2026-08-25)
   Missing: economic buyer, IT security, finance
   Add: economic buyer
   On file, unengaged, fits: CT-A1C4B3, Chief People Officer, economic buyer

7. Deal-D0D6B5 (C-32918E) — 3 active / 3 on file, but all in one persona: 3 champions (CT-87CED4 2026-09-02, CT-DE6D7C 2026-08-19, CT-FD70B2 2026-08-07)
   Missing: economic buyer, HR admin, IT security, finance
   Add: economic buyer — buying power is the gap; every active thread is a champion
   On file, unengaged, fits: CT-1FA4DB, Chief People Officer, economic buyer

8. Deal-5BFE3B (C-535D36) — 2 active / 2 on file
   Active personas: champion x2 (CT-57123B 2026-08-31, CT-5CE757 2026-08-12) — also single-persona
   Missing: economic buyer, HR admin, IT security, finance
   Add: economic buyer
   On file, unengaged, fits: none on file

9. Deal-885F45 (C-5E8EFB) — 2 active / 2 on file
   Active personas: economic buyer (CT-51C81E, 2026-08-26), champion (CT-D9A0E8, 2026-08-11)
   Missing: HR admin, IT security, finance
   Add: IT security — EB and champion are covered; security review is the likely next blocker, and it is the only missing persona with an on-file candidate
   On file, unengaged, fits: CT-B3F25D, IT Security Lead, IT security

10. Deal-5408B0 (C-2AE3AA) — 2 active / 2 on file
    Active personas: champion (CT-D33AE4, 2026-09-01), HR admin (CT-8742FD, 2026-08-18)
    Missing: economic buyer, IT security, finance
    Add: economic buyer
    On file, unengaged, fits: CT-07FA76, Chief People Officer, economic buyer

11. Deal-C6D97A (C-5A8FC2) — 3 active / 3 on file, but all in one persona: 3 champions (CT-223DDC 2026-08-31, CT-B03555 2026-08-20, CT-4E8A2B 2026-08-05)
    Missing: economic buyer, HR admin, IT security, finance
    Add: economic buyer — no buying authority on the thread
    On file, unengaged, fits: none on file

NOT FLAGGED (verification, not part of the ask): Deal-84DBA6 (C-BE9BE0) 3 active — champion, economic buyer, IT security; Deal-4B0BEB (C-1BDFE0) 4 active — champion, economic buyer, HR admin, finance; Deal-D348E1 (C-804F29) 5 active — all five personas.

Reconciliation of unengaged_contacts.csv: 9 rows, 7 consumed by the recommendations above; the other 2 (CT-8E04F5 HRIS Manager at C-804F29, CT-2A0169 Controller at C-BE9BE0) belong to clean deals, so they are correctly unused. One caveat on counts: my "active" totals count rows, and duplicate (title, persona) combos at the same company (e.g. three champions at C-32918E) appear as distinct contact_keys in the file, so no dedup was applied — none is implied by the data.

SCOPE: 10 transcripts (TT-001…TT-010), all Alex Franklin, 2026-07-28 to 2026-09-03. The CSV contains excerpted lines only (roughly minutes 0, 2, 4-6, 8, 11-15 per call), not full transcripts, and no deal-outcome data — so findings below are limited to the provided lines, and anything not derivable from them is flagged as unavailable.

1) WHAT THEY LEAD WITH (FIRST FIVE MINUTES)

- 8 of 10 calls open at minute 0 with the identical customer proof story: Deal-D348E1, Deal-5408B0, Deal-547B2B, Deal-C61CF7, Deal-60C2C2, Deal-EDC141, Deal-D9A12F, Deal-84DBA6. 8 ÷ 10 = 80%.
  "Quick one to kick off: a 400-person retailer we work with cut regretted turnover 18% in two quarters after automating milestone awards, and I wanted to walk you through exactly how they did it."
- Two exceptions: Deal-403845 (TT-004) leads with an agenda — "I put together a short agenda — security review first, then pricing." Deal-1E2498 (TT-009) leads with pricing — "You asked for straight pricing last time, so let's start there."
- The only other rep line inside minutes 0-4 is the unprompted Workhuman contrast in TT-005 (covered in section 4).

2) THREE MOST COMMON OBJECTIONS AND HANDLING

Primary objections (all at minute 6): 4 + 3 + 3 = 10 total; every call contains exactly one of these three, and the objection line is verbatim-identical within each type.

- Budget locked until next fiscal year / no new line item — 4 calls: Deal-D348E1, Deal-547B2B, Deal-60C2C2, Deal-84DBA6 (4 ÷ 10 = 40%). Handling: identical at minute 8 all 4 times — reframes cost as self-funding from turnover savings, reusing the same retailer proof: "Totally fair. Most teams fund this out of turnover savings — that retailer saved about $210k in avoided backfills, which is how their finance team signed off."
- Revisit next quarter / open enrollment — 3 calls: Deal-5408B0, Deal-C61CF7, Deal-D9A12F (3 ÷ 10 = 30%). Handling: identical at minute 8 all 3 times — counters the timing objection with a scoped pilot: "Makes sense. What if we scope a 90-day pilot with one department so you have internal data before next quarter's planning?"
- Status quo (spreadsheet + quarterly gift cards) — 3 calls: Deal-403845, Deal-EDC141, Deal-1E2498 (3 ÷ 10 = 30%). Handling: identical at minute 8 all 3 times — concedes it works at scale-limit, differentiates on automation and 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."

Not covered by the script: second stalls in 3 calls — budget-committee deferral (Deal-403845 min 11, Deal-84DBA6 min 11) and no-urgency/think-about-it (Deal-EDC141 min 14). Each is met with a concession and no counter: "Understood — I'll leave it with you." (TT-004; TT-007 and TT-010 end similarly with brief acknowledgments and no ask.)

3) NEXT-STEP RATE

- The identical minute-14 ask is made in 7 of 10 calls: Deal-D348E1, Deal-5408B0, Deal-547B2B, Deal-C61CF7, Deal-60C2C2, Deal-D9A12F, Deal-1E2498.
- The prospect agrees in the same 7 calls (minute 15, identical line each time — a scheduled working session with the HRIS manager invited): "Yes, Thursday at 2pm works — send the invite and I'll bring our HRIS manager."
- Concrete next step agreed: 7 ÷ 10 = 70% of calls. Ask-to-agreement: 7 ÷ 7 = 100%.
- The 3 calls with no agreed next step (Deal-403845, Deal-EDC141, Deal-84DBA6) are exactly the 3 calls with the unscripted second stalls above; in each, no ask was made at all.
- The file has no follow-up data, so whether the 7 agreed sessions actually occurred cannot be determined from the data provided.

4) COMPETITORS RAISED BY PROSPECTS

- Awardco — 1 call, Deal-547B2B (TT-003, minute 4): "We're also in late talks with Awardco — their rewards catalog looks bigger than yours."
- Kudos — 1 call, Deal-EDC141 (TT-007, minute 4): "How are you different from Kudos? Our CEO used them at her last company."
- Workhuman is named once (Deal-C61CF7, TT-005, minute 2) but by Alex Franklin, not the prospect, so it does not count as prospect-raised: "And unlike Workhuman, our pricing includes the full rewards catalog with no extra margin."
- These are the only competitor names anywhere in the provided lines (2 prospect-raised + 1 rep-raised = 3 mentions). Competitors raised in unexcerpted portions of the calls, if any, are not in the data.

COACHING NOTES

1. Build a fourth play for committee/urgency stalls. The only three calls that ended with no next step (3 ÷ 10 = 30%) are precisely the three with an unscripted second stall, and each time Alex conceded with no counter and dropped the minute-14 ask entirely — while the ask itself converts 7 of 7 when made. Coach him to keep the ask alive after a stall: arm the champion with the $210k backfill-savings story, offer to join the committee review, or shrink the commitment to something small and dated.

2. Adapt the script deliberately. 80% of opens, all three objection responses, and every next-step ask are verbatim-identical across ten deals and six weeks — one gear regardless of buyer. The deviations show he can adapt (pricing-first in Deal-1E2498 still closed a next step). Coach him to match the open to the buyer, port the 90-day pilot counter — proven against timing objections — to budget/committee stalls like Deal-84DBA6 where the savings reframe carries no attached commitment, and stop introducing competitors unprompted (Workhuman in TT-005); prospects raised only Awardco and Kudos.

All figures below are computed from deals.csv exactly as provided (86 rows, snapshot 2026-09-05). Quarter = 2026-07-01 to 2026-09-30; 54 deals fall inside, 32 outside.

COMMIT total (in-quarter): 7 deals
11200 (Deal-547B2B) + 9000 (Deal-B7EBD1) + 9000 (Deal-403845) + 6360 (Deal-A2B47C) + 5400 (Deal-2465CE) + 2520 (Deal-A5E80A) + 1249 (Deal-499BF6) = 44,729

BEST_CASE total (in-quarter): 24 deals
38935 + 24000 + 19656 + 16250 + 11116 + 10800 + 10500 + 9890 + 9720 + 9000 + 7200 + 3840 + 3780 + 3600 + 3240 + 3150 + 3120 + 3060 + 2916 + 2760 + 2484 + 2100 + 1920 + 528 = 203,565

Weighted forecast
= 100% of COMMIT + 35% of BEST_CASE
= 44,729 + (0.35 × 203,565)
= 44,729 + 71,247.75
= 115,976.75

Counts in-quarter
- COMMIT: 7
- BEST_CASE: 24
- PIPELINE: 23 (count 0 toward forecast)

Excluded for being outside the quarter: 32 deals, total amount 227,575
= 22 PIPELINE (185,565) + 9 BEST_CASE (28,240) + 1 COMMIT (13,770, Deal-D348E1)
All 32 have close dates 2026-10-01 through 2026-10-15 (Q4); none fall before 2026-07-01.
Cross-check: 44,729 + 203,565 + 185,565 + 28,240 + 13,770 = 475,869 = sum of all 86 rows. ✓

Top 5 BEST_CASE deals by amount inside the quarter
1. Deal-2D7423 — 38,935 (2026-09-30)
2. Deal-25F752 — 24,000 (2026-09-25)
3. Deal-E53952 — 19,656 (2026-09-30)
4. Deal-5EED42 — 16,250 (2026-09-30)
5. Deal-FA32A0 — 11,116 (2026-09-25)

## Data quality
Four open deals (Deal-333EBB, Deal-57FF13, Deal-31AD2C, Deal-7A2454; 16,255 total) have close dates before the 2026-09-05 snapshot, so close-date hygiene is stale and the in-quarter cut can silently include or miss slipped deals. Two COMMIT deals sit in discovery stages (Deal-A5E80A at DS1, Deal-499BF6 at DS2), a stage/forecast-category contradiction that inflates the 100%-weighted term. The owner field is blank on 85 of 86 deals, so nothing here is accountability-checked, and 22 of 24 in-quarter BEST_CASE deals have why_buys_chars = 0, meaning the 35% bucket carries almost no documented rationale. Together these mean an unattended run would likely double-count the two mislabeled COMMIT deals and mis-time slipped-closedate deals with no owner to flag it.

ACTIVATION HYPOTHESIS TEST — 2023 signup cohort, first-calendar-month signals
Signals: givers = m1_users >= 5; redemptions = m1_redemptions >= 1. Retention = current_status == 'active' (all 220 companies are 25+ months old). Arithmetic shown as retained/cohort.

FULL 2x2
- Both signals: 31/47 retained = 66.0%
- Givers-only (m1_users >= 5, m1_redemptions = 0): 23/49 = 46.9%
- Redemption-only (m1_users < 5, m1_redemptions >= 1): 9/29 = 31.0%
- Neither: 38/95 = 40.0%
- Check: 47 + 49 + 29 + 95 = 220; 31 + 23 + 9 + 38 = 101 active.

EXCLUSIONS
None. 0 of 220 rows excluded — every row has non-missing m1_users, m1_redemptions, and current_status. Denominator = 220.

Note on the outcome field: 3 companies are current_status = 'non_renewing' (C-0B2078FB, C-0A96134F, C-0BEAF685) and 116 are 'cancelled'; per the stated rule only 'active' counts as retained at 24 months, so all 119 are counted as not retained.

SINGLE SIGNAL WITH LARGEST RETENTION LIFT
The givers signal (m1_users >= 5). Marginal lift: 56.2% (54/96) with the signal vs 37.9% (47/124) without = +18.3 points. Compare redemptions >= 1: 52.6% (40/76) vs 42.4% (61/144) = +10.3 points. In the 2x2, the combination driven by givers carries the lift (both = +26.0 pts vs neither; givers-only = +6.9; redemption-only = -9.0).

WHAT THIS DOES AND DOES NOT PROVE
Does: in this extract, both signals co-occurring is associated with markedly better 24-month retention (66.0% vs 40.0% neither), and the givers threshold is the stronger single predictor. The hypothesis is directionally supported in this data.

Does not: prove causation. The signals are measured post-signup and could be consequences, not drivers, of retention. The extract shows clear confounding by tier: the "both" cell is 33/47 tier_three vs 46/95 tier_two in "neither" (tier composition differs across cells), and no covariates (tier, ARR, industry, integrations) are controlled for. It is one cohort (2023 signups only, 220 companies), with small cells (29–49 companies in three of four quadrants), and non_renewing companies are counted as churn by rule, not by observation. It also does not test the m1 data quality (e.g., C-0DD506E9 shows m1_users=27 but m3_users=0), and there is no data here on what happened between month 1 and month 24.

RECONCILIATION — ARR: CRM vs Billing, as of 2026-09-05

SCOPE & METHOD
- 39 subscription rows, 39 CRM company rows, 38 aliases in both.
- Billing-only alias: C-21629AA4 (SUB-0004, active). CRM-only alias: C-0D5BBE3A (no subscription).
- Billing ARR = MRR x 12, counting ACTIVE subscriptions only (37 active, 2 cancelled). Cancelled subs still carried in CRM are captured in the "status mismatch" bucket. (If you instead sum MRR x 12 over all 39 rows, billing = 617,897.76 and variance = 14,316.00 with a zero status bucket — flagging so the definitional choice is explicit.)

TOTALS
- CRM ARR (sum of 39 hubspot_arr rows) = 603,581.76
- Billing ARR (sum MRR of 37 active subs = 50,394.94; x 12) = 604,739.28
- Variance (Billing − CRM) = 604,739.28 − 603,581.76 = +1,157.52

DECOMPOSITION (must sum to +1,157.52)
1. Status mismatch: −13,158.48
   C-0C8323BF (SUB-000E, cancelled): billing 0.00 vs CRM 4,905.24 = −4,905.24
   C-0DC4FB8C (SUB-000F, cancelled): billing 0.00 vs CRM 8,253.24 = −8,253.24
   (No cancellation dates in the data; if either cancellation postdates 2026-09-05, reclassify.)
2. Missing records: +11,952.00 (net)
   C-21629AA4 (SUB-0004, active, billing-only): billing 28,449.24, no CRM record → +28,449.24
   C-0D5BBE3A (CRM-only, no subscription): CRM 16,497.24, billing 0 → −16,497.24
3. Rounding: −36.00
   C-0D66DF9E (SUB-0005): 1,932.00 x 12 = 23,184.00 vs CRM 23,200.00 → −16.00
   C-14D70CE0 (SUB-0008): 1,515.00 x 12 = 18,180.00 vs CRM 18,200.00 → −20.00
   (Small residuals, not derivable from provided fields; classified as rounding/entry drift.)
4. Other: +2,400.00
   C-0F7269D7 (SUB-0006, active): 2,233.00 x 12 = 26,796.00 vs CRM 24,396.00 → +2,400.00
   (Implied CRM MRR 2,033.00 vs billing 2,233.00 — consistent with a 200.00/mo entry error; source of truth unknown from data.)

Check: −13,158.48 + 11,952.00 − 36.00 + 2,400.00 = +1,157.52 ✓ (equals variance exactly)
Remaining 31 shared active accounts match MRR x 12 to the cent.

MISMATCHED ACCOUNTS — SUGGESTED OWNER
No owner field exists in the provided data (state explicitly); suggestions are functional queues, not named people:
- C-0C8323BF — cancelled in billing, stale ARR in CRM → CSM to confirm cancellation, RevOps/CRM data steward to zero the record.
- C-0DC4FB8C — same pattern → CSM + RevOps/CRM data steward.
- C-21629AA4 — active subscription, no CRM company record → CRM admin (create record, 28,449.24 ARR at stake).
- C-0D5BBE3A — CRM record, no subscription (16,497.24 ARR unsubstantiated) → Billing/CS ops to locate or purge the subscription.
- C-0F7269D7 — +2,400.00 amount mismatch → account AE/CSM to verify contracted MRR; RevOps to correct whichever source is wrong.
- C-0D66DF9E and C-14D70CE0 — rounding-level drift → RevOps data hygiene (low priority).

BUSINESS RULE VIOLATIONS (term ≠ 12 months AND cf_agreement_end_date empty)
- SUB-0002 / C-1794A52C — term 24 months, cf_agreement_end_date blank. Owner: billing ops to backfill.
- SUB-0019 / C-22170CA1 — term 36 months, cf_agreement_end_date blank. Owner: billing ops to backfill.
Compliant non-12-month subs: SUB-000C (C-0DB48281, 24 mo, end date 2027-11-30) and SUB-001A (C-0FC4DBB8, 36 mo, end date 2027-11-30). Note: both violators' CRM ARR equals MRR x 12 exactly, so term length is not contributing to the variance.

DATA GAPS (per instructions, stated explicitly): no cancellation dates, no owner/user fields, no pipeline or contract metadata in either file; bucket ownership above is therefore functional, not named.

All 30 companies appear in both months (60 rows, all plan_tier = tier_three; 10 per size_band). Values below are unweighted means across the 30 companies — no user counts/weights are provided, so a weighted figure cannot be computed.

| KVM | 2026-07 | 2026-08 | Abs Δ | Rel Δ | Direction |
|---|---|---|---|---|---|
| Giving rate | 0.6023 | 0.6027 | +0.0004 | +0.07% | ▲ |
| Redemptions per user | 1.7300 | 1.7302 | +0.0002 | +0.01% | ▲ |
| 1:1 meetings engagement | 0.4469 | 0.4472 | +0.0003 | +0.06% | ▲ |
| Pulse check engagement | 0.6006 | 0.5086 | −0.0920 | −15.3% | ▼ |

Largest relative move: pulse check engagement, −15.3%. The data supports segment attribution: the drop is driven entirely by the enterprise size_band (0.5500 → 0.2743, −50.1%), where all 10 companies fell ~49–51% (e.g. C-0B2895EF 0.5619 → 0.2864). SMB (−0.2%) and mid_market (+0.2%) pulse engagement were essentially flat. Plan_tier cannot be the driver — every row is tier_three, so no tier variation exists in the data.

Arithmetic example: pulse rel Δ = (0.508610 − 0.600587) / 0.600587 = −0.091977 / 0.600587 = −15.3%.

All 378 rows in redemptions_ytd.csv fall between 2026-01-01 and 2026-08-31 (max redeemed_at: 2026-08-31T11:53). The file contains no September rows, so no partial-month exclusions were needed.

**Last completed month: 2026-08 (August 2026).** September 2026 is the current partial month and is excluded; it has no rows in this file anyway.

**Redemption section — Jan 1 through Aug 31, 2026**

- Redemption count: 378
- Spend: $27,846.00 (sum of amount_usd across 378 rows)
- Unique redeemers: 235 (distinct user_key)
- Redemptions per redeemer: 378 ÷ 235 = 1.61

**Provider mix (share of spend)**

| Provider | Spend | Count | Share |
|---|---|---|---|
| custom | $10,873.00 | 37 | 10,873 ÷ 27,846 = 39.05% |
| Tremendous | $8,505.00 | 192 | 8,505 ÷ 27,846 = 30.54% |
| Snappy | $5,238.00 | 59 | 5,238 ÷ 27,846 = 18.81% |
| TangoCard | $3,230.00 | 90 | 3,230 ÷ 27,846 = 11.60% |

Shares sum to 100.00%. Provider counts (37 + 192 + 59 + 90 = 378) reconcile to the redemption total.

**Top 5 countries by redemptions**

1. US — 244
2. CA — 24
3. AU — 21
4. GB — 17 (tie)
5. NL — 17 (tie)

GB and NL are tied at 17 for ranks 4–5; both are included, so the top 5 is exactly five countries (next is SG at 12). Country counts total 378.

Notes on data coverage: the file provided every field needed for these metrics (redeemed_at, provider, amount_usd, user_key, country) — nothing was missing. Unique redeemers are counted on user_key as given, since no separate user table was provided.

All figures below were computed by script against the two files you provided (30 accounts, snapshot date 2026-09-05 from rule R3). Arithmetic is shown. Aliases are cited exactly as given.

ELIGIBILITY (all three rules must pass: R1 health_score < 60; R2 churn_save_eligible_amount > 0; R3 renewal within 120 days of 2026-09-05, i.e. on or before 2027-01-03)

QUALIFIERS — 8 accounts, $224,601.00 total at stake

Account | Health | Renewal (days out) | Eligible amount | Passes
C-0B0F1BAB | 38 | 2026-09-23 (18d) | $5,494.00 | R1, R2, R3
C-0E9C27D1 | 39 | 2026-09-24 (19d) | $41,235.00 | R1, R2, R3
C-0F6C0F34 | 51 | 2026-10-03 (28d) | $49,707.00 | R1, R2, R3
C-0B360C78 | 57 | 2026-10-28 (53d) | $35,748.00 | R1, R2, R3
C-0D3278C7 | 54 | 2026-11-12 (68d) | $17,602.00 | R1, R2, R3
C-0B827671 | 56 | 2026-11-14 (70d) | $25,365.00 | R1, R2, R3
C-0CEF69FD | 53 | 2026-11-21 (77d) | $32,621.00 | R1, R2, R3
C-0CA21961 | 58 | 2026-12-28 (114d) | $16,829.00 | R1, R2, R3

Total: 5,494 + 41,235 + 49,707 + 35,748 + 17,602 + 25,365 + 32,621 + 16,829 = $224,601.00. (Context, as given: these 8 accounts carry $454,380.00 combined ARR, so the eligible pool is 49.4% of it. Note the two renewals in the file dated 2026-09-23/24 are ~2.5 weeks past the 2026-09-05 snapshot — treat the snapshot as the evaluation point per R3.)

PLAY ASSIGNMENT — one play per account. No play-mapping rules exist in the provided data, so I mapped from the account signals, using this stated logic: declining usage or very low seat utilization → usage revival (reverse an active engagement problem); no active champion → executive touch (relationship/sponsor risk); otherwise (engagement and relationship look fine, so the drag is price/value) → commercial concession.

1. Usage revival — 3 accounts, $59,796.00
- C-0D3278C7: $17,602.00. Signal: usage_trend_3m = declining; seat utilization 126/380 = 33.2%.
- C-0B827671: $25,365.00. Signal: usage_trend_3m = declining; utilization 113/202 = 55.9%.
- C-0CA21961: $16,829.00. Signal: lowest qualifier utilization, 84/325 = 25.8%, with flat 3-month usage trend.
2. Executive touch — 3 accounts, $87,822.00
- C-0F6C0F34: $49,707.00. Signal: champion_active = false (despite growing usage, 308/395 = 78.0%).
- C-0CEF69FD: $32,621.00. Signal: champion_active = false (usage growing, 97/136 = 71.3%).
- C-0B0F1BAB: $5,494.00. Signal: champion_active = false, plus the file's lowest health score, 38.
3. Commercial concession — 2 accounts, $76,983.00
- C-0E9C27D1: $41,235.00. Rationale: champion active, flat usage, high utilization (134/157 = 85.4%) — engagement is fine, so the health score of 39 points at a price/value issue, the one lever the other plays don't address.
- C-0B360C78: $35,748.00. Rationale: champion active, usage growing, utilization 246/327 = 75.2% — again engagement and relationship are healthy, leaving commercial terms as the remaining lever.

Cross-check: 87,822 + 59,796 + 76,983 = $224,601.00 (matches the qualifier total).

AT-RISK (health < 60) BUT NOT QUALIFYING — 7 accounts

- C-0BC71BDD (h=55, renewal 2026-10-27, 52d): fails R2 — eligible amount $0.00 (despite $54,515.00 ARR in the file).
- C-0BE96399 (h=54, renewal 2026-10-29, 54d): fails R2 — $0.00 eligible; declining usage, 43/154 = 27.9% utilization.
- C-10A56B0F (h=54, renewal 2026-12-12, 98d): fails R2 — $0.00 eligible; declining usage.
- C-0F876796 (h=47, renewal 2027-02-06, 154d): fails R3 — renewal 154 days out (> 120), despite $19,958.00 eligible.
- C-0BA71F12 (h=52, renewal 2027-04-11, 218d): fails R3 — 218 days out, despite $6,824.00 eligible.
- C-0F6694C3 (h=43, renewal 2027-03-21, 197d): fails R2 ($0.00) and R3 (197d out).
- C-0FCCD2DF (h=43, renewal 2027-04-23, 230d): fails R2 ($0.00) and R3 (230d out).

Also not qualifying on R1: four accounts with health ≥ 60 renew inside the 120-day window (C-0AAA9434 2026-10-14, C-0D035262 2026-10-20, C-172EEFBC 2026-11-24, C-0B2213A9 2026-12-03; combined ARR $231,969.00). They renew soon but are not flagged at risk by R1 (health 69–85, mostly growing usage).

DATA GAPS (stating explicitly, per your ground rules)
- No play-mapping rules were provided; the usage revival / executive touch / commercial concession assignment above is my stated mapping from the signals in the file, not a documented rule.
- The files give no reason for $0.00 eligible amounts (e.g., C-0BC71BDD carries $54,515.00 ARR and renews in 52 days yet has $0.00 churn-save eligible — cause not documented). No currency is stated in the files; figures are reported exactly as given.
- Signal data ends at what's in churnzero_accounts.csv; no notes, contact, or product-usage fields beyond trend/seat/champion exist to corroborate play choices.

EXPANSION KIT — C-0DDFC9A7

1) SEAT COVERAGE
150 licensed / 400 headcount = 37.5%. 250 employees (400 − 150) are unlicensed.

2) USAGE HEALTH (2 lines)
Monthly active users rose from 88 (Mar 2026) to 126 (Aug 2026): +38 users, +43.2% (38/88) over five months, averaging +7.6 users/month (compound ≈ 7.4%/month).
August utilization is 126/150 = 84% of licensed seats (up from 88/150 = 58.7% in March); at the +7.6/month pace, straight-line, usage reaches the 150-seat cap in ~3 months (~Dec 2026) — a projection, not a given.

3) HEADROOM AT CURRENT PER-SEAT RATE
Per-seat rate: $9,000 ARR / 150 seats = $60/seat/year (assumes uniform pricing; no tier data provided).
Seat headroom: 400 − 150 = 250 seats.
ARR headroom: 250 × $60 = $15,000 incremental (total at full headcount coverage: 400 × $60 = $24,000).
Near-term note: only 24 licensed seats (150 − 126) are currently unused.

4) WHO REPLIED / CAN THEY BUY
Maria S., People Operations Coordinator, replied 2026-09-02 to Cole Ingram. She cannot buy — she states she is "not the right person for purchasing decisions here" and that budget and seat expansion sit with Dana R. She offered to make an introduction.

5) RIGHT BUYER FROM OUR CONTACTS
Dana R., VP People (in expansion_contacts.csv, last engaged 2026-05-18). Basis: Maria's reply explicitly names Dana R. as owning budget and seat expansion — that authority is per Maria's statement only, not independently verified in the provided data. She has also been asking about usage numbers per Maria. Sam K. (Office Manager, last engaged 2025-11-03) shows no purchasing role in the data.

6) REPLY EMAIL (from Cole, ~83 words)

Subject: RE: Growing your team's recognition program

Hi Maria,

Thanks for this — and great to hear the team is enjoying the program.

An intro to Dana would be helpful, thank you. Since she's been asking about usage numbers: monthly active users grew from 88 in March to 126 in August — up 43% in five months.

If it's easiest, feel free to forward this note to her, or I can send a short usage summary she can skim ahead of a call. Either works — no rush on timing.

Thanks again,
Cole

7) DATA GAPS (explicit)
No contact details for Dana R. beyond name/title; her budget authority rests solely on Maria's email. No pricing/tier structure (per-seat rate is derived). No deal stage, contract end date, or department-level headcount breakdown provided. Cole Ingram's role is inferred from the reply thread (recipient of Maria's response to outreach).

CSM PREP — MID-ONBOARDING CALL — C-0D284E42
Sources: onboarding_account.csv, onboarding_usage.csv. Usage data covers 2026-08-11 through 2026-09-04 only; nothing after that date is in the data.

WHAT IS COMPLETE (each backed by a data field)
1. Slack integration — integration_slack = 2026-08-12 (1 day after signup on 2026-08-11).
2. Allowance set — allowance_set = 2026-08-13 (2 days after signup).
3. Admins added — admins_added = 2. (No target count is provided, so whether 2 is "enough" is not determinable from data.)
4. First recognition given — first_recognition_at = 2026-08-15 14:22 (4 days after signup).

WHAT IS NOT COMPLETE
1. HRIS integration — integration_hris is blank. No data field shows a connection; treat as not connected.
2. First redemption — first_redemption_at is blank. No redemption on record through the end of the data window (2026-09-04), i.e., 20 days after the first recognition.
3. Onboarding progress vs. plan — no milestone/target fields exist in the data, so where "mid" falls cannot be quantified.

EARLY ENGAGEMENT SIGNALS (active_givers, 2026-08-11 → 2026-09-04)
- Growth: 3 givers on 2026-08-11 → 15 on 2026-09-04. That is +12, or 5x (15 ÷ 3 = 5).
- No dormant days: 25 of 25 days show ≥3 active givers.
- Weekly totals (avg per day), each period higher than the last:
  W1 (08-11–08-17): 3+3+4+4+5+4+7 = 30 → ~4.3/day
  W2 (08-18–08-24): 5+7+6+9+8+9+9 = 53 → ~7.6/day
  W3 (08-25–08-31): 9+11+10+10+11+13+11 = 75 → ~10.7/day
  09-01–09-04 (4 days): 13+13+15+15 = 56 → 14.0/day
- Peak: 15, on the two most recent days in the data (09-03 and 09-04).
- Caveat: no headcount/eligible-user field exists, so 15 givers cannot be converted into an adoption percentage.

THREE THINGS TO COVER ON THE CALL
1. HRIS integration — the one open setup item (blank field). Confirm the blocker, an owner, and a target date.
2. First redemption — the one open activation milestone. Recognition has been live since 08-15 with zero redemptions recorded. Walk the rewards catalog and balance visibility with the 2 admins to find what's blocking it.
3. Sustain the giver ramp — 3 → 15 with no zero days is the strongest signal in the data. Ask what's driving the climb, agree what steady-state giving looks like, and capture headcount on the call so adoption can be measured going forward (currently not computable from the data).

DATA EXPLICITLY MISSING: HRIS connection date, first redemption timestamp, total eligible users/headcount, recognition counts (data tracks givers only, not posts), any activity after 2026-09-04, and onboarding plan milestones/targets.

90-DAY RENEWAL RISK BRIEF — window 2026-09-24 to 2026-12-23
Anchor date: I used 2026-09-24 (today) as "now" since no data file states it. All 20 accounts fall inside the window; none fall outside. Data integrity: 20 accounts in each file, identical alias sets, 12 usage months per account — no missing data.

DATE-SOURCE DECISIONS — 5 DISAGREEMENTS, ALL FLAGGED
Rule given: multi-year contracts are known wrong in ChurnZero, so Chargebee (CB) is authoritative for the 5 accounts with is_multi_year=true. The other 15 are single-year and CZ and CB dates match exactly, so no decision is needed (both agree).

  1. C-0B7D2C30 — CZ 2026-09-10 vs CB 2026-09-15 (+5d, 36mo). Use CB.
  2. C-0BCDB8C2 — CZ 2027-09-18 vs CB 2026-09-18 (-365d, 36mo). Use CB. Material: CZ would place this renewal a full year outside the window.
  3. C-0D2AB865 — CZ 2026-09-10 vs CB 2026-09-22 (+12d, 24mo). Use CB.
  4. C-0BBE3E60 — CZ 2027-09-26 vs CB 2026-09-26 (-365d, 24mo). Use CB. Material: same one-year-out problem as #2.
  5. C-0F5D2323 — CZ 2026-09-10 vs CB 2026-09-29 (+19d, 24mo). Use CB. Material: moves the account from "already past due" to "5 days out".

Because of #2, #4, #5, the choice of source changes the brief's contents, not just dates: trusting CZ would drop two renewals ($85,420 ARR) from the window entirely and mis-date a third.

RISK RUBRIC (stated because none was supplied)
PAST-DUE = renewal date already passed as of 2026-09-24 (per trusted source).
HIGH = seat utilization < 35% OR 3-month usage decline >= 10%.
MEDIUM = utilization 35-65%. LOW = otherwise.
Seat utilization = seats_used / seats. 3-mo trend = active users Jun → Aug 2026, % change.

RENEWALS (chronological by trusted date; trend shown Jun→Jul→Aug 2026)

PAST-DUE (date passed before 2026-09-24, per Chargebee):
C-0B7D2C30 | Dana Mercer | $65,901 | 2026-09-15 (CB) | 274/476 = 57.6% | 97→94→84 (-13.4%) | PAST-DUE — renewal was 9 days ago and usage fell 13.4% in 3 months and 45.8% over 12 months.
C-0BCDB8C2 | Cole Ingram | $54,427 | 2026-09-18 (CB) | 232/424 = 54.7% | 127→118→110 (-13.4%) | PAST-DUE — renewal was 6 days ago with usage down 13.4% in 3 months and 45.0% over 12 months.
C-0D2AB865 | Elena Sinclair | $38,022 | 2026-09-22 (CB) | 250/407 = 61.4% | 125→117→109 (-12.8%) | PAST-DUE — renewal was 2 days ago and usage has dropped every month for a year (199 → 109).

UPCOMING IN WINDOW:
C-0BBE3E60 | Dana Mercer | $30,993 | 2026-09-26 (CB) | 74/114 = 64.9% | 39→35→33 (-15.4%) | HIGH — usage is down 15.4% in 3 months and 47.6% over 12 months, two days before renewal.
C-0F5D2323 | Cole Ingram | $90,647 | 2026-09-29 (CB) | 111/390 = 28.5% | 20→21→18 (-10.0%) | HIGH — only 28.5% of seats active and 3-month usage is down 10.0% on the largest at-risk contract.
C-0EC6999D | Elena Sinclair | $79,419 | 2026-10-03 (CZ=CB) | 31/112 = 27.7% | 17→16→15 (-11.8%) | HIGH — 27.7% utilization with usage still eroding (-11.8% over 3 months).
C-0B20DB64 | Dana Mercer | $21,770 | 2026-10-07 (CZ=CB) | 214/378 = 56.6% | 294→298→294 (0.0%) | MEDIUM — more than 4 in 10 seats idle, though usage itself is flat.
C-0BBC4E7A | Cole Ingram | $56,374 | 2026-10-10 (CZ=CB) | 228/337 = 67.7% | 142→141→139 (-2.1%) | LOW — healthy utilization and usage essentially flat for 12 months.
C-0FD551AB | Elena Sinclair | $48,815 | 2026-10-14 (CZ=CB) | 210/376 = 55.9% | 123→122→126 (+2.4%) | MEDIUM — utilization at 55.9% despite slightly rising usage.
C-0F9F8F13 | Dana Mercer | $46,230 | 2026-10-18 (CZ=CB) | 199/352 = 56.5% | 185→185→182 (-1.6%) | MEDIUM — utilization at 56.5% with flat usage.
C-0BC34584 | Cole Ingram | $16,740 | 2026-10-22 (CZ=CB) | 327/494 = 66.2% | 104→104→106 (+1.9%) | LOW — 66.2% utilization and gently rising usage (+2.9% over 12 months).
C-0B7A7546 | Elena Sinclair | $35,062 | 2026-10-25 (CZ=CB) | 182/205 = 88.8% | 64→65→63 (-1.6%) | LOW — near-full seat utilization with usage up 8.6% over 12 months.
C-0B369871 | Dana Mercer | $85,128 | 2026-10-29 (CZ=CB) | 317/422 = 75.1% | 326→330→333 (+2.1%) | LOW — strong utilization and usage up every single month for a year (289 → 333).
C-0B144C78 | Cole Ingram | $30,899 | 2026-11-02 (CZ=CB) | 169/224 = 75.4% | 101→101→106 (+5.0%) | LOW — 75.4% utilization and usage up 17.8% over 12 months.
C-0FC4DBB8 | Elena Sinclair | $94,732 | 2026-11-05 (CZ=CB) | 356/464 = 76.7% | 189→191→193 (+2.1%) | LOW — largest contract in the book, 76.7% utilized with steady growth (168 → 193).
C-0D5BBE3A | Dana Mercer | $39,740 | 2026-11-09 (CZ=CB) | 85/102 = 83.3% | 88→90→91 (+3.4%) | LOW — high utilization and usage up 19.7% over 12 months.
C-0FB9D5AF | Cole Ingram | $63,158 | 2026-11-13 (CZ=CB) | 144/199 = 72.4% | 173→173→176 (+1.7%) | LOW — solid utilization with uninterrupted 12-month growth (154 → 176).
C-0B344485 | Elena Sinclair | $64,384 | 2026-11-16 (CZ=CB) | 224/287 = 78.0% | 238→240→244 (+2.5%) | LOW — 78.0% utilization and 12 straight months of growth (211 → 244).
C-0CB2C1B4 | Dana Mercer | $40,628 | 2026-11-20 (CZ=CB) | 386/473 = 81.6% | 47→48→49 (+4.3%) | LOW — highest utilization in the book with usage up 14.0% over 12 months.
C-22170CA1 | Cole Ingram | $45,646 | 2026-11-24 (CZ=CB) | 251/294 = 85.4% | 143→148→146 (+2.1%) | LOW — high utilization and usage up 12.3% over 12 months.

TOTALS (arithmetic shown)
Total ARR renewing in the 90-day window: $1,048,715.00 across 20 accounts.
  = 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
  Of that, $890,365.00 is still upcoming (17 accounts, 2026-09-26 onward) and $158,350.00 is already past due (65,901 + 54,427 + 38,022).

ARR at risk: $476,224.00 = 45.4% of total renewing.
  HIGH (3): 30,993 + 90,647 + 79,419 = $201,059.00
  MEDIUM (3): 21,770 + 48,815 + 46,230 = $116,815.00
  Past-due (3, all with double-digit 3-month usage declines): $158,350.00
  = 201,059 + 116,815 + 158,350 = $476,224.00
  If you count only upcoming renewals, at-risk ARR is $317,874.00 (HIGH + MEDIUM) = 35.7% of the $890,365.00 upcoming base.

Caveats: "today" is my assumption (session date), so the past-due/upcoming split shifts if run on a different day; risk ratings use the rubric above since no company rubric was supplied; CSM, ARR, seats, and seats_used come from the ChurnZero file, which was only overridden for renewal dates.

Read all 80 ticket bodies (Jun 1 – Aug 29, 2026), ignoring the tag column (tags are unreliable: the same complaint text carries tags ranging from bug to how-to to billing). Grouped by complaint text, then by underlying system. ARR affected = sum of distinct-account ARR per theme (no account appears in more than one theme, so the sums are non-overlapping). Total base: 80 tickets, 24 distinct accounts, $284,800 distinct-account ARR.

THEMES, RANKED BY ARR EXPOSURE

1. HRIS PROVISIONING FAILURE — NEW HIRES NOT CREATED
   Count: 12 tickets (15.0% of 80). Share of account ARR: 40.0%
   Distinct accounts: 3 — C-0B2213A9 (7 tickets), C-0DDFC9A7 (3), C-0F6C0F34 (2)
   ARR affected: $114,000 = 36,000 + 48,000 + 30,000
   Example tickets: IC-460059, IC-460060
   Note: three complaint texts, one root system ("HRIS sync skipped 12 new hires; provisioning log shows no errors" — silent failure).
   Rec: Top engineering escalation — silent provisioning failures at your three largest affected accounts block new-hire onboarding for a full quarter.

2. REDEMPTION / CHECKOUT FAILURE (GIFT CARDS)
   Count: 18 tickets (22.5%). Share of account ARR: 24.2%
   Distinct accounts: 7 — C-0B827671 (4), C-0CEF69FD (3), C-0FCCD2DF (3), C-0F876796 (3), C-14264ABD (3), C-0D9CA315 (1), C-0B0F1BAB (1)
   ARR affected: $68,800 = 10,700 + 8,900 + 9,600 + 8,700 + 11,000 + 9,600 + 10,300
   Example tickets: IC-460025, IC-460038
   Note: two failure modes in the text — checkout hang ("spins forever") and failed order with points still deducted (money-losing defect).
   Rec: Make failed gift-card orders auto-refund deducted points and fix the checkout timeout; this is the only theme where customers lose value outright.

3. BILLING / INVOICING ERRORS — SINGLE ACCOUNT
   Count: 16 tickets (20.0%). Share of account ARR: 18.3%
   Distinct accounts: 1 — C-0E9C27D1 only
   ARR affected: $52,000
   Example tickets: IC-460071, IC-460078
   Note: four complaint texts (seat-count error, 200-vs-150 seat overcharge, unapproved seat count, wrong renewal tier price), all one account, recurring all quarter.
   Rec: This is single-account noise, not a broad pattern — treat as a named-account save play: dedicated CSM/billing owner to re-issue corrected invoices on the $52k renewal before it churns.

4. POINTS LEDGER NOT POSTING
   Count: 20 tickets (25.0% — highest volume). Share of account ARR: 10.9%
   Distinct accounts: 9 — C-0D3278C7 (3), C-0BE96399 (3), C-0D284E42 (3), C-0D6CC8E3 (3), C-0BF20542 (2), C-0D0B047C (2), C-0DD0626C (2), C-21FEBCBB (1), C-0B2895EF (1)
   ARR affected: $31,100 = 3,500 + 2,700 + 3,400 + 4,200 + 4,500 + 4,500 + 2,500 + 2,900 + 2,900
   Example tickets: IC-460001, IC-460004
   Note: "after the weekend" and "since Tuesday" phrasing points to a batch/posting job failure, not one-off bugs.
   Rec: Highest ticket volume but smallest accounts — investigate the weekend ledger batch job; cheap to fix and stops 25% of ticket load.

5. SLACK INTEGRATION BREAKAGE
   Count: 14 tickets (17.5%). Share of account ARR: 6.6%
   Distinct accounts: 4 — C-0BA71F12 (6), C-10A56B0F (4), C-0B843542 (3), C-8C2E8F00 (1)
   ARR affected: $18,900 = 3,900 + 5,400 + 4,400 + 5,200
   Example tickets: IC-460047, IC-460046
   Note: "sync toggle resets itself" and "re-auth does not stick" suggest token/settings persistence, not a Slack-side outage.
   Rec: Fix OAuth token/refresh persistence — 6 of 14 tickets are one $3.9k account (C-0BA71F12), so partially single-account noise, but the symptom is identical across all four.

SUM CHECK: 12 + 18 + 16 + 20 + 14 = 80 tickets; 114,000 + 68,800 + 52,000 + 31,100 + 18,900 = 284,800 = total distinct-account ARR. All 80 tickets assigned, none left over.

BROAD PATTERN VS SINGLE-ACCOUNT NOISE
- Broad patterns (multi-account, same root cause): HRIS (3 accounts), redemption (7), points ledger (9), Slack (4, though skewed by C-0BA71F12).
- Single-account noise: the entire billing theme is C-0E9C27D1 (16 tickets, 20% of volume, 1 account) — high ARR exposure but one customer's broken invoicing, not a systemic defect.

DATA NOT PROVIDED (limits on this analysis): no ticket status/resolution dates (can't confirm open vs closed), no per-ticket monetary amounts at risk (ARR is the only exposure proxy), no seat counts per account, and no product area beyond what the text implies.

RANKING (prospect C-82AF3719: Technology / Mid-Market / employee_recognition / NA-West)

Method: 1 point per exact match across the four fields (industry, size_band, use_case, region); max 4. Only customers with has_case_study=true are eligible — 8 of 25 qualify. Ties broken by the field priority in your prompt (industry > size band > use case > region), i.e. the match missing the least-important field ranks higher.

1. C-64171065 — 3/4
   Matched: industry (Technology), size_band (Mid-Market), use_case (employee_recognition). Missed: region only (NA-East vs NA-West).
   Case study: yes.

2. C-A13C193D — 3/4
   Matched: industry (Technology), size_band (Mid-Market), region (NA-West). Missed: use_case (retention vs employee_recognition).
   Case study: yes.

3. C-11C31562 — 3/4
   Matched: size_band (Mid-Market), use_case (employee_recognition), region (NA-West). Missed: industry (Manufacturing vs Technology).
   Case study: yes.

Arithmetic shown: all three candidates score 3 exact field matches out of 4; the 8 case-study customers at 2/4 or 0/4 (e.g. C-9D69D147, C-CD4829A7) rank below them. No 4/4 case-study customer exists.

Data caveats:
- Two customers in the file match the prospect 4/4 on all fields, but both have has_case_study=false. Per your rule they are excluded and are not named here. So no perfect-profile social proof exists in this dataset.
- The file contains no billing data and no contact-name fields, so none can appear in this ranking.
- Fields available for similarity were exactly industry, size_band, use_case, region, and has_case_study — nothing else; any other dimension (headcount, product tier, tenure) is absent from the source.

All figures below are computed from the two files only. Verification first: 122 contact rows, all unique contact_keys, every row has an sqm_date, all dates fall within 2026-03-01 to 2026-08-31 (the 6-month window), and pipeline_amount > 0 exactly where sqo_date is present. Trailing 6 months = 2026-03 through 2026-08.

PAID CHANNELS

```
channel        spend    SQMs  SQOs  cost/SQM   cost/SQO   SQM->SQO  pipeline    pipeline/$
paid_search    36,000   40    18    900        2,000      45.0%     720,000     20.00
linkedin_ads   24,000   25    8     960        3,000      32.0%     96,000      4.00
paid_social    18,000   0     0     undefined  undefined  undefined 0           undefined
webinars        9,000   12    5     750        1,800      41.7%     60,000      6.67
TOTAL          87,000   77    31                                     876,000     10.07
```

Arithmetic:
- paid_search: 6 x 6,000 = 36,000; 36,000/40 = 900; 36,000/18 = 2,000; 18/40 = 0.450; 18 x 40,000 = 720,000; 720,000/36,000 = 20.00
- linkedin_ads: 6 x 4,000 = 24,000; 24,000/25 = 960; 24,000/8 = 3,000; 8/25 = 0.320; 8 x 12,000 = 96,000; 96,000/24,000 = 4.00
- paid_social: 6 x 3,000 = 18,000; zero SQMs in contacts_first_touch.csv, so cost/SQM, cost/SQO, conversion, and pipeline per dollar are UNDEFINED (not zero) — the file does not distinguish "produced nothing" from "not tracked."
- webinars: 6 x 1,500 = 9,000; 9,000/12 = 750; 9,000/5 = 1,800; 5/12 = 0.4167; 5 x 12,000 = 60,000; 60,000/9,000 = 6.67
- Paid total pipeline per dollar: 876,000/87,000 = 10.07 (or 876,000/69,000 = 12.70 if paid_social's spend is excluded from the denominator).

ORGANIC CHANNELS (no spend recorded; spend-based metrics not applicable)

```
channel          SQMs  SQOs  SQO rate  pipeline
organic_search   30    10    33.3%     90,000
referral         15    6     40.0%     48,000
```

Arithmetic: organic_search 10/30 = 0.333, 10 x 9,000 = 90,000; referral 6/15 = 0.400, 6 x 8,000 = 48,000.

DATA INTEGRITY FLAGS (SQO date precedes SQM date)

- CT-000044, linkedin_ads: SQO 2026-07-18 precedes SQM 2026-07-23 (by 5 days)
- CT-000041, linkedin_ads: SQO 2026-06-09 precedes SQM 2026-06-14 (by 5 days)

Both flags are linkedin_ads rows and both are counted as SQOs above. Excluding them, linkedin_ads becomes 6 SQOs / 23 SQMs = 26.1%, cost/SQO = 24,000/6 = 4,000, pipeline = 6 x 12,000 = 72,000, pipeline per dollar = 3.00 — worse on every metric. (Also noted, not a violation: CT-000007, paid_search, has SQO date = SQM date, same day.)

DATA GAPS AND CAVEATS

- paid_social appears in channel_spend.csv ($18,000) but has zero rows in contacts_first_touch.csv. Missing data: whether that reflects true zero output or an attribution failure. Treat as undefined, verify before cutting.
- Webinars recorded zero SQMs in August despite $1,500 August spend (all 12 webinar SQMs are Mar–Jul); SQM lag or decay, unresolvable from this data.
- Deal sizes are uniform within each channel (paid_search 40,000; linkedin_ads 12,000; webinars 12,000; organic_search 9,000; referral 8,000), so pipeline per dollar is heavily driven by per-deal value, not just conversion efficiency.

REALLOCATION RECOMMENDATION

1. paid_social: hold a small verification budget (e.g., 3,000–6,000/month) for one month while confirming tracking/UTMs. Six months and $18,000 with zero tracked SQMs is either the worst channel in the dataset or a measurement failure — the data cannot say which. If verified as genuinely zero-output, cut to zero.
2. paid_search: primary destination for reallocated dollars. Best pipeline per dollar (20.00 vs 4.00–6.67) and lowest cost per SQO among high-volume channels (2,000). At observed efficiency, each $1,000 shifted yields ~0.5 SQOs and ~20,000 pipeline (1,000/2,000 = 0.5 SQOs; 0.5 x 40,000 = 20,000) — linear extrapolation, subject to diminishing returns.
3. webinars: modest increase. Best cost per SQM (750) and best cost per SQO (1,800), but only 5 SQOs total and a dead August — scale gradually, re-measure monthly.
4. linkedin_ads: trim ~20–25% (24,000 → ~18,000–21,000) pending a data fix. It is worst on cost/SQM, cost/SQO, and pipeline per dollar among channels with SQMs, it contains both date-integrity flags, and its clean-row rate (26.1%) is the lowest of any channel. The trim is a hedge, not a kill — the gap vs paid_search is within sampling noise.

Illustrative next-month split at the same $14,500/month total: paid_search 8,000 (from 6,000), webinars 2,000 (from 1,500), linkedin 3,500 (from 4,000), paid_social 1,000 verification hold (from 3,000).

CONFIDENCE: LOW to MODERATE

- Sample sizes are small: 18 SQOs (paid_search), 8 (linkedin_ads), 5 (webinars), 0 (paid_social), 10 and 6 for the organic channels. Approximate 95% CIs on SQM-to-SQO rates overlap heavily: paid_search 30–60%, linkedin_ads 14–50%, webinars 14–70%, organic_search 16–50%, referral 15–65%. The paid_search vs linkedin_ads rate gap (45.0% vs 32.0%) is not statistically significant (z ≈ 1.07, p ≈ 0.29); after excluding the two flagged linkedin rows the gap widens (45.0% vs 26.1%) but remains within noise.
- The two defensible directional claims: paid_social produced no tracked SQMs (undefined efficiency, real verification task), and paid_search leads every efficiency metric — though its pipeline advantage is partly a 40,000 vs 12,000 deal-size artifact.
- Given that, the reallocation should be staged (verification hold on paid_social, incremental shifts, not a full reweighting) and re-measured after 1–2 months. Missing data that would raise confidence: paid_social tracking status, corrected dates for CT-000044 and CT-000041, and per-channel deal counts beyond this window.

# Battlecard: Rivally (updated 2026-09-24)

Sources: competitor_snippets.csv (S01–S25), deals_with_competitor.csv. Per policy, rep opinions are excluded as facts (noted at end). Review-based claims are stated as reviewer-reported.

## One-line positioning
Points-based employee recognition for mid-market, now pushing EU enterprise expansion via an EMEA leadership hire, a Dublin office, and GA EU data residency (S02, S04, S11, S12, S15).

## Pricing
- Current list (newest source wins): Recognition Starter, $7 per user/month, annual billing required — pricing page, 2026-08-12 (S17).
- Conflict noted: the pricing page previously listed $5/user/month (2026-01-20, S03; still $5 on 2026-04-01, S08). Newer source wins → $7. That is a +40% list increase between 2026-04-01 and 2026-08-12: (7 − 5) / 5 = 40% (S08, S17).
- Quote evidence (prospect-reported in call notes, not list price):
  - $6.50/user/mo, annual term, quoted to a 500-seat prospect on 2026-06-02 (S13) — sits between the old $5 and new $7 list.
  - $7/user/mo list with 15% discount for a 3-year term, reported 2026-08-14 (S18) — effective $5.95/user/mo (7 × 0.85), corroborating the new $7 list.
- Add-on: Rivally Pulse survey add-on is priced separately, not bundled (S23, 2026-09-01). No Pulse price appears anywhere in the data.
- Data missing: no pricing info beyond Recognition Starter; "aggressive discounting" is rep opinion only and cannot be cited as fact (S21 — excluded).

## Where they win
- Engaging points-based recognition feed — repeatedly praised by reviewers (S02, S16).
- Fast mid-market time-to-value: setup under a week; Slack integration worked out of the box (S04).
- EU / distributed teams: EU data residency GA and Dublin office (S15); ex-Workday VP EMEA hired to lead European expansion (S11); multi-language support praised for distributed EU teams (S12). They actively pitch EU residency against us in competitive deals (S05).
- Responsive support: reviewer praises response times under 4 hours (S22).
- Product breadth: Pulse engagement survey add-on (S06, S23); Microsoft Teams app v2 in public preview (S19).
- Deal terms: 15% discount offered for a 3-year commitment, per prospect-reported quote (S18).

## Where we win
- Analytics/reporting depth: reviewers report limited analytics (S02), dashboards basic vs enterprise tools (S07), CSV-only analytics exports (S20). Direct evidence: an 800-seat prospect picked Bonusly over Rivally citing analytics depth (S25).
- Enterprise admin and IAM at scale: no SCIM provisioning; manual user management painful (S10); admin tooling lags peers (S16); no bulk recognition editing (S24).
- Data portability: analytics exports are CSV-only (S20) — a gap to press on data access/audit requirements.
- EMEA rewards: Rivally's EMEA rewards catalog is thinner than its US catalog (S14) — counter-angle in EU deals despite their residency pitch (S05, S15).
- Data missing: the snippets contain no claims about our own catalog, exports, SCIM, or support — press their documented gaps; do not assert un-sourced superiority on our side.

## Objections and responses
1. Objection: "Rivally has EU data residency." (pitched to a prospect: S05; GA: S15)
   Response: True — GA since 2026-07-01 (S15). Counter from the data: their EMEA rewards catalog is thinner than their US catalog (S14) — make EU users evaluate catalog depth in a live demo. [No data on our own EU residency in the provided snippets — verify internally before countering.]
2. Objection: "They'll do $7 with 15% off on a 3-year term." (S18)
   Response: Effective $5.95/user/mo (7 × 0.85) (S18), but their list rose $5 → $7 (+40%) in 2026 (S03, S08, S17) and a mid-year quote of $6.50 was observed (S13). Note "aggressive discounting" is rep opinion, not confirmed (S21 — excluded). [No data on our pricing in the snippets — check ours before countering on price.]
3. Objection: "Their recognition feed is more engaging." (S02, S16)
   Response: Feed engagement is consistently praised (S02, S16) — but the same reviewers flag admin tooling lagging peers (S16), no bulk recognition editing (S24), and CSV-only exports (S20). For analytics-driven buyers this is why we won an 800-seat deal (S25).
4. Objection: "Setup is fast and Slack works out of the box." (S04)
   Response: Documented for mid-market (S04). At enterprise scale their reviewers report no SCIM and painful manual user management (S10) — setup speed ≠ ongoing admin cost. [No data on our setup time or Slack integration — reframe rather than counter-claim.]
5. Objection: "Their support is faster." (S22)
   Response: Under-4-hour response is reviewer-praised (S22). [No data on our support response times — don't counter on support; pivot to analytics and admin gaps (S02, S07, S10).]
6. Objection: "They have an engagement survey add-on too." (S06, S23)
   Response: Pulse only exited beta 2026-09-01 and is priced as a separate paid add-on, not bundled (S06, S23) — no price is published in our data, so make them quote it line-item.

## Recent changes (last 12 months)
- 2025-11-04: Series C, $40M, led by Northgate Ventures (S01).
- 2026-03-05: Launched Rivally Pulse survey add-on; exited beta 2026-09-01 as a separate paid add-on (S06, S23).
- 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: List price increased $5 → $7/user/mo (S08, S17).
- 2026-08-20: Microsoft Teams app v2 public preview (S19).

## Our 12-month win/loss record vs Rivally
Window: 2025-09 through 2026-08 — the 12 months covered by deals_with_competitor.csv (no Rivally deals in the data after 2026-08).

By month (aliases exactly as given; source: deals_with_competitor.csv):
- 2025-09: Deal-7767F5 loss, Deal-072E31 win (1–1)
- 2025-10: Deal-A9FD43 win, Deal-F65C8F win (2–0)
- 2025-11: Deal-7AA785 win, Deal-D263E0 loss (1–1)
- 2025-12: Deal-44C524 win, Deal-935746 loss (1–1)
- 2026-01: Deal-0D0CD6 win, Deal-E46EAB win (2–0)
- 2026-02: Deal-D5B790 win, Deal-1D2392 win (2–0)
- 2026-03: Deal-5C636E win, Deal-9066A6 loss (1–1)
- 2026-04: Deal-5645A5 loss, Deal-72A02F loss (0–2)
- 2026-05: Deal-C6FFAA loss (0–1)
- 2026-06: Deal-67BE14 win (1–0)
- 2026-07: Deal-1B6969 win (1–0)
- 2026-08: Deal-F03E7B win (1–0)

Arithmetic: wins 1+2+1+1+2+2+1+0+0+1+1+1 = 13; losses 1+0+1+1+0+0+1+2+1+0+0+0 = 7; total 13 + 7 = 20 deals; win rate 13/20 = 65%.
Trend: Sep 2025–Feb 2026: 9W–3L (9/12 = 75%); Mar–May 2026: 1W–4L (1/5 = 20%); Jun–Aug 2026: 3W–0L (3/3 = 100%).
Data missing: the deals file records no win/loss reasons. The only sourced reason for choosing us over Rivally is analytics depth (S25, 800-seat prospect), which is not tied to any alias above.

## Old-card claims: re-sourced status
- "Points-based recognition for mid-market" — re-sourced (S02, S04); updated above to include the EU enterprise push (S11, S15).
- "Starts at $5/user/month, annual billing (as of 2026-01)" — accurate as of 2026-01-20 (S03) but superseded by the 2026-08-12 page: now $7 (S17).
- "Rivally lacks a Slack integration" — CONTRADICTED: Slack integration worked out of the box (S04, 2026-02-02). Remove from the card.
- "Acquired by Workhuman in 2025" — UNVERIFIED: no snippet mentions an acquisition or Workhuman; cannot re-source. (S11 references a hire from Workday — a different company — and is not acquisition evidence.) Do not use until independently confirmed.
- "Strong in EU enterprise with multi-language support" — re-sourced (S12).

Excluded as rep opinions (not facts about the competitor): S09 (AE Bryce Harmon: "UI is clunky," not verified against the product) and S21 (AE Elena Sinclair: "discounting aggressively," not confirmed).

SEQUENCE SCORECARD (rates = per step sent; sequence rates = per total sent)

New Logo Nurture — sent 1386 (500/458/428). Open 490/1386=35.4%. Reply 90/1386=6.5%. Meetings 27/1386=1.9%. Weakest: step 3 (120/428=28.0% open, 18/428=4.2% reply) — normal decay, healthy.

Expansion Nurture — sent 875 (300/300/275). Open 565/875=64.6% (invalid, see error). Reply 59/875=6.7%. Meetings 12/875=1.4%. Weakest valid step: 3 (95/275=34.5% open, 12/275=4.4% reply).

Cold Outbound - HR Leaders — sent 1785 (600/595/590). Open 545/1785=30.5%. Reply 8/1785=0.45%. Meetings 0/1785=0.0%. Weakest: step 3 (130/590=22.0% open, 1/590=0.17% reply).

Cold Outbound - People Ops — sent 1163 (400/386/377). Open 340/1163=29.2%. Reply 29/1163=2.5%. Meetings 6/1163=0.5%. Weakest: step 3 (80/377=21.2% open, 6/377=1.6% reply).

TRACKING ERROR
Expansion Nurture step 2: opened 340 > sent 300 (113.3%) — impossible. Open pixel is double-counting or misattributing (likely bot/security-scanner opens). Its sequence-level 64.6% open rate is unreliable until fixed.

AUDIENCE OVERLAP
963 rows, 940 unique contacts — 23 contacts in two sequences:
- Cold Outbound - HR Leaders <-> Cold Outbound - People Ops (21): CT-000849, CT-000884, CT-000890, CT-000908, CT-001033, CT-001097, CT-001101, CT-001103, CT-001105, CT-001130, CT-001153, CT-001159, CT-001217, CT-001227, CT-001236, CT-001255, CT-001258, CT-001277, CT-001285, CT-001311, CT-001345
- Expansion Nurture <-> New Logo Nurture (2): CT-000301, CT-000624
Cross-mailing the same contacts inflates fatigue and muddles reply attribution.

FAILURE MODES (<2% REPLY)
- Cold Outbound - HR Leaders, every step (0.83% / 0.34% / 0.17%): opens are fine (30.5%) but replies and meetings collapse. Message-audience mismatch, not deliverability — they read it and don't respond.
- Cold Outbound - People Ops step 3 (1.59%): sequence fatigue — reply decays 3.5% -> 2.3% -> 1.6%.

ONE CHANGE PER WEAK SEQUENCE
- Cold Outbound - HR Leaders: rebuild the message/offer for the HR-leader persona; deliverability is not the constraint.
- Cold Outbound - People Ops: cut or replace step 3; steps 1-2 carry the sequence.

FIX FIRST: Cold Outbound - HR Leaders — 1785/5209 = 34.3% of all send volume, 0.45% reply, 0 meetings. Largest recoverable waste in the data.

Pace basis: 66 of 92 days elapsed → 66/92 = 71.7% through the quarter. Expected-at-pace = target × 66/92. All figures below are exactly as given in the three files; no external data was used.

QTD SCORECARD — Q3-2026 (66/92 days, 71.7% elapsed)

1. SQMs
   Actual 230 | Target 300 | Delta −70
   Expected at pace: 300 × 0.717 = 215.2 → 230 vs 215.2 = 106.9% of pace
   Pace: AHEAD of pace (76.7% of full-quarter target)

2. SQOs
   Actual 84 | Target 120 | Delta −36
   Expected at pace: 120 × 0.717 = 86.1 → 84 vs 86.1 = 97.6% of pace
   Pace: BEHIND pace, marginally (70.0% of target)

3. DS2s
   Actual 40 | Target 75 | Delta −35
   Expected at pace: 75 × 0.717 = 53.8 → 40 vs 53.8 = 74.3% of pace
   Pace: BEHIND (largest funnel gap; 53.3% of target)

4. Closed-lost MIA rate
   Actual: 5 MIA ÷ 25 closed-lost = 0.20 (20%) | Target 0.10 (10%), lower_better | Delta +0.10 (2.0× target)
   At the target rate, 25 closed-lost would imply 2.5 MIA (25 × 0.10); actual is 5
   Pace: BEHIND (rate metrics are not time-pro-rated; 20% is worse than the 10% target at any point in the quarter)

5. Same-quarter closes
   Actual 10 | Target 20 | Delta −10
   Expected at pace: 20 × 0.717 = 14.3 → 10 vs 14.3 = 69.7% of pace
   Pace: BEHIND (50.0% of target)

6. Active pipeline (coverage vs target)
   Actual $3,000,000 | Target $4,000,000 | Delta −$1,000,000 | Coverage: 3,000,000 ÷ 4,000,000 = 75.0%
   Expected at pace: 4,000,000 × 0.717 = $2,869,565 → $3.0M vs $2.87M = 104.5% of pace
   Pace: AHEAD of pace (75.0% of target)

WHAT MOVED THIS WEEK: Not computable from the data provided. The three files contain only current QTD snapshots, quarter targets, and quarter metadata — no prior-week values, week-stamped history, or period-over-period deltas for any metric, and no deal-level or company-level records at all (so no aliases exist to cite). I cannot state what moved this week without inventing numbers, which you've prohibited. What is knowable from the data: quarter-to-date, top-of-funnel volume (SQMs, active pipeline) is tracking at or ahead of the 71.7% elapsed pace, while conversion depth (DS2s, same-quarter closes) and the closed-lost MIA rate are behind target; if you can supply last week's QTD snapshot, I'll compute the exact week-over-week deltas.

Q3 weighted forecast is 115,976.75: 7 COMMIT deals at 44,729 plus 35% of 203,565 across 24 BEST_CASE (71,247.75), with 54 of 86 deals in quarter and 23 PIPELINE at zero. 32 deals totaling 227,575 close after 2026-09-30 and are excluded, including COMMIT Deal-D348E1 at 13,770 (2026-10-15). Caveat: why-buys are empty on all 7 in-quarter COMMIT deals and owner blank on 85 of 86, so the 44,729 commitment has no documented reason to buy.

**Follow-up email — Deal-0D2F7A (owner: Alex Franklin)**

Subject: Following up — pricing recap for 150 seats

Hi [Name],

Following up on the pricing recap I sent on August 5 for 150 seats — I wanted to make sure it didn't get buried.

Since birthdays and anniversaries are tracked manually today, the automated milestone awards and points catalog your team had such a strong reaction to would take that work entirely off your plate.

Could we set up a quick call to walk through the pricing and any open questions?

Best regards,
Alex Franklin

---

**Notes:**
- Word count (incl. subject + sign-off): 7 + 2 + 23 + 31 + 16 + 4 = **83 words** (under 120).
- Prior touch referenced: ENG-00001 — the 2026-08-05 email with pricing for 150 seats (no reply). Value points (automated milestone awards, points catalog, manual birthday/anniversary tracking) are taken from ENG-00002 and ENG-00003.
- One clear ask: a call to walk through the pricing.
- Missing data: no contact name or email address is provided in the files — hence the [Name] placeholder.

**Marketing:** Marketing landed 46 SQMs against a target of 52, finishing 6 short (52 − 46 = 6). The webinar channel delivered 18 of them, just over a third of the week's total (18 ÷ 46 = 39.1%). Cost per SQM on paid search held at $150. No prior-week numbers appear in the extract, so there is no trend to call yet; the webinar share is the standout.

**Sales:** Sales converted 14 SQOs and set 9 DS2 meetings. New pipeline created was $310,000, and the same-quarter close count for the week was 3. The extract does not include average deal size or win rate, so pipeline quality waits for next week's read.

**CS:** CS saved 2 renewals this week. Team NPS moved to 61, and 3 red-flag accounts stay open heading into next week. The extract gives the flag count only, with no detail on what is driving each one.

**PLG:** PLG added 412 new signups with activation at 31 percent, which works out to roughly 128 activated signups (0.31 × 412 = 127.72). 38 companies reached the aha moment of 10 recognition gives. Paid conversion is not in the extract, so signup volume and the aha count carry this week's story.

PARTNER DIGEST — Period: 2026-08-24 to 2026-09-04 (per #partners Slack export window)

TOTALS (from partner_deals.csv; all 5 rows carry utm_source=Partner)
- Partner-sourced deals: 5
- Partner-sourced pipeline: $550,000
- Arithmetic: 180,000 + 95,000 + 140,000 + 60,000 + 75,000 = 550,000

ACTIVE PARTNERS (4)

1. Apex Rewards Co — 2 sourced deals, $275,000
   - Deal-DDAAF2: $180,000; Deal-2CF33E: $95,000 → 180,000 + 95,000 = 275,000
   - Both in DS1 per Slack 2026-08-25; both logged with UTM Source = Partner (confirmed by Cole Ingram).
   - Co-webinar locked for 09-15.

2. HRCloud Partners — 1 sourced deal, $140,000
   - Deal-F1CDA5: $140,000
   - Moved to DS2 per Slack 2026-08-27 after the integration referral closed security review.

3. CultureBridge — 2 sourced deals, $135,000
   - Deal-096E1D: $60,000; Deal-067213: $75,000 → 60,000 + 75,000 = 135,000
   - Sourced via lunch-and-learn; stage given only as "early stage" per Slack 2026-08-29 (no DS number in the data).

4. WorkWell Group — 0 sourced deals, $0
   - No rows in partner_deals.csv this period, consistent with Slack ("no sourced deals this period").
   - Wants to restart joint playbook in Q4; planning call booked for 09-09.

QUIET PARTNERS (4)
- Recogniq: No sourced deals in partner_deals.csv; no messages in the Slack export window.
- KudosWave: No sourced deals in partner_deals.csv; no messages in the Slack export window.
- PeopleFirst Advisors: No sourced deals in partner_deals.csv; no messages in the Slack export window.
- TotalPerk: No sourced deals in partner_deals.csv; no messages in the Slack export window.

RECONCILIATION
- Roster: 8 partners → 8 in digest (4 active, 4 quiet), each appearing once.
- Deal check: 5 partner-sourced deals, $550,000 — matches partner_deals.csv row-for-row (2 Apex + 1 HRCloud + 2 CultureBridge; WorkWell 0).

DATA GAPS (stated explicitly)
- partner_deals.csv has no stage column; all stage references (DS1, DS2, "early stage") come from dated Slack messages and are point-in-time as of those dates.
- CultureBridge stage is given only as "early stage"; no DS number is provided.
- Currency is not specified in the data; amounts are reported exactly as given.
- No data beyond the roster exists for the four quiet partners.

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

Q2. Is data encrypted in transit?
Yes. Data in transit is encrypted with TLS 1.2 or higher. [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. [P2]

Q4. How long is customer data retained after contract termination?
Retention = contract duration + 90 days. Arithmetic: data is held for the full term plus 90 days, so post-termination retention is 90 days, after which data is deleted from production systems. [P3]

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

Q6. Do you support SAML single sign-on?
Yes. SAML 2. single sign-on is available on the Enterprise plan. [P5]

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

Q8. Do you hold an ISO 27001 certification?
Unanswerable. No excerpt addresses ISO 27001 certification. This would be answered by an ISO 27001 certificate or the certifications section of the trust portal. We do not guess.

Q9. What is your contractual uptime SLA percentage?
Unanswerable. No excerpt states an uptime SLA percentage. This would be answered by the SLA exhibit of our SaaS agreement / master service agreement. We do not guess.

Q10. Will you sign a HIPAA Business Associate Agreement?
Unanswerable. No excerpt addresses HIPAA or Business Associate Agreements. This would be answered by our legal team's BAA policy or the executed DPA / contract terms. We do not guess.

Note: no other arithmetic applies — the only quantitative values in the excerpts are 90 days (P3), 30 days (P4), 35 days (P6), and 72 hours (P7, not asked here), all quoted as stated.

RECONCILIATION: skill_manifest.csv (14 rows) vs 14 SKILL.md files. 16 findings. Arithmetic and exact citations shown per finding.

=================================================================
(1) ALWAYS-TRIGGER OVERLAP / DUPLICATION — 3 pairs
=================================================================

F1. comms-drafter vs email-drafter — CRITICAL — MERGE
Both descriptions ALWAYS-trigger on the same phrases. Shared verbatim triggers (5):
- "write me an email" (in both), "draft a follow-up" (in both), "what should I say" (in both), "bump email" (in both), "contract nudge" (in both); near-match "help me reply" (comms-drafter) vs "help me reply to this" (email-drafter).
comms-drafter: "Trigger for: 'write me an email,' 'draft a follow-up,' 'help me reply,' ... 'bump email,' 'contract nudge,'"
email-drafter: "Also trigger when the user says 'write me an email,' 'draft a follow-up,' ... 'bump email,' or 'contract nudge' should use this skill."
Bodies also duplicate: identical Recommended/Option 2 Softer/Option 3 Firmer output format, identical 1–10 review flow, identical "Bonusly positioning" theme list, near-identical "Final standard" paragraph, and both carry the same lane marker to deal-strategy-coach.
Proposal (one): MERGE email-drafter into comms-drafter — comms-drafter survives (its scope "AEs, SDRs, CSMs, partnerships, rewards, ops" is a superset of email-drafter's "AEs, SDRs, and CSMs"); port email-drafter's unique Gmail-signature retrieval section into comms-drafter; repoint deal-strategy-coach's "use the `email-drafter` skill" reference to comms-drafter in the same change.

F2. weekly-pipeline-report vs pipeline-intelligence-report — WARNING — TRIM_DESC
Shared trigger phrases: "pipeline update" appears verbatim in both ALWAYS lists; "generate the pipeline report" (weekly) vs "run the pipeline report" (PIR); "what does pipeline look like" (weekly) vs "what's the pipeline look like" (PIR). Both produce pipeline HTML from the same sources (HubSpot + Snowflake + signalforge-reports design system).
Proposal: TRIM_DESC weekly-pipeline-report — remove the generic phrases ("run the pipeline update", "generate the pipeline report", "what does pipeline look like") and keep its unambiguous ones ("weekly pipeline report", "mid-month pipeline check", "give me this week's numbers"); PIR retains the generic pipeline asks, having declared itself "Master pipeline scoring skill — never answer pipeline questions inline without running it."

F3. deal-strategy-coach vs next-to-close — WARNING — TRIM_DESC
deal-strategy-coach: "Also trigger when a manager or VP ... asks which deals are likely to close"
next-to-close: "ALWAYS trigger for ... 'which deals are most likely to close'"
One word apart; the same user ask fires both.
Proposal: TRIM_DESC deal-strategy-coach — drop "asks which deals are likely to close" (keep the manager 1:1 / book-of-business context triggers) and leave deal-selection asks to next-to-close.

=================================================================
(2) CIRCULAR DELEGATION CHAIN — 1
=================================================================

F4. deal-strategy-coach ⇄ email-drafter — WARNING — UPDATE_BODY
The chain, named: deal-strategy-coach → email-drafter → deal-strategy-coach.
- deal-strategy-coach: "When drafting manager-to-prospect emails, use the `email-drafter` skill which automatically retrieves your Gmail signature..."
- email-drafter: "If the user needs strategic deal coaching ... point them to the `deal-strategy-coach` skill."
Both also claim the combined case with conflicting rules: email-drafter says "If they need both strategy and a draft, do the draft here and suggest deal-strategy-coach"; deal-strategy-coach says "guide first, draft second." A stalled-deal manager email satisfies both handoff conditions → potential ping-pong. comms-drafter mirrors the same leg ("For deep deal strategy, use deal-strategy-coach — this skill drafts, that skill diagnoses").
Proposal: UPDATE_BODY — break the cycle in one direction: deal-strategy-coach becomes the single entry point for deal-context messaging (diagnose, then delegate the draft exactly once); the drafting skill's strategy handoff becomes advisory text that never re-invokes. Apply the same one-way rule after any F1 merge, or the cycle merely relocates to comms-drafter ⇄ deal-strategy-coach.

=================================================================
(3) DANGLING DELEGATION TARGETS — 5
=================================================================
None of the following have a manifest row or a file in the provided set. Existence cannot be confirmed from the data provided; if this manifest is the complete skill register, they are dangling.

F5. bonusly-brand — CRITICAL — REVIEW
Referenced as a mandatory gate by 4 skills: comms-drafter Step 0 ("Before drafting any communication, apply the `bonusly-brand` skill"), email-drafter ("apply the bonusly-brand org skill to ensure tone, language, and style are on-brand"), sales-forecast ("Always reference `bonusly-brand` skill for full voice, color, and typography guidance"), signalforge-claim-compressor (description: "use bonusly-brand for those"). Two skills fail their Step 0 if it is absent.
Proposal: REVIEW — confirm existence; add a manifest row (or annotate as external dependency), or strip the mandatory-gate wording from comms-drafter and email-drafter.

F6. prospect-research-multithreading — WARNING — REVIEW
Referenced by 3 skills: comms-drafter ("invoke `prospect-research-multithreading` in Contact Lookup mode first"), email-drafter (same gate, plus multithread CC lookups), deal-strategy-coach (Cross-skill handoff section: "Invoke **prospect-research-multithreading** whenever..." / "always offer the handoff").
Proposal: REVIEW — verify and register, or repoint the three references.

F7. skill-orchestrator — WARNING — REVIEW
Referenced by analysis-validator §11 ("Check cascading files: ... `skill-orchestrator`") and signalforge-feedback's activation checklist ("Skill registered in skill-orchestrator as a terminal step for Report/Synthesis and Analysis/Diagnosis archetypes").
Proposal: REVIEW — verify and register, or remove the dependency from the activation checklist.

F8. signalforge-reports (org skill) — WARNING — REVIEW
Mandatory pre-build reads in pipeline-intelligence-report Phase 5 ("Read `/mnt/skills/organization/signalforge-reports/SKILL.md`" + DESIGN-SYSTEM.md + signalforge.css) and weekly-pipeline-report (same three reads before any HTML).
Proposal: REVIEW — verify the paths resolve; register the dependency.

F9. Eight specialist skills + xlsx — INFO — REVIEW
analysis-validator §12.4 delegates to: 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 (8 targets, none in manifest/files). stale-pipeline-report also depends on `/mnt/skills/public/xlsx/scripts/recalc.py`.
Proposal: REVIEW — register external dependencies in the manifest or annotate §12.4 as pointing outside this set.

=================================================================
(4) VERSION CONFLICT — 1
=================================================================

F10. analysis-validator v3.2 vs v3.6 — WARNING — UPDATE_BODY — v3.6 survives
Conflict inside analysis-validator, corroborated cross-skill:
- Current: header "**Version:** 3.6", "**Last Updated:** May 9, 2026 (v3.6 — G2-F: ID Resolution...)", changelog top row "3.6 | May 9, 2026", footer "analysis-validator v3.6 · May 9, 2026".
- Stale: §7 trail template hardcodes "Validator: analysis-validator v3.2".
- Cross-skill: pipeline-intelligence-report's footer stamps "✓ SignalForge Validated · Analysis Validator v3.6".
Every Full-Mode validation trail would publish a wrong version stamp. v3.6 survives (header, changelog, footer, and PIR's reference all agree on it). Supporting evidence of version-management drift: the changelog table runs 1.0, 2.0, 2.6, 3.6, 3.5, 3.4, 3.3, 3.2, 3.1, 3.0 — the 3.6 row sits out of sequence between 2.6 and 3.5.
Proposal: UPDATE_BODY — set the §7 template line to v3.6 (or a version variable) and correct changelog ordering in the same edit. No other version conflict exists between skills; the only skill-vs-skill supersession question is F1, where comms-drafter is the proposed survivor.

=================================================================
(5) DESCRIPTIONS EXCEEDING 1,024 CHARACTERS
=================================================================

F11. Count = 0 — INFO — REVIEW
Manifest description_chars (n=14): 656, 897, 996, 792, 965, 676, 945, 1004, 1006, 962, 1006, 708, 762, 656.
Test each against 1,024: 656<1024 ✓, 897<1024 ✓, 996<1024 ✓, 792<1024 ✓, 965<1024 ✓, 676<1024 ✓, 945<1024 ✓, 1004<1024 ✓, 1006<1024 ✓, 962<1024 ✓, 1006<1024 ✓, 708<1024 ✓, 762<1024 ✓, 656<1024 ✓.
Count(>1024) = 0 of 14. Max = 1006; headroom = 1024 − 1006 = 18.
Proposal: REVIEW — no TRIM_DESC needed today, but three descriptions sit within 20 characters of the cap (partner-digest 1004, pipeline-intelligence-report 1006, signalforge-claim-compressor 1006); one added ALWAYS-phrase would cross it.

=================================================================
(6) HARDCODED PAGE IDs / DATES / PERSON NAMES — 4
=================================================================

F12. weekly-pipeline-report hardcodes a closed quarter — CRITICAL — UPDATE_BODY
Body: "Business days complete in Q2 (April 1 – June 30, 2026; total ≈ 64–65)" and "Q1 2026 context (static): Sales Bookings Actual: $365,152 vs. $475,000 plan (77%); Pipeline Addition Actual: $2,490,532 vs. $3,288,000 forecast (76%)".
Arithmetic: current date is Friday, September 25, 2026, which falls in Q3 2026 (Jul 1–Sep 30). Q2 2026 ended June 30 — 87 days ago (Jul 31 + Aug 31 + Sep 25 = 87). A run today paces every metric against a closed quarter, and Step 2A reads targets for "the current month and remaining Q2 months."
Proposal: UPDATE_BODY — compute the active quarter at runtime (the exact fix sales-forecast v1.1 already applied: "Quarter-agnostic (Q2 → current quarter throughout)") and replace the static Q1 comparators with a live read from the bookings-forecast spreadsheet.

F13. Hardcoded person names and rosters — WARNING — UPDATE_BODY
- analysis-validator §12.3 "GTM Team Roster (Updated May 4, 2026)": 19 named people with owner IDs (Alaina Loori, Shealagh Coughlin, Bryce Harmon, Hugo Lindqvist, Dana Mercer, Alex Franklin, Cole Ingram, Gavin Porter, Colleen Perry, Ellie Barton, Ashley Reyer, Megan Franz, Elena Sinclair, Youssef Elkhateeb, Amanda Czenkus, Ben Castelli, Amani Phipps, John Thomas, Yasmin Wahid); escalation names "Manish or Amani" (G1-K HOLD output and §10).
- pipeline-intelligence-report Phase 1: "AE owner IDs (verified May 2026):" lists 5 names — and directly contradicts its own "System Constants (verify at run time — do not hardcode)" section. Roster conflict with the validator: "Core 6 AEs" (validator, includes Hugo Lindqvist 77260721) vs 5 (PIR). 6 − 5 = 1: Hugo Lindqvist missing from PIR.
- partner-digest: "Owner: Amani Phipps (RevOps / Partnerships)"; "DMs and threads involving Amani (search `from:<@U03QLMBL7AR>`)"; contacts Kelli, Jen Lee, Hani, Bryce, Sara.
- weekly-pipeline-report: "Ben Lavin · Demand Generation · Bonusly" (title); "deliver the HTML file to Ben".
- deal-strategy-coach: ".edu domains are not auto-disqualified — routed to Farid for manual qualification."
- sales-forecast: "Manager Forecast (Alaina / VP Sales view)"; changelog "Elena → Alaina (VP Sales)".
- signalforge-feedback: example title "Gavin Porter Rep Diagnostic".
Proposal: UPDATE_BODY — replace hardcoded rosters/owner maps with runtime resolution, the pattern stale-pipeline-report Phase 2 already mandates ("Never hardcode rep names or owner IDs... Resolve via `HubSpot:get_crm_objects`"); keep person names only in clearly-labeled examples. This also resolves the 6-vs-5 roster contradiction.

F14. Hardcoded Confluence/Drive page IDs — INFO — REVIEW
- partner-digest: cloudId 73fe98de-a4a3-4869-9f8a-bb1eeed4cf7f; spaceId 1958248479; folder 2286616609; pages 2286321666, 2265382925, 2236940297, 2237825028, 2239365136, 2238283777.
- sales-forecast: spaceId 2232811524; parent page 2232582148; cloudId 73fe98de-a4a3-4869-9f8a-bb1eeed4cf7f.
- signalforge-feedback: page 2295136266; parent 2234417154; Build Log page 2247295002; spaceId 2232811524; cloudId 73fe98de-a4a3-4869-9f8a-bb1eeed4cf7f.
- deal-strategy-coach: Confluence page 2257879045 (AE Excellence Playbook April 2026).
- weekly-pipeline-report: spreadsheet IDs 1CLZeOsElVDF_LF0ZG_t2nfwvhnZ6bpwqM_nX3WEYzcw and 1ENuaEcCuLjdKhMvp8FK3Ys1ek5Aw9ZuOZhsHJJFoB_k.
The same cloudId is hardcoded in 3 skills; space 2232811524 in 2. Adjacent non-page IDs also hardcoded: Slack channel C0561C1JCPJ (stale-pipeline-report), HubSpot org ID 1973303 (next-to-close, pipeline-intelligence-report, stale-pipeline-report).
Proposal: REVIEW — verify each ID is still the correct destination and centralize shared destinations (cloudId, spaces, folders) in one reference so a migration changes one place, not five skills.

F15. Other hardcoded dates — WARNING — UPDATE_BODY
- analysis-validator: "Created: April 26, 2026"; "Last Updated: May 9, 2026"; "as of May 4, 2026" (four places: CALL_SPOTLIGHT_BRIEF removal, CLOSEDWON_DEALS currency, Gong routing, roster); "Stale as of March 28, 2023"; "Expected ranges (as of May 2026 — will drift over time)" — partially mitigated because §8 mandates the live session-start query.
- model-selection: "last_checked: 2026-05-19" with its own rule "If today's date is more than 14 days past the `last_checked` date... run the self-update procedure." Arithmetic: 2026-05-19 → 2026-09-25 = 12 (rest of May) + 30 (Jun) + 31 (Jul) + 31 (Aug) + 25 (Sep) = 129 days. 129 > 14 → the registry is stale by its own rule at the current date.
- closed-lost-analysis: "In the 30-deal AI-field sample from May 2026: 10 of 10 deals"; "Lost to Motivosity on this in May 2026 (Softheon)"; "MinIO: rep vacation May 4–12"; "`ai_closed_lost_reason` field confirmed May 2026"; "`closed_lost_reason` field confirmed May 2026".
- partner-digest: "May 16, 2026 issue"; examples "Week of May 19, 2026" / "Week of June 2, 2026"; page title "Pipeline Partner Plays Q2/Q3 2026".
- pipeline-intelligence-report: "verified May 2026"; "last modified March 2023"; "v6 · May 2026"; "deprecated as of May 2026".
- deal-strategy-coach: "Pricing — 2026" table; "AE Excellence Playbook April 2026".
- sales-forecast: example "Q3 2026 Forecast Intelligence — July 9, 2026" (mitigated: "always use the active quarter"); changelog April 27, 2026.
- stale-pipeline-report: example dates 5/15, 5/19, 5/7; changelog 2026-06-10. signalforge-claim-compressor: changelog 2026-05-09.
Proposal: UPDATE_BODY — convert currency-sensitive stamps ("confirmed May 2026", "verified May 2026", last_checked) into run-time verification steps, the pattern analysis-validator §8 already models ("Do not use hardcoded figures... run this query block to get current anchors"); run model-selection's self-update procedure now given 129 > 14.

=================================================================
(7) MANIFEST DRIFT — BOTH DIRECTIONS
=================================================================

F16. Zero drift in both directions — INFO — no action required
Manifest rows: 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).
Skill files provided: 14. Name match on declared_name: 14/14.
Files with no manifest row: 14 − 14 = 0.
Manifest rows with no file: 14 − 14 = 0.
Data limitation, stated explicitly: the description_chars and body_lines columns cannot be fully re-verified from the rendered markdown (exact line counts are ambiguous in this format); a spot-check of description lengths was consistent with the declared values (e.g., analysis-validator declared 656). No proposal required beyond optionally re-verifying body_lines against the raw files.

=================================================================
SUMMARY
=================================================================
16 findings: 3 CRITICAL (F1 trigger duplication, F5 bonusly-brand dangling, F12 closed-quarter hardcode), 9 WARNING (F2, F3, F4, F6, F7, F8, F10, F13, F15), 4 INFO (F9, F11, F14, F16). Answers to the seven questions in order: (1) 3 overlapping pairs, worst = comms-drafter/email-drafter; (2) one cycle: deal-strategy-coach ⇄ email-drafter; (3) 10+ named dangling targets (bonusly-brand, prospect-research-multithreading, skill-orchestrator, signalforge-reports, 8 specialist skills, xlsx), unverifiable from provided data; (4) v3.2 vs v3.6 inside analysis-validator — v3.6 survives; (5) 0 of 14 descriptions exceed 1,024 (max 1006, headroom 18); (6) hardcoded items in 10 of 14 bodies (next-to-close, comms-drafter, email-drafter are clean); (7) 0 files without rows, 0 rows without files.

RUNBOOK — incident-2026-08-29-reward-queue (#incident-2026-08-29-reward-queue, resolved)

Sole source: the thread as supplied (M01–M10). No supplementary details added. "Needs confirmation" = not in the thread.

STEP 1 — Acknowledge alert, take IC
[M01] 2026-08-29 14:02:10Z — Bryce Harmon
Action: acknowledged the PagerDuty alert (reward-worker queue depth > 10k) and took IC.
Command: none documented — needs confirmation (how the acknowledgment was performed is not in the thread).
Verification: none documented — needs confirmation.
Rollback: if the PagerDuty acknowledgment counts as a state change, no reversal is documented — needs confirmation.

STEP 2 — Measure queue depth (read-only)
[M02] 14:04:33Z — Farid Osman
Command: `bundle exec rake sidekiq:queue_depth`
Result: reward queue at 48,213 pending jobs; normal is under 500 (both as reported).
Verification: this command's output is the measurement itself.
Rollback: n/a — no state change.

STEP 3 — Inspect dead set (read-only)
[M03] 14:06:02Z — Farid Osman
Action: inspected the dead set. Result: 112 jobs, all Redis::TimeoutError, from around 13:58 (as reported).
Command: not documented — needs confirmation.
Verification: reported result only; no command output shown.
Rollback: n/a — no state change documented (command absent, so read-only status itself needs confirmation).

STEP 4 — Pause enqueue (STATE CHANGE)
[M04] 14:08:45Z — Farid Osman
Command: `bin/rails runner 'FeatureFlag.disable(:auto_recognition_enqueue)'`
Verification: none direct — the flag's state was not checked after the disable; needs confirmation. Later queue improvements (M07/M08) are observations of the queue, not proof the flag was disabled.
Rollback (documented in-thread): `bin/rails runner 'FeatureFlag.enable(:auto_recognition_enqueue)'`

STEP 5 — Clear dead set (STATE CHANGE, destructive)
[M05] 14:15:20Z — Elena Sinclair
Action: "cleared out the dead set" while in the console.
Command: not documented — needs confirmation (exact console command/method absent).
Verification: not documented — needs confirmation (no before/after dead-set count after clearing).
Rollback: not documented — needs confirmation. The thread does not establish that cleared jobs can be restored. Per the thread alone, this is not a verified, approved remediation — needs confirmation before reuse.

STEP 6 — Scale workers up (STATE CHANGE)
[M06] 14:21:07Z — Bryce Harmon
Command: `kubectl scale deployment/reward-worker --replicas=6` (was 3, per the message)
Verification: none direct — no replica-count check after scaling; needs confirmation. M07/M08 are later queue observations, not isolated proof of this step's effect.
Rollback (documented in-thread): `kubectl scale deployment/reward-worker --replicas=3`

STEP 7 — Progress check (read-only)
[M07] 14:33:41Z — Farid Osman
Reported result: queue depth down to 9,400 and falling ~1,200/min.
Command: not documented — needs confirmation (measurement method absent).
Rollback: n/a — no state change.

STEP 8 — Confirm recovery (read-only)
[M08] 14:47:55Z — Cole Ingram
Command: `bundle exec rake sidekiq:queue_depth` — returns 0.
Also reported: Datadog error rate back to baseline (reported claim; no query/dashboard reference given — needs confirmation if you need the exact monitor).
Rollback: n/a — no state change.

STEP 9 — Re-enable enqueue (STATE CHANGE)
[M09] 14:49:10Z — Bryce Harmon
Command: `bin/rails runner 'FeatureFlag.enable(:auto_recognition_enqueue)'`
Verification: "40 new jobs processed cleanly in the next 3 minutes" — Bryce's report; no command shown for how those 40 jobs were counted; needs confirmation if a verifiable check is required.
Rollback: not documented — needs confirmation. (The disable command from M04 exists in the thread, but the thread does not designate it as this step's rollback.)

STEP 10 — Scale workers back down (STATE CHANGE)
[M10] 14:55:00Z — Bryce Harmon
Command: `kubectl scale deployment/reward-worker --replicas=3`
Verification: queue stable at 0 (Bryce's report; measurement method not shown — needs confirmation for the exact check).
Rollback: not documented — needs confirmation. (Scaling back to 6 is not designated in the thread as this step's rollback.)
Incident declared resolved in this message.

ARITHMETIC
No arithmetic was needed to build this runbook — every count and rate (48,213; 112; 9,400; ~1,200/min; 40 jobs; 0; replica counts 3/6) is a reported value from the thread, preserved as given. The only computable figures, shown here:
- Incident span: 14:02:10Z → 14:55:00Z = 52 min 50 s (14:55:00 − 14:02:10).
- Disable-to-restore of enqueue: 14:08:45Z → 14:49:10Z = 40 min 25 s.
No drain-rate or error-rate figures were derived, since the thread reports them but does not document the underlying measurements.

DATA GAPS (all marked above, collected here)
- M01: acknowledgment method, verification, reversal — needs confirmation.
- M03: dead-set inspection command — needs confirmation.
- M04: direct flag-state verification — needs confirmation.
- M05: exact command, verification, rollback for dead-set clearing — needs confirmation.
- M06: direct replica-count verification — needs confirmation.
- M07: measurement command — needs confirmation.
- M09: rollback — needs confirmation.
- M10: rollback and the "stable at 0" measurement method — needs confirmation.

Note: the reward-worker-queue-incident-runbook skill I loaded contained stale actor names for this same incident ID; per its own rule the supplied thread is authoritative, and I patched the skill's source-specific checks to the thread's actors (Bryce Harmon, Farid Osman, Elena Sinclair, Cole Ingram) so future runs won't inherit the mismatch.

FIRST ERROR
2026-09-03T14:01:12Z — service: reward-service, level: ERROR, message: "Redis::TimeoutError: Connection to Redis at redis-primary:6379 timed out after 5s". Every line before it (13:55:13Z–13:59:30Z) is INFO; this is the first non-INFO line in the slice.

CASCADE, IN ORDER OF FIRST OCCURRENCE
1. 14:01:12Z reward-service ERROR — Redis connection timeout to redis-primary:6379 (root symptom).
2. 14:01:20Z, 14:01:30Z, 14:01:40Z reward-service ERROR — "retry exhausted for RewardGiveJob" x3.
3. 14:01:40Z sidekiq ERROR — "RewardGiveJob failed: Redis::TimeoutError; retrying in 60s". First sidekiq involvement: 14:01:40 − 14:01:12 = 28s after the root error.
4. 14:01:46Z–14:01:57Z — first job-failure batch in sidekiq_jobs.csv (earliest is J-00005 at 14:01:46Z, 34s after the root error; 6 jobs in this batch: J-00001–J-00006).
5. 14:02:28Z sidekiq ERROR — retry failure; second RewardGiveJob batch fails 14:02:51–14:02:58 (J-00007–J-00012), consistent with the 60s retry stated at 14:01:40.
6. 14:02:30Z sidekiq WARN — "Queue reward depth above 10,000" (backlog).
7. 14:02:36Z — first RecognitionDigestJob failure (J-00013); collateral, same Redis::TimeoutError.
8. 14:03:05Z api-gateway ERROR — "502 upstream timeout calling reward-service /gives". First gateway impact: 14:03:05 − 14:01:12 = 113s = 1m53s.
9. 14:03:30Z web-app ERROR — "Give form submission failed: upstream 502 from api-gateway". First user-visible failure: 14:03:30 − 14:01:12 = 138s = 2m18s.
10. 14:03:31–14:06:52Z — steady-state failure loop: sidekiq retries (14:03:31, 14:04:22, 14:05:26, 14:06:47), api-gateway 502s (14:03:48, 14:04:13, 14:05:16, 14:06:52), web-app form failures (14:04:45, 14:05:42, 14:06:49), RecognitionDigestJob failures (J-00014 14:03:15, J-00015 14:04:55, J-00016 14:05:50).
11. 14:22:10Z reward-service INFO — "Redis connection restored; resuming job processing". Redis unavailable from first error: 14:22:10 − 14:01:12 = 1258s = 20m58s.
12. 14:24:45Z sidekiq INFO — "Queue reward depth below 500". Drain time: 14:24:45 − 14:22:10 = 155s = 2m35s. Total span first error → recovery: 14:24:45 − 14:01:12 = 1413s = 23m33s.

Counts (arithmetic): ERROR lines — reward-service 4 + sidekiq 6 + api-gateway 5 + web-app 4 = 19, plus 1 sidekiq WARN. Job failures in sidekiq_jobs.csv — 12 RewardGiveJob (J-00001–J-00012) + 4 RecognitionDigestJob (J-00013–J-00016) = 16.

SERVICE AND JOB
- Origin service: reward-service, failing on its Redis dependency at redis-primary:6379 (named only in error text; no redis service logs exist).
- Job: RewardGiveJob, processed by sidekiq on queue "reward" (per sidekiq's queue-depth lines). RecognitionDigestJob is collateral — same Redis::TimeoutError, first failing 84s after the root error (14:02:36 − 14:01:12).
- Blast radius: reward-service → sidekiq (queue "reward" backlog) → api-gateway (502s calling reward-service /gives) → web-app (Give form submission failures). postgres logs only INFO "checkpoint complete" — no postgres errors in the data; not implicated.

DATADOG QUERY
Logs Explorer, time range 2026-09-03T13:55:00Z → 2026-09-03T14:05:00Z, sorted ascending by timestamp:

  service:reward-service status:error "Redis::TimeoutError"

Expected confirmation: zero matches before 14:01:12Z; earliest match at 2026-09-03T14:01:12Z with message "Redis::TimeoutError: Connection to Redis at redis-primary:6379 timed out after 5s", followed by 3 more matches (14:01:20, 14:01:30, 14:01:40) — 4 total. To isolate the connection timeout from the retry-exhausted messages, narrow the phrase: service:reward-service status:error "timed out after 5s" (expected: exactly 1 hit, at 14:01:12Z).

WHAT THE LOGS DO NOT SHOW
1. No logs from redis-primary itself — zero redis service lines, no failover, restart, memory, connection-count, or latency events. The root cause of the 5s timeouts is absent; only the symptom is logged.
2. No cause for the recovery — "Redis connection restored" at 14:22:10Z has no corresponding event (no restart, failover, config change, or operator action anywhere in the slice).
3. No job outcomes after recovery — nothing shows whether the 16 failed jobs (J-00001–J-00016) were reprocessed successfully, retried to exhaustion, or dead-lettered after 14:22:10Z. sidekiq_jobs.csv carries only job_id, job_class, failed_at, error — no retry counts or completion records.
4. Job-population mismatch — sidekiq warns queue "reward" depth above 10,000 at 14:02:30Z, yet sidekiq_jobs.csv lists only 16 failures (16 ≠ >10,000). The full failed/queued population is not shown; the CSV cannot be the complete set, but the logs don't state either way.
5. No user-impact quantification — only 4 web-app form-failure lines (14:03:30, 14:04:45, 14:05:42, 14:06:49). Total affected submissions or users cannot be counted from this slice.
6. Logging gaps — reward-service emits nothing between 13:59:30Z (last INFO) and 14:01:12Z (1m42s covering onset), and nothing between 14:01:40Z and 14:22:10Z (20m30s of silence from the origin service while downstream errors continued). No lines from reward-service, sidekiq, api-gateway, or web-app between 14:06:52Z and 14:22:10Z (15m18s; only postgres INFOs appear there). Whether errors truly stopped or the slice is truncated/sampled is not determinable.
7. No job IDs in the datadog logs — the "job enqueued" lines (web-app 13:58:49Z, reward-service 13:59:30Z) cannot be tied to J-00001–J-00016.
8. No metrics (Redis memory/CPU/connections/latency), no alerts, and no deploy or change events near 14:01Z.
9. postgres has no lines before 14:10:56Z — its health during the incident window cannot be assessed; the data shows only that no postgres ERROR lines exist.

FEATURE FLAG SUMMARY — 9 flags in export, all counts quoted from flags_export.csv

A. Flags with code references (6 of 9)

1. recognition_streaks_v2 — ON — 42 companies
   Controls (app/models/recognition.rb): when enabled, StreakTracker.record(give) runs on a recognition, i.e., streak tracking on gives. The disabled path is not shown in the excerpt.
   Targeting: segment "beta_companies". No company names given.

2. points_budget_guardrails — ON — 220 companies
   Controls (app/services/budget_service.rb): when enabled, BudgetService.new(company).enforce!(giver, points), i.e., budget enforcement on points a giver awards. Disabled path not shown.
   Targeting: all_companies (220).

3. slack_dm_nudges — ON — 87 companies
   Controls (app/jobs/nudge_job.rb): job returns early unless the flag is enabled; when enabled it sends SlackDm.send_nudge(user). Both paths shown.
   Targeting: segment "region_na".

4. redeem_flow_redesign — OFF — 12 companies
   Controls (app/controllers/redeem_controller.rb): enabled renders RedeemV2Component, disabled renders RedeemV1Component. Both paths shown.
   Targeting: targeted_list of 12 companies — these are configured targets only; the flag is off, so no company is currently receiving the redesign.

5. analytics_dashboard_v3 — ON — 65 companies
   Controls (app/controllers/analytics_controller.rb): when enabled, @dashboard = AnalyticsV3.new(company). Disabled path not shown.
   Targeting: segment "tier_three".

6. ms_teams_app_v2 — OFF — 9 companies
   Controls (app/services/teams_installer.rb): when enabled, TeamsAppV2.install(company). Disabled path not shown.
   Targeting: targeted_list of 9 companies — configured targets only; flag off.

B. Flags in the export with NO code reference (3 of 9)
   These appear in flags_export.csv but no file in flag_code.md references them, so what they control is not determinable from the excerpt:

7. legacy_give_modal — OFF — 14 companies, segment "legacy_plan".
8. survey_boosters_q3 — ON — 7 companies, segment "legacy_plan".
   Note: same segment as legacy_give_modal but a different count (14 vs 7); the export gives no explanation.
9. paused_offboard_cleanup — OFF — 0 companies, targeting_rules blank.
   This is the only flag with no targets and no targeting rules. It also has no code reference — fully inert in this export.

C. Coverage, gaps, and arithmetic

- Flags with no code reference: legacy_give_modal, survey_boosters_q3, paused_offboard_cleanup (3).
- Flag with no targets: paused_offboard_cleanup (blank targeting_rules, company_count 0).
- No flag referenced in the code excerpt is missing from the export; the excerpt references exactly 6 flags, all present.
- No company names or aliases appear in either file. Only segment identifiers (beta_companies, region_na, tier_three, legacy_plan, all_companies) and two targeted_list sizes are given, so companies can only be identified by segment.
- States: 5 on (recognition_streaks_v2, points_budget_guardrails, slack_dm_nudges, analytics_dashboard_v3, survey_boosters_q3) + 4 off (redeem_flow_redesign, ms_teams_app_v2, legacy_give_modal, paused_offboard_cleanup) = 9.
- ON-flag enrollments: 42 + 220 + 87 + 65 + 7 = 421 company-flag enrollments. A unique-company total is not computable because the export does not state whether segments overlap all_companies.
- OFF-flag configured targets: 12 + 9 + 14 + 0 = 35 companies targeted but flag off.
- For the four OFF flags, no company has the flag on; their counts are targeting-list/segment sizes, not active recipients.

NDA-1 — [PARTY A]: GREEN
Driving clause: "Carve-outs: information that (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."
Reasoning: Mutual, all five standard carve-outs present, no restrictive covenants, Delaware law — only quirk is the tail arithmetic: 2-year term + 3-year post-termination survival = 5-year total obligation window (2 + 3 = 5), the long edge of market but still standard-approval territory.

NDA-2 — [PARTY B]: YELLOW
Driving clause: "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."
Reasoning: Embedded non-solicit that is actually a no-hire ("solicit for employment or hire") with a post-term tail — 3-year term + 18 months = 4.5-year restriction window (3 + 1.5 = 4.5) — mutuality and the "came into contact" scoping mitigate it, but any hiring restriction on Bonusly warrants counsel review before signature.

NDA-3 — [PARTY C]: RED
Driving clauses: "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." / "No confidentiality carve-outs are stated in this Agreement." / "This Agreement shall be governed by and construed in accordance with the laws of the Republic of Ireland, and the parties submit to the exclusive jurisdiction of its courts."
Reasoning: One-way in favor of [PARTY C] means Bonusly is the Recipient, so this naked 3-year non-compete binds Bonusly against serving any business competing with [PARTY C] — compounded by zero carve-outs (even public or prior-known information stays "confidential"), a 5-year one-way term, exclusive Irish jurisdiction, and no confidentiality protection flowing back to Bonusly at all — full legal review.

Data gap: party identities are redacted, so whether [PARTY C]'s business actually overlaps Bonusly's (the real-world severity of the non-compete) cannot be assessed from the data provided; the RED classification stands on clause structure alone.