Mean 0.947 · 32/40 perfect tests · $1.85 total · each card: the question → the correct answer (gold) → this model's actual answer
Definitions (applied to deals_open.csv, 156 rows):
- DS2+ deal: stage ∈ {DS2, DS3, DS4, DS5}.
- Substantive why_buys: non-empty, ≥15 chars, not a placeholder (tbd/n/a/see notes). A value of the form LONG(n) counts as present/substantive (real text truncated for display).
- No-DS1: empty t_ds1 field.
- Regressed: any earlier-stage timestamp is later than a later-stage timestamp (e.g. t_ds2 > t_ds3).
Numbers:
- DS2+ deals: 124 (of 156 total; 32 are DS1).
- why_buys non-compliant overall: 101 / 124 = 81.45%.
Arithmetic: 101 ÷ 124 = 0.81452.
- By owner (DS2+ only):
- Alex Franklin (84342457): 48 / 61 = 78.69%
- Dana Mercer (83155923): 18 / 22 = 81.82%
- Bryce Harmon (119337721): 15 / 18 = 83.33%
- Cole Ingram (83155924): 19 / 22 = 86.36%
- Farid Osman (716654662): 1 / 1 = 100.00%
- No DS1 timestamp: 0.
- Regressed: 0.
Three process fixes:
1. Gate stage advancement on why_buys — block DS2→DS3 progression in the CRM unless why_buys is non-empty and ≥15 chars, so the field is captured at the moment intent is demonstrated rather than backfilled later.
2. Add a pipeline-hygiene exception report (or dashboard) keyed by owner, surfacing DS2+ rows with blank/placeholder why_buys daily, and make per-owner why_buys fill-rate a standing metric in rep 1:1s (Franklin and Ingram are the biggest raw offenders).
3. Normalize why_buys as a structured field (required enum/free-text with length floor) plus a validation rule that rejects placeholders — eliminating both the blank-value problem and the need for LONG(n) display truncation, so substantive text is verifiable at the record level rather than inferred.
Done. Here's the result, computed directly from the two files (156 open deals, 6 distinct owner ids). NUMBER OF DEALS RESOLVED 156 (all open deals). Every deal's owner_id matched an entry in owners.csv. DEALS WITH UNMATCHED OWNER ID None. All 6 distinct owner ids present in deals_open.csv are accounted for in owners.csv. OWNER IDS MAPPING TO ARCHIVED/DEACTIVATED OWNERS None. The two archived owners in the table — Gavin Porter (1520255671) and Hugo Lindqvist (77260721) — do not appear as owner_id on any open deal. All 6 owner ids used by open deals have archived = false. TOTAL PIPELINE AMOUNT PER RESOLVED OWNER (amount = sum of the "amount" field for each deal, unrounded) Bryce Harmon (119337721): 1,054,144.00 Alex Franklin (84342457): 624,310.00 Dana Mercer (83155923): 341,195.00 Cole Ingram (83155924): 288,161.43 Farid Osman (716654662): 4,134.00 Elena Sinclair (701163055): 2,100.00 TOTAL: 2,314,054.43 Notes on arithmetic: Cole Ingram's total includes fractional amounts (7225.4, 7781.2, 6947.5, 58529.25, 2480.4, 3334.8, 4779.88, etc.), so his figure is not a whole number. Farid Osman's 4,134.00 is six "$1" placeholder deals plus one 2,880 deal (1+1+1+1+1+1+2880 = 2,886, plus one more $1,248 deal = wait — let me flag: his total is 4,134, which is 1+1+1+1+1+1+2880+... I'll list the six deals explicitly to avoid any ambiguity). Farid Osman (716654662) deal breakdown: Deal-499BF6 = 1,249 + Deal-03BA69 = 1 + Deal-117863 = 1 + Deal-F17780 = 1 + Deal-8BA24E = 2,880 + Deal-2B39B0 = 1 + Deal-8FDCD2 = 1 = 4,134. Correct. Elena Sinclair (701163055): Deal-57FF13 = 2,100. Correct. No names were guessed for any id — every resolved id has an explicit row in owners.csv.
Results below. All arithmetic from the data as provided. (a) Orphan gong rows (deal id with no match in deals_open) Gong rows total: 67. Deals_open rows total: 156. Orphans: 30 rows (gong deal id not found in deals_open). Sample aliases (from the data): Deal-8FA85D, Deal-8FC3F9, Deal-3B7945, Deal-42B265, Deal-9CCC42, Deal-36EA09, Deal-9A43B4, Deal-605F3C. (Note: these 30 orphans all cluster in the later rows of the gong table — deal ids beginning 60251…/60250…/60248… etc., which simply don't appear in deals_open. That is exactly the "calls logged but deal no longer open" pattern.) (b) Duplicate conversation keys (calls_90d > distinct_conversation_keys) Count: 0. Every gong row has calls_90d exactly equal to distinct_conversation_keys (e.g. 11/11, 9/9, 46/46, 24/24). No row exceeds its distinct key count. (c) Open deals at DS3+ with at least one logged call Open deals at stage DS3, DS4, or DS5: 85. Of those, deals whose id appears in the gong table (i.e. ≥1 logged call): 25. Share = 25 / 85 = 0.2941 ≈ 29.4%. Caveat on interpretation: "logged call" here means the deal id exists in gong_calls_by_deal_90d. If a DS3+ deal simply has no gong record at all, it counts as no logged call (not as zero). This is the correct reading given the two tables provided, but worth flagging in case the intent was to treat "no row in gong" differently from "row with 0 calls." Also note: gong_owner_id is a Gong user id, not a HubSpot owner id (as you flagged), so I did not join on owner across the two tables — only on deal id.
I can't write a correct query from this catalog, because the data required for two of the three metrics is not present in it. Here is exactly what's missing, cited against the catalog: 1. Unique givers — no source. The catalog has no raw giving/recognition events table and no giver dimension. The only giving-related fields anywhere in the catalog are the pre-aggregated columns in PRODUCTION.PLG.COMPANY_COHORT_SUMMARY (M1_GIVES, M1_REDEMPTIONS, M1_USERS), which are (a) PLG/self-serve only, (b) already bucketed into M1/M2/M3 rather than raw events, and (c) contain no per-giver granularity, so a "unique givers" count cannot be derived from them. 2. Recognition count — no source. Same gap. Recognition count requires raw give events; the catalog exposes only the pre-aggregated M1_GIVES in COMPANY_COHORT_SUMMARY, not an events table. Note the business rule "a filter excluding deleted givers exists in some giving queries ... must NOT be applied to historical giving counts" references a giving table that is NOT listed in this catalog excerpt — that table is the one I would need and it is absent here. 3. Successful redemption count — partial source only. PRODUCTION.DEPRECATED_RECOGNITION.REDEMPTION_RECORDS_V2 is the documented redemption source (STATE = 'succeeded' only). But the catalog documents no company/date/identifier columns for this table — only the STATE filter rule — so it cannot be joined to "customer company" or "first calendar month" without column names I don't have. 4. "Customer company" and "first calendar month as a customer" — no clean join source. COMPANY_COHORT_SUMMARY provides SIGNUP_DATE / ACTIVATED_DATE / FIRST_SUB_PAYMENT_DATE but only for self-serve (PLG) companies and carries no way to tie a company to raw redemption events. The HubSpot deal tables (V2_DAILY.OBJECTS_DEALS is canonical; V2_LIVE.OBJECTS_DEALS is UNPOPULATED and PRODUCTION.HUBSPOT.DEALS is STALE and both must be avoided) give closed-won dates for sales-sourced customers but have no giving/recognition/redemption linkage in the catalog. Because I must not invent tables, columns, or numbers, there is no valid single Snowflake query I can produce from this catalog alone. To write it I would need at least: (a) a raw gives/recognition events table with giver_id, company_id, and event timestamp, and (b) the column list for REDEMPTION_RECORDS_V2 (company_id and redemption timestamp, plus its giver/user key). None of those are present in the excerpt provided.
I've worked through the three files row-by-row. One thing up front, because it changes what I can deliver:
DEALS DATA IS MISSING. No deals.csv was provided. I cannot audit deal-field completeness (owner, stage, amount, close date, why-buys), and I cannot rank fixes by pipeline amount — there is no amount data anywhere in the extract. I flag this instead of inventing numbers. For the final "10 fixes," I rank by account size (employee_count) as the only monetary-adjacent signal available, and I label it as a proxy, not pipeline value.
═══════════════════════════════════════════
1. COMPLETENESS AUDIT
═══════════════════════════════════════════
Companies (34 rows):
industry 34/34 = 100.0% filled (all present, but non-standardized — see §5)
employee_count 25/34 = 73.5% filled (9 blank)
hq_country 28/34 = 82.4% filled (6 blank)
Blank employee_count (9):
C-EC3025, C-96039F, C-44EA29, C-D04904, C-B23205,
C-60C75F, C-7BBDFA, C-50D386, C-93C8BF
Blank hq_country (6):
C-2D1F1B, C-D73B89, C-44EA29, C-D04904, C-2C60E5, C-EE9FFB
Contacts (52 rows):
email 48/52 = 92.3% filled (4 invalid/truncated)
title 39/52 = 75.0% filled (13 blank)
persona 37/52 = 71.2% filled (15 blank)
Blank title (13):
CT-0000, CT-0022, CT-0072, CT-0080, CT-0081, CT-0092,
CT-0120, CT-0121, CT-0122, CT-0132, CT-0141, CT-0162, CT-0170
Blank persona (15):
CT-0000, CT-0022, CT-0041, CT-0060, CT-0070, CT-0081, CT-0082,
CT-0092, CT-0110, CT-0132, CT-0162, CT-0171, CT-0172, CT-0180, CT-0181
Deals (0 rows provided): cannot audit.
═══════════════════════════════════════════
2. DUPLICATE COMPANY CLUSTERS
═══════════════════════════════════════════
Cluster A — shared domain acme-corp.com:
C-0A092931 Technology, 500, US
C-0A092932 tech, 510, USA
Discrepancy: employee_count 500 vs 510; industry "Technology" vs "tech"; country "US" vs "USA".
Survivor: C-0A092931 (keep). Re-verify employee count before merge (list both: 500 / 510).
Cluster B — shared domain globex.io:
C-0A092933 SaaS, 200, US
C-0A092934 Technology, 200, US
Discrepancy: industry "SaaS" vs "Technology" only (emp 200 and US agree).
Survivor: C-0A092933 (keep; "SaaS" is the more specific, correct category).
No other shared domains or name variants among the hex-style aliases. Neither cluster has contacts attached, so merging won't orphan any contact rows.
═══════════════════════════════════════════
3. INVALID EMAILS & DOMAIN MISMATCHES
═══════════════════════════════════════════
Invalid/truncated emails (missing domain after "@") — 4:
CT-0010 user0@ (company C-66D1FC)
CT-0080 user0@ (company C-92D97D)
CT-0081 user1@ (company C-92D97D)
CT-0192 user2@ (company C-425E2A)
Domain mismatch (email domain ≠ company domain) — 1:
CT-0011 user1@other-domain.com vs company domain 66d1fc.com (company C-66D1FC)
═══════════════════════════════════════════
4. FILL FROM ENRICHMENT (only where a matching row exists)
═══════════════════════════════════════════
employee_count — 8 of 9 blanks can be filled from ZoomInfo, all to 400:
C-EC3025 -> 400 C-96039F -> 400 C-44EA29 -> 400 C-D04904 -> 400
C-B23205 -> 400 C-60C75F -> 400 C-7BBDFA -> 400 C-50D386 -> 400
C-93C8BF -> NO enrichment row for 93c8bf.com; cannot fill.
hq_country — NONE of the 6 blanks can be filled from enrichment:
C-2D1F1B, C-D73B89, C-44EA29, C-D04904, C-2C60E5 -> enrichment country is also blank.
C-EE9FFB -> no enrichment row at all.
These need a different source; I will not invent values.
Note: enrichment has 25 rows; companies has 34. The 9 companies with NO enrichment row are:
C-BA969B, C-332637, C-93C8BF, C-EE9FFB, C-C9BB20,
C-0A092931, C-0A092932, C-0A092933, C-0A092934
═══════════════════════════════════════════
5. CRM vs ENRICHMENT DISAGREEMENTS
═══════════════════════════════════════════
No true value conflicts (nothing like "Retail vs Finance"). Two taxonomy/format disagreements:
(a) Industry — CRM "Technology"/"tech"/"Tech " vs ZoomInfo "Computer Software" (10 companies):
C-66D1FC (tech), C-EC3025, C-44EA29 (tech), C-92D97D, C-D04904,
C-77A95A, C-AA8DDA, C-B25F40, C-60C75F (tech), C-425E2A (Tech )
Recommend: adopt ZoomInfo "Computer Software" (more granular, standard taxonomy).
(b) Country format — CRM "US"/"USA" vs ZoomInfo "United States" (10 companies):
"US": C-66D1FC, C-950043, C-77A95A, C-B23205, C-D0662E
"USA": C-EC3025, C-96039F, C-E51FB7, C-425E2A, C-2D7423
Recommend: standardize to "United States". No genuine country conflict.
employee_count: no disagreements among filled values (all filled CRM values match ZoomInfo exactly).
═══════════════════════════════════════════
6. TOP 10 FIXES (ranked by account size; NOT pipeline — no deals data)
═══════════════════════════════════════════
1. Merge acme-corp.com duplicates (C-0A092931 + C-0A092932); resolve 500 vs 510.
2. Merge globex.io duplicates (C-0A092933 + C-0A092934); resolve SaaS vs Technology.
3. Fill 8 blank employee_count = 400 from ZoomInfo (C-EC3025, C-96039F, C-44EA29,
C-D04904, C-B23205, C-60C75F, C-7BBDFA, C-50D386) — 400-person accounts missing a key field.
4. Source hq_country for 6 blanks externally (C-2D1F1B, C-D73B89, C-44EA29, C-D04904,
C-2C60E5, C-EE9FFB) — enrichment cannot supply them.
5. Fix 4 invalid emails (CT-0010, CT-0080, CT-0081, CT-0192).
6. Fix domain mismatch CT-0011 (other-domain.com vs 66d1fc.com) — a 900-person account.
7. Normalize industry taxonomy (10 companies -> "Computer Software"; also "health care"->Healthcare).
8. Normalize country codes (10 companies US/USA -> "United States").
9. Backfill 13 blank contact titles.
10. Backfill 15 blank personas, and obtain contacts for the 14 companies with zero contact rows
(C-2C60E5 through C-0A092934).
To deliver the actual "10 fixes by pipeline amount" ranking, I need the deals/pipeline file (owner, stage, amount, close date, why-buys per deal). Provide it and I'll re-rank against real dollars.
Note on scope first: the file only spans 2026-07-29 → 2026-09-30 (~2 months), not 6. I classified all 90 rows present, and I'm flagging that the "last 6 months" window appears to be truncated in the data you provided.
Classification of every deal (alias → category / side; [D] = tag disagrees with free-text):
TIMING (19) — all side: buyer
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, Deal-55867E
COMPETITOR (26)
side buyer (9): Deal-422BA6 (ADP TotalSource PEO partner), Deal-1BCA50, Deal-5E64CE (Nectar contract lock), Deal-8A0992 (Canadian provider), Deal-D0C698 (past Kudos user), Deal-47F1A1 (WorkTango), Deal-BF2A98 (HiThrive), Deal-369281 (paylocity), Deal-9FCD0D (Canadian company/CEO)
side Bonusly (6): Deal-F97C37 (more diversified offerings), Deal-DDAB52 (Rippl), Deal-242273 (points-currency digitization), Deal-A2C349 (Awardco + surveying), Deal-286F9C (not a good fit), Deal-DC77FE (more customization)
side unknown (11): Deal-F7F635, Deal-381C8C, Deal-F1E8A6, Deal-ACE061 (HeyTaco guess), Deal-2D2F8D, Deal-0F96AA (RFP), Deal-7CC678, Deal-C7156E, Deal-EECC02, Deal-1E7DA9, Deal-64B19A (Motivosity guess)
NO DECISION (31)
side buyer (25): Deal-AC944F, Deal-214060, Deal-13E9CF, Deal-F308CA, Deal-4664E1, Deal-E74A73, Deal-8E27DA [D], Deal-7CB44D, Deal-50E5D8, Deal-AFA56C, Deal-413C56, Deal-2A292B, Deal-D1AABF, Deal-FEDBCB, Deal-2BBA21, Deal-7FBAC6, Deal-386F6E, Deal-2FEDDB, Deal-3F86A0, Deal-096750, Deal-ABD14C, Deal-79E61A, Deal-AE7C4E, Deal-DAB4F1, Deal-B4B50F
side unknown (6): Deal-21B045, Deal-988493, Deal-D48E0B, Deal-583ADB, Deal-E0441F, Deal-5885B9
PRICING (6)
side buyer (5): Deal-7ED004, Deal-C33D91, Deal-5AD03E [D], Deal-DAFB82, Deal-8A119B
side Bonusly (1): Deal-7B2236 (wanted "simpler and cheaper")
PRODUCT GAP (4) — all side Bonusly
Deal-70F704 [D], Deal-9048EB [D], Deal-3618CC [D], Deal-981AD4
CHAMPION LEFT (2) — both side buyer
Deal-FAC17C, Deal-F325A5
OTHER (2)
Deal-5DB9B0 [D] (side unknown — "Spam"), Deal-ED9AE7 [D] (side buyer — "Timing, budget, authority")
---
SUMMARY
Category counts (90 total):
- timing 19
- competitor 26
- no decision 31
- pricing 6
- product gap 4
- champion left 2
- other 2
Check: 19+26+31+6+4+2+2 = 90 ✓
Side split:
- buyer 61
- Bonusly 11
- unknown 18
Check: 61+11+18 = 90 ✓
Arithmetic: timing 19 + no-decision buyer 25 + competitor buyer 9 + pricing buyer 5 + champion-left buyer 2 + other buyer 1 = 61 buyer. Bonusly = 6 (competitor) + 1 (pricing) + 4 (product gap) = 11. Unknown = 11 (competitor) + 6 (no decision) + 1 (other) = 18.
Tag vs free-text disagreements: 7
1. Deal-5DB9B0 — tag "Lost- Does not fit ICP" vs reason "Spam"
2. Deal-9048EB — tag "MIA" vs reason "bad fit… multiple feature gaps" (real cause = product gap)
3. Deal-3618CC — tag "Lost DM" vs reason "Wanted Surveys" (product gap)
4. Deal-8E27DA — tag "Feature Request" vs reason "swag provider, didn't want R&R" (no decision)
5. Deal-5AD03E — tag "Competitor" vs reason "Wanted more defined budget access" (pricing)
6. Deal-70F704 — tag "Lost DM" vs reason "only automate anniversary awards… MIA" (scope/product gap)
7. Deal-ED9AE7 — tag "Lost DM" vs reason "Timing, budget, authority" (multiple/mixed)
Two patterns most worth acting on:
1. Buyer-side inaction, not competition, is the dominant loss driver — and much of it has a concrete re-entry date. timing (19) + no decision (31) = 50 of 90 deals (56%), and 61 of 90 (68%) sit on the buyer side. Crucially, a large share of these aren't hard "no"s — they carry explicit revisit windows ("early 2027", "Q2 next year", "reconnect next year", "on hold"). This is a nurture/sequencing opportunity: build a structured "revisit 2027" cadence rather than treating these as dead. The flip side is a qualification gap — a heavy run of "unresponsive/MIA/no contact since intro" (Deal-AC944F, Deal-214060, Deal-F308CA, Deal-4664E1, Deal-2BBA21, Deal-7CB44D, and many more) suggests deals are being worked that never had real intent.
2. When a competitor wins with a stated reason, it's a feature/scope gap, not price. Only 1 of 90 (Deal-7B2236) is attributed to Bonusly's price, and multiple losses explicitly say price was NOT the issue (Deal-DC77FE "competitive in price so that wasn't a factor"; Deal-13E9CF "Not a budget issue"). The recurring Bonusly-side reasons are: surveys (Deal-3618CC, Deal-A2C349 "add their surveying"), points-as-currency/customization (Deal-242273, Deal-DC77FE "label points as dollars"), "more diversified offerings" beyond R&R (Deal-F97C37, Deal-DDAB52 "Rippl offers a lot more"), and UI/regional fit (Deal-981AD4 "not UK focused"; Deal-8A0992 + Deal-9FCD0D Canadian). That's a product-roadmap + positioning signal, not a pricing problem.
One data-quality caveat worth its own line: 11 competitor losses and 6 no-decision losses have "unknown" side because the reason text gives no usable signal ("Nothing specific provided", "Went another direction", "MIA", rep guesses like Deal-ACE061 "I feel they went with HeyTaco" and Deal-64B19A "Likely stayed with Motivosity"). Improving loss-reason capture there would sharpen both patterns above.
{
"tier_counts": {"LOCK": 3, "ACTION": 12, "BUILD": 36, "REVIVE": 4, "WATCH": 95, "RISKY": 6},
"tier_examples": {
"LOCK": ["Deal-D348E1", "Deal-C26D20", "Deal-403845"],
"ACTION": ["Deal-25F752", "Deal-944310", "Deal-3974EB"],
"BUILD": ["Deal-D73B89", "Deal-523604", "Deal-CA7DC0"],
"REVIVE": ["Deal-2D1F1B", "Deal-7BBDFA", "Deal-3EED2C"],
"WATCH": ["Deal-E53952", "Deal-5408B0", "Deal-9AAE5F"],
"RISKY": ["Deal-547B2B", "Deal-B7EBD1", "Deal-A2B47C"]
},
"risky_deals": ["Deal-547B2B", "Deal-B7EBD1", "Deal-A2B47C", "Deal-2465CE", "Deal-584EE5", "Deal-FD9F4E"],
"lock_violations": 0,
"pipeline_shape": "156 open deals are heavily bottom-weighted: 105 PIPELINE vs 40 BEST_CASE and only 11 COMMIT, with stage mass concentrated at DS2/DS3. Inbound is thin — only 55 of 156 deals logged any meetings in 30 days. That leaves 95 WATCH (zero meetings, email-only contact), 4 REVIVE (fully stale), and 6 RISKY COMMITs carrying zero meetings against their forecast. Just 3 deals clear LOCK (late-stage COMMITs with live meetings), and 12 ACTION/36 BUILD hold the only real meeting motion."
}
Here are the extracted CRM write-back fields. Every field is sourced strictly from prospect statements; rep utterances are excluded. Arithmetic and any inference are flagged inline.
```json
[
{
"transcript_id": "TX-001",
"deal_alias": "Deal-CFE7F4",
"why_buys": [
"Automating anniversary and birthday awards — HR team of three cannot keep up manually (VP People)",
"Avoid people slipping through the cracks (HR Admin)"
],
"pain_points": [
"HR team of three can't keep up with anniversary/birthday awards manually",
"Everything tracked in a spreadsheet; people slip through the cracks"
],
"stakeholders": ["VP People", "HR Admin"],
"budget_signal": "$40k earmarked for engagement tools this fiscal year (prospect-stated)",
"timeline_signal": "Live before open enrollment in November",
"competitor_mentioned": "Achievers (prospect raised; 'too heavy for a team our size')",
"next_step": "Security review on September 12 (explicitly agreed by VP People)",
"objections": ["SSO and audit logs required for IT sign-off"],
"confidence": "High"
},
{
"transcript_id": "TX-002",
"deal_alias": "Deal-70BB30",
"why_buys": [
"Tie recognition to retention for hourly workforce — regretted turnover over 30% (Head of Total Rewards)"
],
"pain_points": [
"Regretted turnover over 30% in hourly workforce"
],
"stakeholders": ["Head of Total Rewards", "CFO"],
"budget_signal": "$25k pilot budget approved by Finance for this quarter (prospect-stated)",
"timeline_signal": "Decision by end of September",
"competitor_mentioned": null,
"next_step": "Send pilot agreement; routed to legal this week (explicitly agreed by CFO)",
"objections": ["Workday integration must be rock solid (CFO condition)"],
"confidence": "High"
},
{
"transcript_id": "TX-003",
"deal_alias": "Deal-530B50",
"why_buys": [
"Make recognition visible across 12 retail locations (People Ops Manager)"
],
"pain_points": [
"Store managers have zero budget autonomy for on-the-spot recognition"
],
"stakeholders": ["People Ops Manager", "CEO (decision-maker, not present)"],
"budget_signal": null,
"timeline_signal": "No rush until Q1",
"competitor_mentioned": "Bucketlist (prospect raised; CEO used and liked it at prior company)",
"next_step": "Schedule a call with CEO; prospect will send two times (explicitly agreed)",
"objections": ["CEO must be sold first — decides anything people-related"],
"confidence": "Medium"
},
{
"transcript_id": "TX-004",
"deal_alias": "Deal-180D02",
"why_buys": [
"Consolidate three separate recognition tools into one (VP People)"
],
"pain_points": [
"Paying for three tools, none of which talk to their HRIS"
],
"stakeholders": ["VP People", "IT Security Lead", "CFO (mentioned, not present)"],
"budget_signal": "Under $15k annually = VP People can approve without board (prospect-stated approval threshold)",
"timeline_signal": "Procurement cycle runs six to eight weeks minimum",
"competitor_mentioned": null,
"next_step": null,
"objections": [
"Security review took three months for last vendor (IT Security Lead's hesitation)"
],
"confidence": "Medium"
},
{
"transcript_id": "TX-005",
"deal_alias": "Deal-F8767A",
"why_buys": [
"Automate service milestones (HR Director)",
"Analytics on recognition equity across departments (HR Director)"
],
"pain_points": [
"Night-shift teams feel invisible; engagement scores run 20 points lower (People Ops Coordinator)"
],
"stakeholders": ["HR Director", "People Ops Coordinator", "Exec team (mentioned, not present)"],
"budget_signal": "$12k approved under engagement line (prospect-stated)",
"timeline_signal": "Running before January all-hands",
"competitor_mentioned": "Nectar (prospect raised; mid-pilot)",
"next_step": "Present to exec team on October 2 (explicitly agreed)",
"objections": [
"Exec team skeptical after a failed rollout two years ago"
],
"confidence": "Medium"
},
{
"transcript_id": "TX-006",
"deal_alias": "Deal-EE195F",
"why_buys": [
"Cut admin time on service awards (HR Manager)"
],
"pain_points": [
"Spends five hours a month ordering and shipping plaques"
],
"stakeholders": ["HR Manager", "COO (mentioned, not present)"],
"budget_signal": null,
"timeline_signal": "Q1 start realistic (fiscal year resets in February)",
"competitor_mentioned": null,
"next_step": "Send one-pager; forwarded to COO this week (explicitly agreed)",
"objections": [
"COO usually prefers building things in-house"
],
"confidence": "Medium"
}
]
```
Notes on where I held the line against inventing:
- TX-003 budget: the rep quoted "$8 per employee per month," but the prospect never stated a budget, so budget_signal is null (not "8/employee"). Rep's line excluded by rule.
- TX-006 competitor: prospect explicitly said "Nobody else — comparing this against just doing it internally." That is a build-vs-buy stance (also reflected under objections via the COO's in-house preference), not a named vendor, so competitor_mentioned stays null.
- TX-004 next_step: VP People said "Maybe — I need to check her calendar, no promises," which is not an explicitly agreed next step, so it is null.
- Confidence is my analyst judgment from the prospect-only signals (not a CRM data field): TX-001 and TX-002 are High (stated budget + locked next step); the rest are Medium — TX-003 (no budget, Q1, CEO gate), TX-004 (long procurement/security friction, no locked step), TX-005 (active Nectar pilot + exec skepticism), TX-006 (build-in-house COO preference).
Missing-data flags: no transcript provided a stated budget for TX-003 or TX-006; no named competitor for TX-002, TX-004, or TX-006; no explicitly agreed next step for TX-004.
Based on the Slack thread overriding the CRM, the three deals closest to signature right now: **1. Deal-547B2B — $11,200** Why close: Alex Franklin's Slack update — "redlines came back clean this morning, the signing page is out, and their VP People told me they are signing tomorrow." Strongest signal in the thread. What's left: the actual signature (execution). **2. Deal-403845 — $9,000** Why close: Dana Mercer reports it "moving fine — the order form is with their finance team." CRM already has it at DS5/COMMIT with a 2026-09-11 close date, and no blocker was flagged in Slack. What's left: finance approval and countersignature. **3. Deal-A2B47C — $6,360** Why close: Franklin confirms it's "still warm, just normal legal-review pace," and its CRM close date (2026-09-11) is the earliest among the two "warm" deals he named. DS5/COMMIT. What's left: legal review to complete. **Note on a trap:** Deal-2465CE ($5,400) sits in the CRM as DS5/COMMIT with a 2026-09-10 close date — the earliest of all — but Slack shows it's actually blocked: the champion left and procurement froze new vendors. Mercer is "pulling it out of commit; it is blocked until they re-staff." So it does not belong on this list despite what the CRM says. Deal-D348E1 ($13,770) is also warm but its close date (2026-10-15) is further out, so it ranks below A2B47C.
Analysis below. One upfront flag before the findings:
AMOUNTS ARE MISSING FROM THE DATA. The transcripts CSV contains only `transcript_id, deal_alias, speaker, line_text` — there is no deal-amount column anywhere in either file. I cannot name amounts without inventing them, so every row below reports amount as "NOT PROVIDED." I will not fabricate a dollar figure.
---
Candidate-by-candidate classification
1) Deal-EC3025 — SCIM user provisioning
Prospect (IT Security Lead): "We need SCIM user provisioning — our security team will not approve any tool that requires manual account management."
Docs: "SCIM user provisioning and ADP Workforce Now integrations are NOT currently listed as supported capabilities."
Classification: REAL GAP. SCIM is not a listed capability on any tier (Core/Pro/Enterprise). The rep's "I'll flag that for our product team" corroborates it isn't currently available.
Amount: NOT PROVIDED.
2) Deal-D0D6B5 — ADP Workforce Now integration
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: HRIS integrations listed are Workday, BambooHR, Gusto, Rippling only. "ADP Workforce Now integrations are NOT currently listed as supported capabilities."
Classification: REAL GAP. ADP is absent from the supported-integrations list across all plans.
Amount: NOT PROVIDED.
3) Deal-CFE7F4 — Custom report builder
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: "Custom report builder — Core: —, Pro: —, Enterprise: yes."
Classification: PLAN GATE (not a product gap). The capability EXISTS in the product but is tier-gated to Enterprise. The feature is built; the prospect is on a lower plan. Rep's "sits on our Enterprise tier" matches the docs.
Amount: NOT PROVIDED.
4) Deal-84DBA6 — Slack adoption / training
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: "Slack and Microsoft Teams integration — yes (all plans)."
Classification: ROLLOUT / ENABLEMENT ISSUE. The Slack integration is a shipped, supported capability. The gap is adoption and training, not a missing product feature.
Amount: NOT PROVIDED.
5) Deal-36C33F — Mobile app
Source: Alex Franklin (REP): "Full transparency — we don't have a native mobile app for hourly workers yet, though it's on the roadmap."
Classification: EXCLUDED — REP LANGUAGE. The only "gap" voiced here comes from the rep, not the prospect. The prospect's actual reply ("The web version should be fine for our office staff for now") accepts the current state and raises no gap.
Amount: NOT PROVIDED.
---
SUMMARY — TRUE PRODUCT GAPS (prospect voice, feature absent from product docs)
• Deal-EC3025 — SCIM user provisioning (prospect: "our security team will not approve any tool that requires manual account management"). Not a supported capability on any tier.
• Deal-D0D6B5 — ADP Workforce Now payroll integration (prospect: "that's a dealbreaker for us"). Not in the supported-integrations list.
Both are genuine, docs-confirmed product gaps. No deal amounts were provided in the source data, so amounts are unknown. No arithmetic was required — the task contained no quantitative fields to compute.
Analysis complete. Here are the results. Snapshot: 2026-09-05. "Stale" = no logged email, call, or meeting within the last 7 days (most recent of last_email / last_call / last_meeting falls on or before 2026-08-28). The deal-level `last_contacted_field` was ignored as instructed. One data caveat: 17 deals carry a `last_meeting` date in the future (e.g. 2026-09-14, 09-15). A future meeting is a *scheduled* event, not a logged contact, so I excluded those future dates from the recency calculation and list them at the end. This did not flip any deal's stale/fresh classification. ═══════════════════════════════════════ STALE OPEN DEALS BY OWNER ═══════════════════════════════════════ BRYCE HARMON — 18 stale deals, total $692,964.00 Deal-2D1F1B | DS1 | $240,000.00 | 81 days (meeting) Deal-66D1FC | DS1 | $99,000.00 | 16 days (email) Deal-950043 | DS1 | $70,000.00 | 19 days (email) Deal-B23205 | DS1 | $45,000.00 | 16 days (email) Deal-7BBDFA | DS3 | $37,440.00 | 46 days (email) Deal-332637 | DS2 | $36,000.00 | 9 days (email) Deal-1BEEBF | DS1 | $31,500.00 | 19 days (email) Deal-A414F6 | DS1 | $25,200.00 | 19 days (email) Deal-C5658B | DS1 | $23,400.00 | 16 days (email) Deal-40522D | DS3 | $21,000.00 | 19 days (email) Deal-C1FA6D | DS1 | $18,000.00 | 16 days (email) Deal-01E193 | DS1 | $12,600.00 | 8 days (email) Deal-F0EBBB | DS3 | $11,400.00 | 24 days (email) Deal-927338 | DS1 | $10,920.00 | 18 days (email) Deal-E25A09 | DS1 | $6,000.00 | 9 days (email) Deal-C9C286 | DS2 | $5,502.00 | 9 days (email) Deal-012CB1 | DS1 | $1.00 | 23 days (email) Deal-3795AD | DS2 | $1.00 | 8 days (email) DANA MERCER — 16 stale deals, total $279,495.00 Deal-44EA29 | DS2 | $60,000.00 | 10 days (email) Deal-E51FB7 | DS2 | $43,875.00 | 12 days (call) Deal-B42F46 | DS1 | $27,000.00 | 19 days (email) Deal-BA3DDC | DS3 | $23,400.00 | 15 days (call) Deal-9DDE86 | DS2 | $20,000.00 | 15 days (email) Deal-215CCA | DS3 | $18,900.00 | 17 days (meeting) Deal-5EED42 | DS3 | $16,250.00 | 11 days (email) Deal-57887A | DS2 | $15,000.00 | 8 days (email) Deal-944310 | DS4 | $10,500.00 | 33 days (email) Deal-B7EBD1 | DS5 | $9,000.00 | 16 days (email) Deal-3974EB | DS4 | $9,000.00 | 8 days (email) Deal-F40F04 | DS2 | $8,100.00 | 15 days (email) Deal-7599B8 | DS3 | $7,350.00 | 18 days (email) Deal-87DDD1 | DS1 | $5,000.00 | 19 days (email) Deal-F336B6 | DS3 | $4,200.00 | 15 days (email) Deal-0660B4 | DS4 | $1,920.00 | 16 days (meeting) ALEX FRANKLIN — 20 stale deals, total $113,936.00 Deal-CC08D1 | DS1 | $24,000.00 | 16 days (email) Deal-E73427 | DS3 | $18,000.00 | 10 days (email) Deal-885F45 | DS2 | $9,300.00 | 12 days (email) Deal-C2FF3C | DS1 | $8,316.00 | 10 days (email) Deal-3EED2C | DS2 | $7,200.00 | no contact logged (no engagement record) Deal-0D2F7A | DS3 | $5,100.00 | 12 days (call) Deal-6C60D4 | DS3 | $4,800.00 | 12 days (call) Deal-13FEBD | DS2 | $4,680.00 | 12 days (call) Deal-819506 | DS1 | $4,400.00 | 8 days (email) Deal-9D0060 | DS3 | $3,840.00 | 12 days (email) Deal-690476 | DS2 | $3,600.00 | 18 days (call) Deal-C6D97A | DS4 | $3,240.00 | 8 days (email) Deal-EE195F | DS3 | $3,120.00 | 8 days (email) Deal-278DEC | DS3 | $2,700.00 | 8 days (email) Deal-635B8E | DS3 | $2,600.00 | 18 days (email) Deal-6883F3 | DS1 | $2,400.00 | 16 days (email) Deal-4A13AD | DS3 | $2,160.00 | 26 days (email) Deal-F67D31 | DS2 | $1,800.00 | 8 days (email) Deal-5FDCE4 | DS3 | $1,600.00 | 12 days (email) Deal-BA571A | DS4 | $1,080.00 | 18 days (email) COLE INGRAM — 18 stale deals, total $252,905.03 Deal-D04904 | DS2 | $58,529.25 | 11 days (email) Deal-B25F40 | DS3 | $40,000.00 | 8 days (email) Deal-813836 | DS2 | $32,175.00 | 11 days (email) Deal-1BA595 | DS2 | $31,750.00 | 11 days (email) Deal-CFE1E8 | DS3 | $18,000.00 | 11 days (email) Deal-CD47A6 | DS2 | $12,168.00 | 11 days (email) Deal-627646 | DS3 | $11,193.00 | 11 days (email) Deal-FF809F | DS2 | $7,781.20 | 11 days (email) Deal-AF932D | DS2 | $7,225.40 | 11 days (email) Deal-A71728 | DS2 | $6,947.50 | 11 days (email) Deal-8BC9F5 | DS2 | $5,616.00 | 10 days (email) Deal-175395 | DS3 | $4,779.88 | 11 days (email) Deal-481E24 | DS3 | $4,140.00 | 10 days (call) Deal-C7F9BF | DS2 | $3,360.00 | 11 days (email) Deal-2F3A66 | DS3 | $3,334.80 | 11 days (email) Deal-342E96 | DS2 | $2,700.00 | 24 days (email) Deal-E568D5 | DS3 | $1,875.00 | 11 days (email) Deal-FD9F4E | DS5 | $1,330.00 | 10 days (email) FARID OSMAN — 2 stale deals, total $2,881.00 Deal-8BA24E | DS1 | $2,880.00 | 8 days (email) Deal-8FDCD2 | DS1 | $1.00 | 15 days (email) ELENA SINCLAIR — 1 stale deal, total $2,100.00 Deal-57FF13 | DS1 | $2,100.00 | no contact logged (no engagement record) ═══════════════════════════════════════ PER-OWNER SUMMARY ═══════════════════════════════════════ Bryce Harmon: 18 stale deals, $692,964.00 Dana Mercer: 16 stale deals, $279,495.00 Alex Franklin: 20 stale deals, $113,936.00 Cole Ingram: 18 stale deals, $252,905.03 Farid Osman: 2 stale deals, $2,881.00 Elena Sinclair: 1 stale deal, $2,100.00 Note on data quality (for transparency, does not change classifications): Future-dated `last_meeting` values (scheduled, treated as not-yet-occurred): Deal-C26D20 (09-14), Deal-944310 (09-15), Deal-62D607 (09-22), Deal-523604 (09-14), Deal-3795AD (10-02), Deal-036E80 (09-11), Deal-01E193 (09-09), Deal-C1FA6D (09-15), Deal-93C8BF (09-14), Deal-927338 (09-17), Deal-A414F6 (09-10), Deal-FA053A (09-15), Deal-819506 (09-09), Deal-7599B8 (09-10), Deal-117863 (09-16), Deal-8BA24E (09-15), Deal-8FDCD2 (09-15) Two deals (Deal-3EED2C under Alex Franklin, Deal-57FF13 under Elena Sinclair) have no row in the engagements table at all, so they have no logged activity on record — I counted them as stale with "no contact."
Computation complete. Here are the results. Snapshot: 2026-09-05; "last 30 days" window = 2026-08-06 through 2026-09-05. Per-rep totals (emails_30d + calls_30d + meetings_30d) and DS2 entries (t_ds2 within window): ``` Rep (owner) Emails Calls Mtgs Total DS2 | Mix (E/C/M) | Activities/DS2 Alex Franklin 307 36 41 384 18 | 79.9% / 9.4% / 10.7% | 21.3 Bryce Harmon 162 0 43 205 4 | 79.0% / 0.0% / 21.0% | 51.3 Dana Mercer 84 18 11 113 1 | 74.3% / 15.9% / 9.7% | 113.0 Cole Ingram 96 14 1 111 2 | 86.5% / 12.6% / 0.9% | 55.5 Farid Osman 38 0 34 72 1 | 52.8% / 0.0% / 47.2% | 72.0 Elena Sinclair 0 0 0 0 0 | n/a | n/a ``` Arithmetic (Alex Franklin example): 307+36+41 = 384 total; 384/18 = 21.33 activities per DS2 entry. Mix: 307/384 = 79.9%, 36/384 = 9.4%, 41/384 = 10.7%. Efficiency ranking (lowest activities per DS2 entry = most efficient): 1. Alex Franklin — 21.3 2. Bryce Harmon — 51.3 3. Cole Ingram — 55.5 4. Farid Osman — 72.0 5. Dana Mercer — 113.0 6. Elena Sinclair — undefined (0 activities, 0 DS2 entries) Most efficient rep: Alex Franklin (21.3 activities per DS2 entry). Highest-volume rep: Alex Franklin (384 total activities — also the most DS2 entries, 18). They do NOT differ — the most efficient rep and the highest-volume rep are the same person (Alex Franklin). Notes / data caveats (no cause attributed): - Elena Sinclair has a single open deal (Deal-57FF13, DS1) with no engagements recorded and no DS2 entry in the window, so she has no activity mix or efficiency ratio to report. - Two Alex Franklin deals fell just outside the window (t_ds2 2026-08-04 and 2026-08-05) and were excluded: Deal-13FEBD and Deal-55164C. - Gavin Porter and Hugo Lindqvist are archived (archived=true) and have no deals in the open-deals file, so they were not evaluated.
QTD Scorecard — Alex Franklin (as of 2026-09-05, quarter 2026-Q3)
BOOKINGS vs QUOTA
Quota: $200,000 (quota.csv, snapshot 2026-09-05)
Bookings QTD: $150,000 across 8 closed-won deals
Attainment: 75.0%
Arithmetic: 40,000 + 20,000 + 35,000 + 21,000 + 12,000 + 11,000 + 6,500 + 4,500 = 150,000
Excluded: Deal-B3E6F1 ($24,000, closed-won 2026-06-20) — dated before the quarter.
NEW vs EXPANSION
New: $113,500 (5 deals: A1C3E5, B7D2F4, C9E1A6, D4B8C2, E6F3A9)
Expansion: $36,500 (3 deals: F2C7D8, A8B4D6, C5D9E2)
Split: 75.7% new / 24.3% expansion (113,500 + 36,500 = 150,000)
ACTIVE PIPELINE BY STAGE (open deals)
DS1: 20 deals — $284,621
DS2: 28 deals — $353,760
DS3: 67 deals — $552,705
DS4: 5 deals — $23,574
DS5: 5 deals — $45,730
Total: 125 deals — $1,260,390
ROLLING 90-DAY DS2-TO-WON RATE
Window: entered DS2 on/after 2026-06-07 (90 days before snapshot)
Closed deals entering DS2 in window: 35 (8 won + 27 lost)
Rate: 8 / 35 = 22.9%
Excluded: Deal-B3E6F1 (entered DS2 2026-05-10, outside window)
WINS / LOSSES (QTD)
Wins: 8
Losses: 27
Top loss reason: "Lost- Timing (1 year or more)" — 13 losses
Other reasons: MIA (5), Competitor (5), Lost DM (2), Feature Request (1), Lost-Does not fit ICP (1)
ACTIVITY VOLUME (last 30 days, all deals)
Emails: 807
Calls: 112
Meetings: 128
Notes: 50
Total: 1,097 touchpoints
COACHING OBSERVATIONS
1. Attainment gap is volume-wide, not an anomaly: at 75% of quota with only 25 days left, closing the remaining $50,000 requires roughly $1,500+/day in additional closed bookings, while the DS4+DS5 pipe ($69,304) can't fully cover the gap even at 100% conversion.
2. The 90-day DS2-to-won rate of 22.9% is thin relative to a 27-deal loss pool; the single largest driver ("Lost-Timing," 13 of 27 losses = 48%) signals deals are spending too long between DS2 entry and decision — a process/velocity problem more than a product-fit one. Timing + MIA together account for 18 of 27 losses (67%).
3. Pipeline is deeply back-weighted in DS3 ($552,705 across 67 deals) but top-of-funnel quality is unproven: 20 DS1 deals hold $284,621 yet show near-zero engagement in the 30-day activity (most open deals have 0 calls/meetings), suggesting the funnel is wide but not being worked to close — focus activity (112 calls across 125+ open deals is ~0.9/deal) on the DS3–DS5 deals closest to a decision.
Data scope check first: neither CSV contains an `amount` column nor a `stage` column. deal_contacts.csv has only: deal_id, deal_alias, company, contact_key, title, persona, last_engaged_date, is_former. So I cannot report amount or stage, and I cannot rank "most valuable persona to add" strictly by stage — I substitute a standard rule (economic buyer > finance > IT security > HR admin) and flag that explicitly below.
Active contact definition applied: last_engaged_date within 60 days of 2026-09-06 (cutoff 2026-07-08) AND is_former = false.
Contacts dropped as inactive/former:
- CT-F2C1AE (Deal-EC3025): former=true
- CT-A902AE (Deal-92D97D): 2026-06-01 (older than cutoff)
- CT-405B45, CT-86B22F (Deal-36C33F): former=true
- CT-913581 (Deal-F9A08A): 2026-06-20 (older than cutoff)
=====================================================================
FLAGGED DEALS (11 of 14 open deals)
=====================================================================
1) Deal-EC3025 (C-FDD0C7) — SINGLE-THREADED
Amount: not provided | Stage: not provided
Active contacts: 1 (CT-047C54, champion)
Personas present: champion
Personas missing: economic buyer, HR admin, IT security, finance
Most valuable to add: economic buyer
On-file unengaged fit: CT-6827DB, Chief People Officer (economic buyer)
2) Deal-92D97D (C-E23238) — SINGLE-THREADED
Amount: not provided | Stage: not provided
Active contacts: 1 (CT-01F5B4, HR admin)
Personas present: HR admin
Personas missing: economic buyer, champion, IT security, finance
Most valuable to add: economic buyer
On-file unengaged fit: none on file
3) Deal-50D386 (C-EB10E4) — UNDER-THREADED (2 active < 3)
Amount: not provided | Stage: not provided
Active contacts: 2 (CT-AA41B2 champion, CT-B9C35B HR admin)
Personas present: champion, HR admin
Personas missing: economic buyer, IT security, finance
Most valuable to add: economic buyer
On-file unengaged fit: CT-A1C4B3, Chief People Officer (economic buyer)
4) Deal-D0D6B5 (C-32918E) — UNDER-THREADED (all 3 contacts in one persona)
Amount: not provided | Stage: not provided
Active contacts: 3 (all champion: CT-87CED4, CT-DE6D7C, CT-FD70B2)
Personas present: champion (only)
Personas missing: economic buyer, HR admin, IT security, finance
Most valuable to add: economic buyer
On-file unengaged fit: CT-1FA4DB, Chief People Officer (economic buyer)
5) Deal-5BFE3B (C-535D36) — UNDER-THREADED (2 active < 3)
Amount: not provided | Stage: not provided
Active contacts: 2 (CT-57123B champion, CT-5CE757 champion)
Personas present: champion (only)
Personas missing: economic buyer, HR admin, IT security, finance
Most valuable to add: economic buyer
On-file unengaged fit: none on file
6) Deal-36C33F (C-077A0E) — SINGLE-THREADED
Amount: not provided | Stage: not provided
Active contacts: 1 (CT-4FE556, IT security)
Personas present: IT security
Personas missing: economic buyer, champion, HR admin, finance
Most valuable to add: economic buyer
On-file unengaged fit: CT-1DB73E, Chief People Officer (economic buyer)
7) Deal-885F45 (C-5E8EFB) — UNDER-THREADED (2 active < 3)
Amount: not provided | Stage: not provided
Active contacts: 2 (CT-51C81E economic buyer, CT-D9A0E8 champion)
Personas present: economic buyer, champion
Personas missing: HR admin, IT security, finance
Most valuable to add: finance (economic buyer already engaged; budget/contract authority is next-highest value)
On-file unengaged fit: none on file for finance.
Note: IT security contact IS on file (CT-B3F25D, IT Security Lead) if security review is the actual bottleneck.
8) Deal-FCBE5B (C-737030) — SINGLE-THREADED
Amount: not provided | Stage: not provided
Active contacts: 1 (CT-4A5317, champion)
Personas present: champion
Personas missing: economic buyer, HR admin, IT security, finance
Most valuable to add: economic buyer
On-file unengaged fit: none on file
9) Deal-5408B0 (C-2AE3AA) — UNDER-THREADED (2 active < 3)
Amount: not provided | Stage: not provided
Active contacts: 2 (CT-D33AE4 champion, CT-8742FD HR admin)
Personas present: champion, HR admin
Personas missing: economic buyer, IT security, finance
Most valuable to add: economic buyer
On-file unengaged fit: CT-07FA76, Chief People Officer (economic buyer)
10) Deal-C6D97A (C-5A8FC2) — UNDER-THREADED (all 3 contacts in one persona)
Amount: not provided | Stage: not provided
Active contacts: 3 (all champion: CT-223DDC, CT-B03555, CT-4E8A2B)
Personas present: champion (only)
Personas missing: economic buyer, HR admin, IT security, finance
Most valuable to add: economic buyer
On-file unengaged fit: none on file
11) Deal-F9A08A (C-0D15DF) — SINGLE-THREADED
Amount: not provided | Stage: not provided
Active contacts: 1 (CT-931B10, champion)
Personas present: champion
Personas missing: economic buyer, HR admin, IT security, finance
Most valuable to add: economic buyer
On-file unengaged fit: CT-697541, Chief People Officer (economic buyer)
=====================================================================
NOT FLAGGED (healthy threading) — for completeness
=====================================================================
- Deal-84DBA6 (C-BE9BE0): 3 active, 3 distinct personas (champion, economic buyer, IT security)
- Deal-4B0BEB (C-1BDFE0): 4 active, 4 distinct personas (champion, economic buyer, HR admin, finance)
- Deal-D348E1 (C-804F29): 5 active, 5 distinct personas (champion, economic buyer, IT security, finance, HR admin)
=====================================================================
SUMMARY
=====================================================================
Single-threaded (1 active contact): 4 deals — Deal-EC3025, Deal-92D97D, Deal-36C33F, Deal-FCBE5B.
Under-threaded (<3 active): 7 deals — Deal-50D386, Deal-D0D6B5, Deal-5BFE3B, Deal-885F45, Deal-5408B0, Deal-C6D97A, Deal-F9A08A.
Total flagged: 11.
Most common gap across flagged deals: economic buyer missing (10 of 11). Deal-885F45 is the sole flagged deal with an active economic buyer.
Data gaps to be explicit about: amount and stage are absent from both provided files, so those fields are reported as "not provided" and the "most valuable persona by stage" call is made via the substitute rule noted above rather than actual deal stage.
Using only the 10 transcripts (TT-001 through TT-010), here's the analysis.
LEAD-IN (first five minutes)
The rep opens 8 of 10 calls with the exact same customer-statistic line:
"Quick one to kick off: a 400-person retailer we work with cut regretted turnover 18% in two quarters after automating milestone awards, and I wanted to walk you through exactly how they did it."
Two exceptions: Deal-403845 (TT-004) opens with "I put together a short agenda — security review first, then pricing," and Deal-1E2498 (TT-009) opens with "You asked for straight pricing last time, so let's start there."
TOP THREE OBJECTIONS AND HANDLING
1) "Budget locked" — raised 4× (Deal-D348E1, Deal-547B2B, Deal-60C2C2, Deal-84DBA6). Rebuts with self-funded turnover savings:
"Totally fair. Most teams fund this out of turnover savings — that retailer saved about $210k in avoided backfills, which is how their finance team signed off."
2) "Revisit next quarter / open enrollment" — raised 3× (Deal-5408B0, Deal-C61CF7, Deal-D9A12F). Counters with a pilot:
"Makes sense. What if we scope a 90-day pilot with one department so you have internal data before next quarter's planning?"
3) "Status quo / already do recognition" — raised 3× (Deal-403845, Deal-EDC141, Deal-1E2498). Counters with automation:
"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."
NEXT-STEP AGREEMENT RATE
Agreed concrete next step (working session) in 7 of 10 calls = 70%.
Yes (7): Deal-D348E1, Deal-5408B0, Deal-547B2B, Deal-60C2C2, Deal-C61CF7, Deal-D9A12F, Deal-1E2498.
No (3): Deal-403845 ("I'll leave it with you"), Deal-EDC141 ("Fair enough"), Deal-84DBA6 ("Understood, thanks for the candor").
Each "yes" is the identical close: "Should we lock the next step — a working session with your team this week?" → "Yes, Thursday at 2pm works — send the invite and I'll bring our HRIS manager."
COMPETITORS RAISED BY PROSPECTS
Two, both prospect-initiated:
- Awardco (Deal-547B2B): "We're also in late talks with Awardco — their rewards catalog looks bigger than yours."
- Kudos (Deal-EDC141): "How are you different from Kudos? Our CEO used them at her last company."
(Workhuman appears in Deal-C61CF7, but that line is spoken by the rep, not a prospect, so it is excluded from "competitors a prospect raised.")
COACHING NOTES
1) The pitch is fully scripted and near-verbatim across calls — identical opener, identical rebuttals, and even the prospect's acceptance line repeats word-for-word. On the two calls where the opener differed (TT-004, TT-009), the rep still pivoted into the same canned "spreadsheets work until they scale" rebuttal. Risk: prospects in the same market hear a recycled, untailored pitch; recommend adapting the opener and rebuttal to each prospect's stated context (pricing, security, existing tooling) rather than defaulting to the turnover statistic.
2) On the three calls where no next step was agreed, the rep has no fallback — the call simply ends on "I'll leave it with you" / "Fair enough" with no follow-up date, no alternative format, and no re-engagement trigger. Same gap with competitors: Awardco and Kudos are deflected but never mined for decision criteria or differentiators. Recommend a standard fallback (a specific follow-up date or lightweight next step) on every call, and capture competitor/decision criteria when a prospect names one.
Note on data: no pricing, win/loss, or post-call outcome data is provided, so nothing can be said about close rates or whether the agreed next steps actually converted.
Q3 2026 forecast (quarter 2026-07-01 → 2026-09-30), built strictly from deals.csv. Weighting rule applied: COMMIT × 100%, BEST_CASE × 35%, PIPELINE × 0%. Inside-quarter COMMIT deals (7): - Deal-547B2B $11,200 - Deal-B7EBD1 $9,000 - Deal-403845 $9,000 - Deal-A2B47C $6,360 - Deal-2465CE $5,400 - Deal-A5E80A $2,520 - Deal-499BF6 $1,249 COMMIT total = 11,200 + 9,000 + 9,000 + 6,360 + 5,400 + 2,520 + 1,249 = $44,729 Inside-quarter BEST_CASE deals (24). Sum: 38,935 + 24,000 + 19,656 + 16,250 + 11,116 + 10,800 + 10,500 + 9,890 + 9,720 + 9,000 + 7,200 + 3,840 + 3,780 + 3,600 + 3,240 + 3,150 + 3,120 + 3,060 + 2,916 + 2,760 + 2,484 + 2,100 + 1,920 + 528 = $203,565 BEST_CASE total = $203,565 Weighted forecast = COMMIT + (35% × BEST_CASE) = 44,729 + (0.35 × 203,565) = 44,729 + 71,247.75 = $115,976.75 Count of deals inside the quarter by category: - COMMIT: 7 - BEST_CASE: 24 - PIPELINE: 23 Excluded — outside the quarter (close date after 2026-09-30): 32 deals, total $227,575. (All exclusions are October dates; none fall before 2026-07-01.) Top 5 BEST_CASE deals by amount (inside quarter): 1. Deal-2D7423 $38,935 2. Deal-25F752 $24,000 3. Deal-E53952 $19,656 4. Deal-5EED42 $16,250 5. Deal-FA32A0 $11,116 ## Data quality The owner field is blank on all but one deal (only Deal-C9C286 carries "Bryce Harmon"), so no accountability or coverage is traceable. Forecast category is inconsistent with stage — DS1/DS2 deals are flagged COMMIT (Deal-A5E80A, Deal-499BF6) while DS5 "contract" deals sit in BEST_CASE (Deal-C61CF7) or PIPELINE, which violates the stage-gated logic the weighting assumes. why_buys_chars is 0 on the large majority of rows, meaning commit confidence has no supporting rationale. Finally, one amount is a fractional $2,480.40 (Deal-42326B), hinting at a data-type/currency issue, and a large cluster of deals sits within days of the quarter boundary (09-30 vs 10-01), making the in/out split highly sensitive to a one-day close-date drift.
Computation complete. All 220 rows processed; every company has both m1_users and m1_redemptions populated, so no denominator exclusions were needed.
Here is the full result.
2x2 MATRIX (cohort size / 24-month retention rate)
Signals tested:
givers = m1_users >= 5 (5+ unique givers in first calendar month)
redemption = m1_redemptions >= 1 (1+ successful redemption in first calendar month)
BOTH signals : n = 47, active = 31 -> 31/47 = 66.0%
Givers only : n = 49, active = 23 -> 23/49 = 46.9%
Redemption only : n = 29, active = 9 -> 9/29 = 31.0%
Neither : n = 95, active = 38 -> 38/95 = 40.0%
Total : n = 220 (47 + 49 + 29 + 95 = 220)
Arithmetic (retention = active / cohort):
Both: 31 / 47 = 0.6596 -> 66.0%
Givers only: 23 / 49 = 0.4694 -> 46.9%
Redemption only: 9 / 29 = 0.3103 -> 31.0%
Neither: 38 / 95 = 0.4000 -> 40.0%
Companies excluded from the denominator: NONE. All 220 rows carry integer values for both m1_users and m1_redemptions, and per the premise every company in the extract is already 25+ months old, so each maps cleanly into one of the four cells with current_status ('active' = retained at 24 months; 'cancelled' and 'non_renewing' = not retained).
Largest single-signal retention lift: GIVERS.
Givers-only 46.9% vs Neither 40.0% = +6.9 percentage points.
Redemption-only 31.0% vs Neither 40.0% = -9.0 percentage points (redemption alone actually trails the no-signal baseline).
What this does prove (on this extract):
- The full "activation" combination (5+ givers AND 1+ redemption) is the strongest single cell at 66.0% 24-month retention — +26.0pp over the 40.0% "neither" baseline, and +19.1pp over givers-only.
- Givers alone is directionally positive (+6.9pp), while redemption alone is not a retention signal on its own in this data.
What this does NOT prove:
- Causation. This is an observational cohort comparison with no control for confounders (company size/ARR, product tier, industry, geography, has_slack/has_hris, etc.). Companies that reach 5+ givers and a redemption quickly may simply be healthier accounts to begin with, so the retention gap cannot be attributed to the activation behavior itself.
- Statistical significance. Cell sizes are small (e.g. redemption-only n=29; both n=47), and no confidence interval / significance test is reported here. The +6.9pp givers lift and the -9.0pp redemption gap could be noise.
- Generalizability. The extract skews heavily toward US, tier_three, Jan–Jul 2023 signups; these results don't transfer to other segments or cohorts without replication.
- The specific threshold (>=5 givers, >=1 redemption) is not validated against alternative cutoffs — the data doesn't show whether, say, 3+ givers or 2+ redemptions would be a better or worse predictor.
One caveat worth flagging: the redemption-only cell (31.0%) sits below the neither baseline (40.0%), which is counterintuitive under a naive "more activation is always better" reading. That inversion is a classic sign of either small-sample noise or unmodeled confounding, and it reinforces that the headline "both" lift should be treated as descriptive, not causal.
Here is the ARR reconciliation as of 2026-09-05.
────────────────────────────────────────
TOTALS
────────────────────────────────────────
Billing ARR = MRR × 12, counting ACTIVE subscriptions only (cancelled subs carry $0 recurring revenue).
CRM ARR (sum of all 39 hubspot_arr rows) = $603,581.76
Billing ARR (sum of 37 active MRR × 12) = $604,739.28
Derivation of billing total:
Sum of all 39 subscriptions (MRR × 12) = $617,897.76
Less 2 cancelled subs (see status bucket) = −$13,158.48
Billing ARR (active only) = $604,739.28
Variance = Billing − CRM = +$1,157.52 (billing is $1,157.52 higher than CRM)
────────────────────────────────────────
DECOMPOSITION (sums exactly to +$1,157.52)
────────────────────────────────────────
Sign convention: positive = billing > CRM; negative = CRM > billing.
1) STATUS MISMATCH ........................ −$13,158.48
Cancelled in billing (→ $0 ARR) but still carried at full value in CRM:
C-0C8323BF : billing $0 (cancelled) vs CRM $4,905.24 → −$4,905.24
C-0DC4FB8C : billing $0 (cancelled) vs CRM $8,253.24 → −$8,253.24
(Note: each CRM value exactly equals its MRR × 12, i.e. CRM never zeroed them.)
2) ROUNDING ............................... $0.00
All 33 value-matched accounts reconcile to the cent; no rounding variance.
3) MISSING RECORDS ........................ +$11,952.00
C-21629AA4 : billing only, $28,449.24 (no CRM row) → +$28,449.24
C-0D5BBE3A : CRM only, $16,497.24 (no billing sub) → −$16,497.24
4) OTHER (value differences) .............. +$2,364.00
C-0F7269D7 : billing $26,796.00 vs CRM $24,396.00 → +$2,400.00
C-0D66DF9E : billing $23,184.00 vs CRM $23,200.00 → −$16.00
C-14D70CE0 : billing $18,180.00 vs CRM $18,200.00 → −$20.00
CHECK: −13,158.48 + 0.00 + 11,952.00 + 2,364.00 = +$1,157.52 ✓
────────────────────────────────────────
MISMATCHED ACCOUNTS + SUGGESTED OWNER
────────────────────────────────────────
No owner field exists in the provided data, so I cannot cite a specific person.
Suggested owners are assigned by functional area based on the mismatch type.
C-0C8323BF status mismatch (cancelled vs active) → Account Owner / Sales Ops
C-0DC4FB8C status mismatch (cancelled vs active) → Account Owner / Sales Ops
C-21629AA4 billing-only (no CRM record) → CRM Admin / Sales Ops
C-0D5BBE3A CRM-only (no billing subscription) → Billing / Finance Ops
C-0F7269D7 value diff $2,400 (largest) → Deal Desk / RevOps
C-0D66DF9E value diff $16 → Deal Desk / RevOps
C-14D70CE0 value diff $20 → Deal Desk / RevOps
────────────────────────────────────────
TERM-AGREEMENT-DATE VIOLATIONS
────────────────────────────────────────
Rule: any term ≠ 12 months must have cf_agreement_end_date populated.
SUB-0002 C-1794A52C term 24 mo end date MISSING → VIOLATION
SUB-0019 C-22170CA1 term 36 mo end date MISSING → VIOLATION
(Suggested owner for these: Billing Ops / Deal Desk.)
Compliant non-12-month subs (no violation):
SUB-000C C-0DB48281 term 24 mo end date 2027-11-30
SUB-001A C-0FC4DBB8 term 36 mo end date 2027-11-30
Note: the two violations do not affect the ARR totals above, since their MRR × 12 values still match CRM exactly ($7,092.00 and $7,788.00 respectively). They are data-quality issues, not ARR variances.
All four KVMs are computed as the mean across the 30 companies (all tier_three; 10 smb, 10 mid_market, 10 enterprise). Giving rate, redemptions per user, and 1:1 engagement are all essentially flat (sub-0.1% moves). Pulse engagement is the outlier: it fell 15.3%, and the drop is concentrated entirely in the enterprise segment. | KVM | Jul 2026 | Aug 2026 | Δ abs | Δ rel | Dir | |---|---|---|---|---|---| | Giving rate | 0.6023 | 0.6027 | +0.0004 | +0.07% | up | | Redemptions per user | 1.7300 | 1.7302 | +0.0002 | +0.01% | up | | 1:1 meetings engagement | 0.4469 | 0.4472 | +0.0003 | +0.06% | up | | Pulse check engagement | 0.6006 | 0.5086 | −0.0920 | −15.31% | down | Largest relative move: **pulse check engagement** (−15.31%). Segment driving it: **enterprise** (size_band). Enterprise pulse engagement fell from 0.5500 to 0.2743 (−50.1%), whereas smb (0.6588 → 0.6573, −0.2%) and mid_market (0.5930 → 0.5942, +0.2%) were flat. Every enterprise company shows the same step-change collapse (~0.55 → ~0.27), so this is a segment-wide effect, not one account. Note: an abrupt, uniform ~50% drop across all enterprise pulse values is consistent with a measurement/definition change rather than organic engagement loss, but that interpretation is not in the data.
Last completed month: 2026-08 (data runs 2026-01 through 2026-08; no rows beyond 2026-08-31). REDEMPTION METRICS (YTD through 2026-08) Redemption count: 378 Spend: $27,846.00 Unique redeemers: 235 Redemptions per redeemer: 1.61 (378 ÷ 235 = 1.6085) PROVIDER MIX (% of spend) custom $10,873.00 39.05% Tremendous $8,505.00 30.54% Snappy $5,238.00 18.81% TangoCard $3,230.00 11.60% Total $27,846.00 100.00% Arithmetic: 10,873 + 8,505 + 5,238 + 3,230 = 27,846 ✓ Shares: 10873/27846=39.05%, 8505/27846=30.54%, 5238/27846=18.81%, 3230/27846=11.60% → sums to 100.00% ✓ TOP 5 COUNTRIES BY REDEMPTIONS 1. US 244 2. CA 24 3. AU 21 4. GB 17 5. NL 17 (GB and NL are tied at 17; shown as listed for the 4th and 5th slots. Next is SG at 12, so the top-5 cut is unambiguous.)
I'll work strictly from the two files provided. ## Eligibility rules (snapshot 2026-09-05) - R1: health_score < 60 - R2: churn_save_eligible_amount > 0 - R3: renewal_date within 120 days of 2026-09-05 → i.e. on or before 2027-01-03 (Sep 5 + 120d = Jan 3, 2027) An account qualifies only if it passes R1 AND R2 AND R3. ## Play-assignment note The files contain eligibility rules only. They do NOT contain a documented rule mapping signals to the three plays, so I am applying a consistent analyst mapping (stated here so it is auditable, not treated as a documented rule): - champion_active = false → executive touch (no internal advocate driving renewal) - usage_trend_3m = declining, or seat utilization ≤ ~50% → usage revival (under-adoption/decline) - otherwise, the only risk flag is a low health score → commercial concession (value-for-price driven) --- ## QUALIFYING ACCOUNTS (8) 1. C-0F6C0F34 — $49,707.00 — executive touch Health 51, growing usage, 308/395 seats (78%), champion_active = false. Signal: no active champion (champion_active = false) despite growing usage. 2. C-0B827671 — $25,365.00 — usage revival Health 56, declining usage, 113/202 seats (56%). Signal: usage_trend_3m = declining and only 113 of 202 seats used. 3. C-0B360C78 — $35,748.00 — commercial concession Health 57, growing usage, 246/327 seats (75%), champion active. Signal: health_score = 57 is the only at-risk flag — usage growing, champion active, healthy utilization. 4. C-0B0F1BAB — $5,494.00 — executive touch Health 38, flat usage, 238/363 seats (66%), champion_active = false. Signal: champion_active = false. 5. C-0CA21961 — $16,829.00 — usage revival Health 58, flat usage, 84/325 seats (26%), champion active. Signal: severe under-utilization — only 84 of 325 seats used (~26%). 6. C-0E9C27D1 — $41,235.00 — commercial concession Health 39, flat usage, 134/157 seats (85%), champion active. Signal: health_score = 39 is the only risk flag — usage flat, champion active, high utilization. 7. C-0CEF69FD — $32,621.00 — executive touch Health 53, growing usage, 97/136 seats (71%), champion_active = false. Signal: champion_active = false. 8. C-0D3278C7 — $17,602.00 — usage revival Health 54, declining usage, 126/380 seats (33%), champion active. Signal: usage_trend_3m = declining and only 126 of 380 seats used (~33%). ### Total at stake 49,707.00 + 25,365.00 + 35,748.00 + 5,494.00 + 16,829.00 + 41,235.00 + 32,621.00 + 17,602.00 = 224,601.00 Total churn-save eligible amount across 8 qualifying accounts: $224,601.00 --- ## AT-RISK ACCOUNTS THAT DO NOT QUALIFY (7) Fails R2 (churn_save_eligible_amount = 0): - C-0BC71BDD — health 55, eligible $0.00, renewal 2026-10-27. No churn-save amount ($0). - C-0BE96399 — health 54, eligible $0.00, renewal 2026-10-29. $0 eligible amount. - C-10A56B0F — health 54, eligible $0.00, renewal 2026-12-12. $0 eligible amount. - C-0F6694C3 — health 43, eligible $0.00, renewal 2027-03-21. $0 eligible (also outside 120-day window). - C-0FCCD2DF — health 43, eligible $0.00, renewal 2027-04-23. $0 eligible (also outside 120-day window). Fails R3 (renewal beyond 120 days): - C-0BA71F12 — health 52, eligible $6,824.00, renewal 2027-04-11. Renewal is outside the 120-day window. - C-0F876796 — health 47, eligible $19,958.00, renewal 2027-02-06. Renewal is outside the 120-day window. --- Summary: 8 accounts qualify for a churn-save offer, totaling $224,601.00 at stake. 7 more accounts are flagged at risk (health < 60) but do not qualify — 5 because their churn-save eligible amount is $0 and 2 because their renewal date falls outside the 120-day window (C-0F6694C3 and C-0FCCD2DF fail both R2 and R3).
Expansion kit for C-0DDFC9A7 SEAT COVERAGE (licensed over headcount) - Licensed seats: 150 - Headcount: 400 - Coverage = 150 / 400 = 37.5% of headcount licensed. USAGE HEALTH (two lines) - Monthly active users climbed every month for six straight months: 88 → 95 → 102 → 110 → 118 → 126 (Mar–Aug 2026). Net +38, +43% over the period. - Aug usage (126) = 84% of licensed seats (126/150). Relative to headcount it's 31.5%, meaning usage is nearing the license ceiling while 274 of 400 people remain unlicensed. HEADROOM - Per-seat rate = current ARR / licensed seats = 9000.00 / 150 = $60/seat/year. - Headroom in seats = headcount − licensed = 400 − 150 = 250 seats. - Headroom in ARR at current per-seat rate = 250 × $60 = $15,000/year. WHO REPLIED / CAN THEY BUY - Replied: Maria S., People Operations Coordinator (engaged 2026-09-02). - Can she buy? No — she explicitly states budget and seat expansion sit with Dana R. RIGHT BUYER FROM CONTACTS - Dana R., VP People (last engaged 2026-05-18). REPLY EMAIL (146 words) Subject: Re: Growing your team's recognition program Hi Maria, Thanks for the update — great to hear the team's momentum. Your monthly active users have grown from 88 in March to 126 in August, so it's no surprise Dana has been asking about the numbers. I appreciate you flagging that purchasing isn't on your plate. Would you be open to a quick introduction to Dana? I'll keep it short — just a note on what that six-month growth means for your current seat coverage and where we can help, nothing pushy. Happy to work around her schedule, and I'll loop you in so you're never out of the loop. Thanks again for making the connection easy. Best, Cole
CSM mid-onboarding prep — C-0D284E42 STATUS: COMPLETE vs NOT (marked complete only where a data field exists) COMPLETE - Slack integration — connected. integration_slack = 2026-08-12 (1 day after signup). - Allowance set — yes. allowance_set = 2026-08-13. - Admins added — yes, admins_added = 2. - First recognition given — yes. first_recognition_at = 2026-08-15 14:22 (4 days after signup). NOT COMPLETE - HRIS integration — integration_hris is EMPTY. Not connected. - First redemption — first_redemption_at is EMPTY. No redemption has happened yet. So: 4 of 6 onboarding milestones done. The two gaps are HRIS and first redemption. EARLY ENGAGEMENT SIGNALS (active_givers, signup 2026-08-11) Weekly averages (sum of active_givers / days): - Week 1 (08-11 → 08-17): 3+3+4+4+5+4+7 = 30 → 4.3 givers/day - Week 2 (08-18 → 08-24): 5+7+6+9+8+9+9 = 53 → 7.6 givers/day - Week 3 (08-25 → 08-31): 9+11+10+10+11+13+11 = 75 → 10.7 givers/day - Week 4 (09-01 → 09-04, partial): 13+13+15+15 = 56 → 14.0 givers/day Trajectory is steadily up: 4.3 → 7.6 → 10.7 → 14.0 average daily active givers. Peak = 15 (09-03 and 09-04, the two most recent days). No plateau or dip at the tail — the account is compounding. One signal worth flagging: recognition is happening (first recognition 08-15, and giver count is climbing week over week), but redemption has not started at all — usage is one-sided so far. THREE THINGS TO COVER ON THE CALL 1. HRIS integration is still missing. It's the only unconnected integration and blocks directory/team sync. Ask what's blocking it and who on their side owns it; offer to walk it through on this call. 2. First redemption hasn't happened. Givers are active and growing (15/day at peak) but nobody has redeemed. Diagnose: is the catalog unclear, is the allowance/points confusing, or is it just a time lag? Goal = get the first redemption logged. 3. Admin coverage is thin (only 2 admins). Confirm both are the right owners, and given the 2.5x giver growth in 3 weeks, check whether they need a second admin tier or a broader rollout plan before activity outpaces administration. Note on "mid-onboarding" framing: with a 2026-08-11 signup and data through 09-04, the account is ~3.5 weeks in. HRIS + first redemption are the two milestones to close; everything else is on track or ahead.
Renewal Risk Brief — 90-Day Window (2026-09-10 through 2026-11-24)
Trust rule applied: ChurnZero's renewal date is known to be wrong for multi-year contracts. For the 5 accounts flagged is_multi_year=true in Chargebee, I trust Chargebee's date. For all other accounts the two systems agree exactly, so there is no conflict.
Risk rubric: High = sustained declining 3-month active-user trend; Medium = very low seat utilization (<35%) and/or marginal decline; Low = stable or growing usage with healthy utilization. Seat utilization = seats_used / seats (from ChurnZero). Usage trend = last 3 months of active_users (2026-06 → 07 → 08).
================================================================
Per-account detail
================================================================
1) C-0B7D2C30 | Dana Mercer | $65,901 | 2026-09-15 | 57.6% (274/476) | 97→94→84 | HIGH — Active users fell 13.4% over the quarter and every month for a year straight.
DISAGREE: CZ 2026-09-10 vs CB 2026-09-15 (36mo multi-year). Trusted CB.
2) C-0BCDB8C2 | Cole Ingram | $54,427 | 2026-09-18 | 54.7% (232/424) | 127→118→110 | HIGH — Declining usage (127→110) signals contraction risk ahead of renewal.
DISAGREE: CZ 2027-09-18 vs CB 2026-09-18 (36mo multi-year). CZ is off by exactly one year; trusted CB.
3) C-0D2AB865 | Elena Sinclair | $38,022 | 2026-09-22 | 61.4% (250/407) | 125→117→109 | HIGH — Steady monthly decline in active users (125→109) over the last quarter.
DISAGREE: CZ 2026-09-10 vs CB 2026-09-22 (24mo multi-year). Trusted CB.
4) C-0BBE3E60 | Dana Mercer | $30,993 | 2026-09-26 | 64.9% (74/114) | 39→35→33 | HIGH — Usage dropped 63→33 across 12 months, with no flattening at the end.
DISAGREE: CZ 2027-09-26 vs CB 2026-09-26 (24mo multi-year). CZ off by one year; trusted CB.
5) C-0F5D2323 | Cole Ingram | $90,647 | 2026-09-29 | 28.5% (111/390) | 20→21→18 | MEDIUM — Largest ARR in the book but only 28.5% of seats used; usage is flat/volatile at ~20 active users.
DISAGREE: CZ 2026-09-10 vs CB 2026-09-29 (24mo multi-year). Trusted CB.
6) C-0EC6999D | Elena Sinclair | $79,419 | 2026-10-03 | 27.7% (31/112) | 17→16→15 | MEDIUM — Very low seat utilization (27.7%) with a soft slide in active users (17→15).
(No disagreement — both systems show 2026-10-03, 12mo.)
7) C-0B20DB64 | Dana Mercer | $21,770 | 2026-10-07 | 56.6% (214/378) | 294→298→294 | LOW — Usage is flat and stable all year.
(No disagreement.)
8) C-0BBC4E7A | Cole Ingram | $56,374 | 2026-10-10 | 67.7% (228/337) | 142→141→139 | LOW — Usage essentially flat (142→139); healthy utilization.
(No disagreement.)
9) C-0FD551AB | Elena Sinclair | $48,815 | 2026-10-14 | 55.9% (210/376) | 123→122→126 | LOW — Usage stable-to-slightly-up (126 in Aug).
(No disagreement.)
10) C-0F9F8F13 | Dana Mercer | $46,230 | 2026-10-18 | 56.5% (199/352) | 185→185→182 | LOW — Flat usage, no trend either direction.
(No disagreement.)
11) C-0BC34584 | Cole Ingram | $16,740 | 2026-10-22 | 66.2% (327/494) | 104→104→106 | LOW — Flat-to-slightly-up usage.
(No disagreement.)
12) C-0B7A7546 | Elena Sinclair | $35,062 | 2026-10-25 | 88.8% (182/205) | 64→65→63 | LOW — Highest utilization in the book (88.8%) and stable usage.
(No disagreement.)
13) C-0B369871 | Dana Mercer | $85,128 | 2026-10-29 | 75.1% (317/422) | 326→330→333 | LOW — Growing usage (289→333 across the year).
(No disagreement.)
14) C-0B144C78 | Cole Ingram | $30,899 | 2026-11-02 | 75.4% (169/224) | 101→101→106 | LOW — Usage trending up (90→106 over the year).
(No disagreement.)
15) C-0FC4DBB8 | Elena Sinclair | $94,732 | 2026-11-05 | 76.7% (356/464) | 189→191→193 | LOW — Steady growth (168→193 across 12 months).
(No disagreement.)
16) C-0D5BBE3A | Dana Mercer | $39,740 | 2026-11-09 | 83.3% (85/102) | 88→90→91 | LOW — Growing usage with high utilization (83.3%).
(No disagreement.)
17) C-0FB9D5AF | Cole Ingram | $63,158 | 2026-11-13 | 72.4% (144/199) | 173→173→176 | LOW — Usage climbing (154→176 across the year).
(No disagreement.)
18) C-0B344485 | Elena Sinclair | $64,384 | 2026-11-16 | 78.0% (224/287) | 238→240→244 | LOW — Consistent growth (211→244 over the year).
(No disagreement.)
19) C-0CB2C1B4 | Dana Mercer | $40,628 | 2026-11-20 | 81.6% (386/473) | 47→48→49 | LOW — Slow steady growth with high utilization (81.6%).
(No disagreement.)
20) C-22170CA1 | Cole Ingram | $45,646 | 2026-11-24 | 85.4% (251/294) | 143→148→146 | LOW — Usage up across the year (130→146), flat at the tail.
(No disagreement.)
================================================================
Disagreement summary
================================================================
5 of 20 accounts disagree, and all 5 are multi-year contracts (the exact class ChurnZero is known to get wrong):
- C-0B7D2C30 (36mo): CZ 09-10 vs CB 09-15
- C-0BCDB8C2 (36mo): CZ 2027-09-18 vs CB 2026-09-18 (CZ off by a full year)
- C-0D2AB865 (24mo): CZ 09-10 vs CB 09-22
- C-0BBE3E60 (24mo): CZ 2027-09-26 vs CB 2026-09-26 (CZ off by a full year)
- C-0F5D2323 (24mo): CZ 09-10 vs CB 09-29
For all five I used the Chargebee date. The 15 remaining accounts (all 12-month terms) agree exactly between systems.
================================================================
Totals
================================================================
Total ARR renewing (20 accounts):
65,901 + 54,427 + 38,022 + 30,993 + 90,647 + 79,419 + 21,770 + 56,374
+ 48,815 + 46,230 + 16,740 + 35,062 + 85,128 + 30,899 + 94,732
+ 39,740 + 63,158 + 64,384 + 40,628 + 45,646
= $1,048,715.00
ARR at risk:
High risk (4 accounts):
65,901 + 54,427 + 38,022 + 30,993 = $189,343.00
Medium risk (2 accounts):
90,647 + 79,419 = $170,066.00
Combined High + Medium = $359,409.00
Data gaps / notes: No missing accounts across the three files (all 20 aliases present in each). The usage_12m "active_users" figures do not reconcile cleanly with "seats_used" (e.g. C-0F5D2323 shows 111 seats_used but only ~20 active users; C-0B20DB64 shows 214 seats_used but ~294 active users) — these are two different metrics and I have reported each as given without inventing a bridge between them.
Here's the synthesis. Total tickets in file: 80. I grouped by reading `body_text` (ignoring `tag`), then ranked by ARR exposure. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ THEME 1 — HRIS provisioning failure (RANK #1) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Count: 12 Share: 12/80 = 15.0% Distinct accounts: 3 C-0DDFC9A7 ($48,000) — 3 tickets C-0B2213A9 ($36,000) — 7 tickets C-0F6C0F34 ($30,000) — 2 tickets ARR affected: 48,000 + 36,000 + 30,000 = $114,000 Ticket ids: IC-460059, IC-460062 Body themes: "HRIS provisioning not creating accounts", "sync skipped 12 new hires; provisioning log shows no errors", "new employees not provisioned". Recommendation: Audit the HRIS sync job for silent no-op failures — the "log shows no errors" reports mean the job exits clean while dropping records. Broad pattern. 3 accounts, highest total ARR. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ THEME 2 — Redemption / checkout / gift-card failure (RANK #2) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Count: 18 Share: 18/80 = 22.5% Distinct accounts: 7 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) ARR affected: 11,000+10,700+10,300+9,600+9,600+8,900+8,700 = $68,800 Ticket ids: IC-460025, IC-460035 Body themes: "checkout spins forever then redemption fails", "redemption failed twice; gift card email never showed", "gift card order errored but points were still deducted". Recommendation: Fix the checkout→redemption transaction to be atomic so points are never deducted on a failed order. Broad pattern. Widest account spread (7) of any theme. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ THEME 3 — Billing / invoicing errors (RANK #3 — SINGLE-ACCOUNT) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Count: 16 Share: 16/80 = 20.0% Distinct accounts: 1 → C-0E9C27D1 only ARR affected: $52,000 Ticket ids: IC-460071, IC-460069 Body themes: "third invoice in a row with same seat-count error", "charged for 200 seats but we license 150", "annual renewal at wrong tier price", "seat count we never approved". Recommendation: Treat as single-account churn risk, not a platform bug — have CS own C-0E9C27D1 directly and reconcile seat/tier config at the account level. SINGLE-ACCOUNT NOISE. 16 tickets all from one account (C-0E9C27D1). It's the highest-volume single-account driver, so it ranks on ARR, but it does NOT represent a broad defect. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ THEME 4 — Recognition points not posting (RANK #4) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Count: 20 Share: 20/80 = 25.0% Distinct accounts: 9 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) ARR affected: 4,500+4,500+4,200+3,500+3,400+2,900+2,900+2,700+2,500 = $31,100 Ticket ids: IC-460004, IC-460001 Body themes: "recognitions show delivered but points never arrived", "points not posting for whole team after the weekend", "missing points — balance not updated", "points from last week's recognition not posting". Recommendation: Investigate the points-crediting pipeline for a lag/drop between recognition delivery and balance update (many reports cluster around weekends). Broad pattern — highest ticket volume (20) and widest account reach (9), but all small-ARR accounts, so lower ARR exposure. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ THEME 5 — Slack integration broken (RANK #5) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Count: 14 Share: 14/80 = 17.5% Distinct accounts: 4 C-10A56B0F ($5,400), C-8C2E8F00 ($5,200), C-0B843542 ($4,400), C-0BA71F12 ($3,900) ARR affected: 5,400 + 5,200 + 4,400 + 3,900 = $18,900 Ticket ids: IC-460041, IC-460046 Body themes: "Slack integration stopped syncing recognitions", "sync toggle resets itself", "Slack app disconnected and re-auth doesn't stick", "Slack slash command returns an error". Recommendation: Stabilize the Slack OAuth/sync loop — fix the self-resetting toggle and slash-command errors that are recurring across 4 accounts. Broad pattern (4 accounts), lowest ARR exposure. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SUMMARY — ranked by ARR exposure ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1. HRIS provisioning $114,000 (3 accts, broad) 2. Redemption/checkout $68,800 (7 accts, broad) 3. Billing/invoicing $52,000 (1 acct, SINGLE-ACCOUNT noise) 4. Points not posting $31,100 (9 accts, broad) 5. Slack integration $18,900 (4 accts, broad) Key callout: Billing (16 tickets) is entirely one account (C-0E9C27D1) and ranks high purely on that account's ARR — it's an escalation/churn issue, not a systemic defect. The true broad-platform problems are HRIS provisioning, redemption/checkout, points-crediting, and Slack sync, in that order of ARR exposure.
Ranking of the three most similar existing customers with public case studies (has_case_study = true), measured against the prospect C-82AF3719 (Technology, Mid-Market, employee_recognition, NA-West). Scoring = matches across four dimensions, weighted by the order given: industry > size_band > use_case > region. Prospect profile: Technology / Mid-Market / employee_recognition / NA-West Candidates (case-study customers only), with per-field match count: | Alias | Industry | Size | Use case | Region | Matches | |---|---|---|---|---|---| | C-FEFCC020 | Education ✗ | Enterprise ✗ | wellness ✗ | NA-East ✗ | 0 | | C-11209339 | Manufacturing ✗ | SMB ✗ | peer_milestones ✗ | APAC ✗ | 0 | | C-9D69D147 | Financial Services ✗ | Mid-Market ✓ | retention ✗ | NA-West ✓ | 2 | | C-11C31562 | Manufacturing ✗ | Mid-Market ✓ | employee_recognition ✓ | NA-West ✓ | 3 | | C-CD4829A7 | Technology ✓ | Mid-Market ✓ | retention ✗ | NA-East ✗ | 2 | | C-0CE315B2 | Education ✗ | SMB ✗ | wellness ✗ | EMEA ✗ | 0 | | C-64171065 | Technology ✓ | Mid-Market ✓ | employee_recognition ✓ | NA-East ✗ | 3 | | C-A13C193D | Technology ✓ | Mid-Market ✓ | retention ✗ | NA-West ✓ | 3 | Three aliases tie at 3/4 matches. Tie-break by field priority (industry first, then size band, then use case, then region): RANK 1 — C-64171065 (Technology, Mid-Market, employee_recognition, NA-East) - industry: Technology = Technology ✓ - size_band: Mid-Market = Mid-Market ✓ - use_case: employee_recognition = employee_recognition ✓ - region: NA-East ≠ NA-West ✗ - 3 matches, and it is the only candidate matching all three of the top-priority fields (industry + size + use case), missing only region. Cleanest functional/company-type analog. RANK 2 — C-A13C193D (Technology, Mid-Market, retention, NA-West) - industry: Technology = Technology ✓ - size_band: Mid-Market = Mid-Market ✓ - use_case: retention ≠ employee_recognition ✗ - region: NA-West = NA-West ✓ - 3 matches. Matches industry + size + region; differs on use case (retention vs employee_recognition). Ranked below C-64171065 because use case (3rd field) is closer to the prospect's need than region (4th field). RANK 3 — C-11C31562 (Manufacturing, Mid-Market, employee_recognition, NA-West) - industry: Manufacturing ≠ Technology ✗ - size_band: Mid-Market = Mid-Market ✓ - use_case: employee_recognition = employee_recognition ✓ - region: NA-West = NA-West ✓ - 3 matches, but misses the highest-priority field (industry), so it ranks behind the two industry matches despite being a perfect size/use-case/region fit. Summary of the three selected social-proof customers, in order: 1. C-64171065 2. C-A13C193D 3. C-11C31562 No other case-study customer exceeded 2 matches (C-9D69D147 and C-CD4829A7 each matched only 2 fields), and none reached the 3-match threshold. No customer without a case study (has_case_study = false) is included. No billing data or contact names were used or cited.
Computation complete. Here is the full channel performance analysis. ═══════════════════════════════════════════ TRAILING 6-MONTH CHANNEL PERFORMANCE (2026-03 → 2026-08) ═══════════════════════════════════════════ PAID CHANNELS ───────────────────────────────────────────── paid_search Spend: $36,000 (6 mo × $6,000) SQMs: 40 SQOs: 18 Cost per SQM: $900 (= 36,000 / 40) Cost per SQO: $2,000 (= 36,000 / 18) SQM-to-SQO rate: 45.0% (= 18 / 40) Pipeline: $720,000 Pipeline / $: $20.00 (= 720,000 / 36,000) linkedin_ads Spend: $24,000 (6 mo × $4,000) SQMs: 25 SQOs: 8 Cost per SQM: $960 (= 24,000 / 25) Cost per SQO: $3,000 (= 24,000 / 8) SQM-to-SQO rate: 32.0% (= 8 / 25) Pipeline: $96,000 Pipeline / $: $4.00 (= 96,000 / 24,000) webinars Spend: $9,000 (6 mo × $1,500) SQMs: 12 SQOs: 5 Cost per SQM: $750 (= 9,000 / 12) Cost per SQO: $1,800 (= 9,000 / 5) SQM-to-SQO rate: 41.7% (= 5 / 12) Pipeline: $60,000 Pipeline / $: $6.67 (= 60,000 / 9,000) paid_social ⚠ UNDEFINED Spend: $18,000 (6 mo × $3,000) SQMs: 0 SQOs: 0 Cost per SQM: undefined (no SQMs to divide by) Cost per SQO: undefined SQM-to-SQO rate: undefined Pipeline: $0 Pipeline / $: $0 → This channel spent $18,000 and produced ZERO first-touch contacts. ORGANIC CHANNELS (no spend) ───────────────────────────────────────────── organic_search Volume: 30 contacts SQOs: 10 SQO rate: 33.3% (= 10 / 30) Pipeline: $90,000 referral Volume: 15 contacts SQOs: 6 SQO rate: 40.0% (= 6 / 15) Pipeline: $48,000 ═══════════════════════════════════════════ DATA-QUALITY FLAGS — SQO DATE PRECEDES SQM DATE ═══════════════════════════════════════════ CT-000044 linkedin_ads SQM 2026-07-23 → SQO 2026-07-18 CT-000041 linkedin_ads SQM 2026-06-14 → SQO 2026-06-09 (2 rows; both in linkedin_ads. These SQOs are counted as-is above but the timestamps are logically inconsistent and warrant correction.) ═══════════════════════════════════════════ REALLOCATION RECOMMENDATION ═══════════════════════════════════════════ 1. paid_social ($18,000/6mo) is dead weight — zero SQMs across the entire window. Reallocate its budget first. This is the single clearest call in the dataset. 2. paid_search is the standout paid channel: lowest cost per SQO ($2,000), highest SQM-to-SQO rate (45%), and by far the best pipeline efficiency ($20 pipeline per $1 spend). Shift a meaningful share of the freed paid_social budget here. 3. webinars is efficient on a per-lead basis ($750/SQM, $1,800/SQO — cheapest SQM of any paid channel) but tiny sample (12 SQMs). Hold or modestly scale to validate the pattern before betting big. 4. linkedin_ads is the weakest paid performer that still produces anything: $3,000/SQO and only $4 pipeline per $1 — and both data-quality flags sit in this channel. Deprioritize until the SQM/SQO timestamp issues are fixed. CONFIDENCE / SAMPLE-SIZE CAVEATS ───────────────────────────────────────────── - paid_social: HIGH confidence it's underperforming (zero over 6 full months, not a small-sample issue). - paid_search: MODERATE-HIGH — 40 SQMs / 18 SQOs is the largest paid sample and the pattern is internally consistent. - linkedin_ads & webinars: MODERATE-LOW — 8 and 5 SQOs respectively; rates swing ±15 points with one or two deals. linkedin_ads also carries both timestamp anomalies, so its numbers are soft. - organic_search (30 vol / 10 SQO) and referral (15 vol / 6 SQO): referral's 40% SQO rate is on only 15 contacts — treat as directional, not stable. Net: the reallocation (kill paid_social → fund paid_search) is well-supported; any finer reshuffling between webinars/linkedin_ads should wait for larger samples.
# Battlecard: Rivally (updated) ## One-line positioning Points-based employee recognition platform, positioned at mid-market (Recognition Starter tier) with active expansion into EU enterprise and a lightweight engagement-survey add-on (Rivally Pulse). [S02 points-based recognition feed; S03/S08 "Recognition Starter" tier; S11 EU expansion hire; S12 EU enterprise strength; S06/S23 Rivally Pulse] ## Pricing (source + date, newer wins) - Current list price: $7 per user/month, annual billing required — pricing page, 2026-08-12 [S17]. - Conflict: earlier pricing pages listed $5/user/mo, annual billing (2026-01-20 [S03]; 2026-04-01 [S08]). Newer source (S17) wins → $7. - Rivally Pulse (engagement survey) is a paid add-on, not bundled — 2026-09-01 [S23]. - Negotiated quotes (call notes / deal mentions, NOT list-price facts): $6.50/user/mo quoted to a 500-seat prospect (2026-06-02) [S13]; $7/user/mo list with 15% discount offered on a 3-year term (2026-08-14) [S18]. ## Where they win - EU data residency generally available + Dublin office (2026-07-01) [S15]; EU data residency was being pitched as early as Feb [S05, prospect mention]; ex-Workday VP EMEA hired to lead Europe expansion (2026-05-09) [S11]. - Strong for distributed EU teams; multi-language support praised [S12]. - Fast setup (< 1 week) and out-of-the-box Slack integration [S04]. - Engaging recognition feed [S02, S16]. - Support response time under 4 hours [S22]. - Momentum: Series C $40M led by Northgate Ventures (2025-11-04) [S01]; Microsoft Teams app v2 in public preview (2026-08-20) [S19]. ## Where we win - Analytics depth: an 800-seat prospect chose Bonusly over Rivally citing analytics depth (2026-09-03) [S25]. Their reporting dashboards are "basic" vs enterprise tools [S07]; analytics "limited" [S02]; exports are CSV-only, which made migration off Rivally hard [S20]. - Enterprise/admin tooling: no SCIM provisioning, manual user management "painful" [S10]; admin tooling lags peers [S16]; no bulk recognition editing [S24]. - EMEA rewards catalog thinner than US catalog [S14]. ## Objections and responses - Objection: "Rivally has EU data residency + multi-language for our EU teams" [S15, S12]. Response: For enterprise/EU-at-scale deals, their admin/enterprise gaps undercut it — no SCIM [S10], lagging admin tooling [S16], no bulk editing [S24]; and analytics depth won us an 800-seat deal against them [S25]. - Objection: "Rivally is cheaper / discounts aggressively" (quotes $6.50 [S13]; 15% 3-year discount [S18]; rep opinion on aggressive discounting is unconfirmed [S21]). Response: Anchor on analytics depth and admin tooling (S25, S10, S16, S20) — the 800-seat deal flipped on analytics, not price [S25]. - Objection: "Fast setup, Slack works out of the box" [S04]. Response: Setup speed doesn't solve for reporting that is "basic" [S07], CSV-only analytics exports [S20], and manual user management at enterprise scale [S10]. - Objection: "Their recognition feed is engaging" [S16]. Response: Engagement without depth — limited analytics [S02], basic dashboards [S07], thinner EMEA rewards catalog [S14]. ## Recent changes - Series C $40M led by Northgate Ventures (2025-11-04) [S01]. - Rivally Pulse engagement-survey add-on launched (2026-03-05) [S06]; exited beta as a paid add-on, not bundled (2026-09-01) [S23]. - Ex-Workday VP EMEA hired to lead European expansion (2026-05-09) [S11]. - Dublin office opened; EU data residency GA (2026-07-01) [S15]. - Price increase: Recognition Starter $5 → $7/user/mo (pricing page updated 2026-08-12) [S17 vs S08]. - Microsoft Teams app v2 in public preview (2026-08-20) [S19]. ## Our 12-month win/loss record vs Rivally (2025-09 through 2026-08) Arithmetic from deals_with_competitor.csv (all 20 rows are Rivally, all within the trailing 12 months of 2026-09-06): Wins: 13 - Deal-A9FD43 (2025-10), Deal-7AA785 (2025-11), Deal-44C524 (2025-12), Deal-0D0CD6 (2026-01), Deal-D5B790 (2026-02), Deal-5C636E (2026-03), Deal-67BE14 (2026-06), Deal-1B6969 (2026-07), Deal-F03E7B (2026-08), Deal-072E31 (2025-09), Deal-F65C8F (2025-10), Deal-E46EAB (2026-01), Deal-1D2392 (2026-02) Losses: 7 - Deal-7767F5 (2025-09), Deal-D263E0 (2025-11), Deal-935746 (2025-12), Deal-9066A6 (2026-03), Deal-5645A5 (2026-04), Deal-72A02F (2026-04), Deal-C6FFAA (2026-05) Total: 20 deals (13 wins + 7 losses). Win rate = 13/20 = 65%. Monthly: 2025-09 (1W/1L), 2025-10 (2W/0L), 2025-11 (1W/1L), 2025-12 (1W/1L), 2026-01 (2W/0L), 2026-02 (2W/0L), 2026-03 (1W/1L), 2026-04 (0W/2L), 2026-05 (0W/1L), 2026-06 (1W/0L), 2026-07 (1W/0L), 2026-08 (1W/0L). ## Old-card items: re-sourcing / corrections - "Rivally lacks a Slack integration" — CONTRADICTED by data; Slack integration "worked out of the box" [S04]. Remove. - "Rivally was acquired by WorkHuman in 2025" — UNVERIFIED. No snippet supports an acquisition; S01 instead reports an independent Series C led by Northgate Ventures (2025-11), which is inconsistent with an acquisition. Flag as unverified. - "Pricing $5/user/mo (2026-01)" — OUTDATED; superseded by $7/user/mo [S17]. - "Strong in EU enterprise with multi-language support" — VERIFIED [S12], corroborated by [S11, S15]. - "Points-based recognition for mid-market" — points-based recognition verified [S02]; "mid-market" only indirectly supported (Recognition Starter tier [S03/S08], mid-market reviewer [S04]), not an explicit positioning statement. ## Note on rep-opinion snippets (excluded from factual claims) - S09 (Bryce Harmon, "UI clunky") — AE opinion, not verified against product. - S21 (Elena Sinclair, "discounting aggressively") — rep opinion, not confirmed. Neither is a fact about Rivally and both are excluded from the sections above (S21 referenced only as an explicitly-unconfirmed opinion).
Analysis complete (computed against the two CSVs). Findings below. Per-sequence (open = opened/sent, reply = replied/sent, meeting = meetings/sent): New Logo Nurture — S1: 210/500=42.0% open, 42/500=8.4% reply, 12/500=2.4% meet. S2: 160/458=34.9%, 30/458=6.6%, 9/458=2.0%. S3: 120/428=28.0%, 18/428=4.2%, 6/428=1.4%. Weakest step 3. Expansion Nurture — S1: 130/300=43.3%, 22/300=7.3%, 5/300=1.7%. S2: 340/300=113.3%, 25/300=8.3%, 4/300=1.3%. S3: 95/275=34.5%, 12/275=4.4%, 3/275=1.1%. Weakest step 3. TRACKING ERROR: S2 opened 340 > sent 300. Cold Outbound – HR Leaders — S1: 240/600=40.0%, 5/600=0.83%, 0. S2: 175/595=29.4%, 2/595=0.34%, 0. S3: 130/590=22.0%, 1/590=0.17%, 0. Weakest step 3; all steps <2% reply, zero meetings. Cold Outbound – People Ops — S1: 150/400=37.5%, 14/400=3.5%, 3/400=0.75%. S2: 110/386=28.5%, 9/386=2.3%, 2/386=0.52%. S3: 80/377=21.2%, 6/377=1.6%, 1/377=0.27%. Weakest step 3 (<2%). Tracking errors: only Expansion Nurture S2 (340 opened vs 300 sent). Audience overlap: 21 contacts appear in BOTH cold-outbound sequences (CT-000849, CT-000884, CT-000890, CT-000908, CT-001033, CT-001097, CT-001101, CT-001103, CT-001105, CT-001130, CT-001153, CT-001159, CT-001217, CT-001227, CT-001236, CT-001255, CT-001258, CT-001277, CT-001285, CT-001311, CT-001345). 2 contacts appear in both Expansion and New Logo (CT-000301, CT-000624). Failure modes (<2% reply): - HR Leaders: entire sequence is dead — reply 0.83%/0.34%/0.17%, zero meetings. The 21-contact overlap means those leads get hit by both cold sequences, driving fatigue/suppression. - People Ops S3: reply decayed to 1.6% (under threshold). Changes (one per weak sequence): - HR Leaders — fix FIRST (600 sends, 0 meetings): dedupe the 21 shared contacts so no lead receives both cold sequences. - People Ops: drop or rewrite step 3 (reply <2%). - Expansion Nurture: correct S2 opened count before trusting its 8.3% reply rate.
Weekly marketing goals update — Q3-2026 (day 66 of 92 = 71.7% elapsed) For each metric: QTD actual | target | delta | pace vs. 71.7% elapsed. SQMs Actual 230 | Target 300 | Delta −70 (76.7% of target) Pace: AHEAD (76.7% vs 71.7% elapsed) SQOs Actual 84 | Target 120 | Delta −36 (70.0% of target) Pace: BEHIND (70.0% vs 71.7% elapsed) DS2s Actual 40 | Target 75 | Delta −35 (53.3% of target) Pace: BEHIND (53.3% vs 71.7% elapsed) Closed-lost MIA rate Actual 5 / 25 = 0.20 = 20% | Target 0.10 = 10% (lower better) Delta +10.0 percentage points over target (unfavorable) Pace: BEHIND — rate is 2x the target. Note: this is a ratio, not a cumulative-through-quarter count, so the days-elapsed comparison does not cleanly apply; judgment is that 20% vs 10% is off-target regardless of elapsed time. Same-quarter closes Actual 10 | Target 20 | Delta −10 (50.0% of target) Pace: BEHIND (50.0% vs 71.7% elapsed) Active pipeline coverage vs target Actual $3,000,000 | Target $4,000,000 | Delta −$1,000,000 (75.0% coverage) Pace: AHEAD on a naive coverage basis (75.0% vs 71.7%), but active pipeline is a point-in-time snapshot, not an accumulated metric — the days-elapsed pace framing does not apply. Judged simply against target, coverage is short by $1M (25%). What moved this week: No week-over-week movement data was provided. The file only contains point-in-time QTD actuals; there is no prior-week snapshot or weekly delta in the supplied data, so I cannot describe what moved this week without inventing figures. The data does indicate two structural gaps worth flagging instead: DS2s and same-quarter closes are the furthest behind pace (53% and 50% of target respectively), and the closed-lost MIA rate (20%) is double its 10% target — a quality-of-loss signal that warrants attention even though I cannot attribute any change to this specific week.
Q3 forecast is $115,977 (44,729 committed plus 35% of 203,565 best case, 54 in-quarter deals). Treat it as directional, not real: the 7 committed deals total only 44,729 and all lack a documented why-buy, with owner blank on 85 of 86 deals. Before we quote this, re-qualify the October pushes and back the commit number with a reason to buy.
Subject: Following up on the 150-seat pricing recap Hi [VP People name], Wanted to circle back on the recap I sent on August 5 with pricing for 150 seats. Since your team's strong reaction to the automated milestone awards and the points catalog during the July 28 demo, I haven't heard back — and I know birthdays and anniversaries are still being tracked manually today. If the pricing or seat count needs adjusting, I'm happy to revisit either. Would you have 15 minutes in the next week or two to walk through next steps? Best, Alex Franklin --- Word count: ~85. Note: the VP People's name is not present in the data, so I left the salutation as a placeholder rather than invent one — fill it in when you have it.
Marketing came in slightly under plan this week, with 46 sales-qualified meetings against a target of 52. The webinar channel did the heavy lifting, contributing 18 of those SQMs, while cost per SQM on paid search held steady at 150 dollars. We're closing the gap and the levers are visible. Sales kept momentum rolling, converting 14 sales-qualified opportunities and setting 9 DS2 meetings. New pipeline created reached 310,000 dollars, and the team logged 3 same-quarter closes for the week — real recognition-worthy progress worth celebrating. CS continues to protect the base, saving 2 renewals this week as team NPS ticked up to 61. We're carrying 3 open red-flag accounts into next week, so the focus stays on getting ahead of those relationships before they need rescuing. PLG is compounding nicely: 412 new signups with activation at 31 percent, and 38 companies crossed the aha moment of 10 recognition gives. Those are the moments that turn curiosity into habit, and it's a great sign of product-led momentum.
Partner Digest — 2026-08-24 to 2026-09-04 ACTIVE PARTNERS Apex Rewards Co — 2 sourced deals, $275,000 Deal-DDAAF2: $180,000 Deal-2CF33E: $95,000 (180,000 + 95,000 = 275,000) Both logged DS1 with UTM Source = Partner. Co-webinar locked for 09-15. HRCloud Partners — 1 sourced deal, $140,000 Deal-F1CDA5: $140,000 Referral passed security review; opp advanced to DS2. CultureBridge — 2 sourced deals, $135,000 Deal-096E1D: $60,000 Deal-067213: $75,000 (60,000 + 75,000 = 135,000) Both early stage, from the lunch-and-learn. WorkWell Group — 0 sourced deals, $0 No sourced deals this period. Planning call booked 09-09; wants to restart joint playbook in Q4. QUIET PARTNERS Recogniq — no sourced deals this period. KudosWave — no sourced deals this period. PeopleFirst Advisors — no sourced deals this period. TotalPerk — no sourced deals this period. PARTNER-SOURCED PIPELINE TOTAL 5 deals 275,000 + 140,000 + 135,000 = $550,000 (Count and amount reconcile to partner_deals.csv: 2 + 1 + 2 = 5 deals; $275k + $140k + $135k = $550k.)
Q1 — Yes. Customer data is encrypted at rest using AES-256. [P1] Q2 — Yes. Data in transit is encrypted with TLS 1.2 or higher. [P1] Q3 — Yes. Bonusly maintains a SOC 2 Type II report, renewed annually. A copy is available to prospects under NDA. [P2] Q4 — Customer data is retained for the duration of the contract plus 90 days, after which it is deleted from production systems. [P3] Q5 — The subprocessor list is published at trust.bonusly.com. Customers receive 30 days notice before a new subprocessor is added. [P4] Q6 — Yes. SAML 2.0 single sign-on is available on the Enterprise plan. [P5] Q7 — Production databases are backed up daily. Backups are encrypted and retained for 35 days. [P6] Q8 — Unanswerable. No ISO 27001 certification is referenced in the provided excerpts. This would be answered by the certification/compliance section of the Trust portal or the security overview document. Q9 — Unanswerable. No uptime SLA percentage appears in the provided excerpts. This would be answered by the MSA/terms of service or the service-level agreement document. Q10 — Unanswerable. No HIPAA Business Associate Agreement commitment is referenced in the provided excerpts. This would be answered by the compliance/certifications disclosure or the terms of service.
Reconciliation complete. Findings below, one proposal per finding.
═══════════════════════════════════════════════
(1) OVERLAPPING / DUPLICATE ALWAYS-TRIGGERS
═══════════════════════════════════════════════
[CRITICAL] comms-drafter ⇄ email-drafter
Both skills declare near-identical ALWAYS triggers:
comms-drafter: "write me an email", "draft a follow-up", "help me reply", "what should I say", "bump email", "contract nudge", pasted-message review/rewrite/rating
email-drafter: "write me an email", "draft a follow-up", "help me reply to this", "what should I say", "bump email", "contract nudge", "review this email", "rewrite this", pasted-email feedback
The trigger-phrase sets are effectively duplicates, and both describe the same job (draft/review external messages to prospects and customers). A request that matches one almost always matches the other.
Proposal (MERGE): email-drafter is the narrower skill (email-only, but with richer mechanics — Gmail signature retrieval, markdown-avoidance rules). comms-drafter is the superset (email + Intercom/support + partner/rewards + contract). Fold email-drafter's email-specific rules (signature extraction, "no markdown in email body") into comms-drafter and DELETE_SKILL email-drafter, OR keep both but TRIM_DESC on comms-drafter to narrow it to non-email channels. Recommend comms-drafter survives as the umbrella.
[WARNING] weekly-pipeline-report ⇄ pipeline-intelligence-report
Overlapping triggers: "pipeline update" (verbatim in both), "do/run the pipeline report" vs "run the pipeline report", "what does pipeline look like" vs "what's the pipeline look like", "pipeline summary" vs "full pipeline".
Proposal (TRIM_DESC): weekly-pipeline-report should be scoped to cadence/momentum ("weekly", "this week's numbers", "bookings MTD", "SQM/SQO/DS2"); pipeline-intelligence-report owns scoring/tiering ("score the pipeline", "tier", "full pipeline review"). Remove "pipeline update" and "pipeline look like" from one of the two so a bare "pipeline update" is unambiguous.
[INFO] next-to-close ⇄ pipeline-intelligence-report
next-to-close already contains an explicit routing guard ("Do not use pipeline-intelligence-report for this; delegate if full scored pipeline wanted"). No duplicate-trigger conflict in practice; flagging only because both touch "which deals will close."
Proposal (REVIEW): confirm the guard is honored; no edit strictly required.
═══════════════════════════════════════════════
(2) CIRCULAR DELEGATION CHAIN
═══════════════════════════════════════════════
[CRITICAL] deal-strategy-coach ⇄ email-drafter (2-node cycle)
- 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: "If the user needs strategic deal coaching ... point them to the deal-strategy-coach skill."
A "draft a manager email" request triggers deal-strategy-coach, which hands the draft to email-drafter, which sees "strategic context" and points back to deal-strategy-coach. Unbounded ping-pong.
Proposal (UPDATE_BODY): break the cycle by removing the reverse edge — email-drafter's lane-marker should delegate strategy to deal-strategy-coach but deal-strategy-coach must NOT re-route its own manager-email drafts back through email-drafter as a skill dependency; inline the signature-retrieval step (or call email-drafter only as a terminal formatter, never as a router). One direction only.
═══════════════════════════════════════════════
(3) DANGLING DELEGATION TARGETS (referenced, not in manifest)
═══════════════════════════════════════════════
[WARNING] The following skills are invoked/delegated-to by the 14 files but have no manifest row and no file provided:
- bonusly-brand (comms-drafter, email-drafter, sales-forecast, signalforge-claim-compressor)
- prospect-research-multithreading (comms-drafter, email-drafter, deal-strategy-coach)
- bonusly-data-questions (analysis-validator §12.4)
- bonusly-product-questions (analysis-validator §12.4)
- bonusly-business-reporting-questions (analysis-validator §12.4)
- bonusly-rewards-questions (analysis-validator §12.4)
- bonusly-ppp-questions (analysis-validator §12.4)
- bonusly-feature-flag-questions (analysis-validator §12.4)
- bonusly-deal-desk-questions (analysis-validator §12.4)
- bonusly-datadog-questions (analysis-validator §12.4)
- signalforge-reports (org skill dir — pipeline-intelligence-report, weekly-pipeline-report)
- skill-orchestrator (analysis-validator §11, signalforge-feedback activation checklist)
- caveman (JuliusBrussee/caveman) (signalforge-claim-compressor, described as a related/upstream skill)
Proposal (REVIEW): confirm each target exists as a real skill file elsewhere. Any that are genuinely absent → DELETE_SKILL the reference (or stub the skill). Any that exist → they are missing from this manifest (see finding 7).
═══════════════════════════════════════════════
(4) VERSION CONFLICT
═══════════════════════════════════════════════
[WARNING] analysis-validator: internal version conflict — header/footer declare v3.6, but §7 Validation Trail template still emits "Validator: analysis-validator v3.2" and the changelog lists 3.x entries newest-first (3.6 → 3.0) below the 1.0/2.0/2.6 rows (non-chronological order).
Which should survive: v3.6 (the current declared state). There is a single validator skill — no competing duplicate — so the skill itself survives; only the stale v3.2 string needs correcting.
Proposal (UPDATE_BODY): set the trail-template validator string to v3.6 and normalize changelog ordering.
[INFO] Related roster conflict (not a version, but a consistency conflict worth fixing with the above): analysis-validator §12.3 lists "Core 6 AEs" = Bryce Harmon, Hugo Lindqvist, Dana Mercer, Alex Franklin, Cole Ingram, Gavin Porter. pipeline-intelligence-report Phase 1 lists only 5 AE owner IDs (Bryce, Dana, Cole, Alex, Gavin) and omits Hugo Lindqvist (77260721). Any "Core 6" / "full AE team" filter diverges between the two skills.
Proposal (REVIEW): reconcile the two rosters to one canonical set (analysis-validator's six appears more complete).
═══════════════════════════════════════════════
(5) MANIFEST DESCRIPTIONS EXCEEDING 1,024 CHARS
═══════════════════════════════════════════════
0 (zero). Max recorded description_chars = 1,006.
pipeline-intelligence-report = 1,006
signalforge-claim-compressor = 1,006
partner-digest = 1,004
comms-drafter = 996
All 14 values ≤ 1,006 < 1,024.
Proposal (INFO/TRIM_DESC — headroom only, not a violation): the two at 1,006 and one at 1,004 sit within ~2% of the cap; if the 1,024 limit is a hard downstream truncation threshold, trim these three now rather than at the next edit.
═══════════════════════════════════════════════
(6) HARDCODED PAGE IDs, DATES, AND PERSON NAMES
═══════════════════════════════════════════════
[WARNING] Hardcoded Confluence/space/cloud/page IDs:
- 2257879045 (AE Excellence Playbook — deal-strategy-coach)
- 2286616609 (Partnerships Digest folder), 2286321666 (May 16 2026 issue) — partner-digest
- 2265382925, 2236940297, 2237825028, 2239365136, 2238283777 (canonical partner pages) — partner-digest
- 2232811524 (SignalForg space), 2232582148 (Sales Recurring Reports parent) — sales-forecast
- 2295136266 (Feedback Log), 2234417154 (About SignalForge parent), 2247295002 (Build Log) — signalforge-feedback
- Cloud ID 73fe98de-a4a3-4869-9f8a-bb1eeed4cf7f (partner-digest, sales-forecast, signalforge-feedback); Space ID 1958248479 (partner-digest)
- HubSpot portal 1973303 (URL patterns in pipeline-intelligence-report, next-to-close, stale-pipeline-report)
- Slack channel C0561C1JCPJ / #revops-team — stale-pipeline-report
- Google Sheet IDs 1CLZeOsElVDF_LF0ZG_t2nfwvhnZ6bpwqM_nX3WEYzcw and 1ENuaEcCuLjdKhMvp8FK3Ys1ek5Aw9ZuOZhsHJJFoB_k — weekly-pipeline-report
[WARNING] Hardcoded person names / owner IDs:
- analysis-validator §12.3: full GTM roster (Bryce Harmon 119337721, Hugo Lindqvist 77260721, Dana Mercer 83155923, Alex Franklin 84342457, Cole Ingram 83155924, Gavin Porter 1520255671, Alaina Loori 82535637, Shealagh Coughlin, Colleen Perry, Ellie Barton, Ashley Reyer, Megan Franz, Elena Sinclair, Youssef Elkhateeb, Amanda Czenkus, Ben Castelli, Amani Phipps, John Thomas, Yasmin Wahid) + "Manish / Amani" (Finance escalation, G1-K)
- pipeline-intelligence-report Phase 1: 5 AE owner IDs (see finding 4 — missing Hugo Lindqvist)
- partner-digest: Amani Phipps (owner), Kelli / Jen Lee (BambooHR), Hani / Bryce (Snappy), Sara (PartnerStack)
- weekly-pipeline-report: Ben Lavin (owner, also named in chat-copy) + Q1 static figures ($365,152 vs $475,000 = 77%; $2,490,532 vs $3,288,000 = 76%)
- sales-forecast changelog: "Elena" (stale name, replaced by Alaina)
- closed-lost-analysis: hardcoded example company/person names in taxonomy (Softheon, Estee Lauder, LIFTOFF, Nestlé, Ozinga, MinIO, Aurora Innovation, GCash, Ethos Cannabis, StickerYou)
[WARNING] Hardcoded dates / "as-of" anchors:
- analysis-validator: "April 26, 2026" (created), "May 9, 2026" (updated), "May 4, 2026" (CALL_SPOTLIGHT_BRIEF removal + roster), "March 28, 2023" (HubSpot DEALS stale), "as of May 2026" universe ranges, ~452,000 / ~110,097 user anchors
- deal-strategy-coach: "AE Excellence Playbook April 2026", pricing "2026"
- model-selection: last_checked 2026-05-19; Opus 4.6 deprecation "April 14, 2026"; per-model knowledge cutoffs
- partner-digest: "May 16, 2026" reference issue; "Week of May 19, 2026" / "June 2, 2026" examples
- pipeline-intelligence-report: "May 2026" / "verified May 2026"
- sales-forecast: "Q2 (April 1 – June 30, 2026)"; changelog "April 27, 2026"
- weekly-pipeline-report: "Q2 (April 1 – June 30, 2026)", "Q1 2026 context" static numbers
- stale-pipeline-report: changelog "2026-06-10"
Note: several of these skills contain explicit "never hardcode / resolve dynamically" rules that their own bodies violate (stale-pipeline-report says "never hardcode rep names"; analysis-validator and pipeline-intelligence-report hardcode owner IDs; stale-pipeline-report hardcodes a support owner ID 55483190 as a counter-example).
Proposal (UPDATE_BODY): move rosters/owner-ID maps, portal/space/page IDs, and "as-of" counts to a single shared reference (the signalforge-reports org skill or a roster reference) and load at runtime; keep only truly immutable constants (pipeline='default', stage-ID map) inline. At minimum, reconcile the two AE rosters (finding 4).
═══════════════════════════════════════════════
(7) MANIFEST DRIFT (BOTH DIRECTIONS)
═══════════════════════════════════════════════
Files with no manifest row: NONE. All 14 provided files have a matching manifest row.
Manifest rows with no file: NONE. All 14 manifest rows have a matching provided file.
The two name sets are identical (analysis-validator, closed-lost-analysis, comms-drafter, deal-strategy-coach, email-drafter, model-selection, next-to-close, partner-digest, pipeline-intelligence-report, sales-forecast, signalforge-claim-compressor, signalforge-feedback, stale-pipeline-report, weekly-pipeline-report = 14 each).
[INFO] Caveat on drift that the presence/absence check misses: the description_chars and body_lines columns were not independently re-measured against the file text (only the file/name cross-reference was verifiable from the provided data). If those two columns must be exact, re-verify description_chars against each frontmatter description and body_lines against each file before trusting them. The referenced-but-absent skills in finding (3) — bonusly-brand, prospect-research-multithreading, the bonusly-*-questions family, signalforge-reports, skill-orchestrator, caveman — are the likely source of real manifest drift: if those files exist on disk, they are missing from skill_manifest.csv.
Proposal (REVIEW): confirm whether the finding-(3) referenced skills exist as files; add any that do to the manifest, and remove/flag references to any that do not.
Runbook — incident-2026-08-29-reward-queue (reward-worker queue depth > 10k) Derived solely from the thread. Where the thread is silent, the step is marked "NEEDS CONFIRMATION" and nothing is invented. Step 1 — Acknowledge and take incident command Action: Acknowledge the PagerDuty alert and take IC. Ran by: Bryce Harmon Source: M01 Success verified: Thread records the ack, but does not state how ack was confirmed in PagerDuty. (No state changed — no rollback.) Step 2 — Measure current queue depth (baseline) Action: bundle exec rake sidekiq:queue_depth Ran by: Farid Osman Source: M02 Result: reward queue at 48,213 pending jobs; normal is under 500. Success verified: The command returned a concrete depth number. Rollback: none (read-only). Step 3 — Inspect dead set Action: Reported that the dead set has 112 jobs, all Redis::TimeoutError from around 13:58. Ran by: Farid Osman Source: M03 Success verified: Dead-set count and error type/time reported. NEEDS CONFIRMATION: the thread does not state the exact command used to inspect the dead set (e.g. `sidekiq:dead` or a console call). Do not assume the command. Rollback: none (read-only). Step 4 — Pause enqueue to stop the bleed Action: bin/rails runner 'FeatureFlag.disable(:auto_recognition_enqueue)' Ran by: Farid Osman Source: M04 Success verified: NOT explicitly stated in the thread. The thread records the command was run, but does not state the flag was confirmed disabled. Rollback (as stated in thread): bin/rails runner 'FeatureFlag.enable(:auto_recognition_enqueue)' Note: rollback is exactly as quoted in M04. Step 5 — Clear the dead set Action: "cleared out the dead set" (in console) Ran by: Elena Sinclair Source: M05 Success verified: NOT explicitly stated. NEEDS CONFIRMATION: the thread gives no command string for clearing the dead set. Exact command unknown. Rollback: none possible for cleared dead-set jobs; the thread does not state whether the 112 jobs were retried or discarded. NEEDS CONFIRMATION on whether clearing meant requeue vs. purge. Step 6 — Scale workers up Action: kubectl scale deployment/reward-worker --replicas=6 (was 3) Ran by: Bryce Harmon Source: M06 Success verified: NOT explicitly stated at this step; however subsequent depth drop (M07) is consistent with added capacity. Rollback (as stated in thread): kubectl scale deployment/reward-worker --replicas=3 Step 7 — Observe queue draining Action: (read-only observation) Ran by: Farid Osman Source: M07 Result: queue depth down to 9,400 and falling ~1,200/min. Success verified: concrete depth + drain rate reported. Rollback: none (read-only). Step 8 — Verify recovery Action: bundle exec rake sidekiq:queue_depth (returns 0); error rate in Datadog back to baseline. Ran by: Cole Ingram Source: M08 Success verified: depth 0 + Datadog error rate baseline. Rollback: none (read-only). Step 9 — Re-enable enqueue Action: bin/rails runner 'FeatureFlag.enable(:auto_recognition_enqueue)' Ran by: Bryce Harmon Source: M09 Success verified: 40 new jobs processed cleanly in the next 3 minutes. Rollback: none given in thread (this restores the flag; if it needed undoing, the disable command from M04 would be the inverse, but the thread does not state this). NEEDS CONFIRMATION if you want an explicit rollback. Step 10 — Scale workers back down Action: kubectl scale deployment/reward-worker --replicas=3 Ran by: Bryce Harmon Source: M10 Success verified: queue stable at 0; incident resolved. Rollback: none given in thread (the inverse would be --replicas=6 from M06, but not stated). NEEDS CONFIRMATION if you want an explicit rollback. Summary of gaps that need confirmation before this runbook is production-ready 1. Step 3: exact dead-set inspection command is not given. 2. Step 5: exact clear-dead-set command is not given, and it is unclear whether jobs were retried or purged. 3. Step 4 (and Step 6): the thread records the commands but does not state the immediate verification that the flag was disabled / that the scale-up took effect. (Step 6 is indirectly corroborated by M07's drain; Step 4 is not corroborated until M09 re-enables.) 4. Steps 9 and 10: no explicit rollback is stated for re-enabling enqueue or scaling back down. Every command, actor, and rollback above is traceable to a message; I have added no facts, deals, companies, or numbers beyond the thread.
Here is the failure sequenced strictly from the provided data. FIRST ERROR (root cause) - Timestamp: 2026-09-03T14:01:12Z - Service: reward-service - Level: ERROR - Message: Redis::TimeoutError: Connection to Redis at redis-primary:6379 timed out after 5s CASCADE (in order) 1. 14:01:12Z reward-service Redis connection timeout to redis-primary:6379 (root cause). 2. 14:01:20Z reward-service Redis::TimeoutError: retry exhausted for RewardGiveJob 3. 14:01:30Z reward-service Redis::TimeoutError: retry exhausted for RewardGiveJob 4. 14:01:40Z reward-service Redis::TimeoutError: retry exhausted for RewardGiveJob 5. 14:01:40Z sidekiq RewardGiveJob failed: Redis::TimeoutError; retrying in 60s 6. 14:02:28Z sidekiq RewardGiveJob failed: Redis::TimeoutError; retrying 7. 14:02:30Z sidekiq WARN "Queue reward depth above 10,000" (backlog building) 8. 14:03:05Z api-gateway ERROR 502 upstream timeout calling reward-service /gives 9. 14:03:30Z web-app ERROR Give form submission failed: upstream 502 from api-gateway (14:03:31–14:06:52Z: sidekiq retries, repeated api-gateway 502s, repeated web-app 502s) 10. 14:22:10Z reward-service Redis connection restored; resuming job processing (recovery) 11. 14:24:45Z sidekiq Queue reward depth below 500 (drained) SERVICE(S) INVOLVED - reward-service (source of failure, Redis client) - sidekiq (job runner — RewardGiveJob, RecognitionDigestJob) - api-gateway (downstream 502) - web-app (user-facing 502) - postgres — present in logs but UNAFFECTED (checkpoint INFOs continue normally at 14:10:56 onward). JOB(S) INVOLVED - RewardGiveJob (primary; sidekiq_jobs.csv rows J-00001 through J-00012, all Redis::TimeoutError) - RecognitionDigestJob (secondary; J-00013 through J-00016, also Redis::TimeoutError) Arithmetic worth noting: - Enqueue → first error: last reward-service "job enqueued" at 13:59:30Z, first error 14:01:12Z = 1m42s gap. - Outage duration (Redis down → restored): 14:01:12Z → 14:22:10Z = 20m58s. - Sidekiq retry cadence in the csv confirms retries every ~60s (J-00001..06 cluster ~14:01:46–57Z, then next cluster ~14:02:51–58Z ≈ 60s later). DATADOG QUERY TO CONFIRM THE FIRST ERROR service:reward-service status:error "Redis::TimeoutError" This isolates the originating service and the exact error string, and the earliest hit (14:01:12Z) is the confirmed first error. WHAT THE LOGS DO NOT SHOW - No logs from redis-primary itself. The timeout's cause (OOM, CPU saturation, network partition, failover, restart) is not in the data. - No resource metrics (memory/CPU/network) for Redis or reward-service. - What specifically triggered the Redis outage — there is no "redis down / crashed / restarted" event, only the client-side timeout observation. - A ~4-minute silence: no log entries between 14:06:52Z and 14:10:56Z (when postgres checkpoints resume). What happened inside reward-service/sidekiq during that window is unrecorded. - No request counts or magnitude of user impact (how many web-app "Give form" submissions failed, how many jobs were queued vs. retried). - Whether Redis failed over to a replica or was manually restored — the recovery line only states "connection restored." - No confirmation of data integrity (whether any RewardGiveJob ultimately completed or was lost after retries exhausted).
Here's the state of every flag in the export, cross-referenced against the code excerpt. Nine flags total; six have code references, three do not. FLAGS WITH CODE REFERENCES 1. recognition_streaks_v2 — state: ON — targeting: segment:beta_companies (42 companies) Controls: streak tracking. When on, recording a "give" triggers StreakTracker.record(give). 2. points_budget_guardrails — state: ON — targeting: all_companies (220 companies) Controls: point-budget enforcement. When on, calls BudgetService.new(company).enforce!(giver, points). 3. slack_dm_nudges — state: ON — targeting: segment:region_na (87 companies) Controls: Slack direct-message nudges. The nudge job returns early unless enabled, then sends SlackDm.send_nudge(user). 4. redeem_flow_redesign — state: OFF — targeting: targeted_list (12 companies) Controls: redemption UI version. On = renders RedeemV2Component; off = renders RedeemV1Component. Currently off, so the 12 targeted companies still see V1. 5. analytics_dashboard_v3 — state: ON — targeting: segment:tier_three (65 companies) Controls: analytics dashboard. When on, sets @dashboard = AnalyticsV3.new(company). Note: the code excerpt shows no else branch — it is unclear what renders when off. 6. ms_teams_app_v2 — state: OFF — targeting: targeted_list (9 companies) Controls: Microsoft Teams app installation. When on, calls TeamsAppV2.install(company). Currently off, so no V2 installs occur for the 9 targets. FLAGS WITH NO CODE REFERENCE 7. legacy_give_modal — state: OFF — targeting: segment:legacy_plan (14 companies) No matching code reference in the provided excerpt. Cannot describe what it controls from the data given. 8. survey_boosters_q3 — state: ON — targeting: segment:legacy_plan (7 companies) No matching code reference in the provided excerpt. Cannot describe what it controls from the data given. 9. paused_offboard_cleanup — state: OFF — targeting: (none / empty) (0 companies) Two anomalies: no code reference AND no targeting rules. The targeting_rules field is empty and company_count is 0. NOTES ON COUNTING - All nine rows in the export are accounted for above (no flag invented or omitted). - Company counts sum to 456 across rows (42 + 220 + 87 + 12 + 65 + 9 + 14 + 7 + 0 = 456), but this is a raw sum across non-exclusive segments — all_companies (220) overlaps beta_companies, region_na, tier_three, and legacy_plan, so 456 is not a deduplicated total and is not a meaningful population figure. - targeted_list flags (redeem_flow_redesign = 12, ms_teams_app_v2 = 9) are OFF; their counts represent the named target lists, not currently-enabled companies. - segment:legacy_plan appears with two different counts: legacy_give_modal = 14 but survey_boosters_q3 = 7. Same segment, inconsistent export counts — worth flagging as a possible data issue in the export itself.
NDA-1 — GREEN (standard approval)
Reasoning: Mutual, 2-year term with a full standard carve-out set ("(a) is or becomes publicly available... (d) is independently developed, or (e) must be disclosed by law"), Delaware law, and explicit "No license, no obligation to proceed, no exclusivity." No restrictive covenants embedded; nothing unusual to flag.
NDA-2 — YELLOW (counsel review)
Reasoning: Core terms are clean (mutual, 3-year, standard carve-outs, Delaware law), but it embeds a post-termination non-solicit — "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" — a restrictive covenant that extends beyond the confidentiality term and needs review for scope (which employees, mutual enforceability, interaction with local hiring law).
NDA-3 — RED (full legal review)
Reasoning: Multiple material issues compound here: (1) it is one-way, not mutual ("One-way confidentiality in favor of [PARTY C]"); (2) it embeds a three-year non-compete ("Recipient shall not... engage in or provide services to any business that competes with Discloser's business") — a broad, undefined-scope non-compete inside an NDA; (3) a five-year term; (4) governing law/jurisdiction is Ireland with exclusive courts ("laws of the Republic of Ireland, and the parties submit to the exclusive jurisdiction of its courts"), an unusual forum for a US party; and (5) "No confidentiality carve-outs are stated" — no public-information, prior-knowledge, or legally-required-disclosure exceptions.
No arithmetic required (terms are stated as plain integers); no missing data that affects the classifications.