Mean 0.939 · 30/40 perfect tests · $0.09 total · each card: the question → the correct answer (gold) → this model's actual answer
Definitions
- DS2+ deals = open deals whose current stage is DS2, DS3, DS4, or DS5. (DS1 excluded from why-buys check.)
- why-buys non-compliant = why_buys is blank OR a placeholder (<15 chars / tbd, n/a, see notes, etc.). A LONG(n) value counts as substantive/present. Only assessed on DS2+ deals.
- No DS1 timestamp = t_ds1 field is empty, assessed on every open deal.
- Regressed = any stage-entry timestamp (t_ds1..t_ds5) is later than a timestamp for a LATER stage (out of order, i.e. movement backward).
WHY-BUYS COMPLIANCE — DS2+ deals (n=124)
- Overall: 101 / 124 = 81.5% non-compliant (blank why_buys). Only 23 carry a real value (LONG(x) or 15+ chars).
- By owner (owners table names):
Bryce Harmon (119337721): 15 / 18 = 83.3%
Alex Franklin (84342457): 48 / 61 = 78.7%
Dana Mercer (83155923): 18 / 22 = 81.8%
Cole Ingram (83155924): 19 / 22 = 86.4%
Farid Osman (716654662): 1 / 1 = 100.0%
(Elena Sinclair and both archived owners have 0 DS2+ deals.)
NO DS1 TIMESTAMP
- 0 of 156 open deals are missing a DS1 entry timestamp. This gate is clean.
REGRESSED STAGE TIMESTAMPS
- 0 of 156 deals show out-of-order stage timestamps. Clean.
Single-deal tiering (non-compliant DS2+ only; by owner)
- Bryce Harmon: Deal-25F752, Deal-E53952, Deal-C26D20, Deal-C6FE92, Deal-40522D, Deal-D73B89, Deal-C9C286, Deal-CA7DC0, Deal-F0EBBB, Deal-3795AD, Deal-332637, Deal-7BBDFA, Deal-A62B1D, Deal-333EBB, Deal-1CCE5C
- Alex Franklin: Deal-5408B0, Deal-D348E1, Deal-547B2B, Deal-403845, Deal-A2B47C, Deal-C61CF7, Deal-F9A08A, Deal-1FC049, Deal-BA571A, Deal-3EED2C, Deal-60C2C2, Deal-FA053A, Deal-7FA0C3, Deal-E531A6, Deal-5296C9, Deal-278DEC, Deal-4A13AD, Deal-9D0060, Deal-36C33F, Deal-0D0211, Deal-5AD94B, Deal-690476, Deal-6C60D4, Deal-EE195F, Deal-F436DA, Deal-034D49, Deal-EC3025, Deal-317E6F, Deal-0D2F7A, Deal-D1E6C2, Deal-635B8E, Deal-D9A72E, Deal-D9A12F, Deal-CA5E44, Deal-4F775F, Deal-898FC5, Deal-293AF3, Deal-46988D, Deal-712010, Deal-13FEBD, Deal-E73427, Deal-42F601, Deal-55164C, Deal-B936FE, Deal-4B0BEB, Deal-3BA5EA, Deal-5FDCE4
- Dana Mercer: Deal-944310, Deal-B7EBD1, Deal-3974EB, Deal-2465CE, Deal-62D607, Deal-C6D97A, Deal-0660B4, Deal-57887A, Deal-F336B6, Deal-215CCA, Deal-E51FB7, Deal-9DDE86, Deal-F40F04, Deal-5EED42, Deal-DAF1D9, Deal-8952F0, Deal-BA3DDC, Deal-7E2131
- Cole Ingram: Deal-7B3B0F, Deal-FD9F4E, Deal-AF932D, Deal-8BC9F5, Deal-FF809F, Deal-A71728, Deal-B25F40, Deal-CD47A6, Deal-42326B, Deal-FA32A0, Deal-E568D5, Deal-1BA595, Deal-813836, Deal-175395, Deal-2F3A66, Deal-D04904, Deal-481E24, Deal-CFE1E8, Deal-99A240
- Farid Osman: Deal-499BF6
Note: Compliant DS2+ deals (23) carry a substantive why_buys including LONG() values — e.g. Deal-9AAE5F, Deal-6787C2, Deal-584EE5, Deal-93C8BF, Deal-FC22A3, Deal-885F45, Deal-8AD4A5, Deal-15D24F, Deal-1E2498, Deal-BE3D9D, Deal-792D44, Deal-E0B692, Deal-F67D31, Deal-ED725A, Deal-D7E999, Deal-530B50, Deal-92D97D, Deal-44EA29, Deal-7599B8, Deal-C7F9BF, Deal-342E96, Deal-627646, Deal-0D0211 (all present per LONG/char rule).
THREE PROCESS FIXES
1. Make why-buys a hard gate for stage promotion — block a deal from advancing past DS1 until why_buys is 15+ chars and not a placeholder, so blank values can't reach DS2+ (eliminates the 81.5% gap at the source).
2. System-capture stage-entry timestamps (auto-stamped on the stage change event) instead of manual editing, plus an automated order-check that flags any stage move dated out of sequence — current exposure is 0, this keeps it 0.
3. One-time remediation sweep on the 101 existing DS2+ gaps: require owners to backfill why_buys before their next pipeline review, and add a live hygiene dashboard (blank why_buys / missing DS1) to catch recurrence.
All 156 deal rows transcribed and verified (independently re-counted owner ids — counts match the amount parse exactly). Findings: DEALS RESOLVED TO A NAME: 156 of 156 Every distinct owner id in the deals file (119337721, 84342457, 83155923, 83155924, 716654662, 701163055) exists in owners.csv, so all 156 open deals resolved. None required a guess. UNMATCHED OWNER IDS: NONE No deal's owner_id fails to match the owners table. The two ids in owners.csv with no deals — 1520255671 (Gavin Porter), 77260721 (Hugo Lindqvist) — simply don't appear on any open deal, they are not unmatched deals. OWNER IDS MAPPING TO ARCHIVED/DEACTIVATED OWNERS: NONE The owners table flags exactly two owners as archived=true — Gavin Porter (1520255671) and Hugo Lindqvist (77260721). Neither is the owner of any open deal in this extract, so no deal pipeline sits with a deactivated owner. (Listed for completeness even though zero deals map to them.) TOTAL PIPELINE PER RESOLVED OWNER (arithmetic: sum of amount per owner_id) - Bryce Harmon (119337721) — 35 deals — $1,054,144.00 - Alex Franklin (84342457) — 67 deals — $624,310.00 - Dana Mercer (83155923) — 24 deals — $341,195.00 - Cole Ingram (83155924) — 22 deals — $288,161.43 - Farid Osman (716654662) — 7 deals — $4,134.00 - Elena Sinclair (701163055) — 1 deal — $2,100.00 TOTAL OPEN PIPELINE (all resolved): 156 deals — $2,314,044.43 Note: $2,314,044.43 is the sum of the amount field exactly as given; it is dominated by Bryce Harmon's $1,054,144 (35 deals, ledger includes two $1 placeholder records and large DS1/PIPELINE deals like Deal-2D1F1B at $240,000 and Deal-66D1FC at $99,000).
All three integrity checks computed. Findings below.
CALL-TO-DEAL MAPPING — INTEGRITY CHECK
Source: gong_calls_by_deal_90d.csv (67 rows) joined to deals_open.csv (156 rows) on hs_deal_id = deal_id.
(a) ORPHANS — gong rows with NO match in deals_open: 30 of 67 gong rows (45%)
No match means the deal id is not in the current open default-pipeline deals. Sample aliases, highest call volume first:
Deal-8FA85D (46 calls)
Deal-8FC3F9 (24)
Deal-3B7945 (21)
Deal-42B265 (21)
Deal-9CCC42 (17)
Deal-36EA09 (17)
Deal-9A43B4 (14)
Deal-605F3C (12)
Note the pattern: the bot-heavy accounts (calls 46/24/21/21/17...) are all orphans, and they carry calls_90d that exceed the 90-day window (last_call dated into Nov 2026, e.g. Deal-8FA85D last_call 2026-11-05). All 30 orphans are in this block. There is no deals_open record for any of them.
(b) DUPLICATE CONVERSATION KEYS — rows where calls_90d > distinct_conversation_keys: 0
Every gong row has calls_90d equal to distinct_conversation_keys (e.g. Deal-C6FE92 = 11/11, Deal-8FA85D = 46/46). No row shows duplicate conversation keys at the deal-rollup level. (Caveat: this table is already collapsed to distinct keys per deal, so cross-deal or per-call duplicates can't be detected from this aggregation alone — I can only confirm nothing exceeds 1:1 at this grain.)
(c) OPEN DEALS AT DS3 OR LATER WITH >=1 LOGGED CALL
Arithmetic: 85 open deals are at stage DS3/DS4/DS5. Of those, 25 have a matching gong row (deal_id appears in the gong table). 60 have no logged call at all.
Share with at least one logged call = 25 / 85 = 29.4%.
Interpretation caveats, kept to the data:
- Orphans (a): gong_owner_id is a Gong user id (e.g. 4729257026550273695), not a HubSpot owner id — consistent with the note; no owner join was attempted. The orphan deals are not in the open default pipeline, so they are either non-default-pipeline or closed/won/lost deals; the given files don't tell us which. I'm flagging this as data missing rather than assuming.
- The 30 orphans include the entire 46→4-call block (Deal-8FA85D … Deal-3B6668) as well as a few lower-count ones (Deal-3F86A0, Deal-9897FA, Deal-422BA6, Deal-B038F0, Deal-38CA53, Deal-AC944F). These are exactly the calls_90d = calls_with_ds2_date = calls_with_sqo_date = 0 rows except a handful that do have ds2/sqo dates but no open deal.
- Of the open DS3+ deals missing calls (60), sample aliases: Deal-9AAE5F, Deal-403845, Deal-6787C2, Deal-FC22A3, Deal-7BBDFA, Deal-1CCE5C. These are open, material-stage deals with zero logged Gong calls — the engagement-tracking gap.
```sql
-- Per customer company: first calendar month as a customer and its
-- unique givers, recognition count, and successful redemption count.
SELECT
COMPANY_ID AS customer_company,
DATE_TRUNC('month', SIGNUP_DATE) AS first_calendar_month,
M1_USERS AS unique_givers,
M1_GIVES AS recognition_count,
M1_REDEMPTIONS AS successful_redemption_count
-- FROM choice: PRODUCTION.PLG.COMPANY_COHORT_SUMMARY is the only populated
-- source that carries, per company, its first-month (M1) aggregates for all
-- three required metrics: M1_USERS (unique givers), M1_GIVES (recognition
-- count), M1_REDEMPTIONS (successful redemptions). There is NO transaction-
-- level giving/recognition event table in the catalog to recompute these from,
-- so to answer "first month as a customer" the pre-rolled M1_* columns are the
-- correct source.
--
-- Deliberately NOT used:
-- * HUBSPOT_HUB_1973303.V2_LIVE.OBJECTS_DEALS -- exists but UNPOPULATED
-- * PRODUCTION.HUBSPOT.DEALS -- STALE (last sync 2023-03)
-- * PRODUCTION.HUBSPOT.GONG_HUBSPOT_MAP_FAST -- RETIRED pattern
-- * PRODUCTION.DEPRECATED_RECOGNITION.REDEMPTION_RECORDS_V2 -- lacks the
-- date + company linkage needed to isolate each company's first month, and
-- the schema name says DEPRECATED (needs confirmation before finance use).
--
-- Deleted-giver filter: NOT applied here. Per the documented business rule,
-- excluding deleted givers must NOT be applied to historical giving counts
-- (it understates history). M1_USERS/M1_GIVES are the un-filtered historical
-- counts for the company's first month, so no such filter is added.
--
-- Redemption semantics: M1_REDEMPTIONS aligns with the documented rule that
-- only STATE = 'succeeded' redemptions count.
--
-- Caveat: COMPANY_COHORT_SUMMARY holds one row per SELF-SERVE company, so this
-- answers the question only for self-serve customers, not sales-assisted ones.
FROM PRODUCTION.PLG.COMPANY_COHORT_SUMMARY;
```
DEALS DATA: MISSING — No deals file (owner, stage, amount, close date, why-buy) was provided in this extract. I cannot audit deal fields or compute pipeline dollar amounts at stake. Completeness for deals is therefore 0/5 fields auditable = N/A ("no data present"). I flag this explicitly and rank fixes below by company employee count as a transparent proxy for account value — NOT by pipeline dollars, which do not exist in this extract.
===============================================================
1. FIELD COMPLETENESS (present / total = %)
===============================================================
DEALS (no file supplied)
owner 0 / 0 = NO DATA
stage 0 / 0 = NO DATA
amount 0 / 0 = NO DATA
close date 0 / 0 = NO DATA
why-buy 0 / 0 = NO DATA
-> These fields cannot be audited; the extract has no deal rows.
COMPANIES (34 total)
industry 34 / 34 = 100.0% (present, but not normalized — see below)
employee_count 25 / 34 = 73.5% (9 blank)
hq_country 28 / 34 = 82.4% (6 blank)
CONTACTS (52 total)
email 52 / 52 = 100.0% (present, but 4 malformed — see sec. 4)
title 39 / 52 = 75.0% (13 blank)
persona 37 / 52 = 71.2% (15 blank)
Industry is 100% populated but badly normalized — 4 spelling variants for one
concept: "Technology" / "tech" / "Tech " (trailing space) / "Computer Software"
(enrichment), and "Healthcare" / "health care".
===============================================================
2. DUPLICATE COMPANY CLUSTERS (shared domain)
===============================================================
Two clusters, both real duplicates, both sharing a domain:
CLUSTER A: ACME (domain acme-corp.com)
C-0A092931 acme-corp.com Technology 500 US
C-0A092932 acme-corp.com tech 510 USA
Survivor: C-0A092931 (canonical industry "Technology"; kept as base).
Open conflict: employee_count 500 vs 510. Neither is in the enrichment
export, so I cannot resolve it from data — flag for manual look-up.
CLUSTER B: GLOBEX (domain globex.io)
C-0A092933 globex.io SaaS 200 US
C-0A092934 globex.io Technology 200 US
Survivor: C-0A092934 ("Technology" matches the CRM/enrichment taxonomy;
"SaaS" is the outlier). Same employee count + country, no conflict.
No third cluster: the remaining "tech/Technology/Tech " and
"health care/Healthcare" rows are distinct domains, not duplicates — just a
normalization problem (fix via picklist, not dedupe).
===============================================================
3. CONTACTS MISSING TITLE / PERSONA (field-level)
===============================================================
13 missing title: CT-0000 (2D1F1B), CT-0022 (C6FE92), CT-0072 (44EA29),
CT-0080, CT-0081 (92D97D), CT-0092 (D04904), CT-0120, CT-0121, CT-0122
(AA8DDA — all three), CT-0132 (B23205), CT-0141 (E51FB7), CT-0162 (D0662E),
CT-0170 (B25F40).
15 missing persona: CT-0000 (2D1F1B), CT-0022 (C6FE92), CT-0041 (D73B89),
CT-0060 (96039F), CT-0070 (44EA29), CT-0081, CT-0082 (92D97D), CT-0092
(D04904), CT-0110 (77A95A), CT-0132 (B23205), CT-0162 (D0662E), CT-0171,
CT-0172 (B25F40), CT-0180, CT-0181 (60C75F).
Note: CT-0000 (C-2D1F1B) has email, title AND persona all blank — fully
incomplete contact and so is CT-0092, CT-0132, CT-0162.
===============================================================
4. INVALID EMAILS & DOMAIN MISMATCHES
===============================================================
INVALID (no domain, "userN@" only — unusable):
CT-0010 C-66D1FC 'user0@'
CT-0080 C-92D97D 'user0@'
CT-0081 C-92D97D 'user1@'
CT-0192 C-425E2A 'user2@'
-> 4 / 52 = 7.7% unrouteable.
DOMAIN MISMATCH (valid-format address but domain != company domain):
CT-0011 C-66D1FC user1@other-domain.com (company domain is 66d1fc.com)
-> 'other-domain.com' is not any company in this extract — likely wrong/
stale address or an acquired alias. Verify before outreach.
No other email/domain mismatches; all remaining addresses match their
company's domain.
===============================================================
5. ENRICHMENT FILL (blank -> zoominfo) + CRM-vs-Zoominfo DISAGREEMENTS
===============================================================
Enrichment export covers 25 of 34 companies. 9 not present: 332637.com,
93c8bf.com, ba969b.com, c9bb20.com, ee9ffb.com, acme-corp.com (x2), globex.io
(x2).
FILLS (CRM blank, enrichment has value) — applied:
employee_count: C-EC3025 -> 400, C-96039F -> 400, C-44EA29 -> 400,
C-D04904 -> 400, C-B23205 -> 400, C-60C75F -> 400,
C-7BBDFA -> 400, C-50D386 -> 400 (8 fills)
hq_country: NONE — enrichment's hq_country is ALSO blank on every row
whose CRM value is blank. Nothing to gain here.
Post-enrichment employee completeness: 33 / 34 = 97.1% (only C-93C8BF 93c8bf.com
remains blank — no enrichment row). hq_country stays 28 / 34 = 82.4%; the 6
still-missing (C-2D1F1B, C-D73B89, C-44EA29, C-D04904, C-2C60E5, C-EE9FFB)
have blank HQ in enrichment too -> need a NON-zoominfo source.
INDUSTRY DISAGREEMENTS (CRM vs Zoominfo both present, different):
C-66D1FC, C-EC3025, C-44EA29, C-92D97D, C-D04904, C-77A95A, C-AA8DDA,
C-B25F40, C-60C75F, C-425E2A
All are the same semantic: CRM "Technology"/"tech"/"Tech " vs Zoominfo
"Computer Software". NO case is a true contradiction (e.g. Retail vs
Finance). Recommendation: treat Zoominfo as source of truth for taxonomy —
it's normalized and consistently coded — and rewrite all CRM variants to
"Computer Software". Same for country spelling "US"/"USA" -> enrichment
"United States" (identical geography, cosmetic normalize only).
EMPLOYEE/COUNTRY: zero true disagreements where both CRM and enrichment are
populated (all 900/1500/340/120/50 values match exact). The only numeric
conflict is inside the ACME duplicate (500 vs 510), which enrichment does not
cover.
===============================================================
6. TEN FIXES, ranked by account size (employee count = VALUE PROXY)
*** Proxy only — real "pipeline $ at stake" is UNCOMPUTABLE: no deal
amounts, stages, or owners exist in this extract. ***
===============================================================
1. C-EE9FFB (1500 emp) — hq_country BLANK and NOT in enrichment. Biggest
account with an unfixable-from-data gap; needs external HQ look-up / manual.
2. C-77A95A (1500) — industry "Technology"->"Computer Software"; CT-0110
persona blank.
3. C-AA8DDA (1500) — industry taxonomy fix; ALL three contacts (CT-0120/121/122)
missing title.
4. C-66D1FC (900) — industry fix; 1 invalid email (CT-0010) + 1 domain
mismatch (CT-0011 other-domain.com). Highest-value account with broken email.
5. ACME cluster C-0A092931 / C-0A092932 (500/510) — neutralize duplicate;
resolve 500 vs 510 employee conflict (no enrichment; manual). Survivor
C-0A092931.
6. C-EC3025 (fills to 400) — employee_count filled from zoi; industry fix.
7. C-D04904 (400) — employee filled from zoi; industry fix.
8. C-B23205 (400) — employee filled from zoi (400).
9. C-60C75F (400) — employee filled from zoi; industry fix.
10. C-96039F (400) — employee filled from zoi (Finance matches).
Same-tier runners-up not in the 10 (identical fix, ~same size): C-44EA29,
C-7BBDFA, C-50D386 (fill employee_count 400; C-44EA29 also needs industry fix),
and C-93C8BF (employee BLANK, not in enrichment -> needs manual), GLOBEX
cluster (200 emp, duplicate, survivor C-0A092934).
NET: after fixes, employee completeness 97.1%, contacts' persona the worst
field at 71.2% (15 blanks), and the two structural risks are (a) NO deals data
at all and (b) 6 accounts with unresolvable HQ (blank in both CRM and
Zoominfo) — those need a second enrichment source (e.g. LinkedIn/D&B) or manual
curation, not more Zoominfo.
Analysis of closed_lost_6mo.csv — 90 deals, $1,267,945.16 total amount. Classification is per-deal, based only on the structured tag plus the free-text reason (tie goes to the free-text where the two conflict).
PRIMARY CATEGORY COUNTS (from tag + free-text together)
no decision 30 (unresponsive/MIA, not interested, leadership pause, no approval)
competitor 25
timing 22 (hold / "revisit next year" / pushed to 2027-28)
pricing 6
product gap 4
other 2
champion left 1
TOTAL 90
SIDE SPLIT (which party's situation drove the loss)
Bonusly 4 (all product-gap: Deal-8E27DA, Deal-9048EB, Deal-3618CC, Deal-981AD4)
buyer 84
unknown 2 (Deal-7CC678 "Nothing specific provided", Deal-5DB9B0 "Spam.")
TOTAL 90
DEALS WHERE THE STRUCTURED TAG CLEARLY DISAGREES WITH THE FREE TEXT: 19 of 90
Deal-ED9AE7, Deal-5E64CE, Deal-2FEDDB, Deal-13E9CF, Deal-70F704, Deal-E74A73,
Deal-FAC17C, Deal-50E5D8, Deal-FEDBCB, Deal-7FBAC6, Deal-413C56, Deal-ABD14C,
Deal-8E27DA, Deal-9048EB, Deal-3618CC, Deal-5AD03E, Deal-F325A5, Deal-5DB9B0,
Deal-2A292B
Examples of the mismatch: 11 of them carry the "Doing nothing/Not a priority/Cost"
tag but the free text says it is NOT a cost issue (e.g. Deal-13E9CF "Not a budget
issue", Deal-7FBAC6 "pause (again)", Deal-413C56 "CEO not ready"); three carry
"Lost DM" but the text describes approval/product issues (Deal-FAC17C couldn't get
final approval, Deal-3618CC "Wanted Surveys", Deal-F325A5 "Layoffs and Change in
Leadership"); Deal-9048EB is tagged MIA but the text says "multiple feature gaps".
TWO PATTERNS MOST WORTH ACTING ON
1. The real loss reason is mostly deferral, not loss. Once you reconcile text vs tag,
no decision (30) + timing (22) = 52 of 90 deals (58%) failed because the buyer
"paused," "went on hold," or went MIA/unresponsive and asked to reconnect in 2027 —
not because they rejected Bonusly or picked a rival. This is a pipeline-maturity /
data-hygiene problem: these aren't closed-lost losses, they're stalled opportunities
being marked lost. Actionable: introduce a "hold / revisit-on-date" stage instead of
killing them, bake re-engagement into the cadence (most name a specific window: early
2027, Q2, contract end), and tighten deal-qualification so 52 deferrable prospects
aren't consuming closed-won follow-up effort.
2. Product and positioning gaps are being under-counted and mis-tagged. The structured
data would say Bonusly lost only on product via 2 "Feature Request" tags; the free text
reveals real product shortcomings hiding under other tags: Deal-3618CC wanted surveys
but Bonusly lost it under "Lost DM"; Deal-9048EB ("multiple feature gaps") under MIA;
Deal-242273 mentions inability to digitize/spend points at onsite facilities; Deal-981AD4
"Doesn't fit UI and not UK focused." There is also a clear geographic/currency strand:
three deals lost to Canadian buyers/localization (Deal-DDAB52 to Rippl on "exchange rate
differences," Deal-9FCD0D CEO-mandated Canadian company, Deal-8A0992 "Canadian provider
that more closely aligns"). Those are positioning/localization gaps, not "competitor
wins." Actionable: fix the closed-lost taxonomy (collapse the overloaded "Doing
nothing/Not a priority/Cost" tag, add a true "feature/geography" reason) so the 19
mis-tagged deals stop distorting loss reporting, and separately assess a North-America
currency/localization play for the Canadian segment.
Caveat on the data: currency is amount as recorded (no currency field given); 7 amounts
are non-whole dollars, and 5 deals carry no usable reason beyond tag or a generic "MIA,"
so their side is inferred as buyer from the tag.
All 156 deals tiered and internally validated (lock_violations=0, tiers sum to 156). Final output:
```json
{
"tier_counts": {
"LOCK": 3,
"ACTION": 38,
"BUILD": 14,
"REVIVE": 16,
"WATCH": 70,
"RISKY": 15
},
"tier_examples": {
"LOCK": ["Deal-D348E1", "Deal-C26D20", "Deal-403845"],
"ACTION": ["Deal-25F752", "Deal-944310", "Deal-3974EB"],
"BUILD": ["Deal-012CB1", "Deal-CA7DC0", "Deal-3795AD"],
"REVIVE": ["Deal-9AAE5F", "Deal-6787C2", "Deal-2D1F1B"],
"WATCH": ["Deal-E53952", "Deal-5408B0", "Deal-C61CF7"],
"RISKY": ["Deal-547B2B", "Deal-B7EBD1", "Deal-A2B47C"]
},
"risky_deals": ["Deal-547B2B", "Deal-B7EBD1", "Deal-A2B47C", "Deal-2465CE", "Deal-584EE5", "Deal-0660B4", "Deal-FD9F4E", "Deal-BA571A", "Deal-7BBDFA", "Deal-4A13AD", "Deal-690476", "Deal-635B8E", "Deal-F336B6", "Deal-BA3DDC", "Deal-7599B8"],
"lock_violations": 0,
"pipeline_shape": "The 156-deal open book is heavily weighted toward the middle and bottom of the funnel: nearly half (70) sit in WATCH (early-DS1/DS2 or low-activity), and 45% are held at DS3/DS4 in BEST_CASE/PIPELINE with mixed engagement, against just 3 genuine LOCK commitments (all COMMIT/DS4-5 with live meetings). Engagement quality is the differentiator — 15 deals (10% of the book) are RISKY because their COMMIT/BEST_CASE forecast carries zero inbound meetings in 30 days and the last contact is 14+ days stale, flagging forecasts that outrun the engagement evidence. This leaves a thin, concentrated near-term close base (LOCK+ACTION = 41 deals) supporting most of the forecasted amount, with the 16 REVIVE deals (long-cycle or high-value but aged out) representing recoverable upside, and a broad WATCH tail of small/early or quiet opportunities that will not convert without renewed attention."
}
```
Note on the one missing data point: Deal-57FF13 (DS1/PIPELINE) has a blank n_contacts field; I excluded it from that field's signal and relied on its meeting count (0) — it tiers to WATCH. All counts above sum to the full 156-deal book.
CRM write-back field extraction, prospect-sourced only. Rep statements are excluded entirely (e.g. price quotes in TX-003, follow-up offers, "we support SSO" — not used).
TX-001 — Deal-CFE7F4
```json
{
"transcript_id": "TX-001",
"deal_alias": "Deal-CFE7F4",
"why_buys": [
"Automating anniversary and birthday awards — HR team of three cannot keep up manually"
],
"pain_points": [
"HR team of three cannot keep up with manual anniversary/birthday award process",
"Tracking everything in a spreadsheet — people slip through the cracks"
],
"stakeholders": ["Prospect (VP People)", "Prospect (HR Admin)"],
"budget_signal": "~$40k earmarked for engagement tools this fiscal year",
"timeline_signal": "Live before open enrollment in November",
"competitor_mentioned": "Achievers (prospect raised: looked at last year, too heavy for team size)",
"next_step": "Agreed security review on September 12",
"objections": [
"Achievers too heavy for a team their size (comparative objection)",
"Need SSO and audit logs for IT to sign off"
],
"confidence": "MEDIUM-HIGH — budget, timeline, next step all stated by prospect; no pricing objection surfaced"
}
```
TX-002 — Deal-70BB30
```json
{
"transcript_id": "TX-002",
"deal_alias": "Deal-70BB30",
"why_buys": "Tie recognition to retention for hourly workforce — regretted turnover over 30%",
"pain_points": ["Regretted turnover over 30% in hourly workforce"],
"stakeholders": ["Prospect (Head of Total Rewards)", "Prospect (CFO)"],
"budget_signal": "$25k pilot budget approved this quarter (finance-approved)",
"timeline_signal": "Decision by end of September",
"competitor_mentioned": "None raised — prospect: 'you're the first vendor we've had a real demo with'",
"next_step": "Send pilot agreement; prospect will route to legal this week",
"objections": [
"Workday integration must be rock solid — stated as CFO's one condition"
],
"confidence": "HIGH — finance-approved budget, explicit timeline, clear next step, single named condition"
}
```
TX-003 — Deal-530B50
```json
{
"transcript_id": "TX-003",
"deal_alias": "Deal-530B50",
"why_buys": "Make recognition visible across 12 retail locations",
"pain_points": ["Store managers have zero budget autonomy for on-the-spot recognition"],
"stakeholders": ["Prospect (People Ops Manager)"],
"budget_signal": null,
"timeline_signal": "No rush on their side until Q1 (soft / future)",
"competitor_mentioned": "Bucketlist (prospect raised: CEO used it at her last company and liked it)",
"next_step": "Schedule a call with the CEO — PPM will send two times",
"objections": [
"CEO must be sold first — she decides anything people-related",
"No budget autonomy currently at store-manager level"
],
"confidence": "MEDIUM — real interest but no budget stated; next step depends on CEO buy-in still unsecured; no amount or deadline"
}
```
TX-004 — Deal-180D02
```json
{
"transcript_id": "TX-004",
"deal_alias": "Deal-180D02",
"why_buys": "Consolidate three separate recognition tools into one",
"pain_points": [
"Paying for three tools, none of which talk to their HRIS"
],
"stakeholders": ["Prospect (VP People)", "Prospect (IT Security Lead)"],
"budget_signal": "Under $15k annually, VP People can approve without going to the board",
"timeline_signal": "Procurement cycle runs 6-8 weeks minimum (process constraint)",
"competitor_mentioned": "None — none raised by prospect",
"next_step": null,
"objections": [
"Procurement cycle 6-8 weeks minimum",
"Security review took three months for last vendor — stated as hesitation"
],
"confidence": "LOW-MEDIUM — budget ceiling set but no agreed next action (CFO follow-up not confirmed; 'maybe, no promises'); no firm date"
}
```
TX-005 — Deal-F8767A
```json
{
"transcript_id": "TX-005",
"deal_alias": "Deal-F8767A",
"why_buys": [
"Automate service milestones",
"Analytics on recognition equity across departments"
],
"pain_points": [
"Night-shift teams feel invisible — engagement scores run 20 points lower"
],
"stakeholders": ["Prospect (HR Director)", "Prospect (People Ops Coordinator)"],
"budget_signal": "$12k approved under their engagement line",
"timeline_signal": "Needs to run before January all-hands",
"competitor_mentioned": "Nectar (prospect raised: mid-pilot right now; must beat that experience)",
"next_step": "Present to exec team on October 2",
"objections": [
"Exec team skeptical after a failed rollout two years ago",
"Mid-pilot with Nectar — must beat that experience"
],
"confidence": "MEDIUM-HIGH — budget, hard date, agreed presentation; but live incumbent (Nectar) and exec skepticism remain open"
}
```
TX-006 — Deal-EE195F
```json
{
"transcript_id": "TX-006",
"deal_alias": "Deal-EE195F",
"why_buys": "Cut admin time on service awards",
"pain_points": [
"HR Manager personally spends 5 hours/month ordering and shipping plaques"
],
"stakeholders": ["Prospect (HR Manager)"],
"budget_signal": null,
"timeline_signal": "Q1 start realistic (fiscal year resets in February)",
"competitor_mentioned": "None raised — comparing against building internally ('doing it in-house')",
"next_step": "Send one-page overview; HR Manager will forward to COO this week",
"objections": [
"COO usually prefers building things in-house (build-vs-buy)",
"No other vendor being evaluated — potential sole-source but internal-build is the true alternative"
],
"confidence": "MEDIUM — time driver confirmed, no budget amount on record; forward to COO is a step but COO buy-in (build-vs-buy) unresolved"
}
```
Note on nulls: budget_signal is null for TX-003 and TX-006 because no dollar figure was stated by the prospect in either (TX-006's "budget isn't the issue — time is" confirms budget is not a blocker but gives no amount); TX-004's next_step is null because the rep's requested follow-up was not confirmed by the prospect ("Maybe — no promises").
Using the CRM plus the 2026-09-04 #sales-sparring thread — Slack is treated as the fresher source where the two conflict. 1. Deal-547B2B — $11,200 (Alex Franklin, DS5/COMMIT) Why close: Redlines came back clean, the signing page is out, and per the VP People "signing tomorrow" — explicitly flagged signature-imminent in Slack, and the CRM holds it at DS5/COMMIT. Left: Only the executed signature; nothing outstanding on procurement or legal. 2. Deal-403845 — $9,000 (CRM owner Alex Franklin; Slack credited to Dana Mercer — attribution discrepancy noted; does not affect proximity) Why close: Dana confirms it is "moving fine"; the order form is with finance. CRM shows DS5/COMMIT for 2026-09-11. Left: Finance sign-off on the order form. 3. Deal-B7EBD1 — $9,000 (Dana Mercer, DS5/COMMIT, 2026-09-10) Why close: Latest-stage COMMIT with the earliest close date in the set, and no adverse Slack flag (weeks where every other near-term deal moved sideways: Deal-2465CE frozen, others in legal review). Left: No outstanding blockers reported; awaiting signature. Dropped explicitly: Deal-2465CE ($5,400) still shows DS5/COMMIT in the CRM, but Slack overrides it — champion departed, procurement has frozen new vendors, so it is blocked and realistically Q4. Deal-A2B47C and Deal-D348E1 are warm but only in normal legal review, behind the three above.
Real gaps summary first, then the full candidate breakdown.
REAL GAPS (only these are true product gaps in the docs excerpt)
1. SCIM user provisioning — Deal-EC3025 (TG-001)
2. ADP Workforce Now integration — Deal-D0D6B5 (TG-002)
Amounts: not included anywhere in the provided data. Nine deals are implied by the target list (Deal-EC3025, Deal-D0D6B5, Deal-CFE7F4, Deal-84DBA6, Deal-36C33F), but the transcripts_gaps.csv has no dollar/ARR/ACV column and product_docs.md has none either. I will not invent deal values. If you have a deal-amount file, point me at it and I'll attach the numbers.
--------------------------------------------------------------------------------
CANDIDATE 1 — Deal-EC3025 (TG-001)
Prospect line (IT Security Lead): "We need SCIM user provisioning — our security team will not approve any tool that requires manual account management."
Docs cross-check: product_docs.md "Supported integrations" states "SCIM user provisioning and ADP Workforce Now integrations are NOT currently listed as supported capabilities."
Classification: REAL GAP. Missing capability, not a plan tier, not a rollout matter — the feature simply isn't shipped.
CANDIDATE 2 — Deal-D0D6B5 (TG-002)
Prospect line (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 cross-check: HRIS list = "Workday, BambooHR, Gusto, Rippling (Pro and above)". docs explicitly state ADP Workforce Now is NOT currently listed.
Classification: REAL GAP. Missing integration, named by the prospect as a stated dealbreaker.
CANDIDATE 3 — Deal-CFE7F4 (TG-003)
Prospect line (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 cross-check: Custom report builder = Enterprise tier only ("| Custom report builder | — | — | yes |").
Classification: PLAN GATE, not a real gap. The capability exists in the product and is already built; the blocker is the prospect's current tier. Rep (Alex Franklin) confirms: "The custom report builder sits on our Enterprise tier — I can walk you through upgrade paths." This is an upsell path, not a product hole.
CANDIDATE 4 — Deal-84DBA6 (TG-004)
Prospect line (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 cross-check: Slack integration = supported on all plans ("yes" across Core/Pro/Enterprise).
Classification: ROLLOUT / ENABLEMENT ISSUE. The feature works; the failure is adoption/training after enablement. Not a product gap. Rep response ("I'll set up a manager enablement session") treats it correctly as enablement.
EXCLUDED — Deal-36C33F (TG-005)
The first speaker in TG-005 is the rep, not the prospect: Alex Franklin: "Full transparency — we don't have a native mobile app for hourly workers yet, though it's on the roadmap." The prospect replies only "Good to know. The web version should be fine..."
Per your rule that rep language does not count as prospect voice, no prospect-raised gap exists in this deal, so it is excluded from the real-gap summary. (Noting: if you want rep-surfaced gaps tracked separately from prospect-raised ones, the missing native mobile app is one — but it is not a prospect-raised gap.)
--------------------------------------------------------------------------------
Bottom line: 2 real product gaps — SCIM provisioning (Deal-EC3025) and ADP Workforce Now (Deal-D0D6B5). Deal amounts unknown; data not provided.
Snapshot date 2026-09-05. "Last 7 days" window = 2026-08-29 through 09-05. A deal is stale if the most recent of last_email / last_call / last_meeting (from engagements_by_deal_90d.csv) is before 2026-08-29. Days since = 2026-09-05 minus that most-recent contact. Grouped by owner, amount descending. Two caveats up front (data missing, stated explicitly): - Deal-3EED2C (DS2, $7,200, Alex Franklin) and Deal-57FF13 (DS1, $2,100, Elena Sinclair) have NO row in the 90-day engagements table, so no email/call/meeting is logged for them at all. They are counted as stale, but days-since-last-contact cannot be computed (shown as N/A). BRYCE HARMON — 13 stale deals | $626,243 Deal-2D1F1B DS1 $240,000 81d Deal-66D1FC DS1 $ 99,000 16d Deal-950043 DS1 $ 70,000 19d Deal-B23205 DS1 $ 45,000 16d Deal-7BBDFA DS3 $ 37,440 46d Deal-332637 DS2 $ 36,000 9d Deal-1BEEBF DS1 $ 31,500 19d Deal-C5658B DS1 $ 23,400 16d Deal-40522D DS3 $ 21,000 19d Deal-F0EBBB DS3 $ 11,400 24d Deal-E25A09 DS1 $ 6,000 9d Deal-C9C286 DS2 $ 5,502 9d Deal-012CB1 DS1 $ 1 23d ALEX FRANKLIN — 19 stale deals | $109,536 Deal-CC08D1 DS1 $ 24,000 16d Deal-E73427 DS3 $ 18,000 10d Deal-885F45 DS2 $ 9,300 12d Deal-C2FF3C DS1 $ 8,316 10d Deal-3EED2C DS2 $ 7,200 N/A (no engagement logged in 90d) Deal-0D2F7A DS3 $ 5,100 12d Deal-6C60D4 DS3 $ 4,800 12d Deal-13FEBD DS2 $ 4,680 12d Deal-9D0060 DS3 $ 3,840 12d Deal-690476 DS2 $ 3,600 18d Deal-C6D97A DS4 $ 3,240 8d Deal-EE195F DS3 $ 3,120 8d Deal-278DEC DS3 $ 2,700 8d Deal-635B8E DS3 $ 2,600 18d Deal-6883F3 DS1 $ 2,400 16d Deal-4A13AD DS3 $ 2,160 26d Deal-F67D31 DS2 $ 1,800 8d Deal-5FDCE4 DS3 $ 1,600 12d Deal-BA571A DS4 $ 1,080 18d COLE INGRAM — 18 stale deals | $252,905 Deal-D04904 DS2 $ 58,529 11d Deal-B25F40 DS3 $ 40,000 8d Deal-813836 DS2 $ 32,175 11d Deal-1BA595 DS2 $ 31,750 11d Deal-CFE1E8 DS3 $ 18,000 11d Deal-CD47A6 DS2 $ 12,168 11d Deal-627646 DS3 $ 11,193 11d Deal-FF809F DS2 $ 7,781 11d Deal-AF932D DS2 $ 7,225 11d Deal-A71728 DS2 $ 6,948 11d Deal-8BC9F5 DS2 $ 5,616 10d Deal-175395 DS3 $ 4,780 11d Deal-481E24 DS3 $ 4,140 10d Deal-C7F9BF DS2 $ 3,360 11d Deal-2F3A66 DS3 $ 3,335 11d Deal-342E96 DS2 $ 2,700 24d Deal-E568D5 DS3 $ 1,875 11d Deal-FD9F4E DS5 $ 1,330 10d DANA MERCER — 14 stale deals | $261,645 Deal-44EA29 DS2 $ 60,000 10d Deal-E51FB7 DS2 $ 43,875 12d Deal-B42F46 DS1 $ 27,000 19d Deal-BA3DDC DS3 $ 23,400 15d Deal-9DDE86 DS2 $ 20,000 15d Deal-215CCA DS3 $ 18,900 17d Deal-5EED42 DS3 $ 16,250 11d Deal-57887A DS2 $ 15,000 8d Deal-B7EBD1 DS5 $ 9,000 16d Deal-3974EB DS4 $ 9,000 8d Deal-F40F04 DS2 $ 8,100 15d Deal-87DDD1 DS1 $ 5,000 19d Deal-F336B6 DS3 $ 4,200 15d Deal-0660B4 DS4 $ 1,920 16d ELENA SINCLAIR — 1 stale deal | $2,100 Deal-57FF13 DS1 $ 2,100 N/A (no engagement logged in 90d) FARID OSMAN — 0 stale deals | $0 SUMMARY BY OWNER Bryce Harmon 13 deals $626,243 Alex Franklin 19 deals $109,536 Cole Ingram 18 deals $252,905 Dana Mercer 14 deals $261,645 Elena Sinclair 1 deal $2,100 Farid Osman 0 deals $0 ------------------------------ TOTAL 65 deals $1,252,429 Note on arithmetic: all "days since" figures = 2026-09-05 minus the latest of the three engagement timestamps; amounts are summed from the deal amount column exactly as given. Farid Osman has no stale deals because every one of his open deals has a last_email or last_meeting dated 2026-08-31 or later (i.e., within the 7-day window).
Analysis complete. Here are the per-rep results (snapshot 2026-09-05; 30-day window for DS2 entry = t_ds2 within 2026-08-06 to 2026-09-05 inclusive; activity totals = the rep's owned deals summed from emails_30d / calls_30d / meetings_30d in the engagements table).
Ratio ranking (total activities ÷ DS2 entries, lowest = most efficient):
Rep Emails Calls Mtgs Total Emails Calls Mtgs DS2 Activities
% % % entries per DS2
Alex Franklin 307 36 41 384 79.9% 9.4% 10.7% 18 21.33 <- most efficient
Bryce Harmon 162 0 43 205 79.0% 0.0% 21.0% 4 51.25
Cole Ingram 96 14 1 111 86.5% 12.6% 0.9% 2 55.50
Farid Osman 38 0 34 72 52.8% 0.0% 47.2% 1 72.00
Dana Mercer 84 18 11 113 74.3% 15.9% 9.7% 1 113.00
Elena Sinclair 0 0 0 0 0.0% 0.0% 0.0% 0 n/a (no DS2)
Arithmetic check (ratio = Total ÷ DS2):
Alex Franklin: 384/18 = 21.33
Bryce Harmon: 205/4 = 51.25
Cole S.: 111/2 = 55.50
Farid Osman: 72/1 = 72.00
Dana Mercer: 113/1 = 113.00
Elena Sinclair: 0/0 = undefined — excluded from ranking (single DS1 deal, Deal-57FF13)
Most efficient rep: Alex Franklin (21.33 activities per DS2 entry).
Highest-volume rep: Alex Franklin — highest total activity (384: 307 emails / 36 calls / 41 meetings) and the most DS2 entries (18: Deal-403845, Deal-1FC049, Deal-3EED2C, Deal-7FA0C3, Deal-E531A6, Deal-5296C9, Deal-36C33F, Deal-EE195F, Deal-F436DA, Deal-317E6F, Deal-D1E6C2, Deal-D9A72E, Deal-CA5E44, Deal-4F775F, Deal-898FC5, Deal-46988D, Deal-E73427, Deal-92D97D).
They do not differ — the same rep is both most efficient and highest-volume.
By activity mix, Alex Franklin is also the only rep whose mix is meaningfully balanced (79.9% email / 9.4% call / 10.7% meeting); Bryce Harmon and Farid Osman show 0.0% calls and rely almost entirely on email (+meetings). Cole Ingram is 86.5% email-dominated. No cause is attributed.
Data notes: Elena Sinclair had no engagements rows and no DS2 entry in window, so her ratio is undefined. Gavin Porter and Hugo Lindqvist (archived owners) have no deals/engagements in this data.
QTD SCORECARD — Alex Franklin — as of 2026-09-05 (2026-Q3)
=================================================================
1) BOOKINGS vs QUOTA
Booked (closed-won in Q3, 07/01–09/30): $150,000
Deal-A1C3E5 40,000 | Deal-F2C7D8 20,000 | Deal-B7D2F4 35,000 | Deal-C9E1A6 21,000
Deal-A8B4D6 12,000 | Deal-D4B8C2 11,000 | Deal-E6F3A9 6,500 | Deal-C5D9E2 4,500
Quota: $200,000
ATTAINMENT = 150,000 / 200,000 = 75.0% (shortfall $50,000; ~25 days left in Q)
Excluded (closed before quarter): Deal-B3E6F1 ($24,000, 2026-06-20)
2) NEW vs EXPANSION SPLIT
New: $113,500 (75.7%) — A1C3E5, B7D2F4, C9E1A6, D4B8C2, E6F3A9
Expansion: $36,500 (24.3%) — F2C7D8, A8B4D6, C5D9E2
113,500 + 36,500 = 150,000 ✓. Growth-skewed; expansion is a minority of booked value.
3) ACTIVE PIPELINE (open, 125 deals; $1,260,390 total)
DS1 n=20 $284,621
DS2 n=28 $353,760
DS3 n=67 $552,705
DS4 n=5 $23,574
DS5 n=5 $45,730
-> Heaviest concentration in DS3 (67 deals, 44% of pipeline value). Thin at top:
only 5 deals in DS4 and 5 in DS5 ($69,304 combined) — little near-term closeable value.
4) ROLLING 90-DAY DS2-TO-WON RATE
Window: entered DS2 on/after 2026-06-07. Resolved deals: 8 won, 27 lost = 35.
DS2-to-won = 8 / 35 = 22.9% (matches overall Q3 win rate)
5) WINS & LOSSES + TOP LOSS REASON
Wins: 8 Losses: 27 (win rate 22.9%)
Loss reasons (of 27):
Lost- Timing (1 year or more) 13 <= TOP
MIA 5
Competitor 5
Lost DM 2
Feature Request 1
Lost- Does not fit ICP (notes) 1
Top reason = "Lost- Timing (1 year or more)", 13/27 = 48% of losses, $184,681 in
lost value (avg $14,206) vs all Q3 losses $329,272 (avg $12,195).
6) ACTIVITY VOLUME — LAST 30 DAYS (all 161 deals tracked)
Emails: 807 Calls: 112 Meetings: 128 Notes: 50
Total touchpoints: 1,097. Email-driven (74%); call volume light relative to meetings.
=================================================================
COACHING OBSERVATIONS (grounded in the numbers)
1) Timing is the single biggest leak, and it is a qualifying problem, not a closing problem.
"Lost- Timing (1 year or more)" is 13 of 27 losses (48%) and $184,681 of value — the
highest-value loss category despite 8 won deals booking only $150,000 total. The AE is
spending motion on deals that cannot close this cycle. This is a DS2/DS3 go/no-go gate:
deal 58754552851 (Deal-B3ABED, $40,001), 62121718303 (Deal-D1A623, $25,200) and
60896018951 were timing losses. Pre-qualify budget/timing (e.g., an explicit "buy by
quarter-end" check) before letting a deal pass DS2 could cut the largest chunk of leak.
2) Pipeline is choked at DS3 and has almost no near-term top-of-funnel conversion.
67 of 125 open deals sit at DS3 (44% of pipeline); only 5 DS4 and 5 DS5 deals exist,
worth just $69,304 combined. With ~3 weeks of Q3 left and attainement at 75%, there is
effectively nothing closeable left in the quarter — the $50,000 shortfall is unlikely to
be covered from this funnel. Length-weighted focus is warranted: the 7 oldest DS3 deals
(e.g., Deal-F9A08A in DS4 since 2025-11-24, Deal-60C2C2 since 2026-02-23) are aging —
DS2-to-won at 22.9% will stay depressed unless DS3 deals are either advanced or qualified
out.
3) Growth is pipeline-healthy but expansion upside is under-managed for the quota gap.
Booked revenue is 75.7% new vs 24.3% expansion, and expansion deals (F2C7D8 20,000, A8B4D6
12,000, C5D9E2 4,500) closed at a higher rate per effort than typical. Meanwhile 5 of the
27 losses, ~$49,020, went to Competitor — a pattern an existing-customer expansion motion
(protect base + grow) could partly defend against, since expansion sells cheaper in this
data. Near-term: rather than chasing 50 fresh deals in 3 weeks to close the $50K gap,
stack expansion/upsell momentum on the current account base, which closes faster (won
cycle 24–41 days) and has a smaller close-date window than new deals.
Cutoff for "active": engaged on/after 2026-07-08 (60 days back from 2026-09-06) AND is_former=false. Note: amount and stage are NOT present in either provided file — I cannot report them, so that field is "not provided in data" for every flagged deal below.
Not flagged (pass): Deal-84DBA6 (3 active: champion+economic buyer+IT security), Deal-4B0BEB (4 active, 4 personas), Deal-D348E1 (5 active, all 5 personas).
===========================================
FLAGGED DEALS (11)
===========================================
1) Deal-EC3025 (61032318100) — C-FDD0C7
amount/stage: NOT PROVIDED in data
active contacts: 1 (CT-047C54, champion)
[CT-F2C1AE economic buyer excluded: is_former=true]
Threading: SINGLE-THREADED (<2 active)
Personas present: champion
Personas missing: economic buyer, HR admin, IT security, finance
Most valuable persona to add: economic buyer
On-file unengaged at company: CT-6827DB, Chief People Officer (economic buyer)
2) Deal-92D97D (59728118877) — C-E23238
amount/stage: NOT PROVIDED
active contacts: 1 (CT-01F5B4, HR admin)
[CT-A902AE champion excluded: engaged 2026-06-01, outside 60 days]
Threading: SINGLE-THREADED (<2 active)
Personas present: HR admin
Personas missing: champion, economic buyer, IT security, finance
Most valuable persona to add: economic buyer
On-file unengaged: NONE on file
3) Deal-50D386 (61055128146) — C-EB10E4
amount/stage: NOT PROVIDED
active contacts: 2 (CT-AA41B2 champion, CT-B9C35B HR admin)
Threading: UNDER-THREADED (<3 active)
Personas present: champion, HR admin
Personas missing: economic buyer, IT security, finance
Most valuable persona to add: economic buyer
On-file unengaged: CT-A1C4B3, Chief People Officer (economic buyer)
4) Deal-D0D6B5 (60081655042) — C-32918E
amount/stage: NOT PROVIDED
active contacts: 3 (CT-87CED4, CT-DE6D7C, CT-FD70B2 — all champion)
Threading: UNDER-THREADED (3 active but all one persona)
Personas present: champion
Personas missing: economic buyer, HR admin, IT security, finance
Most valuable persona to add: economic buyer
On-file unengaged: CT-1FA4DB, Chief People Officer (economic buyer)
5) Deal-5BFE3B (51674270311) — C-535D36
amount/stage: NOT PROVIDED
active contacts: 2 (CT-57123B, CT-5CE757 — both champion)
Threading: UNDER-THREADED (<3 active AND all one persona)
Personas present: champion
Personas missing: economic buyer, HR admin, IT security, finance
Most valuable persona to add: economic buyer
On-file unengaged: NONE on file
6) Deal-36C33F (63739413805) — C-077A0E
amount/stage: NOT PROVIDED
active contacts: 1 (CT-4FE556, IT security)
[CT-405B45 champion & CT-86B22F economic buyer excluded: is_former=true]
Threading: SINGLE-THREADED (<2 active)
Personas present: IT security
Personas missing: champion, economic buyer, HR admin, finance
Most valuable persona to add: economic buyer
On-file unengaged: CT-1DB73E, Chief People Officer (economic buyer)
7) Deal-885F45 (60686135564) — C-5E8EFB
amount/stage: NOT PROVIDED
active contacts: 2 (CT-51C81E economic buyer, CT-D9A0E8 champion)
Threading: UNDER-THREADED (<3 active)
Personas present: economic buyer, champion
Personas missing: HR admin, IT security, finance
Most valuable persona to add: IT security (missing; matching contact on file)
On-file unengaged: CT-B3F25D, IT Security Lead (IT security)
8) Deal-FCBE5B (62639586615) — C-737030
amount/stage: NOT PROVIDED
active contacts: 1 (CT-4A5317, champion)
Threading: SINGLE-THREADED (<2 active)
Personas present: champion
Personas missing: economic buyer, HR admin, IT security, finance
Most valuable persona to add: economic buyer
On-file unengaged: NONE on file
9) Deal-5408B0 (60182332309) — C-2AE3AA
amount/stage: NOT PROVIDED
active contacts: 2 (CT-D33AE4 champion, CT-8742FD HR admin)
Threading: UNDER-THREADED (<3 active)
Personas present: champion, HR admin
Personas missing: economic buyer, IT security, finance
Most valuable persona to add: economic buyer
On-file unengaged: CT-07FA76, Chief People Officer (economic buyer)
10) Deal-C6D97A (62121783047) — C-5A8FC2
amount/stage: NOT PROVIDED
active contacts: 3 (CT-223DDC, CT-B03555, CT-4E8A2B — all champion)
Threading: UNDER-THREADED (3 active but all one persona)
Personas present: champion
Personas missing: economic buyer, HR admin, IT security, finance
Most valuable persona to add: economic buyer
On-file unengaged: NONE on file
11) Deal-F9A08A (49757401138) — C-0D15DF
amount/stage: NOT PROVIDED
active contacts: 1 (CT-931B10, champion)
[CT-913581 economic buyer excluded: engaged 2026-06-20, outside 60 days]
Threading: SINGLE-THREADED (<2 active)
Personas present: champion
Personas missing: economic buyer, HR admin, IT security, finance
Most valuable persona to add: economic buyer
On-file unengaged: CT-697541, Chief People Officer (economic buyer)
===========================================
SUMMARY
- 11 of 14 deals flagged: 4 single-threaded (Deal-EC3025, Deal-92D97D, Deal-36C33F, Deal-FCBE5B, Deal-F9A08A) — that's 5 actually; recheck below.
Single-threaded (<2 active): Deal-EC3025, Deal-92D97D, Deal-36C33F, Deal-FCBE5B, Deal-F9A08A = 5
Under-threaded (<3 OR single-persona): Deal-50D386, Deal-D0D6B5, Deal-5BFE3B, Deal-885F45, Deal-5408B0, Deal-C6D97A = 6
5 + 6 = 11
- 6 of 11 flagged deals have a matching unengaged contact on file (economic buyer in 5, IT security in 1); 5 have none on file.
- Missing data: amount and stage are not in the provided files for ANY deal — I could not report them or tailor the recommended persona to stage. Recommend you bring in the deal staging/ARR file to fix that.
Note: my "most valuable persona" recommendation defaults to economic buyer since stage data is unavailable and it's the universal missing signature persona. For Deal-885F45 the economic buyer is present, so IT security is the top missing persona there.
Analysis of Alex Franklin's last 10 calls (TT-001 … TT-010).
## 1. What the rep leads with in the first five minutes
In 8 of 10 calls (TT-001, 002, 003, 005, 006, 007, 008, 010) the rep opens with the same customer social-proof story:
> "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." (TT-001)
Two calls open differently: TT-004 opens with "I put together a short agenda — security review first, then pricing," and TT-009 opens with "You asked for straight pricing last time, so let's start there."
## 2. Handling the three most common objections
Counts across the 10 calls: budget-locked 4x (TT-001/003/006/010), revisit-next-quarter 3x (TT-002/005/008), spreadsheet status-quo 3x (TT-004/007/009). Committee approval appears 2x, and no-urgency 1x.
- Budget locked → reframe to self-funding from 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." (TT-001)
- Revisit next quarter → scope a pilot to create internal urgency:
> "Makes sense. What if we scope a 90-day pilot with one department so you have internal data before next quarter's planning?" (TT-002)
- Spreadsheet/status-quo → counter with automation + analytics:
> "Spreadsheets work until they scale — the difference is automation: milestones fire without HR lifting a finger, and you get analytics on who is being recognized." (TT-004)
## 3. Concrete next-step rate
The rep asked to lock a next step in 7 of 10 calls and got a "Yes" in all 7 → 7/7 = 100% conversion when asked; overall 7 of 10 (70%) of the last calls ended with a concrete next step agreed. In the 3 calls without one (TT-004, TT-007, TT-010) the rep did not ask — they deferred ("I'll leave it with you," "Fair enough," "Understood, thanks for the candor").
Arithmetic: 7 agreed ÷ 10 total calls = 70%; asked 7/10 = 70% ask rate; close when asked = 7/7 = 100%.
## 4. Competitors raised by prospects
Two, both raised by prospects:
- Awardco — TT-003: "We're also in late talks with Awardco — their rewards catalog looks bigger than yours."
- Kudos — TT-007: "How are you different from Kudos? Our CEO used them at her last company."
(Workhuman in TT-005 was raised by the rep, not a prospect, so it is excluded.)
## Coaching notes
1. The objections the rep handles well close at 100% — but in 3 of 10 calls (TT-004 committee, TT-007 no-urgency, TT-010 committee) the rep surrendered without proposing any next step, costing every one of those deals. Never leave a call with nothing set: convert "committee / I can't commit / need to think" into a 90-day pilot or a data-share deliverable rather than "I'll leave it with you."
2. The rep opens 8/10 calls with the identical retailer story and closed 2 more leads earlier than the competition was even raised — yet the only prospect-raised competitor answers were generic ("where we win is automation"). Build a sharper, competitor-specific objection script (Awardco's catalog breadth, Kudos' social-recognition positioning) and consider varying the opener to the buyer's own framing, as the TT-004 and TT-009 opens did.
Q3 2026 FORECAST (2026-07-01 to 2026-09-30)
Weighting: COMMIT x 100%, BEST_CASE x 35%, PIPELINE x 0%
Included = close date on/after 2026-07-01 and on/before 2026-09-30.
COMMIT deals inside quarter (7):
11200 + 9000 + 9000 + 6360 + 5400 + 2520 + 1249 = $44,729
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 = $44,729 (n = 7)
BEST_CASE deals inside quarter (24), total $203,565:
38935 + 24000 + 19656 + 16250 + 11116 + 10800 + 10500 + 9890 + 9720 + 9000 + 7200 + 3840 + 3780 + 3600 + 3240 + 3150 + 3120 + 3060 + 2916 + 2760 + 2484 + 2100 + 1920 + 528 = $203,565
BEST_CASE total = $203,565 (n = 24)
PIPELINE deals inside quarter (23): $0 weighted (count zero toward forecast).
Weighted forecast = (1.00 x 44,729) + (0.35 x 203,565)
= 44,729 + 71,252.75
= $115,981.75
Category counts inside quarter: COMMIT 7, BEST_CASE 24, PIPELINE 23 (PIPELINE contributes $0).
Excluded — close date outside Q3 (Oct 1 - Oct 15), 31 deals, $221,875:
43875 + 18000 + 17000 + 13770 + 10800 + 9000 + 9000 + 7920 + 7690 + 7500 + 7200 + 5400 + 5400 + 5400 + 5400 + 5160 + 4800 + 4400 + 4300 + 4000 + 3600 + 3600 + 3600 + 3300 + 2400 + 1800 + 1800 + 1680 + 1600 + 1400 + 1080 = $221,875
Count: 31. Notable exclusions: Deal-D348E1 ($13,770 COMMIT) and 9 BEST_CASE deals; the rest are PIPELINE (Deal-E51FB7 $43,875, Deal-D9A12F $17,000, Deal-B936FE $18,000, etc.).
Top 5 BEST_CASE deals inside quarter by amount:
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 essentially unpopulated (only Deal-C9C286 has an owner, Bryce Harmon), so the forecast cannot be attributed to any rep. Several early-stage deals are tagged COMMIT despite being DS1/DS2 (Deal-A5E80A, Deal-499BF6), which is inconsistent with the DS5-contract norm and would overstate confidence. Amount precision is inconsistent — one deal is a decimal (Deal-42326B, 2480.4) while all others are integers — and the why_buys_chars field uses "0" as a sentinel that is indistinguishable from a real blank, making that column unreliable as-is. Finally, the extract spills past the quarter into mid-October, so any unattended run that missed the date filter would silently misweight 31 deals worth $221,875.
ANALYSIS — Activation hypothesis on the 2023 cohort (n=220, all companies) Signals used: m1_users >= 5 (giver signal), m1_redemptions >= 1 (redemption signal). Retention at 24 months = current_status == 'active'. 2x2 TABLE cell n retained 24-mo retention both signals 47 31 66.0% (31/47) givers-only 49 23 46.9% (23/49) redemption-only 29 9 31.0% ( 9/29) neither 95 38 40.0% (38/95) TOTAL 220 101 Arithmetic (retention rate = active / cell n): both: 31 / 47 = 66.0% givers-only: 23 / 49 = 46.9% redemption-only: 9 / 29 = 31.0% neither: 38 / 95 = 40.0% EXCLUSIONS FROM DENOMINATOR None. All 220 companies in the extract carried both m1_user and m1_redemption values, so every record mapped to exactly one cell (47+49+29+95 = 220). No company was excluded for missing/blank month-1 data. SINGLE SIGNAL WITH THE LARGEST RETENTION LIFT The giver signal (m1_users >= 5). Measured as the marginal gain of having just that one signal vs. neither: Giver signal lift: givers-only vs neither = 46.9% - 40.0% = +6.9 pts Redemption signal lift: redemption-only vs neither = 31.0% - 40.0% = -9.0 pts The redemption signal by itself shows a NEGATIVE association with retention in this sample (-9.0 pts). So the giver/activation signal is not just the larger lift — it is the only one that lifts retention on its own. KEY READ: Both signals (66.0%) beats every single-signal cell by a wide margin (+19.1 pts over givers-only, +35.0 pts over redemption-only, +26.0 pts over neither). The two signals are complementary: givers are the base driver, and adding a successful redemption on top more than doubles the gap. WHAT THIS DOES AND DOES NOT PROVE This is an observational, correlational cohort comparison — it supports, but does not prove, the activation hypothesis. Proves (within this extract): companies showing both momentum signals in their first month are retained at 24 months at a materially higher rate (66.0%) than companies showing only one signal or neither; and the giver signal is the individual signal doing the heavy lifting (+6.9 pts), with early redemption adding a large incremental gain on top of it. The split is not explainable by chance variation of these magnitudes, and it is directionally what the hypothesis predicts. Does NOT prove: causation. There are no controls for confounders — product tier, industry group, geography, starter ARR, or account size at signup are all uncontrolled, and cell sizes are uneven (redemption-only is only n=29, so its -9.0 pt figure is the noisiest). Companies that already have 5+ givers and a redemption in month 1 may simply be larger/healthier accounts that would have retained regardless. Also, the counterintuitive finding that redemption-only (31.0%) trails neither (40.0%) signals that these are raw associations, not causal levers — it should not be read as "redemptions hurt retention." To establish causation you'd need a controlled test (randomized onboarding variation or matched-cohort/)regression with the confounders above held fixed. Data note: m3/m3_gives columns were not used; the test is scoped strictly to month-1 signals as specified. Data file saved at /Users/amaniphipps/plg_company_cohort_2023.csv.
Reconciliation as of 2026-09-05 (all figures $; arithmetic shown; no data invented — no owner field exists in either file, so owners below are functional recommendations based on error type).
TOTALS
Billing ARR (MRR x 12, active subscriptions only) = 604,739.28
(active MRR = 50,394.94; 50,394.94 x 12 = 604,739.28)
Company ARR (sum of hubspot_arr) = 603,581.76
Variance (billing - company) = +1,157.52
Note: if cancelled subscriptions are counted in billing, billing ARR = 617,897.76 (all-sub MRR 51,491.48 x 12) and variance = +14,316.00. I used active-only as the baseline because it makes the status bucket meaningful (below) — the two cancelled subs appear in the company file at full ARR and drive the status bucket either way.
VARIANCE DECOMPOSITION (sums exactly to 1,157.52)
Status mismatch -13,158.48 two subscriptions status=cancelled in billing but carried at full ARR in CRM:
C-0C8323BF (SUB-000E): 0 - 4,905.24 = -4,905.24
C-0DC4FB8C (SUB-000F): 0 - 8,253.24 = -8,253.24
Rounding $0.00 every clean match is an exact 12x multiple; no rounding deltas present.
Missing records +11,952.00 C-21629AA4 (SUB-0004): billed 2,370.77x12 = +28,449.24, no CRM company record
C-0D5BBE3A: CRM record 16,497.24, no billing subscription = -16,497.24
Other (rate/disc) +2,364.00 C-0F7269D7: 2,233.00x12 = 26,796 vs 24,396 = +2,400.00
C-0D66DF9E: 1,932.00x12 = 23,184 vs 23,200 = -16.00
C-14D70CE0: 1,515.00x12 = 18,180 vs 18,200 = -20.00
TOTAL check: -13,158.48 + 0 + 11,952.00 + 2,364.00 = 1,157.52 ✓
MISMATCHED ACCOUNTS + SUGGESTED OWNER (no owner field in the data; functional recommendation)
C-0C8323BF billing $0 / CRM $4,905.24 -> Revenue Ops to mark subscription cancelled in CRM
C-0DC4FB8C billing $0 / CRM $8,253.24 -> Revenue Ops to mark subscription cancelled in CRM
C-21629AA4 billed $28,449.24, no CRM rec -> Sales Ops to create/associate company record
C-0D5BBE3A CRM $16,497.24, no subscription -> Billing Ops to confirm contract/missed invoice
C-0F7269D7 billing $26,796 / CRM $24,396 -> Account Manager + RevOps to validate discount/contract rate
C-0D66DF9E billing $23,184 / CRM $23,200 -> RevOps to align rate (diff $16)
C-14D70CE0 billing $18,180 / CRM $18,200 -> RevOps to align rate (diff $20)
TERM-AGREEMENT VIOLATIONS (rule: term != 12 requires cf_agreement_end_date populated)
SUB-0002 / C-1794A52C term 24 months, cf_agreement_end_date EMPTY VIOLATION
SUB-0019 / C-22170CA1 term 36 months, cf_agreement_end_date EMPTY VIOLATION
Compliant for reference: SUB-000C / C-0DB48281 (24 mo) and SUB-001A / C-0FC4DBB8 (36 mo) both carry 2027-11-30.
Gaps flagged: no billing-start/end, currency, or owner data was provided, so I could not verify effective dates or assign named owners — the owners above are role-based recommendations only.
KVM report — Aug-2026 vs Jul-2026 (n=30 accounts each month; simple mean of the 30 account-level values). | 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 | Arithmetic (pulse): (0.5086 − 0.6006)/0.6006 = −15.31%. All other KVMs moved <0.1% relative. Largest relative move: pulse check engagement at −15.31%, driven by the enterprise size_band. Enterprise pulse fell 0.5500 → 0.2743 (−50.13%); every enterprise account dropped (e.g. C-0B2895EF 0.5619→0.2864, C-0F6C0F34 0.5357→0.2662, C-0BA71F12 0.5588→0.2723). By contrast smb fell just −0.22% (0.6588→0.6573) and mid_market rose +0.21% (0.5930→0.5942). The plan_tier column is uniform (all values tier_three), so it cannot be the driver — the size_band (enterprise) is. The 1:1, giving-rate, and redemption KVMs are effectively flat month-over-month.
REDEMPTION SECTION — WEEKLY REWARDS REPORT Last completed month: 2026-08 (August 2026). The full data set spans 2026-01-01 through 2026-08-31, so all 378 redemption records fall within the reporting window (through the last completed month). No records were excluded. Headline metrics (YTD through Aug 2026) - Redemptions: 378 - Total spend: $27,846.00 - Unique redeemers: 235 - Redemptions per redeemer:1.61 (= 378 redemptions / 235 unique redeemers) Provider mix (share of spend, sums to 100%) Provider Spend % of Spend Redemptions ----------- ----------- ---------- ----------- custom $10,873.00 39.0% 37 Tremendous $8,505.00 30.5% 192 Snappy $5,238.00 18.8% 59 TangoCard $3,230.00 11.6% 90 ----------- ----------- ---------- ----------- TOTAL $27,846.00 100.0% 378 Arithmetic check on provider shares: 39.0 + 30.5 + 18.8 + 11.6 = 100.0%. Top 5 countries by redemption count 1. US — 244 2. CA — 24 3. AU — 21 4. GB — 17 5. NL — 17 Note on data completeness: all requested fields were present for every record — no missing dates, providers, amounts, or countries. The four providers observed are custom, Tremendous, Snappy, and TangoCard. Spend and counts are as shown in redemptions_ytd.csv; no figures were assumed.
Churn-save qualification analysis (snapshot 2026-09-05). All numbers and aliases come directly from the two CSV files provided. RULE SET EVALUATED R1 health_score < 60 (at risk) R2 churn_save_eligible_amount > 0 R3 renewal_date within 120 days of 2026-09-05 (i.e. on/before 2027-01-03) Arithmetic for the 120-day window: Sep 5 +25d = Sep 30, +31d = Oct 31, +30d = Nov 30, +31d = Dec 31, +3d = Jan 3, 2027. Cutoff = 2027-01-03. ========================================================== QUALIFYING ACCOUNTS (R1 + R2 + R3 all met) — 8 accounts ========================================================== Per-account amount at stake = churn_save_eligible_amount in file. 1) C-0F6C0F34 $49,707.00 rn 2026-10-03 health 51 Play: EXECUTIVE TOUCH Signal: champion_active = false despite usage_trend_3m = growing and 308/395 seats used — engaged product, no active champion to anchor the renewal; escalate to leadership. 2) C-0B827671 $25,365.00 rn 2026-11-14 health 56 Play: USAGE REVIVAL Signal: usage_trend_3m = declining (only 113/202 seats used); champion active but traction is slipping. 3) C-0B360C78 $35,748.00 rn 2026-10-28 health 57 Play: COMMERCIAL CONCESSION Signal: growing usage + active champion (246/327 seats) — no usage or champion risk; health 57 is borderline only, so price/renewal is the residual lever. 4) C-0B0F1BAB $5,494.00 rn 2026-09-23 health 38 Play: EXECUTIVE TOUCH Signal: champion_active = false on a flat-trend account at the lowest health score in the set (38); no champion to re-engage, needs exec call. 5) C-0CA21961 $16,829.00 rn 2026-12-28 health 58 Play: USAGE REVIVAL Signal: seats 325 / seats_used 84 = 26% utilization — severe under-adoption even though a champion is flagged active. 6) C-0E9C27D1 $41,235.00 rn 2026-09-24 health 39 Play: COMMERCIAL CONCESSION Signal: renewal is imminent (2026-09-24, within days of snapshot) on flat usage with an active champion; time-pressured commercial close. 7) C-0CEF69FD $32,621.00 rn 2026-11-21 health 53 Play: EXECUTIVE TOUCH Signal: champion_active = false on a growing-trend account (97/136 seats used) — product in use, no champion to carry the renewal. 8) C-0D3278C7 $17,602.00 rn 2026-11-12 health 54 Play: USAGE REVIVAL Signal: usage_trend_3m = declining with low adoption (126/380 seats used = 33%); both signals point to usage, not commercial. PLAY SUMMARY Usage revival : C-0B827671, C-0CA21961, C-0D3278C7 = 3 accounts Executive touch: C-0F6C0F34, C-0B0F1BAB, C-0CEF69FD = 3 accounts Commercial concession: C-0B360C78, C-0E9C27D1 = 2 accounts TOTAL AMOUNT AT STAKE 49,707 + 25,365 + 35,748 + 5,494 + 16,829 + 41,235 + 32,621 + 17,602 = $224,601.00 across the 8 qualifying accounts. ========================================================== AT RISK BUT NOT QUALIFIED — 7 accounts ========================================================== C-0BC71BDD health 55 rn 2026-10-27 Fails R2: churn_save_eligible_amount = 0.00. C-0F6694C3 health 43 rn 2027-03-21 Fails R2: amount = 0.00. Also fails R3: renewal 2027-03-21 is beyond the 2027-01-03 cutoff. C-0BE96399 health 54 rn 2026-10-29 Fails R2: churn_save_eligible_amount = 0.00. C-0F876796 health 47 rn 2027-02-06 (amount = 19,958.00) Fails R3 only: renewal 2027-02-06 is beyond the 2027-01-03 cutoff, despite having an eligible amount on file. C-0FCCD2DF health 43 rn 2027-04-23 Fails R2: amount = 0.00. Also fails R3: renewal 2027-04-23 > cutoff. C-10A56B0F health 54 rn 2026-12-12 Fails R2: churn_save_eligible_amount = 0.00. C-0BA71F12 health 52 rn 2027-04-11 (amount = 6,824.00) Fails R3 only: renewal 2027-04-11 is beyond the 2027-01-03 cutoff, despite having an eligible amount on file. Note: No active-champion or engagement data was given to drive the play assignments — that mapping is inferred from the three signals present in the file (usage_trend_3m, seats_used/seats utilization, champion_active). Everything else above is read directly from the CSVs with no invented facts.
EXPANSION KIT — C-0DDFC9A7 Account alias cited as given. All figures derived only from the provided files. SEAT COVERAGE - Licensed seats: 150 over headcount 400 => 150/400 = 37.5% coverage. USAGE HEALTH (two lines) - Active users climbed every month, 88 (Mar) -> 126 (Aug), a +38 gain / ~43% over six months; the trajectory is steady and compounding, not one-off. - Active users sit at 126/150 licensed = 84% seat utilization, so the seats you've paid for are well-used and adoption is running above the coverage you've sold — demand is outpacing licensed capacity. HEADROOM - Per-seat rate: $9,000 ARR / 150 seats = $60/seat. - Seat headroom vs headcount: 400 - 150 = 250 seats. - ARR headroom at current rate: 250 x $60 = $15,000. (Note: headroom is vs full headcount; most teams license a subset. 150/400 coverage is low enough that even partial expansion is meaningful — e.g. +50 seats = $3,000.) WHO REPLIED / CAN THEY BUY - Maria S. (People Operations Coordinator) replied. She explicitly IS NOT the purchasing decision-maker — budget and seat expansion sit with Dana R. - Maria cannot buy, but she is your internal champion: happy to make an introduction and notes Dana has been asking about usage numbers. RIGHT BUYER - Dana R., VP People — owns budget and seat expansion. Last engaged 2026-05-18 (still warm, ~3.5 months). She is also mid-conversation on usage, which your reply data arms her for. REPLY TO MARIA (<150 words) — asks her to connect you to Dana, no push, cites one usage fact Subject: RE: Growing your team's recognition program Hi Maria, Really glad to hear the team's loving Bonusly — and your numbers back that up. Active users have climbed every month, from 88 in March to 126 in August, and the feed is clearly staying busy. Thanks for offering the intro to Dana. That would be ideal, and timing works well since she's been looking at usage. I can show her how your 126 active users compare to your 150 licensed seats, and simply make room for more of your team when it makes sense — no pressure, just a conversation. Easiest path: either loop her into this thread or give us five minutes on a call. Either way, appreciate you bridging the connection. Best, Cole (~120 words)
PREP — MID-ONBOARDING CALL, ACCOUNT C-0D284E42 Date context: signup 2026-08-11, so ~4 weeks in. Call is the mid-onboarding checkpoint. COMPLETE (field-backed) - Slack integration connected — integration_slack = 2026-08-12 - Allowance set — allowance_set = 2026-08-13 - Admins added — admins_added = 2 - First recognition given — first_recognition_at = 2026-08-15 14:22 NOT COMPLETE (field is empty / not present) - HRIS integration — integration_hris is BLANK. Nothing in the record shows it was connected. Do not mark complete. - First redemption — first_redemption_at is BLANK. As of the latest data (09-04) there is NO redemption event on record. First recognition was 08-15, so ~20 days elapsed with zero redemptions recorded. EARLY ENGAGEMENT SIGNALS (from onboarding_usage.csv, active_givers) Arithmetic: - Start of usage (08-11): 3 active givers → latest (09-04): 15. Growth 15/3 = 5x (+12 net givers over the window). - First time at double digits: 08-26 (11). Prior max was 9 (08-21, 08-23, 08-24, 08-25). - Sustained high end: ≥11 every day 08-26 onward except small dips; peaked at 15 on 09-03 and 09-04 (current ceiling). - Growth is not linear — it steps: 3-4 (wk 1) → 7-9 (wk 2) → 9-11 (wk 3) → 13-15 (wk 4). Read: real adoption trend upward and the account is still climbing (last two days are the all-time high), so momentum is healthy. Caveat: active_givers is a giver count, not total headcount, so I cannot infer team size or % of team engaged — that field is not in the data. I also will not call out day-of-week dips (e.g. 08-16, 08-22, 08-31) as a pattern: the drops don't fall on a consistent weekday, so I can't support a weekly-seasonality claim from this data. THREE THINGS TO COVER ON THE CALL 1. HRIS integration is the gap. Slack is live and allowance/admins/recognition are in, but the HRIS row is empty. Establish who owns it, what's blocking, and a target date — this is the last core setup step not done. 2. No redemption yet (~20 days since first recognition). Recognition is happening, but the incentive loop is unproven until someone redeems. Walk the admin through the recipient/store experience, surface the redemption moment, and remove any friction. Track first_redemption_at for the next check-in. 3. Reinforce and expand the pattern. 3 → 15 active givers (5x) is the story to celebrate, and it's still at an all-time high — but with 2 admins on the account, check whether admin coverage and recognition guidance scale with the team, and whether the flat spots (dips in the teens/givers) represent a real plateau to break through or just normal variance. Set the next giver-count target and a redemption goal before you close. Not covered (missing data): team size/headcount, any spend/ROI fields, engagement per-giver, or redemption counts — none are in these two files, so I'm not asserting anything on them.
RENEWAL RISK BRIEF — 90-day window (2026-09-06 → 2026-12-05) As of 2026-09-06. All 20 accounts renew within the 90-day window. SOURCE DECISION Rule applied: multi-year contracts are known to be WRONG in ChurnZero. For the 5 multi-year accounts in chargebee_terms (is_multi_year=true), I use the Chargebee term date. For the 15 twelve-month contracts, ChurnZero and Chargebee dates match exactly, so I use that common date (synonyms). DISAGREEMENTS FLAGGED (5) — all are the multi-year accounts, all resolved toward Chargebee: · C-0BCDB8C2: CZ 2027-09-18 vs CB 2026-09-18 → CZ off by exactly one year (multi-year bug). Use 2026-09-18. · C-0BBE3E60: CZ 2027-09-26 vs CB 2026-09-26 → CZ off by one year. Use 2026-09-26. · C-0B7D2C30: CZ 2026-09-10 vs CB 2026-09-15 → CZ shows spurious 9/10 stub. Use 2026-09-15. · C-0D2AB865: CZ 2026-09-10 vs CB 2026-09-22 → same spurious 9/10 stub. Use 2026-09-22. · C-0F5D2323: CZ 2026-09-10 vs CB 2026-09-29 → same. Use 2026-09-29. (15 twelve-month accounts: CZ and CB agree on every date — no disagreement. List: C-0EC6999D, C-0B20DB64, C-0BBC4E7A, C-0FD551AB, C-0F9F8F13, C-0BC34584, C-0B7A7546, C-0B369871, C-0B144C78, C-0FC4DBB8, C-0D5BBE3A, C-0FB9D5AF, C-0B344485, C-0CB2C1B4, C-22170CA1.) PER-ACCOUNT (util = seats_used/seats; trend = active_users May-26 → Aug-26, %) --- HIGH RISK (declining usage, near-term renewal) --- C-0B7D2C30 | Dana Mercer | $65,901 | 2026-09-15 | util 57.6% (274/476) | -21.5% (107→84) | HIGH — 12 straight monthly declines in active users and under-60% seat utilization, renewing in 9 days. C-0BCDB8C2 | Cole Ingram | $54,427 | 2026-09-18 | 54.7% (232/424) | -19.1% (136→110) | HIGH — sustained decline to 110 active users on a 424-seat base, renews 12 days out. C-0D2AB865 | Elena Sinclair | $38,022 | 2026-09-22 | 61.4% (250/407) | -20.4% (137→109) | HIGH — continuous erosion (199→109) with only 61% seats engaged before a 9/22 renewal. C-0BBE3E60 | Dana Mercer | $30,993 | 2026-09-26 | 64.9% (74/114) | -19.5% (41→33) | HIGH — shrinking small base (63→33) signals contraction ahead of 9/26. C-0F5D2323 | Cole Ingram | $90,647 | 2026-09-29 | 28.5% (111/390) | -10.0% (20→18) | HIGH — largest ARR et risk; shockingly low 28.5% utilization on 390 seats (111 used), renewing 9/29. --- MEDIUM RISK (stable usage but low-monitor signals) --- C-0EC6999D | Elena Sinclair | $79,419 | 2026-10-03 | 27.7% (31/112) | +7.1% (14→15) | MED — utilization critically low (27.7%) despite $79K ARR; usage flat, needs utilization remediation. C-0B20DB64 | Dana Mercer | $21,770 | 2026-10-07 | 56.6% (214/378) | -0.7% (~294 const.) | MED — stable but only ~57% of seats engaged on a 378-seat contract. C-0BBC4E7A | Cole Ingram | $56,374 | 2026-10-10 | 67.7% (228/337) | -2.1% (142→139) | MED — flat usage and 68% utilization leaves shrink/expand risk at a near-term date. C-0FD551AB | Elena Sinclair | $48,815 | 2026-10-14 | 55.9% (210/376) | +0.8% (125→126) | MED — stable usage but only 56% seat utilization on 376 seats. C-0F9F8F13 | Dana Mercer | $46,230 | 2026-10-18 | 56.5% (199/352) | 0% (182→182) | MED — flat usage, ~57% utilization; no growth signal. --- LOW RISK (growing/stable, high utilization) --- C-0BC34584 | Cole Ingram | $16,740 | 2026-10-22 | 66.2% (327/494) | +2.9% (103→106) | LOW — stable, low-ARR, moderate utilization. C-0B7A7546 | Elena Sinclair | $35,062 | 2026-10-25 | 88.8% (182/205) | +3.3% (61→63) | LOW — high seat utilization, usage rising. C-0B369871 | Dana Mercer | $85,128 | 2026-10-29 | 75.1% (317/422) | +4.4% (319→333) | LOW — 12-month usage growth, healthy utilization; strongest Dana Mercer account. C-0B144C78 | Cole Ingram | $30,899 | 2026-11-02 | 75.4% (169/224) | +7.1% (99→106) | LOW — rising usage, 75% utilization. C-0FC4DBB8 | Elena Sinclair | $94,732 | 2026-11-05 | 76.7% (356/464) | +4.3% (185→193) | LOW — steady growth, largest ARR in portfolio and healthy. C-0D5BBE3A | Dana Mercer | $39,740 | 2026-11-09 | 83.3% (85/102) | +4.6% (87→91) | LOW — growing usage, 83% utilization. C-0FB9D5AF | Cole Ingram | $63,158 | 2026-11-13 | 72.4% (144/199) | +4.8% (168→176) | LOW — rising usage, 72% utilization. C-0B344485 | Elena Sinclair | $64,384 | 2026-11-16 | 78.0% (224/287) | +3.8% (235→244) | LOW — growth trend, 78% utilization. C-0CB2C1B4 | Dana Mercer | $40,628 | 2026-11-20 | 81.6% (386/473) | -2.0% (50→49) | LOW — high utilization, flat usage. C-22170CA1 | Cole Ingram | $45,646 | 2026-11-24 | 85.4% (251/294) | +2.1% (143→146) | LOW — high utilization, slight growth. ARITHMETIC / CONSOLIDATION Total ARR renewing (all 20) = 65,901+54,427+38,022+30,993+90,647+79,419+21,770+56,374+48,815 +46,230+16,740+35,062+85,128+30,899+94,732+39,740+63,158+64,384+40,628+45,646 = $1,048,715 ARR at risk (HIGH + MEDIUM, 10 accounts): HIGH = 65,901+54,427+38,022+30,993+90,647 = $279,990 MEDIUM = 79,419+21,770+56,374+48,815+46,230 = $248,608 HIGH + MEDIUM = $528,598 (50.4% of renewing ARR is HIGH or MEDIUM) HIGH-only (immediate action) = $279,990 BOTTOM LINE $1,048,715 renews in the next 90 days. $279,990 (27%) is HIGH risk and $528,598 (50%) is at least MEDIUM risk — concentrated in the five 9/15–9/29 declining accounts plus five fluid-utilization accounts. No revenue-op degradation data beyond seat/utilization is present (no health-score, patch, or sentiment fields in the files provided), so risk is assessed on renewal proximity, seat utilization, and 3-month usage trend only. DATA NOTE: for some accounts the usage active_users differ from seats_used (e.g., C-0B20DB64 active_users ≈294 vs seats_used 214), so utilization and usage trend come from two separate sources; I did not reconcile them since no mapping key was provided.
Synthesized all 80 tickets by reading body text (existing tags ignored — they were unreliable: e.g. billing-tagged tickets were actually points/HRIS issues). Cleaned into 5 clusters below.
Method note: ARR affected = sum of ARR across DISTINCT accounts in the cluster (not ticket count), so repeat tickets on the same account don't inflate exposure. Ranked by ARR exposure, not volume.
VERIFICATION OF COVERAGE: 20 + 14 + 18 + 12 + 16 = 80 tickets. All 80 accounted for, no orphans.
================================================
RANK 1 — HRIS provisioning / new-hire sync
Tickets: 12 (12/80 = 15.0%)
Distinct accts: 3 — C-0B2213A9, C-0F6C0F34, C-0DDFC9A7
ARR affected: $114,000
C-0B2213A9 36,000 + C-0F6C0F34 30,000 + C-0DDFC9A7 48,000
Ticket ids: IC-460059, IC-460062
Broad pattern: YES — 3 independent accounts, recurring June-Aug
One-liner: HRIS sync/provisioning is silently dropping new hires (logs show no errors); fix the pipeline before high-ARR accounts start losing onboarding trust.
================================================
RANK 2 — Redemption / checkout / gift-card fulfillment
Tickets: 18 (18/80 = 22.5%)
Distinct accts: 7 — C-0CEF69FD, C-0B827671, C-0FCCD2DF, C-0F876796, C-14264ABD, C-0D9CA315, C-0B0F1BAB
ARR affected: $68,800
8900+10700+9600+8700+11000+9600+10300
Ticket ids: IC-460025, IC-460024
Broad pattern: YES — 7 accounts, as many as June-Aug
One-liner: Redeem/checkout flow errors out while points are still deducted and gift cards never arrive — fix fulfillment consistency and credit affected members.
================================================
RANK 3 — (single-account noise) Billing / seat-count & tier errors
Tickets: 16 (16/80 = 20.0%)
Distinct accts: 1 — C-0E9C27D1
ARR affected: $52,000 (all on C-0E9C27D1)
Ticket ids: IC-460071, IC-460069
Broad pattern: NO — single account. Flagged because 52K is your largest exposed account and repeated wrong-tier/seat-count invoices are a churn and credits risk.
One-liner: Handle as a named-account escalation, not systemic: reconcile C-0E9C27D1's seat count + tier pricing proactively before renewal, not via tickets.
================================================
RANK 4 — Recognition points not posting / not arriving
Tickets: 20 (20/80 = 25.0%) <- highest VOLUME
Distinct accts: 9 — C-0D3278C7, C-0BF20542, C-0D0B047C, C-0BE96399, C-0D284E42, C-0D6CC8E3, C-21FEBCBB, C-0DD0626C, C-0B2895EF
ARR affected: $31,100
3500+4500+4500+2700+3400+4200+2900+2500+2900
Ticket ids: IC-460004, IC-460016
Broad pattern: YES — 9 accounts, most accounts in dataset; clustered after weekends
One-liner: Recognition points silently vanish after weekends (delivered but never credited) — likely a batch/ledger failure; touches the most accounts even though ARR per account is low.
================================================
RANK 5 — Slack integration (sync / toggle / re-auth / slash command)
Tickets: 14 (14/80 = 17.5%)
Distinct accts: 4 — C-0B843542, C-10A56B0F, C-0BA71F12, C-8C2E8F00
ARR affected: $18,900
4400+5400+3900+5200
Ticket ids: IC-460041, IC-460047
Broad pattern: YES — 4 accounts, persistent June-Aug
One-liner: Slack app is unstable (sync toggle resets, re-auth won't stick, slash command errors) — fix connection persistence and reduce repeated re-auth requests.
================================================
KEY INSIGHT
The two highest-ARR broad themes (HRIS $114K, Redemption $68.8K) are the real revenue-protection priorities. The two highest-VOLUME themes (Points 20, Slack 14) span the most accounts but carry the least ARR exposure — fix them for account-health/support load, not for revenue risk. The $52K billing cluster is single-account noise with outsized concentrated risk, so it needs a relationship fix, not a code fix.
Data caveat: no SLA/response/status fields were provided, so "recommendation" is derived only from ticket text; where a root cause is unproven (HRIS logs, redemption double-deduction) it is stated as a hypothesis from the wording, not a verified fact.
Prospect C-82AF3719: Technology | Mid-Market | employee_recognition | NA-West Restricted to customers with has_case_study = true (8 total), I scored each on the number of exact field matches against the prospect across the four similarity dimensions (industry, size_band, use_case, region). Case-study customer matches: - C-FEFCC020 (Education/Enterprise/wellness/NA-East) -> 0/4 - C-11209339 (Manufacturing/SMB/peer_milestones/APAC) -> 0/4 - C-9D69D147 (FinSvc/Mid-Market/retention/NA-West) -> 2/4 (size_band ✓, region ✓) - C-11C31562 (Manufacturing/Mid-Market/employee_recognition/NA-West) -> 3/4 - C-0CE315B2 (Education/SMB/wellness/EMEA) -> 0/4 - C-64171065 (Technology/Mid-Market/employee_recognition/NA-East) -> 3/4 - C-A13C193D (Technology/Mid-Market/retention/NA-West) -> 3/4 - C-CD4829A7 (Technology/Mid-Market/retention/NA-East) -> 2/4 (industry ✓, size_band ✓) Top tier is a three-way tie at 3/4. I ordered them by which field is missing, weighted toward same use-case (functional proof) and same industry for social proof: 1. C-64171065 — 3/4 matches Matches: industry (Technology) ✓, size_band (Mid-Market) ✓, use_case (employee_recognition) ✓ Differs: region (NA-East vs NA-West) Strongest: only candidate sharing BOTH the exact use case and the exact industry. 2. C-11C31562 — 3/4 matches Matches: size_band (Mid-Market) ✓, use_case (employee_recognition) ✓, region (NA-West) ✓ Differs: industry (Manufacturing vs Technology) Shares the exact use case; same region and size band. 3. C-A13C193D — 3/4 matches Matches: industry (Technology) ✓, size_band (Mid-Market) ✓, region (NA-West) ✓ Differs: use_case (retention vs employee_recognition) Same industry/size/region but adjacent use case, so ranked behind the two same-use-case peers. Next tier (2/4) excluded: C-9D69D147 and C-CD4829A7. All remaining case-study customers (C-FEFCC020, C-11209339, C-0CE315B2) match on zero dimensions and were excluded. Recommended social-proof set: C-64171065, C-11C31562, C-A13C193D. No billing data or contact names included.
CHANNEL PERFORMANCE — TRAILING 6 MONTHS (Mar–Aug 2026) Spend pulled from channel_spend.csv (6 months each). Contact-level SQM/SQO/pipeline from contacts_first_touch.csv. PAID CHANNELS ------------- paid_search (spend $6,000 x6 = $36,000) SQMs: 40 SQOs: 18 cost/SQM: 36,000 / 40 = $900 cost/SQO: 36,000 / 18 = $2,000 SQM->SQO rate: 18/40 = 45.0% pipeline: $720,000 ($40,000 x18 SQOs) pipeline per dollar: 720,000 / 36,000 = $20.00 linkedin_ads (spend $4,000 x6 = $24,000) SQMs: 25 SQOs: 8 cost/SQM: 24,000 / 25 = $960 cost/SQO: 24,000 / 8 = $3,000 SQM->SQO rate: 8/25 = 32.0% pipeline: $96,000 ($12,000 x8 SQOs) pipeline per dollar: 96,000 / 24,000 = $4.00 paid_social (spend $3,000 x6 = $18,000) [FLAGGED] SQMs: 0 -> cost/SQM UNDEFINED (spend with zero SQMs), not zero SQOs: 0 -> cost/SQO UNDEFINED SQM->SQO rate: UNDEFINED (no SQMs) pipeline: $0 (no SQOs produced); pipeline per dollar: UNDEFINED Interpretation: $18,000 spent with zero pipeline attribution = tracking gap, not a performant zero. webinars (spend $1,500 x6 = $9,000) SQMs: 12 SQOs: 5 cost/SQM: 9,000 / 12 = $750 cost/SQO: 9,000 / 5 = $1,800 SQM->SQO rate: 5/12 = 41.7% pipeline: $60,000 ($12,000 x5 SQOs) pipeline per dollar: 60,000 / 9,000 = $6.67 ORGANIC CHANNELS (volume = SQMs; no spend data supplied) ------------- organic_search: volume 30, SQOs 10, SQO rate 10/30 = 33.3%, pipeline $90,000 referral: volume 15, SQOs 6, SQO rate 6/15 = 40.0%, pipeline $48,000 Note: organic has no spend in channel_spend.csv, so cost metrics and pipeline-per-dollar are not computable (data missing — stated explicitly, not imputed). FLAGS — SQO date precedes SQM date (suspicious/backdated) ------------- CT-000044 linkedin_ads sqm 2026-07-23 sqo 2026-07-18 ($12,000) CT-000041 linkedin_ads sqm 2026-06-14 sqo 2026-06-09 ($12,000) Both are linkedin_ads and both are $12,000 deals where opportunity close predates qualification. Worth an audit; if the first-touch dates are misentered they'd shave linkedin_ads' SQO count and its pipeline. REALLOCATION RECOMMENDATION ------------- paid_search is the clear winner: $20 pipeline per dollar vs $6.67 (webinars) and $4.00 (linkedin_ads), with the best SQM->SQO rate (45%). Reallocate spend from linkedin_ads (weakest efficiency and it carries both date-flag anomalies) and from paid_social (no attributable pipeline at all) toward paid_search. Reprioritize: paid_search > webinars > linkedin_ads > paid_social. Also fix the paid_social tracking gap before any reinvestment there. CONFIDENCE: MEDIUM. Sample sizes are small for the efficiency ratios — paid_search rests on only 18 SQOs, webinars on 5, linkedin_ads on 8. The linkedin_ads conclusions are further undermined by the two SQO-before-SQM anomalies. And no spend/cost data exists for the organic channels, so ROI can't be compared against them. The paid_search-vs-rest ranking is directionally safe; the exact reallocation magnitude is not.
# Battlecard: Rivally (updated 2026-09-06) ## One-line positioning Points-based recognition platform targeting mid-market, expanding hard into EU enterprise with data residency, multi-language support, and local presence. (S02, S04, S12, S15) - Points-based recognition: S02 - Serves mid-market: S04 (mid-market reviewer) - EU enterprise strength / multi-language: S12 - EU data residency + Dublin office: S15 ## Pricing (source + date; newest wins) - CURRENT LIST: $7 per user/month, annual billing required — as of 2026-08-12. (S17 — newest pricing_page source) - Note the conflict: list price was $5/user/mo on 2026-01-20 (S03) and still $5 on 2026-04-01 (S08), but was updated to $7 on 2026-08-12 (S17). Newer source wins → list is $7. So Rivally has raised list price ~40% ($5 → $7) over 2026. - Negotiated deals observed: $6.50/user/mo quoted to a 500-seat prospect, annual term (S13, 2026-06-02); $7/user/mo list with 15% discount offered for a 3-year term (S18, 2026-08-14). - Pulse engagement add-on priced as an add-on, not bundled (S23, 2026-09-01). ## Where they win - EU / EMEA enterprise: multi-language support and strength with distributed EU teams. (S12) - EU data residency is generally available (GA) with a Dublin office and ex-Workday EMEA VP leading expansion. (S15, S11; S05 showed they were pitching residency as early as Feb 2026) - Ease of onboarding: setup under a week, Slack integration works out of the box. (S04) - Engagement: users like the recognition feed. (S02, S16) - Support responsiveness: praised at under 4 hours. (S22) - Microsoft Teams app v2 in public preview. (S19) ## Where we win - Analytics depth: an 800-seat prospect picked Bonusly over Rivally expressly citing analytics depth. (S25) - Rivally's analytics/reporting are the weak spot: limited analytics (S02), basic reporting dashboards (S07), CSV-only exports (make migration off hard) (S20). - Admin tooling lags: lacks SCIM provisioning, manual user management painful for enterprise (S10); admin console lacks bulk recognition editing (S24); admin tooling lags peers (S16). - EMEA catalog is thinner than US (recognition/rewards catalog). (S14) ## Objections & responses - "Rivally has EU data residency, you don't." → They do have EU residency GA (S15), but our edge is analytics depth; an 800-seat EU-bound prospect chose Bonusly for that. (S25) - "Rivally is cheaper / discounting." → Rivally list actually rose to $7/user/mo (S17); discounts observed required multi-year terms (3-yr for 15%) (S18). Price at volume is comparable; the delta is admin tooling and reporting. (S24, S20) - "Rivally supports Slack/Teams out of the box." → True (S04, S19), but flag admin tooling deficits that hurt at scale: no SCIM (S10), no bulk recognition editing (S24). ## Recent changes (with dates) - 2026-08-12: List price raised $5 → $7/user/mo, annual billing. (S17) - 2026-08-20: Microsoft Teams app v2 public preview. (S19) - 2026-09-01: Pulse add-on exits beta, sold as separate add-on. (S23) - 2026-07-01: Dublin office opened, EU data residency GA. (S15) - 2026-05-09: Hired ex-Workday VP EMEA for European expansion. (S11) - 2026-03-05: Launched "Rivally Pulse" survey add-on. (S06) ## Our 12-month win/loss vs Rivally (2026-09-06 review window: 2025-09 → 2026-08) Total 20 deals vs Rivally: 13 wins, 7 losses → 65.0% win rate (13/20). | Month | W | L | Deals | |--------|---|---|-------| | 2025-09| 1 | 1 | 072E31(W), 7767F5(L) | | 2025-10| 2 | 0 | A9FD43, F65C8F | | 2025-11| 1 | 1 | 7AA785(W), D263E0(L) | | 2025-12| 1 | 1 | 44C524(W), 935746(L) | | 2026-01| 2 | 0 | 0D0CD6, E46EAB | | 2026-02| 2 | 0 | D5B790, 1D2392 | | 2026-03| 1 | 1 | 5C636E(W), 9066A6(L) | | 2026-04| 0 | 2 | 5645A5, 72A02F | | 2026-05| 0 | 1 | C6FFAA | | 2026-06| 1 | 0 | 67BE14 | | 2026-07| 1 | 0 | 1B6969 | | 2026-08| 1 | 0 | F03E7B | Recent trend: last 3 months (Jun–Aug 2026) we are 3W–0L (100%); the losses cluster in Apr–May 2026 (0W–3L). Our Apr–May dip is the main watch item, not Rivally. ## Old-card items: re-sourced or unverified - "Points-based recognition for mid-market" → Sourced: points-based (S02), mid-market (S04). CONFIRMED. - "Rivally lacks a Slack integration" → CONTRADICTED. S04 (2026-02-02) confirms the Slack integration works out of the box. As of that date this claim is false; strike it. - "Starts at $5/user/mo, annual (as of 2026-01)" → Superseded. See pricing above; current list is $7 (S17). - "Strong in EU enterprise with multi-language support" → CONFIRMED (S12). - "Rivally was acquired by WorkHuman in 2025" → UNVERIFIED. No snippet supports this; no acquisition evidence in the data. Treat as unverified. ## Excluded (rep opinions, not facts about Rivally) - S09 (Bryce Harmon: UI "clunky") — rep opinion, not verified against the product. - S21 (Elena Sinclair: Rivally discounting aggressively) — rep opinion, not confirmed; exclude from pricing conclusions. Missing data called out: no source for the old card's WorkHuman acquisition claim, and no primary-verified product/UI evidence — those claims are flagged accordingly above.
RATES (aggregated across all 3 steps, sent = sum): New Logo Nurture — sent 1386, open 35.4% (490/1386), reply 6.5% (90/1386), meeting 1.9% (27/1386). Weakest step: 3 (reply 4.2%, 18/428; open decays 42→28%). Expansion Nurture — sent 875, open 64.6% (565/875), reply 6.7% (59/875), meeting 1.4% (12/875). Weakest step: 3 (reply 4.4%, 12/275). Cold Outbound – HR Leaders — sent 1785, open 30.5% (545/1785), reply 0.45% (8/1785), meeting 0.0% (0/1785). Weakest step: 3 (0.17%, 1/590). Cold Outbound – People Ops — sent 1163, open 29.2% (340/1163), reply 2.5% (29/1163), meeting 0.5% (6/1163). Weakest step: 3 (1.6%, 6/377). TRACKING ERROR — Expansion Nurture step 2 reports 340 opened on 300 sent (113.3%). Opened cannot exceed sent; opens are double-counted (likely pixel fires/multi-device). Its 64.6% open rate is unreliable until deduped. AUDIENCE OVERLAP — 23 contacts sit in 2+ sequences. 21 are in BOTH Cold Outbound – HR Leaders AND Cold Outbound – People Ops (e.g. CT-000849, CT-001255, CT-001105, CT-001890, CT-001033). Two sit in both Expansion and New Logo Nurture (e.g. CT-000301). Those prospects receive two stacked sequences — inflating send counts and risking burnout. FAILURE MODE UNDER 2% REPLY — Cold Outbound – HR Leaders (0.45%). It opens fine (30.5%), so deliverability isn't the issue; people read and ignore = messaging/offer fails to resonate with that title (no personalization hook, wrong value prop). Zero meetings confirms the CTA isn't landing. People Ops (2.5%) is just above the line and healthy by comparison. ONE CHANGE PER WEAK SEQ: - New Logo: rebuild step 3 — replace the generic follow-up with a value-add (case study + explicit meeting ask). - Expansion: dedupe opens per recipient to fix the corrupted step-2 count. - HR Leaders: rewrite lead line + offer around a people metric (retention/turnover) and test a different CTA. - People Ops: remove the 21 HR-Leaders-overlapped contacts so no one gets both. FIX FIRST: Cold Outbound – HR Leaders. 0.45% reply and 0 meetings on the largest send (1785) is the biggest revenue leak; fix messaging before scaling. (Correct the Expansion tracking error in parallel — no rates are trustworthy until it's fixed.)
Weekly Marketing Goals Update — Q3-2026 Days elapsed: 66 / 92 = 71.7% of the quarter Run-rate benchmark (on-pace value) = target × 0.7174 for each higher_better metric. Delta = actual − target. --- Volumes (higher_better) --- SQMs QTD actual : 230 Target : 300 Delta : -70 (= 230 − 300) On-pace val : 300 × 0.7174 = 215.2 → 230 > 215.2 PACE: AHEAD (above pro-rata by ~15; still below full-qtr target) SQOs QTD actual : 84 Target : 120 Delta : -36 (= 84 − 120) On-pace val : 120 × 0.7174 = 86.1 → 84 < 86.1 PACE: BEHIND DS2s QTD actual : 40 Target : 75 Delta : -35 (= 40 − 75) On-pace val : 75 × 0.7174 = 53.8 → 40 < 53.8 PACE: BEHIND Same-quarter closes QTD actual : 10 Target : 20 Delta : -10 (= 10 − 20) On-pace val : 20 × 0.7174 = 14.3 → 10 < 14.3 PACE: BEHIND --- Closed-lost MIA rate (lower_better) --- QTD actual : 5 / 25 = 20.0% MIA Target : ≤ 10.0% Delta : +10.0 pts (= 0.20 − 0.10) → worse than target PACE: BEHIND (actual 20% is 2× the 10% ceiling) --- Active pipeline coverage vs target (higher_better) --- QTD actual : $3,000,000 Target : $4,000,000 Delta : -$1,000,000 (= 3.0M − 4.0M) Coverage : 3.0M / 4.0M = 75.0% On-pace val : 4.0M × 0.7174 = $2,869,565 → 3.0M > 2.87M PACE: AHEAD (run-rate coverage 75% vs 71.7% of quarter elapsed) --- What moved this week --- I can't quantify this week's movement. The provided data is QTD cumulative only — there is no prior-week snapshot, so no week-over-week deltas can be computed. Stating them would be inventing facts. What the run-rate picture does show: SQMs and active pipeline are the only two metrics tracking ahead of pro-rata pace this quarter; SQOs, DS2s, same-quarter closes, and MIA rate are all behind where the quarter's elapsed time implies they should be. To report actual weekly movement next time I need at minimum a last-week cumulative snapshot (or weekly granularity) for each metric.
Treat the Q3 forecast with caution: a clean-looking 115,976 is 44,729 in COMMIT plus 71,247 (35% of 203,565 BEST_CASE), but owner is blank on 85 of 86 deals and why-buys are empty on 71, including all 7 COMMIT, so it cannot be attributed or trusted. Pushed close dates and missing reasons to buy make that precision illusory.
Hi there, Reaching out after the pricing recap I sent on August 5 for 150 seats, following the July 28 demo with your VP People and two HR admins. Your team had a strong reaction to the automated milestone awards and the points catalog that day, and they asked for pricing — so I've kept this deal open rather than treating your silence as a no. As the November close date approaches, is the pricing we sent still in range for this year's recognition budget? If so, I'd welcome 20 minutes to walk through the numbers and next steps with the VP People. Best, Alex Franklin Word count: 107. References the prior touch (July 28 People-team demo where pricing was requested, then the Aug 5 recap with 150-seat pricing), makes one clear ask (confirm pricing is in-budget and book 20 minutes with the VP People), and stays professional/low-pressure to match the follow-up thread. All details — 150 seats, VP People, two HR admins, milestone awards, points catalog, Nov 26 close, recognition budget — come from the CSV data only.
Marketing closed the week at 46 SQMs against a 52-target (88% of plan), with webinars carrying 39% of that volume at 18 SQMs. Paid search held steady at $150 cost per SQM, so spend discipline on that channel isn't slipping even as the week fell short of plan by 6 SQMs — the gap to watch is closing the target delta outside webinars. Sales converted 14 SQOs and booked 9 DS2 meetings this week, generating $310,000 in new pipeline. The same-quarter close count of 3 means only a minority of that pipeline is landing inside the quarter — with 9 DS2s on the books, next week's follow-up throughput will determine whether those advance into SQOs or stall. CS saved 2 renewals this week while Team NPS rose to 61. The 3 open red-flag accounts heading into next week are the priority queue; at a 2-per-week renewal-save pace, that's roughly 1.5 weeks of effort to clear if all convert. PLG added 412 signups at 31% activation — roughly 128 activated users — and 38 companies reached the aha moment of 10 recognition gives. That activation rate is the lever: lifting it modestly while keeping the 10-give threshold consistent would scale activated accounts faster than raw signup growth alone. [Word count: ~230]
PARTNER DIGEST — 2026-08-24 to 2026-09-04 Partner-sourced pipeline (from deal data): 5 deals, $550,000 total. ACTIVE PARTNERS Apex Rewards Co - Active. 2 sourced opps (both DS1, UTM Source = Partner): Deal-DDAAF2 $180,000, Deal-2CF33E $95,000 -> $275,000. - Co-webinar locked for 09-15. HRCloud Partners - Active. 1 sourced opp: Deal-F1CDA5 $140,000. - Integration referral closed the security review; opp moved to DS2. CultureBridge - Active. 2 sourced opps (both early stage): Deal-096E1D $60,000, Deal-067213 $75,000 -> $135,000. - Lunch-and-learn produced both. WorkWell Group - Active. No sourced deals this period ($0). - Restarting joint playbook in Q4; planning call booked 09-09. QUIET PARTNERS - Recogniq: no activity this period. - KudosWave: no activity this period. - PeopleFirst Advisors: no activity this period. - TotalPerk: no activity this period. TOTALS Deals: 5 (Apex 2, HRCloud 1, CultureBridge 2, WorkWell 0) Pipeline: $550,000 (Apex $275,000 + HRCloud $140,000 + CultureBridge $135,000) Roster: 8 partners — 4 active, 4 quiet. All accounted for; nothing added, nothing omitted. Note: Partner-sourced amounts are as logged in the deal data; I treated each sourced opportunity as one deal as shown.
Vendor response — answers grounded strictly in the provided Trust-portal policy excerpts. Nothing outside those excerpts is asserted. Q1 — Is customer data encrypted at rest? If so, how? Yes. AES-256 encryption at rest. Excerpt: P1. Q2 — Is data encrypted in transit? Yes. TLS 1.2 or higher. Excerpt: P1. Q3 — Do you hold a SOC 2 report, and can we obtain a copy? Yes. SOC 2 Type II, renewed annually; available to prospects under NDA. Excerpt: P2. Q4 — How long is customer data retained after contract termination? Retained for the contract duration plus 90 days, then deleted from production systems. Excerpt: P3. Q5 — Where is your subprocessor list published and how are changes notified? Published at trust.bonusly.com. Customers receive 30 days notice before a new subprocessor is added. Excerpt: P4. Q6 — Do you support SAML single sign-on? Yes. SAML 2.0 SSO (and SCIM user provisioning) are available on the Enterprise plan. Excerpt: P5. Q7 — What is your production backup schedule and retention? Production databases backed up daily; encrypted, retained for 35 days. Excerpt: P6. Q8 — Do you hold an ISO 27001 certification? Unanswerable from the provided excerpts — no excerpt addresses ISO 27001. A definitive answer would require the security/compliance annex, certification register, or the full Trust-portal security documentation; the excerpts provided do not contain it. Q9 — What is your contractual uptime SLA percentage? Unanswerable from the provided excerpts — no excerpt states an uptime SLA or percentage. A definitive answer would require the commercial contract / service-level agreement (SLA annex), which is not among the excerpts. Q10 — Will you sign a HIPAA Business Associate Agreement? Unanswerable from the provided excerpts — no excerpt addresses HIPAA or BAAs. A definitive answer would require the privacy/security policy set or the legal/contract review of the BAA, neither of which is present in the provided excerpts. Summary: 7 of 10 items answered from the excerpts; 3 (Q8, Q9, Q10) marked unanswerable because the policy excerpts do not cover them.
I reconciled the 14 skill files against the 14-row manifest. Findings, each with severity, action type, and a single proposal. Nothing rewritten.
FINDING 1 — ALWAYS-trigger overlap (duplicate)
- Pair: comms-drafter ↔ email-drafter.
- Evidence: comms-drafter ALWAYS-triggers on "write me an email," "draft a follow-up," "help me reply," "what should I say," "bump email," "contract nudge." email-drafter triggers on the same literal strings: "write me an email," "draft a follow-up," "help me reply to this," "what should I say," "bump email," "contract nudge." Both draft the same communication types (outbound, follow-up, post-demo, contract, QBR, onboarding, renewal), both carry the identical "If the Recipient Is Unknown ... invoke prospect-research-multithreading" step, and both delegate strategy to deal-strategy-coach. Two handlers will both claim the same request.
- Severity: CRITICAL. Action: MERGE. Proposal: merge email-drafter into comms-drafter (comms-drafter is the broader, parent skill), keeping one canonical trigger set; delete email-drafter afterward with absorbed_into=comms-drafter.
- Secondary overlap (WARNING, action REVIEW): weekly-pipeline-report and pipeline-intelligence-report collide on "pipeline update," "pipeline report / run the pipeline report," and "what does pipeline look like / what's the pipeline look like." Distinct deliverables (weekly performance HTML vs 10-tab full scoring), so not a merge — proposal: redescribe triggers so each owns disjoint phrasing and one canonical handler for the shared strings.
FINDING 2 — Circular delegation chain
- Named chain: email-drafter → deal-strategy-coach → email-drafter.
- Evidence: email-drafter's Lane marker sends strategic-coaching requests to deal-strategy-coach; deal-strategy-coach ("Manager-to-prospect email frameworks") tells the model to "use the email-drafter skill" for email drafting. A single request can route drafting→strategy→drafting with no stable terminal handler. Severity: WARNING. Action: REVIEW. Proposal: resolve by the MERGE in Finding 1 (email-drafter folds into comms-drafter) and re-point deal-strategy-coach's email reference to comms-drafter so the back-link is non-circular. Note: comms-drafter → deal-strategy-coach and deal-strategy-coach → email-drafter are inconsistent anyway — deal-strategy-coach only routes to email-drafter, ignoring comms-drafter's claim to the same lane.
FINDING 3 — Dangling delegation targets (do not exist in manifest)
- Named: prospect-research-multithreading (invoked as a hard "Contact Lookup mode" handoff by comms-drafter, email-drafter, and a dedicated "Cross-skill handoff" section in deal-strategy-coach) and bonusly-brand (referenced as a mandatory Step-0 / org dependency by comms-drafter, email-drafter, sales-forecast, and signalforge-claim-compressor).
- Also absent (referenced, no manifest row): the analysis-validator §12.4 specialist family bonusly-data-questions, -product-questions, -business-reporting-questions, -rewards-questions, -ppp-questions, -feature-flag-questions, -deal-desk-questions, -datadog-questions (8); skill-orchestrator (analysis-validator, signalforge-feedback); signalforge-reports (org-skill reference files read by pipeline-intelligence-report, weekly-pipeline-report, sales-forecast); caveman (signalforge-claim-compressor). Total 13 referenced-but-unmanifested.
- Severity: CRITICAL (a mandatory brand dependency and a hard multi-skill handoff point to skills with no record; ether they must be declared or the references suppressed). Action: REVIEW. Proposal: register the in-repo ones in the manifest or explicitly declare bonusly-brand / prospect-research-multithreading / signalforge-reports as external org deps, and re-point any reference that would otherwise dispatch to a nonexistent skill.
FINDING 4 — Version conflict
- analysis-validator declares "Version: 3.6" (Last Updated May 9, 2026) but its own Validation Trail template (Section 7) still prints "Validator: analysis-validator v3.2." pipeline-intelligence-report's footer and sales-forecast's quality gates all reference v3.6, so v3.6 is the operative truth and v3.2 is a stale hardcode.
- Severity: WARNING. Action: UPDATE_BODY. Proposal: keep v3.6; replace the literal "v3.2" in the trail template with a dynamic {version} reference (or v3.6) so the trail cannot drift from the header again.
- Related cross-skill data conflict (INFO, action REVIEW): analysis-validator §12.3 defines a "Core 6 AEs" filter that must include all six IDs, including Hugo Lindqvist (77260721), but pipeline-intelligence-report's Phase 1 AE list enumerates only five owners and omits Lindqvist. Proposal: analysis-validator's Core-6 roster should survive as canonical; back-fill Lindqvist into pipeline-intelligence-report's AE list (or have it resolve owners dynamically as stale-pipeline-report does).
FINDING 5 — descriptions exceeding 1,024 characters
- Count: 0. Largest declared values are pipeline-intelligence-report and signalforge-claim-compressor at 1,006 chars; partner-digest 1,004; none exceed 1,024. No action needed.
FINDING 6 — Hardcoded page IDs, dates, person names
Many, spread across the set (INFO severity; reference-heavy designs, but several violate the skills' own anti-hardcoding rules):
- Confluence/Atlassian IDs: partner-digest (cloudId 73fe98de-…, spaceId 1958248479, folder 2286616609, page refs 2286321666, 2265382925, 2236940297, 2237825028, 2239365136, 2238283777), sales-forecast (spaceId 2232811524, parent 2232582148), signalforge-feedback (page 2295136266, spaceId 2232811524, parent 2234417154, Build Log 2247295002), deal-strategy-coach (page 2257879045).
- Slack IDs: partner-digest hardcodes Amani's DM ID @U03QLMBL7AR; stale-pipeline-report hardcodes channel #revops-team (C0561C1JCPJ).
- Spreadsheet IDs: weekly-pipeline-report hardcodes two (1CLZe…Q2 targets, 1ENua…forecast) for a skill that also declares "always read live — do not hard-code values."
- Person names: analysis-validator §12.3 roster (~19 named people incl. Amani Phipps); pipeline-intelligence-report AES; closed-lost-analysis company examples (Estee Lauder, MinIO, Aurora Innovation, GCash, Ozinga, LIFTOFF, Nestlé, Softheon, Ethos Cannabis, StickerYou); partner-digest vendor contacts (Kelli, Jen Lee, Hani, Bryce, Sara) and "Owner: Amani Phipps"; weekly-pipeline-report title hardcodes "Ben Lavin." This conflicts with analysis-validator and stale-pipeline-report's explicit guidance to never hardcode rosters (stale-pipeline-report: "Never hardcode rep names or owner IDs"; analysis-validator: "Do not use hardcoded figures").
- Dates/figures: weekly-pipeline-report static Q1 2026 figures ($365,152 actual, $475,000 plan, $2,490,532 pipeline) and Q2 window (Apr 1–Jun 30, 2026); analysis-validator dates (Apr 26 / May 4 / May 9, 2026) and anchors (3,200+ customers, ~452,000 / ~110,097 users, 850–1,100 Gong calls); model-selection last_checked 2026-05-19 and knowledge-cutoff dates; partner-digest canonical "May 16, 2026" issue.
- Proposal (one per category, action REVIEW): extract the page/space/cloud/parent IDs into a single shared constants/reference block per skill instead of inline literals; convert the hardcoded owner (Amani in partner-digest, Ben Lavin in weekly-pipeline-report) and roster names to dynamic resolution (as stale-pipeline-report already does), converting the metadata/date figures to session-time computations.
FINDING 7 — Manifest drift
- Within the provided corpus there is zero drift in either direction: all 14 manifest rows have a file (analysis-validator … weekly-pipeline-report) and all 14 provided .SKILL.md files have a manifest row. 1:1.
- The real coverage gap is the reverse side of Finding 3: the manifest carries rows for every provided file but has no rows for the 13 referenced skills (bonusly-brand, prospect-research-multithreading, signalforge-reports, skill-orchestrator, caveman, and the 8 bonusly-*-questions specialists). If those exist as real in-repo files, they are files with no manifest row; if they don't exist at all, the manifest silently omits the skills the 14 provided files depend on.
- Severity: WARNING. Action: REVIEW. Proposal: extend the manifest to include any first-party referenced skill (or explicitly mark external org deps), so delegation targets in Finding 3 become manifest-managed rather than unresolved.
Bottom line: the single highest-leverage fix is MERGE email-drafter into comms-drafter (resolves Finding 1's worst overlap and severs the Finding 2 cycle in one move), then declare or register the 13 dangling delegation targets (Findings 3 & 7). Zero description-length violations (Finding 5), and the analysis-validator v3.6 → v3.2 drift is a one-line UPDATE_BODY (Finding 4).
# Runbook — #incident-2026-08-29-reward-queue Source: incident_thread.md (10 messages, M01–M10). Every step traces to the message cited. Where the thread is unclear or verification is not stated, I call it out. --- STEP 1 — ACKNOWLEDGE incident, take IC Who: Bryce Harmon [M01] Action: Acknowledged PagerDuty alert for reward-worker queue depth > 10k; assumed IC. Command: (none stated — no exact command in thread) Verify: Acknowledgment confirmed (IC taken per thread). Rollback: N/A — no state changed by acknowledging. STEP 2 — Measure queue depth (baseline) Who: Farid Osman [M02] Command: bundle exec rake sidekiq:queue_depth Result: reward queue at 48,213 pending jobs; normal < 500. Verify: Sample data point captured; intent was to establish magnitude. Rollback: N/A — read-only. STEP 3 — Inspect dead set for root cause Who: Farid Osman [M03] Command: (inferred: queried Sidekiq dead set — exact command NOT stated in thread) — NEEDS CONFIRMATION Result: 112 dead jobs, all Redis::TimeoutError, originating ~13:58. Verify: Dead set enumerated showing exception type + timestamp. Rollback: N/A — read-only. STEP 4 — Pause enqueue (STATE CHANGE) Who: Farid Osman [M04] Command: bin/rails runner 'FeatureFlag.disable(:auto_recognition_enqueue)' Verify: Not explicitly verified in thread; stated as "to stop the bleed." Mark absorbed into M07's confirmation (after workers scaled, depth fell). — Rollback and enablement ARE listed, but success of this specific disable is not separately confirmed. Rollback: bin/rails runner 'FeatureFlag.enable(:auto_recognition_enqueue)' STEP 5 — Clear dead set (STATE CHANGE) Who: Elena Sinclair [M05] Command: Not stated — "While I was in the console I cleared out the dead set." Exact command MISSING. NEEDS CONFIRMATION Verify: Not verified; no count or idempotency statement. NEEDS CONFIRMATION Rollback: None given. Note: the 112 dead jobs are destroyed, not requeued — no rollback in thread. ⚠ Sequencing note: M05 (14:15) cleared the dead set BEFORE enqueue was re-enabled (M09, 14:49). The 112 dead jobs were destroyed, NOT requeued — they are not recovered by the feature-flag rollback. STEP 6 — Scale workers up (STATE CHANGE) Who: Bryce Harmon [M06] Command: kubectl scale deployment/reward-worker --replicas=6 (was 3) Verify: Indirect — M07 (14:33) reports depth down to 9,400 and falling ~1,200/min; no explicit kubectl readiness check stated. Rollback: kubectl scale deployment/reward-worker --replicas=3 STEP 7 — Confirm drain (read-only verification) Who: Farid Osman [M07] Command: (measurement) — queue at 9,400 and falling ~1,200/min. Verify: Rate-of-drain report; contributes to confirming STEP 4 + STEP 6 effect. Rollback: N/A — read-only. STEP 8 — Verify full drain + error-rate baseline (STATE: confirmation gates) Who: Cole Ingram [M08] Command: bundle exec rake sidekiq:queue_depth → returns 0 Verify: Queue = 0; Datadog error rate back to baseline. Rollback: N/A — read-only (gate before re-enable). STEP 9 — Re-enable enqueue (STATE CHANGE) Who: Bryce Harmon [M09] Command: bin/rails runner 'FeatureFlag.enable(:auto_recognition_enqueue)' Verify: 40 new jobs processed cleanly in the next 3 minutes. Rollback: bin/rails runner 'FeatureFlag.disable(:auto_recognition_enqueue)' STEP 10 — Scale workers back down + mark resolved (STATE CHANGE) Who: Bryce Harmon [M10] Command: kubectl scale deployment/reward-worker --replicas=3 Verify: Queue stable at 0. Incident resolved. Rollback: kubectl scale deployment/reward-worker --replicas=6 (restore the 6-replica config if drain resumes) — NOTE: not explicitly stated as rollback in thread; inferred inverse. NEEDS CONFIRMATION --- Open items needing confirmation (thread does not contain): 1. STEP 3 — exact command used to inspect the dead set. 2. STEP 5 — exact command Elena used to clear the dead set, and POST-condition verification. 3. STEP 4 — explicit success check that enqueue actually disabled before scaling (only implied by M07's falling depth). 4. STEP 10 — rollback for the scale-down (inverse replica count) is inferred, not stated. Confirm whether "back down to 3" was the intended steady state. 5. STEP 5 data-loss scope — dead set jobs were dropped at 14:15, before re-enable; no thread message states these were recovered elsewhere. Confirm FATE of the 112 Redix::TimeoutError jobs.
First error (the root, and the earliest error in the slice):
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:
14:01:12 reward-service Redis::TimeoutError — connection to redis-primary:6379 times out (root cause)
14:01:20 reward-service Redis::TimeoutError: retry exhausted for RewardGiveJob
14:01:30 reward-service Redis::TimeoutError: retry exhausted for RewardGiveJob
14:01:40 reward-service Redis::TimeoutError: retry exhausted for RewardGiveJob
14:01:40 sidekiq RewardGiveJob failed: Redis::TimeoutError; retrying in 60s
(sidekiq_jobs.csv: J-00005 at 14:01:46, then J-00001 14:01:51, J-00003 14:01:54, J-00006 14:01:55, J-00002 14:01:56, J-00004 14:01:57 all fail with Redis::TimeoutError)
14:02:28 sidekiq RewardGiveJob failed; retrying
14:02:30 sidekiq WARN Queue reward depth above 10,000
(sidekiq_jobs.csv: J-00013..J-00016 RecognitionDigestJob also fail 14:02:36–14:05:50 — not echoed in datadog_logs)
14:03:05 api-gateway 502 upstream timeout calling reward-service /gives (first user-facing failure)
14:03:30 web-app Give form submission failed: upstream 502 from api-gateway (first front-end failure)
(then sustained 502s / RewardGiveJob retries / Give-form failures through 14:06:52)
-- gap: no error or recovery event logged between 14:06:52 and 14:22:10 --
14:22:10 reward-service Redis connection restored; resuming job processing
14:24:45 sidekiq Queue reward depth below 500
Failure topology
Dependency actually at fault: redis-primary at redis-primary:6379 (the connect target that timed out).
Primary service affected: reward-service (first to error, the one touch everything else).
Job involved: RewardGiveJob (Sidekiq), plus RecognitionDigestJob, which fails in sidekiq_jobs.csv but appears nowhere in datadog_logs.
Downstream: api-gateway (502s to /gives) then web-app (Give form failures).
Datadog query that would confirm the first error
service:reward-service AND level:error AND @message:"Connection to Redis at redis-primary:6379 timed out after 5s"
Run with results sorted oldest-first and a lower bound at the healthy baseline to prove 14:01:12 is the first occurrence:
service:reward-service level:error @evt.date:>=2026-09-03T13:55:00Z AND @message:"Redis::TimeoutError"
The first row returning 14:01:12Z and no earlier error rows confirms it as the root.
What the logs do NOT show
- Why Redis timed out: no redis-primary service logs, no network/latency/infra events. The root cause (Redis down vs. saturated vs. network partition) is absent.
- RecognitionDigestJob failures are only in sidekiq_jobs.csv; datadog_logs sidekiq lines only reference RewardGiveJob. The logs do not connect sidekiq log lines to specific job_ids.
- No 502 web-app out (i.e. outbound web-app "502" calls after 14:04:45 stop in the log while api-gateway 502s continue — no explanation).
- An unexplained silence between 14:06:52 and 14:22:10 — no incident-marking, restart, deploy, or tuning events before the recovery line.
- What restored Redis (fix/rollback/deploy) — the recovery is stated only ("connection restored").
- Exact queue depth values — only the WARN threshold ("above 10,000") and the recovery line ("below 500") are given.
- Whether the 4 RewardGiveJob retries exhausting at 14:01:20–40 and the later retries are the same or different jobs, and final death counts per job class.
FEATURE FLAG SUMMARY (derived from flags_export.csv + flag_code.md) 1. recognition_streaks_v2 - State: on | Target: segment:beta_companies | Companies: 42 - Code ref: app/models/recognition.rb — gates StreakTracker.record(give). Only beta-segment companies record recognition streaks. 2. points_budget_guardrails - State: on | Target: all_companies | Companies: 220 - Code ref: app/services/budget_service.rb — enforces points budget via BudgetService#enforce!. Enabled for the entire installed base (220 = full export). Note: it is the only flag set to all_companies. 3. slack_dm_nudges - State: on | Target: segment:region_na | Companies: 87 - Code ref: app/jobs/nudge_job.rb — early-return unless enabled; then SlackDm.send_nudge(user). Only NA-region companies get DM nudges. 4. redeem_flow_redesign - State: off | Target: targeted_list | Companies: 12 - Code ref: app/controllers/redeem_controller.rb — renders RedeemV2Component when on, else RedeemV1. Off, so all listed targets (12) are on the V1 fallback. 5. analytics_dashboard_v3 - State: on | Target: segment:tier_three | Companies: 65 - Code ref: app/controllers/analytics_controller.rb — instantiates AnalyticsV3 when enabled. Since the code only builds AnalyticsV3 inside the enabled branch, tier-three companies get v3; everyone else falls through (no branch sets AnalyticsV1 explicitly — no else render assigned in the excerpt). 6. ms_teams_app_v2 - State: off | Target: targeted_list | Companies: 9 - Code ref: app/services/teams_installer.rb — calls TeamsAppV2.install when on. Off, so listed targets (9) do not get the v2 installer. FLAGS WITH NO CODE REFERENCE (in export, absent from flag_code.md): - legacy_give_modal — off | segment:legacy_plan | 14 companies. No code usage shown. - survey_boosters_q3 — on | segment:legacy_plan | 7 companies. No code usage shown. (Overlaps the same segment as legacy_give_modal, but no code to confirm the 7 are a subset of the 14.) - paused_offboard_cleanup — off | no targeting rule | 0 companies. No code usage shown. FLAG WITH NO TARGETS: - paused_offboard_cleanup — off, empty targeting_rules, company_count = 0. Nothing gated, nothing claims it. NOTES - 6 flags map to code; 3 have no code reference (legacy_give_modal, survey_boosters_q3, paused_offboard_cleanup). - 1 flag has no targets (paused_offboard_cleanup). - Company counts are quoted exactly from the export; sum check: 42 + 220 + 87 + 12 + 65 + 9 + 14 + 7 + 0 = 456. The export lists an all_companies flag (220) alongside segment lists, so 456 is a per-flag sum, not a deduplicated account total — I cannot derive a unique-company count from this data and will not fabricate one. - State crossover worth flagging: survey_boosters_q3 is on while legacy_give_modal (same legacy_plan segment) is off — if the intent was to retire the legacy plan surface, that is inconsistent, but I have no data on what survey_boosters_q3 maps to, so this is an observation only.
NDA-1 — GREEN Standard mutual NDA: reasonable term (2 yrs) and survival (3 yrs), a full standard carve-out set including the required legally-required-disclosure exception "(e) must be disclosed by law or court order," Delaware law is normal, and it expressly disclaims license/obligation/exclusivity. No non-solicit, non-compete, or unusual terms present. No legal risk apparent. NDA-2 — YELLOW Standard mutual NDA with a clean carve-out set and Delaware governing law, BUT it carries an embedded non-solicitation: "During the term of this Agreement and for eighteen (18) months thereafter, neither party shall solicit for employment or hire any employee of the other party with whom it came into contact under this Agreement." The 18-month tail is aggressive for an evaluation-stage NDA and restricts ordinary recruiting of anyone Bonusly meets under it. Note also the term (3 yrs) is stated but no post-termination survival period is set — worth confirming the exceptions survive. Counsel should weigh in to trim the non-solicit scope/tail. NDA-3 — RED Three serious flags: (1) it is one-way in favor of [PARTY C], with no reciprocity; (2) it contains a non-compete — "For a period of three (3) years following the Effective Date, Recipient shall not, directly or indirectly, engage in or provide services to any business that competes with Discloser's business" — for an evaluation NDA this is disproportionate and likely overbroad; (3) "No confidentiality carve-outs are stated in this Agreement," meaning Bonusly has no exception for publicly available information, pre-existing knowledge, third-party receipt, independent development, or legally-required disclosure — which could put Bonusly in breach just for disclosing its own prior knowledge or complying with a court order. Compounding this, governing law is the Republic of Ireland under exclusive jurisdiction, which is unusual for a US-bound counterparty. Full legal review required before signature; negotiate reciprocity, standard carve-outs, removal/narrowing of the non-compete, and confirm governing law/jurisdiction. Summary: NDA-1 GREEN · NDA-2 YELLOW · NDA-3 RED.