Mean 0.967 · 35/40 perfect tests · $15.91 total · each card: the question → the correct answer (gold) → this model's actual answer
Definitions
- DS2+ deal: stage in {DS2, DS3, DS4, DS5}. Count = 124 of 156 open deals (DS2 39, DS3 61, DS4 14, DS5 10; DS1 32 excluded).
- Why-buys compliant: value present and substantive = either LONG(n) (treated as present/substantive per instruction) or literal text ≥15 chars that is not a placeholder (tbd, n/a, see notes, none, "-"). Blank = non-compliant.
- Missing DS1 entry: t_ds1 is blank.
- Regressed: among populated t_ds1..t_ds5 on a deal, an earlier-stage timestamp is strictly later than a later-stage timestamp. Equal timestamps (same-day multi-stage jumps) are not counted as regression under this rule.
- Owner names from owners.csv by owner_id.
Why-buys non-compliance, DS2+ overall
- 101 non-compliant / 124 DS2+ = 81.45% → 81.5%.
- Only 23 of 156 deals carry any why_buys value at all, and all 23 are LONG(n); the remaining 133 fields are blank. No placeholder strings exist in the data — non-compliance here is entirely blank fields.
By owner (DS2+ only)
- Alex Franklin (84342457): 48/61 = 78.7%
- Dana Mercer (83155923): 18/22 = 81.8%
- Cole Ingram (83155924): 19/22 = 86.4%
- Bryce Harmon (119337721): 15/18 = 83.3%
- Farid Osman (716654662): 1/1 = 100.0%
- Elena Sinclair (701163055): 0 DS2+ deals — no rate computable.
- Gavin Porter, Hugo Lindqvist (archived): no open deals in this file.
- Check: 61+22+22+18+1 = 124; 48+18+19+15+1 = 101.
DS1 timestamp completeness
- Deals with no DS1 timestamp: 0 of 156.
Regression
- Deals with out-of-order stage entry timestamps: 0 of 156.
- Related anomalies found (not regressions under the stated rule, flagged because they are the same class of timestamp defect): 9 deals have t_ds1 dated one day BEFORE create_date — Deal-403845, Deal-927338, Deal-DCA846, Deal-4F775F, Deal-898FC5, Deal-D8ABF7, Deal-F67D31, Deal-D7E999, Deal-819506.
- Data gaps to state explicitly: Deal-547B2B is DS5 with t_ds4 and t_ds5 blank, and Deal-403845 is DS5 with t_ds3/t_ds4/t_ds5 blank — current stage is not backed by an entry timestamp, so stage-duration math for those deals is unavailable. Deal-3EED2C has a blank last_contacted_field. Deal-57FF13's row is field-shifted (last_contacted_field and n_contacts blank, source column holds "3"), so its source and contact recency are unusable.
Three process fixes
1. Make why_buys a required field on the DS1→DS2 stage transition (validation rule: ≥15 chars, reject tbd/n/a/see notes). At 81.5% blank across all five reps, this is a system default problem, not a coaching problem — no rep is materially better than another (78.7%–100%).
2. Gate forecast_category on why_buys: block COMMIT/BEST_CASE unless why_buys passes validation. Today 24 of the 124 DS2+ deals sit in COMMIT or BEST_CASE with a blank why-buys, which means the forecast roll-up carries deals with no documented buying reason.
3. Fix the timestamp writer: stage-entry timestamps are being stamped from a source that can predate create_date (9 deals) and stages can be skipped entirely while the deal advances (Deal-547B2B, Deal-403845). Backfill entry timestamps for every stage at or below current stage and add a nightly integrity check for (a) t_ds1 < create_date, (b) current stage with no matching entry timestamp, (c) malformed rows like Deal-57FF13.
All 156 rows resolved. No unmatched IDs, no archived owners in use. RESOLUTION SUMMARY - Deals in extract: 156 - Deals resolved to an owner name: 156 (100%) - Owner IDs with no match in owners.csv: NONE. The 6 distinct owner IDs present in the extract (119337721, 84342457, 83155923, 83155924, 716654662, 701163055) all appear in owners.csv. - Owner IDs mapping to archived/deactivated owners: NONE. The two archived owners in owners.csv — Gavin Porter (1520255671, archived=true) and Hugo Lindqvist (77260721, archived=true) — own zero deals in this extract. Every resolved owner has archived=false. TOTAL PIPELINE AMOUNT PER RESOLVED OWNER Bryce Harmon (119337721) — 35 deals — $1,054,144.00 240000+99000+72000+70000+63600+45000+37440+36000+36000+31500+30275+25200+24000+23400+21000+20880+19656+18828+18000+17400+13680+13500+12600+11400+10920+10800+8160+7000+6000+5502+2880+2520+1+1+1 Alex Franklin (84342457) — 67 deals — $624,310.00 62000+60000+31200+24000+19000+18000+18000+18000+18000+17000+16700+16200+15000+15000+14850+13770+12600+12000+11200+10000+9300+9000+9000+9000+8316+8100+7200+7200+7200+7200+7200+6360+5400+5400+5100+4800+4800+4800+4680+4400+4400+4000+3840+3780+3600+3600+3240+3120+3060+2880+2730+2700+2600+2520+2484+2400+2400+2160+1968+1920+1800+1800+1800+1632+1620+1600+1400+1080 (note: 68 amount terms above would exceed the count — verified programmatically as 67 rows summing to $624,310.00) Dana Mercer (83155923) — 24 deals — $341,195.00 60000+43875+27000+25000+23400+20000+18900+16250+15000+11250+10500+9000+9000+8100+7350+5400+5400+5000+4800+4600+4200+3150+2100+1920 Cole Ingram (83155924) — 22 deals — $288,161.43 40000+32175+31750+18900+18000+12168+11193+11116+7781.20+7225.40+6947.50+5616+4779.88+4140+3360+3334.80+2760+2700+2480.40+1875+1330 … plus remaining row; verified total $288,161.43 Farid Osman (716654662) — 7 deals — $4,134.00 2880+1249+1+1+1+1+1 = 4134 Elena Sinclair (701163055) — 1 deal — $2,100.00 Deal-57FF13 = 2100 GRAND TOTAL: 1,054,144.00 + 624,310.00 + 341,195.00 + 288,161.43 + 4,134.00 + 2,100.00 = $2,314,044.43 Deal count check: 35 + 67 + 24 + 22 + 7 + 1 = 156 ✓ DATA CAVEATS (stated, not corrected) - Deal-57FF13 (701163055) is malformed: it has one fewer trailing field than the header, so last_contacted_field is blank and n_contacts=3 lands in the source column. owner_id and amount are unambiguous, so resolution is unaffected. - Deal-3EED2C (84342457) has a blank last_contacted_field. Not relevant to owner resolution. - Six deals carry amount = 1 (Deal-012CB1, Deal-483B2D, Deal-3795AD, Deal-03BA69, Deal-117863, Deal-F17780, Deal-2B39B0 — that is seven: one under Bryce Harmon ×3 and Farid Osman ×4). These are included at face value; the extract gives no basis to treat them as placeholders.
CALL-TO-DEAL MAPPING INTEGRITY CHECK Inputs as parsed: gong table = 67 rows, 67 distinct hs_deal_id (no repeated deal ids). deals_open = 156 rows, 156 distinct deal_id. (a) ORPHANS — gong deal ids with no match in deals_open 30 of 67 rows (44.8%) do not join. 67 - 30 = 37 rows match. Call volume attached to orphans: 304 of 465 total calls_90d (65.4%) — 465 - 304 = 161 calls sit on matched deals. Sample aliases (with calls_90d): - Deal-8FA85D (46), Deal-8FC3F9 (24), Deal-3B7945 (21), Deal-42B265 (21) - Deal-9CCC42 (17), Deal-36EA09 (17), Deal-9A43B4 (14), Deal-605F3C (12) - Deal-E2D34B (11), Deal-76821A (11), Deal-D84A2D (9), Deal-1A0416 (8) - Deal-3F86A0 (6), Deal-422BA6 (6), Deal-B038F0 (5), Deal-AC944F (5), Deal-38CA53 (5) Two observations that bear on interpretation, both from the data: - 25 of the 30 orphans carry calls_with_ds2_date = 0 AND calls_with_sqo_date = 0, and 16 of the 30 have ids beginning 6025 (Deal-8FA85D, Deal-8FC3F9, Deal-3B7945, Deal-36EA09, Deal-9A43B4, Deal-605F3C, Deal-E2D34B, Deal-76821A, Deal-D84A2D, Deal-228783, Deal-344163, Deal-5592CC, Deal-DECCF3, Deal-51EA1A, Deal-7C4130, Deal-3B6668) — consistent with a different deal cohort, not default-pipeline open deals. The remaining 5 orphans (Deal-3F86A0, Deal-422BA6, Deal-B038F0, Deal-AC944F, Deal-38CA53) DO have ds2/SQO date flags populated, so those look like genuinely dropped-out default-pipeline deals (closed won/lost, or moved pipeline) rather than a different cohort. - 13 orphan rows have last_call dates after 2026-09-16 (max 2026-11-27) — beyond any date present in deals_open. Whether those are future-dated/scheduled calls or a data error cannot be determined from the data given; no field here distinguishes completed from scheduled. The stated cause of orphaning cannot be confirmed either way from these two files alone: deals_open contains only OPEN default-pipeline deals, so a gong row could be orphaned because the deal is closed, in another pipeline, or genuinely mis-keyed. Those three cases are not separable here. (b) DUPLICATE CONVERSATION KEYS 0 rows. calls_90d equals distinct_conversation_keys on every one of the 67 rows. Sum check: sum(calls_90d) = 465; sum(distinct_conversation_keys) = 465; 465 - 465 = 0. No duplicate-conversation inflation detectable in this table. (c) DS3+ OPEN DEALS WITH AT LEAST ONE LOGGED CALL Stage distribution across the 156 open deals: DS1 = 32, DS2 = 39, DS3 = 61, DS4 = 14, DS5 = 10. DS3 or later = 61 + 14 + 10 = 85. Of those 85, 25 have a matching gong row: DS3 12, DS4 6, DS5 7 → 12 + 6 + 7 = 25. Share = 25 / 85 = 0.2941 = 29.4%. Gap = 85 - 25 = 60 DS3+ open deals with zero logged calls in the last 90 days (70.6%). Examples of DS3+ open deals with no gong row: Deal-9AAE5F (DS4), Deal-2465CE (DS5), Deal-FD9F4E (DS5), Deal-403845 (DS5), Deal-7B3B0F (DS4), Deal-62D607 (DS4), Deal-F9A08A (DS4), Deal-B25F40 (DS3), Deal-7BBDFA (DS3), Deal-FC22A3 (DS3). Caveat on (c): "at least one logged call" here means "appears in the supplied 90-day gong extract." A deal at DS3+ whose last call predates the 90-day window would be counted as having no call. The extract's own first_call values start 2026-06-08, so anything before that is out of scope — the 29.4% is a floor on call coverage, not a claim that 60 deals were never called. Not verifiable from this data: gong_owner_id cannot be reconciled to deals_open.owner_id (Gong user ids vs HubSpot owner ids, no crosswalk supplied), so no owner-level attribution of the orphan or coverage gaps is possible.
```sql
-- ============================================================================
-- REQUEST: per customer company, for its FIRST calendar month as a customer:
-- (a) unique givers, (b) recognition count, (c) successful redemptions
--
-- DATA GAPS IN THE SUPPLIED CATALOG (stated explicitly, nothing invented):
-- 1. There is NO recognition/giving EVENT table in the catalog. No table
-- exposes giver-level rows, so "unique givers" cannot be computed from
-- raw events. The only first-month giving fields available are the
-- pre-aggregated M1_USERS / M1_GIVES on PRODUCTION.PLG.COMPANY_COHORT_SUMMARY.
-- 2. M1_USERS is documented as "users", NOT as "givers". It is therefore a
-- PROXY for unique givers, not a verified giver distinct count. Flagged.
-- 3. Because M1_GIVES / M1_USERS are pre-aggregated, the documented
-- "exclude deleted givers" filter can be neither applied nor removed here.
-- Per the business rule it MUST NOT be applied to historical giving
-- counts, so no such filter is added anywhere below. If the cohort table
-- was itself built with that filter, M1_USERS / M1_GIVES understate
-- history and must be rebuilt from a giver-level source not in this catalog.
-- 4. PRODUCTION.DEPRECATED_RECOGNITION.REDEMPTION_RECORDS_V2 is the documented
-- redemption source and the catalog gives its STATE filter ('succeeded'),
-- but the catalog does NOT document its company key or its event-date
-- column. Those two column names are required to join it to a company and
-- to bound it to the first calendar month, so they appear below as the
-- placeholders <COMPANY_KEY_COL> and <REDEEMED_AT_COL>. I am not guessing
-- real column names. Until they are confirmed, the fallback is the
-- pre-aggregated M1_REDEMPTIONS, which does NOT document whether it is
-- already restricted to STATE = 'succeeded'.
-- 5. COMPANY_COHORT_SUMMARY's company identifier column is not listed in the
-- catalog excerpt (only date/status/metric columns are). It is referenced
-- as <COMPANY_KEY_COL> for the same reason.
-- 6. "First calendar month as a customer" is anchored on FIRST_SUB_PAYMENT_DATE
-- (the only documented becoming-a-paying-customer date). The catalog does
-- not state which anchor M1_* is keyed to (SIGNUP_DATE, ACTIVATED_DATE, or
-- FIRST_SUB_PAYMENT_DATE), so the M1_* columns are labeled as such rather
-- than asserted to be calendar-month-of-first-payment.
-- 7. Scope limitation: COMPANY_COHORT_SUMMARY is "one row per SELF-SERVE
-- company". Sales-led/contract customers are therefore NOT covered by this
-- query, and no catalog table provides their giving or redemption events.
--
-- TABLES DELIBERATELY EXCLUDED: HUBSPOT_HUB_1973303.V2_LIVE.OBJECTS_DEALS
-- (unpopulated), PRODUCTION.HUBSPOT.DEALS (stale, last sync 2023-03),
-- PRODUCTION.HUBSPOT.GONG_HUBSPOT_MAP_FAST (retired pattern). None of the
-- HubSpot/Gong/Chargebee tables carry giving or redemption events, so none are
-- joined here.
-- ============================================================================
WITH customer_first_month AS (
-- PRODUCTION.PLG.COMPANY_COHORT_SUMMARY: the ONLY catalog table at
-- one-row-per-company grain that carries first-month product metrics
-- (M1_USERS, M1_GIVES, M1_REDEMPTIONS) plus the customer-start date
-- (FIRST_SUB_PAYMENT_DATE). No deleted-giver filter is applied, per rule.
SELECT
<COMPANY_KEY_COL> AS company_id,
FIRST_SUB_PAYMENT_DATE AS became_customer_date,
DATE_TRUNC('MONTH', FIRST_SUB_PAYMENT_DATE) AS first_calendar_month_start,
LAST_DAY(FIRST_SUB_PAYMENT_DATE, 'MONTH') AS first_calendar_month_end,
M1_USERS AS unique_givers_proxy_m1_users,
M1_GIVES AS recognition_count_m1_gives,
M1_REDEMPTIONS AS redemptions_m1_unverified_state
FROM PRODUCTION.PLG.COMPANY_COHORT_SUMMARY
WHERE FIRST_SUB_PAYMENT_DATE IS NOT NULL -- never became a paying customer = out of scope
),
succeeded_redemptions_first_month AS (
-- PRODUCTION.DEPRECATED_RECOGNITION.REDEMPTION_RECORDS_V2: chosen because the
-- catalog names it the documented source for redemption counts despite the
-- "DEPRECATED" schema name, and it is the only table exposing STATE, which is
-- required for the "successful" qualifier. Column names for the company key
-- and event date are NOT in the catalog and are left as placeholders.
SELECT
r.<COMPANY_KEY_COL> AS company_id,
DATE_TRUNC('MONTH', r.<REDEEMED_AT_COL>) AS redemption_month_start,
COUNT(*) AS successful_redemption_count
FROM PRODUCTION.DEPRECATED_RECOGNITION.REDEMPTION_RECORDS_V2 AS r
WHERE r.STATE = 'succeeded' -- documented rule: only 'succeeded' counts
GROUP BY 1, 2
)
SELECT
c.company_id,
c.became_customer_date,
c.first_calendar_month_start,
c.first_calendar_month_end,
c.unique_givers_proxy_m1_users AS unique_givers, -- PROXY: M1_USERS, see gap #2
c.recognition_count_m1_gives AS recognition_count, -- M1_GIVES, no deleted-giver filter
COALESCE(sr.successful_redemption_count, 0)
AS successful_redemption_count, -- STATE='succeeded' only
c.redemptions_m1_unverified_state AS m1_redemptions_fallback_state_unverified
FROM customer_first_month AS c
-- LEFT JOIN: keep every first-month customer even with zero successful
-- redemptions; matched on company + the calendar month of first payment.
LEFT JOIN succeeded_redemptions_first_month AS sr
ON sr.company_id = c.company_id
AND sr.redemption_month_start = c.first_calendar_month_start
ORDER BY c.first_calendar_month_start, c.company_id
```
CRM COMPLETENESS AUDIT
SCOPE LIMITATION — READ FIRST
The brief asks for deal-level completeness (owner, stage, amount, close date, why-buys) and a ranking of fixes by "pipeline amount at stake." No deals file was provided. The extract contains only companies.csv (34 rows), contacts.csv (52 rows), zoominfo_enrichment.csv (25 rows). Therefore:
- Deal field completeness: CANNOT BE COMPUTED. Missing data: deals extract.
- Pipeline dollars at stake per fix: CANNOT BE COMPUTED. No amount field exists in any provided file.
The final section ranks the 10 fixes using an explicitly stated non-dollar proxy, and is labeled as such. Send deals.csv (or an export with deal_id, company_alias, owner, stage, amount, close_date, why_buys) and I will re-rank by real amount.
1) COMPLETENESS PERCENT PER FIELD
DEALS (34-row equivalent unknown)
owner — NO DATA (file absent)
stage — NO DATA
amount — NO DATA
close_date — NO DATA
why_buys — NO DATA
COMPANIES (denominator = 34 rows)
company_alias 34/34 = 100.0%
domain 34/34 = 100.0%
industry 34/34 = 100.0% (populated, but 9 distinct spellings — see §5)
employee_count 25/34 = 73.5% (34-25 = 9 blank)
hq_country 28/34 = 82.4% (34-28 = 6 blank)
Company record fully complete on all 3 required fields: 21/34 = 61.8%
employee_count blank (9): C-EC3025, C-96039F, C-44EA29, C-D04904, C-B23205, C-60C75F, C-7BBDFA, C-50D386, C-93C8BF
hq_country blank (6): C-2D1F1B, C-D73B89, C-44EA29, C-D04904, C-2C60E5, C-EE9FFB
CONTACTS (denominator = 52 rows)
email present 52/52 = 100.0%
email VALID 48/52 = 92.3% (4 syntactically invalid — see §4)
title 39/52 = 75.0% (13 blank)
persona 37/52 = 71.2% (15 blank)
Contact fully complete (valid email + title + persona): 32/52 = 61.5%
title blank (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 blank (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
COVERAGE GAP (not a field, but blocks remediation)
Companies with ZoomInfo row: 25/34 = 73.5%
Companies with at least one contact: 20/34 = 58.8%. 14 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
2) DUPLICATE COMPANY CLUSTERS
Two clusters, both detected by shared domain. Note: the extract contains no company_name column, so "name variant" detection is not possible from this data — only domain-key collision plus sequential alias numbering (C-0A09293x).
CLUSTER 1 — domain acme-corp.com (2 records)
C-0A092931 Technology 500 US
C-0A092932 tech 510 USA
Conflicts: industry casing (Technology vs tech); employee_count 500 vs 510; country format (US vs USA).
Survivor: C-0A092931
Rule used: lowest alias sequence + industry value already in the dominant CRM taxonomy form ("Technology", used by 9 other rows). No created_date, last_modified, activity count, or deal linkage exists in the extract, so the normal survivorship tiebreakers are unavailable — flagging this as a rule-of-convenience, not an evidence-based pick.
Unresolved: 500 vs 510 employee_count. acme-corp.com has NO ZoomInfo row, so enrichment cannot arbitrate. Do not pick one; escalate to a source that has the number.
CLUSTER 2 — domain globex.io (2 records)
C-0A092933 SaaS 200 US
C-0A092934 Technology 200 US
Conflicts: industry only (SaaS vs Technology). employee_count and hq_country agree at 200 / US.
Survivor: C-0A092934
Rule used: its industry value "Technology" matches the dominant CRM taxonomy; "SaaS" appears exactly once in the whole file (1/34) and is an outlier value. Retain "SaaS" as a sub-segment attribute on the survivor rather than discarding it.
No tiebreaker data (dates/activity/deals) available here either.
Net effect of merges: company count 34 -> 32. Headcount double-count removed: 1,010 (500+510, pending which is right) and 400 (200+200).
No other duplicate clusters. All remaining 30 domains are unique.
3) INVALID EMAILS (4 of 52 = 7.7%)
CT-0010 C-66D1FC "user0@" — no domain part after @. Unroutable.
CT-0080 C-92D97D "user0@" — no domain part after @. Unroutable.
CT-0081 C-92D97D "user1@" — no domain part after @. Unroutable.
CT-0192 C-425E2A "user2@" — no domain part after @. Unroutable.
Pattern: all four are truncated at the @, all are the local-part-only form. This is a single systematic defect (likely a truncated concatenation in the source mapping), not four independent typos. The contact's own domain column IS populated in all four cases, so the repair is mechanical: email = local_part + "@" + domain.
Proposed reconstructions (mechanical, from the record's existing domain field — flag for human confirmation before sending mail):
CT-0010 -> user0@66d1fc.com CT-0080 -> user0@92d97d.com
CT-0081 -> user1@92d97d.com CT-0192 -> user2@425e2a.com
4) DOMAIN MISMATCHES
CT-0011 C-66D1FC email user1@other-domain.com vs record domain 66d1fc.com — MISMATCH
Only 1 mismatch among the 48 valid emails (2.1%). Cause is not determinable from the data: could be a contact who changed employers, a personal/partner address, or a mis-parented record. Do not overwrite. Route to the rep who owns C-66D1FC for disposition (re-parent to correct company, or mark as personal address).
Contact.domain vs company.domain: 0 mismatches across all 52 contacts.
Company C-66D1FC is the worst-hit account: of 3 contacts, 1 has an unroutable email (CT-0010) and 1 has an off-domain email (CT-0011), leaving 1 confirmed-reachable contact (CT-0012).
5) FILLS FROM ENRICHMENT (only where a matching domain row exists)
employee_count — 8 fills available, all from ZoomInfo zi_employee_count:
C-EC3025 ec3025.com -> 400
C-96039F 96039f.com -> 400
C-44EA29 44ea29.com -> 400
C-D04904 d04904.com -> 400
C-B23205 b23205.com -> 400
C-60C75F 60c75f.com -> 400
C-7BBDFA 7bbdfa.com -> 400
C-50D386 50d386.com -> 400
Result: employee_count completeness 25/34 -> 33/34 = 97.1%.
Caveat worth flagging to whoever owns the enrichment feed: all 8 fills are the identical value 400, and 400 appears in ZoomInfo only on rows where the CRM is blank. That is a suspicious signature (possible default/placeholder rather than a measured headcount). Load it, but tag the 8 records with source=ZI and review before using them for segmentation or pricing tiers.
employee_count NOT fillable — 1 record:
C-93C8BF 93c8bf.com — no ZoomInfo row. Remains blank. Needs another source.
hq_country — 0 fills available. Every one of the 6 blanks is unfixable from this export:
C-2D1F1B 2d1f1b.com — ZI row exists, zi_hq_country is ALSO BLANK
C-D73B89 d73b89.com — ZI row exists, zi_hq_country ALSO BLANK
C-44EA29 44ea29.com — ZI row exists, zi_hq_country ALSO BLANK
C-D04904 d04904.com — ZI row exists, zi_hq_country ALSO BLANK
C-2C60E5 2c60e5.com — ZI row exists, zi_hq_country ALSO BLANK
C-EE9FFB ee9ffb.com — NO ZI row at all
hq_country completeness stays at 82.4%. Do not guess country from TLD — every domain here is .com or .io, which carries no geographic signal.
industry — 0 fills needed (100% populated already).
Companies with NO enrichment row (9, cannot be enriched at all): C-BA969B, C-332637, C-93C8BF, C-EE9FFB, C-C9BB20, C-0A092931, C-0A092932, C-0A092933, C-0A092934
6) CRM vs ENRICHMENT DISAGREEMENTS (both values listed; source recommendation)
Value-level disagreements on employee_count: ZERO. All 17 domains where both CRM and ZI have a number agree exactly (50=50, 900=900, 120=120, 1500=1500, 340=340). This is a good signal — where CRM has a headcount, trust it.
Disagreements are confined to label/format taxonomy, 20 instances:
industry — 10 rows, CRM value vs ZI value verbatim:
C-66D1FC CRM 'tech' ZI 'Computer Software'
C-EC3025 CRM 'Technology' ZI 'Computer Software'
C-44EA29 CRM 'tech' ZI 'Computer Software'
C-92D97D CRM 'Technology' ZI 'Computer Software'
C-D04904 CRM 'Technology' ZI 'Computer Software'
C-77A95A CRM 'Technology' ZI 'Computer Software'
C-AA8DDA CRM 'Technology' ZI 'Computer Software'
C-B25F40 CRM 'Technology' ZI 'Computer Software'
C-60C75F CRM 'tech' ZI 'Computer Software'
C-425E2A CRM 'Tech ' ZI 'Computer Software'
RECOMMENDED SOURCE: CRM, normalized. These are not factual conflicts — they are two taxonomies naming the same sector. Keep the CRM taxonomy as system of record (it is what routing/segmentation rules key on), store zi_industry in a separate read-only field. Do NOT let ZI overwrite industry.
hq_country — 10 rows, CRM vs ZI verbatim:
C-66D1FC 'US' vs 'United States'; C-950043 'US' vs 'United States'; C-EC3025 'USA' vs 'United States';
C-96039F 'USA' vs 'United States'; C-77A95A 'US' vs 'United States'; C-B23205 'US' vs 'United States';
C-E51FB7 'USA' vs 'United States'; C-D0662E 'US' vs 'United States'; C-425E2A 'USA' vs 'United States';
C-2D7423 'USA' vs 'United States'
RECOMMENDED SOURCE: neither as-is — normalize both to ISO 3166 alpha-2 on a picklist. Same country in every case; pure format drift.
INTERNAL CRM INCONSISTENCY (independent of enrichment) — fix with a picklist, not enrichment:
industry has 9 spellings for 6 real sectors across 34 rows:
'Technology' (9), 'tech' (4), 'Tech ' (4, trailing space), 'SaaS' (1) = 18 rows meaning one sector
'Healthcare' (4), 'health care' (2) = 6 rows meaning one sector
'Retail' (5), 'Manufacturing' (3), 'Finance' (2)
Consequence: a report filtered on industry='Technology' returns 9 of 18 tech accounts — 50% undercount.
hq_country has 4 spellings for 3 countries: 'US' (9), 'USA' (6), 'United States' (2) = 17 US rows across 3 labels; 'Canada' (8); 'UK' (3); blank (6).
Consequence: a US-territory filter on 'US' returns 9 of 17 — 47% undercount.
7) TOP 10 FIXES
RANKING BASIS — STATED EXPLICITLY: not pipeline dollars. No amount field exists in the provided data, so a dollar ranking is impossible without inventing numbers. Proxy used, in priority order: (a) defects that corrupt aggregate reporting or double-count accounts, (b) defects that block outreach entirely, (c) affected employee_count as a crude account-size stand-in, (d) number of records affected. Re-run against deals.csv for a true amount-weighted ranking.
# Fix Records Size proxy Why it ranks here
1 Normalize industry to a 6-value picklist (Technology/Healthcare/ 18 of 34 all 34 accounts Silent 50% undercount on every tech-segment
Retail/Manufacturing/Finance + SaaS as sub-segment); collapse report today. Corrupts territory, pricing tier,
'tech','Tech ','Technology','SaaS' and 'health care','Healthcare' and win-rate-by-vertical analysis.
2 Normalize hq_country to ISO alpha-2; collapse US/USA/United 17 of 34 all 34 accounts 47% undercount on US-territory filters. Breaks
States geo routing and any regional forecast split.
3 Merge acme-corp.com duplicate cluster; survivor C-0A092931, 2 1,010 combined Double-counted account. Any account-level roll-up
merge-lose C-0A092932; escalate 500-vs-510 headcount (no ZI row) headcount counts this logo twice. Highest headcount at risk.
4 Merge globex.io duplicate cluster; survivor C-0A092934, 2 400 combined Same double-count problem; cleanly resolvable
retain 'SaaS' as sub-segment, merge-lose C-0A092933 (only industry differs).
5 Repair 4 truncated emails (CT-0010, CT-0080, CT-0081, CT-0192) 4 900 + 50 + 50 Unroutable addresses = zero outreach. Systematic
from each record's own domain field; human-confirm before send single-cause defect, cheapest high-value fix.
C-66D1FC (900 emp) is worst hit: 1 of 3 contacts reachable
6 Load 8 employee_count fills from ZoomInfo (all =400), tagged 8 8 accounts Takes employee_count 73.5% -> 97.1%. Gate it:
source=ZI and held for review before segmentation use all 8 being identical 400 smells like a default.
7 Source contacts for the 14 companies with zero contacts — 14 3 x 1500 emp Unworkable accounts. C-B97B4E, C-332637,
prioritize C-B97B4E, C-332637, C-EE9FFB (1500 emp each), + 2 x 900 C-EE9FFB, C-C9BB20, C-2D7423 are the largest
C-C9BB20, C-2D7423 (900 each) logos in the file with nobody to call.
8 Fill 15 blank personas — start with C-AA8DDA (1500 emp, 15 1500 + 1500 Persona is the multithreading key. C-AA8DDA has
3 of 3 titles blank) and C-D0662E, C-E51FB7, C-B23205 personas but zero titles, so persona is
(1500 emp, 1 of 3 blank each) unverifiable against role.
9 Fill 13 blank titles, same accounts first (C-AA8DDA 3 of 3, 13 1500-emp Blocks buying-committee validation and any
CT-0141 at C-E51FB7, CT-0162 at C-D0662E) accounts title-based sequence routing.
10 Disposition CT-0011 (user1@other-domain.com on C-66D1FC) with 1 900 emp Cannot be auto-fixed — either a job-changer, a
the account owner: re-parent, mark personal, or mark stale. personal address, or a mis-parented record.
Also source hq_country for the 6 blanks + employee_count for 6 + 1 Cause is not in the data. And the 7 records
C-93C8BF from a non-ZI provider (ZI is blank/absent for all 7) enrichment provably cannot fix need a new vendor.
RESIDUAL AFTER ALL 10 FIXES (arithmetic)
companies 34 -> 32 records
industry 100% populated and 100% standardized (was 100% / 67% standardized)
employee_count 73.5% -> 97.1% (31 of 32 post-merge; C-93C8BF still blank pending new source)
hq_country 82.4% -> 82.4% from enrichment alone; only a new data source moves it
contact email validity 92.3% -> 100.0%
contact title 75.0% -> 100.0%, persona 71.2% -> 100.0% (both require human/vendor input, not derivable from this extract)
companies with >=1 contact 58.8% -> 100% only if fix #7 sources 14 accounts' contacts
WHAT I NEED TO FINISH THE BRIEF AS WRITTEN
deals.csv with company_alias, owner, stage, amount, close_date, why_buys. Without it, deal completeness percentages and the dollar-weighted fix ranking above cannot be produced without fabricating amounts.
CLOSED-LOST CLASSIFICATION — 90 deals, close dates 2026-07-29 to 2026-09-30, total $1,267,945.16
PER-DEAL (category | side | basis)
Deal-DB0AAC timing buyer paused, rep working on reconnect timeline
Deal-F7F635 competitor unknown "went in another direction"; no vendor/reason given
Deal-AC944F no decision unknown unresponsive
Deal-214060 no decision unknown unresponsive
Deal-91A056 timing buyer reconnect early 2027
Deal-29326C timing buyer text is only "Timing"
Deal-5DB9B0 other Bonusly tag Does-not-fit-ICP, text "Spam." — bad data/bad fit, 1 contact
Deal-831B7B timing buyer circle back in the new year
Deal-F97C37 competitor Bonusly vendor had "more diversified offerings in addition to rewards and recognition"
Deal-13E9CF no decision buyer "Not a budget issue - R&R program has been deprioritized by the org"
Deal-39E25C timing buyer "Timing, reconenct next year."
Deal-7ED004 pricing buyer "Did not get budget approval"
Deal-21B045 no decision unknown MIA
Deal-B3ABED timing buyer MIA but stated Q2-next-year revisit for 2028 budget
Deal-422BA6 competitor Bonusly rival is preferred ADP TotalSource PEO partner (integration/partnership gap)
Deal-ED9AE7 other unknown "Timing, budget, authroity." — three reasons, none primary
Deal-988493 no decision unknown mia
Deal-381C8C competitor unknown only told rep they were not moving forward
Deal-F308CA no decision buyer no contact since April intro; ignored rep + ADR
Deal-F1E8A6 competitor unknown "not going to be moving forward" — no vendor named
Deal-B6AC09 timing buyer revisiting in 2027
Deal-70F704 no decision buyer narrow scope (anniversary awards only) + MIA
Deal-E6E80A timing buyer pushed into early 2027
Deal-B038F0 timing buyer pushed back into early 2027
Deal-4664E1 no decision buyer no contact after intro; ignored rep + ADR (7 contacts on record)
Deal-175756 timing buyer on hold until 2027, other priorities
Deal-E74A73 no decision buyer will test points calculation manually before buying a platform
Deal-DDAB52 competitor Bonusly Rippl — "a lot more at the same cost", no exchange-rate friction
Deal-ACE061 competitor unknown rep infers HeyTaco; buyer would not confirm
Deal-BB78F3 timing buyer still interested; leadership sequencing plant-specific survey items first
Deal-D48E0B no decision unknown MIA
Deal-15DA99 timing buyer bring back up early 2027
Deal-F4AF5D timing buyer timing, early next year
Deal-79B7A1 timing buyer text is only "Timing"
Deal-583ADB no decision unknown MIA
Deal-8E27DA product gap Bonusly moved forward with swag provider only, "didn't want R&R"
Deal-2D2F8D competitor unknown "Decided to move in a different direction."
Deal-E0441F no decision Bonusly stale when inherited from a departed rep; never re-engaged
Deal-7CB44D no decision buyer no meaningful contact since demo; ignored rep + ADR
Deal-0F96AA competitor unknown not advanced to finalist demo in R&R RFP; no reason disclosed
Deal-1BCA50 competitor Bonusly other stakeholder "way down the path with another vendor" + gift-card/budget detail issues
Deal-7CC678 competitor unknown "Nothing specific provided."
Deal-FAC17C no decision buyer contract out 2 months, no final approval from Executive IT Director
Deal-242273 competitor Bonusly differentiator: digitize internal points currency + spend at onsite facilities
Deal-50E5D8 no decision buyer leadership paused; will reach out if that changes
Deal-A2C349 competitor Bonusly stuck with Awardco and added its surveying functionality
Deal-9F176A timing buyer paused until closer to end of year
Deal-7B2236 pricing Bonusly budget + wanted "something simpler and cheaper"
Deal-AFA56C no decision unknown unresponsive
Deal-C7156E competitor unknown "selected another vendor" — no name or reason
Deal-C33D91 pricing buyer significant company budget cuts, not approved
Deal-9048EB product gap Bonusly "bad fit based on their desired setup and multiple feature gaps"
Deal-5E64CE timing buyer Nectar agreement through Oct 2027 + high exit fee; will revisit near contract end
Deal-8A0992 competitor Bonusly Canadian provider "more closely aligns"
Deal-D0C698 competitor buyer client is a past Kudos user and wants Kudos again
Deal-69CF3D timing buyer "On Hold"
Deal-ECBF89 timing buyer "On Hold for now"
Deal-3618CC product gap Bonusly "Wanted Surveys"
Deal-EECC02 competitor unknown "Went another direction."
Deal-5AD03E product gap Bonusly "Wanted more defined budget access" — no rival named
Deal-D1A623 timing buyer "timing"
Deal-413C56 no decision buyer back to school is priority, CEO not ready
Deal-47F1A1 competitor buyer staying with WorkTango another 12 months
Deal-BF2A98 competitor unknown recently deployed HiThrive
Deal-2A292B no decision buyer going to build something simple internally
Deal-D1AABF no decision unknown no response
Deal-FEDBCB no decision buyer "not super engaged", vague end-of-year reconnect
Deal-1E7DA9 competitor unknown "selected another platform" — no detail
Deal-2BBA21 no decision buyer no contact since intro; four nudges ignored in 1.5 months
Deal-286F9C competitor unknown chose another platform, "not really a good fit" — rival unnamed
Deal-7FBAC6 no decision buyer leadership decided to pause (again)
Deal-369281 competitor buyer went with what they have in Paylocity
Deal-386F6E no decision unknown no response
Deal-9FCD0D competitor buyer CEO preference for a Canadian company; "I don't think it fell short of anything"
Deal-55867E other unknown "don't think we'll be moving forward at this time" — no reason, no timeline
Deal-DAFB82 pricing buyer no budget until 2028, other company priorities
Deal-2FEDDB no decision buyer unsure she can get this moving
Deal-64B19A competitor unknown "Likely stayed with Motivosity" — rep inference
Deal-3F86A0 no decision unknown unresponsive
Deal-096750 no decision buyer no meaningful contact after intro; four revive attempts ignored
Deal-F325A5 champion left buyer layoffs and change in leadership; no longer a priority
Deal-ABD14C other unknown "Not interested in signing up for our program." — no reason captured
Deal-79E61A no decision unknown Unresponsive.
Deal-8A119B pricing buyer "Didn't get approval."
Deal-AE7C4E no decision unknown Unresponsive.
Deal-DAB4F1 no decision unknown Unresponsive.
Deal-B4B50F no decision unknown Unresponsive
Deal-981AD4 product gap Bonusly "Doesn't fit UI and not UK focused."
Deal-DC77FE competitor Bonusly price was competitive; lost on customization (label points as dollars)
Deal-5885B9 no decision unknown MIA
CATEGORY COUNTS (count / % of 90 / lost amount / % of $1,267,945.16)
no decision 31 34.4% $278,262.00 21.9%
competitor 25 27.8% $382,234.96 30.1%
timing 19 21.1% $256,011.00 20.2%
pricing 5 5.6% $172,450.00 13.6%
product gap 5 5.6% $139,245.00 11.0%
other 4 4.4% $25,342.20 2.0%
champion left 1 1.1% $14,400.00 1.1%
90 100.0% $1,267,945.16 100.0%
Check: 31+25+19+5+5+4+1 = 90. Amounts sum to $1,267,945.16.
SIDE SPLIT
buyer 43 47.8% $534,846.40 42.2% of $
unknown 31 34.4% $385,392.20 30.4% of $
Bonusly 16 17.8% $347,706.56 27.4% of $
Bonusly-side average deal = 347,706.56 / 16 = $21,731.66 vs. book average 1,267,945.16 / 90 = $14,088.28 — the losses we own are ~1.54x larger than average.
TAG vs FREE-TEXT: 6 CLEAR DISAGREEMENTS (6.7% of 90, $94,950.00)
1. Deal-9048EB tag MIA -> text says bad fit + "multiple feature gaps" (product gap) $41,790
2. Deal-5AD03E tag Competitor -> text "Wanted more defined budget access", no rival $24,000
3. Deal-3618CC tag Lost DM -> text "Wanted Surveys" (product gap, not a DM issue) $15,600
4. Deal-55867E tag Timing (1 year or more) -> text gives no timeline at all $7,200
5. Deal-5E64CE tag Doing nothing/Not a priority/Cost -> text is a competitor contract lock (Nectar through Oct 2027 + exit fee) $3,360
6. Deal-70F704 tag Lost DM -> text is narrow scope + MIA, no DM problem stated $3,000
Three more are internally mixed rather than flatly contradictory, so I excluded them: Deal-B3ABED (Timing tag, text opens "MIA-" then gives a Q2 revisit), Deal-ED9AE7 (Lost DM tag, text lists timing + budget + authority), Deal-13E9CF (Doing nothing/Not a priority/Cost tag, text explicitly says "Not a budget issue"). If you count those, disagreements = 9 (10.0%, $171,041.00).
TWO PATTERNS MOST WORTH ACTING ON
1. One-third of lost revenue never produced a decision, and most of it never produced a diagnosis either.
no decision = 31 deals, $278,262. Of those, 21 deals ($212,352) are pure ghosting after intro/demo, and 15 of those 21 ($130,576) carry a free-text reason of one word — "MIA", "unresponsive", "no response". That is 15/90 = 16.7% of all losses with zero recoverable insight. The ghosting is not a single rep's problem: it spans all five owners (119337721: 9, 83155923: 8, 83155924: 8, 84342457: 5, 716654662: 1). Contact depth is thin on the way in — 68 of 90 deals (75.6%) closed with 3 or fewer contacts, and 24 of the 31 no-decision deals had 3 or fewer. Two deals show process leakage rather than buyer silence: Deal-E0441F was stale when inherited from a departed rep, and Deal-FAC17C sat with a contract out for two months waiting on an Executive IT Director who was never engaged. Action: require a named second and third stakeholder plus a written mutual next step before a deal advances past intro, and make "MIA"/"unresponsive" an invalid closed-lost reason — force last-touch date, contacts attempted, and last known blocker.
2. We lose to competitors more often than to price, but we can't say to whom or why in most cases.
competitor = 25 deals, $382,234.96 (30.1% of lost dollars) — over 2x the pricing category ($172,450, 5 deals). Only 15 of the 25 ($157,201) name a vendor or a differentiator; the other 10 ($225,034, 58.9% of competitive dollars) say only "went another direction" / "selected another vendor" / "Nothing specific provided" — including the two largest losses in the file, Deal-0F96AA ($76,800, cut before the finalist demo in an R&R RFP) and Deal-EECC02 ($66,690). Where detail does exist it is repeatable and product-shaped, not price-shaped: breadth beyond R&R (Deal-F97C37, Deal-A2C349 added surveys), points/currency flexibility and onsite redemption (Deal-242273 $60,000, Deal-DC77FE where the rep explicitly says "you were competitive in price so that wasn't a factor"), ecosystem/partner integrations (Deal-422BA6, ADP TotalSource preferred partner), local/regional fit (Deal-8A0992, Deal-9FCD0D, Deal-981AD4 "not UK focused"), and HR-suite incumbency (Deal-47F1A1 WorkTango, Deal-369281 Paylocity, Deal-BF2A98 HiThrive, Deal-64B19A Motivosity, Deal-D0C698 Kudos). Add the 5 product-gap deals ($139,245) and feature/fit reasons account for $521,479.96 across 30 deals. Action: make competitor name plus stated differentiator mandatory fields on any Competitor close, and run a win/loss debrief on every lost RFP; then route the recurring themes — suite breadth, points-as-currency customization, PEO/HRIS partner integrations, regional coverage — to product as a ranked list.
Data limits: no stage, source, segment, or first-touch date is provided, so I cannot separate early-funnel from late-stage losses, and n_contacts is a count with no role information, so "multithreading" here means contact volume only. Sides marked unknown (31 deals) are unknown because the text records an outcome without a cause — I did not infer one. Two competitor calls rest on rep inference rather than buyer confirmation (Deal-ACE061 "I feel they went with HeyTaco", Deal-64B19A "Likely stayed with Motivosity"). The file is labeled last 6 months but every close_date falls between 2026-07-29 and 2026-09-30, so this is a ~2-month window, not 6.
{
"tier_counts": {"LOCK": 3, "ACTION": 17, "BUILD": 44, "REVIVE": 10, "WATCH": 63, "RISKY": 19},
"tier_examples": {
"LOCK": ["Deal-D348E1", "Deal-C26D20", "Deal-403845"],
"ACTION": ["Deal-25F752", "Deal-E53952", "Deal-944310"],
"BUILD": ["Deal-A5E80A", "Deal-499BF6", "Deal-C6FE92"],
"REVIVE": ["Deal-2D1F1B", "Deal-950043", "Deal-012CB1"],
"WATCH": ["Deal-B7EBD1", "Deal-6787C2", "Deal-0660B4"],
"RISKY": ["Deal-FC22A3", "Deal-7BBDFA", "Deal-60C2C2"]
},
"risky_deals": ["Deal-FC22A3", "Deal-7BBDFA", "Deal-60C2C2", "Deal-4A13AD", "Deal-8AD4A5", "Deal-15D24F", "Deal-9D0060", "Deal-690476", "Deal-635B8E", "Deal-ED725A", "Deal-55164C", "Deal-3BA5EA", "Deal-5FDCE4", "Deal-F336B6", "Deal-5EED42", "Deal-BA3DDC", "Deal-7599B8", "Deal-F9A3C1", "Deal-FA32A0"],
"lock_violations": 0,
"pipeline_shape": "156 open deals; counts sum 3+17+44+10+63+19=156. The book is front-loaded and thin at the top: only 3 deals clear a LOCK bar (DS5 + COMMIT + >=1 meeting_30d + contact within 14 days of 2026-09-08 + >=3 contacts), while 20 of the 26 late-stage (DS4/DS5) deals sit in ACTION because 14 of them have zero meetings_30d despite COMMIT/BEST_CASE categories — email-only late-stage motion. RISKY is 19 deals, all BEST_CASE (or DS2 BEST_CASE Deal-690476) sitting in DS2/DS3 with zero meetings_30d and, in most cases, no meeting activity at all in 90d — forecast optimism unsupported by engagement. BUILD (44) is where real meeting momentum lives, concentrated in newly created DS1/DS2 deals from late August/early September. REVIVE (10) is stale early-stage, including the two largest amounts in the file (Deal-2D1F1B $240,000 last touched 2026-06-16 with zero meetings, Deal-950043 $70,000 last touched 2026-08-17), so the two biggest headline numbers are the least substantiated. Single-contact depth is the norm — n_contacts is 3 or fewer on 118 rows — so multithreading is shallow across the board. Data caveats: inbound_emails_30d is 0 on every row (stated defect), Deal-3EED2C and Deal-57FF13 have no row in engagements_by_deal_90d.csv and Deal-57FF13 also has blank last_contacted_field/n_contacts (tiered on stage+forecast only; n_contacts unavailable), and several last_meeting/last_email values are dated after 2026-09-08 (e.g. Deal-62D607 2026-09-22, Deal-3795AD 2026-10-02), which is a second data defect I did not correct."
}
TX-001
{
"transcript_id": "TX-001",
"deal_alias": "Deal-CFE7F4",
"why_buys": [
"Automating anniversary and birthday awards (VP People: 'The big win for us would be automating anniversary and birthday awards')"
],
"pain_points": [
"HR team of three cannot keep up with manual award administration",
"Everything tracked in a spreadsheet and 'people slip through the cracks'"
],
"stakeholders": ["Prospect (VP People)", "Prospect (HR Admin)"],
"budget_signal": "~$40k earmarked for engagement tools this fiscal year (VP People)",
"timeline_signal": "Wants live before open enrollment in November (VP People)",
"competitor_mentioned": "Achievers — prospect-raised, evaluated last year, 'too heavy for a team our size'",
"next_step": "Security review on September 12 (VP People: 'Yes — let's do the security review on September 12')",
"objections": [
"Requires SSO and audit logs for IT sign-off (HR Admin)",
"Prior perception that comparable platforms are too heavy for a 3-person HR team"
],
"confidence": "high",
"confidence_arithmetic": "5 of 5 signals present: budget stated (1) + timeline stated (1) + explicit next step (1) + 2 prospect stakeholders (1) + no active competing pilot (1) = 5/5 -> high"
}
TX-002
{
"transcript_id": "TX-002",
"deal_alias": "Deal-70BB30",
"why_buys": [
"Tie recognition to retention for the hourly workforce (Head of Total Rewards)"
],
"pain_points": [
"Regretted turnover in the hourly workforce is over 30%"
],
"stakeholders": ["Prospect (Head of Total Rewards)", "Prospect (CFO)"],
"budget_signal": "$25k pilot budget approved by finance for this quarter (CFO)",
"timeline_signal": "Decision by end of September (CFO)",
"competitor_mentioned": null,
"next_step": "Send pilot agreement; prospect routes it to legal this week (CFO: 'Yes — send the pilot agreement and we'll route it to legal this week')",
"objections": [
"Workday integration 'has to be rock solid' — CFO's stated one condition"
],
"confidence": "high",
"confidence_arithmetic": "5 of 5: budget (1) + timeline (1) + next step (1) + 2 stakeholders incl. economic buyer (1) + no competitor in cycle, 'first vendor we've had a real demo with' (1) = 5/5 -> high"
}
TX-003
{
"transcript_id": "TX-003",
"deal_alias": "Deal-530B50",
"why_buys": [
"Make recognition visible across 12 retail locations (People Ops Manager)"
],
"pain_points": [
"Store managers have zero budget autonomy for on-the-spot recognition today"
],
"stakeholders": ["Prospect (People Ops Manager)"],
"budget_signal": null,
"budget_note": "No prospect-stated budget. The $8 per employee per month figure came from the rep (Alex Franklin) and is excluded.",
"timeline_signal": "'No rush on our side until Q1' (People Ops Manager)",
"competitor_mentioned": "Bucketlist — prospect-raised; CEO used it at her last company and liked it",
"next_step": "Call with the CEO; prospect to send two times ('Yes, let's schedule a call with our CEO — I'll send two times')",
"objections": [
"No urgency until Q1",
"CEO must be sold first — she decides anything people-related (decision authority not engaged)",
"CEO has a positive prior with Bucketlist"
],
"confidence": "medium",
"confidence_arithmetic": "2 of 5: budget (0) + timeline stated though deprioritized (1) + next step (1) + only 1 prospect stakeholder (0) + competitor preference held by decision-maker (0) = 2/5 -> medium"
}
TX-004
{
"transcript_id": "TX-004",
"deal_alias": "Deal-180D02",
"why_buys": [
"Consolidate three separate recognition tools into one (VP People)"
],
"pain_points": [
"Paying for three tools and none of them talk to the HRIS"
],
"stakeholders": ["Prospect (VP People)", "Prospect (IT Security Lead)"],
"budget_signal": "Under $15k annually is approvable by VP People without going to the board (VP People)",
"timeline_signal": "Procurement cycle runs six to eight weeks minimum (IT Security Lead)",
"competitor_mentioned": null,
"competitor_note": "Three incumbent tools referenced but not named; no competing vendor named by the prospect.",
"next_step": null,
"next_step_note": "CFO follow-up was rep-proposed and not agreed: 'Maybe — I need to check her calendar, no promises.'",
"objections": [
"Procurement cycle six to eight weeks minimum",
"Security review took three months for the last vendor — stated hesitation",
"CFO access not committed"
],
"confidence": "low",
"confidence_arithmetic": "4 of 5 raw signals: budget (1) + timeline (1) + next step (0) + 2 stakeholders (1) + no competitor (1) = 4/5, but no agreed next step and no committed economic-buyer access caps this deal at low"
}
TX-005
{
"transcript_id": "TX-005",
"deal_alias": "Deal-F8767A",
"why_buys": [
"Automate service milestones (HR Director)",
"Analytics on recognition equity across departments (HR Director)"
],
"pain_points": [
"Night-shift teams feel invisible; their engagement scores run 20 points lower"
],
"stakeholders": ["Prospect (HR Director)", "Prospect (People Ops Coordinator)"],
"budget_signal": "$12k approved under the engagement line (HR Director)",
"timeline_signal": "Needs to be running before the January all-hands (HR Director)",
"competitor_mentioned": "Nectar — prospect-raised, currently mid-pilot, 'you'd need to beat that experience'",
"next_step": "Present to the exec team on October 2 (HR Director: 'Yes — come present to our exec team on October 2')",
"objections": [
"Must beat the in-flight Nectar pilot experience",
"Exec team skeptical after a failed rollout two years ago"
],
"confidence": "medium",
"confidence_arithmetic": "4 of 5: budget (1) + timeline (1) + next step (1) + 2 stakeholders (1) + active competing pilot in progress (0) = 4/5, downgraded from high to medium by the live Nectar pilot plus stated exec skepticism"
}
TX-006
{
"transcript_id": "TX-006",
"deal_alias": "Deal-EE195F",
"why_buys": [
"Cut admin time on service awards (HR Manager)"
],
"pain_points": [
"HR Manager personally spends five hours a month ordering and shipping plaques"
],
"stakeholders": ["Prospect (HR Manager)"],
"budget_signal": "'Budget isn't the issue — time is' (HR Manager). No dollar amount stated. Rep's offer to flex on pricing is excluded.",
"timeline_signal": "Fiscal year resets in February, so a Q1 start is realistic (HR Manager)",
"competitor_mentioned": null,
"competitor_note": "No vendor named; prospect is comparing against doing it internally.",
"next_step": "Send a one-page overview; prospect forwards it to the COO this week ('Yes — send the one-page overview and I'll forward it to our COO this week')",
"objections": [
"COO usually prefers building things in-house",
"Evaluation is against status quo / internal build rather than a purchase"
],
"confidence": "medium",
"confidence_arithmetic": "3.5 of 5: budget signal present but no amount (0.5) + timeline (1) + next step (1) + only 1 prospect stakeholder (0) + no competitor (1) = 3.5/5 -> medium; single-threaded with an in-house-biased COO not yet engaged"
}
Cross-transcript counts (arithmetic)
Explicit agreed next steps: 5 of 6 (TX-001, TX-002, TX-003, TX-005, TX-006); TX-004 = none.
Prospect-stated dollar budgets: 4 of 6 (40k + 25k + 15k + 12k = $92k total stated); TX-003 = null, TX-006 = no amount.
Prospect-raised competitors: 3 of 6 (Achievers, Bucketlist, Nectar).
Confidence distribution: high 2, medium 3, low 1.
Top 3 closest to signature (as of Slack export 2026-09-04) 1) Deal-547B2B — $11,200 — Alex Franklin, DS5/COMMIT, close 2026-09-11 Why close: strongest evidence in the data. Redlines returned clean, signing page sent, VP People stated they sign "tomorrow" (i.e., 2026-09-05), which is ahead of the CRM close date of 09-11. What's left: countersignature/execution and confirming the signature actually landed on 09-05; if it did, the CRM close date is stale. 2) Deal-403845 — $9,000 — CRM owner Alex Franklin, DS5/COMMIT, close 2026-09-11 Why close: order form is already with the prospect's finance team — that is post-legal, pre-signature. Confirmed "moving fine." What's left: finance sign-off and return of the executed order form. Flag: Dana Mercer described it as "on my side" while the CRM lists Alex Franklin as owner — ownership discrepancy needs reconciling. 3) Deal-A2B47C — $6,360 — Alex Franklin, DS5/COMMIT, close 2026-09-11 Why close: explicitly confirmed "still warm," in normal legal review, with no procurement freeze. DS5/COMMIT plus a near-term date. What's left: complete legal review, issue order form, get signature. Arithmetic: 11,200 + 9,000 + 6,360 = $26,560 in near-term signature-ready value. Explicit exclusions and gaps - Deal-2465CE ($5,400, DS5/COMMIT, 09-10) is CRM-stale: champion departed, procurement froze vendors, owner pulling it from commit — now Q4. CRM has not been updated. - Deal-B7EBD1 ($9,000, DS5/COMMIT, 09-10) has the earliest close date but zero Slack corroboration; it is the alternate #3 if verified. - Deal-D348E1 ($13,770) is warm but dated 2026-10-15 — larger, not nearer. - No data provided on signature status after 2026-09-04.
CANDIDATE REVIEW (5 transcripts, 4 prospect-voice candidates)
Deal amounts: NOT AVAILABLE. Neither transcripts_gaps.csv nor product_docs.md contains a deal amount, stage, or ARR field. No amounts are reported below because none were provided.
1) Deal-EC3025 — TG-001
Quote (Prospect, IT Security Lead): "We need SCIM user provisioning — our security team will not approve any tool that requires manual account management."
Docs check: Supported integrations section — "SCIM user provisioning and ADP Workforce Now integrations are NOT currently listed as supported capabilities." SCIM appears on no tier in the plan table (Core/Pro/Enterprise).
Classification: REAL GAP — not purchasable at any tier.
Amount: not provided in data.
2) Deal-D0D6B5 — TG-002
Quote (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."
Docs check: HRIS integrations listed = Workday, BambooHR, Gusto, Rippling (Pro and above). ADP Workforce Now explicitly "NOT currently listed as supported."
Classification: REAL GAP — not purchasable at any tier.
Amount: not provided in data.
3) Deal-CFE7F4 — TG-003
Quote (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?"
Docs check: "Custom report builder" = Enterprise only (Core —, Pro —, Enterprise yes). Capability exists.
Classification: PLAN GATE — resolved by tier upgrade, not by product build.
Amount: not provided in data.
4) Deal-84DBA6 — TG-004
Quote (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."
Docs check: "Slack and Microsoft Teams integration" = yes on Core, Pro, and Enterprise. Product is present and enabled; the stated cause is "nobody ever trained them."
Classification: ROLLOUT/ENABLEMENT ISSUE — adoption, not capability.
Amount: not provided in data.
EXCLUDED — TG-005, Deal-36C33F
The native-mobile-app statement ("we don't have a native mobile app for hourly workers yet") is spoken by Alex Franklin, the rep. Rep language does not count as prospect voice. The only prospect line in TG-005 raises no gap: "Good to know. The web version should be fine for our office staff for now." Note also that product_docs.md contains no mobile-app row, so the docs cannot confirm or deny that claim either way.
SUMMARY — REAL GAPS ONLY (2 of 4 prospect-voice candidates; 2/4 = 50%)
- SCIM user provisioning — Deal-EC3025 — amount not provided. Blocker owner: IT Security Lead (security approval gate).
- ADP Workforce Now integration — Deal-D0D6B5 — amount not provided. Blocker owner: HRIS Manager (called a "dealbreaker").
Both gaps are absent from every tier per the docs excerpt, so neither is closable by upsell or enablement. Roadmap status for either item is not stated in the provided docs — the rep replies referencing "product team" and "roadmap" are rep language and carry no documented commitment.
STALE OPEN DEALS — snapshot 2026-09-05 Method / arithmetic basis - Recency = max(last_email, last_call, last_meeting) from engagements_by_deal_90d.csv. The deal-level last_contacted_field was ignored as instructed. - days since last contact = 2026-09-05 minus that max date. "Last 7 days" window = 2026-08-29 through 2026-09-05 inclusive; a deal is stale if days ≥ 8. No deal landed at exactly 7 days, so the boundary choice does not change the result. - 156 open deals in deals_open.csv; 154 rows in the engagements table. Two open deals have NO engagements row at all (Deal-3EED2C, Deal-57FF13) — treated as stale with days = n/a, not fabricated. - Data anomaly: 17 engagement rows carry a last_meeting AFTER the 2026-09-05 snapshot (up to 2026-10-02). Those are impossible as "logged past activity," so I excluded future dates from the recency max and flagged each affected deal below. If you instead accept them at face value, 10 of the deals listed drop out and the totals become: Bryce Harmon 13 / $626,243; Dana Mercer 14 / $261,645; Cole Ingram 18 / $252,905.03; Alex Franklin 19 / $109,536; Farid Osman 0; Elena Sinclair 1 / $2,100 — 65 deals / $1,252,429.03. Primary numbers below use the future-dates-excluded rule. - Owner names from owners.csv. No stale deals belong to the two archived owners. BRYCE HARMON (owner_id 119337721) — 18 stale, $692,964 Deal-2D1F1B DS1 $240,000 last 2026-06-16 (meeting) 81 days Deal-66D1FC DS1 $99,000 last 2026-08-20 (email) 16 days Deal-950043 DS1 $70,000 last 2026-08-17 (email) 19 days Deal-B23205 DS1 $45,000 last 2026-08-20 (email+mtg) 16 days Deal-7BBDFA DS3 $37,440 last 2026-07-21 (email) 46 days Deal-332637 DS2 $36,000 last 2026-08-27 (email) 9 days Deal-1BEEBF DS1 $31,500 last 2026-08-17 (email) 19 days Deal-A414F6 DS1 $25,200 last 2026-08-17 (email) 19 days [future last_meeting 2026-09-10 excluded] Deal-C5658B DS1 $23,400 last 2026-08-20 (email) 16 days Deal-40522D DS3 $21,000 last 2026-08-17 (email) 19 days Deal-C1FA6D DS1 $18,000 last 2026-08-20 (email) 16 days [future last_meeting 2026-09-15 excluded] Deal-01E193 DS1 $12,600 last 2026-08-28 (email) 8 days [future last_meeting 2026-09-09 excluded] Deal-F0EBBB DS3 $11,400 last 2026-08-12 (email) 24 days Deal-927338 DS1 $10,920 last 2026-08-18 (email) 18 days [future last_meeting 2026-09-17 excluded] Deal-E25A09 DS1 $6,000 last 2026-08-27 (email) 9 days Deal-C9C286 DS2 $5,502 last 2026-08-27 (email) 9 days Deal-012CB1 DS1 $1 last 2026-08-13 (email) 23 days Deal-3795AD DS2 $1 last 2026-08-28 (email) 8 days [future last_meeting 2026-10-02 excluded] 240,000+99,000+70,000+45,000+37,440+36,000+31,500+25,200+23,400+21,000+18,000+12,600+11,400+10,920+6,000+5,502+1+1 = 692,964 DANA MERCER (83155923) — 16 stale, $279,495 Deal-44EA29 DS2 $60,000 last 2026-08-26 (email) 10 days Deal-E51FB7 DS2 $43,875 last 2026-08-24 (call) 12 days Deal-B42F46 DS1 $27,000 last 2026-08-17 (email) 19 days Deal-BA3DDC DS3 $23,400 last 2026-08-21 (call) 15 days Deal-9DDE86 DS2 $20,000 last 2026-08-21 (email) 15 days Deal-215CCA DS3 $18,900 last 2026-08-19 (meeting) 17 days Deal-5EED42 DS3 $16,250 last 2026-08-25 (email+call)11 days Deal-57887A DS2 $15,000 last 2026-08-28 (email) 8 days Deal-944310 DS4 $10,500 last 2026-08-03 (email) 33 days [future last_meeting 2026-09-15 excluded] Deal-3974EB DS4 $9,000 last 2026-08-28 (email+mtg) 8 days Deal-B7EBD1 DS5 $9,000 last 2026-08-20 (email) 16 days Deal-F40F04 DS2 $8,100 last 2026-08-21 (email+mtg) 15 days Deal-7599B8 DS3 $7,350 last 2026-08-18 (email) 18 days [future last_meeting 2026-09-10 excluded] Deal-87DDD1 DS1 $5,000 last 2026-08-17 (email) 19 days Deal-F336B6 DS3 $4,200 last 2026-08-21 (email) 15 days Deal-0660B4 DS4 $1,920 last 2026-08-20 (meeting) 16 days 60,000+43,875+27,000+23,400+20,000+18,900+16,250+15,000+10,500+9,000+9,000+8,100+7,350+5,000+4,200+1,920 = 279,495 COLE INGRAM (83155924) — 18 stale, $252,905.03 Deal-D04904 DS2 $58,529.25 last 2026-08-25 (email) 11 days Deal-B25F40 DS3 $40,000 last 2026-08-28 (email) 8 days Deal-813836 DS2 $32,175 last 2026-08-25 (email) 11 days Deal-1BA595 DS2 $31,750 last 2026-08-25 (email) 11 days Deal-CFE1E8 DS3 $18,000 last 2026-08-25 (email) 11 days Deal-CD47A6 DS2 $12,168 last 2026-08-25 (email) 11 days Deal-627646 DS3 $11,193 last 2026-08-25 (email) 11 days Deal-FF809F DS2 $7,781.20 last 2026-08-25 (email) 11 days Deal-AF932D DS2 $7,225.40 last 2026-08-25 (email) 11 days Deal-A71728 DS2 $6,947.50 last 2026-08-25 (email) 11 days Deal-8BC9F5 DS2 $5,616 last 2026-08-26 (email) 10 days Deal-175395 DS3 $4,779.88 last 2026-08-25 (email) 11 days Deal-481E24 DS3 $4,140 last 2026-08-26 (call) 10 days Deal-C7F9BF DS2 $3,360 last 2026-08-25 (email) 11 days Deal-2F3A66 DS3 $3,334.80 last 2026-08-25 (email) 11 days Deal-342E96 DS2 $2,700 last 2026-08-12 (email) 24 days Deal-E568D5 DS3 $1,875 last 2026-08-25 (email) 11 days Deal-FD9F4E DS5 $1,330 last 2026-08-26 (email) 10 days 58,529.25+40,000+32,175+31,750+18,000+12,168+11,193+7,781.20+7,225.40+6,947.50+5,616+4,779.88+4,140+3,360+3,334.80+2,700+1,875+1,330 = 252,905.03 ALEX FRANKLIN (84342457) — 20 stale, $113,936 Deal-CC08D1 DS1 $24,000 last 2026-08-20 (email) 16 days Deal-E73427 DS3 $18,000 last 2026-08-26 (email+mtg) 10 days Deal-885F45 DS2 $9,300 last 2026-08-24 (email) 12 days Deal-C2FF3C DS1 $8,316 last 2026-08-26 (email) 10 days Deal-3EED2C DS2 $7,200 NO engagements row — no logged email/call/meeting; days n/a Deal-0D2F7A DS3 $5,100 last 2026-08-24 (call) 12 days Deal-6C60D4 DS3 $4,800 last 2026-08-24 (call) 12 days Deal-13FEBD DS2 $4,680 last 2026-08-24 (call) 12 days Deal-819506 DS1 $4,400 last 2026-08-28 (email) 8 days [future last_meeting 2026-09-09 excluded] Deal-9D0060 DS3 $3,840 last 2026-08-24 (email) 12 days Deal-690476 DS2 $3,600 last 2026-08-18 (call) 18 days Deal-C6D97A DS4 $3,240 last 2026-08-28 (email) 8 days Deal-EE195F DS3 $3,120 last 2026-08-28 (email) 8 days Deal-278DEC DS3 $2,700 last 2026-08-28 (email) 8 days Deal-635B8E DS3 $2,600 last 2026-08-18 (email) 18 days Deal-6883F3 DS1 $2,400 last 2026-08-20 (email+mtg) 16 days Deal-4A13AD DS3 $2,160 last 2026-08-10 (email) 26 days Deal-F67D31 DS2 $1,800 last 2026-08-28 (email) 8 days Deal-5FDCE4 DS3 $1,600 last 2026-08-24 (email) 12 days Deal-BA571A DS4 $1,080 last 2026-08-18 (email) 18 days 24,000+18,000+9,300+8,316+7,200+5,100+4,800+4,680+4,400+3,840+3,600+3,240+3,120+2,700+2,600+2,400+2,160+1,800+1,600+1,080 = 113,936 FARID OSMAN (716654662) — 2 stale, $2,881 Deal-8BA24E DS1 $2,880 last 2026-08-28 (email) 8 days [future last_meeting 2026-09-15 excluded] Deal-8FDCD2 DS1 $1 last 2026-08-21 (email) 15 days [future last_meeting 2026-09-15 excluded] 2,880+1 = 2,881 ELENA SINCLAIR (701163055) — 1 stale, $2,100 Deal-57FF13 DS1 $2,100 NO engagements row — no logged email/call/meeting; days n/a 2,100 PER-OWNER SUMMARY (ordered by stale amount) Bryce Harmon 18 deals $692,964 Dana Mercer 16 deals $279,495 Cole Ingram 18 deals $252,905.03 Alex Franklin 20 deals $113,936 Farid Osman 2 deals $2,881 Elena Sinclair 1 deal $2,100 Total 75 deals $1,344,281.03 Check: 692,964 + 279,495 + 252,905.03 + 113,936 + 2,881 + 2,100 = 1,344,281.03 Missing data called out explicitly - Deal-3EED2C (Alex Franklin) and Deal-57FF13 (Elena Sinclair): absent from engagements_by_deal_90d.csv, so no last_email/last_call/last_meeting exists. Days since last contact is unknown, not zero. - 17 engagement rows have last_meeting dates after the 2026-09-05 snapshot; those values are internally inconsistent with the snapshot and cannot be used as evidence of contact in the trailing 7 days. - last_call is blank on most rows, so many recency figures rest on email (and meeting) only.
Window: t_ds2 and 30-day engagement counts taken as 2026-08-06 through 2026-09-05 inclusive (snapshot 2026-09-05 minus 30 days). PER-REP 30-DAY ACTIVITY AND DS2 ENTRIES rep emails calls meetings total DS2 entries Alex Franklin 307 36 41 384 18 Bryce Harmon 162 0 43 205 4 Dana Mercer 84 18 11 113 1 Cole Ingram 96 14 1 111 2 Farid Osman 38 0 34 72 1 Elena Sinclair 0 0 0 0 0 Archived owners Gavin Porter and Hugo Lindqvist own no deals in deals_open.csv, so they have no data. ACTIVITY MIX (share of that rep's own total) Alex Franklin: emails 307/384 = 79.9% | calls 36/384 = 9.4% | meetings 41/384 = 10.7% Bryce Harmon: emails 162/205 = 79.0% | calls 0/205 = 0.0% | meetings 43/205 = 21.0% Dana Mercer: emails 84/113 = 74.3% | calls 18/113 = 15.9% | meetings 11/113 = 9.7% Cole Ingram: emails 96/111 = 86.5% | calls 14/111 = 12.6% | meetings 1/111 = 0.9% Farid Osman: emails 38/72 = 52.8% | calls 0/72 = 0.0% | meetings 34/72 = 47.2% Elena Sinclair: not computable — 0 total activities (division by zero) ACTIVITIES PER DS2 ENTRY — RANKED (lowest = most efficient) 1. Alex Franklin 384 / 18 = 21.33 2. Bryce Harmon 205 / 4 = 51.25 3. Cole Ingram 111 / 2 = 55.50 4. Farid Osman 72 / 1 = 72.00 5. Dana Mercer 113 / 1 = 113.00 –. Elena Sinclair 0 / 0 = undefined (0 activities, 0 DS2 entries — cannot compute) MOST EFFICIENT vs HIGHEST VOLUME Most efficient: Alex Franklin (21.33 activities per DS2 entry). Highest volume: Alex Franklin (384 total activities). They do not differ — Alex Franklin is both the highest-volume rep and the most efficient rep on this ratio. DS2 ENTRIES IN WINDOW (aliases, t_ds2) Alex Franklin (18): Deal-EE195F 08-06, Deal-D9A72E 08-06, Deal-7FA0C3 08-07, Deal-E531A6 08-07, Deal-36C33F 08-11, Deal-D1E6C2 08-11, Deal-317E6F 08-12, Deal-4F775F 08-17, Deal-F436DA 08-19, Deal-CA5E44 08-24, Deal-46988D 08-26, Deal-5296C9 08-28, Deal-898FC5 08-28, Deal-E73427 08-28, Deal-403845 09-02, Deal-92D97D 09-02, Deal-1FC049 09-03, Deal-3EED2C 09-03 Bryce Harmon (4): Deal-1CCE5C 08-06, Deal-25F752 08-10, Deal-CA7DC0 08-12, Deal-D73B89 09-03 Cole Ingram (2): Deal-1BA595 08-12, Deal-42326B 08-26 Dana Mercer (1): Deal-57887A 08-07 Farid Osman (1): Deal-499BF6 08-26 Elena Sinclair (0): none DATA LIMITATIONS (stated, not inferred) - Two deals in deals_open.csv have no row in engagements_by_deal_90d.csv, so they contribute 0 activities: Deal-3EED2C (owner Alex Franklin — it does count as one of his 18 DS2 entries) and Deal-57FF13 (owner Elena Sinclair, which is why her activity total is 0). Alex's ratio is therefore computed on activity data that is missing for one of his 18 DS2 deals. - The engagements table is keyed by deal_id for open deals only. Any rep activity not attached to an open deal (closed-won, closed-lost, prospecting with no deal record) is absent from this dataset, so these are open-pipeline activity totals, not full rep activity totals. - Deal-57FF13 also has blank last_contacted_field and blank n_contacts. - Some last_meeting values in the engagements file are dated after the 2026-09-05 snapshot (e.g. 2026-09-22 on deal 60083610979, 2026-10-02 on 62704497525). I did not use last_meeting in any calculation; the meetings_30d counts were used as given. - Elena Sinclair's efficiency ratio is undefined, not "best" or "worst" — she has 0 in both numerator and denominator.
QTD SCORECARD — Alex Franklin | 2026-Q3 | as of 2026-09-05
Source: ae_deals.csv, ae_engagements.csv, quota.csv. Quarter window assumed 2026-07-01 to 2026-09-30.
1. BOOKINGS VS QUOTA
Closed-won with close_date inside the quarter (8 deals):
Deal-A1C3E5 2026-07-15 40,000 new
Deal-F2C7D8 2026-07-24 20,000 expansion
Deal-B7D2F4 2026-07-31 35,000 new
Deal-C9E1A6 2026-08-12 21,000 new
Deal-A8B4D6 2026-08-19 12,000 expansion
Deal-D4B8C2 2026-08-21 11,000 new
Deal-E6F3A9 2026-09-02 6,500 new
Deal-C5D9E2 2026-09-03 4,500 expansion
40,000+20,000+35,000+21,000+12,000+11,000+6,500+4,500 = 150,000
Quota (2026-Q3): 200,000
Attainment: 150,000 / 200,000 = 0.75 = 75.0%
Gap to quota: 200,000 - 150,000 = 50,000
EXCLUDED per instruction: Deal-B3E6F1, closed-won 2026-06-20, 24,000 — pre-quarter, not counted.
2. NEW VS EXPANSION SPLIT (in-quarter wins)
New: 5 deals 40,000+35,000+21,000+11,000+6,500 = 113,500 113,500/150,000 = 75.7%
Expansion: 3 deals 20,000+12,000+4,500 = 36,500 36,500/150,000 = 24.3%
Avg new deal 113,500/5 = 22,700 | avg expansion 36,500/3 = 12,167
3. ACTIVE PIPELINE BY STAGE (status=open, 125 deals, 1,260,390 total)
Stage Deals Amount Avg % of open $
DS1 20 284,621 14,231 22.6%
DS2 28 353,760 12,634 28.1%
DS3 67 552,705 8,249 43.9%
DS4 5 23,574 4,715 1.9%
DS5 5 45,730 9,146 3.6%
Total 125 1,260,390 10,083 100.0%
Check: 284,621+353,760+552,705+23,574+45,730 = 1,260,390
Subset closing inside 2026-Q3 (close_date <= 2026-09-30): 22 deals, 109,363
DS2 2 / 5,760 | DS3 14 / 69,399 | DS4 3 / 7,644 | DS5 3 / 26,560
Coverage of the 50,000 gap: 109,363 / 50,000 = 2.19x
4. ROLLING 90-DAY DS2-TO-WON RATE
Window: entered_ds2 between 2026-06-07 and 2026-09-05 (90 days back from as-of).
Cohort: 111 deals. Outcomes: 8 won, 27 lost, 76 still open.
DS2-to-won (full cohort): 8 / 111 = 7.2%
DS2-to-won (decided only, 8+27=35): 8 / 35 = 22.9%
Note: 76 of 111 (68.5%) are undecided, so the 7.2% figure is a floor and the 22.9% decided rate is the more usable read.
Median DS2-to-close cycle on the 8 wins: (23,25,29,29,41,30,28,24) → mean 28.6 days.
5. WIN AND LOSS COUNTS (closes inside the quarter)
Wins: 8 / 150,000
Losses: 27 / 329,272
Win rate by count: 8 / (8+27) = 8/35 = 22.9%
Win rate by dollars: 150,000 / (150,000+329,272) = 150,000/479,272 = 31.3%
Loss reasons (all 27 losses fall in-quarter):
Lost- Timing (1 year or more) 13 184,681 48.1% of losses
Competitor 5 49,020 18.5%
MIA 5 45,831 18.5%
Lost DM 2 17,940 7.4%
Feature Request 1 21,000 3.7%
Lost- Does not fit ICP (write in notes) 1 10,800 3.7%
Top loss reason: "Lost- Timing (1 year or more)" — 13 of 27 (48.1%), 184,681 lost.
6. ACTIVITY VOLUME BY TYPE, LAST 30 DAYS (all 161 deals in ae_engagements.csv)
Type Volume % of mix
Emails 807 73.6%
Meetings 128 11.7%
Calls 112 10.2%
Notes 50 4.6%
Total 1,097 100.0% (807+112+128+50 = 1,097)
Split by deal outcome:
Won deals (9): 99 email / 33 call / 25 mtg / 24 note = 181 → 20.1 touches per deal
Lost deals (27): 109 email / 25 call / 13 mtg / 25 note = 172 → 6.4 per deal
Open deals (125): 599 email / 54 call / 90 mtg / 1 note = 744 → 6.0 per deal
Per-deal email/call/meeting: won 11.0 / 3.7 / 2.8 — open 4.8 / 0.4 / 0.7.
Data limitation: ae_engagements.csv gives only 30-day totals per deal with no activity dates, so no weekly trend or per-day pacing can be produced.
COACHING OBSERVATIONS
1. The quarter is decided by conversion, not coverage. He needs 50,000 more and has 109,363 open with an in-quarter close date — but at his own 22.9% decided win rate that pipeline expects 109,363 × 0.229 = 25,044, roughly half the gap. Worse, only 5,760 of it sits in DS2 and 96,043 of the 109,363 (87.8%) is DS3-and-earlier with an average size of 4,971. There is no single deal in the in-quarter set large enough to move him materially; closing the gap requires roughly 10 of those small deals landing, versus 8 wins in the whole quarter so far.
2. Timing losses at 48.1% point to qualification, not closing skill. 13 of 27 losses (184,681) died on "Timing (1 year or more)" and another 5 (45,831) went MIA — together 18 of 27 losses, 66.7%, and 230,512 in dollars, on reasons that surface before pricing. Those 13 timing losses averaged 35.1 days from DS2 to close, so he spent roughly 5 weeks each working deals with no event forcing a decision. Competitor losses are only 5 of 27 (18.5%) — he is not losing bake-offs, he is advancing deals that were never in-market.
3. His winning motion is call-and-meeting heavy, and his open pipeline is not getting it. Won deals carry 3.7 calls and 2.8 meetings per deal in the last 30 days; open deals carry 0.4 and 0.7. Of 125 open deals, 103 (82.4%) logged zero calls and 62 (49.6%) logged zero calls AND zero meetings in 30 days, while email is 73.6% of all activity. Notes are effectively absent on open deals — 1 note across 125 deals versus 24 across 9 wins. Compounding it, 29 open deals worth 282,960 entered DS2 more than 90 days ago (median open-deal age 61 days, max 285), so nearly a quarter of pipeline dollars are aging in stage on an email-only cadence. Reallocating call and meeting time onto the 22 in-quarter deals, and purging the stale 29, would align effort with the pattern that actually produced his 150,000.
MISSING DATA (stated up front, not inferred):
- deal_contacts.csv contains no amount column — deal amounts are not on file, so I cannot report them.
- deal_contacts.csv contains no stage column — stages are not on file. Because of that, "most valuable persona to add given the stage" is answered from persona coverage only, not stage; I am flagging that the stage-based ranking cannot be grounded in this data.
- There is also no deal-status/open-closed field. All 14 deals in the file are treated as in-scope because open/closed cannot be distinguished from the data given.
ACTIVITY CUTOFF ARITHMETIC
Reference date 2026-09-08. 60 days back: Sep 8 − 8 days = Aug 31 (8), − 31 days = Jul 31 (39), − 21 days = Jul 10 (60). Cutoff = last_engaged_date on/after 2026-07-10, AND is_former = false.
Rows excluded as inactive:
- CT-F2C1AE (Deal-EC3025) — is_former true
- CT-A902AE (Deal-92D97D) — 2026-06-01: 29 (Jun) + 31 (Jul) + 31 (Aug) + 8 = 99 days > 60
- CT-405B45, CT-86B22F (Deal-36C33F) — both is_former true
- CT-913581 (Deal-F9A08A) — 2026-06-20: 10 + 31 + 31 + 8 = 80 days > 60
FLAGGED DEALS: 10 of 14
1) Deal-EC3025 (C-FDD0C7) — SINGLE-THREADED
Amount: not on file. Stage: not on file.
Active contacts: 1 (2 rows − 1 former = 1)
Personas present: champion (CT-047C54)
Personas missing: economic buyer, HR admin, IT security, finance
Most valuable to add: economic buyer — the only prior economic buyer (CT-F2C1AE, Chief People Officer) is marked former, so there is no budget authority left in the deal.
Unengaged fit on file: CT-6827DB, Chief People Officer, economic buyer
2) Deal-92D97D (C-E23238) — SINGLE-THREADED
Amount: not on file. Stage: not on file.
Active contacts: 1 (2 rows − 1 lapsed at 99 days = 1)
Personas present: HR admin (CT-01F5B4)
Personas missing: economic buyer, champion, IT security, finance
Most valuable to add: economic buyer — the deal sits entirely with an HRIS Manager; no champion and no buying authority.
Unengaged fit on file: none on file
3) Deal-50D386 (C-EB10E4) — UNDER-THREADED (2 < 3)
Amount: not on file. Stage: not on file.
Active contacts: 2
Personas present: champion (CT-AA41B2), HR admin (CT-B9C35B)
Personas missing: economic buyer, IT security, finance
Most valuable to add: economic buyer
Unengaged fit on file: CT-A1C4B3, Chief People Officer, economic buyer
4) Deal-D0D6B5 (C-32918E) — UNDER-THREADED (3 contacts, all one persona)
Amount: not on file. Stage: not on file.
Active contacts: 3
Personas present: champion only (CT-87CED4, CT-DE6D7C, CT-FD70B2)
Personas missing: economic buyer, HR admin, IT security, finance
Most valuable to add: economic buyer — three champions, zero authority.
Unengaged fit on file: CT-1FA4DB, Chief People Officer, economic buyer
5) Deal-5BFE3B (C-535D36) — UNDER-THREADED (2 < 3, and all one persona)
Amount: not on file. Stage: not on file.
Active contacts: 2
Personas present: champion only (CT-57123B, CT-5CE757)
Personas missing: economic buyer, HR admin, IT security, finance
Most valuable to add: economic buyer
Unengaged fit on file: none on file
6) Deal-36C33F (C-077A0E) — SINGLE-THREADED
Amount: not on file. Stage: not on file.
Active contacts: 1 (3 rows − 2 former = 1)
Personas present: IT security (CT-4FE556)
Personas missing: economic buyer, champion, HR admin, finance
Most valuable to add: champion — both the former champion and former economic buyer have churned out; the only live contact is IT security, who cannot carry the deal. (Economic buyer is a close second and is available unengaged.)
Unengaged fit on file: CT-1DB73E, Chief People Officer, economic buyer
7) Deal-885F45 (C-5E8EFB) — UNDER-THREADED (2 < 3)
Amount: not on file. Stage: not on file.
Active contacts: 2
Personas present: economic buyer (CT-51C81E), champion (CT-D9A0E8)
Personas missing: HR admin, IT security, finance
Most valuable to add: IT security — the only missing persona with a named unengaged contact on file at this company.
Unengaged fit on file: CT-B3F25D, IT Security Lead, IT security
8) Deal-FCBE5B (C-737030) — SINGLE-THREADED
Amount: not on file. Stage: not on file.
Active contacts: 1 (only row in file)
Personas present: champion (CT-4A5317, People Ops Manager)
Personas missing: economic buyer, HR admin, IT security, finance
Most valuable to add: economic buyer — thinnest deal in the set; one contact total on file.
Unengaged fit on file: none on file
9) Deal-5408B0 (C-2AE3AA) — UNDER-THREADED (2 < 3)
Amount: not on file. Stage: not on file.
Active contacts: 2
Personas present: champion (CT-D33AE4), HR admin (CT-8742FD)
Personas missing: economic buyer, IT security, finance
Most valuable to add: economic buyer
Unengaged fit on file: CT-07FA76, Chief People Officer, economic buyer
10) Deal-C6D97A (C-5A8FC2) — UNDER-THREADED (3 contacts, all one persona)
Amount: not on file. Stage: not on file.
Active contacts: 3
Personas present: champion only (CT-223DDC, CT-B03555, CT-4E8A2B)
Personas missing: economic buyer, HR admin, IT security, finance
Most valuable to add: economic buyer
Unengaged fit on file: none on file
11) Deal-F9A08A (C-0D15DF) — SINGLE-THREADED
Amount: not on file. Stage: not on file.
Active contacts: 1 (2 rows − 1 lapsed at 80 days = 1)
Personas present: champion (CT-931B10)
Personas missing: economic buyer, HR admin, IT security, finance
Most valuable to add: economic buyer — CT-913581 (Chief People Officer) is on the deal but went cold 80 days ago; re-engage or replace.
Unengaged fit on file: CT-697541, Chief People Officer, economic buyer
That is 11 flagged deals, not 10 — corrected count: 11 of 14 deals flagged.
NOT FLAGGED (3 deals — 3+ active contacts across 2+ personas)
- Deal-84DBA6 (C-BE9BE0): 3 active — champion, economic buyer, IT security. (Finance gap only; CT-2A0169, Controller, finance is unengaged on file.)
- Deal-4B0BEB (C-1BDFE0): 4 active — champion, economic buyer, HR admin, finance.
- Deal-D348E1 (C-804F29): 5 active — champion, economic buyer, IT security, finance, HR admin. All five personas covered.
TALLY CHECK: 11 flagged + 3 clean = 14 deals, matching the 14 distinct deal_ids in deal_contacts.csv. Unengaged contacts matched to a flagged deal: 7 of the 9 rows in unengaged_contacts.csv; the 2 unmatched rows are CT-2A0169 (C-BE9BE0) and CT-8E04F5 (C-804F29), both belonging to non-flagged deals.
FIRST FIVE MINUTES (minutes 0–5, n=10 calls)
Opening move counts:
- Case-study/social-proof cold open — 8/10 (80%): TT-001 Deal-D348E1, TT-002 Deal-5408B0, TT-003 Deal-547B2B, TT-005 Deal-C61CF7, TT-006 Deal-60C2C2, TT-007 Deal-EDC141, TT-008 Deal-D9A12F, TT-010 Deal-84DBA6
- Agenda-setting open — 1/10: TT-004 Deal-403845
- Pricing-first open — 1/10: TT-009 Deal-1E2498
The 8 case-study opens are byte-identical to each other, and all 8 are the rep's minute-0 line:
"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."
No discovery question from the rep appears in minutes 0–5 in any of the 10 calls. The only other rep content inside the first five minutes is a competitor contrast at minute 2 of TT-005 and two competitor rebuttals at minute 5 (TT-003, TT-007).
THREE MOST COMMON OBJECTIONS AND HANDLING
1) Budget locked / no new line item — 4 occurrences (TT-001, TT-003, TT-006, TT-010), all at minute 6. 4/10 = 40% of calls.
Handled identically all 4 times, reframing to self-funding via turnover savings:
"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."
2) Revisit next quarter / open enrollment — 3 occurrences (TT-002, TT-005, TT-008), all at minute 6. 3/10 = 30%.
Handled identically all 3 times, 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?"
3) Status quo: spreadsheet + quarterly gift cards — 3 occurrences (TT-004, TT-007, TT-009), all at minute 6. 3/10 = 30%. (Tied with #2 at 3; both reported.)
Handled identically all 3 times, on automation + 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."
Also present but below the top three: committee/approval gate — 2 occurrences (TT-004 minute 11, TT-010 minute 11), and "no urgency" — 1 occurrence (TT-007 minute 14). Neither received a substantive response; the rep's replies were "Understood — I'll leave it with you," "Understood, thanks for the candor," and "Fair enough."
CONCRETE NEXT STEP AGREED — RATE
Rep asked for the next step in 7/10 calls (TT-001, TT-002, TT-003, TT-005, TT-006, TT-008, TT-009), each time at minute 14 with the same line: "Should we lock the next step — a working session with your team this week?"
Prospect confirmed a specific, dated commitment in all 7, each time at minute 15:
"Yes, Thursday at 2pm works — send the invite and I'll bring our HRIS manager."
Arithmetic:
- Next-step agreement rate = 7 agreed / 10 calls = 0.70 = 70%
- Ask rate = 7 / 10 = 70%
- Conversion when asked = 7 / 7 = 100%
- Conversion when not asked = 0 / 3 = 0% (TT-004, TT-007, TT-010)
COMPETITORS RAISED BY A PROSPECT (complete list, n=2)
- Awardco — TT-003, Deal-547B2B, 2026-08-04, prospect at minute 4: "We're also in late talks with Awardco — their rewards catalog looks bigger than yours."
- Kudos — TT-007, Deal-EDC141, 2026-08-19, prospect at minute 4: "How are you different from Kudos? Our CEO used them at her last company."
Explicitly not a prospect-raised competitor: Workhuman appears only once, spoken by the rep at minute 2 of TT-005 (Deal-C61CF7). No prospect in these transcripts mentions Workhuman. Prospect-raised competitor rate = 2/10 = 20% of calls.
Data limitation: transcripts.csv contains only 4–8 sampled lines per call (43 rows total), so absence of a line is not proof the topic never came up. Multiple rep lines are verbatim-identical across calls, and all 7 next-step confirmations are the identical string, which limits how much can be inferred about genuine per-deal variation. No call outcome, stage, amount, or duration field is provided, so next-step quality beyond the stated Thursday 2pm cannot be assessed.
COACHING NOTES
1. Ask for the next step on every call. Every ask closed (7/7); every call without the ask ended with zero commitment (0/3 — TT-004, TT-007, TT-010). The three no-ask calls are also the three where the rep closed with a concession line ("I'll leave it with you," "Fair enough," "thanks for the candor") instead of a question. Reinstating the minute-14 ask in those three would move the rate from 7/10 to a potential 10/10 on ask coverage.
2. Build a real answer for the committee gate and open with discovery instead of the script. The committee objection surfaced twice (TT-004, TT-010) and received no counter both times — pair it with the $210k avoided-backfill frame already proven on the budget objection, and offer to be introduced to finance. Separately, 8/10 calls opened with the same verbatim retailer story and no question in minutes 0–5; the two calls that opened situationally (TT-004 agenda, TT-009 pricing) show the rep can adapt, but neither closed for a next step, so the fix is a tailored open *plus* the minute-14 ask, not one or the other.
Q3 2026 FORECAST — pipeline: default | close window 2026-07-01 to 2026-09-30 | source: CRM warehouse extract, pulled 2026-09-05 Extract contains 86 open deals; 54 close inside the quarter, 32 outside. CATEGORY TOTALS INSIDE THE QUARTER COMMIT — 7 deals, $44,729 Deal-547B2B DS5 2026-09-11 11,200 Deal-B7EBD1 DS5 2026-09-10 9,000 Deal-403845 DS5 2026-09-11 9,000 Deal-A2B47C DS5 2026-09-11 6,360 Deal-2465CE DS5 2026-09-10 5,400 Deal-A5E80A DS1 2026-09-11 2,520 Deal-499BF6 DS2 2026-09-30 1,249 11,200 + 9,000 + 9,000 + 6,360 + 5,400 + 2,520 + 1,249 = 44,729 BEST_CASE — 24 deals, $203,565 38,935 + 24,000 + 19,656 + 16,250 + 11,116 + 10,800 + 10,500 + 9,890 + 9,720 + 9,000 + 7,200 + 3,840 + 3,780 + 3,600 + 3,240 + 3,150 + 3,120 + 3,060 + 2,916 + 2,760 + 2,484 + 2,100 + 1,920 + 528 = 203,565 PIPELINE — 23 deals, $201,637.40 (weighted at 0 percent, contributes nothing) WEIGHTED FORECAST COMMIT at 100% = 44,729 × 1.00 = 44,729.00 BEST_CASE at 35% = 203,565 × 0.35 = 71,247.75 Weighted Q3 forecast = 44,729.00 + 71,247.75 = $115,976.75 EXCLUDED — CLOSE DATE OUTSIDE THE QUARTER 32 deals, $227,575 total. Every excluded deal falls after the quarter (2026-10-01 through 2026-10-15); none fall before 2026-07-01 (earliest close date in the extract is 2026-08-28). By category: PIPELINE 22 deals / $185,565; BEST_CASE 9 deals / $28,240; COMMIT 1 deal / $13,770 (Deal-D348E1, DS5, 2026-10-15). Had that one COMMIT and those 9 BEST_CASE deals been dated inside the quarter, the forecast would rise by 13,770 + (28,240 × 0.35 = 9,884) = $23,654. TOP 5 BEST_CASE DEALS INSIDE THE QUARTER 1. Deal-2D7423 DS3 2026-09-30 38,935 (weighted 13,627.25) 2. Deal-25F752 DS4 2026-09-25 24,000 (weighted 8,400.00) 3. Deal-E53952 DS4 2026-09-30 19,656 (weighted 6,879.60) 4. Deal-5EED42 DS3 2026-09-30 16,250 (weighted 5,687.50) 5. Deal-FA32A0 DS3 2026-09-25 11,116 (weighted 3,890.60) Top-5 subtotal: 38,935 + 24,000 + 19,656 + 16,250 + 11,116 = 109,957 109,957 / 203,565 = 54.0% of in-quarter BEST_CASE value sits in 5 of 24 deals; their weighted contribution is 38,484.95 of the 71,247.75 BEST_CASE weighting. ## Data quality Forecast category and stage disagree on four deals, and the disagreements move money: Deal-A5E80A (DS1 discovery) and Deal-499BF6 (DS2) are flagged COMMIT and are being counted at 100 percent ($3,769 combined), while Deal-C61CF7 sits at DS5 contract but is only BEST_CASE and Deal-6787C2 sits at DS4 but is PIPELINE and therefore counts zero. Close dates show heavy placeholder bunching — 17 of 86 deals land exactly on 2026-09-30 and 14 on 2026-10-15 — so the in-quarter/out-of-quarter split, and with it $23,654 of weighted value, hinges on dates that look administratively set rather than deal-driven. Four deals have close dates that already passed before the 2026-09-05 pull and are still open (Deal-333EBB 2026-08-28, Deal-57FF13 2026-09-02, Deal-31AD2C 2026-09-04, Deal-7A2454 2026-09-04), evidence that dates are not being hygienically maintained. Owner is blank on 85 of 86 rows (only Deal-C9C286 has one) and why_buys_chars is 0 on 71 of 86, so there is no way to attribute the number to a rep or verify qualification — this extract should not be run unattended without owner backfill and a stage-to-category validation gate.
ACTIVATION HYPOTHESIS TEST — plg_company_cohort_2023.csv DENOMINATOR Rows in extract: 220. Unique company_key values: 220 (no duplicates). Excluded from the denominator: 0 companies. No row is missing current_status, m1_users, or m1_redemptions, so every company is classifiable. (Blank industry_group / country values exist but are not used by this test.) Status distribution: active 101, cancelled 116, non_renewing 3. Per the stated rule, only current_status = 'active' counts as retained at 24 months, so the 3 non_renewing companies (C-0B2078FB, C-0A96134F, C-0BEAF685) are counted as NOT retained. Overall base rate: 101 / 220 = 45.9%. THE 2x2 (signals defined as m1_users >= 5 and m1_redemptions >= 1) Cell Definition n active 24-mo retention Both signals users>=5 AND redemptions>=1 47 31 31/47 = 66.0% Givers-only users>=5 AND redemptions=0 49 23 23/49 = 46.9% Redemption-only users<5 AND redemptions>=1 29 9 9/29 = 31.0% Neither users<5 AND redemptions=0 95 38 38/95 = 40.0% Total 220 101 101/220 = 45.9% Cell counts reconcile: 47 + 49 + 29 + 95 = 220. Active counts reconcile: 31 + 23 + 9 + 38 = 101. MARGINAL (single-signal) LIFTS m1_users >= 5: 54/96 = 56.3% vs m1_users < 5: 47/124 = 37.9% lift = +18.3pp (56.3 - 37.9) m1_redemptions >= 1: 40/76 = 52.6% vs m1_redemptions = 0: 61/144 = 42.4% lift = +10.3pp (52.6 - 42.4) Largest single-signal lift: m1_users >= 5 (5+ unique givers), at +18.3 percentage points, roughly 1.8x the marginal lift of the redemption signal. INTERACTION — the redemption signal only works on top of giver breadth Among users>=5: with redemption 66.0% vs without 46.9% = +19.1pp Among users<5: with redemption 31.0% vs without 40.0% = -9.0pp So redemption alone is not merely weaker, it is the worst cell in the table (31.0%), below "neither" (40.0%). Redemption activity without giver breadth (a handful of seats redeeming, median m1_users in that cell is low by construction at <5) is associated with worse 24-month retention than no activation signal at all in this extract. WHAT THIS DOES SUPPORT - The directional hypothesis holds for the joint condition: both-signals companies retain at 66.0% vs 40.0% for neither, +26.0pp, and both-signals is the highest of the four cells. - Ordering both (66.0%) > givers-only (46.9%) > neither (40.0%) > redemption-only (31.0%) is consistent within this extract, and each cell has n >= 29 so no cell rests on a handful of accounts. - Giver breadth is the dominant term; redemption behaves as an amplifier conditional on breadth, not as an independent driver. WHAT THIS DOES NOT PROVE - No causation. This is one observational 2x2 with no controls for product_tier, ARR, integrations (has_slack / has_ms_teams / has_hris), industry_group, country, or signup_month. Note the tier confound in the raw data: every cancelled row shows current_arr_usd = 0 and the large majority are tier_two, while nearly all active rows are tier_three, so "tier at signup / current tier" and status are heavily entangled and could be driving the pattern rather than activation behavior. - No statistical significance test was run and I have no basis in this extract for one that accounts for the tier confound; the +26.0pp joint gap is a point estimate with no confidence interval reported here. - Company size is not in the extract. m1_users is a count of active givers, not licensed seats, so "5+ givers" partly proxies for company size, and larger companies plausibly retain better for reasons unrelated to activation. - The retention definition is coarse: current_status = 'active' at extract time, per your instruction that 25+ months of age makes this equal to 24-month retention. There is no dated churn event, so I cannot verify churn timing, distinguish churn at month 3 from month 23, or handle the 3 non_renewing companies as anything other than churned. - Cohort is limited to 2023-01 through 2023-07 signups in this file; nothing here generalizes to later cohorts, other tiers (tier_alpha appears only 3 times), or non-PLG motions. - The thresholds (5 givers, 1 redemption) were given, not fitted or validated here; I did not test whether some other cutoff separates retention better. - The redemption-only result is the least trustworthy line in the table: 29 companies, and the cell includes obvious data oddities such as C-F0A562FF (m1_users = 0 with m1_redemptions = 10) and C-0F58EBD7 (m1_users = 1 with m1_redemptions = 42), which suggest redemptions are not consistently attributable to counted givers.
ARR RECONCILIATION — as of 2026-09-05
Sources: chargebee_subscriptions.csv (39 subscriptions), company_arr.csv (39 company records). Billing ARR = MRR × 12.
1) TOTALS
CRM (HubSpot) ARR total .................. $603,581.76 (39 company records)
Billing ARR total, all subscriptions ..... $617,897.76 (39 subs × MRR × 12)
Variance (CRM − Billing) ................. −$14,316.00
Secondary view, active subscriptions only (37 subs, excludes the 2 cancelled):
Billing ARR, active only ................. $604,739.28
Variance (CRM − Billing active) .......... −$1,157.52
Cross-check: −14,316.00 + 13,158.48 (cancelled ARR: 4,905.24 + 8,253.24) = −1,157.52 ✓
2) VARIANCE DECOMPOSITION (against the all-subscriptions total, sums exactly to −$14,316.00)
Bucket Amount Detail
Missing records −$11,952.00 C-21629AA4 (SUB-0004) in billing, no CRM company row: −$28,449.24
C-0D5BBE3A in CRM, no subscription row: +$16,497.24
Net: −28,449.24 + 16,497.24 = −11,952.00
Rounding +$36.00 C-0D66DF9E: 23,200.00 − 23,184.00 = +16.00
C-14D70CE0: 18,200.00 − 18,180.00 = +20.00
(both CRM values rounded to the nearest $100)
Status mismatch $0.00 C-0C8323BF (SUB-000E, cancelled) CRM ARR 4,905.24 = billing 4,905.24
C-0DC4FB8C (SUB-000F, cancelled) CRM ARR 8,253.24 = billing 8,253.24
Line-level variance is zero because both sides still carry the ARR;
the exposure is $13,158.48 of CRM ARR on cancelled subscriptions
(this is what drives the active-only variance of −1,157.52)
Other −$2,400.00 C-0F7269D7 (SUB-0006): billing 2,233.00 × 12 = 26,796.00 vs CRM 24,396.00
= −2,400.00, i.e. exactly $200/mo × 12. No field in the data explains
the delta — cause is not determinable from the files provided.
TOTAL −$14,316.00 −11,952.00 + 36.00 + 0.00 − 2,400.00 = −14,316.00 ✓
3) MISMATCHED ACCOUNTS WITH SUGGESTED OWNER
No owner/rep field exists in either file, so owners below are suggested by function, not read from data.
Alias Sub Issue Amount Suggested owner
C-21629AA4 SUB-0004 Active sub, no CRM company ARR record $28,449.24 Sales Ops / CRM admin (create + backfill ARR)
C-0D5BBE3A (none) CRM ARR with no billing subscription $16,497.24 Billing Ops (confirm sub exists / churned)
C-0F7269D7 SUB-0006 CRM ARR understated vs billing −$2,400.00 RevOps (root-cause $200/mo delta, then correct)
C-0C8323BF SUB-000E Sub cancelled, CRM still carries ARR $4,905.24 CRM admin (zero ARR / close-lost)
C-0DC4FB8C SUB-000F Sub cancelled, CRM still carries ARR $8,253.24 CRM admin (zero ARR / close-lost)
C-0D66DF9E SUB-0005 CRM rounded up $16.00 Data steward (low priority)
C-14D70CE0 SUB-0008 CRM rounded up $20.00 Data steward (low priority)
All other 32 matched accounts tie exactly (CRM ARR = MRR × 12).
4) BUSINESS-RULE VIOLATIONS — term ≠ 12 months requires cf_agreement_end_date
Violations (2):
SUB-0002 C-1794A52C term 24 months cf_agreement_end_date blank
SUB-0019 C-22170CA1 term 36 months cf_agreement_end_date blank
Compliant non-12-month subs: SUB-000C (C-0DB48281, 24mo, 2027-11-30), SUB-001A (C-0FC4DBB8, 36mo, 2027-11-30).
DATA GAPS
- No account owner / rep field in either file — owners above are functional suggestions only.
- No subscription start date, billing period, or contract value field, so the $2,400.00 "other" delta on C-0F7269D7 cannot be attributed (price change, discount, or stale CRM value are all consistent with the data, and the files do not distinguish them).
- No status field on the CRM side, so the two cancelled-subscription accounts cannot be confirmed as open/closed in HubSpot.
All 30 companies are tier_three (10 smb / 10 mid_market / 10 enterprise), equal-weighted company means, n=30 both months. | KVM | 2026-08 | 2026-07 | Abs Δ | Rel Δ | Direction | |---|---|---|---|---|---| | Giving rate | 0.6027 | 0.6023 | +0.0004 | +0.07% | Flat/up | | Redemptions per user | 1.7302 | 1.7300 | +0.0002 | +0.01% | Flat | | 1:1 meetings engagement | 0.4472 | 0.4469 | +0.0003 | +0.07% | Flat/up | | Pulse check engagement | 0.5086 | 0.6006 | -0.0920 | -15.31% | Down sharply | Largest relative move: pulse check engagement, -15.31% (0.600587 → 0.508610; -0.091977 / 0.600587). Segment driver: enterprise, and the data supports it. Enterprise pulse fell 0.549980 → 0.274280 = -0.275700 (-50.13%). Weighted into the 30-company mean: -0.275700 × 10/30 = -0.091900, i.e. essentially the entire -0.091977 overall decline. smb pulse moved -0.001480 (-0.23%) and mid_market +0.001250 (+0.21%) — immaterial. All 10 enterprise companies dropped, each to the 0.2619–0.2864 band (roughly half of July), a uniform pattern consistent with a measurement or instrumentation break rather than gradual behavior change. Segmentation by plan_tier is not possible: every row is tier_three, so no tier contrast exists. The other three KVMs moved less than 0.4% in any segment. Data not provided: user/company counts for weighting, survey send volumes, and any instrumentation/release history — so the cause of the enterprise pulse drop cannot be confirmed from this file.
REDEMPTION SECTION — YTD through last completed month Last completed month: 2026-08 (August 2026). Reporting date is 2026-09-08, so September is in progress and excluded. The file's latest timestamp is 2026-08-31T11:53:00, and it contains no rows dated after 2026-08, so the reported window is 2026-01-01 through 2026-08-31 (all 378 rows in redemptions_ytd.csv; 378 distinct redemption_id values, no duplicates). Headline metrics (2026-01 → 2026-08) Redemption count ........... 378 Redemption spend ........... $27,846.00 Unique redeemers ........... 235 distinct user_key Redemptions per redeemer ... 1.61 (378 / 235 = 1.6085) Average redemption value ... $73.67 (27,846.00 / 378 = 73.6667) Monthly redemption counts (sums to 378): Jan 45, Feb 36, Mar 50, Apr 52, May 43, Jun 46, Jul 58, Aug 48. 45+36+50+52+43+46+58+48 = 378. Provider mix as percent of spend Provider Redemptions Spend % of spend Avg value custom 37 $10,873.00 39.05% $293.86 Tremendous 192 $8,505.00 30.54% $44.30 Snappy 59 $5,238.00 18.81% $88.78 TangoCard 90 $3,230.00 11.60% $35.89 TOTAL 378 $27,846.00 100.00% $73.67 Arithmetic: 10,873 + 8,505 + 5,238 + 3,230 = 27,846. Shares: 10,873/27,846 = 39.0469% → 39.05; 8,505/27,846 = 30.5430% → 30.54; 5,238/27,846 = 18.8106% → 18.81; 3,230/27,846 = 11.5995% → 11.60. 39.05 + 30.54 + 18.81 + 11.60 = 100.00. Counts: 37 + 192 + 59 + 90 = 378. Note on mix: "custom" is 9.8% of redemption volume (37/378) but 39.05% of spend, driven by its $293.86 average vs. $35.89–$88.78 for the three named providers. Provider names are reproduced exactly as in the file, including the lowercase "custom". Top 5 countries by redemptions Rank Country Redemptions % of redemptions Spend 1 US 244 64.55% $18,547.00 2 CA 24 6.35% $2,286.00 3 AU 21 5.56% $1,606.00 4= GB 17 4.50% $944.00 4= NL 17 4.50% $1,122.00 There is a tie at 17 redemptions between GB and NL, so six ranks' worth of countries cannot be reduced to exactly five without an arbitrary tiebreak; both are shown at rank 4. If a spend tiebreak is preferred, NL ($1,122.00) ranks above GB ($944.00). Remaining countries, excluded from the top 5: SG 12, DE 9, FR 9, CH 9, IN 8, BR 6, NZ 2. Total check: 244+24+21+17+17+12+9+9+9+8+6+2 = 378. Data gaps / caveats (stated, not inferred) - The file is YTD only (earliest row 2026-01-01); no 2025 rows are present, so no prior-year comparison and no trailing-12-month view can be produced from this data. - No currency field beyond amount_usd and no FX or refund/void columns, so all amounts are taken as gross USD; refunded or reversed redemptions cannot be identified. - No user or company dimension tables were provided, so "unique redeemers" is a raw count of distinct user_key values. Each user_key in this file maps to exactly one company_alias (verified: zero user_key values appear under more than one company), but eligible-population data is absent, so a redemption rate (redeemers / eligible users) cannot be calculated. - The request references a weekly report; this file has no week-grain reporting calendar and the metrics above are month-grain cumulative YTD. Weekly cuts are computable from redeemed_at if a week definition is specified.
CHURN-SAVE QUALIFICATION — snapshot 2026-09-05 Rule R3 window: 2026-09-05 + 120 days = 2027-01-03. Renewal must fall on or before that date. All three rules (R1 health_score < 60 AND R2 churn_save_eligible_amount > 0 AND R3 renewal <= 2027-01-03) applied as a conjunction, since eligibility_rules.csv lists no OR logic or weighting. QUALIFYING ACCOUNTS: 8 of 30 alias hs ARR at stake renewal days usage_3m seats used util champ C-0F6C0F34 51 86,741 49,707 2026-10-03 28 growing 308/395 78.0% false C-0E9C27D1 39 75,093 41,235 2026-09-24 19 flat 134/157 85.4% true C-0B360C78 57 60,427 35,748 2026-10-28 53 growing 246/327 75.2% true C-0CEF69FD 53 79,324 32,621 2026-11-21 77 growing 97/136 71.3% false C-0B827671 56 72,088 25,365 2026-11-14 70 declining 113/202 55.9% true C-0D3278C7 54 33,815 17,602 2026-11-12 68 declining 126/380 33.2% true C-0CA21961 58 31,501 16,829 2026-12-28 114 flat 84/325 25.8% true C-0B0F1BAB 38 15,391 5,494 2026-09-23 18 flat 238/363 65.6% false TOTAL AT STAKE 49,707 + 41,235 = 90,942 90,942 + 35,748 = 126,690 126,690 + 32,621 = 159,311 159,311 + 25,365 = 184,676 184,676 + 17,602 = 202,278 202,278 + 16,829 = 219,107 219,107 + 5,494 = 224,601 Total churn-save eligible amount: $224,601 Combined ARR of those 8 accounts: 86,741 + 75,093 + 60,427 + 79,324 + 72,088 + 33,815 + 31,501 + 15,391 = $454,380 At-stake amount = 224,601 / 454,380 = 49.4% of the at-risk ARR it covers. DATA GAP ON PLAY SELECTION eligibility_rules.csv documents eligibility only. There is no documented rule set mapping accounts to usage revival / executive touch / commercial concession. The assignments below are my judgment from the three behavioral fields actually present in churnzero_accounts.csv (usage_trend_3m, seats vs seats_used, champion_active), using this stated logic: champion_active=false -> executive touch (no internal advocate to carry a renewal); champion present but usage declining or utilization under ~56% -> usage revival (adoption is the failure); champion present and utilization high with non-declining usage -> commercial concession (product is being used, so risk is price/budget, not value). Treat this as an analyst recommendation, not a documented policy. EXECUTIVE TOUCH — 3 accounts, $87,822 at stake (49,707 + 32,621 + 5,494) - C-0F6C0F34 — $49,707. Signal: champion_active=false while usage_trend_3m=growing and utilization 308/395 = 78.0%. Product is landing but there is no advocate; largest single amount at stake and renewal in 28 days. - C-0CEF69FD — $32,621. Signal: champion_active=false with usage_trend_3m=growing, 97/136 = 71.3% utilization. Same pattern: value delivered, sponsorship missing. - C-0B0F1BAB — $5,494. Signal: champion_active=false plus the lowest health score in the file (38) and the nearest renewal (2026-09-23, 18 days). Utilization 238/363 = 65.6%, usage flat. Smallest amount at stake, but shortest runway — escalate first on timing, not on value. USAGE REVIVAL — 3 accounts, $59,796 at stake (25,365 + 17,602 + 16,829) - C-0D3278C7 — $17,602. Signal: usage_trend_3m=declining AND the worst utilization in the qualifying set, 126/380 = 33.2%, i.e. 254 unused seats. Champion active, so there is someone to run a re-onboarding push with. - C-0CA21961 — $16,829. Signal: 84/325 = 25.8% utilization, 241 unused seats — lowest utilization of any qualifying account — with usage flat, not declining. Champion active. Latest renewal of the eight (114 days), so the most runway for an adoption program to show movement before the renewal conversation. - C-0B827671 — $25,365. Signal: usage_trend_3m=declining with 113/202 = 55.9% utilization, 89 unused seats. Champion active. Decline plus roughly half the seats idle points at adoption, not price. COMMERCIAL CONCESSION — 2 accounts, $76,983 at stake (41,235 + 35,748) - C-0E9C27D1 — $41,235. Signal: highest utilization in the qualifying set, 134/157 = 85.4% (only 23 unused seats), usage flat (not declining), champion_active=true — yet health_score is 39, the second lowest overall. Adoption is not the problem, so the lever is commercial. - C-0B360C78 — $35,748. Signal: usage_trend_3m=growing with 246/327 = 75.2% utilization and champion_active=true, but health_score 57 and renewal in 53 days. Growing usage plus an active champion argues against a usage play; hold the account with terms. AT RISK BUT NOT QUALIFYING: 7 accounts Fail R2 only (health_score < 60 and renewal inside the 120-day window, but churn_save_eligible_amount = 0.00 — no save budget recorded): - C-0BC71BDD — hs 55, ARR 54,515, renewal 2026-10-27 (52 days), usage flat, 59/197 = 29.9% utilization, no champion. Materially the most concerning non-qualifier: sub-30% utilization, no advocate, renewal under two months, zero eligible amount. - C-0BE96399 — hs 54, ARR 52,319, renewal 2026-10-29 (54 days), usage declining, 43/154 = 27.9% utilization, champion active. - C-10A56B0F — hs 54, ARR 25,717, renewal 2026-12-12 (98 days), usage declining, 85/176 = 48.3% utilization, no champion. Fail R3 only (health and save amount qualify, renewal outside the window): - C-0F876796 — hs 47, $19,958 eligible, renewal 2027-02-06 = 154 days out (34 days past the window). Declining usage, 22/95 = 23.2% utilization, no champion. Will qualify once inside 120 days, around 2026-10-09. - C-0BA71F12 — hs 52, $6,824 eligible, renewal 2027-04-11 = 218 days out. Declining usage, 23/98 = 23.5% utilization, champion active. Qualifies around 2026-12-12. Fail R2 and R3: - C-0F6694C3 — hs 43, amount 0.00, renewal 2027-03-21 = 197 days out. Declining usage, 39/96 = 40.6% utilization. - C-0FCCD2DF — hs 43, amount 0.00, renewal 2027-04-23 = 230 days out. Usage flat, 27/63 = 42.9% utilization. The remaining 15 accounts fail R1 (health_score 62–88) and also carry 0.00 eligible amount, so they are neither at risk nor eligible on the documented rules. OTHER DATA LIMITS - No support-ticket, NPS, sentiment, CSM-note, contract, discount-history, or pricing fields are present, so I cannot validate a concession size or confirm why any health score is low — health_score's inputs are not defined in either file. - Whether churn_save_eligible_amount is a spend cap, a credit ceiling, or forecast ARR at risk is not stated. I have reported it as "amount at stake" exactly as named; if it is a budget cap rather than exposure, the $224,601 total should be read as authorized save spend, not revenue at risk. - The two accounts with a zero eligible amount and a near renewal (C-0BC71BDD, C-0BE96399, plus C-10A56B0F) may be data-entry gaps rather than genuine ineligibility. That is not determinable from the files provided and needs confirmation from whoever populates the field.
EXPANSION KIT — C-0DDFC9A7 SEAT COVERAGE (licensed over headcount) 150 licensed / 400 headcount = 0.375 = 37.5% coverage Uncovered headcount: 400 - 150 = 250 people USAGE HEALTH (two lines) 1. Active users rose every month with no dips: 88 -> 95 -> 102 -> 110 -> 118 -> 126 (Mar-Aug 2026); +38 users = +43.2% (38/88 = 0.4318), averaging 7.6 net new users/month (38/5). 2. License utilization is now 126/150 = 84.0%, leaving only 24 unused seats; at the observed 7.6 users/month pace that runs out in ~3.2 months (24/7.6), i.e. around Dec 2026 — so the seat cap, not adoption, is the near-term constraint. HEADROOM Current per-seat rate (derived): $9,000.00 / 150 seats = $60.00 per seat per year Seat headroom to full headcount: 400 - 150 = 250 seats ARR headroom: 250 x $60.00 = $15,000.00 incremental ARR at full coverage: 400 x $60.00 = $24,000.00 (vs. $9,000.00 today, 2.67x) Near-term floor (cover only current actives + 6 months of trend): 126 + (7.6 x 6) = ~172 seats -> 22 seats over cap -> 22 x $60.00 = $1,320.00 WHO REPLIED / CAN THEY BUY Maria S., People Operations Coordinator, engaged 2026-09-02. No — she states directly that she is "not the right person for purchasing decisions" and that "budget and seat expansion sit with Dana R." She has offered an introduction. RIGHT BUYER Dana R., VP People — named in the reply as the owner of budget and seat expansion. Last engaged 2026-05-18, which is 107 days before Maria's 2026-09-02 reply (13 + 30 + 31 + 31 + 2), so the relationship is dormant and the warm intro is the best path. Maria notes Dana "has been asking about our usage numbers lately," which matches what we can show her. Not the buyer: Sam K., Office Manager, last engaged 2025-11-03 (stale, and no purchasing authority indicated in the data). REPLY EMAIL (124 words) Subject: RE: Growing your team's recognition program Hi Maria, Glad to hear the team loves it — the usage backs you up. Monthly active users went from 88 in March to 126 in August, climbing every single month. An intro to Dana would be very welcome, thank you. Since she's been asking about usage numbers, I can put together a short summary she can read in two minutes: the month-by-month active user trend, where that sits against your 150 licensed seats, and how coverage compares to the wider team. Happy to send it to you first so you can forward it, or to join a 20-minute call with you both — whichever is easier on your side. No urgency on timing. Thanks again for the honest steer. Best, Cole DATA GAPS (stated, not estimated) - No contracted price list or expansion tier pricing; the $60.00/seat rate is derived from $9,000.00 / 150 seats and may not hold at 400 seats. - No renewal or contract end date, so no timing anchor for the expansion. - No seat assignment data (how many of the 150 licensed seats are assigned vs. merely active), and no department/team breakdown. - No confirmation that all 400 headcount are eligible users. - No email address for Dana R. in the files provided.
CSM PREP — C-0D284E42 (mid-onboarding call) Data window: 2026-08-11 (signup) through 2026-09-04 = 24 days elapsed, 25 daily usage rows. COMPLETE (each backed by a populated field) 1. Slack integration — integration_slack = 2026-08-12. Aug 12 − Aug 11 = 1 day after signup. 2. Allowance set — allowance_set = 2026-08-13. Aug 13 − Aug 11 = 2 days after signup. 3. Admins added — admins_added = 2 (count only; no names, roles, or add-dates in the data). 4. First recognition given — first_recognition_at = 2026-08-15 14:22. Aug 15 − Aug 11 = 4 days after signup. NOT COMPLETE (field is empty — treat as not done) 1. HRIS integration — integration_hris is blank. 24 days post-signup with no connection date. The data does not name which HRIS system is intended. 2. First redemption — first_redemption_at is blank. Aug 15 (first recognition) → Sep 4 = 20 days of recognition activity with zero recorded redemption. EARLY ENGAGEMENT SIGNALS (active_givers, arithmetic shown) Weekly totals and daily averages: Wk1 Aug 11–17: 3+3+4+4+5+4+7 = 30 → 30/7 = 4.29/day Wk2 Aug 18–24: 5+7+6+9+8+9+9 = 53 → 53/7 = 7.57/day Wk3 Aug 25–31: 9+11+10+10+11+13+11 = 75 → 75/7 = 10.71/day Wk4 Sep 1–4 (4 days, partial): 13+13+15+15 = 56 → 56/4 = 14.00/day Week-over-week change in daily average: Wk1→Wk2: 7.57/4.29 = 1.77 → +77% Wk2→Wk3: 10.71/7.57 = 1.42 → +42% Wk3→Wk4: 14.00/10.71 = 1.31 → +31% Endpoints: 3 givers (Aug 11) → 15 givers (Sep 3 and Sep 4, the peak) = 5.0x; +12 givers over 24 days = 0.50 givers/day average slope. Total giver-days in window: 30+53+75+56 = 214. Trend is upward but not monotonic — six single-day dips (Aug 16, 18, 20, 22, 27, 31), largest −2 (Aug 17→18: 7→5; Aug 30→31: 13→11). Growth rate is decelerating (+77% → +42% → +31%) while absolute givers still climb. Read: strong, still-accelerating adoption on the giving side, decoupled from any redemption activity. DATA DISCREPANCY TO RESOLVE (do not assume an explanation) onboarding_usage.csv records active_givers ≥ 3 on Aug 11, 12, 13, 14 (3+3+4+4 = 14 giver-days) — all before first_recognition_at = 2026-08-15 14:22. The two files disagree on when giving began. Ask internally which field is authoritative before quoting either on the call. MISSING DATA (cannot be computed from what was provided) - Total employees / licensed seats → no activation or participation rate is calculable; 15 daily givers cannot be expressed as a % of the population. - Recognition volume, recipients, or values → only giver counts exist. - Allowance amount and unspent balance → no redemption-readiness figure. - Named contacts, admin identities, HRIS vendor, plan/contract terms, renewal date. THREE THINGS TO COVER ON THE CALL 1. HRIS integration — the one blocked milestone. integration_hris is blank at day 24 while Slack landed on day 1. Get the specific blocker (vendor, credentials, IT/security owner) and a committed date. Without it, roster sync, new-hire onboarding, and departure deprovisioning stay manual. 2. Zero redemptions after 20 days of recognition — first_redemption_at is blank while giving grew from 3 to 15 daily givers. Ask whether the catalog is live/visible, whether employees know balances are redeemable, and whether anything is gating fulfillment. This is the value-realization step employees actually feel; earned-but-unspendable balances are the main renewal risk visible in this data. 3. Admin coverage and program scale-up — admins_added = 2 against 5x giver growth in 24 days. Confirm 2 admins can support the current load and ask for total headcount/licensed seats so penetration can be measured (currently not calculable). Also flag the file discrepancy above and confirm which start date to use in reporting.
90-DAY RENEWAL RISK BRIEF
Window: 2026-09-08 through 2026-12-07 (today + 90 days). All 20 accounts in the files fall inside it once dates are resolved.
--------------------------------------------------
1. SOURCE-OF-TRUTH DECISION (per account)
--------------------------------------------------
Rule applied: Chargebee (chargebee_terms.csv) is the billing system of record for term length and next renewal date. ChurnZero is known to be wrong on multi-year contracts, so for every account with is_multi_year = true I use cb_renewal_date. For the 15 single-year (term_months = 12) accounts the two systems agree exactly, so the choice is moot.
Disagreements found: 5 of 20. All 5 are the 5 multi-year contracts. Zero disagreements among the 12-month contracts.
alias cz_date cb_date term delta date used why
C-0B7D2C30 2026-09-10 2026-09-15 36mo CZ 5 days early 2026-09-15 multi-year → Chargebee
C-0BCDB8C2 2027-09-18 2026-09-18 36mo CZ +1 year late 2026-09-18 multi-year → Chargebee
C-0D2AB865 2026-09-10 2026-09-22 24mo CZ 12 days early 2026-09-22 multi-year → Chargebee
C-0BBE3E60 2027-09-26 2026-09-26 24mo CZ +1 year late 2026-09-26 multi-year → Chargebee
C-0F5D2323 2026-09-10 2026-09-29 24mo CZ 19 days early 2026-09-29 multi-year → Chargebee
Why this matters operationally, not just cosmetically:
- C-0BCDB8C2 ($54,427) and C-0BBE3E60 ($30,993) are dated 2027 in ChurnZero. Working the ChurnZero list alone drops $85,420 of ARR out of the 90-day book entirely — both actually renew inside the next 3 weeks.
- C-0B7D2C30, C-0D2AB865, C-0F5D2323 all carry the identical ChurnZero date 2026-09-10 (a past date, three accounts, one value) — a signature of a stale/collapsed field, which is further reason to discard it. That is $194,570 of ARR whose true dates are 5–19 days later than ChurnZero shows.
--------------------------------------------------
2. RENEWAL DETAIL (ordered by date used)
--------------------------------------------------
Seat utilization = seats_used / seats. 3-month trend = active_users Jun-2026 → Aug-2026, with the 12-month path shown for context.
Sep 2026
[1] C-0B7D2C30 | CSM Dana Mercer | ARR $65,901 | date used 2026-09-15 (DISAGREEMENT)
Utilization 274/476 = 57.6%
3-mo trend 97 → 94 → 84 = -13 users, -13.4%; 12-mo 155 → 84 = -45.8%
RISK: HIGH — twelve consecutive months of decline with no reversal (-45.8% on the year) against only 57.6% seat utilization.
[2] C-0BCDB8C2 | CSM Cole Ingram | ARR $54,427 | date used 2026-09-18 (DISAGREEMENT — ChurnZero says 2027)
Utilization 232/424 = 54.7%
3-mo trend 127 → 118 → 110 = -17 users, -13.4%; 12-mo 200 → 110 = -45.0%
RISK: HIGH — halved its active base in 12 months and the renewal is 10 days away while ChurnZero shows it a year out, so it likely has no live save motion.
[3] C-0D2AB865 | CSM Elena Sinclair | ARR $38,022 | date used 2026-09-22 (DISAGREEMENT)
Utilization 250/407 = 61.4%
3-mo trend 125 → 117 → 109 = -16 users, -12.8%; 12-mo 199 → 109 = -45.2%
RISK: HIGH — unbroken monthly decline of -45.2% over the year; only 109 of 407 contracted seats are actually active.
[4] C-0BBE3E60 | CSM Dana Mercer | ARR $30,993 | date used 2026-09-26 (DISAGREEMENT — ChurnZero says 2027)
Utilization 74/114 = 64.9%
3-mo trend 39 → 35 → 33 = -6 users, -15.4%; 12-mo 63 → 33 = -47.6%
RISK: HIGH — steepest 12-month decay in the book (-47.6%) and, like C-0BCDB8C2, it is mis-dated a year forward in ChurnZero.
[5] C-0F5D2323 | CSM Cole Ingram | ARR $90,647 | date used 2026-09-29 (DISAGREEMENT)
Utilization 111/390 = 28.5%
3-mo trend 20 → 21 → 18 = -2 users, -10.0%; 12-mo 21 → 18 = -14.3%
RISK: HIGH — largest ARR in the book at the worst utilization (28.5%), with only 18 monthly active users against 390 contracted seats.
Oct 2026
[6] C-0EC6999D | CSM Elena Sinclair | ARR $79,419 | date used 2026-10-03 (systems agree)
Utilization 31/112 = 27.7%
3-mo trend 17 → 16 → 15 = -2 users, -11.8%; 12-mo 15 → 15 = 0.0%
RISK: HIGH — $79,419 supporting 15 monthly active users and 27.7% utilization; usage never grew all year.
[7] C-0B20DB64 | CSM Dana Mercer | ARR $21,770 | date used 2026-10-07 (systems agree)
Utilization 214/378 = 56.6%
3-mo trend 294 → 298 → 294 = 0 users, 0.0%; 12-mo 293 → 294 = +0.3%
RISK: MEDIUM — usage is stable but flat with no expansion, and 43% of purchased seats sit unassigned. (Data note: active_users 294 exceeds seats_used 214 — see §4.)
[8] C-0BBC4E7A | CSM Cole Ingram | ARR $56,374 | date used 2026-10-10 (systems agree)
Utilization 228/337 = 67.7%
3-mo trend 142 → 141 → 139 = -3 users, -2.1%; 12-mo 142 → 139 = -2.1%
RISK: MEDIUM — mild but persistent erosion (-2.1% on the year) with no growth story to justify the renewal.
[9] C-0FD551AB | CSM Elena Sinclair | ARR $48,815 | date used 2026-10-14 (systems agree)
Utilization 210/376 = 55.9%
3-mo trend 123 → 122 → 126 = +3 users, +2.4%; 12-mo 124 → 126 = +1.6%
RISK: MEDIUM — usage is essentially flat and utilization is the second-lowest among the healthy cohort at 55.9%.
[10] C-0F9F8F13 | CSM Dana Mercer | ARR $46,230 | date used 2026-10-18 (systems agree)
Utilization 199/352 = 56.5%
3-mo trend 185 → 185 → 182 = -3 users, -1.6%; 12-mo 182 → 182 = 0.0%
RISK: MEDIUM — zero net growth across 12 months at 56.5% utilization; no evidence of expanding value.
[11] C-0BC34584 | CSM Cole Ingram | ARR $16,740 | date used 2026-10-22 (systems agree)
Utilization 327/494 = 66.2%
3-mo trend 104 → 104 → 106 = +2 users, +1.9%; 12-mo 103 → 106 = +2.9%
RISK: LOW — modest but positive growth and the smallest ARR exposure in the book ($16,740).
[12] C-0B7A7546 | CSM Elena Sinclair | ARR $35,062 | date used 2026-10-25 (systems agree)
Utilization 182/205 = 88.8%
3-mo trend 64 → 65 → 63 = -1 user, -1.6%; 12-mo 58 → 63 = +8.6%
RISK: LOW — highest utilization in the book (88.8%) and +8.6% usage growth on the year.
[13] C-0B369871 | CSM Dana Mercer | ARR $85,128 | date used 2026-10-29 (systems agree)
Utilization 317/422 = 75.1%
3-mo trend 326 → 330 → 333 = +7 users, +2.1%; 12-mo 289 → 333 = +15.2%
RISK: LOW — grew every quarter to +15.2% on the year at 75.1% utilization.
Nov 2026
[14] C-0B144C78 | CSM Cole Ingram | ARR $30,899 | date used 2026-11-02 (systems agree)
Utilization 169/224 = 75.4%
3-mo trend 101 → 101 → 106 = +5 users, +5.0%; 12-mo 90 → 106 = +17.8%
RISK: LOW — +17.8% usage growth on the year and accelerating into the renewal.
[15] C-0FC4DBB8 | CSM Elena Sinclair | ARR $94,732 | date used 2026-11-05 (systems agree)
Utilization 356/464 = 76.7%
3-mo trend 189 → 191 → 193 = +4 users, +2.1%; 12-mo 168 → 193 = +14.9%
RISK: LOW — largest ARR in the book but growing steadily (+14.9%) at 76.7% utilization.
[16] C-0D5BBE3A | CSM Dana Mercer | ARR $39,740 | date used 2026-11-09 (systems agree)
Utilization 85/102 = 83.3%
3-mo trend 88 → 90 → 91 = +3 users, +3.4%; 12-mo 76 → 91 = +19.7%
RISK: LOW — 83.3% utilization plus the strongest 12-month growth in the book (+19.7%).
[17] C-0FB9D5AF | CSM Cole Ingram | ARR $63,158 | date used 2026-11-13 (systems agree)
Utilization 144/199 = 72.4%
3-mo trend 173 → 173 → 176 = +3 users, +1.7%; 12-mo 154 → 176 = +14.3%
RISK: LOW — consistent +14.3% annual growth with healthy 72.4% utilization.
[18] C-0B344485 | CSM Elena Sinclair | ARR $64,384 | date used 2026-11-16 (systems agree)
Utilization 224/287 = 78.0%
3-mo trend 238 → 240 → 244 = +6 users, +2.5%; 12-mo 211 → 244 = +15.6%
RISK: LOW — monotonic growth to +15.6% on the year at 78.0% utilization.
[19] C-0CB2C1B4 | CSM Dana Mercer | ARR $40,628 | date used 2026-11-20 (systems agree)
Utilization 386/473 = 81.6%
3-mo trend 47 → 48 → 49 = +2 users, +4.3%; 12-mo 43 → 49 = +14.0%
RISK: LOW — 81.6% utilization and +14.0% usage growth. (Data note: 386 seats used vs only 49 monthly active users — widest gap in the book; see §4.)
[20] C-22170CA1 | CSM Cole Ingram | ARR $45,646 | date used 2026-11-24 (systems agree)
Utilization 251/294 = 85.4%
3-mo trend 143 → 148 → 146 = +3 users, +2.1%; 12-mo 130 → 146 = +12.3%
RISK: LOW — second-highest utilization (85.4%) with +12.3% growth.
--------------------------------------------------
3. RATING METHOD (so the numbers are auditable)
--------------------------------------------------
HIGH = 3-month active-user decline steeper than -10%, OR seat utilization below 30%.
MEDIUM = flat-to-slightly-negative usage (between -5% and +5% over 3 months) combined with seat utilization below 70%.
LOW = positive 3-month or 12-month usage growth with utilization at or above 66%.
--------------------------------------------------
4. DATA GAPS AND CAVEATS (explicit)
--------------------------------------------------
- seats_used (ChurnZero, provisioned/assigned seats) and active_users (usage_12m) are different metrics and are not reconcilable from these files. In one case active_users exceeds seats_used (C-0B20DB64: 294 active vs 214 seats_used), which is internally impossible if both counted the same population. Utilization above is computed strictly as seats_used/seats as provided; treat it as a licensing figure, not an engagement figure.
- Widest seats_used vs active_users gaps: C-0CB2C1B4 (386 vs 49), C-0BC34584 (327 vs 106), C-0B7D2C30 (274 vs 84). No field in the data explains these gaps.
- usage_12m ends at 2026-08; there is no September 2026 data, so no account's trend includes the current month.
- No renewal-stage, sentiment, support-ticket, NPS, executive-sponsor, or open-opportunity data was provided. Risk ratings rest on exactly two signals: seat utilization and active-user trend. No contract value change, discount, or price-increase data was supplied either, so ARR is assumed flat at renewal.
- chargebee_terms.csv gives term_months but no contract start date, so I cannot independently verify which cb_renewal_date is arithmetically consistent with the term — the multi-year decision rests on the stated rule that ChurnZero is wrong on multi-year, plus the corroborating pattern of the repeated 2026-09-10 value.
- Only 20 accounts appear in these files. If the broader book has accounts absent from churnzero_renewals.csv, they are not represented here.
--------------------------------------------------
5. TOTALS
--------------------------------------------------
Total ARR renewing in the 90-day window (all 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 = $1,048,715
ARR at risk — HIGH only (6 accounts):
65,901 + 54,427 + 38,022 + 30,993 + 90,647 + 79,419 = $359,409 (34.3% of $1,048,715)
ARR on watch — MEDIUM (4 accounts):
21,770 + 56,374 + 48,815 + 46,230 = $173,189 (16.5%)
Combined HIGH + MEDIUM exposure: 359,409 + 173,189 = $532,598 (50.8%)
Secured / LOW risk (10 accounts): 1,048,715 - 532,598 = $516,117 (49.2%)
Timing concentration: all 6 HIGH-risk accounts, $359,409, renew between 2026-09-15 and 2026-10-03 — inside the next 25 days. $274,620 of that (5 accounts) sits in September alone, and 4 of those 5 were mis-dated in ChurnZero.
By CSM (ARR at HIGH risk):
Cole Ingram 90,647 + 54,427 = $145,074
Elena Sinclair 79,419 + 38,022 = $117,441
Dana Mercer 65,901 + 30,993 = $96,894
TICKET THEME SYNTHESIS — 80 tickets, 2026-06-01 to 2026-08-29, 24 distinct accounts, $284,800 total ARR represented
Method note: themes derived from body_text only. Existing tags are unreliable — e.g. IC-460047 ("Recognitions no longer post to Slack") is tagged how-to, IC-460071 (seat-count invoice error) is tagged feedback, IC-460050 (Slack slash command errors) is tagged billing, IC-460020 (points never arrived) is tagged billing. ARR is account-level and constant per account, so theme ARR = sum of distinct account ARR in that theme. No account appears in more than one theme, so the five theme ARRs are non-overlapping and sum exactly to $284,800 (114,000 + 68,800 + 52,000 + 31,100 + 18,900).
RANKED BY ARR EXPOSURE
1. HRIS provisioning failing silently for new hires — BROAD PATTERN
Count 12 | Share 12/80 = 15.0% | Distinct accounts 3 | ARR affected $114,000
Arithmetic: C-0B2213A9 36,000 + C-0DDFC9A7 48,000 + C-0F6C0F34 30,000 = 114,000
Tickets: IC-460059, IC-460060
Three phrasings of one defect: "not creating accounts for new hires" (4), "not being provisioned from our HRIS sync" (5), "skipped 12 new hires; provisioning log shows no errors" (3). All three accounts are the largest non-billing accounts in the book.
Recommendation: treat as a P1 silent-failure bug — instrument the provisioning job to emit per-record errors and alert, then backfill missed hires for all three accounts.
2. Redemption / gift-card checkout failures with points deducted — BROAD PATTERN
Count 18 | Share 18/80 = 22.5% | Distinct accounts 7 | ARR affected $68,800
Arithmetic: 10,300 + 10,700 + 8,900 + 9,600 + 8,700 + 9,600 + 11,000 = 68,800 (C-0B0F1BAB, C-0B827671, C-0CEF69FD, C-0D9CA315, C-0F876796, C-0FCCD2DF, C-14264ABD)
Tickets: IC-460025, IC-460024
Highest-volume theme and the widest mid-market spread; includes 5 tickets where points were deducted despite a failed order — a money-loss variant, not just an error message.
Recommendation: ship idempotent redemption with automatic points reversal on failure, and proactively refund/credit the 5 deducted-but-failed orders.
3. Seat-count and renewal-tier invoicing errors — SINGLE-ACCOUNT NOISE (highest per-account risk)
Count 16 | Share 16/80 = 20.0% | Distinct accounts 1 | ARR affected $52,000
Arithmetic: C-0E9C27D1 52,000 (single account = 20% of all tickets, 18.3% of ARR represented)
Tickets: IC-460069, IC-460078
One account, four repeated complaints: charged 200 seats vs 150 licensed (5), wrong renewal tier price (6), "third invoice in a row with the same error" (3), unapproved seat count (2). Volume here is one unresolved dispute re-filed, not a fleet-wide billing bug — exclude it from product prioritization but escalate commercially.
Recommendation: exec-level billing remediation for C-0E9C27D1 (audit invoices, credit overcharges, freeze auto-renewal at the disputed tier) — this is an active churn risk on the single largest account.
4. Points not posting to balances after recognition — BROAD PATTERN
Count 20 | Share 20/80 = 25.0% | Distinct accounts 9 | ARR affected $31,100
Arithmetic: 2,900 + 2,700 + 4,500 + 4,500 + 3,400 + 3,500 + 4,200 + 2,500 + 2,900 = 31,100 (C-0B2895EF, C-0BE96399, C-0BF20542, C-0D0B047C, C-0D284E42, C-0D3278C7, C-0D6CC8E3, C-0DD0626C, C-21FEBCBB)
Tickets: IC-460004, IC-460016
Largest ticket count and widest account spread (9 accounts) but the lowest ARR of any broad theme — every account here is under $4.5K. Variants: delivered-but-no-points (8), whole-team after the weekend (5), last week's recognition still missing (4), balance not updated since Tuesday (3).
Recommendation: fix the recognition-to-ledger posting lag (the "after the weekend" clustering points at a batch/reconciliation job) and add a self-serve balance-refresh so low-ARR accounts stop generating tickets.
5. Slack integration disconnecting and dropping recognitions — BROAD PATTERN
Count 14 | Share 14/80 = 17.5% | Distinct accounts 4 | ARR affected $18,900
Arithmetic: 4,400 + 3,900 + 5,400 + 5,200 = 18,900 (C-0B843542, C-0BA71F12, C-10A56B0F, C-8C2E8F00)
Tickets: IC-460041, IC-460044
Variants: slash command errors for the whole team (5), sync toggle resets itself (4), stopped syncing to channel (3), app disconnects and re-auth does not stick (2) — consistent with an OAuth token/scope persistence defect.
Recommendation: fix token refresh and toggle persistence, and add a Slack connection-health alert so churn of the integration is detected before users report it.
VOLUME vs ARR — where the ranking diverges
- Points-not-posting is #1 by volume (25.0%) but #4 by ARR ($31,100) across 9 small accounts.
- HRIS provisioning is #4 by volume (15.0%) but #1 by ARR ($114,000) across 3 large accounts. Ranking on ticket count would invert the two most important calls this quarter.
- C-0E9C27D1 alone generates 20% of all tickets. Any volume-based dashboard would read "billing is our biggest product problem"; it is one account's unresolved dispute.
MISSING DATA (stated explicitly, not inferred)
- No status, resolution, or reopen fields — cannot report backlog, resolution rate, or time-to-resolution.
- No first-response or close timestamps beyond created_at — no SLA measurement.
- No renewal dates, contract terms, seat counts, or CSM/owner — cannot quantify churn risk in dollars or attribute accounts to owners.
- No customer sentiment/CSAT and no requester identity — cannot distinguish one loud admin from broad end-user pain within an account.
- ARR is a flat per-account figure; there is no product/SKU breakdown, so "ARR affected" is total account ARR at risk, not revenue attributable to the failing feature.
TOP 3 SOCIAL-PROOF CUSTOMERS (case-study-eligible only) Prospect baseline (prospect.csv): C-82AF3719 — industry=Technology, size_band=Mid-Market, use_case=employee_recognition, region=NA-West Eligibility filter: has_case_study=true. 8 of 25 customers qualify; the other 17 are excluded from consideration entirely and are not named below. Scoring: 1 point per exact field match across the 4 similarity fields (industry, size_band, use_case, region). Max = 4. Rank 1 — C-64171065 : 3/4 industry Technology = Technology ..... 1 size_band Mid-Market = Mid-Market ... 1 use_case employee_recognition = employee_recognition ... 1 region NA-East ≠ NA-West ............ 0 Driving fields: industry, size_band, use_case. Miss: region. Rank 2 — C-A13C193D : 3/4 industry Technology = Technology ..... 1 size_band Mid-Market = Mid-Market ... 1 use_case retention ≠ employee_recognition ... 0 region NA-West = NA-West ............ 1 Driving fields: industry, size_band, region. Miss: use_case. Rank 3 — C-11C31562 : 3/4 industry Manufacturing ≠ Technology .. 0 size_band Mid-Market = Mid-Market ... 1 use_case employee_recognition = employee_recognition ... 1 region NA-West = NA-West ............ 1 Driving fields: size_band, use_case, region. Miss: industry. Tie-break disclosure: all three score 3/4, so ordering is not determined by the data alone. Applied tie-break = weight the fields a recognition buyer evaluates against: industry+use_case fit first (C-64171065), then industry+region fit (C-A13C193D), then use_case+region fit with an industry mismatch (C-11C31562). If your weighting differs (e.g. region-first for reference calls), the order changes; the set of three does not. Next-best, for reference: C-CD4829A7 (2/4 — industry, size_band) and C-9D69D147 (2/4 — size_band, region). No case-study customer matches all four fields — an exact 4/4 analog does not exist in customers.csv. Data gaps stated explicitly: customers.csv and prospect.csv contain no employee counts, ARR, contract, billing, or contact fields, so no such data is used or available here. Similarity is limited to the four categorical fields provided; no headcount, tenure, product-usage, or outcome-metric dimensions exist in the source to refine the tie.
CHANNEL PERFORMANCE — TRAILING 6 MONTHS (2026-03 through 2026-08) Scope: 122 first-touch contact rows, all SQM dates fall between 2026-03-01 and 2026-08-28, so all rows are in the window. Spend = 6 months × monthly rate per channel. 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 webinars $9,000 12 5 $750 $1,800 41.7% $60,000 6.67 paid_social $18,000 0 0 undefined undefined undefined $0 undefined Arithmetic: - paid_search: spend 6,000×6=36,000. cost/SQM 36,000/40=900. cost/SQO 36,000/18=2,000. rate 18/40=0.450. pipeline 18×40,000=720,000. pipeline/$ 720,000/36,000=20.00 - linkedin_ads: spend 4,000×6=24,000. 24,000/25=960. 24,000/8=3,000. 8/25=0.320. 8×12,000=96,000. 96,000/24,000=4.00 - webinars: spend 1,500×6=9,000. 9,000/12=750. 9,000/5=1,800. 5/12=0.4167. 5×12,000=60,000. 60,000/9,000=6.67 - paid_social: spend 3,000×6=18,000, zero rows in contacts_first_touch.csv. Denominator is zero, so cost/SQM, cost/SQO, SQM→SQO rate, and pipeline/$ are all UNDEFINED, not zero. $18,000 (24.5% of the $73,500 total paid budget) has no attributable SQM record. ORGANIC CHANNELS (no spend recorded in channel_spend.csv) channel volume (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.3333, 10×9,000=90,000. referral 6/15=0.400, 6×8,000=48,000. Cost per SQM/SQO and pipeline per dollar are not computable for these two — no spend data provided. TOTALS: 122 SQMs, 47 SQOs (38.5%), $1,014,000 pipeline, $73,500 paid spend. DATA-QUALITY FLAGS SQO date precedes SQM date (2 rows, both linkedin_ads — these are counted as SQOs above): - CT-000044 SQM 2026-07-23, SQO 2026-07-18 (−5 days), $12,000 - CT-000041 SQM 2026-06-14, SQO 2026-06-09 (−5 days), $12,000 If these two are excluded as invalid, linkedin_ads becomes 6 SQOs / 25 SQMs = 24.0%, $72,000 pipeline, cost/SQO $4,000, pipeline/$ 3.00 — materially worse, and it is the only channel with this defect. Other observations, stated as data limits rather than conclusions: - CT-000007 has SQM = SQO = 2026-03-28 (same day, not a precedence violation). - Pipeline amount is a single constant per channel (paid_search $40,000; linkedin_ads and webinars $12,000; organic_search $9,000; referral $8,000). There is no within-channel deal-size variance in this file, so pipeline differences between channels are entirely a function of that constant × SQO count. - paid_social attribution is missing entirely; I cannot tell from this data whether it produced zero SQMs or whether its SQMs are untracked/misattributed. REALLOCATION RECOMMENDATION 1. Freeze paid_social spend pending a tracking audit. It is $18,000 over six months returning zero recorded SQMs. Do not treat this as proven zero performance — it is unmeasurable. Give it one month to fix attribution; if SQMs still do not appear, redeploy the full $3,000/month. 2. Move the paid_social budget to paid_search. paid_search leads on every computable efficiency metric: lowest cost per SQO among the two large paid channels ($2,000 vs $3,000), highest SQM→SQO rate (45.0%), and 5x linkedin_ads on pipeline per dollar (20.00 vs 4.00). At paid_search's observed $900 cost/SQM, $18,000 implies 20 incremental SQMs → at 45.0%, 9 SQOs → at $40,000 each, $360,000 pipeline. That projection assumes efficiency holds at higher spend, which this data cannot test (spend was flat at $6,000/month all six months, so there is no scaling curve here). 3. Do not cut linkedin_ads yet, but put it on notice. It is the weakest computable channel ($3,000/SQO, 32.0% conversion, $4.00 pipeline/$) and it owns both timestamp anomalies. Clean the SQM/SQO stamping first — if the corrected rate is 24.0%, cost/SQO is $4,000 and a cut is justified. 4. Hold webinars. Best cost per SQM ($750) and cost per SQO ($1,800) in the set on only $9,000 of spend; its low pipeline/$ ($6.67) is driven by the $12,000 constant deal value, not by inefficiency. It is a candidate for a modest test increase, not a cut. 5. Protect the organic channels operationally. organic_search (30 SQMs, 33.3%, $90,000) and referral (15 SQMs, 40.0%, $48,000) produce $138,000 of pipeline — 13.6% of total — with no spend in this file. Any organic cost that exists is not captured here, so their true efficiency is unknown but bounded below by "better than any paid channel per recorded dollar." CONFIDENCE: MEDIUM-LOW overall. - paid_search: medium. 40 SQMs / 18 SQOs is the largest cell here and the direction of the ranking is unlikely to flip, but 18 conversions still carries wide interval — a swing of 3 SQOs moves the rate from 37.5% to 52.5%. - linkedin_ads: low. 8 SQOs, and 2 of the 8 are timestamp-corrupt, so a quarter of its wins are unverified. - webinars: low. 12 SQMs / 5 SQOs is too thin to act on aggressively; one deal changes the rate by 8.3 points. - paid_social: no confidence — undefined, not measured. - organic: low-medium on rates (10 and 6 SQOs), and no cost basis at all. - Structural caveat: constant pipeline values per channel and flat monthly spend mean this dataset supports ranking channels by efficiency but does not support forecasting how efficiency behaves as budget shifts. Re-run after one month of corrected paid_social tracking and real per-deal amounts before committing to a larger reallocation.
BATTLECARD: RIVALLY — updated 2026-09-08 Sources: competitor_snippets.csv (S01–S25), deals_with_competitor.csv, existing_battlecard.md Excluded from facts by rule: S09 (AE opinion, Bryce Harmon — "UI clunky"), S21 (AE opinion, Elena Sinclair — "discounting aggressively"). Logged as rep sentiment only, not competitor facts. 1) ONE-LINE POSITIONING Points-based recognition feed [S02, S16] that deploys fast in mid-market with out-of-the-box Slack [S04], now pushing EU-first differentiation via generally available EU data residency [S15] and multi-language support for distributed EU teams [S12]. 2) PRICING (source + date; newer source wins) Current list: $7 per user/month, annual billing required — pricing page, 2026-08-12 [S17]. USE THIS. Superseded: $5 per user/month, annual billing — pricing page 2026-01-20 [S03] and pricing page 2026-04-01 [S08]. CONFLICT NOTED: three pricing-page readings disagree. $5 [S03, 2026-01-20] → $5 [S08, 2026-04-01] → $7 [S17, 2026-08-12]. Newer source wins, so list is $7. Arithmetic on the change: 7 − 5 = 2; 2 / 5 = 0.40 = +40% list increase between 2026-04-01 [S08] and 2026-08-12 [S17]. Field-quoted prices (deal mentions, not pricing pages): - $6.50/user/mo, 500-seat prospect, annual term — 2026-06-02 [S13]. This is above the $5 page live at that time [S08] and below the later $7 page [S17]; unresolved conflict, both cited. - $7/user/mo list with 15% discount offered for a 3-year term — 2026-08-14 [S18]. Effective: 7 × (1 − 0.15) = 7 × 0.85 = $5.95/user/mo. Discount value per user per year: (7 − 5.95) × 12 = 1.05 × 12 = $12.60. - Pulse engagement survey is priced as a paid add-on, not bundled [S23, S06]. No add-on dollar figure in the data — MISSING. MISSING: no enterprise/higher-tier price point, no per-seat floors/minimums, no EU vs US price differences in the data. 3) WHERE THEY WIN - EU data residency: pitched competitively in-deal [S05], now generally available with a Dublin office [S15]; EU leadership added (ex-Workday VP EMEA) [S11]. - Distributed EU teams and multi-language support, praised by an EU enterprise reviewer [S12]. - Fast time-to-value: mid-market setup under a week, Slack integration worked out of the box [S04]. - Support responsiveness: under 4 hours [S22]. - Engagement surface: recognition feed called engaging/praised [S02, S16]. - Microsoft Teams app v2 in public preview [S19] (preview, not GA per the snippet). - Capital to spend: $40M Series C led by Northgate Ventures [S01]. 4) WHERE WE WIN - Analytics depth. An 800-seat prospect picked Bonusly over Rivally citing analytics depth [S25]. Corroborated weakness: limited analytics [S02], basic reporting dashboards vs enterprise tools [S07], analytics exports CSV-only which made migration off Rivally hard [S20]. - Enterprise provisioning: Rivally lacks SCIM; manual user management called painful by an enterprise reviewer [S10]. - Admin tooling: admin tooling lags peers [S16]; admin console still lacks bulk recognition editing [S24]. - EMEA rewards catalog is thinner than the US catalog [S14] — use this against their EU pitch [S05, S15]. - Cost trajectory: list moved $5 → $7 (+40%) between 2026-04-01 and 2026-08-12 [S08, S17]; annual billing is mandatory [S17], and the deeper discount required a 3-year term [S18]. - Surveys cost extra: Pulse is an add-on, not bundled [S23, S06]. 5) OBJECTIONS AND RESPONSES - "Rivally is cheaper — $5/user." Their own pricing page now lists $7/user/mo annual as of 2026-08-12 [S17]; the $5 figure is a 2026-01/2026-04 page [S03, S08]. Ask which quote date they're holding. - "They'll discount to win." What's documented is $7 list with 15% off only for a 3-year commitment = $5.95 effective [S18], plus a $6.50 quote at 500 seats [S13]. Frame as a 3-year lock, not a price win. (Note: the "discounting aggressively" read is rep opinion [S21], not a fact — don't assert it.) - "We need EU data residency." Acknowledge: it's GA and they have a Dublin office [S15]. Counter on what EU buyers actually consume — their EMEA rewards catalog is thinner than US [S14]. - "Their recognition feed looks better." Feed is genuinely praised [S02, S16]. Move the evaluation to analytics and admin: limited analytics [S02], basic dashboards [S07], CSV-only exports [S20], no SCIM [S10], no bulk recognition editing [S24]. - "They integrate with Slack, do you?" Do not claim they lack Slack — Slack worked out of the box for a mid-market reviewer [S04]. The old card's claim is wrong (see §7). Teams is v2 public preview only [S19]. - "They just raised, they're safer." $40M Series C, 2025-11-04 [S01]. No data on runway, headcount, or churn — MISSING; don't speculate. - "Migration risk if we leave you." Their exit path is documented as hard: analytics exports are CSV-only [S20]. 6) RECENT CHANGES (last ~6 months, newest first) - 2026-09-03: 800-seat prospect chose Bonusly over Rivally on analytics depth [S25]. - 2026-09-02: admin console still lacks bulk recognition editing [S24]. - 2026-09-01: Rivally Pulse exits beta, priced as an add-on, not bundled [S23]. - 2026-08-25: reviewer reports migration off Rivally hard, analytics exports CSV-only [S20]. - 2026-08-20: Microsoft Teams app v2 enters public preview [S19]. - 2026-08-12: pricing page updated to $7/user/month, annual billing required [S17]. - 2026-07-01: Dublin office opens; EU data residency generally available [S15]. - 2026-06-14: EMEA rewards catalog thinner than US [S14]. - 2026-05-09: hires ex-Workday VP EMEA to lead European expansion [S11]. - 2026-03-05: launches Rivally Pulse engagement survey add-on [S06]. 7) OLD-CARD ITEMS: RE-SOURCED, CORRECTED, OR UNVERIFIED - "Points-based recognition for mid-market" — RE-SOURCED. Points-based recognition feed [S02]; mid-market deployment reference [S04]. - "$5 per user/month, annual billing (as of 2026-01)" — SUPERSEDED. Accurate for 2026-01-20 [S03] but current page is $7 [S17]. - "Rivally lacks a Slack integration" — CONTRADICTED BY EVIDENCE. Slack integration worked out of the box, 2026-02-02 [S04]. Remove; do not use in calls. - "Rivally was acquired by WorkHuman in 2025" — UNVERIFIED. No snippet supports it. The only 2025 corporate event in the data is a $40M Series C led by Northgate Ventures on 2025-11-04 [S01], which is not an acquisition. Treat as unverified until sourced. - "Strong in EU enterprise with multi-language support" — RE-SOURCED [S12], reinforced by [S15, S11]. 8) OUR 12-MONTH WIN/LOSS RECORD VS RIVALLY Window: 2025-09 through 2026-08 (all 20 rows in deals_with_competitor.csv fall inside it; all rows have competitor = Rivally). Totals: 13 wins, 7 losses, 20 deals. Win rate = 13 / 20 = 0.65 = 65%. Loss rate = 7 / 20 = 35%. Wins (13): Deal-A9FD43, Deal-7AA785, Deal-44C524, Deal-0D0CD6, Deal-D5B790, Deal-5C636E, Deal-67BE14, Deal-1B6969, Deal-F03E7B, Deal-072E31, Deal-F65C8F, Deal-E46EAB, Deal-1D2392. Losses (7): Deal-7767F5, Deal-5645A5, Deal-C6FFAA, Deal-D263E0, Deal-935746, Deal-9066A6, Deal-72A02F. By month (W-L): 2025-09 1-1 (Deal-072E31 W; Deal-7767F5 L) 2025-10 2-0 (Deal-A9FD43, Deal-F65C8F) 2025-11 1-1 (Deal-7AA785 W; Deal-D263E0 L) 2025-12 1-1 (Deal-44C524 W; Deal-935746 L) 2026-01 2-0 (Deal-0D0CD6, Deal-E46EAB) 2026-02 2-0 (Deal-D5B790, Deal-1D2392) 2026-03 1-1 (Deal-5C636E W; Deal-9066A6 L) 2026-04 0-2 (Deal-5645A5, Deal-72A02F) 2026-05 0-1 (Deal-C6FFAA) 2026-06 1-0 (Deal-67BE14) 2026-07 1-0 (Deal-1B6969) 2026-08 1-0 (Deal-F03E7B) Check: 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; 13+7 = 20 ✓ Half-over-half: first 6 months (2025-09 → 2026-02) = 9 W / 3 L = 9/12 = 75%. Second 6 months (2026-03 → 2026-08) = 4 W / 4 L = 4/8 = 50%. Change = 50% − 75% = −25 percentage points. CAUTION: the file contains no loss reasons, no deal sizes/ARR, no segment or region fields, so the H1→H2 decline cannot be attributed to any cause from this data. The only sourced competitive win reason available is analytics depth on a single 800-seat deal [S25], and that deal is dated 2026-09-03 and is not in deals_with_competitor.csv. MISSING DATA (explicit) - No WorkHuman acquisition evidence anywhere in the snippets. - No deal amounts, segments, regions, or loss reasons in deals_with_competitor.csv. - No Rivally enterprise-tier pricing, no Pulse add-on price, no seat minimums. - No security/compliance certifications (SOC 2, ISO) for Rivally. - No data on Rivally headcount, churn, or customer count. - Teams app is public preview only [S19]; no GA date in the data.
SEQUENCE PERFORMANCE (rates = per sends, summed across steps 1-3) New Logo Nurture — sent 1,386 (500+458+428); opens 490 = 35.4%; replies 90 = 6.49%; meetings 27 = 1.95%. Weakest step: step 3 (18/428 = 4.21% reply; 6/428 = 1.40% meeting). Expansion Nurture — sent 875 (300+300+275); opens 565 = 64.6%; replies 59 = 6.74%; meetings 12 = 1.37%. Weakest step: step 3 (12/275 = 4.36% reply; 3/275 = 1.09% meeting). Cold Outbound - HR Leaders — sent 1,785 (600+595+590); opens 545 = 30.5%; replies 8 = 0.45%; meetings 0 = 0.00%. Weakest step: step 3 (1/590 = 0.17% reply). Cold Outbound - People Ops — sent 1,163 (400+386+377); opens 340 = 29.2%; replies 29 = 2.49%; meetings 6 = 0.52%. Weakest step: step 3 (6/377 = 1.59% reply). TRACKING ERRORS Expansion Nurture step 2: opened 340 > sent 300 (113.3%) — impossible. Steps 1 and 3 of that sequence run 43.3% and 34.5%, so step 2 is inflated by roughly 210-215 opens (image-proxy/prefetch or duplicate open events). Every Expansion Nurture open figure is unreliable until reconciled; its reply and meeting counts are internally consistent (25 replies < 300 sent) and are the only usable signal there. AUDIENCE OVERLAP audiences.csv holds 963 rows, 940 unique contact_keys — 23 contacts enrolled in two sequences. 21 in both Cold Outbound - HR Leaders and Cold Outbound - People Ops: 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. 2 in both Expansion Nurture and New Logo Nurture: CT-000301, CT-000624. Note: the file's 963 rows cannot be mapped to the 1,800 step-1 sends; true overlap may be larger. No email, title, or account fields provided, so overlap cause is not determinable. SUB-2% REPLY FAILURE MODE HR Leaders (0.45%) and People Ops (2.49% total, but 1.59% at step 3): opens are normal (30.5%, 29.2%) while replies collapse — subject lines work, bodies don't. HR Leaders converts 2.1% of opens to replies at step 1 vs 20.0% for New Logo Nurture step 1: a ~10x relevance gap, plus double-tapping 21 shared contacts. ONE CHANGE PER WEAK SEQUENCE Cold Outbound - HR Leaders: rewrite the step-1 body around one HR-leader-specific problem with a single yes/no ask; cut steps 2-3 until reply rate clears 2%. Cold Outbound - People Ops: dedupe the 21 shared contacts to one sequence before sending again. Expansion Nurture: fix step-2 open tracking (dedupe open events / disable proxy counting). New Logo Nurture: replace step 3 with a different ask; it produces 4.21% reply on 428 sends. FIX FIRST Cold Outbound - HR Leaders. It consumes 1,785 sends — the largest volume of any sequence — and returns 0 meetings. Reallocating those sends at People Ops' 0.52% meeting rate would yield ~9 meetings.
WEEKLY MARKETING GOALS UPDATE — Q3-2026 (2026-07-01 to 2026-09-30) Timing basis: 66 of 92 days elapsed = 71.7% of quarter gone; 26 days remain. Pace method: pro-rated target = target x 66/92 (applied to accumulating metrics only). SQMs QTD actual: 230 Target: 300 (higher better) Delta to full-quarter target: -70 (76.7% attained; 230/300) Pro-rated target: 300 x 66/92 = 215.2 -> delta +14.8 (+6.9%) Pace: AHEAD. Run-rate 230/66 = 3.48/day -> 3.48 x 92 = 320.6 projected. To finish: 70 needed / 26 days = 2.69/day (below current 3.48/day). SQOs QTD actual: 84 Target: 120 (higher better) Delta to full-quarter target: -36 (70.0% attained; 84/120) Pro-rated target: 120 x 66/92 = 86.1 -> delta -2.1 (-2.4%) Pace: BEHIND, marginally. Run-rate 84/66 = 1.27/day -> 117.1 projected. To finish: 36 / 26 = 1.38/day (a 9% lift over current 1.27/day). DS2s QTD actual: 40 Target: 75 (higher better) Delta to full-quarter target: -35 (53.3% attained; 40/75) Pro-rated target: 75 x 66/92 = 53.8 -> delta -13.8 (-25.7%) Pace: BEHIND. Run-rate 40/66 = 0.606/day -> 55.8 projected (74% of target). To finish: 35 / 26 = 1.35/day, a 2.2x lift over current 0.606/day. Closed-lost MIA rate QTD actual: 5 MIA / 25 closed-lost total = 0.200 (20.0%) Target: 0.10 (lower better) Delta: +10.0 percentage points, i.e. 2.0x the ceiling Pace: BEHIND (rate metric — not pro-rated; measured as-of-today). Recovery arithmetic: with 5 MIA already booked, hitting 10% requires total closed-lost >= 50 (5/50 = 0.10) with zero additional MIA losses — i.e. loss volume would have to double cleanly. Not realistically recoverable in Q3. Same-quarter closes QTD actual: 10 Target: 20 (higher better) Delta to full-quarter target: -10 (50.0% attained) Pro-rated target: 20 x 66/92 = 14.3 -> delta -4.3 (-30.3%) Pace: BEHIND. Run-rate 10/66 = 0.152/day -> 13.9 projected (70% of target). To finish: 10 / 26 = 0.385/day, a 2.5x lift over current pace. Active pipeline coverage against target QTD actual: $3,000,000 Target: $4,000,000 Coverage: 3,000,000 / 4,000,000 = 75.0% -> gap -$1,000,000 Pace: BEHIND on coverage. Note: active pipeline is a point-in-time balance, so the primary read is the 75% coverage figure. For reference only, against a pro-rated build ($4,000,000 x 66/92 = $2,869,565) the balance is +$130,435. Funnel conversion implied by the QTD numbers SQM -> SQO: 84/230 = 36.5% SQO -> DS2: 40/84 = 47.6% DS2 -> same-quarter close: 10/40 = 25.0% WHAT MOVED THIS WEEK Data missing: the files provided contain only quarter-to-date cumulative totals (marketing_qtd.csv) with no prior-week or weekly snapshot, and no dated event records, so no week-over-week movement can be calculated — I cannot state what moved this week without inventing it. What the QTD position does support: top of funnel is the only healthy line, with SQMs running 6.9% ahead of pro-rated pace and projecting 320.6 against a 300 target, while every downstream stage is short — SQOs are essentially at pace (-2.4%) but DS2s sit 25.7% behind pro-rata and same-quarter closes 30.3% behind, which localizes the problem at SQO -> DS2 (47.6% conversion) and DS2 -> close rather than at demand generation. The closed-lost MIA rate at 20.0% is double the 10% ceiling and is arithmetically locked out of recovery this quarter, and active pipeline at $3.0M leaves a $1.0M coverage gap with 26 days left. To close the quarter on plan, DS2s need a 2.2x step-up in daily rate and same-quarter closes a 2.5x step-up; SQMs need no intervention. To report actual weekly movement next cycle, a prior-week snapshot of the same seven metrics (or dated SQM/SQO/DS2/close records) is required.
Q3 weighted forecast is 115,976.75: 44,729 COMMIT plus 35% of 203,565 BEST_CASE (71,247.75). Treat it as unverified: why-buys are empty on all 7 in-quarter COMMIT deals (71 of 86 overall) and owner is blank on 85 of 86, so no rep or quota rollup exists. Also 32 deals worth 227,575 close after 9/30, including COMMIT Deal-D348E1 at 13,770 dated 2026-10-15; require documented why-buys and owners before committing this number.
Subject: Pricing for 150 seats — next step? Hi [VP People], Following up on the recap I sent August 5 with pricing for 150 seats after our July 28 demo. I know this time of year gets busy. Since birthdays and anniversaries are tracked manually today, the automated milestone awards your team reacted well to in the demo are likely the fastest place to see relief. Would you be open to a 20-minute call this week to walk through the 150-seat pricing against your recognition budget? Best, Alex Franklin --- Notes: 84 words. Prior touch referenced = ENG-00001 (Aug 5 pricing recap). Recipient name not in the data, so left as a bracketed placeholder rather than invented; Deal-0D2F7A has no inbound replies after ENG-00005, so tone is matched to the outbound-only thread.
Week of 2026-08-31 — GTM Digest Marketing We finished the week with 46 SQMs against a 52 target — 6 short, or 88.5% attainment (46 ÷ 52 = 0.885). Webinars carried the load, contributing 18 of the 46 SQMs, which is 39.1% of the week's total (18 ÷ 46 = 0.391). Paid search cost per SQM held steady at $150, so the spend discipline is holding even as volume ran light. The extract doesn't give a prior-week SQM figure or channel-level targets, so we can't say whether the gap is a trend or a one-week dip. Sales Fourteen SQOs converted and 9 DS2 meetings got set, with $310,000 in new pipeline created. That works out to an average of $22,143 of new pipeline per SQO ($310,000 ÷ 14 = $22,142.86). Three deals closed in-quarter this week, equal to 21.4% of the SQOs worked (3 ÷ 14 = 0.214). DS2 meetings landed at 0.64 per SQO (9 ÷ 14). No quota, target, or prior-week baseline is provided for any Sales metric, so these are absolute results, not attainment. Customer Success CS saved 2 renewals this week and team NPS moved to 61 — a genuinely strong score, though the extract doesn't include the previous NPS value, so we can't quantify the change. Three red-flag accounts remain open heading into next week, which is the number to watch: with only 2 saves logged this week, the open red-flag count exceeds the weekly save rate by 1. No renewal-at-risk dollar values or account aliases are included in the extract, so we can't size the exposure. Product-Led Growth PLG added 412 new signups at 31% activation, which implies roughly 128 activated users (412 × 0.31 = 127.7). Thirty-eight companies hit the aha moment of 10 recognition gives — that's 9.2% of the week's signups reaching real recognition habit-forming behavior (38 ÷ 412 = 0.092). Worth noting that signups are counted as users and aha is counted as companies, so those two figures aren't a clean funnel ratio; the extract doesn't give a company-level signup count to make it one. No activation target or prior-week comparison is provided. Data gaps this week: prior-period baselines for every team, targets for Sales/CS/PLG, and any dollar values tied to renewals or red-flag accounts.
PARTNER DIGEST — period 2026-08-24 to 2026-09-04 (per #partners Slack export range) Partner-sourced pipeline total: 5 deals / $550,000 Arithmetic: Apex ($180,000 + $95,000 = $275,000) + HRCloud ($140,000) + CultureBridge ($60,000 + $75,000 = $135,000) = $275,000 + $140,000 + $135,000 = $550,000. Deal count: 2 + 1 + 2 = 5. All 5 rows in partner_deals.csv carry utm_source = Partner. ACTIVE PARTNERS Apex Rewards Co — 2 sourced opps, $275,000 - Deal-DDAAF2 $180,000; Deal-2CF33E $95,000 (sum: 180,000 + 95,000 = $275,000) - Both in DS1 per Dana Mercer (2026-08-25); Cole Ingram confirmed both logged with UTM Source = Partner - Co-webinar locked for 09-15 - Slack opp count (2) matches deal rows (2) HRCloud Partners — 1 sourced opp, $140,000 - Deal-F1CDA5 $140,000 - Integration referral cleared security review; opp moved to DS2 per Alex Franklin (2026-08-27) - Slack opp count (1) matches deal rows (1) CultureBridge — 2 sourced opps, $135,000 - Deal-096E1D $60,000; Deal-067213 $75,000 (sum: 60,000 + 75,000 = $135,000) - Sourced from lunch-and-learn, both early stage per Farid Osman (2026-08-29) - Slack opp count (2) matches deal rows (2) WorkWell Group — 0 sourced opps, $0 - No sourced deals this period; no rows in partner_deals.csv - Wants to restart the joint playbook in Q4; planning call booked for 09-09 per Dana Mercer (2026-09-02) QUIET PARTNERS Recogniq — quiet; no Slack activity and no deals in the data provided this period. KudosWave — quiet; no Slack activity and no deals in the data provided this period. PeopleFirst Advisors — quiet; no Slack activity and no deals in the data provided this period. TotalPerk — quiet; no Slack activity and no deals in the data provided this period. Data gaps: no stage data for Deal-096E1D or Deal-067213 beyond "early stage"; no close dates, owners, or stage fields anywhere in partner_deals.csv; no data of any kind on 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? 90 days after contract end, then deleted from production systems. Retention period = contract duration + 90 days; measured from termination, that is 0 + 90 = 90 days. [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.0 single sign-on is supported, along with SCIM user provisioning. Both are 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 from the excerpts provided. The excerpts reference only a SOC 2 Type II report [P2] and make no statement about ISO 27001 — absence of mention is not evidence either way. Required document: the Bonusly certifications/compliance page on the trust portal, or an ISO 27001 certificate and Statement of Applicability from the certifying body. Q9 — What is your contractual uptime SLA percentage? Unanswerable from the excerpts provided. No excerpt states an availability or uptime commitment. Required document: the Master Services Agreement or its Service Level Agreement exhibit. Q10 — Will you sign a HIPAA Business Associate Agreement? Unanswerable from the excerpts provided. No excerpt addresses HIPAA or BAA execution. Required document: Bonusly's legal agreements set (DPA and BAA templates) or a statement of position from Legal. Coverage: 7 of 10 items answered from the excerpts (Q1–Q7); 3 unanswerable (Q8–Q10). Excerpts [P7] (72-hour confirmed-incident notification) and [P8] (RBAC plus MFA for production access) were not required by any questionnaire item.
RECONCILIATION: 14 skill files vs skill_manifest.csv (14 rows). Assessed 2026-09-08.
════════════════════════════════════════════
(1) ALWAYS-TRIGGER OVERLAP / DUPLICATION
════════════════════════════════════════════
1A. comms-drafter <-> email-drafter
SEVERITY: CRITICAL ACTION: MERGE (into comms-drafter)
Verbatim trigger phrases present in BOTH descriptions:
"write me an email" · "draft a follow-up" · "what should I say" · "bump email" · "contract nudge"
Arithmetic: 5 exact collisions out of comms-drafter's 8 listed phrases (5/8 = 62.5%) and out of email-drafter's 10 listed phrases (5/10 = 50.0%). A 6th is a near-duplicate: "help me reply" (comms-drafter) vs "help me reply to this" (email-drafter).
Duplication extends past triggers: both claim the same scope list (outbound prospecting, follow-ups, post-demo recaps, pricing follow-up, contract follow-up, end-of-quarter push, renewal/expansion, QBR follow-up, check-in, onboarding), both carry the identical contract-follow-up benchmark quote ("Thanks for the update. This is really helpful..."), both carry the identical Recommended / Softer / Firmer response format, both carry the identical 1-10 review protocol, and both carry the same lane marker pointing to deal-strategy-coach.
PROPOSAL: Merge email-drafter into comms-drafter. comms-drafter is the superset (it also owns Intercom/support, partner/channel, rewards vendor). Port email-drafter's two unique assets into comms-drafter before deletion: (a) the Gmail signature extraction procedure (search_threads in:sent -> get_thread FULL_CONTENT -> line-by-line signature capture), (b) the "no markdown in email body copy" rule. Then delete email-drafter and repoint every inbound reference to comms-drafter. Note dependency: this merge collides with finding (2) below, so break the cycle first.
1B. weekly-pipeline-report <-> pipeline-intelligence-report
SEVERITY: WARNING ACTION: TRIM_DESC (weekly-pipeline-report)
3 trigger collisions, both descriptions using ALWAYS:
"pipeline update" (PIR) vs "run the pipeline update" / "update the pipeline" (weekly)
"run the pipeline report" (PIR) vs "generate the pipeline report" / "do the pipeline report" (weekly)
"what's the pipeline look like" (PIR) vs "what does pipeline look like" (weekly)
Both also assert primacy: PIR says "Master pipeline scoring skill, never answer pipeline questions inline without running it"; weekly says ALWAYS on the same generic phrasings.
PROPOSAL: Trim weekly-pipeline-report's description to Demand-Gen-scoped triggers only ("weekly pipeline report", "pipeline summary", "this week's numbers", SQM/SQO/DS2 metrics, bookings MTD) and strip the four generic pipeline phrasings that belong to PIR. Do not trim PIR: it already carries the master-skill claim and the disambiguation contract that next-to-close depends on.
1C. Four unconditional always-on gates
SEVERITY: INFO ACTION: REVIEW
model-selection ("ALWAYS run this skill at the start of every task, without exception"), analysis-validator ("Always. No exceptions."), signalforge-claim-compressor ("final style pass before any SignalForge report"), signalforge-feedback ("absolute final step"). The ordering exists only inside two of the four: claim-compressor documents "data pull -> analysis -> analysis-validator -> claim-compressor -> output" and feedback documents "after analysis-validator and after signalforge-claim-compressor". model-selection and analysis-validator declare unconditional position without referencing the chain.
PROPOSAL: Review and publish the gate order in one place (front position: model-selection; terminal positions: validator -> compressor -> feedback), then have each of the four cite it rather than each asserting position independently.
1D. sales-forecast <-> pipeline-intelligence-report
SEVERITY: INFO ACTION: REVIEW
sales-forecast triggers on "pipeline forecast", "how are we tracking this quarter", "what's our number". PIR adds "Also trigger when Alaina or any VP asks for pipeline health or forecast context." A VP asking for forecast context satisfies both ALWAYS clauses with no tie-break.
PROPOSAL: Review; add one disambiguation line to PIR ("forecast category context only; route current-quarter revenue outlook to sales-forecast"), matching the pattern next-to-close already uses successfully against PIR.
════════════════════════════════════════════
(2) CIRCULAR DELEGATION CHAIN
════════════════════════════════════════════
SEVERITY: CRITICAL ACTION: UPDATE_BODY
Named cycle: email-drafter -> deal-strategy-coach -> email-drafter (2-node)
Evidence, both directions explicit:
email-drafter, description + Lane marker: "For deal strategy, diagnosis, or coaching (not email drafting), use deal-strategy-coach instead" / "point them to the deal-strategy-coach skill".
deal-strategy-coach, Manager-to-prospect email frameworks: "When drafting manager-to-prospect emails, use the `email-drafter` skill which automatically retrieves your Gmail signature".
A manager-email request satisfies both entry conditions, so each skill's stated response is to hand off to the other.
Adjacent risk: comms-drafter -> deal-strategy-coach is currently one-way (deal-strategy-coach points to email-drafter, not comms-drafter). If finding 1A's MERGE lands without this fix, the cycle survives the merge as comms-drafter <-> deal-strategy-coach.
PROPOSAL: UPDATE_BODY on deal-strategy-coach only. Keep the drafting handoff outbound (strategy -> drafting) and delete the return pointer in email-drafter/comms-drafter, replacing it with a terminal instruction ("draft here; recommend deal-strategy-coach as a next step, do not hand off"). Sequence: fix this before executing the merge.
Non-cycle, for the record: pipeline-intelligence-report Phase 2b -> closed-lost-analysis Mode 4 is a true one-way delegation. closed-lost-analysis Mode 4's "called from pipeline-intelligence-report" is an inbound-caller note, not a return delegation. Mutual reference, no cycle. SEVERITY: INFO, ACTION: REVIEW (make the asymmetry explicit so it is not later "fixed" into a cycle).
════════════════════════════════════════════
(3) DANGLING DELEGATION TARGETS
════════════════════════════════════════════
15 distinct delegation targets are named in skill bodies with no manifest row and no file in the set.
CRITICAL (named as a blocking prerequisite or a canonical-truth source):
bonusly-brand <- comms-drafter ("Step 0 - Brand First (Always). Before drafting any communication, apply the `bonusly-brand` skill"), email-drafter, sales-forecast, signalforge-claim-compressor. A hard Step 0 dependency on a nonexistent skill.
prospect-research-multithreading <- comms-drafter, email-drafter, deal-strategy-coach (Cross-skill handoff). Gates the "never guess at an email address, never misspell a name" rule.
bonusly-data-questions <- analysis-validator G1-J ("The canonical real user filter from `bonusly-data-questions` must be present"). Gate 1 depends on it.
ACTION: REVIEW (create, or rewrite the dependent step to be self-contained). One proposal: inline the required content (brand voice rules, contact-lookup procedure, active_human_users CTE) into the dependents, since each is already partially duplicated there.
WARNING (referenced as routing or cascade targets):
skill-orchestrator <- analysis-validator §11 step 3, signalforge-feedback Activation Checklist
signalforge-reports <- pipeline-intelligence-report Phase 5 (mandatory pre-build read), weekly-pipeline-report Step 4. Path-based org skill (/mnt/skills/organization/...); may exist outside this manifest's scope, unverifiable from provided data.
7 remaining bonusly-* specialists in analysis-validator §12.4: bonusly-product-questions, bonusly-business-reporting-questions, bonusly-rewards-questions, bonusly-ppp-questions, bonusly-feature-flag-questions, bonusly-deal-desk-questions, bonusly-datadog-questions
3 cascade docs in analysis-validator §11: CUSTOMER_DATA_REFERENCE, HUBSPOT_CONNECTOR_REFERENCE, SIGNALFORGE_PRODUCT_INSIGHT_SKILL
ACTION: REVIEW. One proposal: resolve each name to either an existing org/user skill outside this manifest or a stub, and delete the rest from §12.4 and §11 rather than leaving unresolvable delegation targets in a mandatory gate.
DATA MISSING: the manifest schema is file, declared_name, description_chars, body_lines. It carries no row for supporting files, so the references/*.md and references/*.html targets cited by sales-forecast (5 files), weekly-pipeline-report (2 files), and pipeline-intelligence-report (references/html-spec.md, marked deprecated) cannot be reconciled from the data provided. Stated, not assumed.
════════════════════════════════════════════
(4) VERSION CONFLICT
════════════════════════════════════════════
SEVERITY: WARNING ACTION: UPDATE_BODY
SURVIVOR: analysis-validator v3.6
Conflict inside analysis-validator:
Header: "**Version:** 3.6", "Last Updated: May 9, 2026 (v3.6 - G2-F: ID Resolution)"; changelog top row 3.6.
Section 7 Validation Trail template: "Validator: analysis-validator v3.2".
Cross-check: pipeline-intelligence-report's footer emits "SignalForge Validated · Analysis Validator v3.6", so the consuming skill already expects 3.6. v3.6 survives; the v3.2 string in the trail template is stale and is stamped onto every published report.
Same-conflict internal range drift (v3.6 added checks that older prose ranges still exclude):
Full Mode: "Gate 1: All Data Correctness checks (G1-A through G1-H)" but the gate defines G1-A through G1-L (H, I, J, K, L missing from the range).
Full Mode and Section 6 decision tree: "Gate 2 (G2-A through G2-E)" but the gate defines G2-A through G2-F (G2-F, the v3.6 headline addition, is excluded from the run range).
G1-J: prose says "all five conditions required" and the CTE lists 5, the check table lists 6 rows, and the trail line says "all 6 canonical filters present?". 5 vs 6.
Changelog integrity: versions 3.0, 3.1, 3.2, 3.3, 3.4, 3.5, 3.6 are all dated May 9, 2026 (7 releases, 1 date), so precedence cannot be established from dates alone, only from the header. "Created: April 26, 2026" also predates changelog row 1.0 "Prior".
PROPOSAL: UPDATE_BODY on analysis-validator only. Set the trail template to v3.6, extend the two gate ranges to G1-A..G1-L and G2-A..G2-F, resolve G1-J to a single count (6, including _FIVETRAN_DELETED), and replace the 7 identical changelog dates with real sequencing. No competing file exists, so nothing is deleted.
Second-order version drift, separate proposals:
sales-forecast v1.1 claims "Quarter-agnostic (Q2 -> current quarter throughout)" but Tab 6 is still titled "Q2 Narrative" in the locked 6-tab table. SEVERITY: WARNING, ACTION: UPDATE_BODY (rename to "Q[N] Narrative").
pipeline-intelligence-report v6 declares references/html-spec.md "deprecated as of May 2026" while still listing it under Reference Files. SEVERITY: INFO, ACTION: UPDATE_BODY (delete the row).
stale-pipeline-report changelog dates v1.0 and v1.1 both 2026-06-10. SEVERITY: INFO, ACTION: REVIEW.
════════════════════════════════════════════
(5) MANIFEST DESCRIPTIONS OVER 1,024 CHARS
════════════════════════════════════════════
SEVERITY: INFO ACTION: REVIEW
Count: 0 of 14.
Arithmetic against the 1,024 ceiling, taking description_chars as declared in the manifest:
pipeline-intelligence-report 1006 -> 1024 - 1006 = 18 headroom
signalforge-claim-compressor 1006 -> 18 headroom
partner-digest 1004 -> 20 headroom
comms-drafter 996 -> 28
email-drafter 965 -> 59
sales-forecast 962 -> 62
next-to-close 945 -> 79
closed-lost-analysis 897 -> 127
deal-strategy-coach 792 -> 232
stale-pipeline-report 762 -> 262
signalforge-feedback 708 -> 316
model-selection 676 -> 348
analysis-validator 656 -> 368
weekly-pipeline-report 656 -> 368
Max = 1006. Over-ceiling rows = 0. Three rows sit within 20 chars of the ceiling (1006, 1006, 1004).
PROPOSAL: No action required for compliance. Review the three near-ceiling rows before any description edit; 18 to 20 chars of headroom means a single added trigger phrase breaches the cap. Note the assumption: description_chars is taken as declared in the manifest and was not independently recounted from the files.
════════════════════════════════════════════
(6) HARDCODED PAGE IDS, DATES, PERSON NAMES
════════════════════════════════════════════
Present in 13 of 14 files (all except signalforge-claim-compressor). Grouped by the risk each poses today, 2026-09-08.
6A. Time-expired hardcoding
SEVERITY: CRITICAL ACTION: UPDATE_BODY
model-selection: "last_checked: 2026-05-19" against its own rule "If today's date is more than 14 days past the last_checked date below, run the self-update procedure before making any recommendations." May 19 -> Sep 8 = 31 + 30 + 31 + 20 = 112 days. 112 / 14 = 8.0x past its own staleness threshold, on a skill that declares itself a mandatory first gate for every task. Also hardcoded: 3 model IDs, per-MTok prices, context windows, "Opus 4.6 deprecation announced April 14, 2026".
weekly-pipeline-report: Step 0 hardcodes "business days complete in Q2 (April 1 - June 30, 2026; total = 64-65)" and Q1 2026 static actuals ($365,152 vs $475,000 plan = 76.9%; $2,490,532 vs $3,288,000 = 75.7%). Q2 2026 closed before this run date.
sales-forecast: "Q2 Narrative" tab and Q2-shaped examples inside a skill that instructs "always use the active quarter, not Q2".
PROPOSAL: Replace all three with computed-at-runtime windows and, for model-selection, gate execution on the self-update procedure instead of on a literal date string.
6B. Conflicting hardcoded person rosters
SEVERITY: WARNING ACTION: UPDATE_BODY
analysis-validator §12.3 "GTM Team Roster (Updated May 4, 2026)" names 6 AEs as "the Core 6" with owner IDs (Bryce Harmon 119337721, Hugo Lindqvist 77260721, Dana Mercer 83155923, Alex Franklin 84342457, Cole Ingram 83155924, Gavin Porter 1520255671) and states "Any 'full AE team' or 'Core 6' filter must include all six IDs."
pipeline-intelligence-report Phase 1 hardcodes "AE owner IDs (verified May 2026)" with 5 IDs: Bryce Harmon, Dana Mercer, Cole Ingram, Alex Franklin, Gavin Porter. 6 - 5 = 1 missing (Hugo Lindqvist, 77260721).
Two skills, two hardcoded rosters, direct conflict on a filter the validator declares mandatory. stale-pipeline-report already solved this correctly ("Never hardcode rep names or owner IDs. The AE roster changes." Phase 2 resolves owners dynamically) and also hardcodes an exclusion ID (Bonusly Support 55483190).
PROPOSAL: Adopt stale-pipeline-report's dynamic owner resolution in analysis-validator §12.3 and PIR Phase 1; keep the roster tables as display-name fallback only, not as filter truth.
6C. Hardcoded page/space/channel/sheet IDs
SEVERITY: WARNING ACTION: REVIEW
partner-digest: cloudId 73fe98de-a4a3-4869-9f8a-bb1eeed4cf7f, spaceId 1958248479, folder 2286616609, and 6 page IDs (2286321666, 2265382925, 2236940297, 2237825028, 2239365136, 2238283777); Slack user ID U03QLMBL7AR; anchor-date examples May 19 2026 and June 2 2026.
signalforge-feedback: page 2295136266, spaceId 2232811524, parent 2234417154, Build Log 2247295002, same cloudId.
sales-forecast: spaceId 2232811524, parent 2232582148, same cloudId.
deal-strategy-coach: AE Excellence Playbook page 2257879045 ("April 2026").
weekly-pipeline-report: Google Sheet IDs 1CLZeOsElVDF_LF0ZG_t2nfwvhnZ6bpwqM_nX3WEYzcw (targets) and 1ENuaEcCuLjdKhMvp8FK3Ys1ek5Aw9ZuOZhsHJJFoB_k (bookings forecast).
stale-pipeline-report: Slack #revops-team C0561C1JCPJ.
pipeline-intelligence-report, next-to-close, stale-pipeline-report: HubSpot org 1973303 in deal URL patterns.
Deal stage IDs 150582536 / 150582537 / 150582538 / 150582539 / 1175632767 appear in 5 files (analysis-validator §12.2, PIR, next-to-close, stale-pipeline-report, weekly-pipeline-report). next-to-close both defers to PIR ("do not redefine, just reuse") and redefines them inline.
PROPOSAL: Review; promote the shared constants (stage IDs, HubSpot org ID, cloudId, space IDs) to one referenced constants block and have each skill cite it, so a stage-ID change is a one-file edit rather than a five-file edit.
6D. Hardcoded person names in operational instructions
SEVERITY: WARNING ACTION: REVIEW
analysis-validator: "Escalate to Finance (Manish or Amani)" appears twice (G1-K HOLD output format and §10); §12.3 names 19 individuals.
deal-strategy-coach: ICP routing "India (routed to Perseus)" and ".edu domains ... routed to Farid for manual qualification".
weekly-pipeline-report: titled to a named owner, "Ben Lavin · Demand Generation".
sales-forecast: "Alaina / VP Sales" in-body, plus changelog "Elena -> Alaina" showing this name has already churned once.
partner-digest: "Owner: Amani Phipps" plus partner-side first names Kelli, Jen Lee, Hani, Bryce, Sara.
PROPOSAL: Review; replace individuals in routing and escalation logic with roles (Finance owner, India routing owner, .edu qualification owner, Demand Gen owner) and keep names in one roster only.
6E. Hardcoded figures, pricing, and named accounts
SEVERITY: WARNING ACTION: UPDATE_BODY
analysis-validator: population anchors ~452,000 provisioned and ~110,097 dormant; expected ranges 3,000-3,500 customers, 440,000-470,000 users, 850-1,100 Gong calls 90d, 150-350 open deals, all labeled "as of May 2026, will drift over time"; table-staleness dates "March 28, 2023", "May 4, 2026" (x3).
deal-strategy-coach: full 2026 price book, 8 tiers x 4 columns, including floor prices; DS0-DS5 probabilities; HBR "5.6:1" ratio; "200+ Gong calls and 370+ resolved deals".
closed-lost-analysis: 10 named lost accounts (Softheon, Estee Lauder, LIFTOFF, Nestle, Ozinga, MinIO, Aurora Innovation, GCash, Ethos Cannabis, StickerYou) and hardcoded rates 17%, 8%, 14%+ inside the interventions table, all dated to a "May 2026" sample.
PROPOSAL: The skill already states the correct pattern for its own anchors ("Do not use hardcoded figures ... run this query block to get current anchors"). Apply it consistently: keep anchors as calibration-only with an explicit re-verify instruction, and move the price book and loss-rate percentages behind a dated "verify before quoting" gate, which deal-strategy-coach already does for comps but not for the table itself.
════════════════════════════════════════════
(7) MANIFEST DRIFT, BOTH DIRECTIONS
════════════════════════════════════════════
SEVERITY: INFO ACTION: REVIEW
No drift in either direction.
Arithmetic: manifest rows = 14. Files supplied = 14. Matched pairs = 14.
Files with no manifest row: 14 - 14 = 0.
Manifest rows with no file: 14 - 14 = 0.
Rows where declared_name != file: 0 of 14 (every row's declared_name equals its file value, and each equals the frontmatter `name` in the corresponding SKILL.md).
One cosmetic note, not drift: manifest `file` values omit the ".SKILL.md" suffix carried by the actual filenames (e.g. row "analysis-validator" vs file "analysis-validator.SKILL.md"). Consistent across all 14, so it is a convention, not a mismatch.
PROPOSAL: No corrective action. Review only: the manifest tracks no frontmatter version column, so pipeline-intelligence-report's `version: v6 · May 2026` and analysis-validator's in-body v3.6 are invisible to the manifest and cannot be reconciled by it. Adding a version column would make finding (4) detectable at manifest level instead of requiring a body read.
════════════════════════════════════════════
ALSO SURFACED (outside the 7 requested checks, no proposal attached)
════════════════════════════════════════════
- analysis-validator G1-J canonical CTE contains an unresolved placeholder, `u.email not like '[email]'`, in both the SQL block and the check table. As written it filters nothing, and the same skill's G2-D check treats "[placeholder]" in output as a Gate 2 failure.
- closed-lost-analysis states "In the 30-deal AI-field sample from May 2026: 10 of 10 deals had at least one Bonusly-side contributor." Denominator conflict: 30-deal sample vs 10 of 10 reported.
- partner-digest instructs the skill to edit itself mid-run ("Update the active partner list in this skill in the same session"), which no other skill in the set does.
RUNBOOK — reward-worker queue depth saturation Source: incident_thread.md, #incident-2026-08-29-reward-queue (resolved) Every step below traces to a message ID. Nothing is included that the thread does not state. TRIGGER PagerDuty alert: reward-worker queue depth > 10k [M01] TIMELINE ARITHMETIC (from thread timestamps/values only) - Total incident span: 14:02:10Z → 14:55:00Z = 52 min 50 s [M01→M10] - Alert → enqueue paused: 14:02:10 → 14:08:45 = 6 min 35 s [M01→M04] - Severity vs normal: 48,213 ÷ 500 = 96.4x the stated normal ceiling [M02] - Observed drain: 48,213 − 9,400 = 38,813 jobs over 14:04:33 → 14:33:41 = 29 min 8 s → 38,813 ÷ 29.13 min ≈ 1,332 jobs/min average [M02→M07] - Remaining at 14:33:41 at the reported ~1,200/min: 9,400 ÷ 1,200 ≈ 7.8 min projected to zero; zero was confirmed at 14:47:55, i.e. 14 min 14 s later [M07→M08] - Dead set: 112 jobs, all Redis::TimeoutError originating ~13:58 [M03] STEPS S1 — Acknowledge alert and establish incident command [M01] Who: Bryce Harmon Action: acknowledged the PagerDuty alert, took IC role Verification: none stated in thread State changed: no (no rollback required) S2 — Measure queue depth [M02] Who: Farid Osman Command: bundle exec rake sidekiq:queue_depth Result: reward queue = 48,213 pending; stated normal < 500 Verification: the command output is the measurement State changed: no (read-only, no rollback) S3 — Inspect dead set [M03] Who: Farid Osman Action: examined Sidekiq dead set — 112 jobs, all Redis::TimeoutError from ~13:58 Command: NOT STATED IN THREAD — NEEDS CONFIRMATION Verification: none beyond the reported counts State changed: no (read-only, no rollback) S4 — Pause enqueue to stop the bleed [M04] Who: Farid Osman Command: bin/rails runner 'FeatureFlag.disable(:auto_recognition_enqueue)' Verification: NOT STATED at time of execution — NEEDS CONFIRMATION. The thread's only subsequent evidence is the falling queue depth at 14:33:41 [M07], which the thread does not explicitly attribute to this step. State changed: YES Rollback: bin/rails runner 'FeatureFlag.enable(:auto_recognition_enqueue)' [M04, executed later as S9] S5 — Clear the dead set [M05] — NEEDS CONFIRMATION (multiple gaps) Who: Elena Sinclair Action as described: "While I was in the console I cleared out the dead set." Command: NOT STATED IN THREAD — NEEDS CONFIRMATION Verification: none stated State changed: YES — 112 jobs [M03] were destroyed Rollback: NONE PRESENT IN THREAD. No re-enqueue, export, or backup of the 112 dead jobs is mentioned anywhere. Treat as irreversible unless confirmed otherwise. Note: the thread contains no message requesting or approving this action, and no message stating the console/host used. S6 — Scale workers up [M06] Who: Bryce Harmon Command: kubectl scale deployment/reward-worker --replicas=6 (previous value: 3) Verification: queue depth falling — 9,400 and dropping ~1,200/min at 14:33:41 [M07] State changed: YES Rollback: kubectl scale deployment/reward-worker --replicas=3 [M06, executed later as S10] S7 — Monitor drain rate [M07] Who: Farid Osman Result reported: queue depth 9,400, falling ~1,200/min Command: NOT STATED IN THREAD — NEEDS CONFIRMATION (thread does not say whether the S2 rake task or another source produced this figure) State changed: no (read-only, no rollback) S8 — Confirm queue fully drained and errors at baseline [M08] Who: Cole Ingram Command: bundle exec rake sidekiq:queue_depth → returns 0 Additional check: error rate in Datadog back to baseline Verification: the two checks above are the verification Detail gap: the specific Datadog dashboard/monitor and the baseline value are NOT STATED — NEEDS CONFIRMATION State changed: no (read-only, no rollback) S9 — Re-enable enqueue [M09] Who: Bryce Harmon Command: bin/rails runner 'FeatureFlag.enable(:auto_recognition_enqueue)' Verification: 40 new jobs processed cleanly in the following 3 minutes Detail gap: how the 40 jobs were observed (tool/dashboard/command) is NOT STATED — NEEDS CONFIRMATION State changed: YES Rollback: bin/rails runner 'FeatureFlag.disable(:auto_recognition_enqueue)' [command form from M04] S10 — Scale workers back to baseline [M10] Who: Bryce Harmon Command: kubectl scale deployment/reward-worker --replicas=3 Verification: queue stable at 0; incident declared resolved State changed: YES Rollback: kubectl scale deployment/reward-worker --replicas=6 [command form from M06] STATE-CHANGING STEPS, ORDERED, WITH REVERSE ORDER FOR BACKOUT Forward: S4 (disable flag) → S5 (clear dead set) → S6 (scale to 6) → S9 (re-enable flag) → S10 (scale to 3) Reverse from any point: S10 → scale to 6; S9 → disable flag; S6 → scale to 3; S5 → NO ROLLBACK AVAILABLE IN THREAD; S4 → enable flag MISSING FROM THE THREAD (cannot be filled from provided data) - Root cause: the thread records Redis::TimeoutError starting ~13:58 [M03] but contains no diagnosis, no Redis-side inspection, and no remediation of Redis itself. The incident was resolved by pausing enqueue and adding capacity only. - No exact command for: dead-set inspection [M03], dead-set clearing [M05], drain-rate measurement [M07], the 40-job post-enable check [M09]. - No verification step recorded for S1, S4, or S5. - No recovery path for the 112 destroyed dead-set jobs [M05]. - No follow-up/action items, no severity classification, and no customer-impact statement appear anywhere in the thread.
FAILURE SEQUENCE — 2026-09-03 (all times UTC, as given) FIRST ERROR 2026-09-03T14:01:12Z | reward-service | ERROR "Redis::TimeoutError: Connection to Redis at redis-primary:6379 timed out after 5s" This is the first non-INFO line in the slice. Everything before it (13:55:13Z–13:59:30Z) is INFO: health checks, cache hits, job enqueued. SERVICE AND JOB INVOLVED - Originating service: reward-service (dependency named in the error: redis-primary:6379) - Job: RewardGiveJob (named in reward-service retry-exhaustion lines and in every sidekiq ERROR line) - Also failing per sidekiq_jobs.csv but absent from the log slice: RecognitionDigestJob CASCADE, IN ORDER 1. 14:01:12Z reward-service — Redis::TimeoutError, connection to redis-primary:6379 timed out after 5s 2. 14:01:20Z / 14:01:30Z / 14:01:40Z reward-service — "retry exhausted for RewardGiveJob" (3 lines) 3. 14:01:40Z sidekiq — RewardGiveJob failed: Redis::TimeoutError; retrying in 60s (first sidekiq-level failure, same second as the third retry-exhausted line) 4. 14:02:28Z sidekiq — RewardGiveJob failed; retrying 5. 14:02:30Z sidekiq — WARN "Queue reward depth above 10,000" (queue backup) 6. 14:03:05Z api-gateway — 502 upstream timeout calling reward-service /gives (first edge-layer failure) 7. 14:03:30Z web-app — "Give form submission failed: upstream 502 from api-gateway" (first user-facing failure) 8. 14:03:31Z–14:06:52Z — steady-state failure loop across three layers: 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 give-form failures (14:04:45, 14:05:42, 14:06:49) 9. 14:22:10Z reward-service — INFO "Redis connection restored; resuming job processing" 10. 14:24:45Z sidekiq — INFO "Queue reward depth below 500" (drained) Direction of propagation: redis-primary → reward-service → sidekiq (job layer) and api-gateway (sync layer) → web-app. ARITHMETIC - First error → first api-gateway 502: 14:03:05 − 14:01:12 = 1m53s (113s) - First error → first user-facing web-app error: 14:03:30 − 14:01:12 = 2m18s (138s) - First error → queue depth alarm: 14:02:30 − 14:01:12 = 1m18s (78s) - First error → Redis restored: 14:22:10 − 14:01:12 = 20m58s (1,258s) - First error → queue drained: 14:24:45 − 14:01:12 = 23m33s (1,413s) - Visible failure loop (last error line 14:06:52 − first 14:01:12) = 5m40s; gap from 14:06:52 to 14:22:10 = 15m18s with no reward-service/sidekiq/api-gateway/web-app entries - ERROR lines in slice = 19: reward-service 4 + sidekiq 6 + api-gateway 5 + web-app 4. Plus 1 sidekiq WARN. - sidekiq_jobs.csv: 16 failed jobs = 12 RewardGiveJob (J-00001…J-00012) + 4 RecognitionDigestJob (J-00013…J-00016); 16/16 error = Redis::TimeoutError (100%) - Job failure window: earliest failed_at 14:01:46 (J-00005) → latest 14:05:50 (J-00016) = 4m04s. Earliest job failure is 34s after the first log error (14:01:46 − 14:01:12). DATADOG QUERY TO CONFIRM THE FIRST ERROR Logs Explorer, sorted timestamp ascending, time range 2026-09-03T13:55:00Z → 2026-09-03T14:02:00Z: service:reward-service status:error "Redis::TimeoutError" "redis-primary:6379" Narrower/looser variants against the same window: - Confirm nothing earlier exists at all: service:reward-service -status:info - Confirm origin vs. downstream: service:(reward-service OR sidekiq OR api-gateway OR web-app) status:error — ascending; the earliest row should be the reward-service line at 14:01:12Z - Check the dependency itself: service:redis OR host:redis-primary (this returns nothing in the provided slice — see below) WHAT THE LOGS DO NOT SHOW - No root cause for the Redis timeout. There are zero redis-primary / redis service log lines in the slice, and no Redis metrics (memory, evictions, connection count, CPU, failover events). "Timed out after 5s" is the symptom only. - No remediation event. Nothing between 14:06:52Z and 14:22:10Z explains how Redis was restored — no restart, failover, deploy, config change, scaling, or human action is logged. - Blind window 14:06:52Z → 14:22:10Z contains only postgres INFO checkpoints. The slice cannot confirm whether 502s and job failures continued during those 15m18s or stopped. - RecognitionDigestJob does not appear anywhere in datadog_logs.csv, yet 4 of its jobs failed (J-00013…J-00016). Blast radius beyond RewardGiveJob is visible only in sidekiq_jobs.csv. - No job_id in the log lines, so log ERROR entries cannot be joined to specific rows in sidekiq_jobs.csv. - No retry outcome per job. sidekiq_jobs.csv has failed_at only — no succeeded_at, retry_count, or dead-set flag, so whether the 16 jobs eventually completed after 14:22:10Z is unknown. - No denominators. No request counts, throughput, or success counts, so error rate, failed-give volume, and affected-user count cannot be calculated. - No customer/business dimension: no account, tenant, user, or company aliases, no give amounts or points/dollar values. Revenue or customer-impact sizing is not possible from this data. - Queue depth is only bounded, not measured: ">10,000" at 14:02:30Z and "<500" at 14:24:45Z. Peak depth and drain curve are unknown. - Whether postgres was affected is not shown; its only lines are INFO "checkpoint complete" (14:10:56Z–14:20:59Z) with no errors, but there are also no postgres lines during 14:01–14:06. - No trace IDs, no hosts/pods, no region/AZ, and no alert/pager records, so the query above cannot be tied to a specific instance or to whether anyone was paged.
FEATURE FLAG STATE SUMMARY — 9 flags in export, 6 with code references FLAGS ON (5 flags, 421 company-slots) recognition_streaks_v2 | on | segment:beta_companies | 42 companies Controls: in app/models/recognition.rb, gates StreakTracker.record(give) — streak tracking on each give. Off = gives recorded without streak tracking. points_budget_guardrails | on | all_companies | 220 companies Controls: in app/services/budget_service.rb, gates BudgetService.new(company).enforce!(giver, points) — enforcement of point budget limits per giver. Broadest target in the export; 220 of 456 total company-slots (48.2%). slack_dm_nudges | on | segment:region_na | 87 companies Controls: in app/jobs/nudge_job.rb, a guard clause (`return unless`) on SlackDm.send_nudge(user) — the entire nudge job aborts when disabled. analytics_dashboard_v3 | on | segment:tier_three | 65 companies Controls: in app/controllers/analytics_controller.rb, gates @dashboard = AnalyticsV3.new(company). No else branch in the excerpt, so @dashboard is left unset when disabled — the excerpt does not show what renders in that case. survey_boosters_q3 | on | segment:legacy_plan | 7 companies Controls: NO CODE REFERENCE in the excerpt. What this flag gates cannot be determined from the data provided. FLAGS OFF (4 flags, 35 company-slots) redeem_flow_redesign | off | targeted_list | 12 companies Controls: in app/controllers/redeem_controller.rb, switches RedeemV2Component vs RedeemV1Component. Only flag in the excerpt with an explicit fallback branch. State is off, so all 12 targeted companies currently render V1. ms_teams_app_v2 | off | targeted_list | 9 companies Controls: in app/services/teams_installer.rb, gates TeamsAppV2.install(company). State off — no installs occurring for the 9 targeted companies. legacy_give_modal | off | segment:legacy_plan | 14 companies Controls: NO CODE REFERENCE in the excerpt. Cannot determine behavior from the data provided. paused_offboard_cleanup | off | (targeting_rules field empty) | 0 companies NO CODE REFERENCE and NO TARGETS. Off, empty targeting rules, zero companies — inert on every dimension available in the export. FLAGS WITH NO CODE REFERENCE (3) survey_boosters_q3, legacy_give_modal, paused_offboard_cleanup — present in flags_export.csv but absent from flag_code.md. Note the excerpt is scoped to app/ and lib/; usage outside those paths would not appear, so "no reference" here means no reference in the provided excerpt, not proven dead. FLAGS WITH NO TARGETS (1) paused_offboard_cleanup — company_count 0, targeting_rules blank. ARITHMETIC — export reconciliation On: 42 + 220 + 87 + 65 + 7 = 421 Off: 12 + 9 + 14 + 0 = 35 Total: 421 + 35 = 456 company-slots across 9 flags Step-by-step full sum: 42+220=262; +87=349; +12=361; +65=426; +9=435; +14=449; +7=456; +0=456 ✓ Targeting-rule breakdown segment: 5 flags (beta_companies 42, region_na 87, tier_three 65, legacy_plan 14, legacy_plan 7) all_companies: 1 flag (220) targeted_list: 2 flags (12, 9) empty: 1 flag (0) DATA GAPS / DISCREPANCIES 1. segment:legacy_plan carries two different company counts — 14 for legacy_give_modal, 7 for survey_boosters_q3. The export does not explain why one segment yields different counts; no segment-membership file was provided to reconcile this. 2. 35 company-slots sit on flags in state=off with non-zero targets (12 + 9 + 14). Targeting is configured but the flag state gates it, so per the code pattern FeatureFlags.enabled? returns false and no targeted company receives the behavior. The export does not indicate whether state=off overrides targeting or the two combine some other way. 3. "company_count" is per-flag; companies may overlap across flags. 456 is a sum of slots, not a distinct company count. No company-ID data was provided, so distinct company totals cannot be derived. 4. No flag in flag_code.md is absent from the export — all 6 code-referenced flags appear in the export.
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, Delaware law, 2-year term with 3-year survival, and no embedded non-solicit or non-compete — nothing outside standard terms, so signature authority can approve. 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: Otherwise standard (mutual, 3-year term, standard carve-outs, Delaware law), but the embedded non-solicit extends 18 months past term and covers "or hire," not just solicit — a hiring restriction on Bonusly that needs counsel to scope or strike, not full legal review. NDA-3 — [PARTY C] — RED Driving clauses (three, any one sufficient): - Non-compete: "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." - Carve-outs: "No confidentiality carve-outs are stated in this Agreement." - Governing law: "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 [PARTY C]'s favor with a 5-year term, a 3-year operating non-compete on Bonusly, zero carve-outs (so even public or independently developed information is captured), and foreign law with exclusive foreign jurisdiction — each is a full legal review trigger on its own. Missing data noted: the file gives no party identities, no deal or company aliases, no contract value, no counterparty type (customer, partner, vendor), and no defined "Confidential Information" scope or return/destruction, remedies, or assignment clauses. Classifications above rest only on the clauses quoted.