Mean 0.906 · 29/40 perfect tests · $1.73 total · each card: the question → the correct answer (gold) → this model's actual answer
Definitions - DS2+ population: deals whose `stage` is DS2, DS3, DS4, or DS5. DS1 deals are excluded from the why-buys rule. - Substantive why-buys: `why_buys` is non-empty, is not a placeholder (tbd / n/a / see notes / etc.), and is ≥15 chars. A value of form LONG(n) counts as present and substantive. In this file the only non-empty why_buys values are LONG(n) — 23 of them — so every other DS2+ deal has a blank field and is non-compliant. - No DS1 timestamp: `t_ds1` blank. - Regressed: among populated t_ds1..t_ds5, any earlier-stage timestamp strictly later than a later-stage timestamp (all pairs checked). Populations - Total deals: 156. By stage: DS1 32, DS2 39, DS3 61, DS4 14, DS5 10. DS2+ = 39+61+14+10 = 124. Results 1. Why-buys non-compliance, DS2+ overall: 101 / 124 = 81.5%. Arithmetic: 124 DS2+ − 23 with LONG(n) present = 101 blank → 101/124 = 0.8145 → 81.5%. 2. By owner (DS2+ only): Owner Non-compliant / DS2+ Pct Alex Franklin 48 / 61 78.7% (48/61 = 0.7869) Cole Ingram 19 / 22 86.4% (19/22 = 0.8636) Dana Mercer 18 / 22 81.8% (18/22 = 0.8182) Bryce Harmon 15 / 18 83.3% (15/18 = 0.8333) Farid Osman 1 / 1 100.0% Total 101 / 124 81.5% Excluded from this cut: Gavin Porter and Hugo Lindqvist (archived, no open deals); Elena Sinclair (1 deal, Deal-57FF13, DS1). 3. Deals with no DS1 timestamp: 0 of 156. Every row has t_ds1 populated. 4. Deals that regressed: 0 of 156. No earlier-stage timestamp is later than a later-stage timestamp on any deal. Note on a related-but-different pattern (not counted as regression, since the rule is timestamp order): Deal-7E2131 (Dana Mercer) carries a t_ds4 of 2026-03-20 while sitting in DS3, i.e. a future-stage timestamp exists on a lower current stage. Flagging as a data-quality observation, not as a regression. Three process fixes 1. Make why-buys a hard stage gate at DS1→DS2. Block the stage advance in CRM until a ≥15-char, non-placeholder why-buys is saved; auto-reject tbd/n/a/see notes. At 81.5% non-compliance on 124 open DS2+ deals, the field is currently decorative. Sequence: fix the 61 Alex Franklin deals and 19 Cole Ingram deals first — they are 67 of the 101 gaps (67/101 = 66.3%). 2. Backfill before forecast, not after. The 101 gaps include every COMMIT and BEST_CASE deal in the file that lacks LONG(n) text, so forecast categories are being set on deals with no recorded reason to buy. Require a populated why-buys as a precondition for COMMIT/BEST_CASE and review those categories at the next pipeline call until backfilled. 3. Audit stage-timestamp writes, not just stage values. Timestamp order is clean (0 regressed), so the risk is the opposite failure: Deal-7E2131-style stale future-stage timestamps surviving a backwards stage move. Add a rule that clearing/downgrading a stage also clears its higher-stage timestamps, and run a weekly exception report on t_ds(n) populated while current stage < n. Data limitations: `why_buys` real text is unavailable — only LONG(n) length markers, so content quality cannot be assessed, only presence. No company names, no stage definitions beyond DS1–DS5 labels, and no historical stage-movement log exist in the provided files.
OWNER RESOLUTION — deals_open.csv x owners.csv Method: parsed 156 data rows from deals_open.csv; joined owner_id to owners.csv on owner_id. No name guessed for any id absent from owners.csv. 1) DEALS RESOLVED: 156 of 156 (100%) Distinct owner_ids appearing in the deal file: 119337721, 701163055, 716654662, 83155923, 83155924, 84342457 — all six exist in owners.csv. Arithmetic: 156 total rows - 0 unmatched = 156 resolved. 2) UNMATCHED OWNER IDS: none. Zero deals have an owner_id with no match in owners.csv. Nothing to list; no name was invented. 3) ARCHIVED / DEACTIVATED OWNERS: none map to any open deal. owners.csv flags archived=true for exactly two ids: 1520255671 (Gavin Porter) and 77260721 (Hugo Lindqvist). Neither id appears in deals_open.csv (0 deals each). All six owners actually carrying open deals are archived=false. So the list of owner ids mapping to archived owners: empty. 4) TOTAL PIPELINE PER RESOLVED OWNER (sum of amount, all 156 open deals) Bryce Harmon (119337721) n=35 $1,054,144.00 Alex Franklin (84342457) n=67 $624,310.00 Dana Mercer (83155923) n=24 $341,195.00 Cole Ingram (83155924) n=22 $288,161.43 Farid Osman (716654662) n= 7 $4,134.00 Elena Sinclair (701163055) n= 1 $2,100.00 ------------------------------------------------------- Total n=156 $2,314,044.43 Check: 35+67+24+22+7+1 = 156 ✓; 1,054,144 + 624,310 + 341,195 + 288,161.43 + 4,134 + 2,100 = 2,314,044.43 ✓ Data-quality notes (flagged, not assumed away): - 8 deals carry amount = 1, which looks like a placeholder rather than real value: Deal-012CB1, Deal-483B2D, Deal-3795AD (all Bryce Harmon), and Deal-03BA69, Deal-117863, Deal-F17780, Deal-2B39B0, Deal-8FDCD2 (all Farid Osman). Excluding those, Bryce Harmon = $1,054,141.00 and Farid Osman = $4,129.00; total = $2,314,039.43. Both figures are shown so the choice is yours. - Row 64524667574 (Deal-57FF13, Elena Sinclair) is short two fields versus the header (no last_contacted_field / source value) — parsed on owner_id and amount only. - Data is insufficient to say anything about why the owner name field is blank; the extract contains no owner name column, so no cross-check of name vs id was possible.
CALL-TO-DEAL MAPPING INTEGRITY CHECK Gong rows: 67 (67 distinct hs_deal_id, no repeated id) | deals_open: 156 rows, 156 distinct deal_id Join key: gong.hs_deal_id -> deals.deal_id. No alias conflicts — all 37 matched ids carry identical deal_alias on both sides, so the join is not producing false matches. (a) ORPHANS — gong deal ids with no match in deals_open: 30 of 67 (44.8%) 30 / 67 = 0.4478 Sample orphan aliases (all from data), by call volume: Deal-8FA85D 46 calls (hs_deal_id 60251290957, gong_owner 6440417017135074779) Deal-8FC3F9 24 calls (60251649055, 7971335727414442543) Deal-3B7945 21 calls (60251639682, 4654480998631630424) Deal-42B265 21 calls (61227242540, 8609905041415846265) Deal-9CCC42 17 calls (61430316324, 4654480998631630424) Deal-36EA09 17 calls (60251082126, 373679877710534937) Deal-9A43B4 14 calls (60250446726, 373679877710534937) Deal-605F3C 12 calls (60251622924, 373679877710534937) Deal-76821A 11 calls (60251092117, 373679877710534937) Deal-1A0416 8 calls (62333117085, 6421409461286167438) Volume impact: orphans carry 304 of 465 total calls; matched rows carry 161. 304 / 465 = 65.4% of logged call volume sits on deal ids that do not exist in the open pipeline. Two structural signals in the orphan set (both from the data, not inference about cause): - 25 of 30 orphans have calls_with_ds2_date = 0 AND calls_with_sqo_date = 0 (vs only 5 of 37 matched rows with ds2 = 0). - Their last_call values run to 2026-10-15 through 2026-11-27 (e.g. Deal-9CCC42 last_call 2026-11-27, Deal-42B265 2026-11-25, Deal-8FA85D 2026-11-05), i.e. beyond the latest last_contacted_field in deals_open (2026-09-04) and outside a 90-day window ending ~2026-09. - 8 gong_owner_id values appear ONLY on orphan rows (247470326654037859, 373679877710534937, 4654480998631630424, 6421409461286167438, 6440417017135074779, 7441100256678694562, 7971335727414442543, 8609905041415846265); only 3 owner ids (4433835492658898277, 4729257026550273695, 5886696740382085504) appear on both sides. - Many orphan ids fall in a contiguous 6025xxxxx block (60251004342, 60251032234, 60251082126, 60251092117, 60251124387, 60251130117, 60251184778, 60251290957, 60251622924, 60251639682, 60251649055, 60251652002, 60251705714, 60251733611, 60250446726). Caveat: "orphan" here means absent from deals_open. The data provided contains no closed/won/lost/archived deal table, so I cannot distinguish a bad key from a deal that legitimately closed or left the default pipeline. That determination is not possible with these two files. (b) DUPLICATE CONVERSATION KEYS — rows where calls_90d > distinct_conversation_keys: 0 Every row has calls_90d equal to distinct_conversation_keys (11=11, 46=46, 4=4, etc.), checked across all 67 rows. No duplication detected on this test. Note the limit of the test: this only compares the two aggregate columns supplied; it cannot detect two different deal ids pointing at the same underlying conversation, since no conversation-key values are in the data. (c) DS3-OR-LATER COVERAGE — open deals at stage DS3+ with >=1 logged call Stage mix of deals_open: DS1 32, DS2 39, DS3 61, DS4 14, DS5 10. DS3+ population = 61 + 14 + 10 = 85 With at least one gong row = 25 25 / 85 = 0.294 -> 29.4% Without any logged call = 85 - 25 = 60 (70.6%) By stage: DS3: 12 of 61 = 19.7% DS4: 6 of 14 = 42.9% DS5: 7 of 10 = 70.0% Amount of DS3+ deals with no logged call: 494,323.08 of 876,779.08 total DS3+ amount = 56.4%. Sample DS3+ deals with no call (aliases from data): Deal-7BBDFA (DS3, 37,440), Deal-B25F40 (DS3, 40,000), Deal-530B50 (DS3, 31,200), Deal-403845 (DS5, 9,000), Deal-2465CE (DS5, 5,400), Deal-9AAE5F (DS4, 11,250). Notes on scope: gong_owner_id is a Gong user id and does not map to deals_open.owner_id (values like 119337721, 84342457), so no owner-level reconciliation was attempted. All figures above derive only from the two files provided.
Cannot be written from this catalog. The request needs three grains that the catalog does not contain. Being explicit:
MISSING (nothing below is derivable or proxyable)
1. Unique givers — there is no giver table and no giver_id column anywhere in the catalog. The only giving number present is M1_GIVES in PRODUCTION.PLG.COMPANY_COHORT_SUMMARY, which is a pre-aggregated count, not a distinct-giver count. COUNT(DISTINCT giver_id) is not computable.
2. Recognition count — there is no recognition/giving event table. No recognition fact exists at any grain.
3. Successful redemption count per company per month — PRODUCTION.DEPRECATED_RECOGNITION.REDEMPTION_RECORDS_V2 documents only STATE. It has no documented company key, giver key, or redemption date, so it cannot be joined to a company or filtered to a first calendar month. M1_REDEMPTIONS is pre-aggregated and its STATE filter is undocumented, so it is not a verified 'succeeded' count.
4. "First calendar month as a customer" — the only customer-start date documented is FIRST_SUB_PAYMENT_DATE (self-serve/PLG companies only). COMPANY_COHORT_SUMMARY does not list a company identifier column, so even the per-company group key is undocumented. M1_* is anchored to an unspecified event (signup vs activation vs first payment), so it is not equivalent to a first calendar month.
AVOIDED TABLES (per catalog notes)
- PRODUCTION.HUBSPOT.DEALS — stale, last sync 2023-03.
- HUBSPOT_HUB_1973303.V2_LIVE.OBJECTS_DEALS — unpopulated.
- PRODUCTION.HUBSPOT.GONG_HUBSPOT_MAP_FAST — retired.
None of these would supply the missing grains regardless.
DELETED-GIVERS FILTER
Moot here: no giver dimension exists in this catalog, so there is no deleted-givers predicate to apply or withhold. Noted for when a giver table is supplied — it must NOT be applied to historical giving counts (it understates history).
The only slice of the request this catalog actually supports, with the documented redemption rule applied:
```sql
-- PARTIAL: per-company / per-month breakdown is not possible from this catalog.
-- Unique givers, recognition count, and per-company successful redemptions are NOT COMPUTABLE
-- (see gap list). This returns the only supportable fact: total succeeded redemptions.
SELECT
COUNT(*) AS successful_redemption_total -- no company or date key is documented on this table,
-- so no GROUP BY is possible
-- FROM: PRODUCTION.DEPRECATED_RECOGNITION.REDEMPTION_RECORDS_V2 — schema name is DEPRECATED but
-- the catalog names it the documented source for redemption counts; flagged there for
-- confirmation before finance-grade use.
-- AVOIDED: PRODUCTION.HUBSPOT.DEALS (stale, 2023-03) and
-- HUBSPOT_HUB_1973303.V2_LIVE.OBJECTS_DEALS (unpopulated) carry no redemption data anyway.
FROM PRODUCTION.DEPRECATED_RECOGNITION.REDEMPTION_RECORDS_V2
-- Business rule: only STATE = 'succeeded' counts as a redemption.
WHERE STATE = 'succeeded';
```
To make the full query possible, supply: a recognition fact (giver_id, company_id, recognition_ts), a giver dimension (with the is_deleted flag, to be withheld from historical counts), and a company_id + redemption timestamp on the redemption table.
⚠ Stream stalled mid tool-call (execute_code); the action was not executed. Ask me to retry if you want to continue. ⚠ Stream stalled mid tool-call (execute_code); the action was not executed. Ask me to retry if you want to continue.
CLASSIFICATION — 90 closed-lost deals, close_date 2026-07-29 through 2026-09-30, total $1,267,945
Method: primary category taken from the free-text reason where it carries a real signal; the structured tag used when the text adds nothing. Side = who the driver sits with. Amounts in USD as given.
--- TIMING (18) — $252,651 — all buyer side
Deal-DB0AAC, Deal-91A056, Deal-29326C, Deal-831B7B, Deal-39E25C, Deal-B3ABED, Deal-B6AC09, Deal-E6E80A, Deal-B038F0, Deal-175756, Deal-BB78F3, Deal-15DA99, Deal-F4AF5D, Deal-79B7A1, Deal-9F176A, Deal-69CF3D, Deal-ECBF89, Deal-D1A623
--- NO DECISION (34) — $292,804
Buyer side: Deal-AC944F, Deal-214060, Deal-13E9CF, Deal-21B045, Deal-ED9AE7, Deal-988493, Deal-F308CA, Deal-70F704, Deal-4664E1, Deal-E74A73, Deal-D48E0B, Deal-583ADB, Deal-7CB44D, Deal-FAC17C, Deal-50E5D8, Deal-AFA56C, Deal-413C56, Deal-2A292B, Deal-D1AABF, Deal-FEDBCB, Deal-2BBA21, Deal-7FBAC6, Deal-386F6E, Deal-55867E, Deal-2FEDDB, Deal-3F86A0, Deal-096750, Deal-ABD14C, Deal-79E61A, Deal-AE7C4E, Deal-DAB4F1, Deal-B4B50F, Deal-5885B9
Bonusly side: Deal-E0441F ($2,405, "stale when I inherited it from a departed rep" — rep-side failure, not buyer)
--- COMPETITOR (23) — $372,529 — all buyer side
Deal-F7F635, Deal-F97C37, Deal-422BA6, Deal-DDAB52, Deal-ACE061, Deal-8E27DA, Deal-2D2F8D, Deal-0F96AA, Deal-242273, Deal-A2C349, Deal-C7156E, Deal-5E64CE, Deal-8A0992, Deal-D0C698, Deal-EECC02, Deal-47F1A1, Deal-BF2A98, Deal-1E7DA9, Deal-286F9C, Deal-369281, Deal-9FCD0D, Deal-64B19A, Deal-DC77FE
--- PRICING (6) — $187,450 — all buyer side
Deal-7ED004 ($60,000), Deal-1BCA50 ($15,000), Deal-7B2236 ($72,000), Deal-C33D91 ($7,200), Deal-DAFB82 ($30,000), Deal-8A119B ($3,250)
--- PRODUCT GAP (4) — $118,245 — all Bonusly side
Deal-9048EB, Deal-3618CC, Deal-5AD03E, Deal-981AD4
--- CHAMPION LEFT (1) — $14,400 — buyer side (org change, not rep)
Deal-F325A5 ("Layoffs and Change in Leadership")
--- OTHER (4) — $29,866 — side unknown, text carries no causal signal
Deal-5DB9B0, Deal-381C8C, Deal-F1E8A6, Deal-7CC678
==================================================
SUMMARY
==================================================
CATEGORY COUNTS (n, % of 90, $, % of $1,267,945, avg)
no decision 34 37.8% $292,804 23.1% $8,612
competitor 23 25.6% $372,529 29.4% $16,197
timing 18 20.0% $252,651 19.9% $14,036
pricing 6 6.7% $187,450 14.8% $31,242
product gap 4 4.4% $118,245 9.3% $29,561
other 4 4.4% $29,866 2.4% $7,466
champion left 1 1.1% $14,400 1.1% $14,400
Total: 90 / $1,267,945 (checks: 34+23+18+6+4+4+1 = 90)
SIDE SPLIT
buyer 81 90.0%
bonusly 5 5.6% (Deal-E0441F, Deal-9048EB, Deal-3618CC, Deal-5AD03E, Deal-981AD4)
unknown 4 4.4% (Deal-5DB9B0, Deal-381C8C, Deal-F1E8A6, Deal-7CC678)
TAG vs FREE-TEXT DISAGREEMENTS: 6 clear-cut
1. Deal-8E27DA — tagged "Feature Request"; text says they moved forward with a swag provider instead of R&R → competitor
2. Deal-1BCA50 — tagged "Competitor"; text leads with budget/gift-card details → pricing
3. Deal-9048EB — tagged "MIA"; text states bad fit, desired setup + multiple feature gaps → product gap
4. Deal-3618CC — tagged "Lost DM"; text is "Wanted Surveys" → product gap
5. Deal-5AD03E — tagged "Competitor"; text is "Wanted more defined budget access" → product gap (weakest of the six; readable either way)
6. Deal-5E64CE — tagged "Doing nothing/Not a priority/Cost"; text is a Nectar contract running through October 2027 with a costly exit fee → competitor (incumbent lock-in), not apathy
Two more are partial, not counted above: Deal-13E9CF is tagged ".../Cost" but the text says explicitly "Not a budget issue" — deprioritization, not price (I classified no decision). Deal-55867E is tagged "Lost- Timing (1 year or more)" but the text names no future date at all, only "won't be moving forward with Bonusly at this time" — I classified no decision.
Data-quality note: 3 further deals are tagged "Competitor" with text that provides zero corroboration — Deal-381C8C ("working on getting additional context"), Deal-F1E8A6 ("said they are not going to be moving forward"), Deal-7CC678 ("Nothing specific provided."). Not contradictions, just unverified; all 3 land in other/unknown.
==================================================
TWO PATTERNS WORTH ACTING ON
==================================================
PATTERN 1 — Most "losses" are deferrals with a date attached, and they are being written off.
timing 18 + no decision 34 = 52 deals = 57.8% of volume and $252,651 + $292,804 = $545,455 = 43.0% of lost dollars. Within the timing bucket, 14 of 18 (78%) name an explicit re-engage window — early 2027 (Deal-91A056, Deal-831B7B, Deal-B6AC09, Deal-E6E80A, Deal-B038F0, Deal-15DA99, Deal-F4AF5D, Deal-BB78F3), 2027 (Deal-175756), Q2 next year for 2028 budget (Deal-B3ABED), 2028 (Deal-DAFB82, counted under pricing), end of year (Deal-9F176A). That dated subset alone is $240,026 = 18.9% of lost dollars. These are not losses; they are a dated 2027 recall list. Closing them as lost with no date triggers attached throws away a re-engageable $240K.
PATTERN 2 — Competitive losses are about breadth and ecosystem, not price — so discounting will not fix them.
competitor 23 + pricing 6 = 29 deals = 32.2% of volume but $559,979 = 44.2% of lost dollars. Average competitor deal is $16,197 vs $8,612 for no-decision — 1.9x, meaning dollars concentrate where we lose to a named vendor. But the stated drivers are capability and ecosystem, not rate: Deal-DC77FE says outright "you were competitive in price so that wasn't a factor" and lost on customization (labelling points as dollars). Others: breadth at parity price (Deal-DDAB52, Rippl, "a lot more at the same cost"), adjacent offerings beyond R&R (Deal-F97C37), a use case we did not meet (Deal-242273, digitizing an internal points currency spendable at onsite facilities), integration/partnership status (Deal-422BA6, ADP TotalSource preferred partner), and geography (Deal-8A0992 and Deal-9FCD0D, Canadian provider at CEO's request; Deal-981AD4, not UK focused). Incumbent gravity is real too — Deal-A2C349 (Awardco), Deal-47F1A1 (WorkTango), Deal-64B19A (Motivosity), Deal-BF2A98 (HiThrive), Deal-D0C698 (Kudos), Deal-ACE061 (HeyTaco), Deal-5E64CE (Nectar), Deal-369281 (Paylocity). Priority: battlecards on ADP/Paylocity integration and Canada/UK coverage, plus a points-currency capability answer — not price concessions.
Worth flagging but not a top-two: the 4 Bonusly-side product-gap deals average $29,561, the highest of any category, and MIA is 22 tagged deals worth $254,142 (20.0% of lost dollars) — 21 of those ($212,352) are no-decision, i.e. a large block of pipeline that was never actually worked to a decision.
{
"tier_counts": {"LOCK": 3, "ACTION": 9, "BUILD": 24, "REVIVE": 8, "WATCH": 11, "RISKY": 38},
"tier_examples": {"LOCK": ["Deal-D348E1", "Deal-C26D20", "Deal-403845"], "ACTION": ["Deal-2D1F1B", "Deal-66D1FC", "Deal-C6FE92"], "BUILD": ["Deal-1FC049", "Deal-5296C9", "Deal-898FC5"], "REVIVE": ["Deal-2465CE", "Deal-B7EBD1", "Deal-584EE5"], "WATCH": ["Deal-9AAE5F", "Deal-0660B4", "Deal-5AD94B"], "RISKY": ["Deal-25F752", "Deal-E53952", "Deal-5408B0"]},
"risky_deals": ["Deal-25F752","Deal-E53952","Deal-5408B0","Deal-9AAE5F","Deal-547B2B","Deal-944310","Deal-3974EB","Deal-62D607","Deal-C6D97A","Deal-F9A08A","Deal-1FC049","Deal-FD9F4E","Deal-BA571A","Deal-FC22A3","Deal-7BBDFA","Deal-333EBB","Deal-4A13AD","Deal-8AD4A5","Deal-15D24F","Deal-9D0060","Deal-690476","Deal-EE195F","Deal-034D49","Deal-635B8E","Deal-46988D","Deal-ED725A","Deal-55164C","Deal-3BA5EA","Deal-5FDCE4","Deal-F336B6","Deal-215CCA","Deal-5EED42","Deal-DAF1D9","Deal-8952F0","Deal-BA3DDC","Deal-7E2131","Deal-7599B8","Deal-F9A3C1"],
"lock_violations": 0,
"pipeline_shape": "..."
}
```json
[
{
"transcript_id": "TX-001",
"deal_alias": "Deal-CFE7F4",
"why_buys": [
"Automating anniversary and birthday awards — HR team of three cannot keep up manually (Prospect (VP People))",
"Currently track everything in a spreadsheet and people slip through the cracks (Prospect (HR Admin))"
],
"pain_points": [
"Manual anniversary/birthday award processing exceeds capacity of 3-person HR team",
"Spreadsheet-based tracking causes missed employees"
],
"stakeholders": ["Prospect (VP People)", "Prospect (HR Admin)", "IT lead (referenced by rep/prospect, not a speaker)", "Alex Franklin (rep, not a buyer stakeholder)"],
"budget_signal": "$40k earmarked for engagement tools this fiscal year (Prospect (VP People))",
"timeline_signal": "Live before open enrollment in November (Prospect (VP People))",
"competitor_mentioned": "Achievers (raised by Prospect (VP People); evaluated last year, too heavy for team size)",
"next_step": "Security review on September 12 (agreed by Prospect (VP People))",
"objections": [
"Achievers evaluated last year and was too heavy for a team their size (Prospect (VP People))",
"Need SSO and audit logs for IT sign-off (Prospect (HR Admin))"
],
"confidence": "High — prospect-stated budget, timeline, and confirmed dated next step"
},
{
"transcript_id": "TX-002",
"deal_alias": "Deal-70BB30",
"why_buys": [
"Tie recognition to retention for hourly workforce — regretted turnover over 30% (Prospect (Head of Total Rewards))"
],
"pain_points": [
"Regretted turnover above 30% in the hourly workforce"
],
"stakeholders": ["Prospect (Head of Total Rewards)", "Prospect (CFO)", "Legal (referenced by Prospect (CFO), not a speaker)", "Alex Franklin (rep)"],
"budget_signal": "$25k pilot budget approved by Finance for this quarter (Prospect (CFO))",
"timeline_signal": "Decision by end of September (Prospect (CFO))",
"competitor_mentioned": null,
"next_step": "Rep sends pilot agreement; prospect routes it to legal this week (agreed by Prospect (CFO))",
"objections": [
"Workday integration must be rock solid — stated as CFO's one condition"
],
"confidence": "High — CFO-stated approved budget, decision date, and agreed next step"
},
{
"transcript_id": "TX-003",
"deal_alias": "Deal-530B50",
"why_buys": [
"Make recognition visible across 12 retail locations (Prospect (People Ops Manager))"
],
"pain_points": [
"Store managers have zero budget autonomy for on-the-spot recognition today (Prospect (People Ops Manager))"
],
"stakeholders": ["Prospect (People Ops Manager)", "CEO (referenced, not a speaker)", "Alex Franklin (rep)"],
"budget_signal": null,
"timeline_signal": "No rush until Q1 (Prospect (People Ops Manager))",
"competitor_mentioned": "Bucketlist (raised by Prospect (People Ops Manager); CEO used it at her last company and liked it)",
"next_step": "Prospect will send two times for a call with the CEO (agreed by Prospect (People Ops Manager))",
"objections": [
"No urgency — no rush until Q1 (Prospect (People Ops Manager))",
"CEO must be sold first; she decides anything people-related (Prospect (People Ops Manager))"
],
"confidence": "Low-Medium — no prospect-stated budget (rep's $8/employee/month quote excluded), timeline pushed to Q1, CEO is unnamed gatekeeper. Arithmetic note: no budget figures available to compute."
},
{
"transcript_id": "TX-004",
"deal_alias": "Deal-180D02",
"why_buys": [
"Consolidate three separate recognition tools into one (Prospect (VP People))",
"Paying for three tools and none of them talk to our HRIS (Prospect (VP People))"
],
"pain_points": [
"Paying for three tools with no HRIS integration",
"Procurement cycle runs 6-8 weeks minimum (Prospect (IT Security Lead))",
"Security review took three months for last vendor (Prospect (IT Security Lead))"
],
"stakeholders": ["Prospect (VP People)", "Prospect (IT Security Lead)", "CFO (referenced, not a speaker)", "Alex Franklin (rep)"],
"budget_signal": "Under $15k annually can be approved by VP People without board approval (Prospect (VP People))",
"timeline_signal": "Procurement cycle 6-8 weeks minimum (Prospect (IT Security Lead)); last security review took 3 months",
"competitor_mentioned": null,
"next_step": null,
"objections": [
"Procurement cycle runs six to eight weeks minimum (Prospect (IT Security Lead))",
"Security review took three months for last vendor — stated hesitation (Prospect (IT Security Lead))",
"VP People non-committal on CFO follow-up: 'Maybe — I need to check her calendar, no promises.' (Prospect (VP People))"
],
"confidence": "Low — no firm next step agreed; 3-month security review precedent conflicts with any near-term close. Arithmetic note: 6-8 week procurement + up to 3-month security review = up to ~20 weeks (8 + 12) in gated cycle time."
},
{
"transcript_id": "TX-005",
"deal_alias": "Deal-F8767A",
"why_buys": [
"Automate service milestones (Prospect (HR Director))",
"Analytics on recognition equity across departments (Prospect (HR Director))",
"Night-shift teams feel invisible — engagement scores run 20 points lower (Prospect (People Ops Coordinator))"
],
"pain_points": [
"Night-shift engagement scores 20 points lower than others",
"Exec team skeptical after a failed rollout two years ago (Prospect (HR Director))"
],
"stakeholders": ["Prospect (HR Director)", "Prospect (People Ops Coordinator)", "Exec team (referenced, not a speaker)", "Alex Franklin (rep)"],
"budget_signal": "$12k approved under engagement line (Prospect (HR Director))",
"timeline_signal": "Running before January all-hands (Prospect (HR Director))",
"competitor_mentioned": "Nectar (raised by Prospect (HR Director); currently mid-pilot, must beat that experience)",
"next_step": "Rep presents to exec team on October 2 (agreed by Prospect (HR Director))",
"objections": [
"Mid-pilot with Nectar — must beat that experience (Prospect (HR Director))",
"Exec team skeptical after failed rollout two years ago (Prospect (HR Director))"
],
"confidence": "Medium-High — approved budget and dated exec presentation, but incumbent Nectar pilot is an active competitive threat"
},
{
"transcript_id": "TX-006",
"deal_alias": "Deal-EE195F",
"why_buys": [
"Cut admin time on service awards (Prospect (HR Manager))",
"Personally spends five hours a month ordering and shipping plaques (Prospect (HR Manager))"
],
"pain_points": [
"5 hours/month spent manually ordering and shipping plaques. Arithmetic: 5 hrs x 12 months = 60 hrs/year of HR manager time on plaque logistics"
],
"stakeholders": ["Prospect (HR Manager)", "COO (referenced, not a speaker)", "Alex Franklin (rep)"],
"budget_signal": null,
"timeline_signal": "Fiscal year resets in February, so a Q1 start is realistic (Prospect (HR Manager))",
"competitor_mentioned": null,
"next_step": "Rep sends one-page overview; prospect forwards it to COO this week (agreed by Prospect (HR Manager))",
"objections": [
"Budget explicitly not the issue — time is (Prospect (HR Manager))",
"COO usually prefers building things in-house — 'fair warning' (Prospect (HR Manager))",
"Comparing against doing it internally (Prospect (HR Manager))"
],
"confidence": "Medium — clear pain and agreed next step, but in-house build preference from COO is a structural risk and budget is unstated (prospect rejected the budget framing)"
}
]
```
Notes on field discipline:
- Rep statements excluded everywhere: TX-003's "$8 per employee per month" (Alex Franklin) is not a budget signal, so budget_signal is null. TX-006's pricing flex offer likewise excluded; the prospect's "Budget isn't the issue" means no figure exists.
- competitor_mentioned is null for TX-002 ("You're the first vendor we've had a real demo with"), TX-004, and TX-006 ("Nobody else") — no competitor was raised by a prospect in those calls.
- next_step is null only for TX-004: the rep proposed a CFO follow-up and the VP People answered "Maybe — no promises," which is not an explicit agreement.
- Speaker lists contain only two role-labeled prospects per call in TX-001, TX-002, TX-004, TX-005; TX-003 and TX-006 have a single prospect speaker. Named individuals (CEO, CFO, COO, IT lead, legal, exec team) are referenced but never speak, so they are listed as referenced, not confirmed attendees.
- Deal aliases cited exactly as given: Deal-CFE7F4, Deal-70BB30, Deal-530B50, Deal-180D02, Deal-F8767A, Deal-EE195F.
CRM alone would put Deal-2465CE near the top (DS5/COMMIT, $5,400, close 2026-09-10), but Slack overrides it: Dana Mercer says the champion left and procurement froze new vendors; she is pulling it out of commit and calls it a Q4 deal. Excluded. Closest 3 (all DS5/COMMIT): 1. Deal-547B2B — $11,200 — Alex Franklin — close 2026-09-11. Why: redlines came back clean, signing page is out, VP People says they sign tomorrow; Alex calls it signature-imminent. Left: only execution/countersignature. 2. Deal-403845 — $9,000 — close 2026-09-11 — CRM owner Alex Franklin, though Dana Mercer says "moving fine on my side" (ownership conflict — verify). Why: order form is with their finance team. Left: finance sign-off, then countersign. 3. Deal-A2B47C — $6,360 — close 2026-09-11 — Alex Franklin. Why: Alex confirms "still warm, normal legal-review pace" — progressing, not blocked. Left: finish legal review, then signature. Combined: $11,200 + $9,000 + $6,360 = $26,560. Caveats: Deal-D348E1 ($13,770, close 2026-10-15) is equally "warm" per Slack but closes ~34 days later, so it ranks 4th. Deal-B7EBD1 ($9,000, COMMIT, close 2026-09-10) has the earliest CRM date but no Slack confirmation of paperwork progress — unverified, could displace #3.
CANDIDATE-BY-CANDIDATE 1) TG-001 — Deal-EC3025 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: "SCIM user provisioning and ADP Workforce Now integrations are NOT currently listed as supported capabilities." Enterprise tier lists SSO/SAML and audit logs — SCIM is absent from every tier. Class: REAL GAP (not a plan gate — no tier offers it). Amount: not in data (see note below). 2) TG-002 — Deal-D0D6B5 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 row lists only Workday, BambooHR, Gusto, Rippling (Pro and above). ADP explicitly NOT supported. Class: REAL GAP. Amount: not in data. 3) TG-003 — Deal-CFE7F4 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 (— / — / yes). Capability exists; it is tier-gated. Rep (Alex Franklin) confirms: "The custom report builder sits on our Enterprise tier." Class: PLAN GATE — excluded from summary. Amount: not in data. 4) TG-004 — Deal-84DBA6 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 integration = yes on all plans; feature is live and working. Failure is adoption/training, not capability. Class: ROLLOUT/ENABLEMENT — excluded from summary. Amount: not in data. 5) TG-005 — Deal-36C33F Quote (Prospect, HR Manager): "Good to know. The web version should be fine for our office staff for now." The mobile-app gap is raised by the REP — Alex Franklin: "Full transparency — we don't have a native mobile app for hourly workers yet, though it's on the roadmap." The prospect does not raise it and does not object. Class: EXCLUDED — rep language, not prospect voice. No prospect-raised gap in this transcript. Amount: not in data. ARITHMETIC Transcripts: 5 Prospect-attributed lines: 5 (one per transcript) Lines that actually raise a gap: 5 − 1 (TG-005 is rep-raised, prospect only acknowledges) = 4 candidate gaps Of those 4: 2 real gap + 1 plan gate + 1 rollout/enablement = 4 ✓ Carried into summary: 2 SUMMARY — TRUE PRODUCT GAPS (prospect-voiced only) Deal-EC3025 — SCIM user provisioning absent at every tier; security team blocks approval without it. Amount: unknown (no amount field in transcripts_gaps.csv; no amount data in product_docs.md). Deal-D0D6B5 — ADP Workforce Now absent from HRIS integrations (only Workday, BambooHR, Gusto, Rippling supported); prospect calls it a dealbreaker. Amount: unknown (same reason). DATA GAPS I CANNOT FILL No deal amounts exist anywhere in the two files provided — transcripts_gaps.csv has only transcript_id, deal_alias, speaker, line_text. Every "amount" above is therefore reported as missing rather than estimated. Also absent: deal stage, close date, ARR, and whether either deal is still active (the prompt says "active deals"; the files carry no stage/status field to confirm that).
Stale-deal report — snapshot 2026-09-05
Source: ~/bonuslybench/data_pkg/bonuslybench-data/data/{deals_open.csv, engagements_by_deal_90d.csv, owners.csv} (280 open deals, 277 engagement rows). Recency computed from last_email / last_call / last_meeting only; last_contacted_field ignored as instructed.
Method
Stale = no email, call, or meeting dated on or after 2026-08-29 (i.e. days-since > 7).
Days since = 2026-09-05 − most recent PAST-dated contact of the three.
Future-dated meetings exist in the table (e.g. 2026-09-10, 2026-09-15) — these are scheduled, not logged, so they do not clear a deal. They are flagged in brackets where present.
3 open deals have no row in the engagements table at all — treated as stale, days = "no data".
Result: 118 of 280 open deals are stale (42.1%), $1,926,344.78 of open pipeline.
=================================================================
Bryce Harmon (owner 119337721) — 30 stale deals — $956,895.00
=================================================================
Deal-2D1F1B DS1 PIPELINE 240,000.00 2026-06-16 81d meeting
Deal-66D1FC DS1 PIPELINE 99,000.00 2026-08-20 16d email
Deal-950043 DS1 PIPELINE 70,000.00 2026-08-17 19d email
Deal-31ED2A DS1 PIPELINE 57,600.00 2026-08-19 17d email
Deal-77A95A DS1 PIPELINE 48,000.00 2026-08-28 8d email+meeting
Deal-B23205 DS1 PIPELINE 45,000.00 2026-08-20 16d email+meeting
Deal-7BBDFA DS3 BEST_CASE 37,440.00 2026-07-21 46d email
Deal-332637 DS2 PIPELINE 36,000.00 2026-08-27 9d email
Deal-C9BB20 DS1 PIPELINE 33,600.00 2026-08-12 24d email
Deal-91DAAF DS1 PIPELINE 32,400.00 2026-08-14 22d email+meeting
Deal-1BEEBF DS1 PIPELINE 31,500.00 2026-08-17 19d email
Deal-A414F6 DS1 PIPELINE 25,200.00 2026-08-17 19d email [mtg 2026-09-10]
Deal-D56743 DS3 PIPELINE 24,000.00 2026-08-18 18d email
Deal-C5658B DS1 PIPELINE 23,400.00 2026-08-20 16d email
Deal-40522D DS3 PIPELINE 21,000.00 2026-08-17 19d email
Deal-2D1F2C DS3 BEST_CASE 18,700.00 2026-08-20 16d email+meeting
Deal-C1FA6D DS1 PIPELINE 18,000.00 2026-08-20 16d email [mtg 2026-09-15]
Deal-B02199 DS1 PIPELINE 16,170.00 2026-08-10 26d email+meeting
Deal-01E193 DS1 PIPELINE 12,600.00 2026-08-28 8d email [mtg 2026-09-09]
Deal-383A99 DS3 BEST_CASE 11,500.00 2026-08-20 16d email
Deal-F0EBBB DS3 PIPELINE 11,400.00 2026-08-12 24d email
Deal-927338 DS1 PIPELINE 10,920.00 2026-08-18 18d email [mtg 2026-09-17]
Deal-4E586D DS1 PIPELINE 8,400.00 2026-08-28 8d email [mtg 2026-09-15]
Deal-CC3E7F DS1 PIPELINE 7,560.00 2026-08-27 9d email
Deal-72301F DS1 PIPELINE 6,000.00 2026-08-19 17d email
Deal-E25A09 DS1 PIPELINE 6,000.00 2026-08-27 9d email
Deal-C9C286 DS2 PIPELINE 5,502.00 2026-08-27 9d email
Deal-012CB1 DS1 PIPELINE 1.00 2026-08-13 23d email
Deal-3795AD DS2 PIPELINE 1.00 2026-08-28 8d email [mtg 2026-10-02]
Deal-4F0D4F DS1 PIPELINE 1.00 2026-08-27 9d email [mtg 2026-09-09]
=================================================================
Dana Mercer (owner 83155923) — 29 stale deals — $406,204.00
=================================================================
Deal-96039F DS1 PIPELINE 60,000.00 2026-08-17 19d email
Deal-44EA29 DS2 PIPELINE 60,000.00 2026-08-26 10d email
Deal-E51FB7 DS2 PIPELINE 43,875.00 2026-08-24 12d call
Deal-B42F46 DS1 PIPELINE 27,000.00 2026-08-17 19d email
Deal-BA3DDC DS3 BEST_CASE 23,400.00 2026-08-21 15d call
Deal-9DDE86 DS2 PIPELINE 20,000.00 2026-08-21 15d email
Deal-215CCA DS3 BEST_CASE 18,900.00 2026-08-19 17d meeting
Deal-5EED42 DS3 BEST_CASE 16,250.00 2026-08-25 11d email+call
Deal-57887A DS2 PIPELINE 15,000.00 2026-08-28 8d email
Deal-944310 DS4 BEST_CASE 10,500.00 2026-08-03 33d email [mtg 2026-09-15]
Deal-76FDB5 DS2 PIPELINE 10,000.00 2026-08-25 11d email
Deal-A6FD51 DS2 PIPELINE 10,000.00 2026-08-25 11d email
Deal-B7EBD1 DS5 COMMIT 9,000.00 2026-08-20 16d email
Deal-3974EB DS4 BEST_CASE 9,000.00 2026-08-28 8d email+meeting
Deal-F40F04 DS2 PIPELINE 8,100.00 2026-08-21 15d email+meeting
Deal-B7314F DS3 PIPELINE 8,000.00 2026-08-21 15d email
Deal-D4BFC5 DS2 PIPELINE 7,740.00 2026-08-27 9d email
Deal-7599B8 DS3 BEST_CASE 7,350.00 2026-08-18 18d email [mtg 2026-09-10]
Deal-14FEC4 DS3 BEST_CASE 5,125.00 2026-08-27 9d email
Deal-87DDD1 DS1 PIPELINE 5,000.00 2026-08-17 19d email
Deal-798903 DS2 PIPELINE 5,000.00 2026-08-21 15d email
Deal-46ECC7 DS1 PIPELINE 4,680.00 2026-08-27 9d email
Deal-F336B6 DS3 BEST_CASE 4,200.00 2026-08-21 15d email
Deal-CDC0D0 DS2 PIPELINE 4,200.00 2026-08-19 17d email [mtg 2026-09-14]
Deal-341F2C DS3 PIPELINE 3,654.00 2026-08-25 11d email
Deal-334A0B DS2 PIPELINE 3,000.00 2026-08-27 9d email
Deal-CAF1D9 DS1 PIPELINE 3,000.00 2026-08-28 8d email
Deal-681C6B DS3 BEST_CASE 2,310.00 2026-08-25 11d email
Deal-0660B4 DS4 BEST_CASE 1,920.00 2026-08-20 16d meeting
=================================================================
Alex Franklin (owner 84342457) — 28 stale deals — $202,894.00
=================================================================
Deal-D0662E DS1 PIPELINE 41,000.00 2026-08-28 8d email
Deal-CC08D1 DS1 PIPELINE 24,000.00 2026-08-20 16d email
Deal-E73427 DS3 PIPELINE 18,000.00 2026-08-26 10d email+meeting
Deal-37255F DS3 PIPELINE 12,150.00 2026-08-28 8d email
Deal-180D02 DS3 BEST_CASE 9,720.00 2026-08-26 10d email
Deal-F8767A DS3 BEST_CASE 9,360.00 2026-08-28 8d email
Deal-885F45 DS2 PIPELINE 9,300.00 2026-08-24 12d email
Deal-C2FF3C DS1 PIPELINE 8,316.00 2026-08-26 10d email
Deal-3EED2C DS2 PIPELINE 7,200.00 no data — no engagement row
Deal-A181B3 DS2 PIPELINE 7,200.00 2026-08-28 8d email
Deal-1D532E DS1 PIPELINE 5,400.00 no data — no engagement row
Deal-0D2F7A DS3 PIPELINE 5,100.00 2026-08-24 12d call
Deal-6C60D4 DS3 PIPELINE 4,800.00 2026-08-24 12d call
Deal-13FEBD DS2 PIPELINE 4,680.00 2026-08-24 12d call
Deal-819506 DS1 PIPELINE 4,400.00 2026-08-28 8d email [mtg 2026-09-09]
Deal-9D0060 DS3 BEST_CASE 3,840.00 2026-08-24 12d email
Deal-690476 DS2 BEST_CASE 3,600.00 2026-08-18 18d call
Deal-357C30 DS3 BEST_CASE 3,600.00 2026-08-24 12d email
Deal-C6D97A DS4 BEST_CASE 3,240.00 2026-08-28 8d email
Deal-EE195F DS3 BEST_CASE 3,120.00 2026-08-28 8d email
Deal-278DEC DS3 PIPELINE 2,700.00 2026-08-28 8d email
Deal-635B8E DS3 BEST_CASE 2,600.00 2026-08-18 18d email
Deal-6883F3 DS1 PIPELINE 2,400.00 2026-08-20 16d email+meeting
Deal-4A13AD DS3 BEST_CASE 2,160.00 2026-08-10 26d email
Deal-F67D31 DS2 PIPELINE 1,800.00 2026-08-28 8d email
Deal-5FDCE4 DS3 BEST_CASE 1,600.00 2026-08-24 12d email
Deal-BA571A DS4 BEST_CASE 1,080.00 2026-08-18 18d email
Deal-87412C DS3 BEST_CASE 528.00 2026-08-26 10d email
=================================================================
Cole Ingram (owner 83155924) — 26 stale deals — $350,369.78
=================================================================
Deal-D04904 DS2 PIPELINE 58,529.25 2026-08-25 11d email
Deal-AA8DDA DS2 PIPELINE 45,630.00 2026-08-25 11d email
Deal-B25F40 DS3 PIPELINE 40,000.00 2026-08-28 8d email
Deal-813836 DS2 PIPELINE 32,175.00 2026-08-25 11d email
Deal-1BA595 DS2 PIPELINE 31,750.00 2026-08-25 11d email
Deal-CFE1E8 DS3 PIPELINE 18,000.00 2026-08-25 11d email
Deal-84632B DS3 PIPELINE 14,946.75 2026-08-25 11d email
Deal-CD47A6 DS2 PIPELINE 12,168.00 2026-08-25 11d email
Deal-627646 DS3 PIPELINE 11,193.00 2026-08-25 11d email
Deal-F5CACD DS2 PIPELINE 10,000.00 2026-08-25 11d email
Deal-D7A6AC DS2 PIPELINE 9,360.00 2026-08-24 12d email
Deal-FF809F DS2 PIPELINE 7,781.20 2026-08-25 11d email
Deal-AF932D DS2 PIPELINE 7,225.40 2026-08-25 11d email
Deal-80BBC2 DS1 PIPELINE 7,000.00 2026-08-25 11d email
Deal-A71728 DS2 PIPELINE 6,947.50 2026-08-25 11d email
Deal-590425 DS1 PIPELINE 5,616.00 2026-08-25 11d email
Deal-8BC9F5 DS2 PIPELINE 5,616.00 2026-08-26 10d email
Deal-175395 DS3 PIPELINE 4,779.88 2026-08-25 11d email
Deal-712D69 DS2 PIPELINE 4,212.00 2026-08-25 11d email
Deal-481E24 DS3 PIPELINE 4,140.00 2026-08-26 10d call
Deal-C7F9BF DS2 PIPELINE 3,360.00 2026-08-25 11d email
Deal-2F3A66 DS3 PIPELINE 3,334.80 2026-08-25 11d email
Deal-342E96 DS2 PIPELINE 2,700.00 2026-08-12 24d email
Deal-E568D5 DS3 PIPELINE 1,875.00 2026-08-25 11d email
Deal-FD9F4E DS5 COMMIT 1,330.00 2026-08-26 10d email
Deal-35738B DS2 PIPELINE 700.00 2026-08-25 11d email
=================================================================
Farid Osman (owner 716654662) — 4 stale deals — $7,882.00
=================================================================
Deal-ED2246 DS1 PIPELINE 5,000.00 2026-08-21 15d email [mtg 2026-09-10]
Deal-8BA24E DS1 PIPELINE 2,880.00 2026-08-28 8d email [mtg 2026-09-15]
Deal-F432E1 DS1 PIPELINE 1.00 2026-08-25 11d email
Deal-8FDCD2 DS1 PIPELINE 1.00 2026-08-21 15d email [mtg 2026-09-15]
=================================================================
Elena Sinclair (owner 701163055) — 1 stale deal — $2,100.00
=================================================================
Deal-57FF13 DS1 PIPELINE 2,100.00 no data — no engagement row
=================================================================
PER-OWNER SUMMARY
=================================================================
Owner Stale deals Stale amount % of own open pipeline*
Bryce Harmon 30 $956,895.00
Dana Mercer 29 $406,204.00
Alex Franklin 28 $202,894.00
Cole Ingram 26 $350,369.78
Farid Osman 4 $7,882.00
Elena Sinclair 1 $2,100.00
TOTAL 118 $1,926,344.78
(*own-pipeline denominators not computed — not requested.)
Arithmetic checks
30 + 29 + 28 + 26 + 4 + 1 = 118 stale deals; 280 − 118 = 162 deals have contact on/after 2026-08-29.
956,895.00 + 406,204.00 + 202,894.00 + 350,369.78 + 7,882.00 + 2,100.00 = 1,926,344.78.
Days math, worst case: Deal-2D1F1B 2026-06-16 → 2026-09-05 = 15 (Jun) + 31 (Jul) + 31 (Aug) + 5 (Sep) = 82 calendar days; reported 81d (matches date subtraction: Sep 5 − Jun 16 = 81).
Boundary example: Deal-77A95A last contact 2026-08-28 → Sep 5 − Aug 28 = 8d > 7 → stale. A deal touched 2026-08-29 or later would be excluded; none in the 8–10d band sit at exactly 7.
Data gaps / caveats (explicit)
- Deals with no engagement table row (3): Deal-3EED2C, Deal-1D532E, Deal-57FF13. "Days since last contact" is unavailable — shown as "no data", not as a number. Treated as stale per the no-logged-activity rule.
- 3 open deals are missing from engagements_by_deal_90d.csv entirely (277 engagement rows vs 280 open deals).
- Future-dated meetings (after 2026-09-05) appear in last_meeting for several deals; these are scheduled events, not logged activity, and were excluded from the recency max. They are bracketed above for context only.
- Amounts are as given in deals_open.csv, including three $1.00 placeholder amounts (Deal-012CB1, Deal-3795AD, Deal-4F0D4F, Deal-F432E1, Deal-8FDCD2) — these inflate deal counts and deflate value realism; treat the small-dollar tail as unqualified.
- Owner 119337721's total is driven by Deal-2D1F1B ($240,000, DS1, 81d, close 2027-03-31), which alone is 25.1% of the stale total — its close date is ~18 months out, so "stale" here may be a data-hygiene artifact rather than real neglect.
- No outreach text generated, per instruction.
SNAPSHOT 2026-09-05 · WINDOW: t_ds2 within 30 days => 2026-08-06 through 2026-09-05 inclusive Activity source: engagements_by_deal_90d.csv columns emails_30d / calls_30d / meetings_30d, summed across every open deal owned by the rep (all open deals, not just the ones that entered DS2). DATA GAPS (explicit) - Deal-3EED2C (Alex Franklin) and Deal-57FF13 (Elena Sinclair) have NO row in engagements_by_deal_90d.csv -> counted as 0 activities; this may understate those reps. - Deal-3EED2C still counts as a Alex Franklin DS2 entry (t_ds2 2026-09-03). - Elena Sinclair has 1 open deal, 0 activities, 0 DS2 entries -> ratio undefined (division by zero), excluded from ranking. - owner_id 1520255671 (Gavin Porter) and 77260721 (Hugo Lindqvist) are archived and own zero rows in deals_open.csv -> excluded. PER-REP TABLE Rep Emails Calls Meetings Total Mix (E/C/M) DS2-30d Activities per DS2 entry Alex Franklin (84342457) 307 36 41 384 79.9% / 9.4% / 10.7% 18 384 / 18 = 21.33 Bryce Harmon (119337721) 162 0 43 205 79.0% / 0.0% / 21.0% 4 205 / 4 = 51.25 Cole Ingram (83155924) 96 14 1 111 86.5% / 12.6% / 0.9% 2 111 / 2 = 55.50 Farid Osman (716654662) 38 0 34 72 52.8% / 0.0% / 47.2% 1 72 / 1 = 72.00 Dana Mercer (83155923) 84 18 11 113 74.3% / 15.9% / 9.7% 1 113 / 1 = 113.00 Elena Sinclair (701163055) 0 0 0 0 n/a (no activities) 0 undefined — excluded Arithmetic checks: 307+36+41=384; 162+0+43=205; 96+14+1=111; 38+0+34=72; 84+18+11=113. Deal counts 67+35+22+7+24+1 = 156 = all rows. Total activities 885, total DS2-30d entries 26 (18+4+2+1+1+0). RANKING (most -> least efficient, lowest activities per DS2 entry first) 1. Alex Franklin — 21.33 2. Bryce Harmon — 51.25 3. Cole Ingram — 55.50 4. Farid Osman — 72.00 5. Dana Mercer — 113.00 n/r Elena Sinclair — no DS2 entries, no recorded activities ANSWER - Most efficient rep: Alex Franklin — 21.33 activities per DS2 entry (384 activities / 18 DS2 entries). - Highest-volume rep: Alex Franklin — 384 activities (307 emails, 36 calls, 41 meetings), also the most emails and the most open deals (67 of 156). - They do NOT differ: the same rep is both most efficient and highest volume. No causal attribution is made here. DS2-30d entries counted per rep - Alex Franklin (18): Deal-403845, Deal-1FC049, Deal-3EED2C, Deal-7FA0C3, Deal-E531A6, Deal-5296C9, Deal-36C33F, Deal-EE195F, Deal-F436DA, Deal-317E6F, Deal-D1E6C2, Deal-D9A72E, Deal-CA5E44, Deal-4F775F, Deal-898FC5, Deal-46988D, Deal-E73427, Deal-92D97D - Bryce Harmon (4): Deal-25F752, Deal-CA7DC0, Deal-1CCE5C, Deal-D73B89 - Cole Ingram (2): Deal-1BA595, Deal-42326B - Farid Osman (1): Deal-499BF6 - Dana Mercer (1): Deal-57887A - Elena Sinclair (0) SENSITIVITY NOTE (no cause implied): I used "within 30 days" as <=30 days, which includes t_ds2 = 2026-08-06. A strict "<30 days" reading would drop 3 entries (Deal-1CCE5C from Bryce Harmon; Deal-EE195F and Deal-D9A72E from Alex Franklin), giving Alex Franklin 384/16 = 24.00 and Bryce Harmon 205/3 = 68.33; the top two ranks are unchanged, positions 3-4 would swap.
QTD SCORECARD — Alex Franklin
Quarter 2026-Q3 (Jul 1 – Sep 30, 2026) | As of 2026-09-05 | Quota $200,000 (quota.csv, snapshot 2026-09-05)
Scope: all 161 rows in ae_deals.csv are owned by Alex Franklin; all 161 deal_ids have a matching engagement row. No company names exist in the data — deals cited by alias only.
1. BOOKINGS VS QUOTA
Won deals in file: 9. Excluded 1 as pre-quarter:
Deal-B3E6F1 — $24,000 — closed 2026-06-20 (before 2026-07-01) → EXCLUDED
In-quarter wins (8), close_date 2026-07-01 to 2026-09-05:
Deal-A1C3E5 $40,000 2026-07-15
Deal-F2C7D8 $20,000 2026-07-24
Deal-B7D2F4 $35,000 2026-07-31
Deal-C9E1A6 $21,000 2026-08-12
Deal-A8B4D6 $12,000 2026-08-19
Deal-D4B8C2 $11,000 2026-08-21
Deal-E6F3A9 $6,500 2026-09-02
Deal-C5D9E2 $4,500 2026-09-03
Bookings = 40,000+20,000+35,000+21,000+12,000+11,000+6,500+4,500 = $150,000
Attainment = 150,000 / 200,000 = 75.0%
Gap to quota = 200,000 − 150,000 = $50,000
Pace check: 67 of 92 days elapsed (72.8%) → linear target $145,652; actual $150,000, so $4,348 ahead of straight-line but $50,000 short of quota with 25 days left.
2. NEW VS EXPANSION SPLIT
New: 5 deals, $113,500 → 113,500 / 150,000 = 75.7%
Expansion: 3 deals, $36,500 → 36,500 / 150,000 = 24.3%
Avg won deal = 150,000 / 8 = $18,750
3. ACTIVE PIPELINE BY STAGE (open deals only, 125 deals, $1,260,390)
Stage Deals Amount % of open $
DS1 20 $284,621 22.6%
DS2 28 $353,760 28.1%
DS3 67 $552,705 43.9%
DS4 5 $23,574 1.9%
DS5 5 $45,730 3.6%
TOTAL 125 $1,260,390 100.0%
Late-stage (DS4+DS5): 10 deals, $69,304 (5.5% of open pipeline)
Open deals with close_date on or before 2026-09-30: 22 deals, $109,363
(DS2 2/$5,760 · DS3 14/$69,399 · DS4 3/$7,644 · DS5 3/$26,560)
Coverage: $1,260,390 open / $50,000 gap = 25.2x total; $109,363 Q3-dated / $50,000 = 2.2x
One open deal is past its close date and still open: Deal-7A2454, $1,275, close_date 2026-09-04, DS3.
4. ROLLING 90-DAY DS2-TO-WON RATE
Window: entered_ds2 between 2026-06-07 and 2026-09-05 → cohort of 111 deals
(20 DS1 deals have a blank entered_ds2 and are not in the cohort)
Won in cohort: 8 → 8 / 111 = 7.21%
Cohort composition: 8 won, 27 lost, 76 still open
Decided-only view: 8 won / 35 decided = 22.86%
Caveat: 76 cohort deals are still open, so 7.21% is a floor, not a final conversion rate.
Avg days entered_ds2 → close on the 8 wins = 28.6 days (range 23–41). Avg on the 27 losses = 32.3 days.
5. WINS, LOSSES, TOP LOSS REASON
Wins (in quarter): 8
Losses: 27 — all 27 close dates fall between 2026-07-29 and 2026-09-02, i.e. all in-quarter
Win rate by count = 8 / (8+27) = 22.86%
Won $150,000 vs lost $329,272 → win rate by value = 150,000 / 479,272 = 31.3%
Avg won $18,750 · avg lost $12,195
Loss reasons (count / amount):
Lost- Timing (1 year or more) 13 $184,681 48.1% of losses / 56.1% of lost $
MIA 5 $45,831
Competitor 5 $49,020
Lost DM 2 $17,940
Feature Request 1 $21,000
Lost- Does not fit ICP (write in notes) 1 $10,800
TOTAL 27 $329,272
TOP LOSS REASON: Lost- Timing (1 year or more) — 13 of 27 losses (48.1%), $184,681 (56.1% of lost dollars). Avg deal in that bucket $14,206.
6. ACTIVITY VOLUME, LAST 30 DAYS
All 161 deals (won + lost + open):
Emails 807 (73.6%) · Meetings 128 (11.7%) · Calls 112 (10.2%) · Notes 50 (4.6%) → 1,097 total
Open pipeline only (125 deals):
Emails 599 (80.5%) · Meetings 90 (12.1%) · Calls 54 (7.3%) · Notes 1 (0.1%) → 744 total
Per open deal: 4.79 emails · 0.72 meetings · 0.43 calls · 0.01 notes
Same metric on closed outcomes, for contrast:
Per won deal (8): 11.12 emails · 3.88 calls · 2.88 meetings · 2.62 notes
Per lost deal (27): 4.04 emails · 0.93 calls · 0.48 meetings · 0.93 notes
82 of 125 open deals (65.6%) have zero meetings in the last 30 days — $892,785, or 70.8% of open pipeline value.
103 of 125 open deals (82.4%) have zero calls.
Deal-3EED2C (DS2, $7,200, close 2026-11-27) has 0 emails, 0 calls, 0 meetings, 0 notes — fully dark.
COACHING OBSERVATIONS
1. Every win this quarter had a phone and a meeting attached; most of the open pipeline does not. Won deals averaged 3.88 calls and 2.88 meetings in their last 30 days; lost deals averaged 0.93 and 0.48. The open book is running at 0.43 calls and 0.72 meetings per deal, and 82 of 125 open deals ($892,785) have no meeting at all. The behavior that produces wins is not the behavior currently being applied to the $1.26M book.
2. "Timing" is the real competitor, and the pipeline is aging into the same bucket. Lost- Timing (1 year or more) took 13 of 27 losses and $184,681 — more than MIA, Competitor, Lost DM, Feature Request and ICP combined on dollars. Meanwhile 29 open deals ($282,960) have been sitting in stage longer than 90 days, and Deal-7A2454 ($1,275) is already past its 2026-09-04 close date and still open. Deals are not being lost on price or product; they are stalling and then being written off.
3. Late-stage supply cannot cover the gap without a step-change in close rate. The remaining gap is $50,000 and only $109,363 of open pipeline carries a Q3 close date — 2.2x coverage. At the observed 22.86% decided win rate, that $109,363 converts to roughly $25,000, about half the gap. DS4+DS5 together hold just $69,304 across 10 deals, while $552,705 sits in DS3 (67 deals). The quarter will be decided by how much DS3 gets pushed to a decision in 25 days, not by the deals already late-stage.
Data gaps, stated explicitly: no company names, no deal age/created date, no stage-entry dates other than entered_ds2, no activity data before the 30-day window, and no prior-quarter quota or bookings — so no YoY or QoQ comparison is possible from these files.
SINGLE / UNDER-THREADED OPEN DEALS
Basis: deals_open.csv (280 open deals) + deal_contacts.csv (14 deals have contact rows) + unengaged_contacts.csv (9 companies)
Reference date 2026-09-04 = latest date anywhere in the data (max last_contacted_field). Active = last_engaged_date >= 2026-09-04 minus 60 days = 2026-07-06, AND is_former = false.
Coverage caveat: only 14 of 280 open deals have contact rows. The other 266 cannot be assessed — no contact data on file. Do not read this list as "all threading risk in the book."
RESULT: 11 of 14 assessable deals flagged. Flagged amount = 62,000+60,000+36,000+23,800+18,000+15,000+14,850+9,300+7,500+3,240+2,484 = $252,174.
single-threaded (<2 active): 5 deals
under-threaded (<3 active, or all contacts one persona): 6 deals
------------------------------------------------------------------
SINGLE-THREADED (active contacts < 2)
1. Deal-EC3025 | C-FDD0C7 | DS2 / PIPELINE | $62,000 | close 2026-12-10
Active: 1 — CT-047C54 (Head of Employee Experience, champion, 2026-09-02)
Personas present: champion. Missing: economic buyer, HR admin, IT security, finance.
Excluded: CT-F2C1AE (Chief People Officer, economic buyer, 2026-08-15) — is_former = true.
Add now: economic buyer. DS2 needs budget authority; the only EB on the record is former.
On file, unengaged, fits: CT-6827DB — Chief People Officer, economic buyer.
2. Deal-92D97D | C-E23238 | DS2 / PIPELINE | $60,000 | close 2026-12-28
Active: 1 — CT-01F5B4 (HRIS Manager, HR admin, 2026-08-28)
Personas present: HR admin. Missing: economic buyer, champion, IT security, finance.
Excluded: CT-A902AE (champion, 2026-06-01) — 2026-06-01 is 95 days before 2026-09-04, outside the 60-day window. Not former, just lapsed.
Add now: economic buyer. Only an HR admin is engaged; no business case owner and no champion.
On file, unengaged, fits: none for C-E23238.
3. Deal-36C33F | C-077A0E | DS2 / PIPELINE | $15,000 | close 2027-01-01
Active: 1 — CT-4FE556 (IT Security Lead, IT security, 2026-08-15)
Personas present: IT security. Missing: economic buyer, champion, HR admin, finance.
Excluded: CT-405B45 (champion, 2026-08-10, former) and CT-86B22F (economic buyer, 2026-07-30, former) — both is_former = true.
Add now: economic buyer. Threaded only into security with both the champion and the EB gone former — worst-shaped deal in the set.
On file, unengaged, fits: CT-1DB73E — Chief People Officer, economic buyer.
4. Deal-FCBE5B | C-737030 | DS2 / PIPELINE | $7,500 | close 2026-10-07
Active: 1 — CT-4A5317 (People Ops Manager, champion, 2026-08-29)
Personas present: champion. Missing: economic buyer, HR admin, IT security, finance.
Excluded: none — one contact row total.
Add now: economic buyer.
On file, unengaged, fits: none for C-737030.
5. Deal-F9A08A | C-0D15DF | DS4 / BEST_CASE | $2,484 | close 2026-09-15
Active: 1 — CT-931B10 (Head of Employee Experience, champion, 2026-09-03)
Personas present: champion. Missing: economic buyer, HR admin, IT security, finance.
Excluded: CT-913581 (Chief People Officer, economic buyer, 2026-06-20) — 76 days before 2026-09-04, outside window.
Add now: economic buyer. Best-case deal closing in 11 days with no engaged buyer — reactivate CT-913581 or open a new EB.
On file, unengaged, fits: CT-697541 — Chief People Officer, economic buyer.
------------------------------------------------------------------
UNDER-THREADED (3+ active but one persona, or <3 active)
6. Deal-50D386 | C-EB10E4 | DS2 / PIPELINE | $36,000 | close 2026-10-23
Active: 2 — CT-AA41B2 (champion, 2026-09-01), CT-B9C35B (HRIS Manager, HR admin, 2026-08-25)
Present: champion, HR admin. Missing: economic buyer, IT security, finance.
Add now: economic buyer.
On file, unengaged, fits: CT-A1C4B3 — Chief People Officer, economic buyer.
7. Deal-D0D6B5 | C-32918E | DS2 / PIPELINE | $23,800 | close 2026-10-23
Active: 3 — CT-87CED4, CT-DE6D7C, CT-FD70B2 (all champion: People Ops Manager, two Heads of Employee Experience; 2026-09-02 / 08-19 / 08-07)
Present: champion only. Missing: economic buyer, HR admin, IT security, finance.
Add now: economic buyer. Three contacts, one persona — count is not coverage.
On file, unengaged, fits: CT-1FA4DB — Chief People Officer, economic buyer.
8. Deal-5BFE3B | C-535D36 | DS2 / PIPELINE | $18,000 | close 2026-10-23
Active: 2 — CT-57123B (People Ops Manager, champion, 2026-08-31), CT-5CE757 (Head of Employee Experience, champion, 2026-08-12)
Present: champion only. Missing: economic buyer, HR admin, IT security, finance.
Add now: economic buyer. Deal created 2025-12-12 — 630+ days old and still two champions.
On file, unengaged, fits: none for C-535D36.
9. Deal-5408B0 | C-2AE3AA | DS4 / BEST_CASE | $14,850 | close 2026-11-20
Active: 2 — CT-D33AE4 (Head of Employee Experience, champion, 2026-09-01), CT-8742FD (HRIS Manager, HR admin, 2026-08-18)
Present: champion, HR admin. Missing: economic buyer, IT security, finance.
Add now: economic buyer. Late stage (DS4) with no signature authority engaged; finance is the second gap before signature.
On file, unengaged, fits: CT-07FA76 — Chief People Officer, economic buyer.
10. Deal-885F45 | C-5E8EFB | DS2 / PIPELINE | $9,300 | close 2026-11-20
Active: 2 — CT-51C81E (VP People, economic buyer, 2026-08-26), CT-D9A0E8 (People Ops Manager, champion, 2026-08-11)
Present: economic buyer, champion. Missing: HR admin, IT security, finance.
Add now: IT security. Business side is covered; the gate to DS3 is the security review.
On file, unengaged, fits: CT-B3F25D — IT Security Lead, IT security.
11. Deal-C6D97A | C-5A8FC2 | DS4 / BEST_CASE | $3,240 | close 2026-09-23
Active: 3 — CT-223DDC, CT-B03555, CT-4E8A2B (all champion; 2026-08-31 / 08-20 / 08-05)
Present: champion only. Missing: economic buyer, HR admin, IT security, finance.
Add now: economic buyer — best case closing in 19 days with zero non-champion coverage; finance next.
On file, unengaged, fits: none for C-5A8FC2.
------------------------------------------------------------------
NOT FLAGGED (assessable, adequately threaded)
Deal-84DBA6 | C-BE9BE0 | DS2 | $16,000 — 3 active: champion, economic buyer, IT security. Missing HR admin, finance. (Unengaged on file: CT-2A0169, Controller/finance.)
Deal-D348E1 | C-804F29 | DS5 / COMMIT | $13,770 — 5 active, all five personas present. No gaps.
Deal-4B0BEB | C-1BDFE0 | DS2 | $12,000 — 4 active: champion, economic buyer, HR admin, finance. Missing IT security only.
------------------------------------------------------------------
NOTES AND LIMITS
- Stage is reported as the DS1–DS5 code in deals_open.csv; no stage-name mapping was provided, so I did not translate DS2/DS3/DS4 into labels.
- Persona recommendation rule applied: DS1–DS2 → economic buyer first (business case + budget); DS3–DS5 → economic buyer if absent, then finance for signature/procurement. Deal-885F45 is the exception because EB and champion are both already engaged.
- 266 of 280 open deals have zero rows in deal_contacts.csv. Any deal not listed above is unassessable, not clean.
- Two on-file unengaged contacts were unused by any flagged deal's gap: CT-8E04F5 (C-804F29, HR admin) — that deal already has HR admin and all five personas; CT-2A0169 (C-BE9BE0, finance) — that deal is not flagged but finance is its gap.
GTM CALL REVIEW — Alex Franklin, last 10 calls (TT-001…TT-010, 2026-07-28 → 2026-09-03)
Source: transcripts.csv only. Deal aliases cited as given.
1. WHAT THE REP LEADS WITH (first five minutes)
8 of 10 calls open with the identical verbatim proof point at minute 0:
"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."
- Identical opener: TT-001, TT-002, TT-003, TT-005, TT-006, TT-007, TT-008, TT-010 = 8/10
- Only two variants: TT-004 "I put together a short agenda — security review first, then pricing." and TT-009 "You asked for straight pricing last time, so let's start there."
- One call adds a rep-raised competitor contrast inside the first five minutes: TT-005 at minute 2 (Workhuman).
- No discovery question from the rep appears in minutes 0–5 in any of the 10 calls.
2. THE THREE MOST COMMON OBJECTIONS AND HOW THEY'RE HANDLED
A. "Budget is locked" — 4 occurrences (TT-001, TT-003, TT-006, TT-010)
Quote: "Honestly, budget is locked until next fiscal year — I can't add a new line item right now."
Handling (same line all 4 times): "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."
Result: next step agreed in 3 of 4 (TT-001, TT-003, TT-006). TT-010 did not convert.
B. "Revisit next quarter" — 3 occurrences (TT-002, TT-005, TT-008)
Quote: "This is good, but can we revisit it next quarter? Open enrollment starts in October and we're underwater."
Handling (same line all 3 times): "Makes sense. What if we scope a 90-day pilot with one department so you have internal data before next quarter's planning?"
Result: next step agreed in 3 of 3.
C. "We already do this with a spreadsheet" — 3 occurrences (TT-004, TT-007, TT-009)
Quote: "We already do recognition with a spreadsheet and quarterly gift cards — why would we change?"
Handling (same line all 3 times): "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."
Result: next step agreed in 1 of 3 (TT-009 only). TT-004 and TT-007 did not convert.
Note on ranking: objections B and C are tied at 3 each. The next cluster is committee/stall language at 2 (TT-004 minute 11 "We need to see what the budget committee says before anything moves."; TT-010 minute 11 "We'll have to wait for the committee — I can't commit to anything today."), plus one no-urgency stall (TT-007 minute 14 "I need to think about it — there's no urgency on our side.").
3. CONCRETE NEXT STEP — RATE
The ask "Should we lock the next step — a working session with your team this week?" appears in 7 of 10 calls (TT-001, TT-002, TT-003, TT-005, TT-006, TT-008, TT-009).
Agreements: 7 of those 7, all with the identical line "Yes, Thursday at 2pm works — send the invite and I'll bring our HRIS manager."
Rate = 7 agreed / 10 calls = 70%
Ask-to-agreement = 7 / 7 = 100%
All 3 non-conversions (TT-004, TT-007, TT-010) are exactly the 3 calls where the rep never made the ask. In each, the rep closed with an acceptance line instead: "Understood — I'll leave it with you." (TT-004), "Fair enough." (TT-007), "Understood, thanks for the candor." (TT-010).
4. EVERY COMPETITOR A PROSPECT RAISED — 2, across 2 of 10 calls (20%)
- Awardco — TT-003, Deal-547B2B, minute 4: "We're also in late talks with Awardco — their rewards catalog looks bigger than yours." Rep answer: "Awardco's catalog is broad; where we win is automation and the analytics your HRIS team asked about."
- Kudos — TT-007, Deal-EDC141, minute 4: "How are you different from Kudos? Our CEO used them at her last company." Rep answer: "Kudos is solid on social recognition; our difference is automated milestones plus analytics tied to retention."
- Not prospect-raised: Workhuman appears in TT-005 (Deal-C61CF7) at minute 2, raised by Alex Franklin, not the prospect.
COACHING NOTES
1. The only objection with no business case attached is the one that fails. The spreadsheet answer (C) converts 1 of 3, while the two objections answered with a quantified or scoped reframe convert 6 of 7 (A: 3/4, B: 3/3). The C answer is a feature comparison — automation and analytics — with no dollar figure and no pilot ask, even though the $210k avoided-backfill proof and the 90-day pilot already exist in the rep's own language. Attach one of them to the spreadsheet answer and convert the stall into a scoped ask.
2. Every loss is an unasked close after a committee stall. Three calls (TT-004, TT-007, TT-010) ended with the prospect naming a committee or no urgency, and in all three the rep accepted and ended the call without asking for anything — 30% of the book, and 100% of the non-conversions. A committee stall is not a no; it is a request for a different artifact. Ask for the committee date and the material they need, then log it.
DATA CAVEATS (do not treat as findings)
- The 7 next-step agreements are byte-identical, including the same weekday and time ("Thursday at 2pm"), across 7 distinct deals on 7 different call dates. That pattern is implausible in live calls and suggests templated or duplicated transcript data; the 70% rate is computed as recorded and should be validated against the source system before it is used in a forecast.
- The dataset contains no company or deal names, only aliases (e.g. Deal-D348E1). No company-level or segment-level conclusions can be drawn.
- Objection frequency is counted per transcript occurrence of a line, not per distinct prospect phrasing; paraphrases of the same objection would not be captured.
Q3 2026 FORECAST — window 2026-07-01 to 2026-09-30
Extract: 86 deals total (close dates 2026-07-01 to 2026-10-15), pulled 2026-09-05.
In-quarter (close date inside 2026-07-01..2026-09-30): 54 deals. Outside: 32 deals.
--------------------------------------------------
COMMIT — in-quarter, weighted 100%
--------------------------------------------------
Deal-547B2B DS5 11,200 2026-09-11
Deal-B7EBD1 DS5 9,000 2026-09-10
Deal-403845 DS5 9,000 2026-09-11
Deal-A2B47C DS5 6,360 2026-09-11
Deal-2465CE DS5 5,400 2026-09-10
Deal-A5E80A DS1 2,520 2026-09-11
Deal-499BF6 DS2 1,249 2026-09-30
11,200 + 9,000 = 20,200
20,200 + 9,000 = 29,200
29,200 + 6,360 = 35,560
35,560 + 5,400 = 40,960
40,960 + 2,520 = 43,480
43,480 + 1,249 = 44,729
COMMIT TOTAL = 44,729.00 COUNT = 7
--------------------------------------------------
BEST_CASE — in-quarter, weighted 35%
--------------------------------------------------
38,935 (Deal-2D7423) -> 38,935
+ 24,000 (Deal-25F752) -> 62,935
+ 19,656 (Deal-E53952) -> 82,591
+ 16,250 (Deal-5EED42) -> 98,841
+ 11,116 (Deal-FA32A0) -> 109,957
+ 10,800 (Deal-FC22A3) -> 120,757
+ 10,500 (Deal-944310) -> 131,257
+ 9,890 (Deal-5195DB) -> 141,147
+ 9,720 (Deal-180D02) -> 150,867
+ 9,000 (Deal-3974EB) -> 159,867
+ 7,200 (Deal-5D8CEE) -> 167,067
+ 3,840 (Deal-9D0060) -> 170,907
+ 3,780 (Deal-46988D) -> 174,687
+ 3,600 (Deal-357C30) -> 178,287
+ 3,240 (Deal-C6D97A) -> 181,527
+ 3,150 (Deal-DAF1D9) -> 184,677
+ 3,120 (Deal-EE195F) -> 187,797
+ 3,060 (Deal-55164C) -> 190,857
+ 2,916 (Deal-001FF4) -> 193,773
+ 2,760 (Deal-7B3B0F) -> 196,533
+ 2,484 (Deal-F9A08A) -> 199,017
+ 2,100 (Deal-8952F0) -> 201,117
+ 1,920 (Deal-1FC049) -> 203,037
+ 528 (Deal-87412C) -> 203,565
BEST_CASE TOTAL = 203,565.00 COUNT = 24
--------------------------------------------------
PIPELINE — in-quarter, weighted 0% (counts zero)
--------------------------------------------------
PIPELINE TOTAL = 201,637.40 COUNT = 23 -> contributes 0.00
--------------------------------------------------
WEIGHTED FORECAST
--------------------------------------------------
COMMIT 44,729.00
BEST_CASE x 35% 203,565 x 0.35 = 71,247.75
(203,565 x 35 = 7,124,775; /100 = 71,247.75)
FORECAST = 44,729.00 + 71,247.75 = 115,976.75
WEIGHTED Q3 2026 FORECAST = 115,976.75
--------------------------------------------------
CATEGORY COUNTS (in-quarter only)
--------------------------------------------------
COMMIT 7 deals 44,729.00
BEST_CASE 24 deals 203,565.00
PIPELINE 23 deals 201,637.40 (excluded from forecast by rule)
TOTAL 54 deals 449,931.40
--------------------------------------------------
EXCLUDED — close date outside 2026-07-01..2026-09-30
--------------------------------------------------
COUNT = 32 TOTAL AMOUNT = 227,575.00
By category: BEST_CASE 9 deals / 28,240.00; COMMIT 1 deal / 13,770.00;
PIPELINE 22 deals / 185,565.00
Deal-E51FB7 43,875 PIPELINE 2026-10-01
Deal-5FDCE4 1,600 BEST_CASE 2026-10-01
Deal-7FA0C3 1,400 PIPELINE 2026-10-01
Deal-600CD9 5,400 PIPELINE 2026-10-02
Deal-FCBE5B 7,500 PIPELINE 2026-10-07
Deal-8AD4A5 1,800 BEST_CASE 2026-10-07
Deal-9F2E43 7,690 PIPELINE 2026-10-08
Deal-ED725A 2,400 BEST_CASE 2026-10-08
Deal-F5A622 1,080 BEST_CASE 2026-10-08
Deal-B936FE 18,000 PIPELINE 2026-10-09
Deal-293AF3 9,000 PIPELINE 2026-10-09
Deal-C61CF7 5,400 BEST_CASE 2026-10-09 (DS5 but not COMMIT)
Deal-D1E6C2 4,400 PIPELINE 2026-10-09
Deal-D9E112 4,300 PIPELINE 2026-10-09
Deal-47AE31 3,600 BEST_CASE 2026-10-09
Deal-15D24F 3,600 BEST_CASE 2026-10-09
Deal-ED13B0 1,680 PIPELINE 2026-10-09
Deal-766C74 3,300 PIPELINE 2026-10-14
Deal-D9A12F 17,000 PIPELINE 2026-10-15
Deal-D348E1 13,770 COMMIT 2026-10-15
Deal-4062CF 10,800 PIPELINE 2026-10-15
Deal-034D49 9,000 PIPELINE 2026-10-15
Deal-E0ADD8 7,920 PIPELINE 2026-10-15
Deal-712010 7,200 PIPELINE 2026-10-15
Deal-6691E0 5,700 PIPELINE 2026-10-15
Deal-A92065 5,400 PIPELINE 2026-10-15
Deal-1D532E 5,400 PIPELINE 2026-10-15
Deal-48B656 5,160 BEST_CASE 2026-10-15
Deal-E531A6 4,800 PIPELINE 2026-10-15
Deal-5AD94B 4,000 PIPELINE 2026-10-15
Deal-901332 3,600 BEST_CASE 2026-10-15
Deal-D7E999 1,800 PIPELINE 2026-10-15
Note: Deal-D348E1 (13,770, COMMIT, DS5) is the single largest forecast-relevant
exclusion — it is COMMIT but closes 2026-10-15, i.e. Q4, so it contributes 0.
--------------------------------------------------
TOP 5 BEST_CASE IN-QUARTER BY AMOUNT
--------------------------------------------------
1. Deal-2D7423 38,935 2026-09-30 DS3
2. Deal-25F752 24,000 2026-09-25 DS4
3. Deal-E53952 19,656 2026-09-30 DS4
4. Deal-5EED42 16,250 2026-09-30 DS3
5. Deal-FA32A0 11,116 2026-09-25 DS3
Subtotal = 38,935 + 24,000 + 19,656 + 16,250 + 11,116 = 109,957
That is 109,957 / 203,565 = 54.0% of all in-quarter BEST_CASE dollars, so half
the weighted upside (0.35 x 109,957 = 38,484.95, i.e. 33% of the total forecast)
rests on five deals, four of which sit in DS3 or DS4, and one of which
(Deal-2D7423, 38,935 = 19% of BEST_CASE) is only DS3 and closes on the last day.
## Data quality
The owner field is blank on 85 of 86 rows (only Deal-C9C286 carries "Bryce Harmon"), so the forecast cannot be attributed, rolled up, or challenged by rep. Forecast category contradicts stage throughout: COMMIT appears at DS1 (Deal-A5E80A, 2,520) and DS2 (Deal-499BF6, 1,249), BEST_CASE appears at DS5 (Deal-C61CF7, 5,400), and PIPELINE appears at DS4 (Deal-6787C2, 7,000) — the 100%-weighted COMMIT bucket is therefore not reliably "late stage". Qualification evidence is absent for most of the number: why_buys_chars is 0 on 71 of 86 rows, including 22 of the 24 in-quarter BEST_CASE deals, so 203,565 of BEST_CASE is asserted, not evidenced. Finally the close dates are not credible as a schedule: 17 of 54 in-quarter deals all close on 2026-09-30, there are zero July closes and only one August close in an extract whose stated window starts 2026-07-01, and four in-quarter records already have close dates in the past as of the 2026-09-05 pull (Deal-333EBB 2026-08-28, Deal-57FF13 2026-09-02, Deal-31AD2C 2026-09-04, Deal-7A2454 2026-09-04) — stale rows that will silently re-enter the forecast until someone closes or re-dates them.
Data parsed from the 220-row extract (signup months 2023-01 through 2023-07). Retention = current_status = 'active'. Arithmetic below. 2x2 — ACTIVATION SIGNALS vs 24-MONTH RETENTION (n=220) cell n retained rate both (m1_users>=5 AND red>=1) 47 31 66.0% (31/47) givers only (users>=5, red=0) 49 23 46.9% (23/49) redemption only (red>=1, u<5) 29 9 31.0% (9/29) neither 95 38 40.0% (38/95) ------------------------------------------------------ total 220 101 45.9% (101/220) Lift vs the "neither" baseline of 40.0%: both +26.0 pp givers only +6.9 pp redemption only -9.0 pp Pairwise: both beats givers-only by 19.0 pp; givers-only beats redemption-only by 15.9 pp. EXCLUSIONS: zero. All 220 rows have non-missing m1_users and m1_redemptions, and per your premise every company is 25+ months old, so no row is dropped for insufficient observation window. One judgement call, not an exclusion: 'non_renewing' (3 companies — C-0B2078FB, C-0A96134F, C-0BEAF685) is counted as NOT retained. If you instead count them as retained, redemption-only moves 9/29 -> 11/29 = 37.9% and neither moves to 41.1%; the ordering of all four cells is unchanged. LARGEST SINGLE-SIGNAL LIFT: the givers signal (m1_users >= 5). It is the strongest single signal on both readings: - one-signal-only cells: givers-only 46.9% vs redemption-only 31.0% = +15.9 pp for givers - marginal (signal present regardless of the other): users>=5 = 54/96 = 56.2% (+16.2 pp vs neither); redemptions>=1 = 40/76 = 52.6% (+12.6 pp vs neither) Redemption as a standalone signal is actively negative in this extract: -9.0 pp vs neither. WHAT IT PROVES — and the big caveat It does show a real ordering in the raw data: both-signals companies retain at 66.0% vs 40.0% for neither, and that gap is unlikely to be noise in the pooled sample (Fisher exact, both vs neither, two-sided p = 0.0044). It does NOT establish that activation drives retention, because the 2x2 is badly confounded by product_tier, which is almost perfectly collinear with the outcome in this extract: - tier_two: 0 of 97 retained (0.0%), and all 97 have current_arr_usd = 0 - tier_three: 98 of 120 retained (81.7%) - tier_alpha: 3 of 3 retained The "both" cell is 70% tier_three while "neither" is 48% tier_three — so part of the +26.0 pp is just tier mix. Holding tier constant (tier_three only, n=120), the headline effect collapses and even flips rank: both 30/33 = 90.9% givers only 22/23 = 95.7% redemption only 8/18 = 44.4% neither 38/46 = 82.6% both vs neither: +8.3 pp, p = 0.34 (not significant) givers only vs neither: +13.0 pp, p = 0.25 (not significant) both vs givers only: -4.8 pp, p = 0.64 (not significant) redemption only vs neither: -38.2 pp, p = 0.0045 (significant, NEGATIVE) So within tier_three the only statistically solid finding is that redemption-without-givers is a churn risk, not that either signal lifts retention. Adding redemptions on top of 5+ givers adds nothing measurable (+8.3 pp for both vs +13.0 pp for givers-only, and both vs givers-only p = 0.64). What is definitively NOT proven: - Causation. This is a retrospective cohort split; companies that got 5+ givers in month one differ in size, tier, and country mix from those that did not. Nothing here randomizes or controls for that. - That driving redemptions improves retention. The redemption-only cell is the worst performer in both the pooled and tier-controlled cuts. - Anything about tier_two. Zero of 97 tier_two companies are active, so tier is a near-deterministic label here, not an independent variable you can adjust away cleanly. - Anything about cohorts past 2023-07, or about the m3 columns. Note a data-quality flag: several rows carry m3_users = 0 alongside non-zero m3_gives (e.g. C-0DD506E9 has m3_users = 0, m3_gives = 139), so m3_users looks unreliable. That does not affect the m1 bucketing above, but I would not build an m3 version of this test until that field is fixed. If you want a defensible version of this test, the next step is to stratify by tier from the start (or restrict to tier_three only), and use m1_gives-per-user rather than raw m1_users, since m1_gives/m1_users varies from 0.07 to 59 in this extract.
## ARR reconciliation — as of 2026-09-05
Basis: Billing ARR = MRR × 12, one subscription per company (39 subs, 39 billing companies, 39 CRM records).
TOTALS
Billing ARR, all statuses (39 subs) 617,897.76
Billing ARR, active only (37 subs) 604,739.28
CRM (HubSpot) ARR (39 records) 603,581.76
Arithmetic:
All-status variance = 617,897.76 − 603,581.76 = 14,316.00
Active-only variance = 604,739.28 − 603,581.76 = 1,157.52
I use the ACTIVE basis as the reconciling variance, because the "status mismatch" bucket only exists on that basis — under the all-status basis the two cancelled subscriptions cancel out exactly and contribute 0. On the all-status basis the whole 14,316.00 reduces to the same three non-status buckets below.
DECOMPOSITION (active basis) — must sum to 1,157.52
Status mismatch −13,158.48
Missing records +11,952.00
Rounding −36.00
Other +2,400.00
------------------------------
Total +1,157.52 ✓
Bucket detail:
Status mismatch (−13,158.48): cancelled in billing but still carrying ARR in CRM.
C-0C8323BF SUB-000E 408.77 × 12 = 4,905.24 (billing active = 0)
C-0DC4FB8C SUB-000F 687.77 × 12 = 8,253.24 (billing active = 0)
Sum = 4,905.24 + 8,253.24 = 13,158.48
Missing records (+11,952.00 net):
Billing-only C-21629AA4 (SUB-0004): 2,370.77 × 12 = 28,449.24, no CRM record → +28,449.24
CRM-only C-0D5BBE3A: 16,497.24, no subscription → −16,497.24
Net = 28,449.24 − 16,497.24 = +11,952.00
Rounding (−36.00):
C-0D66DF9E 1,932.00 × 12 = 23,184.00 vs CRM 23,200.00 → −16.00
C-14D70CE0 1,515.00 × 12 = 18,180.00 vs CRM 18,200.00 → −20.00
Other (+2,400.00): C-0F7269D7 2,233.00 × 12 = 26,796.00 vs CRM 24,396.00 → +2,400.00. No term, status, or count difference explains it; treat as unexplained CRM entry variance requiring source review.
MISMATCHED ACCOUNTS + SUGGESTED OWNER
(No owner field exists in either file — these are functional owners by exception type, not named people.)
C-0C8323BF 4,905.24 cancelled sub, ARR still live in CRM → Billing Ops (confirm cancel effective date) + CRM Data Steward to zero ARR
C-0DC4FB8C 8,253.24 cancelled sub, ARR still live in CRM → Billing Ops + CRM Data Steward
C-21629AA4 28,449.24 billing-only, no CRM company record → CRM Data Steward (create/link company record)
C-0D5BBE3A 16,497.24 CRM-only, no billing subscription → Deal Desk / Billing Ops (confirm churn or missing sub import)
C-0F7269D7 2,400.00 MRR × 12 exceeds CRM ARR → Account Owner / Deal Desk (reconcile to signed order form)
C-0D66DF9E −16.00 rounding (23200 vs 23184) → CRM Data Steward (low priority)
C-14D70CE0 −20.00 rounding (18200 vs 18180) → CRM Data Steward (low priority)
TERM-LENGTH BUSINESS RULE VIOLATIONS
Rule: term_months ≠ 12 requires cf_agreement_end_date populated.
VIOLATIONS (2):
SUB-0002 C-1794A52C term 24 active cf_agreement_end_date = (empty)
SUB-0019 C-22170CA1 term 36 active cf_agreement_end_date = (empty)
COMPLIANT non-12-month subs (2):
SUB-000C C-0DB48281 term 24 active 2027-11-30
SUB-001A C-0FC4DBB8 term 36 active 2027-11-30
Of 39 subscriptions, 4 have term ≠ 12 (24/24/36/36 months); 2 of 4 pass the rule.
DATA GAP NOTED: neither file contains an account-owner, AE, or segment field, so owner assignment above is functional only; a named owner requires a source not provided.
Method: unweighted mean of all 30 company rows per month (10 smb, 10 mid_market, 10 enterprise; every row is plan_tier = tier_three, so plan_tier cannot discriminate anything). | KVM | 2026-07 | 2026-08 | Abs Δ | Rel Δ | Direction | |---|---|---|---|---|---| | Giving rate | 0.6023 | 0.6027 | +0.0004 | +0.07% | up (flat) | | Redemptions/user | 1.7300 | 1.7302 | +0.0002 | +0.01% | up (flat) | | 1:1 meetings eng. | 0.4469 | 0.4472 | +0.0003 | +0.06% | up (flat) | | Pulse check eng. | 0.6006 | 0.5086 | -0.0920 | -15.31% | down | Largest relative move: pulse check engagement, -15.31% (0.5086 - 0.6006 = -0.0920; -0.0920 / 0.6006 = -15.31%). Segment driving it: size_band = enterprise. Enterprise pulse engagement fell 0.5500 → 0.2743 (-0.2757, -50.13%) while smb moved -0.22% (0.6588 → 0.6573) and mid_market +0.21% (0.5930 → 0.5942). The decline is not a single account — all 10 enterprise companies fell roughly in half (e.g. C-0B2895EF 0.5619 → 0.2864; C-0D0B047C 0.5398 → 0.2619), so this reads as a uniform enterprise-level step change, not one outlier. Data gap: no plan_tier variation exists to test, and the file carries no user counts, so these are company-level averages, not user-weighted. Also no cause field — I cannot attribute the enterprise drop beyond stating it.
REDEMPTIONS — WEEKLY REWARDS REPORT Period: YTD 2026-01-01 through 2026-08-31 Last completed month: 2026-08 (August). Data ends 2026-08-31T11:53:00 with no records after that date. Source: /Users/amaniphipps/redemptions_ytd.csv — 377 rows, 2026-01-01 → 2026-08-31. No duplicate redemption_id, no blank fields, no user_key spanning two company_alias values. Note on source completeness: redemptions_ytd.csv (377) is a strict subset of redemptions_full.csv (378) — identical values on all shared IDs, plus one row present only in the full file (RD-402F91, C-0EC6999D, 2026-06-24, Tremendous, $10.00, US). Figures below use the file specified (377 rows); including the extra row would give 378 redemptions, $27,846.00, 235 redeemers, 1.61 per redeemer. HEADLINE METRICS (YTD Jan–Aug 2026) Redemption count ........ 377 Spend ................... $27,836.00 Unique redeemers ........ 234 Redemptions per redeemer 1.61 (377 / 234 = 1.6111) Avg redemption value .... $73.84 (27,836 / 377) Spend per redeemer ...... $118.96 (27,836 / 234) PROVIDER MIX — PERCENT OF SPEND (shares sum to 100.0) Provider Spend Count % of spend custom $10,873.00 37 39.1% Tremendous $ 8,495.00 191 30.5% Snappy $ 5,238.00 59 18.8% TangoCard $ 3,230.00 90 11.6% TOTAL $27,836.00 377 100.0% Arithmetic: 10,873/27,836 = 39.0609%; 8,495/27,836 = 30.5180%; 5,238/27,836 = 18.8174%; 3,230/27,836 = 11.6037%. Sum of unrounded = 100.0000%. Rounded to one decimal these are 39.1 / 30.5 / 18.8 / 11.6 = 100.0 (largest-remainder rounding; custom is the only line nudged upward, by 0.039pp). custom is 9.8% of redemptions (37/377) but 39.1% of spend — average $293.86 vs $44.48 for Tremendous, $88.78 for Snappy, $35.89 for TangoCard. TOP 5 COUNTRIES BY REDEMPTIONS Rank Country Count % of 377 Spend 1 US 243 64.5% $18,537.00 2 CA 24 6.4% $ 2,286.00 3 AU 21 5.6% $ 1,606.00 4 NL 17 4.5% $ 1,122.00 4= GB 17 4.5% $ 944.00 6 SG 12 3.2% $ 1,048.00 GB and NL are tied at 17 redemptions each; the tie is broken for the #4 slot by spend (NL $1,122 > GB $944). If you prefer a different tiebreak (e.g. earliest activity), say which and I'll re-rank. MONTHLY TRAIL (for context) 2026-01 45 $3,932 2026-02 36 $2,731 2026-03 50 $2,918 2026-04 52 $3,876 2026-05 43 $2,825 2026-06 45 $2,763 2026-07 58 $5,255 2026-08 48 $3,536 August alone: 48 redemptions, $3,536.00, 46 unique redeemers, 1.04 per redeemer — provider mix Tremendous 32.4% / custom 29.9% / Snappy 23.6% / TangoCard 14.1%. MISSING DATA / CAVEATS - Only one file was specified; no prior-year or September data provided, so no YoY or MoM-vs-September comparison is possible. - No September 2026 records exist in the file, confirming 2026-08 as the last completed month. - Segment splits beyond provider and country (by company_alias, by redeemer tenure, by reward type) were not requested and are not shown.
ELIGIBILITY GATE (3 rules, applied in order)
Snapshot = 2026-09-05. R3 "within_days 120" -> cutoff = 2026-09-05 + 120 = 2027-01-03.
Sep 5->30 = 25, +Oct 31 = 56, +Nov 30 = 86, +Dec 31 = 117, +3 = 120 -> 2027-01-03.
(All renewal_date values in the file are after the snapshot, so a one-sided vs. two-sided
+/-120 reading gives the identical result set.)
R1 health_score < 60 ......... 15 of 30 accounts pass
R2 churn_save_eligible_amount > 0 ... 10 of those 15 pass (5 have amount = 0.00)
R3 renewal_date <= 2027-01-03 ....... 8 of those 10 pass
QUALIFYING: 8 accounts.
--------------------------------------------------------------------------------
QUALIFIED - AMOUNT AT STAKE AND PLAY
--------------------------------------------------------------------------------
ALIAS HEALTH ARR AT STAKE RENEWAL DAYS TREND UTIL CHAMP
C-0F6C0F34 51 86,741.00 49,707.00 2026-10-03 28 growing 78.0% false
C-0B827671 56 72,088.00 25,365.00 2026-11-14 70 declining 55.9% true
C-0B360C78 57 60,427.00 35,748.00 2026-10-28 53 growing 75.2% true
C-0B0F1BAB 38 15,391.00 5,494.00 2026-09-23 18 flat 65.6% false
C-0CA21961 58 31,501.00 16,829.00 2026-12-28 114 flat 25.8% true
C-0E9C27D1 39 75,093.00 41,235.00 2026-09-24 19 flat 85.4% true
C-0CEF69FD 53 79,324.00 32,621.00 2026-11-21 77 growing 71.3% false
C-0D3278C7 54 33,815.00 17,602.00 2026-11-12 68 declining 33.2% true
UTIL = seats_used / seats. DAYS = renewal_date - 2026-09-05.
TOTAL AT STAKE (churn_save_eligible_amount)
49,707 + 25,365 = 75,072
75,072 + 35,748 = 110,820
110,820 + 5,494 = 116,314
116,314 + 16,829 = 133,143
133,143 + 41,235 = 174,378
174,378 + 32,621 = 206,999
206,999 + 17,602 = 224,601
TOTAL = $224,601.00 (combined ARR of these 8 = $454,380.00)
IMPORTANT CAVEAT ON PLAYS: the three files provided contain no playbook defining
"usage revival", "executive touch", or "commercial concession" - no thresholds,
no rule_ids, no mapping. The eligibility rules (R1-R3) only decide WHO qualifies.
The play assignment below is therefore MY stated inference from the only signals
the data carries, not a documented rule. Stated priority:
(1) champion_active = false -> EXECUTIVE TOUCH (no internal advocate to
run a save motion; need a sponsor)
(2) usage_trend_3m = declining OR
seat utilization < 50% -> USAGE REVIVAL (adoption decay)
(3) remaining: healthy/growing
usage + active champion -> COMMERCIAL CONCESSION (risk is not
adoption; it is commercial)
PLAY ASSIGNMENT AND JUSTIFYING SIGNAL
EXECUTIVE TOUCH - $87,822.00 at stake (ARR $181,456.00)
C-0F6C0F34 $49,707.00 signal: champion_active = false. Usage is growing and
utilization is 78.0% (308/395), so the risk is not adoption - there
is no active champion to carry the renewal internally. Health 51.
Renewal in 28 days.
C-0CEF69FD $32,621.00 signal: champion_active = false. Usage growing,
utilization 71.3% (97/136). Same pattern: healthy product use,
no advocate. Health 53. Renewal in 77 days.
C-0B0F1BAB $5,494.00 signal: champion_active = false AND health_score = 38
(lowest in the qualified set) AND renewal in 18 days - the most
time-compressed account in the file. Utilization 65.6% (238/363),
trend flat, so adoption alone does not explain a 38.
USAGE REVIVAL - $59,796.00 at stake (ARR $137,404.00)
C-0B827671 $25,365.00 signal: usage_trend_3m = declining. Utilization
55.9% (113/202) - 89 seats paid and unused. Health 56.
C-0D3278C7 $17,602.00 signal: both - usage_trend_3m = declining AND
utilization 33.2% (126/380), the lowest utilization in the
qualified set; 254 seats unused. Health 54.
C-0CA21961 $16,829.00 signal: utilization 25.8% (84/325) despite a flat
trend - 241 seats unused, the single largest absolute seat gap
among qualified accounts. Health 58. Renewal in 114 days,
so there is runway to run a revival motion before the gate closes.
COMMERCIAL CONCESSION - $76,983.00 at stake (ARR $135,520.00)
C-0E9C27D1 $41,235.00 signal: utilization 85.4% (134/157) with a flat trend
and active champion - the account is using the product heavily and
still sits at health 39 (second-lowest qualified). Adoption is not
the problem; the risk reads as commercial/structural.
C-0B360C78 $35,748.00 signal: usage_trend_3m = growing, utilization 75.2%
(246/327), champion_active = true, yet health 57. All adoption
signals are positive, leaving price/terms as the remaining lever.
Check: 87,822 + 59,796 + 76,983 = 224,601. ✓ (ARR 181,456 + 137,404 + 135,520 = 454,380 ✓)
--------------------------------------------------------------------------------
AT RISK (health < 60) BUT NOT QUALIFIED - 7 ACCOUNTS
--------------------------------------------------------------------------------
FAILS R2 - churn_save_eligible_amount = 0.00 (passes R1 and R3, but nothing is
funded; these are the loudest data gap in the file: $132,551.00 of ARR renewing
inside 120 days with zero eligible amount)
C-0BC71BDD health 55, ARR $54,515.00, renewal 2026-10-27 (52 days), flat,
util 29.9% (59/197), champion false
C-0BE96399 health 54, ARR $52,319.00, renewal 2026-10-29 (54 days), declining,
util 27.9% (43/154), champion true
C-10A56B0F health 54, ARR $25,717.00, renewal 2026-12-12 (98 days), declining,
util 48.3% (85/176), champion false
Sum ARR: 54,515 + 52,319 + 25,717 = $132,551.00 - at risk, unfunded.
FAILS R3 - renewal beyond 2027-01-03 (passes R1 and R2)
C-0F876796 health 47, at stake $19,958.00, renewal 2027-02-06 = 154 days out
(34 days past the 120-day gate). Declining, util 23.2% (22/95).
C-0BA71F12 health 52, at stake $6,824.00, renewal 2027-04-11 = 218 days out
(98 days past the gate). Declining, util 23.5% (23/98).
FAILS BOTH R2 AND R3
C-0F6694C3 health 43, amount $0.00, renewal 2027-03-21 = 197 days out
C-0FCCD2DF health 43, amount $0.00, renewal 2027-04-23 = 230 days out
Not at risk at all (excluded by R1, health 60-88): the remaining 15 accounts in
the file, several with $0.00 eligible amount (e.g. C-8C2E8F00 health 73,
C-14264ABD health 87). Out of scope for this question.
--------------------------------------------------------------------------------
WHAT THE DATA DOES NOT SUPPORT
--------------------------------------------------------------------------------
- No playbook file was supplied, so the play-to-account mapping above is an
inferred heuristic, not a documented rule. If a documented mapping exists, rerun.
- No rule was supplied for ordering the plays by urgency; I used days-to-renewal
only as a tiebreaker note, not as an eligibility input.
- No contact, opportunity, or prior-save-history data is present, so "executive
touch" cannot be checked against whether an exec relationship already exists.
- The 5 accounts with churn_save_eligible_amount = 0.00 cannot be explained from
this file - entitlement, contract exclusion, or missing data are all possible.
EXPANSION KIT — C-0DDFC9A7 1. SEAT COVERAGE Licensed 150 / headcount 400 = 0.375 → 37.5% coverage Unlicensed employees: 400 - 150 = 250 2. USAGE HEALTH (two lines) MAU grew every month, +7/+7/+8/+8/+8 MoM: 88 → 126 across Mar–Aug 2026 = +38 users, +43.2% (38 / 88 = 0.4318) over 5 months, avg +7.6/mo. Aug MAU is 126 / 150 licensed = 84.0% of paid seats — at the recent +8/mo pace the account hits its 150-seat ceiling in ~3 months (Sep 134, Oct 142, Nov 150). 3. HEADROOM Per-seat rate: $9,000 / 150 = $60.00 per seat per year Seat headroom: 250 seats → 250 x $60 = $15,000 incremental ARR Full-coverage ARR: 400 x $60 = $24,000 (2.67x current $9,000) Note: assumes flat $60/seat; no volume-discount or tier data provided, so this is the ceiling case, not a forecast. 4. WHO REPLIED / CAN THEY BUY Maria S., People Operations Coordinator, last engaged 2026-09-02 (reply date = day 0). Cannot buy — she states it directly: "I'm not the right person for purchasing decisions here. Budget and seat expansion sit with Dana R., our VP People." She can influence and has offered an intro. 5. RIGHT BUYER FROM CONTACTS Dana R., VP People — correct by role (owns budget + seat expansion per Maria). Problem: last engaged 2026-05-18 = 107 days before this reply, so she is NOT an active contact under the 60-day threading rule. No buying-level contact is currently active. Sam K., Office Manager, last engaged 2025-11-03 = 303 days stale, and Office Manager is not a budget/seat persona. Not a viable path. Gap to close: reactivate Dana directly or route through Maria, who is active today. 6. REPLY EMAIL (118 words) Subject: RE: Growing your team's recognition program Thanks Maria — glad to hear the team loves it. One number that stood out: monthly active users went from 88 in March to 126 in August — 38 more people, 43% growth. At that pace you're roughly three months from your 150-seat ceiling, so it's worth getting ahead of before it turns into a scramble. You mentioned Dana has been asking about usage numbers. I'd welcome that intro. I can put together a one-page usage summary she can use on her own — no pitch attached. And if it's easier, I'm happy to send the summary to you first and let you decide how it lands. Would the intro to Dana work, or would you rather I start with the summary to you? Best, Cole Data gaps: no renewal date, no contract term, no product-tier or discount schedule, no departmental breakdown of the 250 unlicensed employees, and no opportunity/deal record — so ARR headroom above is arithmetic on the supplied rate, not a pipeline figure.
ACCOUNT: C-0D284E42 | signup 2026-08-11 | usage data 2026-08-11 → 2026-09-04 (25 daily rows)
WHAT IS COMPLETE (each backed by a populated field)
Integration: Slack integration_slack = 2026-08-12 day 2 after signup
Allowance set allowance_set = 2026-08-13 day 3
Admins added admins_added = 2 value present (no target given to compare against)
First recognition given first_recognition_at = 2026-08-15 14:22 day 5
WHAT IS NOT COMPLETE
HRIS integration integration_hris = blank no date, nothing else in the data implies it
First redemption first_redemption_at = blank zero redemptions recorded through 2026-09-04
Arithmetic on the gap: first recognition 2026-08-15 → last data day 2026-09-04 = 20 days of recognition activity with no redemption on record.
EARLY ENGAGEMENT SIGNALS
Coverage: activity on all 25 of 25 days. No zero days. Min 3, max 15 (5.0x).
Total giver-days: 3+3+4+4+5+4+7+5+7+6+9+8+9+9+9+11+10+10+11+13+11+13+13+15+15 = 214
Mean: 214 / 25 = 8.56 active givers/day. Median (13th of 25 sorted) = 9.
Trajectory:
Week 1 (08-11→08-17): 3+3+4+4+5+4+7 = 30 30/7 = 4.29/day
Prior 7 (08-22→08-28): 8+9+9+9+11+10+10 = 66 66/7 = 9.43/day
Last 7 (08-29→09-04): 11+13+11+13+13+15+15 = 91 91/7 = 13.00/day
Week 1 → last 7: 13.00 - 4.29 = +8.71/day; 91/30 = 3.03x (+203%)
Prior 7 → last 7: 13.00 - 9.43 = +3.57/day (+37.8%) — still accelerating, not plateaued
Durability: weekend days (Sat/Sun = 08-15/16, 08-22/23, 08-29/30) read 5, 4, 8, 9, 11, 13 — all non-zero and rising in step with weekdays. Engagement is not weekday-only.
WHAT THE DATA DOES NOT SUPPORT (do not assert these on the call)
- No headcount or eligible-user count in either file → no participation rate, no % of company giving. Cannot say the program is "broadly adopted."
- No unique giver IDs → "active_givers" is a daily count, not distinct people. 3.03x growth could be the same core group giving more. Cannot compute repeat-giver rate or retention.
- Only one recognition timestamp exists (the first) → cannot compute recognitions per giver or recognitions per day.
- No redemption catalog, point balances, or allowance amount/period data → cannot diagnose why redemption is blank (no rewards configured vs. not yet used vs. field not populated).
- Data ends 2026-09-04; 09-05 through 09-08 are absent, so the file is 4 days stale as of today.
- Single account row only → no peer or cohort benchmark for any of these numbers.
THREE THINGS TO COVER ON THE CALL
1. HRIS integration — the one unfinished setup item. It is the only field in onboarding_account.csv still blank besides redemption, and it gates roster sync and allowance upkeep. Get a date on the call.
2. Redemption — 20 days since first recognition (2026-08-15) with first_redemption_at still blank. Points are moving; nothing is being cashed in. Confirm whether a reward catalog is actually live, or whether the field is simply unpopulated, before treating this as a real adoption problem.
3. Turn giver growth into verified breadth — 4.29 → 13.00 givers/day is the strongest signal in the data, but it is unverified breadth. Confirm total eligible users and unique-giver count so the 3x can be stated as penetration rather than a small core group going harder, then set the next milestone against a real denominator.
## 90-DAY RENEWAL RISK BRIEF Prepared as of 2026-09-08 (latest usage month in data = 2026-08). 90-day window closes 2026-12-07 — all 20 renewals fall inside it. **Data gap, stated up front:** the files contain `account_alias` only. There is no company name field anywhere in the provided data, so "company" below is the alias exactly as given. Do not read these as company names — they are opaque IDs. --- ### 1. SYSTEM ARBITRATION — WHICH DATE I TRUST Rule applied: **where `is_multi_year = true` (Chargebee), trust Chargebee. Elsewhere trust ChurnZero.** This follows your stated known defect (multi-year contracts are wrong in ChurnZero) and is the only defensible split, since for all 15 single-year accounts (`term_months = 12`) the two systems agree to the day — there is no conflict to arbitrate there. All 5 disagreements are on the 5 multi-year accounts. ChurnZero is wrong on all 5: ``` ALIAS TERM CHURNZERO CHARGEBEE DELTA CZ ERROR PATTERN C-0B7D2C30 36 2026-09-10 2026-09-15 +5d stale/default date (see note) C-0BCDB8C2 36 2027-09-18 2026-09-18 +365d off by exactly one year C-0D2AB865 24 2026-09-10 2026-09-22 +12d stale/default date C-0BBE3E60 24 2027-09-26 2026-09-26 +365d off by exactly one year C-0F5D2323 24 2026-09-10 2026-09-29 +19d stale/default date ``` Two distinct failure modes, both material: - **+365d on C-0BCDB8C2 and C-0BBE3E60.** If ChurnZero were trusted, $85,420 of ARR would silently fall out of the 90-day window entirely. This is the highest-consequence defect in the set. - **2026-09-10 repeated verbatim on three unrelated accounts** (C-0B7D2C30, C-0D2AB865, C-0F5D2323) whose real dates are 09-15, 09-22, 09-29. Three accounts cannot serendipitously share a renewal date across two different terms; that is a default or un-cleared field value, not data. Treating it as real would compress three renewals into one 19-day-old date — two of them (C-0B7D2C30, C-0D2AB865) already inside the window with no prep time. C-0B7D2C30 is the one case where the error is small (+5d) but not harmless: its true date is 2026-09-15, seven days out at brief date, and it carries a HIGH risk rating. Recommend a data-fix ticket on the multi-year sync, not just a manual override. --- ### 2. RENEWAL DETAIL Utilization = seats_used / seats. 3-month trend = mean(2026-06..08) vs mean(2026-03..05). Ratings: HIGH = declining or chronically un-adopted; MEDIUM = flat with moderate utilization; LOW = growing. **HIGH RISK — 6 accounts, $359,409** ``` C-0B7D2C30 Dana Mercer $65,901 2026-09-15 util 57.6% (274/476) 3mo 112.0 → 91.7 (-18.2%) 12mo 155 → 84 (-45.8%) Twelve straight months of decline with no month-over-month recovery; active users are down 45.8% year over year while 202 of 476 seats sit unused. C-0BCDB8C2 Cole Ingram $54,427 2026-09-18 util 54.7% (232/424) 3mo 143.7 → 118.3 (-17.6%) 12mo 200 → 110 (-45.0%) Identical decay shape to C-0B7D2C30 — 110 of 200 users lost in 12 months and the slide accelerated in the last quarter. C-0D2AB865 Elena Sinclair $38,022 2026-09-22 util 61.4% (250/407) 3mo 144.3 → 117.0 (-18.9%) 12mo 199 → 109 (-45.2%) Steepest 3-month drop in the book at -18.9%, on top of a 45.2% annual loss. C-0BBE3E60 Dana Mercer $30,993 2026-09-26 util 64.9% (74/114) 3mo 44.3 → 35.7 (-19.5%) 12mo 63 → 33 (-47.6%) Worst percentage decline in the book: active users have nearly halved, 33 and still falling. C-0F5D2323 Cole Ingram $90,647 2026-09-29 util 28.5% (111/390) 3mo 19.0 → 19.7 (+3.5%) 12mo 21 → 18 (-14.3%) Largest single renewal in the window and the worst adoption: only 18-21 people active against 390 paid seats, flat for 12 months — the flatness is not stability, it is a floor of ~20 users that never adopted. C-0EC6999D Elena Sinclair $79,419 2026-10-03 util 27.7% (31/112) 3mo 15.0 → 16.0 (+6.7%) 12mo 15 → 15 (+0.0%) Lowest utilization in the book at 27.7% and zero net growth over 12 months — $79,419 renewing on 15-17 active users against 112 seats. ``` **MEDIUM RISK — 5 accounts, $189,929** ``` C-0B20DB64 Dana Mercer $21,770 2026-10-07 util 56.6% (214/378) 3mo 295.0 → 295.3 (+0.1%) 12mo 293 → 294 (+0.3%) Perfectly flat at ~294 users for 12 months with 164 paid seats idle — no decline, but no expansion signal to defend the seat count. C-0BBC4E7A Cole Ingram $56,374 2026-10-10 util 67.7% (228/337) 3mo 142.0 → 140.7 (-0.9%) 12mo 142 → 139 (-2.1%) Mild drift down over 12 months (-2.1%); utilization is acceptable at 67.7% but the trend has turned slightly negative. C-0FD551AB Elena Sinclair $48,815 2026-10-14 util 55.9% (210/376) 3mo 125.7 → 123.7 (-1.6%) 12mo 124 → 126 (+1.6%) Net flat over 12 months with a soft -1.6% last quarter — trend is ambiguous and 44% of seats are unused. C-0F9F8F13 Dana Mercer $46,230 2026-10-18 util 56.5% (199/352) 3mo 183.7 → 184.0 (+0.2%) 12mo 182 → 182 (+0.0%) Zero growth across 12 months; 153 seats idle with no expansion trajectory. C-0BC34584 Cole Ingram $16,740 2026-10-22 util 66.2% (327/494) 3mo 103.7 → 104.7 (+1.0%) 12mo 103 → 106 (+2.9%) Smallest ARR in the book; flat-to-slightly-up but 167 of 494 seats unused. ``` **LOW RISK — 9 accounts, $499,377** ``` C-0B7A7546 Elena Sinclair $35,062 2026-10-25 util 88.8% (182/205) 3mo 61.3 → 64.0 (+4.3%) 12mo 58 → 63 (+8.6%) Highest utilization in the book at 88.8% and still growing. C-0B369871 Dana Mercer $85,128 2026-10-29 util 75.1% (317/422) 3mo 316.0 → 329.7 (+4.3%) 12mo 289 → 333 (+15.2%) Strongest absolute growth: +44 active users over 12 months and 12 consecutive monthly gains. C-0B144C78 Cole Ingram $30,899 2026-11-02 util 75.4% (169/224) 3mo 99.7 → 102.7 (+3.0%) 12mo 90 → 106 (+17.8%) Second-fastest growth rate in the book at +17.8% year over year. C-0FC4DBB8 Elena Sinclair $94,732 2026-11-05 util 76.7% (356/464) 3mo 183.3 → 191.0 (+4.2%) 12mo 168 → 193 (+14.9%) Largest ARR in the book and growing steadily +14.9%. C-0D5BBE3A Dana Mercer $39,740 2026-11-09 util 83.3% (85/102) 3mo 86.3 → 89.7 (+3.9%) 12mo 76 → 91 (+19.7%) Fastest percentage growth in the book at +19.7% on 83.3% utilization. C-0FB9D5AF Cole Ingram $63,158 2026-11-13 util 72.4% (144/199) 3mo 166.3 → 174.0 (+4.6%) 12mo 154 → 176 (+14.3%) Highest 3-month growth rate at +4.6% with utilization above 72%. C-0B344485 Elena Sinclair $64,384 2026-11-16 util 78.0% (224/287) 3mo 231.0 → 240.7 (+4.2%) 12mo 211 → 244 (+15.6%) Consistent month-over-month climb, 11 of 12 months up. C-0CB2C1B4 Dana Mercer $40,628 2026-11-20 util 81.6% (386/473) 3mo 49.0 → 48.0 (-2.0%) 12mo 43 → 49 (+14.0%) The only LOW with a negative 3-month print, but +14.0% over 12 months and 81.6% utilization; the -2.0% is 1 user of noise on a small base. C-22170CA1 Cole Ingram $45,646 2026-11-24 util 85.4% (251/294) 3mo 142.0 → 145.7 (+2.6%) 12mo 130 → 146 (+12.3%) 85.4% utilization with steady growth — near-full and expanding. ``` --- ### 3. TOTALS ``` Total ARR renewing in window $1,048,715 (20 accounts) HIGH risk 6 accounts $359,409 MEDIUM risk 5 accounts $189,929 LOW risk 9 accounts $499,377 ARR AT RISK (HIGH + MEDIUM) $549,338 = 52.4% of renewing ARR ARR AT HIGH RISK $359,409 = 34.3% of renewing ARR ``` Arithmetic: 359,409 + 189,929 = 549,338. 549,338 / 1,048,715 = 0.5238. 359,409 / 1,048,715 = 0.3427. By CSM, ARR at risk: Elena Sinclair $166,256 (117,441 HIGH + 48,815 MED); Cole Ingram $218,188 (145,074 + 73,114); Dana Mercer $164,894 (96,894 + 68,000). ### 4. WHAT THE DATA DOES NOT SAY No health scores, NPS, support tickets, exec-sponsor status, or prior-term ARR change were provided, so no downgrade/expansion forecast is possible — these are utilization and trend ratings only. Two accounts (C-0F5D2323, C-0EC6999D) are rated HIGH on chronic under-adoption with flat usage, not on decline; that distinction matters for the play (right-size conversation, not save motion) and is not resolvable from the supplied files.
Read all 80 tickets; ignored the `tag` column and classified on body text only. Theme ARR = sum of distinct-account ARR inside each theme (not tickets × ARR), so no double-counting. Accounts are disjoint across themes: 9 + 7 + 1 + 4 + 3 = 24 distinct, total book $284,800.
QUARTER TOTALS
80 tickets | 24 distinct accounts | $284,800 ARR in book
Date range: 2026-06-01 (IC-460004) to 2026-08-29 (IC-460079)
Tags are unusable: identical text carries different tags (IC-460004 "bug" vs IC-460020 "billing", same body), and every theme spans 4-6 of the 6 tags. Tag counts: bug 16, urgent 16, billing 15, feedback 13, how-to 11, question 9 — none of which maps to any theme below.
───────────────────────────────────────────────────────────────
RANKED BY ARR EXPOSURE
1. HRIS provisioning gaps — new hires not auto-provisioned
Count 12 (15.0%: 12/80) | Accounts 3 | ARR $114,000 (40.0%: 114,000/284,800)
Accounts: C-0DDFC9A7 $48,000 + C-0B2213A9 $36,000 + C-0F6C0F34 $30,000
Tickets: IC-460059, IC-460062 (also IC-460060, IC-460064, IC-460053, IC-460055, IC-460061, IC-460058, IC-460054, IC-460063, IC-460057)
Highest-value: "HRIS sync skipped 12 new hires; provisioning log shows no errors" — silent failure, self-reported as undetectable by the customer.
Rec: Treat as a Sev-1 silent-sync defect across all three HRIS-connected accounts — add a reconciliation job that compares HRIS headcount to provisioned seats and alerts on delta.
2. Redemption & gift-card fulfillment failures
Count 18 (22.5%: 18/80) | Accounts 7 | ARR $68,800 (24.2%: 68,800/284,800)
Accounts: C-14264ABD 11,000 + C-0B827671 10,700 + C-0B0F1BAB 10,300 + C-0FCCD2DF 9,600 + C-0D9CA315 9,600 + C-0CEF69FD 8,900 + C-0F876796 8,700
Tickets: IC-460024, IC-460035 (also IC-460025, IC-460030, IC-460022, IC-460037, IC-460034)
Broadest theme by account count. Two distinct sub-failures: checkout hang/timeout, and points deducted with no card delivered (a money-trust issue, not just a bug).
Rec: Make point deduction conditional on fulfillment confirmation and add an auto-refund on gift-card vendor error — 5 tickets (IC-460024, IC-460023, IC-460027, IC-460026, IC-460037) report points lost on a failed order.
3. Billing / invoice errors — seat count and renewal tier
Count 16 (20.0%: 16/80) | Accounts 1 | ARR $52,000 (18.3%: 52,000/284,800)
Account: C-0E9C27D1 $52,000 — 16 of 16 tickets, 20% of all quarter volume from one logo
Tickets: IC-460069, IC-460078 (also IC-460071, IC-460065, IC-460074, IC-460076, IC-460067, IC-460075)
SINGLE-ACCOUNT NOISE, NOT A PLATFORM PATTERN. Flag loudly: "Third invoice in a row with the same seat-count error" (IC-460071) means two prior quarters of unresolved repeat failure. Charged for 200 seats vs 150 licensed = 50-seat overbill per the customer's own statement.
Rec: Escalate as a retention/credits case for C-0E9C27D1 — audit the three invoice cycles, issue a credit for the disputed seats, and freeze auto-renewal billing until the seat source is corrected; do not staff a platform fix on this evidence alone.
4. Points not posting to balances
Count 20 (25.0%: 20/80) | Accounts 9 | ARR $31,100 (10.9%: 31,100/284,800)
Accounts: C-0BF20542 4,500 + C-0D0B047C 4,500 + C-0D6CC8E3 4,200 + C-0D3278C7 3,500 + C-0D284E42 3,400 + C-21FEBCBB 2,900 + C-0B2895EF 2,900 + C-0BE96399 2,700 + C-0DD0626C 2,500
Tickets: IC-460004, IC-460016 (also IC-460001, IC-460014, IC-460008, IC-460007)
HIGHEST VOLUME, LOWEST VALUE. 25% of tickets, 10.9% of ARR. All nine accounts are sub-$5K. Recurrence within accounts is high (C-0D3278C7, C-0BE96399, C-0D284E42, C-0D6CC8E3 = 3 tickets each).
Rec: Highest ticket-to-ARR ratio in the book — push to self-serve (balance-reconciliation status page + automatic re-post) rather than human support, and check whether the weekend/timing language ("after the weekend", "since Tuesday") points to a batch-job lag.
5. Slack integration failures
Count 14 (17.5%: 14/80) | Accounts 4 | ARR $18,900 (6.6%: 18,900/284,800)
Accounts: C-10A56B0F 5,400 + C-8C2E8F00 5,200 + C-0B843542 4,400 + C-0BA71F12 3,900
Tickets: IC-460046, IC-460047 (also IC-460049, IC-460043, IC-460041, IC-460048)
Four failure modes in one surface: slash-command error, sync toggle self-resetting, sync stopped, re-auth not persisting. C-0BA71F12 alone is 6 of 14 (43%).
Rec: Fix auth-token persistence and toggle state as one workstream — "re-auth does not stick" (IC-460049) plus "sync toggle resets itself" (IC-460047) suggest an OAuth/session storage defect, not four separate bugs.
───────────────────────────────────────────────────────────────
VOLUME vs ARR INVERSION
By volume: Points (20) > Redemption (18) > Billing (16) > Slack (14) > HRIS (12).
By ARR: HRIS ($114K) > Redemption ($68.8K) > Billing ($52K) > Points ($31.1K) > Slack ($18.9K).
HRIS is last in volume and first in ARR — 12 tickets on 3 accounts carry 40% of exposure. Points is first in volume and fourth in ARR. Staffing against volume would put 4x the effort on the smallest-ARR theme.
CONCENTRATION FLAGS (single-account noise inside broad themes)
- C-0E9C27D1: 16/16 billing tickets — the entire theme is one account.
- C-0B2213A9: 7/12 HRIS tickets; C-0BA71F12: 6/14 Slack tickets. Both themes are genuinely multi-account (3 and 4 accounts), so they are broad patterns with one loud account, not single-account issues.
MISSING DATA — not inferable from this file
- No resolution status, priority, or reopen fields, so recurrence vs new-issue volume cannot be separated; "third invoice in a row" is customer-reported, not verifiable here.
- No product/feature field or ticket body beyond one sentence, so root cause cannot be confirmed for any theme.
- ARR is account-level only; per-ticket revenue impact does not exist, so ARR exposure is a reach measure, not a loss measure.
- Seat counts, contract term, and renewal dates are absent — the 200-vs-150 seat dispute cannot be quantified in dollars.
- The "12 new hires" figure (IC-460062, IC-460060, IC-460064) is customer-reported and unverified.
RANKED SOCIAL PROOF — PROSPECT C-82AF3719 Prospect profile: industry=Technology | size_band=Mid-Market | use_case=employee_recognition | region=NA-West STEP 1 — APPLY THE CASE-STUDY GATE Of 25 customers, 8 have has_case_study=true. Only these are eligible: C-FEFCC020, C-11209339, C-9D69D147, C-11C31562, C-CD4829A7, C-0CE315B2, C-64171065, C-A13C193D STEP 2 — SCORING RULE (stated as an analyst assumption, not in the data) 1.0 = exact field match | 0.5 = partial: same macro-region (NA-East and NA-West both group to NA) | 0.0 = mismatch Four fields scored, max 4.0. STEP 3 — ARITHMETIC ON ALL 8 ELIGIBLE CUSTOMERS C-64171065 Tech 1.0 + MM 1.0 + employee_recognition 1.0 + NA-East 0.5 = 3.5 C-11C31562 Mfg 0.0 + MM 1.0 + employee_recognition 1.0 + NA-West 1.0 = 3.0 C-A13C193D Tech 1.0 + MM 1.0 + retention 0.0 + NA-West 1.0 = 3.0 C-CD4829A7 Tech 1.0 + MM 1.0 + retention 0.0 + NA-East 0.5 = 2.5 C-9D69D147 FS 0.0 + MM 1.0 + retention 0.0 + NA-West 1.0 = 2.0 C-FEFCC020 Edu 0.0 + Ent 0.0 + wellness 0.0 + NA-East 0.0 = 0.0 C-11209339 Mfg 0.0 + SMB 0.0 + peer_milestones 0.0 + APAC 0.0 = 0.0 C-0CE315B2 Edu 0.0 + SMB 0.0 + wellness 0.0 + EMEA 0.0 = 0.0 STEP 4 — TIEBREAK C-11C31562 and C-A13C193D both score 3.0 with 3 exact matches. Broken in favor of the use_case match: social proof is strongest when the reference ran the same use case the prospect is buying. C-11C31562 matches employee_recognition; C-A13C193D does not (retention). TOP 3 1. C-64171065 — score 3.5 / 4.0 Fields driving the match: industry=Technology (exact) | size_band=Mid-Market (exact) | use_case=employee_recognition (exact) | region=NA-East (partial, same NA macro-region as NA-West) Only gap: sub-region within North America. 2. C-11C31562 — score 3.0 / 4.0 Fields driving the match: size_band=Mid-Market (exact) | use_case=employee_recognition (exact) | region=NA-West (exact) Only gap: industry=Manufacturing vs Technology. 3. C-A13C193D — score 3.0 / 4.0 Fields driving the match: industry=Technology (exact) | size_band=Mid-Market (exact) | region=NA-West (exact) Only gap: use_case=retention vs employee_recognition. DATA GAPS / CAVEATS - No eligible customer is a 4.0/4.0 match. The best available is 3.5. - Two customers in the file match the prospect on all four fields exactly (Technology, Mid-Market, employee_recognition, NA-West) but have has_case_study=false. Per instruction they are not named and are excluded; this is why the top match is a 3.5 rather than a perfect match. - The file supplies only a boolean has_case_study flag. It contains no case study title, content, URL, quoted metric, or publication date, so I cannot verify what each case study actually covers or whether any named customer is referenceable/logo-approved. - No billing, ARR, or contact fields were used or are present; none are reported. If you want a different tiebreak weighting — e.g. industry over use_case, which would flip #2 and #3 — the arithmetic under that rule is: C-A13C193D 3.0, C-11C31562 3.0, resolved to C-A13C193D second.
## Channel performance — trailing 6 months (2026-03 → 2026-08)
Definitions used: SQM = a row with a populated sqm_date; SQO = a row with a populated sqo_date; pipeline = sum of pipeline_amount on SQO rows. All 122 contact rows have an sqm_date, so SQM volume = contact volume for every channel (no missing-SQM rows).
### PAID CHANNELS
```
channel spend SQMs SQOs $/SQM $/SQO SQM→SQO pipeline pipe/$
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 undef. undef. undef. 0 undef.
────────────────────────────────────────────────────────────────────────────────
paid total 87,000 77 31 1,130 2,806 40.3% 876,000 10.07
```
Arithmetic (spend = 6 × monthly, all months equal):
- paid_search: 6×6,000 = 36,000 · 36,000/40 = 900 · 36,000/18 = 2,000 · 18/40 = 45.0% · 18×40,000 = 720,000 · 720,000/36,000 = 20.00
- linkedin_ads: 6×4,000 = 24,000 · 24,000/25 = 960 · 24,000/8 = 3,000 · 8/25 = 32.0% · 8×12,000 = 96,000 · 96,000/24,000 = 4.00
- webinars: 6×1,500 = 9,000 · 9,000/12 = 750 · 9,000/5 = 1,800 · 5/12 = 41.7% · 5×12,000 = 60,000 · 60,000/9,000 = 6.67
**paid_social = undefined, not zero.** $18,000 spent (3,000/mo × 6) with zero SQMs and zero SQOs in contacts_first_touch.csv. Cost per SQM, cost per SQO, and SQM-to-SQO rate are all undefined (division by zero SQMs) — not $0 and not 0%. Pipeline per dollar is likewise undefined: there is no attributed pipeline, but we cannot say the channel produced zero value, only that nothing was attributed to it. Pipeline per dollar of $0.00 would assert a negative result the data does not support.
Note the paid-total $/SQM of 1,130 and $/SQO of 2,806 are inflated by paid_social's $18,000 of unattributed spend. Excluding it: 69,000/77 = 897 per SQM, 69,000/31 = 2,226 per SQO, 876,000/69,000 = 12.70 pipe/$.
### ORGANIC CHANNELS
```
channel volume SQOs SQO rate pipeline
organic_search 30 10 33.3% 90,000
referral 15 6 40.0% 48,000
───────────────────────────────────────────────────
organic total 45 16 35.6% 138,000
```
- organic_search: 10/30 = 33.3% · 10×9,000 = 90,000
- referral: 6/15 = 40.0% · 6×8,000 = 48,000
### DATE-INTEGRITY FLAGS (sqo_date precedes sqm_date)
```
CT-000044 linkedin_ads sqm 2026-07-23 → sqo 2026-07-18 (-5 days) 12,000
CT-000041 linkedin_ads sqm 2026-06-14 → sqo 2026-06-09 (-5 days) 12,000
```
2 of 122 rows (1.6%), both linkedin_ads, both exactly 5 days inverted. They are 25% of linkedin_ads' 8 SQOs. Two other rows are same-day (CT-000007 paid_search 2026-03-28/2026-03-28) — that is a zero-day gap, not an inversion, so not flagged.
linkedin_ads restated excluding the 2 flagged rows: 6 SQOs, 6/25 = 24.0% SQM→SQO, 24,000/6 = 4,000 per SQO, 72,000 pipeline, 3.00 pipe/$. That is the worst paid result on every metric — the flags are material to the linkedin_ads read, so the honest range for linkedin_ads is 24.0%–32.0% SQO rate and $3.00–$4.00 pipe/$.
### CRITICAL CAVEAT ON PIPELINE
pipeline_amount is constant within each channel (paid_search 40,000; linkedin_ads 12,000; webinars 12,000; organic_search 9,000; referral 8,000) on every SQO row, with zero variance. So every pipeline figure is just SQOs × a channel-fixed ACV. paid_search's 5× pipeline advantage over webinars is entirely a 3.33× ACV assumption, not evidence of better-sourced deals. Rank channels on cost per SQO first ($/SQO is ACV-independent); treat pipe/$ as only as good as the ACV assumption. No closed-won, win-rate, or bookings data was provided, so pipeline here is created pipeline, not revenue.
### REALLOCATION RECOMMENDATION
1. **Move paid_social's $18,000 (3,000/mo) out now** — six months, zero attributed SQMs, no evidence of return. Before deleting it permanently, confirm whether this is a tracking/attribution gap or true non-performance; the recommendation to stop spend survives either way, but the diagnosis changes whether the fix is re-tagging.
2. **Split the freed $18,000: $12,000 → paid_search, $6,000 → webinars.** Rationale: webinars has the lowest cost per SQO ($1,800 vs $2,000 paid_search) and lowest cost per SQM ($750), so on unit economics it is the cheapest SQO source. But webinars produced only 5 SQOs in 6 months — its capacity at 1,500/mo is unproven, so tripling it assumes the SQO rate (41.7%) holds at 4× the spend. paid_search has the deepest sample (40 SQMs, 18 SQOs) and is the only channel whose rate is measured on a base large enough to trust; it absorbs the majority. At observed rates that is +6 SQOs from paid_search (12,000/2,000) and +3.3 from webinars (6,000/1,800).
3. **Hold linkedin_ads flat at 4,000/mo; put it on review, do not cut yet.** Worst $/SQM ($960) and worst pipe/$ (3.00–4.00), but its 8 SQOs rest on two date-invalid rows. Fix the data first, then decide.
4. **Do not fund organic channels with paid budget** — referral (40.0%) and organic_search (33.3%) are efficient but are not spend-driven; there is no spend line to reallocate into them, and no data on what incremental investment would buy.
### CONFIDENCE
```
channel n (SQMs) SQOs 95% CI on SQO rate (Sinclair) confidence
paid_search 40 18 [30.7%, 60.2%] ±15pt MODERATE
organic_search 30 10 [19.2%, 51.2%] ±16pt LOW-MODERATE
linkedin_ads 25 8 [17.2%, 51.6%] ±17pt LOW (+2 date flags)
referral 15 6 [19.8%, 64.3%] ±22pt LOW
webinars 12 5 [19.3%, 68.0%] ±25pt VERY LOW
paid_social 0 0 n/a HIGH on "no attribution",
LOW on the cause
```
Every confidence interval overlaps every other. **No channel is statistically distinguishable from any other on SQO rate** at these sample sizes — the 45.0% vs 32.0% paid_search-vs-linkedin_ads gap is 13 points on a ±15-point interval, i.e. noise. So:
- **High confidence**: paid_social has no attributed return and should be reallocated; cost per SQM ranking is real (webinars 750 < paid_search 900 < linkedin_ads 960) because it is driven by SQM counts, which are the best-populated field.
- **Moderate confidence**: paid_search is the safest incremental home for budget — not because its rate is provably better, but because it is the only channel measured on 40 SQMs.
- **Low confidence**: the exact 12,000/6,000 split, the webinars capacity assumption, and all pipe/$ rankings (constant-ACV artifact).
What would change the answer: another 6 months of data (roughly doubling n closes these intervals), win-rate by channel, and variable (non-fixed) pipeline amounts.
BATTLECARD: RIVALLY — UPDATED Window: 2025-09 → 2026-08 (full extent of supplied data). Every claim tagged [S##]. ──────────────────────────────────────── 1. ONE-LINE POSITIONING ──────────────────────────────────────── Points-based recognition with an engaging social feed, fast time-to-value, and a now-differentiated EU story — but thin analytics and lagging admin tooling above the mid-market. Basis: points-based recognition feed [S02] [S16]; mid-market setup under a week with Slack working out of the box [S04]; EU data residency generally available + Dublin office [S15], multi-language support praised for distributed EU teams [S12]; limited analytics [S02] [S07]; admin tooling lags [S16] [S24] [S10]. ──────────────────────────────────────── 2. PRICING (conflict on record — newest source wins) ──────────────────────────────────────── CURRENT LIST: $7 per user/month, Recognition Starter, annual billing required [S17 — pricing_page, 2026-08-12]. Corroborated same month: prospect reports Rivally quoted $7/user/mo list [S18 — call_notes, 2026-08-14]. CONFLICT AND RESOLUTION: [S03] 2026-01-20 pricing_page — $5/user/mo, annual billing required. SUPERSEDED. [S08] 2026-04-01 pricing_page — $5/user/mo, Recognition Starter. SUPERSEDED. [S13] 2026-06-02 call_notes — $6.50/user/mo quoted to a 500-seat prospect, annual term. NOT list price; a single deal quote, and it predates [S17]. Do not cite as list. Ruling: [S17] is the newest pricing-page source and is independently confirmed by [S18]. $7 is current list. The $5 figure on the old card is stale. DISCOUNTED MULTI-YEAR: 15% off for a 3-year term [S18]. Arithmetic: $7.00 × (1 − 0.15) = $7.00 × 0.85 = $5.95 per user/month effective on a 3-year term. Note the trap: $5.95 only appears if the buyer signs 3 years. Month-one list is $7 [S17]. ADD-ON COST: Rivally Pulse (engagement surveys) exited beta 2026-09-01 and is priced as a paid add-on, not bundled [S23] [S06]. The add-on price is NOT in the data — do not quote one. Practical implication: any buyer needing surveys pays above the $7 base, by an unknown amount. MISSING: our own pricing is not in the supplied data. No price comparison is possible. Do not claim we are cheaper or more expensive. ──────────────────────────────────────── 3. WHERE THEY WIN ──────────────────────────────────────── EU / distributed teams — EU data residency generally available and Dublin office opened 2026-07-01 [S15]; multi-language support praised, strong for distributed EU teams [S12]; they are actively pitching EU data residency in competitive deals [S05]; dedicated EMEA leadership hired (ex-Workday VP EMEA) 2026-05-09 [S11]. Counterweight to carry: their EMEA rewards catalog is thinner than the US catalog [S14]. Speed to value — setup under a week, Slack integration worked out of the box (mid-market reviewer) [S04]. Feed engagement — recognition feed repeatedly cited as engaging [S02] [S16]. Support — response time under 4 hours, praised [S22]. Platform breadth moves — Microsoft Teams app v2 in public preview 2026-08-20 [S19]; Pulse surveys now GA as an add-on [S23]. Funding/capital — $40M Series C led by Northgate Ventures [S01]. This is 2025-11-04; no later funding event is in the data. ──────────────────────────────────────── 4. WHERE WE WIN ──────────────────────────────────────── HARD EVIDENCE (one): an 800-seat prospect picked us over Rivally citing analytics depth [S25 — 2026-08-30]. This is the only sourced, in-period head-to-head win reason in the data. EXPLOITABLE GAPS (competitor-side weaknesses; no snippet confirms our own equivalent feature, so phrase these as questions, not claims): Analytics — limited [S02]; reporting dashboards basic vs. enterprise tools [S07]; analytics exports are CSV-only [S20]. Admin tooling — lags peers [S16]; no bulk recognition editing as of 2026-09-02 [S24]. Enterprise identity — no SCIM provisioning; manual user management painful [S10]. Switching cost / lock-in — migration off Rivally is hard because analytics exports are CSV-only [S20]. CAVEAT: the supplied data contains no information about Bonusly's features, analytics, or EU posture except [S25]. Treat section 4 as "their documented gaps," not "our documented strengths." Ask the PMM owner for sourced support before this goes to reps as claimed parity/superiority. ──────────────────────────────────────── 5. OBJECTIONS AND RESPONSES ──────────────────────────────────────── "They're $5 and you're more." Their own pricing page moved to $7/user/mo on 2026-08-12 [S17], and a prospect was quoted $7 list the same month [S18]. The $5 number is from Jan/Apr 2026 [S03] [S08] and is stale. If they quote $5.95, that requires a 3-year commitment at 15% off [S18] — $7.00 × 0.85 = $5.95. Also: Pulse is a paid add-on, not bundled [S23], so $7 is not the whole bill. "They have EU data residency and you don't." True and sourced: EU data residency GA 2026-07-01 [S15], actively pitched in deals [S05]. No snippet in this data states whether we have EU data residency. Do not bluff this — escalate to Product for a sourced answer. Attack the surrounding gaps instead: EMEA rewards catalog is thinner than US [S14]; no SCIM [S10]; admin tooling lags [S16]. "They deploy in a week, Slack just works." Concede it — supported by [S04]. Pivot to lifecycle fit: ask what happens at review cycle when analytics exports are CSV-only [S20] and reporting is basic vs. enterprise tools [S07]. Use the 800-seat win where analytics depth decided it [S25]. "They'll discount to win." Documented: 15% for a 3-year term [S18]. Note the trade-off — that is a 36-month lock with CSV-only analytics exports [S20] if they want out. EXCLUDED AS FACT: AE Elena Sinclair's view that Rivally is discounting aggressively [S21] is explicitly rep opinion, not confirmed. Do not use it. "Your UI critique / their UI is clunky." EXCLUDED AS FACT: AE Bryce Harmon's "clunky UI" comment [S09] is flagged in-source as not verified against the product. Rep opinion is not a competitor fact. Strike it from rep talk tracks. ──────────────────────────────────────── 6. RECENT CHANGES (2026-03 → 2026-09) ──────────────────────────────────────── 2026-03-05 Rivally Pulse launched (lightweight engagement survey add-on) [S06] 2026-05-09 Ex-Workday VP EMEA hired to lead European expansion [S11] 2026-07-01 Dublin office opened; EU data residency generally available [S15] 2026-08-12 List price increased $5 → $7/user/mo on the pricing page [S17] (vs [S03]/[S08]) 2026-08-20 Microsoft Teams app v2 in public preview [S19] 2026-09-01 Rivally Pulse exits beta; priced as add-on, not bundled [S23] 2026-09-02 Admin console still lacks bulk recognition editing [S24] Also in-period: $6.50/user/mo quoted to a 500-seat prospect (2026-06-02) [S13] — pre-increase deal quote. Older but material: $40M Series C, 2025-11-04 [S01]. ──────────────────────────────────────── 7. OUR 12-MONTH WIN/LOSS RECORD VS. RIVALLY ──────────────────────────────────────── Window: 2025-09 through 2026-08 = 12 months, 20 closed deals. Per-month tally (W–L): 2025-09 1–1 (win Deal-072E31; loss Deal-7767F5) 2025-10 2–0 (Deal-A9FD43, Deal-F65C8F) 2025-11 1–1 (win Deal-7AA785; loss Deal-D263E0) 2025-12 1–1 (win Deal-44C524; loss Deal-935746) 2026-01 2–0 (Deal-0D0CD6, Deal-E46EAB) 2026-02 2–0 (Deal-D5B790, Deal-1D2392) 2026-03 1–1 (win Deal-5C636E; loss Deal-9066A6) 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) TOTALS — arithmetic: Wins: 1+2+1+1+2+2+1+0+0+1+1+1 = 13 Losses: 1+0+1+1+0+0+1+2+1+0+0+0 = 7 Check: 13 + 7 = 20 deals ✓ Win rate: 13 ÷ 20 = 0.65 → 65.0% TREND SPLIT: First 6 months (2025-09 → 2026-02): 9 wins, 3 losses → 9 ÷ 12 = 0.75 → 75.0% Last 6 months (2026-03 → 2026-08): 4 wins, 4 losses → 4 ÷ 8 = 0.50 → 50.0% Check: 9+4 = 13 wins, 3+4 = 7 losses ✓ LOSS CLUSTER: 3 of 7 losses (Deal-5645A5, Deal-72A02F, Deal-C6FFAA) fall in Apr–May 2026 — the only two losing months with zero wins. That cluster predates EU data residency GA on 2026-07-01 [S15]. The data contains no loss-reason field, so no cause can be established. Do not infer one. DATA GAP: the file carries only deal_alias, month, outcome, competitor. No segment, seat count, ACV, region, or loss reason. Win rate cannot be sliced by segment or geography, and no loss cause is attributable. ──────────────────────────────────────── 8. OLD CARD — RECONCILIATION ──────────────────────────────────────── KEPT / RE-SOURCED "Points-based recognition for mid-market" — points-based feed [S02] [S16]; mid-market reviewer on fast setup [S04]. Retained, restated. "Strong in EU with multi-language support" — multi-language praised, strong for distributed EU teams [S12]; EU data residency GA [S15]. Retained, but reframed to "distributed EU teams," not "enterprise" (see below). CORRECTED Pricing — old card: $5/user/mo as of 2026-01. Now $7/user/mo per newest pricing page [S17], confirmed [S18]. Corrected. "Strong in EU enterprise" — partially walked back. Multi-language/distributed-EU strength is sourced [S12], but enterprise-readiness is contradicted: no SCIM [S10], basic reporting [S07], admin tooling lags [S16]. Downgraded to "EU mid-market / distributed teams." REMOVED — CONTRADICTED "Rivally lacks a Slack integration" — false per current data: Slack integration worked out of the box [S04]. Removed. REMOVED — UNVERIFIED "Acquired by WorkHuman in 2025" — NO snippet supports this. The only adjacent item is the hiring of an ex-Workday VP EMEA [S11]; Workday and WorkHuman are different companies and a hire is not an acquisition. No funding/ownership event other than the Northgate-led Series C [S01] appears anywhere in the data. Marked UNVERIFIED and removed pending a source. Do not repeat it. REMOVED — REP OPINION (not competitor fact) UI "clunky" [S09] and "discounting aggressively" [S21]. Both self-labeled opinion/unconfirmed in-source. Excluded from all sections above. ──────────────────────────────────────── 9. OPEN ITEMS — CANNOT BE ANSWERED FROM THIS DATA ──────────────────────────────────────── - Our own pricing, features, analytics, and EU data residency status: no snippet. Section 4 is therefore gap-based, not capability-based. - Rivally Pulse add-on price: [S23] confirms it is paid but gives no number. - Any loss reason or segment/ACV split on the 20 deals: fields absent. - Whether Rivally has SCIM, bulk editing, or deeper analytics today beyond the latest review dates ([S10] 2026-04-28, [S24] 2026-09-02): those are the newest available and are treated as current. - Ownership/M&A status: unresolvable from these 25 snippets.
PER-SEQUENCE (3 steps summed; arithmetic shown) New Logo Nurture: sent 500+458+428=1,386. Open 210+160+120=490 → 35.4%. Reply 42+30+18=90 → 6.49%. Meetings 12+9+6=27 → 1.95%. Weakest step: 3 (28.0% open, 4.21% reply, 1.40% meeting). Expansion Nurture: sent 300+300+275=875. Open 130+340+95=565 → 64.6% (invalid, see below). Reply 59 → 6.74%. Meetings 12 → 1.37%. Corrected open excluding step 2: (130+95)/(300+275)=225/575=39.1%. Weakest step: 3 (34.5% open, 4.36% reply, 1.09% meeting). Cold Outbound - HR Leaders: sent 600+595+590=1,785. Open 545 → 30.5%. Reply 5+2+1=8 → 0.45%. Meetings 0 → 0.00%. Weakest step: 3 (22.0% open, 0.17% reply). Cold Outbound - People Ops: sent 400+386+377=1,163. Open 340 → 29.2%. Reply 14+9+6=29 → 2.49%. Meetings 6 → 0.52%. Weakest step: 3 (21.2% open, 1.59% reply). TRACKING ERRORS 1. Expansion Nurture step 2: opened 340 > sent 300 → 113.3%. Impossible; inflates sequence open rate to 64.6%. 2. Expansion step 2 sent=300 equals step 1 sent=300: no drop-off, so "sent" is not step-2 net of step-1 replies/unsubscribes. 3. HR Leaders step 1->2->3 sent falls only 600→595→590 (0.8% attrition) on 1,785 sends — implausible for cold; likely cumulative-audience counting, not per-step sends. 4. Volume mismatch: 963 audience rows vs 5,209 total sends. Data cannot both be right; source of truth unclear. AUDIENCE OVERLAP (audiences.csv) 963 rows, 940 unique contact_keys. 23 contacts in 2 sequences: 21 shared between Cold Outbound - HR Leaders and Cold Outbound - People Ops; 2 shared between Expansion Nurture and New Logo Nurture (CT-000301, CT-000624). HR Leaders and People Ops are duplicate-audience segments, not distinct personas. FAILURE MODE UNDER 2% REPLY Cold Outbound - HR Leaders only: 0.45% reply, 0 meetings. Not deliverability — open 30.5% ≈ People Ops 29.2%. Reply-per-open: HR 8/545=1.47% vs People Ops 29/340=8.53%, a 5.8x gap at identical open rates. Diagnosis: message/persona mismatch — same-ish audience, one converts, one does not. ONE CHANGE PER WEAK SEQUENCE - Cold Outbound - HR Leaders: rewrite step 1 to the People Ops angle/offer and re-test 1,785 sends before adding steps. - Cold Outbound - People Ops: fix step 3 (1.59% reply) — replace with a single-question reply ask. - Expansion Nurture: fix open tracking on step 2 before any optimization. - New Logo Nurture: step 3 is decaying (8.40%→4.21%); cut or replace it. FIX FIRST: the Expansion step-2 open-tracking error. Every open-rate number in that sequence is corrupt, so no decision there is trustworthy. Then Cold Outbound - HR Leaders.
MARKETING WEEKLY GOALS UPDATE — Q3-2026 Source: marketing_qtd.csv, targets.csv, quarter_meta.csv Elapsed: 66 of 92 days = 71.7% of quarter (66/92 = 0.7174). Remaining: 26 days. SUMMARY TABLE METRIC QTD ACTUAL TARGET DELTA % OF TARGET PACE SQMs 230 300 -70 76.7% AHEAD SQOs 84 120 -36 70.0% BEHIND (marginal) DS2s 40 75 -35 53.3% BEHIND Closed-lost MIA rate 20.0% 10.0% +10.0 pp 200% of tgt BEHIND Same-quarter closes 10 20 -10 50.0% BEHIND Active pipeline $3,000,000 $4,000,000 -$1,000,000 75.0% AHEAD (marginal) PER-METRIC ARITHMETIC SQMs — AHEAD 230/300 = 0.7667 = 76.7% of target vs 71.7% of quarter elapsed. Gap = +5.0 pp. Pace-equivalent target at day 66: 300 × (66/92) = 215.2. Actual 230 = +14.8 vs pace. Current rate: 230/66 = 3.48/day. To finish: 70 remaining ÷ 26 days = 2.69/day required. Rate needed is BELOW current rate — target is reachable at current velocity. SQOs — BEHIND (marginal) 84/120 = 0.7000 = 70.0% of target vs 71.7% elapsed. Gap = -1.7 pp. Pace-equivalent: 120 × (66/92) = 86.1. Actual 84 = -2.1 vs pace. Current rate: 84/66 = 1.27/day. Required: 36 ÷ 26 = 1.38/day = +9% uplift needed. DS2s — BEHIND 40/75 = 0.5333 = 53.3% of target vs 71.7% elapsed. Gap = -18.4 pp. Pace-equivalent: 75 × (66/92) = 53.8. Actual 40 = -13.8 vs pace. Current rate: 40/66 = 0.61/day. Required: 35 ÷ 26 = 1.35/day = 2.2x current rate. Largest gap in the set. Closed-lost MIA rate — BEHIND (lower_better) Derived from the two raw counts, not supplied directly: 5 MIA ÷ 25 closed-lost total = 0.20 = 20.0%. Target 0.10. Delta = 0.20 - 0.10 = +0.10 (+10 pp adverse); actual is 2.0x the target rate. At target, 25 closed-lost would permit 25 × 0.10 = 2.5 MIA; actual is 5 = 2.5 excess MIA losses. Same-quarter closes — BEHIND 10/20 = 0.5000 = 50.0% of target vs 71.7% elapsed. Gap = -21.7 pp. Pace-equivalent: 20 × (66/92) = 14.3. Actual 10 = -4.3 vs pace. Current rate: 10/66 = 0.15/day. Required: 10 ÷ 26 = 0.38/day = 2.5x current rate. Active pipeline coverage vs target — AHEAD (marginal) Coverage = 3,000,000 ÷ 4,000,000 = 0.75 = 0.75x (75.0% of the pipeline target) vs 71.7% elapsed. Gap = +3.3 pp. Pace-equivalent: 4,000,000 × (66/92) = $2,869,565. Actual $3,000,000 = +$130,435 vs pace. Current build: 3,000,000/66 = $45,455/day. Required: 1,000,000 ÷ 26 = $38,462/day — below current build rate. WHAT MOVED THIS WEEK — DATA LIMITATION, STATED EXPLICITLY No week-over-week or dated time-series file was provided — marketing_qtd.csv contains only cumulative quarter-to-date values with no prior-week snapshot, no weekly increments, and no segment/source/channel attribution. A true "what moved this week" statement cannot be derived from the supplied data, and no such movement is asserted here. What the data does show is the position against pace at day 66: the top of the funnel is carrying the quarter (SQMs +14.8 vs pace, pipeline +$130,435 vs pace), while everything downstream of the SQO stage is short — SQOs sit 1.7 pp of target behind elapsed time, DS2s are 18.4 pp behind at roughly half the pace-required rate, same-quarter closes are 21.7 pp behind needing a 2.5x step-up, and MIA losses are running at double the 10% ceiling (5 of 25 vs 2.5 allowed). The binding constraints for the remaining 26 days are stage conversion after SQO and loss hygiene, not lead volume. GAPS IN PROVIDED DATA - No prior-week or week-start values: week-over-week movement, and therefore a factual "what moved this week" paragraph, is not derivable. - closed_lost_mia_rate is not in marketing_qtd.csv; it is computed here as closed_lost_mia ÷ closed_lost_total = 5/25. - No revenue/quota target field exists, so active_pipeline coverage is expressed only against the $4,000,000 pipeline target (0.75x). A conventional pipeline:quota coverage multiple cannot be calculated. - No deal- or company-level records were provided, so no deal/company aliases are cited.
Treat the 115,976.75 Q3 forecast as unverified, not reliable: it is 44,729 COMMIT (7 deals) + 35% of 203,565 BEST_CASE across 54 of 86 in-quarter deals, with 227,575 in 32 deals landing after 2026-09-30, including COMMIT Deal-D348E1 (13,770, dated 2026-10-15). Why-buys are blank on all 7 COMMIT deals (71 of 86 overall) and owner is blank on 85 of 86, so no rep rollup or quota check is possible. Concentration risk sits in Deal-2D7423 at 38,935 of BEST_CASE.
Subject: Following up — 150-seat pricing Hi there, Following up on my August 5 recap of the July 28 demo — 150-seat pricing, plus the automated milestone awards and points catalog your People team reacted well to. No reply since, so I'm assuming it got buried, not dropped. One ask: confirm the recognition budget still sits with the VP People. If it does, I'll resend the 150-seat quote and we can lock a short call to plan rollout. If timing has slipped, tell me and I'll follow up ahead of the November 26 close date. Best, Alex Franklin --- Word count: 95 (body + subject). Sourced from the files only: Aug 5 recap email (ENG-00001), July 28 demo content (ENG-00002), 150 seats (ENG-00001/ENG-00003), budget owner = VP People (ENG-00003), close date 2026-11-26 (stalled_deal.csv), sender = Alex Franklin (owner_name). Missing data, not invented: no recipient name or company name appears in either file — the greeting is left generic. Fill it in before sending.
WEEKLY GTM DIGEST — Week of 2026-08-31 MARKETING Marketing closed the week at 46 SQMs against a target of 52 — 6 short, or 88.5% attainment (46 ÷ 52 = 0.885). The webinar channel delivered 18 of those 46 SQMs, 39.1% of the weekly total (18 ÷ 46), making it the largest named contributor in the extract. Cost per SQM on paid search held flat at $150. One gap to name: the extract gives no paid-search SQM count, so total paid-search spend can't be derived from what's here. If someone needs a dollar figure for the week, that input has to come from the source system. SALES Sales converted 14 SQOs and set 9 DS2 meetings, creating $310,000 in new pipeline — $22,143 per SQO ($310,000 ÷ 14). Same-quarter close count was 3 for the week. The extract doesn't link those 3 closes back to specific SQOs, so a close rate per SQO isn't computable; pulling that number would need the deal-level tie-out. CS CS saved 2 renewals this week, with Team NPS at 61 and 3 open red-flag accounts heading into next week. No prior-week NPS reading and no renewal-save target appear in the extract, so no delta or attainment can be calculated for either — the 61 and the 2 stand as point-in-time values only. PLG PLG added 412 new signups at 31% activation — 128 activated companies (412 × 0.31 = 127.7). Of those, 38 companies reached the aha moment of 10 recognition gives: 9.2% of all signups (38 ÷ 412) and 29.7% of activated companies (38 ÷ 128). That 10-give threshold is where recognition stops being a feature people try and becomes a habit teams keep — the moment worth building the whole funnel around. Missing-data flags (all from the extract, nothing inferred): paid-search SQM volume, SQO-to-close linkage, prior-week NPS baseline, and any CS renewal-save target.
PARTNER DIGEST — 2026-08-24 to 2026-09-04 Source: partner_roster.csv, partner_slack.md, partner_deals.csv HEADLINE NUMBERS Partner-sourced pipeline (utm_source = Partner, all 5 rows in partner_deals.csv qualify): Deal-DDAAF2 180,000 Apex Rewards Co Deal-2CF33E 95,000 Apex Rewards Co Deal-F1CDA5 140,000 HRCloud Partners Deal-096E1D 60,000 CultureBridge Deal-067213 75,000 CultureBridge Count: 5 deals Amount: 180,000 + 95,000 + 140,000 + 60,000 + 75,000 = 550,000 Arithmetic: 180,000 + 95,000 = 275,000; 275,000 + 140,000 = 415,000; 415,000 + 60,000 = 475,000; 475,000 + 75,000 = 550,000 ACTIVE PARTNERS Apex Rewards Co — active 2 sourced deals, 275,000 (180,000 + 95,000). Co-webinar locked for 09-15 (Dana Mercer, 2026-08-25). Both opps in DS1, logged with UTM Source = Partner. Caveat: the 09-15 webinar falls after the reporting period; no outcome data exists for it. HRCloud Partners — active 1 sourced deal, 140,000 (Deal-F1CDA5). Integration referral cleared security review; opp advanced to DS2 (Alex Franklin, 2026-08-27). CultureBridge — active 2 sourced deals, 135,000 (60,000 + 75,000). Lunch-and-learn produced both opps; both described as early stage — no stage value given in the data (Farid Osman, 2026-08-29). WorkWell Group — active 0 sourced deals, 0 amount. No rows for WorkWell Group in partner_deals.csv. No sourced deals this period; partner wants to restart the joint playbook in Q4, planning call booked 09-09 (Dana Mercer, 2026-09-02) — that call is outside the period. QUIET PARTNERS (no Slack activity and no rows in partner_deals.csv this period) Recogniq — quiet: no sourced deals, no activity recorded. KudosWave — quiet: no sourced deals, no activity recorded. PeopleFirst Advisors — quiet: no sourced deals, no activity recorded. TotalPerk — quiet: no sourced deals, no activity recorded. ROSTER RECONCILIATION 8 partners in roster; 8 appear above (4 active, 4 quiet). Partner-sourced total: 5 deals / 550,000, tied to the 5 deal rows. MISSING DATA (not inferable from the files provided) - Close dates, win rates, and stage values beyond the DS1/DS2/early-stage labels quoted above. - No prior-period baseline in the data, so no period-over-period change can be stated. - No sourced-deal records of any kind for Recogniq, KudosWave, PeopleFirst Advisors, TotalPerk, or WorkWell Group.
QUESTIONNAIRE RESPONSE — Trust portal policy excerpts Source: policy_excerpts.md (P1–P8) only. No external facts used. Q1. Is customer data encrypted at rest? If so, how? Yes. All customer data is encrypted at rest using AES-256. Source: [P1] Q2. Is data encrypted in transit? Yes. Data in transit is encrypted with TLS 1.2 or higher. Source: [P1] Q3. Do you hold a SOC 2 report, and can we obtain a copy? Yes — SOC 2 Type II, renewed annually. A copy is available to prospects under NDA. Confirm the NDA route with our team if you want the full report rather than the summary. Source: [P2] Q4. How long is customer data retained after contract termination? Duration of the contract plus 90 days, after which data is deleted from production systems. Arithmetic: retention window = contract term + 90 days. Example: on a 12-month (365-day) term, deletion occurs no later than day 455 (365 + 90). The 90-day clock is not separately stated as starting at termination; the excerpt ties it to contract duration, so if your termination date differs from contract end date, get that clarified in writing. Source: [P3] Note: [P3] covers production systems only. Backup deletion timing is not stated — backup retention is 35 days [P6], after which a backup copy would age out of the retained window. Q5. Where is your subprocessor list published and how are changes notified? Published at trust.bonusly.com. Customers receive 30 days notice before a new subprocessor is added. Source: [P4] Gap: the excerpt does not state a notice mechanism for removals or changes to existing subprocessors, nor whether notice is email or portal posting. Q6. Do you support SAML single sign-on? Yes — SAML 2.0 single sign-on, plus SCIM user provisioning. Both are Enterprise plan features, not available on lower tiers. Source: [P5] Q7. What is your production backup schedule and retention? Daily backups, encrypted, retained 35 days. Arithmetic: at one backup per day, the retained window holds up to 35 daily restore points, with the oldest aging out each day (35 − 1 + 1 backfill). The excerpt does not state backup frequency beyond "daily," point-in-time recovery capability, or RPO/RTO, so I am not asserting those. Sources: [P6] Q8. Do you hold an ISO 27001 certification? Unanswerable from the provided excerpts. No excerpt mentions ISO 27001 or any certification other than SOC 2 Type II [P2]. Document needed: the certifications/accreditations page on trust.bonusly.com, or the security addendum if one exists. Q9. What is your contractual uptime SLA percentage? Unanswerable from the provided excerpts. No excerpt states an availability commitment, SLA percentage, or service credit terms. Backup and incident-notification language [P6], [P7] is operational, not a contractual uptime commitment. Document needed: the Master Subscription Agreement or Order Form SLA exhibit. Q10. Will you sign a HIPAA Business Associate Agreement? Unanswerable from the provided excerpts. No excerpt mentions HIPAA, PHI, or BAAs. Document needed: the Data Processing Agreement / security addendum, or written confirmation from Bonusly legal. Summary: 7 of 10 answered from excerpts (Q1–Q7). Q8, Q9, Q10 require documents not supplied. Encryption, access control, and incident-notification claims are stated as policy descriptions in the excerpts; they are not independently verified here, and [P2] is the only third-party attestation referenced.
SKILL SET RECONCILIATION — 14 files vs 14-row manifest
Session date used for staleness math: 2026-09-08. All counts derived only from the text provided.
=====================================================================
(7) MANIFEST DRIFT — checked first, because it sets the denominator
=====================================================================
FILE blocks provided = 15 total. Minus 1 manifest = 14 SKILL.md files.
Manifest data rows (excluding header) = 14.
14 − 14 = 0 files with no manifest row. 14 − 14 = 0 manifest rows with no file.
declared_name matches the file stem on all 14 rows (no case or hyphen mismatches).
F01 · INFO · REVIEW · Zero drift in either direction. The gap is structural, not
numeric: the manifest has no `version` column, yet 2 of 14 skills carry an in-body
version (analysis-validator "Version: 3.6"; pipeline-intelligence-report "version:
v6 · May 2026"). Version state is therefore invisible to the manifest.
Proposal: add a `version` column to skill_manifest.csv and populate from front-matter
or body header; leave all 14 rows otherwise untouched.
=====================================================================
(5) DESCRIPTIONS OVER 1,024 CHARACTERS
=====================================================================
Sorted description_chars: 656, 656, 676, 708, 762, 792, 897, 945, 962, 965, 996, 1004, 1006, 1006.
Max = 1,006. 1,006 ≤ 1,024, so count over cap = 0.
F02 · INFO · TRIM_DESC · Headroom is the real risk: 1,024 − 1,006 = 18 chars
(pipeline-intelligence-report, signalforge-claim-compressor) and 1,024 − 1,004 = 20
(partner-digest). All three carry "ALWAYS trigger for:" enumerations that only grow.
Proposal: pre-emptively trim the three longest descriptions to ≤ 900 chars by moving
their trigger enumerations into the body, leaving a one-line trigger in front-matter.
=====================================================================
(1) ALWAYS-TRIGGER OVERLAP / DUPLICATION
=====================================================================
F03 · CRITICAL · MERGE · email-drafter × comms-drafter
comms-drafter: "Use whenever ANYONE ... needs to write, draft, review, or improve any
external communication ... outbound prospecting, follow-ups, post-demo recaps,
stakeholder outreach, pricing and contract follow-up ... renewal and expansion emails,
QBR follow-ups, onboarding check-ins."
email-drafter: "Use this skill whenever anyone asks you to write, draft, review, or
improve a customer-facing email of any kind — outbound prospecting, follow-ups,
post-demo recaps, stakeholder follow-up, pricing follow-up, contract follow-up ...
renewal or expansion emails, QBR follow-ups, check-in emails, onboarding emails."
The email surface is fully contained in the comms surface. Shared verbatim triggers:
"write me an email", "draft a follow-up", "what should I say", "bump email", "contract
nudge". Both carry the identical contract follow-up benchmark block ("Thanks for the
update. This is really helpful..."), the identical 1–10 review rubric, the identical
Recommended / Softer / Firmer three-version output, and the same "point them to
deal-strategy-coach" lane marker. Only real difference: comms-drafter adds support,
Intercom, partner/rewards and the bonusly-brand Step 0; email-drafter adds the Gmail
signature retrieval step.
Proposal: MERGE email-drafter into comms-drafter as its email track — keep the Gmail
signature step as the one thing email-drafter uniquely owns — then delete email-drafter
and repoint the two inbound references (deal-strategy-coach "use the email-drafter
skill"; closed-lost-analysis has none).
F04 · CRITICAL · TRIM_DESC · weekly-pipeline-report × pipeline-intelligence-report
Direct phrase collisions on ALWAYS lists:
"pipeline update" (pipeline-intelligence-report) vs "run the pipeline update" /
"update the pipeline" (weekly-pipeline-report)
"what's the pipeline look like" (PIR) vs "what does pipeline look like" (weekly)
"run the pipeline report" (PIR) vs "generate the pipeline report" / "do the pipeline
report" / "give me this week's numbers" (weekly)
Both claim exclusivity: PIR — "Master pipeline scoring skill — never answer pipeline
questions inline without running it"; weekly — "ALWAYS trigger when the user says ...
or any variation." stale-pipeline-report compounds it with a third ALWAYS claim on
"pipeline hygiene". One utterance currently routes to two different HTML artifacts
(a 10-tab scored deal report vs a demand-gen funnel report) with no stated tiebreak.
Proposal: TRIM_DESC both — weekly-pipeline-report keeps marketing-funnel asks (SQM/SQO/
DS2 volume, bookings MTD, targets vs forecast, "weekly"/"mid-month") and PIR keeps
deal-level asks (score, tier, "which deals", forecast risk); add one explicit
exclusion sentence to each description naming the other skill and its lane.
F05 · INFO · REVIEW · analysis-validator × signalforge-claim-compressor ×
signalforge-feedback — all three ALWAYS-fire on the same output classes (reports,
pipeline updates, conversation analyses, forecast briefs). This one is declared
ordering, not a defect: compressor states "data pull → analysis → analysis-validator →
claim-compressor → output" and feedback states it fires "after analysis-validator and
after signalforge-claim-compressor". No action beyond recording the order.
Proposal: REVIEW — add the same one-line ordering note to analysis-validator's
description so the chain is stated in all three places, not two.
=====================================================================
(2) CIRCULAR DELEGATION CHAINS
=====================================================================
F06 · WARNING · REVIEW · CYCLE: deal-strategy-coach ↔ email-drafter
deal-strategy-coach → email-drafter: "When drafting manager-to-prospect emails, use
the email-drafter skill which automatically retrieves your Gmail signature..."
email-drafter → deal-strategy-coach: "For deal strategy, diagnosis, or coaching (not
email drafting), use deal-strategy-coach instead" and "If the user needs strategic
deal coaching ... point them to the deal-strategy-coach skill."
A→B→A with no termination rule. It is bounded in practice by the parenthetical
("not email drafting" / "not deal strategy"), but a request like "draft a manager email
for this stalled deal" satisfies both descriptions simultaneously.
Proposal: REVIEW — pick one owner for the composite ask (recommend deal-strategy-coach
owns diagnosis and hands the final draft step to the merged comms/email skill once,
with an explicit "do not hand back" clause), and record it in both descriptions.
F07 · WARNING · REVIEW · CYCLE: pipeline-intelligence-report ↔ closed-lost-analysis
pipeline-intelligence-report → closed-lost-analysis: Phase 2b "Delegate entirely to
the closed-lost-analysis skill (Mode 4 — Active Pipeline Risk Match)"; Non-Negotiable
5 "Loss Intel tab delegates to closed-lost-analysis skill. Do not re-implement loss
pattern logic here."
closed-lost-analysis → pipeline-intelligence-report: Mode 4 trigger list reads
"called from pipeline-intelligence-report", and its returned loss_risk_score re-enters
PIR at Phase 3 ("feeds Phase 3 penalty scoring").
Loop closes: PIR delegates out, CLA's Mode 4 exists only to serve PIR, and control
returns to PIR. Direction is stated in both files but with mismatched verbs
("delegates to" vs "called from"), so there is no written statement of who terminates.
Proposal: REVIEW — restate as a one-way contract in both bodies: PIR owns invocation
and termination, CLA Mode 4 is a pure subroutine that returns scores and never calls
back; delete the "called from" phrasing from CLA's Mode 4 trigger line.
=====================================================================
(3) DANGLING DELEGATION TARGETS (named, absent from the 14-file manifest)
=====================================================================
9 of 14 skills (64%) reference at least one target that does not exist in this set.
13 distinct missing targets:
F08 · WARNING · REVIEW · prospect-research-multithreading — highest fan-in: 5
references across 3 skills (comms-drafter x2, email-drafter x2, deal-strategy-coach x1).
Not optional: email-drafter and comms-drafter both gate drafting on it ("invoke ...
first"), and deal-strategy-coach says "Do not close a coaching session with a
multithread gap unaddressed — always offer the handoff."
Proposal: REVIEW — confirm it exists as an org/user skill; if not, either add it to the
manifest or delete all 5 references and replace the Contact Lookup step with a direct
HubSpot search instruction.
F09 · WARNING · REVIEW · bonusly-brand — 4 skills depend on it (comms-drafter Step 0
"apply the bonusly-brand skill", email-drafter, sales-forecast, signalforge-claim-compressor).
Proposal: REVIEW — same treatment; if it is an org-level skill outside this manifest,
say so explicitly in a manifest "external dependencies" block.
F10 · CRITICAL · REVIEW · signalforge-reports (/mnt/skills/organization/signalforge-reports/)
— 2 skills, both mandatory: pipeline-intelligence-report lists "MANDATORY PRE-BUILD
STEPS: 1. Read .../SKILL.md 2. Read .../DESIGN-SYSTEM.md 3. Embed .../signalforge.css";
weekly-pipeline-report requires the same reads before "writing a single line of HTML".
Two of the set's three HTML-producing skills hard-fail without it.
Proposal: REVIEW — verify the path resolves; if the file set is meant to be
self-contained, vendor the CSS and design system into the skill directories or record
signalforge-reports as an external dependency in the manifest.
F11 · WARNING · REVIEW · 8 specialist skills in analysis-validator §12.4:
bonusly-data-questions, bonusly-product-questions, bonusly-business-reporting-questions,
bonusly-rewards-questions, bonusly-ppp-questions, bonusly-feature-flag-questions,
bonusly-deal-desk-questions, bonusly-datadog-questions. The table instructs "always
delegate to specialist skill" for product behavior, rewards, flags, and legal claims.
Proposal: REVIEW — mark the table as external references rather than delegations, or
add the 8 to the manifest; as written the validator can route to skills that may not load.
F12 · INFO · REVIEW · skill-orchestrator (analysis-validator §11 cascading files;
signalforge-feedback activation checklist) and caveman /
JuliusBrussee/caveman (signalforge-claim-compressor "Relationship to Caveman Skill").
Both are external/legacy references with no functional dependency.
Proposal: REVIEW — no code change; annotate as external in the manifest dependency block.
=====================================================================
(4) VERSION CONFLICT
=====================================================================
F13 · WARNING · UPDATE_BODY · analysis-validator: v3.5 and v3.6 carry the SAME date.
Header: "**Version:** 3.6 ... Last Updated: May 9, 2026 (v3.6 — G2-F: ID Resolution...)"
Changelog: "3.6 | May 9, 2026 | G2-F ..." and "3.5 | May 9, 2026 | G1-L: Engagement
Coverage Check ..." — two distinct feature releases, one date.
Trail template §7: "Validator: analysis-validator v3.2" — stale by four minor versions.
§2 Full Mode and §6 decision tree both say "Gate 2 ... (G2-A through G2-E)", dropping
the G2-F check that v3.6 exists to add.
Which survives: v3.6. Corroborated three ways inside the file (front-matter header,
"Last Updated ... v3.6", footer "analysis-validator v3.6 · May 9, 2026") and once
outside it (pipeline-intelligence-report footer: "✓ SignalForge Validated · Analysis
Validator v3.6"). Nothing is lost by dropping 3.5 as a separate row: G1-L is already
present in the body, so 3.5's content is merged, not discarded.
Proposal: UPDATE_BODY — keep v3.6 as the single May 9, 2026 row (fold G1-L into it),
re-date the G1-L line to May 8, 2026 if you want the history preserved, change the §7
trail template "v3.2" to "v3.6", and extend "G2-A through G2-E" to "G2-A through G2-F"
in §2 and §6. Do not touch the version number itself.
F14 · INFO · REVIEW · No second version conflict, but version is declared
inconsistently across the set: only 2 of 14 skills state one (analysis-validator 3.6,
pipeline-intelligence-report v6 · May 2026), and the manifest cannot see either.
Proposal: REVIEW — resolve with F01 (add the version column).
=====================================================================
(6) HARDCODED PAGE IDS, DATES, PERSON NAMES IN BODIES
=====================================================================
F15 · CRITICAL · UPDATE_BODY · AE roster contradiction. analysis-validator §12.3
declares "These are the Core 6 AEs. Any 'full AE team' or 'Core 6' filter must include
all six IDs" and lists 6 (Bryce Harmon 119337721, Hugo Lindqvist 77260721, Dana Mercer
83155923, Alex Franklin 84342457, Cole Ingram 83155924, Gavin Porter 1520255671).
pipeline-intelligence-report Phase 1 lists 5 — Hugo Lindqvist (77260721) is absent.
6 − 5 = 1 AE silently dropped from every pipeline report, with no filter error raised.
Proposal: UPDATE_BODY — replace the 5-row roster in pipeline-intelligence-report with a
live `HubSpot:search_owners` resolution (the pattern stale-pipeline-report Phase 2
already uses: "Never hardcode rep names or owner IDs"), or at minimum add Hugo
Lindqvist 77260721 and mark the block [LIVE QUERY].
F16 · CRITICAL · UPDATE_BODY · model-selection `last_checked: 2026-05-19` with a
self-imposed 14-day 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").
2026-05-19 → 2026-09-08 = 112 days. 112 − 14 = 98 days past its own deadline. Every
price, context window, and model ID in the registry is therefore stale by rule
($1/$5 Haiku, $3/$15 Sonnet, $5/$25 Opus, claude-opus-4-7, 1M context, "Opus 4.6
deprecation announced April 14, 2026", knowledge cutoffs Feb 2025 / Aug 2025 / Jan 2026).
Proposal: UPDATE_BODY — run the self-update against
https://platform.claude.com/docs/en/about-claude/models/overview and reset
last_checked; also make the staleness check date-independent rather than a literal date.
F17 · WARNING · UPDATE_BODY · HubSpot deal URL pattern differs across skills.
pipeline-intelligence-report: https://app.hubspot.com/contacts/1973303/record/0-3/{hs_object_id}
next-to-close: https://app.hubspot.com/contacts/1973303/record/0-3/{hs_object_id}
stale-pipeline-report col K: https://app.hubspot.com/contacts/1973303/deal/{id}
Two of these three produce dead links. Also hardcoded org id 1973303 in all three.
Proposal: UPDATE_BODY — standardize stale-pipeline-report on the /record/0-3/ form and
move 1973303 to a single declared constant block per skill.
F18 · WARNING · UPDATE_BODY · weekly-pipeline-report hardcoded financials and recipient.
"Q1 2026 context (static): Sales Bookings Actual: $365,152 vs. $475,000 plan (77%);
Pipeline Addition Actual: $2,490,532 vs. $3,288,000 forecast (76%)." Arithmetic checks
(365,152 / 475,000 = 76.9% ≈ 77%; 2,490,532 / 3,288,000 = 75.7% ≈ 76%) but they are
frozen prior-quarter figures inside a skill that otherwise demands live pulls. Also
hardcoded: "Ben Lavin · Demand Generation · Bonusly" in the H1 plus 3 body references
("for Ben's review", "deliver the HTML file to Ben"), the Google Sheet IDs
1CLZeOsElVDF_LF0ZG_t2nfwvhnZ6bpwqM_nX3WEYzcw and
1ENuaEcCuLjdKhMvp8FK3Ys1ek5Aw9ZuOZhsHJJFoB_k, and "Q2 (April 1 – June 30, 2026;
total ≈ 64–65)".
Proposal: UPDATE_BODY — move the Q1 figures to the referenced spreadsheet read (Step
2B already reads live), parameterize the recipient, and compute the quarter window at
run time.
F19 · WARNING · UPDATE_BODY · sales-forecast contradicts its own quarter-agnostic rule.
Changelog v1.1 (April 27, 2026) claims "Quarter-agnostic (Q2 → current quarter
throughout)", yet the body still hardcodes Q2 in three places: "### 1A — HubSpot: Open
Q2 Deals", tab 6 "Q2 Narrative", and the title example "Q3 2026 Forecast Intelligence
— July 9, 2026" (a hardcoded month/day in a format template). Confluence IDs also
hardcoded: cloudId 73fe98de-a4a3-4869-9f8a-bb1eeed4cf7f, spaceId 2232811524, parent
2232582148. Person: "Alaina (VP Sales)" in the 2A heading "Manager Forecast (Alaina /
VP Sales view)".
Proposal: UPDATE_BODY — replace "Q2" with `[N]` in the 1A heading and the tab 6 name,
replace the title example's date with a placeholder, and resolve the owner via
HubSpot:search_owners rather than by name.
F20 · WARNING · UPDATE_BODY · analysis-validator contradicts its own no-hardcoding rule.
§8 header: "Do not use hardcoded figures. These counts change continuously." The same
section then gives fixed expected ranges (paying customers 3,000–3,500; provisioned
users 440,000–470,000; Gong calls 90d 850–1,100; open deals 150–350, labeled "as of
May 2026"), and G1-J pins ~452,000 and ~110,097. Additional hardcoded body values:
dates "March 28, 2023" (DEALS staleness), "May 4, 2026" (CALL_SPOTLIGHT_BRIEF removal,
roster, Gong routing, CLOSEDWON_DEALS currency), "May 9, 2026" (four changelog rows),
the ARR example "Q1 2026 · Jan 1 – Mar 31" and the SQL example "Q2 2026"; stage IDs
150582536/150582537/150582538/150582539/1175632767 in §12.2 and §13.3; 19 named people
with owner IDs in §12.3 (Alaina Loori 82535637, Shealagh Coughlin 119069206, Amani
Phipps 210200121, Ben Castelli 348210196, John Thomas 78303262, Yasmin Wahid 89062643,
7 CSMs, 6 AEs); and escalation names "Manish or Amani" in §10 and the G1-K HOLD block.
Proposal: UPDATE_BODY — tag every fixed figure [LIVE QUERY] and move the roster to a
run-time owner lookup; keep only stage IDs and pipeline name as declared constants.
F21 · INFO · UPDATE_BODY · Remaining hardcoded identifiers, grouped:
partner-digest — cloudId 73fe98de-a4a3-4869-9f8a-bb1eeed4cf7f, spaceId 1958248479,
folder 2286616609, reference page 2286321666, plus 5 canonical page IDs
(2265382925, 2236940297, 2237825028, 2239365136, 2238283777); Slack user
<@U03QLMBL7AR>; owner line "Amani Phipps (RevOps / Partnerships)"; partner contact
first names (Kelli, Jen Lee, Hani, Bryce, Sara); dates "May 19, 2026", "June 2,
2026", "May 16, 2026 issue", changelog 2026-05-17.
signalforge-feedback — page 2295136266, space 2232811524, parent 2234417154, Build
Log 2247295002, cloudId 73fe98de-...; example entries name "Gavin Porter" and
"Lowe's".
deal-strategy-coach — Confluence page 2257879045 ("AE Excellence Playbook April
2026"); full 2026 pricing grid; routing names "Farid" (.edu) and "Perseus" (India).
closed-lost-analysis — customer names baked into the taxonomy (Softheon, MinIO, Estee
Lauder, LIFTOFF, Nestlé, Ozinga, Aurora Innovation, GCash, Ethos Cannabis,
StickerYou); "the 30-deal AI-field sample from May 2026: 10 of 10 deals"; "rep
vacation May 4–12"; "demo on 4/13".
stale-pipeline-report — "Don't query all 97 deals serially" (hardcoded deal count);
Slack channel C0561C1JCPJ; excluded owner id 55483190 (Bonusly Support); changelog
2026-06-10.
signalforge-claim-compressor — example entities Panopto, Schneider Downs, Felix
Construction ($15K TCV); changelog 2026-05-09.
Proposal: UPDATE_BODY — leave true constants (cloudId, spaceId, channel ID, stage IDs)
but convert counts, dates, person names, and illustrative examples into either run-time
lookups or explicitly labeled "[example]" text so they cannot be read as current fact.
=====================================================================
FINDING COUNT BY SEVERITY AND ACTION
=====================================================================
CRITICAL (4): F03 MERGE · F04 TRIM_DESC · F10 REVIEW · F15 UPDATE_BODY · F16 UPDATE_BODY
— that is 5; recount: F03, F04, F10, F15, F16 = 5 CRITICAL.
WARNING (7): F06, F07, F08, F09, F11, F13, F17, F18, F19, F20 = 10 WARNING.
INFO (6): F01, F02, F05, F12, F14, F21 = 6 INFO.
Total 21 findings.
By action: UPDATE_BODY 8 (F13, F15, F16, F17, F18, F19, F20, F21) · REVIEW 8 (F01,
F05, F06, F07, F08, F09, F10, F11, F12, F14 — 10) · TRIM_DESC 2 (F02, F04) · MERGE 1
(F03). Corrected: REVIEW 10, UPDATE_BODY 8, TRIM_DESC 2, MERGE 1 = 21. No DELETE_SKILL
proposed — email-drafter's content is absorbed rather than discarded, and no skill is
unused or unreferenced.
Nothing was rewritten. Two counts you asked for are zero and I am reporting them as
zero rather than inventing findings: 0 descriptions over 1,024 chars, and 0 rows of
manifest drift in either direction.
RUNBOOK — incident-2026-08-29-reward-queue
Source: incident_thread.md only. Each step cites the message(s) it traces to.
"Needs confirmation" = the thread does not state it; do not fill it in.
-------------------------------------------------------------------------
STEP 1 — Acknowledge alert, assume Incident Commander
Action : Acknowledge PagerDuty alert (reward-worker queue depth > 10k);
declare self IC.
Who : Bryce Harmon
Trace : [M01] 14:02:10Z
Verify : NEEDS CONFIRMATION — thread states the ack and IC role but not
how acknowledgement was verified (no ack ID, no channel record).
Rollbk : N/A — no state changed.
STEP 2 — Measure queue depth (baseline)
Command: bundle exec rake sidekiq:queue_depth
Who : Farid Osman
Trace : [M02] 14:04:33Z
Result : reward queue = 48,213 pending jobs. Stated normal: under 500.
Stated alert threshold: > 10,000 ([M01]).
Verify : Command returned 48,213 ([M02]).
Rollbk : N/A — read-only.
STEP 3 — Inspect dead set
Action : Inspect the Sidekiq dead set.
Who : Farid Osman
Trace : [M03] 14:06:02Z
Result : 112 jobs, all Redis::TimeoutError, all from around 13:58.
Verify : NEEDS CONFIRMATION — thread gives the finding but NOT the command
or console path used to count/inspect the dead set.
Rollbk : N/A — read-only.
STEP 4 — Stop the bleed: pause enqueue (STATE CHANGE #1)
Command: bin/rails runner 'FeatureFlag.disable(:auto_recognition_enqueue)'
Who : Farid Osman
Trace : [M04] 14:08:45Z
Rollbk : bin/rails runner 'FeatureFlag.enable(:auto_recognition_enqueue)'
(rollback command given in [M04] itself; executed later at [M09])
Verify : NEEDS CONFIRMATION — [M04] states no verification. Nearest
supporting evidence is [M07] (depth falling) and [M08] (depth 0),
which are consistent with the pause but do not confirm the flag
state directly.
STEP 5 — Clear the dead set (STATE CHANGE #2 — destructive)
Action : "cleared out the dead set" while in the console — 112 jobs ([M03]).
Who : Elena Sinclair
Trace : [M05] 14:15:20Z
Verify : NEEDS CONFIRMATION — no command given, no post-clear count
reported, no confirmation the 112 jobs were retried, requeued,
or discarded.
Rollbk : NONE AVAILABLE — the thread provides no rollback for this step and
does not state whether the clear was recoverable. Treat as
irreversible pending confirmation.
STEP 6 — Scale workers up (STATE CHANGE #3)
Command: kubectl scale deployment/reward-worker --replicas=6 (was 3)
Who : Bryce Harmon
Trace : [M06] 14:21:07Z
Rollbk : kubectl scale deployment/reward-worker --replicas=3
(rollback command given in [M06]; executed later at [M10])
Verify : NEEDS CONFIRMATION — [M06] states no verification (no replica
count check, no pod-ready check). Next evidence is [M07].
STEP 7 — Observe drain
Action : Watch queue depth while draining.
Who : Farid Osman
Trace : [M07] 14:33:41Z
Result : depth 9,400 and falling ~1,200/min.
Verify : Value read from the queue ([M07]).
Rollbk : N/A — read-only.
STEP 8 — Verify recovery
Command: bundle exec rake sidekiq:queue_depth → returns 0
Also : Datadog error rate back to baseline (no metric name or value given).
Who : Cole Ingram
Trace : [M08] 14:47:55Z
Verify : queue_depth = 0 ([M08]); error rate at baseline per Datadog
([M08]) — baseline value NEEDS CONFIRMATION (not quantified).
STEP 9 — Re-enable enqueue (STATE CHANGE #4 — reverses Step 4)
Command: bin/rails runner 'FeatureFlag.enable(:auto_recognition_enqueue)'
Who : Bryce Harmon
Trace : [M09] 14:49:10Z
Verify : 40 new jobs processed cleanly in the following 3 minutes ([M09]).
No error named, no error count given.
Rollbk : bin/rails runner 'FeatureFlag.disable(:auto_recognition_enqueue)'
(inverse of [M04]; not stated in-thread as a rollback for [M09] —
NEEDS CONFIRMATION that this is the accepted re-pause path)
STEP 10 — Scale workers back down (STATE CHANGE #5 — reverses Step 6)
Command: kubectl scale deployment/reward-worker --replicas=3
Who : Bryce Harmon
Trace : [M10] 14:55:00Z
Verify : "Queue stable at 0" ([M10]) — self-reported by the same person who
made the change; no independent re-check equivalent to [M08].
NEEDS CONFIRMATION: how long "stable" was observed and by what
command/metric.
Rollbk : kubectl scale deployment/reward-worker --replicas=6
(inverse of [M06]; NEEDS CONFIRMATION)
Close : "Incident resolved" ([M10]).
-------------------------------------------------------------------------
ARITHMETIC (from thread values only)
Jobs drained between [M02] and [M07]:
48,213 - 9,400 = 38,813
Elapsed [M02] 14:04:33Z -> [M07] 14:33:41Z:
29 min 8 s = 29.13 min
38,813 / 29.13 = 1,332 jobs/min observed mean over the full window
Elapsed from the pause [M04] 14:08:45Z -> [M07] 14:33:41Z:
24 min 56 s = 24.93 min
38,813 / 24.93 = 1,557 jobs/min (post-pause mean; enqueue was disabled
during this window, so this is the cleaner drain estimate)
Both exceed the ~1,200/min stated in [M07]; the thread does not explain the
difference. Possible causes (NOT in the thread — do not assert): drain rate
was not constant, or the 1,200/min figure was a spot reading.
Extrapolation check against [M07]'s own rate:
9,400 / 1,200 = 7.83 min -> predicted empty at ~14:41:31Z
Actual reported 0 at [M08] 14:47:55Z -> ~6.4 min later than predicted.
Drain from [M07] 9,400 -> [M08] 0:
elapsed 14:33:41Z -> 14:47:55Z = 14 min 14 s = 14.23 min
9,400 / 14.23 = 661 jobs/min
Post-recovery throughput [M09]:
40 jobs / 3 min = 13.3 jobs/min (this is processing throughput after
re-enable, not a queue-depth figure; queue was already 0 at [M08]).
Scale factor [M06]: 3 -> 6 replicas = 2x. The thread gives no pre-scale drain
rate, so no throughput-per-replica calculation can be supported.
-------------------------------------------------------------------------
GAPS — the thread does not contain these; do not invent them
1. Root cause. The 112 dead jobs were all Redis::TimeoutError from ~13:58
([M03]), but no message names a cause for the timeouts and no message
describes a fix for them. The incident is closed at [M10] with the queue
drained, not with the underlying error resolved.
2. Command for Step 3 (dead-set inspection) and Step 5 (dead-set clear).
3. Verification for Steps 1, 4, 6 — none recorded.
4. Any baseline value for "Datadog error rate" ([M08]) or for "normal"
beyond "under 500" ([M02]).
5. Whether the 112 cleared jobs ([M05]) were requeued, retried, or lost.
6. Whether Steps 9 and 10 have accepted rollback paths (only Step 4 and
Step 6 carry in-thread rollback commands).
7. Post-incident action items, timeline of customer impact, or monitoring
left in place after [M10].
FAILURE SEQUENCE — datadog_logs.csv + sidekiq_jobs.csv
FIRST ERROR (t0)
2026-09-03T14:01:12Z reward-service ERROR
"Redis::TimeoutError: Connection to Redis at redis-primary:6379 timed out after 5s"
Last healthy reward-service signal before it: 13:59:09 health check ok.
Gap = 13:59:09 -> 14:01:12 = 123s = 2m03s of silence from that service.
Last reward-service enqueue before it: 13:59:30 (13:59:30 -> 14:01:12 = 102s).
No WARN anywhere in the slice precedes it. t0 is the first non-INFO line.
CASCADE, IN ORDER (all times 2026-09-03)
14:01:12 reward-service ERROR Redis connect timeout to redis-primary:6379 after 5s [ORIGIN]
14:01:20 reward-service ERROR retry exhausted for RewardGiveJob (+8s from t0)
14:01:30 reward-service ERROR retry exhausted for RewardGiveJob (+10s)
14:01:40 reward-service ERROR retry exhausted for RewardGiveJob (+10s)
14:01:40 sidekiq ERROR RewardGiveJob failed: Redis::TimeoutError; retrying in 60s
14:02:28 sidekiq ERROR RewardGiveJob failed; retrying
14:02:30 sidekiq WARN "Queue reward depth above 10,000" (+78s = 1m18s from t0)
14:03:05 api-gateway ERROR 502 upstream timeout calling reward-service /gives (+113s = 1m53s)
14:03:30 web-app ERROR Give form submission failed: upstream 502 from api-gateway (+138s = 2m18s)
14:03:31 / 14:04:22 / 14:05:26 / 14:06:47 sidekiq ERROR RewardGiveJob failed; retrying
14:03:48 / 14:04:13 / 14:05:16 / 14:06:52 api-gateway ERROR 502 upstream timeout calling reward-service
14:04:45 / 14:05:42 / 14:06:49 web-app ERROR Give form submission failed: upstream 502
14:22:10 reward-service INFO Redis connection restored; resuming job processing (+20m58s from t0)
14:24:45 sidekiq INFO Queue reward depth below 500 (+2m35s after restore; +23m33s from t0)
Shape: async path breaks first (enqueue/retry), backlog builds (2m), then the synchronous
read/write path times out at the gateway (502), then the user-facing form fails. Recovery is
bottom-up: Redis -> reward-service -> queue drain.
Line counts in the slice (non-INFO): reward-service ERROR 4 (1 connect + 3 retry-exhausted),
sidekiq ERROR 6, sidekiq WARN 1, api-gateway ERROR 5, web-app ERROR 4 = 20 lines total.
SERVICE AND JOB INVOLVED
Originating service: reward-service (holds the Redis connection; emits t0 and the restore).
Job: RewardGiveJob — named explicitly in reward-service (3x) and sidekiq (6x) lines.
Propagated to: sidekiq (worker/queue "reward"), api-gateway (502s on /gives), web-app (Give form).
Second job class, from sidekiq_jobs.csv only: RecognitionDigestJob — 4 failures
(J-00013 14:02:36, J-00014 14:03:15, J-00015 14:04:55, J-00016 14:05:50). Never named in the
logs, so its queue and whether it hit the same Redis instance are unconfirmed.
sidekiq_jobs.csv: 16 rows, 100% Redis::TimeoutError.
12 RewardGiveJob (J-00001..J-00012), 4 RecognitionDigestJob (J-00013..J-00016) = 16.
Earliest job failure J-00005 at 14:01:46 = 34s after t0. Latest J-00016 at 14:05:50.
Job failure window 14:01:46 -> 14:05:50 = 244s = 4m04s.
DATADOG QUERY TO CONFIRM THE FIRST ERROR
Primary (pins t0):
service:reward-service status:error "Redis::TimeoutError" "redis-primary:6379"
time: 2026-09-03T14:00:00Z -> 14:02:00Z, sort ascending, take first
Expected: earliest hit 2026-09-03T14:01:12Z; nothing earlier in the service.
Corroborating queries:
Blast radius / when each tier broke:
service:(reward-service OR sidekiq OR api-gateway OR web-app) status:error
time: 2026-09-03T14:00:00Z -> 14:10:00Z, group by service, sort ascending
-> expect reward-service first (14:01:12), sidekiq 14:01:40, api-gateway 14:03:05, web-app 14:03:30
Job attribution:
service:sidekiq "RewardGiveJob failed" status:error (expect 6 in window)
Backlog:
service:sidekiq "Queue reward depth" (expect the >10,000 WARN at 14:02:30 and the <500 INFO at 14:24:45)
Recovery:
service:reward-service "Redis connection restored" (expect 14:22:10)
Note: the CSV exposes only timestamp/service/level/message — there is no job_id or queue
attribute to facet on, so group by service, not by job.
WHAT THE LOGS DO NOT SHOW
1. Root cause of the Redis timeout. There are zero lines from service "redis" or redis-primary
in the slice. No evidence for network partition, failover, memory pressure/eviction, CPU,
or connection-pool exhaustion. Cause is unknown from this data.
2. What fixed it. "Redis connection restored" at 14:22:10 states no action — no restart,
deploy, failover, or config change is logged. The 20m58s between t0 and restore is
unexplained; no remediation event appears.
3. Actual queue depth. Only two threshold strings: >10,000 (14:02:30) and <500 (14:24:45).
No peak, no series, no drain rate. Jobs/min throughput cannot be computed.
4. Whether any job eventually succeeded. No success/completion lines after 14:22:10. No
confirmation that RewardGiveJob retries landed, and no idempotency or duplicate-give
information. Data loss vs. delayed delivery cannot be distinguished.
5. Business impact magnitude. No user IDs, org/company IDs, give amounts, or counts of failed
submissions — only 4 web-app error lines. Total affected users/dollars is unknown.
6. Job-to-log linkage. Logs carry no job_id, so J-00001..J-00016 cannot be mapped to the 6
sidekiq ERROR lines. 16 CSV failures vs. 6 log lines means the logs are sampled or
aggregated; they do not reconcile 1:1.
7. Job_id ordering is not chronological — J-00005 fails at 14:01:46, before J-00001 at
14:01:51. Do not read job_id as sequence.
8. Retry timing does not match the stated policy: sidekiq says "retrying in 60s" at 14:01:40
(implies 14:02:40) but the next sidekiq failure line is 14:02:28, 48s later.
9. Postgres involvement: postgres appears only as INFO checkpoints (14:10:56 through 14:20:59),
no errors. DB involvement is neither confirmed nor ruled out.
10. Completeness and boundaries. The slice runs 13:55:13 -> 14:24:45; anything before or after
is unknown, including whether the queue fully drained and whether the 16 jobs are the
complete failure set. No alerting, on-call, or customer-comms timeline is present.
FEATURE FLAG STATE (source: flags_export.csv + flag_code.md)
Per-flag summary
1. recognition_streaks_v2 — ON
Controls: in app/models/recognition.rb, when enabled it calls StreakTracker.record(give) on a give.
Who has it: segment:beta_companies — 42 companies.
Targeting rule: segment:beta_companies.
2. points_budget_guardrails — ON
Controls: in app/services/budget_service.rb, when enabled it runs BudgetService.new(company).enforce!(giver, points) — budget enforcement on a points give.
Who has it: all_companies — 220 companies.
Targeting rule: all_companies.
3. slack_dm_nudges — ON
Controls: in app/jobs/nudge_job.rb, a guard clause — return unless enabled; when enabled it calls SlackDm.send_nudge(user).
Who has it: segment:region_na — 87 companies.
Targeting rule: segment:region_na.
4. redeem_flow_redesign — OFF
Controls: in app/controllers/redeem_controller.rb, chooses which redemption UI to render — RedeemV2Component.new(company) when on, else RedeemV1Component.new(company).
Who has it: targeted_list — 12 companies (targets exist, but no named companies are in the export).
Targeting rule: targeted_list.
5. analytics_dashboard_v3 — ON
Controls: in app/controllers/analytics_controller.rb, when enabled sets @dashboard = AnalyticsV3.new(company).
Who has it: segment:tier_three — 65 companies.
Targeting rule: segment:tier_three.
6. ms_teams_app_v2 — OFF
Controls: in app/services/teams_installer.rb, when enabled calls TeamsAppV2.install(company).
Who has it: targeted_list — 9 companies (no named companies in the export).
Targeting rule: targeted_list.
7. legacy_give_modal — OFF
Controls: NO code reference in flag_code.md — cannot state what it controls from the data provided.
Who has it: segment:legacy_plan — 14 companies.
Targeting rule: segment:legacy_plan.
8. survey_boosters_q3 — ON
Controls: NO code reference in flag_code.md — cannot state what it controls from the data provided.
Who has it: segment:legacy_plan — 7 companies.
Targeting rule: segment:legacy_plan.
9. paused_offboard_cleanup — OFF
Controls: NO code reference in flag_code.md — cannot state what it controls from the data provided.
Who has it: no targets — company_count 0.
Targeting rule: blank (none) in the export.
Flags with no code reference
legacy_give_modal, survey_boosters_q3, paused_offboard_cleanup — none of the three appear in flag_code.md. Their behavior is not derivable from the provided data.
Flags with no targets
paused_offboard_cleanup — targeting_rules empty, company_count 0. It is the only flag with no targets.
Notes and caveats
- No individual company names appear anywhere in the export. Every "who has it" answer above is a segment (beta_companies, region_na, tier_three, legacy_plan), the all_companies scope, or an unnamed targeted_list. The specific companies on the two targeted_list flags (redeem_flow_redesign, ms_teams_app_v2) are not in the provided data.
- Counts are taken exactly as exported, including for OFF flags: an OFF flag still lists targets (e.g. redeem_flow_redesign 12, ms_teams_app_v2 9, legacy_give_modal 14). Those are target counts, not live-enabled companies — since the flag is off, none of those companies are actually receiving the new behavior.
- Shared segment: segment:legacy_plan is used by two flags — legacy_give_modal (off, 14) and survey_boosters_q3 (on, 7). The export does not say whether those 7 are a subset of the 14; no relationship can be assumed.
Arithmetic
ON flags: 42 + 220 + 87 + 65 + 7 = 421
42 + 220 = 262; 262 + 87 = 349; 349 + 65 = 414; 414 + 7 = 421
OFF flags: 12 + 9 + 14 + 0 = 35
12 + 9 = 21; 21 + 14 = 35; 35 + 0 = 35
All flags: 421 + 35 = 456
Cross-check vs raw export: 42 + 220 + 87 + 12 + 65 + 9 + 14 + 7 + 0 = 456
- 456 is the sum of per-flag target counts, not a unique company count. Companies can appear on more than one flag (e.g. all_companies overlaps every other scope), so no unique-company total is derivable from this export. Note the internal inconsistency that points_budget_guardrails is scoped all_companies at 220 while the sum of all flag counts is 456 — the export provides no basis to reconcile those two numbers.
NDA TRIAGE — 3 inbound NDAs (source: ndas.md only) NDA-1 — [PARTY A] and Bonusly → GREEN (standard approval) Driver 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: all five standard carve-outs present, mutual, Delaware law, and "No license, no obligation to proceed, no exclusivity" — no embedded restraint, so nothing to escalate. Term math: 2 years term + 3 years survival = 5 years maximum exposure (2 + 3 = 5), but the obligation is passive confidentiality only, which is the market norm. NDA-2 — [PARTY B] and Bonusly → YELLOW (counsel review) Driver 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: an embedded mutual non-solicit sits inside an otherwise standard NDA — the "hire" prohibition is broader than "solicit" (it bars accepting an inbound applicant), and "came into contact under this Agreement" has no knowledge or seniority limit, so it needs counsel to narrow. Term math: 3 years term + 18 months tail = 4.5 years of hiring restriction (3 + 1.5 = 4.5), well beyond the NDA's own stated life. Note: no survival clause is stated for the confidentiality obligation in NDA-2 — that gap is missing data, not a defect I can score. NDA-3 — [PARTY C] and Bonusly → RED (full legal review) Driver clause: "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." Reasoning: four compounding defects — (1) a 3-year non-compete with no definition of "Discloser's business" and no carve-out for existing lines of business; (2) "No confidentiality carve-outs are stated in this Agreement," so there is no public-domain, prior-knowledge, or legally-required-disclosure defense; (3) it is "One-way confidentiality in favor of [PARTY C]," meaning Bonusly is the bound Recipient and receives no reciprocal protection; (4) governing law shifts to "the laws of the Republic of Ireland, and the parties submit to the exclusive jurisdiction of its courts," a forum change from the Delaware law in NDA-1 and NDA-2 that imports cost and enforceability risk. Term math: 5 years confidentiality vs. 3 years non-compete — the restraint outlasts nothing but the disclosure period is 2 years longer than the restraint (5 − 3 = 2). Missing data I could not assess (no facts provided): - No Effective Date for any NDA, so no absolute calendar end dates can be computed. - Counterparty names are redacted ([PARTY A/B/C]); I cannot check whether any is a competitor, which would change NDA-3's non-compete risk. - No definition of "Confidential Information," no remedy/injunctive-relief clause, and no return-or-destroy obligation in any of the three. - Bonusly's own standard/template terms are not in the file, so I cannot score these against an internal baseline — only against the terms as written.