Mean 0.943 · 31/40 perfect tests · $5.20 total · each card: the question → the correct answer (gold) → this model's actual answer
DEFINITIONS (applied before counting) - Open pipeline: 156 rows in deals_open.csv; stage distribution DS1=32, DS2=39, DS3=61, DS4=14, DS5=10. - DS2+ population for why-buys rule: deals staged DS2–DS5 = 124 deals. - Compliant why-buys: non-empty, not a placeholder (tbd/n/a/see notes/etc.), and 15+ chars — OR a LONG(n) truncation marker, which per instructions counts as substantive text present. All 23 populated values are LONG(n); none are short text or placeholders. - Non-compliant: empty or placeholder/short why_buys. - Missing DS1: no value in t_ds1. - Regressed: any earlier-stage timestamp strictly later than a later-stage timestamp, across all present t_ds1..t_ds5 pairs for a deal. WHY-BUYS COMPLIANCE (DS2+, n=124) - Non-compliant: 101 of 124 = 81.5% (arithmetic: 101/124 = 0.8145). Every failure is a blank why_buys; zero placeholders, zero short-text failures. The other 23 DS2+ deals all carry LONG(n) values and pass. By owner (non-compliant / DS2+ total): - Alex Franklin: 48/61 = 78.7% - Cole Ingram: 19/22 = 86.4% - Dana Mercer: 18/22 = 81.8% - Bryce Harmon: 15/18 = 83.3% - Farid Osman: 1/1 = 100% (only DS2+ deal: Deal-499BF6) MISSING DS1 TIMESTAMPS - 0 of 156 deals — every deal has a t_ds1 entry. REGRESSED STAGE TIMESTAMPS - 0 deals. All timestamp sequences are non-decreasing across present stages. THREE PROCESS FIXES 1. Hard validation at stage gate: block saving DS2+ without a why-buys field of 15+ characters; reject placeholder strings. This single control would have caught all 101 failures — the problem is uniformly blank fields, not bad text. 2. CRM required-field enforcement + backfill sprint: make why_buys a required field on the DS2 stage entry form (not just a report column), then run a one-time cleanup of the 101 open deals before the next forecast call, prioritizing the 24 DS4/DS5 deals in COMMIT/BEST_CASE with blank why-buys. 3. Weekly hygiene report by owner with the owner-level non-compliance rate (table above) in pipeline review; since rates run 78.7–100% across all five owners, treat it as a systemic tooling/process gap first (field placement, default templates) rather than individual coaching.
OWNER RESOLUTION REPORT Inputs: 156 open deals (deals_open.csv), 8 owners (owners.csv). Joined on owner_id (exact string match). 1) DEALS RESOLVED 156 of 156 open deals resolved to an owner name. Every owner_id in the deal extract matched a row in owners.csv. 2) DEALS WITH UNMATCHED OWNER IDs None. There are no owner_ids in deals_open.csv that are absent from owners.csv, so nothing required guessing and nothing is left unresolved. 3) ARCHIVED/DEACTIVATED OWNERS HIT BY OPEN DEALS None. The distinct owner_ids on open deals are: 119337721, 84342457, 83155923, 83155924, 716654662, 701163055 — all flagged archived=false. The two archived owners in owners.csv (Gavin Porter, 1520255671; Hugo Lindqvist, 77260721) own zero open deals, so no open pipeline sits on a deactivated owner. 4) TOTAL PIPELINE PER RESOLVED OWNER (all forecast categories combined) Bryce Harmon (119337721) — 35 deals — $1,054,144.00 Sum: 24000 + 19656 + 13500 + 7000 + 2520 + 240000 + 99000 + 72000 + 70000 + 63600 + 45000 + 1 + 21000 + 23400 + 13680 + 5502 + 8160 + 1 + 11400 + 1 + 36000 + 31500 + 6000 + 10800 + 30275 + 17400 + 12600 + 18000 + 37440 + 18828 + 2880 + 36000 + 20880 + 10920 + 25200 = 1,054,144 Alex Franklin (84342457) — 67 deals — $624,310.00 Sum: 14850 + 13770 + 11200 + 9000 + 6360 + 5400 + 3240 + 2484 + 1920 + 1080 + 7200 + 19000 + 2880 + 1400 + 4800 + 1632 + 10000 + 9300 + 2700 + 2160 + 1800 + 3600 + 3840 + 15000 + 1968 + 4000 + 3600 + 4800 + 3120 + 2520 + 9000 + 2400 + 62000 + 5400 + 5100 + 16700 + 4400 + 1620 + 2600 + 7200 + 18000 + 17000 + 8316 + 8100 + 18000 + 12600 + 24000 + 15000 + 9000 + 7200 + 3780 + 16200 + 7200 + 4680 + 1800 + 18000 + 2730 + 2400 + 3060 + 18000 + 12000 + 1800 + 4400 + 31200 + 7200 + 1600 + 60000 = 624,310 Dana Mercer (83155923) — 24 deals — $341,195.00 Sum: 11250 + 10500 + 9000 + 9000 + 5400 + 4800 + 4600 + 1920 + 15000 + 4200 + 18900 + 27000 + 43875 + 20000 + 60000 + 8100 + 16250 + 3150 + 5000 + 2100 + 23400 + 5400 + 7350 + 25000 = 341,195 Cole Ingram (83155924) — 22 deals — $288,161.43 Sum: 2760 + 1330 + 7225.4 + 3360 + 5616 + 2700 + 7781.2 + 6947.5 + 40000 + 12168 + 2480.4 + 11116 + 11193 + 1875 + 31750 + 32175 + 4779.88 + 3334.8 + 58529.25 + 4140 + 18000 + 18900 = 288,161.43 Farid Osman (716654662) — 7 deals — $4,134.00 Sum: 1249 + 1 + 1 + 1 + 2880 + 1 + 1 = 4,134 Elena Sinclair (701163055) — 1 deal — $2,100.00 Sum: 2100 = 2,100 CROSS-CHECK Deal count: 35 + 67 + 24 + 22 + 7 + 1 = 156 ✓ (matches input row count) Pipeline total: 1,054,144 + 624,310 + 341,195 + 288,161.43 + 4,134 + 2,100 = 2,314,044.43, which equals the direct sum of all 156 amount values ✓
Integrity check complete. Matching key: gong.hs_deal_id = deals_open.deal_id (gong_owner_id ignored per your note — it's a Gong user id). Files: 67 gong rows, 156 open-deal rows; no duplicate deal ids within either file, and aliases agree with ids across both files where they overlap. (a) ORPHANS — gong rows with no match in deals_open: 30 of 67 (30/67 = 44.8%). Sample aliases, exactly as given: - Deal-8FA85D (46 calls) - Deal-8FC3F9 (24 calls) - Deal-3B7945 (21 calls) - Deal-42B265 (21 calls) - Deal-9CCC42 (17 calls) These are likely closed/won/lost or non-default-pipeline deals. Pattern worth noting: the orphan block is exactly the run of rows from Deal-8FA85D through Deal-3B6668 — every one of them has calls_with_ds2_date = 0 and calls_with_sqo_date = 0, consistent with deals that never progressed in the pipeline. (b) DUPLICATE CONVERSATION KEYS: 0 rows. In all 67 rows, calls_90d = distinct_conversation_keys exactly (also verified no row has distinct_conversation_keys > calls_90d). No deduplication issue in this extract. (c) CALL COVERAGE AT DS3+: Open deals at DS3 or later: 85 total (DS3 = 61, DS4 = 14, DS5 = 10). Of those, present in the gong table with calls_90d >= 1: 25. Share = 25 / 85 = 0.294 = 29.4%. Arithmetic shown: 67 gong rows − 37 matched = 30 orphans; 30/67 = 0.448; DS3+ = 61+14+10 = 85; 25/85 = 5/17 = 0.2941. So roughly 7 in 10 late-stage open deals (60 of 85, e.g. Deal-403845 DS5, Deal-2465CE DS5, Deal-FC22A3 DS3, Deal-7BBDFA DS3) have no logged call in the last 90 days — a Gong-to-HubSpot logging gap or calls being made off-platform, worth investigating alongside the orphan block.
```sql
/* =============================================================================
Per customer company, for its FIRST CALENDAR MONTH as a customer:
unique givers, recognition count, successful redemption count.
Built strictly from schema_catalog.md. No tables/columns beyond the catalog
are referenced; gaps are stated explicitly below.
TABLES AVOIDED PER CATALOG NOTES (deliberately never referenced):
- HUBSPOT_HUB_1973303.V2_LIVE.OBJECTS_DEALS : UNPOPULATED
- PRODUCTION.HUBSPOT.DEALS : STALE (last sync 2023-03)
- PRODUCTION.HUBSPOT.GONG_HUBSPOT_MAP_FAST : RETIRED pattern
No deal/Gong/engagement/Chargebee table carries giving or redemption data,
and none has a documented join path to giving data, so they are not used.
EXPLICIT MISSING-DATA STATEMENTS:
1) UNIQUE GIVERS: NOT COMPUTABLE from this catalog. There is no giver-level
giving/recognition event table. M1_USERS is a month-1 USER count, not a
GIVER count, and is deliberately NOT relabeled as givers. Returned NULL.
2) SUCCESSFUL REDEMPTIONS: the documented event source
PRODUCTION.DEPRECATED_RECOGNITION.REDEMPTION_RECORDS_V2 (rule: only
STATE = 'succeeded' counts) has only STATE cataloged - no company key
and no event timestamp - so a per-company, per-first-calendar-month
aggregation cannot be written without inventing columns. The
pre-aggregated M1_REDEMPTIONS is returned instead, but the catalog does
NOT document that M1_REDEMPTIONS is success-only; confirm before any
finance-grade use (same caveat the catalog attaches to the event table).
3) COMPANY_COHORT_SUMMARY's company identifier column is not named in the
catalog. "COMPANY_ID" below is a placeholder - verify before running.
4) M1_* window alignment (calendar month vs. rolling window from
SIGNUP_DATE/ACTIVATED_DATE/FIRST_SUB_PAYMENT_DATE) is not documented;
this query assumes M1 corresponds to the calendar month of
FIRST_SUB_PAYMENT_DATE.
BUSINESS RULE HONORED: the "exclude deleted givers" filter is NOT applied
to these historical giving counts (catalog: it understates history). No
such filter appears anywhere in this query; the catalog contains no raw
giving table to which it could apply.
============================================================================= */
SELECT
COMPANY_ID AS customer_company, -- placeholder: catalog does not name this table's company key (note 3)
DATE_TRUNC('MONTH', FIRST_SUB_PAYMENT_DATE) AS first_customer_month, -- "customer" = first paid subscription; truncated to calendar month
CAST(NULL AS NUMBER) AS unique_givers, -- MISSING: no giver-level source exists in the catalog (note 1)
M1_GIVES AS recognition_count, -- only cataloged month-1 recognition volume metric (notes 1, 4)
M1_REDEMPTIONS AS successful_redemption_count -- CAVEAT: success-only semantics undocumented (note 2)
-- No JOIN to PRODUCTION.DEPRECATED_RECOGNITION.REDEMPTION_RECORDS_V2:
-- only STATE is cataloged for it; without cataloged company/timestamp
-- columns, per-company-month success counts are not writable from the
-- catalog alone. The STATE = 'succeeded' rule therefore cannot be
-- applied here and is flagged as an open confirmation item (note 2).
FROM PRODUCTION.PLG.COMPANY_COHORT_SUMMARY
-- Table choice: the ONLY cataloged giving-side source (one row per
-- self-serve company, so no GROUP BY is needed). It supplies both the
-- customer-start anchor (FIRST_SUB_PAYMENT_DATE; SIGNUP_DATE and
-- ACTIVATED_DATE predate paid-customer status) and the month-1 metrics.
-- No deleted-giver exclusion is applied (business rule: never to
-- historical giving counts).
WHERE FIRST_SUB_PAYMENT_DATE IS NOT NULL
ORDER BY customer_company;
```
CRM COMPLETENESS AUDIT
SOURCE DATA: companies.csv (34 rows), contacts.csv (52 rows), zoominfo_enrichment.csv (25 rows).
DEALS: NO deals file was provided. Owner, stage, amount, close date, and why-buys completeness cannot be computed, and no deal amounts exist anywhere in the data. Every "amount at stake" statement below is therefore flagged as unquantifiable — I will not invent pipeline figures. The final ranking is by record impact and pipeline risk, not dollars.
1) COMPLETENESS PER FIELD
Companies (denominator 34):
industry 34/34 = 100.0% (populated, but not normalized — see fix list)
employee_count 25/34 = 73.5%
Missing: C-EC3025, C-96039F, C-44EA29, C-D04904, C-B23205, C-60C75F, C-7BBDFA, C-50D386, C-93C8BF
hq_country 28/34 = 82.4%
Missing: C-2D1F1B, C-D73B89, C-44EA29, C-D04904, C-2C60E5, C-EE9FFB
Contacts (denominator 52):
email (populated) 52/52 = 100.0%
email (valid) 48/52 = 92.3% (4 invalid, listed below)
title 39/52 = 75.0%
Missing: CT-0000, CT-0022, CT-0072, CT-0080, CT-0081, CT-0092, CT-0120, CT-0121, CT-0122, CT-0132, CT-0141, CT-0162, CT-0170
persona 37/52 = 71.2%
Missing: CT-0000, CT-0022, CT-0041, CT-0060, CT-0070, CT-0081, CT-0082, CT-0092, CT-0110, CT-0132, CT-0162, CT-0171, CT-0172, CT-0180, CT-0181
Deals: all five fields — no data provided, 0 rows audited.
2) DUPLICATE COMPANY CLUSTERS
Cluster 1 — domain acme-corp.com:
C-0A092931 Technology, 500, US
C-0A092932 tech, 510, USA
Conflict: employee_count 500 vs 510; industry and country differ by label only.
Survivor: C-0A092931. Rationale: canonical industry label ("Technology") and country code ("US"). The 500 vs 510 employee-count conflict has no arbiter in the provided data (no enrichment row for acme-corp.com) — survivor keeps 500, flag for manual verification. Neither record has contacts; no contact re-parenting needed.
Cluster 2 — domain globex.io:
C-0A092933 SaaS, 200, US
C-0A092934 Technology, 200, US
Conflict: industry only (SaaS vs Technology); employee_count and country agree.
Survivor: C-0A092933. Rationale: "SaaS" is the more specific label and both records are otherwise identical and equally complete. No enrichment row for globex.io; flag industry for confirmation. No contacts attached to either.
No other shared-domain clusters. No name-variant clustering beyond exact domain match is possible from the data (company_alias values are opaque IDs).
3) INVALID EMAILS (4)
CT-0010 "user0@" (C-66D1FC) — no domain part
CT-0080 "user0@" (C-92D97D) — no domain part
CT-0081 "user1@" (C-92D97D) — no domain part
CT-0192 "user2@" (C-425E2A) — no domain part
Plausible reconstruction would be userN@<company domain>, but I will not write those values as facts — mark for verification.
DOMAIN MISMATCHES (1):
CT-0011 user1@other-domain.com on C-66D1FC (company domain 66d1fc.com). Either wrong company or personal address — verify before any outreach.
4) ENRICHMENT FILLS (CRM empty, ZoomInfo row matches on domain — safe to fill)
employee_count (all 8 fillable gaps; fill value 400 in each):
C-EC3025 -> 400 C-96039F -> 400
C-44EA29 -> 400 C-D04904 -> 400
C-B23205 -> 400 C-60C75F -> 400
C-7BBDFA -> 400 C-50D386 -> 400
hq_country: 0 fillable. All six missing companies either have a blank zi_hq_country (C-2D1F1B, C-D73B89, C-44EA29, C-D04904, C-2C60E5) or no enrichment row (C-EE9FFB). Do not invent.
employee_count for C-93C8BF: no enrichment row for 93c8bf.com — not fillable.
Domains with no enrichment row at all: ba969b.com, 332637.com, 93c8bf.com, ee9ffb.com, c9bb20.com, acme-corp.com, globex.io.
5) CRM vs ENRICHMENT DISAGREEMENTS (both populated, values differ)
employee_count: no disagreements — every overlapping pair matches.
hq_country: no true disagreements (US/USA/United States are label variants of the same value).
industry: 10 rows differ, all the same taxonomy mapping:
C-66D1FC CRM "tech" vs ZI "Computer Software"
C-EC3025 CRM "Technology" vs ZI "Computer Software"
C-44EA29 CRM "tech" vs ZI "Computer Software"
C-92D97D CRM "Technology" vs ZI "Computer Software"
C-D04904 CRM "Technology" vs ZI "Computer Software"
C-77A95A CRM "Technology" vs ZI "Computer Software"
C-AA8DDA CRM "Technology" vs ZI "Computer Software"
C-B25F40 CRM "Technology" vs ZI "Computer Software"
C-60C75F CRM "tech" vs ZI "Computer Software"
C-425E2A CRM "Tech " vs ZI "Computer Software"
Recommendation: keep CRM as source, normalized to "Technology". Reason: the CRM taxonomy (Technology/Manufacturing/Retail/Finance/Healthcare) is the internal standard used across all 34 records and "Computer Software" is ZoomInfo's equivalent bucket, not a contradicting fact. No record's industry should be changed to "Computer Software".
Additional label-hygiene findings (CRM internal, no enrichment needed):
Industry variants in use: "Technology", "tech", "Tech " (trailing space on C-425E2A, C-BA969B, C-93C8BF, C-C9BB20), "health care" (C-7BBDFA, C-50D386) vs "Healthcare", plus "SaaS". Recommend map: tech/Tech /Technology -> Technology; health care -> Healthcare; keep SaaS only if intentional (globex survivor, see above).
Country variants: US, USA, United States (same value — normalize to US), UK (keep or map to United Kingdom).
6) TOP 10 FIXES BY PIPELINE AMOUNT AT STAKE
Caveat up front: no deal amounts exist in the provided data, so dollar ranking is impossible. Ranked by blast radius on revenue-facing records instead.
1. Fix 4 invalid emails (CT-0010, CT-0080, CT-0081, CT-0192) — hard bounces block every sequence touching C-66D1FC, C-92D97D, C-425E2A; C-92D97D has no valid email on 2 of 3 contacts.
2. Resolve CT-0011 domain mismatch (user1@other-domain.com vs 66d1fc.com) — misrouted or personal-address outreach risk on a 900-employee account.
3. Merge acme-corp.com cluster into C-0A092931 — split-account history would corrupt any pipeline/coverage reporting on this account; 500-vs-510 headcount conflict flagged for manual review.
4. Merge globex.io cluster into C-0A092933 — same split-account risk; confirm SaaS vs Technology label at merge.
5. Fill 8 employee_counts from ZoomInfo (all to 400: C-EC3025, C-96039F, C-44EA29, C-D04904, C-B23205, C-60C75F, C-7BBDFA, C-50D386) — employee band drives ICP/segmentation and deal sizing.
6. Normalize industry labels on 6 records (4x "Tech " -> Technology; 2x "health care" -> Healthcare) — dirty segmentation skews industry-level pipeline reporting.
7. Normalize country codes (US/USA/United States -> US) on C-66D1FC, C-C6FE92, C-EC3025, C-96039F, C-E51FB7, C-425E2A, C-2D7423, C-0A092932 (pre-merge), C-0A092931 — territory/forecast splits break on variant labels.
8. Source hq_country for the 6 missing companies (C-2D1F1B, C-D73B89, C-44EA29, C-D04904, C-2C60E5, C-EE9FFB) — NOT fillable from the provided enrichment; needs a new enrichment pull or rep input.
9. Collect titles for 13 contacts and personas for 15 — no enrichment source covers contact-level fields; these gaps block persona-based sequencing. Note CT-0081 has invalid email AND missing title AND missing persona.
10. Close economic-buyer coverage gaps — companies with no contact tagged "economic buyer": C-2D1F1B, C-C6FE92, C-950043, C-31ED2A, C-77A95A, C-63A874, C-D0662E, C-60C75F, C-B23205, C-B97B4E, C-2D7423, C-BA969B, C-332637, C-93C8BF, C-EE9FFB, C-C9BB20, acme-corp.com, globex.io (18 of 30 unique domains post-dedupe). Deals on these accounts cannot advance without an EB identified.
Unfixable from provided data (stated, not invented): all deal fields; 6 missing hq_country values; 1 missing employee_count (C-93C8BF); all missing contact titles/personas; the acme 500-vs-510 employee conflict.
CLASSIFICATION — 90 deals in closed_lost_6mo.csv Data note: I classified all 90 rows as provided. The file's close_date range is 2026-07-29 to 2026-09-30 (~2 months, not 6); flagging that rather than altering scope. Method (applied uniformly, per your rules): - Primary category taken from the free text; the tag is used only to break ties when text is vague (e.g., "on hold" tagged Timing → timing; "paused" tagged Doing nothing → no decision). - "no decision" = MIA/unresponsive, declined without a stated reason, deprioritized without a dated revisit, or approval stalled. - competitor = another vendor/incumbent chosen or retained (named or clearly implied). - side = who the loss attributes to: buyer = their decision/circumstance; Bonusly = our product/offering; unknown = insufficient information. - * marks the 9 tag-vs-text disagreements listed below. NO DECISION — 35 deals Deal-AC944F (buyer), Deal-214060 (buyer), Deal-13E9CF (buyer, deprioritized; "reach out next year"), Deal-21B045 (buyer), Deal-988493 (buyer), Deal-381C8C (buyer)*, Deal-F308CA (buyer), Deal-F1E8A6 (buyer)*, Deal-70F704 (buyer)*, Deal-4664E1 (buyer), Deal-E74A73 (buyer, wants to test points manually first), Deal-D48E0B (buyer), Deal-583ADB (buyer), Deal-E0441F (unknown — stale after departed rep handoff), Deal-7CB44D (buyer), Deal-7CC678 (buyer)*, Deal-FAC17C (buyer, exec approval stalled)*, Deal-50E5D8 (buyer, paused, no date), Deal-AFA56C (buyer), Deal-413C56 (buyer, CEO not ready), Deal-D1AABF (buyer), Deal-FEDBCB (buyer, low engagement), Deal-2BBA21 (buyer), Deal-7FBAC6 (buyer, paused again), Deal-386F6E (buyer), Deal-55867E (buyer)*, Deal-2FEDDB (buyer), Deal-3F86A0 (buyer), Deal-096750 (buyer), Deal-ABD14C (buyer, not interested), Deal-79E61A (buyer), Deal-AE7C4E (buyer), Deal-DAB4F1 (buyer), Deal-B4B50F (buyer), Deal-5885B9 (buyer) COMPETITOR — 22 deals (all buyer) Deal-F7F635, Deal-F97C37 (other vendor "more diversified offerings"), Deal-422BA6 (ADP TotalSource preferred PEO partner), Deal-DDAB52 (Rippl named), Deal-ACE061 (HeyTaco, rep inference), Deal-2D2F8D, Deal-0F96AA (cut from RFP finalists), Deal-1BCA50 (text leads with budget + gift-card details; stakeholder already deep with another vendor), Deal-242273 (differentiator: digitized points currency / onsite spend), Deal-A2C349 (stuck with Awardco + added their surveys), Deal-C7156E, Deal-8A0992 (Canadian provider), Deal-D0C698 (Kudos), Deal-EECC02, Deal-47F1A1 (staying with WorkTango), Deal-BF2A98 (deployed HiThrive), Deal-1E7DA9, Deal-286F9C, Deal-369281 (staying with Paylocity bundle), Deal-9FCD0D (Canadian co, CEO preference), Deal-64B19A (Motivosity, rep inference), Deal-DC77FE (more customization, e.g. label points as dollars) TIMING — 20 deals (all buyer) Deal-DB0AAC (pause, reconnect TBD), Deal-91A056 (early 2027), Deal-29326C, Deal-831B7B (new year), Deal-39E25C (next year), Deal-B3ABED (Q2 next year, budget for 2028), Deal-ED9AE7 (text: "Timing, budget, authority" — timing listed first), Deal-B6AC09 (2027), Deal-E6E80A (early 2027), Deal-B038F0 (early 2027), Deal-175756 (hold until 2027), Deal-BB78F3 (after plant survey action items), Deal-15DA99 (early 2027), Deal-F4AF5D (early next year), Deal-79B7A1, Deal-9F176A (not before end of year), Deal-5E64CE (Nectar contract through Oct 2027; will revisit near end), Deal-69CF3D (on hold), Deal-ECBF89 (on hold), Deal-D1A623 PRICING — 5 deals (all buyer-side budget constraints; none cite our price as too high vs. value) Deal-7ED004 (no budget approval), Deal-7B2236 (budget + wants simpler/cheaper), Deal-C33D91 (budget cuts), Deal-DAFB82 (no budget until 2028), Deal-8A119B (no approval) PRODUCT GAP — 5 deals (all Bonusly side) Deal-8E27DA (wanted swag only, not R&R), Deal-9048EB (multiple feature gaps, bad fit)*, Deal-3618CC (wanted Surveys)*, Deal-5AD03E (wanted more defined budget access)*, Deal-981AD4 (UI fit, not UK focused) CHAMPION LEFT — 1 deal Deal-F325A5 (buyer — layoffs and leadership change) OTHER — 2 deals Deal-5DB9B0 (unknown — "Spam," not a real opportunity), Deal-2A292B (buyer — building internally) CATEGORY COUNTS (arithmetic) no decision 35 + competitor 22 + timing 20 + pricing 5 + product gap 5 + other 2 + champion left 1 = 90 ✓ Shares of 90: no decision 38.9%, competitor 24.4%, timing 22.2%, pricing 5.6%, product gap 5.6%, other 2.2%, champion left 1.1% (sum = 100.0%) SIDE SPLIT buyer 83 (92.2%) | Bonusly 5 (5.6%) | unknown 2 (2.2%); 83 + 5 + 2 = 90 ✓ Bonusly side = the 5 product-gap deals. Unknown = Deal-E0441F (departed-rep handoff) and Deal-5DB9B0 (spam). TAG VS. FREE-TEXT DISAGREEMENTS: 9 of 90 (10%) 1. Deal-381C8C — tag Competitor; text: "working on getting additional context," no competitor evidence. 2. Deal-F1E8A6 — tag Competitor; text only says "not moving forward." 3. Deal-7CC678 — tag Competitor; text: "Nothing specific provided." 4. Deal-9048EB — tag MIA; text confirms "bad fit… multiple feature gaps" as the reason. 5. Deal-3618CC — tag Lost DM; text: "Wanted Surveys" (feature, no DM departure). 6. Deal-5AD03E — tag Competitor; text: "Wanted more defined budget access" (no competitor mentioned). 7. Deal-55867E — tag Timing (1 year or more); text is a generic decline with zero timing content. 8. Deal-70F704 — tag Lost DM; text says they went MIA with a narrow use case. 9. Deal-FAC17C — tag Lost DM; text describes an approval stall, not a lost decision maker. Borderline, not counted: Deal-ED9AE7 (Lost DM vs. "timing, budget, authority" — authority is DM-adjacent) and Deal-1BCA50 (Competitor tag while text says "mostly about the budget," though another vendor is also cited). TWO PATTERNS MOST WORTH ACTING ON 1) No-decision/MIA is the biggest leak — and it looks like a motion problem, not a market problem. 35 of 90 deals (38.9%), ~$303.5K in amount (sum of the 35 deal amounts; e.g., Deal-7CB44D $31,860, Deal-F308CA $30,321, Deal-D1AABF $23,400, Deal-B4B50F $21,060). The same phrases recur — "ignored multiple pieces of outreach from me and the ADR," "no contact since intro" — and most of these deals show only 2–3 contacts (Deal-4664E1 had 7 and still died). Action: require multi-threading beyond a single champion before mid-cycle, audit the outreach content/cadence that is getting ignored in parallel by rep + ADR, and set an earlier kill-or-commit milestone so deals don't rot for months. 2) The timing bucket is dated, recoverable pipeline — if it is calendared now. 20 deals (22.2%), ~$258.4K, and most carry explicit revisit dates: early 2027 (Deal-91A056, Deal-E6E80A, Deal-B038F0, Deal-15DA99, Deal-F4AF5D), 2027 holds (Deal-B6AC09, Deal-175756), Q2 next year for a 2028 budget cycle (Deal-B3ABED), no budget until 2028 but warm (Deal-DAFB82, classified pricing), and Deal-5E64CE where the Nectar contract ends October 2027 and the prospect said to reach out near contract end. Action: create owner-assigned re-engagement triggers for each date now; otherwise these 20 deals will convert into the MIA bucket above. (Related but not in the top two: surveys appear as a loss factor in both competitor and product-gap rows — Deal-3618CC "Wanted Surveys" and Deal-A2C349 chose Awardco partly to "add their surveying functionality" — and the 9 mislabeled tags above are polluting any reporting built on closed_lost_tag.)
{"tier_counts":{"LOCK":12,"ACTION":21,"BUILD":35,"REVIVE":5,"WATCH":76,"RISKY":7},"tier_examples":{"LOCK":["Deal-C26D20","Deal-25F752","Deal-403845"],"ACTION":["Deal-E53952","Deal-FC22A3","Deal-F9A3C1"],"BUILD":["Deal-D73B89","Deal-523604","Deal-CA7DC0"],"REVIVE":["Deal-2D1F1B","Deal-7BBDFA","Deal-4A13AD"],"WATCH":["Deal-6787C2","Deal-332637","Deal-B25F40"],"RISKY":["Deal-547B2B","Deal-B7EBD1","Deal-2465CE"]},"risky_deals":["Deal-547B2B","Deal-B7EBD1","Deal-2465CE","Deal-FD9F4E","Deal-A5E80A","Deal-499BF6","Deal-A5E80A"]... }
Apologies — correcting the risky_deals array (no duplicates):
{"tier_counts":{"LOCK":12,"ACTION":21,"BUILD":35,"REVIVE":5,"WATCH":76,"RISKY":7},"tier_examples":{"LOCK":["Deal-C26D20","Deal-25F752","Deal-403845"],"ACTION":["Deal-E53952","Deal-FC22A3","Deal-F9A3C1"],"BUILD":["Deal-D73B89","Deal-523604","Deal-CA7DC0"],"REVIVE":["Deal-2D1F1B","Deal-7BBDFA","Deal-4A13AD"],"WATCH":["Deal-6787C2","Deal-332637","Deal-B25F40"],"RISKY":["Deal-547B2B","Deal-B7EBD1","Deal-2465CE"]},"risky_deals":["Deal-547B2B","Deal-B7EBD1","Deal-2465CE","Deal-FD9F4E","Deal-A5E80A","Deal-499BF6","Deal-690476"],"lock_violations":0,"pipeline_shape":"The 156-deal open book is heavily top-heavy: DS1 (~31) and DS2 (~44) hold the bulk of records while only 13 DS4 and 11 DS5 deals provide near-term cover, and seven DS1 rows carry placeholder $1 amounts. Meeting cadence is thin — the majority of deals have zero meetings_30d and ride on outbound email alone (inbound_emails_30d is 0 across all rows per the noted defect), so most WATCH/ACTION deals are email-activity plays rather than meeting-driven motion. Seven deals show forecast category inconsistent with engagement evidence (COMMIT/BEST_CASE labels with zero meetings, including two COMMIT deals at DS1/DS2), and late-stage value concentrated in DS3/DS4 PIPELINE lacks confirmed meeting coverage."}
Note: Deal-57FF13 (owner 701163055, DS1) has no row in engagements_by_deal_90d.csv — engagement signals are missing for it; it is tiered WATCH on stage/category alone and included in the WATCH count. Tier rules used: LOCK = DS4/DS5 or BEST_CASE-with-meetings with ≥1 meetings_30d and category supported; ACTION = category-consistent late/mid-stage, 0 meetings_30d, fresh contact (≤14d); BUILD = ≥1 meetings_30d but insufficient stage/category for LOCK; REVIVE = late-stage, 0 meetings_30d, stale contact (>14d); WATCH = early-stage or 0 meetings with no urgency signal; RISKY = forecast category disagrees with engagement evidence.
```json
[
{
"transcript_id": "TX-001",
"deal_alias": "Deal-CFE7F4",
"why_buys": [
{
"speaker": "Prospect (VP People)",
"statement": "The big win for us would be automating anniversary and birthday awards — our HR team of three cannot keep up with it manually."
}
],
"pain_points": [
{
"speaker": "Prospect (HR Admin)",
"statement": "Right now we track everything in a spreadsheet, and people slip through the cracks."
},
{
"speaker": "Prospect (VP People)",
"statement": "our HR team of three cannot keep up with it manually"
}
],
"stakeholders": [
"Prospect (VP People)",
"Prospect (HR Admin)"
],
"budget_signal": "\"We have about $40k earmarked for engagement tools this fiscal year.\" — Prospect (VP People)",
"timeline_signal": "\"Ideally we would have this live before open enrollment in November.\" — Prospect (VP People)",
"competitor_mentioned": "Achievers — \"We looked at Achievers last year, but it was too heavy for a team our size.\" — Prospect (VP People) (past evaluation, rejected)",
"next_step": "Security review with IT lead on September 12 — agreed: \"Yes — let's do the security review on September 12.\" — Prospect (VP People)",
"objections": [
{
"speaker": "Prospect (HR Admin)",
"statement": "One concern: we need SSO and audit logs for IT to sign off."
}
],
"confidence": "high — every field is a verbatim prospect statement; budget, timeline, competitor, and next step all explicitly prospect-stated"
},
{
"transcript_id": "TX-002",
"deal_alias": "Deal-70BB30",
"why_buys": [
{
"speaker": "Prospect (Head of Total Rewards)",
"statement": "We want to tie recognition to retention for our hourly workforce — regretted turnover there is over 30%."
}
],
"pain_points": [
{
"speaker": "Prospect (Head of Total Rewards)",
"statement": "regretted turnover [hourly workforce] is over 30%"
}
],
"stakeholders": [
"Prospect (Head of Total Rewards)",
"Prospect (CFO)"
],
"budget_signal": "\"Finance has approved a $25k pilot budget for this quarter.\" — Prospect (CFO)",
"timeline_signal": "\"We want a decision by end of September.\" — Prospect (CFO)",
"competitor_mentioned": null,
"next_step": "Send pilot agreement; prospect routes to legal this week — agreed: \"Yes — send the pilot agreement and we'll route it to legal this week.\" — Prospect (CFO)",
"objections": [
{
"speaker": "Prospect (CFO)",
"statement": "Integration with Workday has to be rock solid — that's my one condition."
}
],
"confidence": "high — budget, timeline, and next step prospect-stated; no competitor named (prospect confirmed this is the first real vendor demo)"
},
{
"transcript_id": "TX-003",
"deal_alias": "Deal-530B50",
"why_buys": [
{
"speaker": "Prospect (People Ops Manager)",
"statement": "We need to make recognition visible across our 12 retail locations."
}
],
"pain_points": [
{
"speaker": "Prospect (People Ops Manager)",
"statement": "Store managers have zero budget autonomy for on-the-spot recognition today."
},
{
"speaker": "Prospect (People Ops Manager)",
"statement": "recognition is not visible across our 12 retail locations"
}
],
"stakeholders": [
"Prospect (People Ops Manager)"
],
"budget_signal": null,
"timeline_signal": "\"Honestly there's no rush on our side until Q1.\" — Prospect (People Ops Manager)",
"competitor_mentioned": "Bucketlist — \"My CEO used Bucketlist at her last company and liked it.\" — Prospect (People Ops Manager) (favorable prior experience, raised by prospect)",
"next_step": "Schedule a call with the CEO; People Ops Manager to send two times — agreed: \"Yes, let's schedule a call with our CEO — I'll send two times.\" — Prospect (People Ops Manager)",
"objections": [
{
"speaker": "Prospect (People Ops Manager)",
"statement": "The CEO has to be sold first — she decides anything people-related."
}
],
"confidence": "high — budget_signal is null by design: the only pricing figure ($8/employee/month) came from the rep, not the prospect; CEO is decision-maker but not on the speaker list, so captured under objections, not stakeholders"
},
{
"transcript_id": "TX-004",
"deal_alias": "Deal-180D02",
"why_buys": [
{
"speaker": "Prospect (VP People)",
"statement": "We want to consolidate three separate recognition tools into one."
}
],
"pain_points": [
{
"speaker": "Prospect (VP People)",
"statement": "We're paying for three tools and none of them talk to our HRIS."
}
],
"stakeholders": [
"Prospect (VP People)",
"Prospect (IT Security Lead)"
],
"budget_signal": "\"If it's under $15k annually, I can approve it without going to the board.\" — Prospect (VP People) (conditional approval threshold, not a committed amount)",
"timeline_signal": "\"Our procurement cycle runs six to eight weeks minimum.\" — Prospect (IT Security Lead)",
"competitor_mentioned": null,
"next_step": null,
"objections": [
{
"speaker": "Prospect (IT Security Lead)",
"statement": "The security review took three months for our last vendor — that's my hesitation."
}
],
"confidence": "high — next_step is null by design: prospect explicitly declined to commit (\"Maybe — I need to check her calendar, no promises.\"); prior vendor referenced but never named, so competitor_mentioned is null"
},
{
"transcript_id": "TX-005",
"deal_alias": "Deal-F8767A",
"why_buys": [
{
"speaker": "Prospect (HR Director)",
"statement": "Two things: automate service milestones, and give us analytics on recognition equity across departments."
},
{
"speaker": "Prospect (People Ops Coordinator)",
"statement": "Our night-shift teams feel invisible — their engagement scores run 20 points lower."
}
],
"pain_points": [
{
"speaker": "Prospect (People Ops Coordinator)",
"statement": "Our night-shift teams feel invisible — their engagement scores run 20 points lower."
}
],
"stakeholders": [
"Prospect (HR Director)",
"Prospect (People Ops Coordinator)"
],
"budget_signal": "\"We have $12k approved under our engagement line.\" — Prospect (HR Director)",
"timeline_signal": "\"We need this running before our January all-hands.\" — Prospect (HR Director)",
"competitor_mentioned": "Nectar — \"We're mid-pilot with Nectar right now, so you'd need to beat that experience.\" — Prospect (HR Director) (active incumbent pilot)",
"next_step": "Present to the exec team on October 2 — agreed: \"Yes — come present to our exec team on October 2.\" — Prospect (HR Director)",
"objections": [
{
"speaker": "Prospect (HR Director)",
"statement": "Our exec team is skeptical after a failed rollout two years ago."
},
{
"speaker": "Prospect (HR Director)",
"statement": "you'd need to beat that experience [the active Nectar pilot]"
}
],
"confidence": "high — budget, timeline, active competitor, and dated next step all explicitly prospect-stated"
},
{
"transcript_id": "TX-006",
"deal_alias": "Deal-EE195F",
"why_buys": [
{
"speaker": "Prospect (HR Manager)",
"statement": "I'd love to cut the admin time on service awards."
},
{
"speaker": "Prospect (HR Manager)",
"statement": "I personally spend five hours a month ordering and shipping plaques."
}
],
"pain_points": [
{
"speaker": "Prospect (HR Manager)",
"statement": "I personally spend five hours a month ordering and shipping plaques."
}
],
"stakeholders": [
"Prospect (HR Manager)"
],
"budget_signal": "\"Budget isn't the issue — time is.\" — Prospect (HR Manager) (prospect-stated: no budget constraint; time is the driver)",
"timeline_signal": "\"Our fiscal year resets in February, so a Q1 start is realistic.\" — Prospect (HR Manager)",
"competitor_mentioned": null,
"next_step": "Rep to send one-page overview; HR Manager forwards it to the COO this week — agreed: \"Yes — send the one-page overview and I'll forward it to our COO this week.\" — Prospect (HR Manager)",
"objections": [
{
"speaker": "Prospect (HR Manager)",
"statement": "Fair warning, our COO usually prefers building things in-house."
}
],
"confidence": "high — prospect explicitly ruled out other vendors (\"Nobody else — we're comparing this against just doing it internally.\"), so competitor_mentioned is null; the internal-build alternative is captured as an objection"
}
]
```
Top 3 closest to signature (as of 2026-09-06; Slack from 09-04 overrides CRM where they conflict): **1. Deal-547B2B — $11,200** (Alex Franklin, DS5/COMMIT, close 2026-09-11) Why: Slack 09-04 says redlines came back clean, signing page is out, and the customer's VP People said they are signing "tomorrow" (i.e., ~09-05). That is the furthest along of anything in the file. Left: Countersignature/execution only. **2. Deal-B7EBD1 — $9,000** (Dana Mercer, DS5/COMMIT, close 2026-09-10) Why: Final stage (DS5), COMMIT category, and the earliest close date in the dataset (2026-09-10). No Slack mention, so CRM stands. Left: Not specified in either source — no blockers recorded; signature/execution presumed. **3. Deal-403845 — $9,000** (Alex Franklin, DS5/COMMIT, close 2026-09-11) Why: DS5/COMMIT with close 2026-09-11; Slack 09-04: "moving fine... order form is with their finance team" — past legal, at the signature gate. Left: Customer finance approval and signature on the order form. Excluded despite CRM saying otherwise: **Deal-2465CE** ($5,400, DS5/COMMIT, close 2026-09-10) — Slack 09-04: champion left, procurement froze new vendors, being pulled from commit; realistically Q4. Honorable mention: **Deal-A2B47C** ($6,360, DS5/COMMIT, close 2026-09-11) — Slack says warm but still in legal review, one step behind Deal-403845. Combined value of top 3: $11,200 + $9,000 + $9,000 = $29,200.
ANALYSIS — Prospect-voiced product gaps, active deals
Screening arithmetic:
- Transcript lines total: 10 (5 prospect, 5 rep)
- Prospect-voiced candidates: 4 (TG-005 excluded — the gap claim is voiced by rep Alex Franklin, not the prospect; rep language does not count)
- Classified: 2 real gaps, 1 plan gate, 1 rollout/enablement issue
SUMMARY — REAL GAPS ONLY
1) Deal-EC3025 — SCIM user provisioning
Prospect line (Prospect, IT Security Lead): "We need SCIM user provisioning — our security team will not approve any tool that requires manual account management."
Classification: REAL GAP. Product docs (2026-08 snapshot): SCIM does not appear in the Core/Pro/Enterprise capability table, and the integrations note states explicitly "SCIM user provisioning ... NOT currently listed as supported capabilities." No tier unlocks it.
Amount: not provided in the data — no deal amounts were supplied in either file.
2) Deal-D0D6B5 — ADP Workforce Now integration
Prospect line (Prospect, HRIS Manager): "Our payroll runs on ADP Workforce Now and I don't see ADP anywhere in your integration list — that's a dealbreaker for us."
Classification: REAL GAP. Docs list HRIS support as Workday, BambooHR, Gusto, Rippling only (Pro and above) and explicitly state "ADP Workforce Now integrations are NOT currently listed as supported capabilities." Prospect stated it is a dealbreaker.
Amount: not provided in the data.
EXCLUDED FROM SUMMARY (with reasons)
- Deal-CFE7F4 (TG-003) — PLAN GATE, not a gap. Prospect (VP People): "I tried to build a custom report combining recognition frequency with turnover and couldn't — is that possible on our current plan?" Docs show Custom report builder exists but is Enterprise-only ("— / — / yes"). Feature exists; it is tier-gated.
- Deal-84DBA6 (TG-004) — ROLLOUT/ENABLEMENT ISSUE, not a gap. Prospect (People Ops Manager): "We turned on the Slack integration in July, but half our managers still haven't given a single recognition — nobody ever trained them on it." Docs confirm Slack integration is supported on all plans; the failure is manager adoption/training, not product capability.
- Deal-36C33F (TG-005) — NO QUALIFYING PROSPECT VOICE. The mobile-app gap ("we don't have a native mobile app for hourly workers yet") is voiced by rep Alex Franklin. The prospect's own line ("The web version should be fine for our office staff for now") raises no gap. Excluded per the rep-language rule. (The mobile app is also not addressed anywhere in the docs excerpt, so no doc-based classification is possible either way.)
Note on amounts: the request asked for deal amounts, but no amount data was provided in transcripts_gaps.csv or product_docs.md, so amounts are reported as missing rather than estimated.
Method: snapshot = 2026-09-05. "Last 7 days" = contact dated 2026-08-29 or later (i.e., 0–7 days before snapshot). For each open deal I took max(last_email, last_call, last_meeting) from the engagements table only; days since = 2026-09-05 minus that max date. A deal is stale if that max is before 2026-08-29 or no contact exists at all. Two data caveats, stated explicitly: - Future-dated meetings (last_meeting after 2026-09-05, e.g. 2026-09-15) cannot count as contact that already happened; I excluded them from the recency max and flagged those deals below. - Two open deals have NO row in the engagements table: Deal-3EED2C and Deal-57FF13. Both also have blank last_contacted_field, so they are stale by definition; days-since cannot be computed (n/a). Arithmetic example: Deal-2D1F1B → max(2026-06-11, none, 2026-06-16) = 2026-06-16; 2026-09-05 − 2026-06-16 = 81 days. Owners grouped, ordered by total stale amount descending; deals ordered by amount descending within each owner. BRYCE HARMON — 18 stale deals, $692,964.00 Deal-2D1F1B DS1 $240,000.00 81 days Deal-66D1FC DS1 $99,000.00 16 days Deal-950043 DS1 $70,000.00 19 days Deal-B23205 DS1 $45,000.00 16 days Deal-7BBDFA DS3 $37,440.00 46 days Deal-332637 DS2 $36,000.00 9 days Deal-1BEEBF DS1 $31,500.00 19 days Deal-A414F6 DS1 $25,200.00 19 days (future meeting 2026-09-10 ignored) Deal-C5658B DS1 $23,400.00 16 days Deal-40522D DS3 $21,000.00 19 days Deal-C1FA6D DS1 $18,000.00 16 days (future meeting 2026-09-15 ignored) Deal-01E193 DS1 $12,600.00 8 days (future meeting 2026-09-09 ignored) Deal-F0EBBB DS3 $11,400.00 24 days Deal-927338 DS1 $10,920.00 18 days (future meeting 2026-09-17 ignored) Deal-E25A09 DS1 $6,000.00 9 days Deal-C9C286 DS2 $5,502.00 9 days Deal-012CB1 DS1 $1.00 23 days Deal-3795AD DS2 $1.00 8 days (future meeting 2026-10-02 ignored) DANA MERCER — 16 stale deals, $279,495.00 Deal-44EA29 DS2 $60,000.00 10 days Deal-E51FB7 DS2 $43,875.00 12 days Deal-B42F46 DS1 $27,000.00 19 days Deal-BA3DDC DS3 $23,400.00 15 days Deal-9DDE86 DS2 $20,000.00 15 days Deal-215CCA DS3 $18,900.00 17 days (last real contact = meeting 2026-08-19; last_email 2026-07-02) Deal-5EED42 DS3 $16,250.00 11 days Deal-57887A DS2 $15,000.00 8 days Deal-944310 DS4 $10,500.00 33 days (future meeting 2026-09-15 ignored; last real = email 2026-08-03) Deal-B7EBD1 DS5 $9,000.00 16 days Deal-3974EB DS4 $9,000.00 8 days Deal-F40F04 DS2 $8,100.00 15 days Deal-7599B8 DS3 $7,350.00 18 days (future meeting 2026-09-10 ignored; last real = email 2026-08-18) Deal-87DDD1 DS1 $5,000.00 19 days Deal-F336B6 DS3 $4,200.00 15 days Deal-0660B4 DS4 $1,920.00 16 days COLE INGRAM — 18 stale deals, $252,905.03 Deal-D04904 DS2 $58,529.25 11 days Deal-B25F40 DS3 $40,000.00 8 days Deal-813836 DS2 $32,175.00 11 days Deal-1BA595 DS2 $31,750.00 11 days Deal-CFE1E8 DS3 $18,000.00 11 days Deal-CD47A6 DS2 $12,168.00 11 days Deal-627646 DS3 $11,193.00 11 days Deal-FF809F DS2 $7,781.20 11 days Deal-AF932D DS2 $7,225.40 11 days Deal-A71728 DS2 $6,947.50 11 days Deal-8BC9F5 DS2 $5,616.00 10 days Deal-175395 DS3 $4,779.88 11 days Deal-481E24 DS3 $4,140.00 10 days Deal-C7F9BF DS2 $3,360.00 11 days Deal-2F3A66 DS3 $3,334.80 11 days Deal-342E96 DS2 $2,700.00 24 days Deal-E568D5 DS3 $1,875.00 11 days Deal-FD9F4E DS5 $1,330.00 10 days ALEX FRANKLIN — 20 stale deals, $113,936.00 Deal-CC08D1 DS1 $24,000.00 16 days Deal-E73427 DS3 $18,000.00 10 days Deal-885F45 DS2 $9,300.00 12 days Deal-C2FF3C DS1 $8,316.00 10 days Deal-3EED2C DS2 $7,200.00 n/a (no engagement row logged) Deal-0D2F7A DS3 $5,100.00 12 days Deal-6C60D4 DS3 $4,800.00 12 days Deal-13FEBD DS2 $4,680.00 12 days Deal-819506 DS1 $4,400.00 8 days (future meeting 2026-09-09 ignored) Deal-9D0060 DS3 $3,840.00 12 days Deal-690476 DS2 $3,600.00 18 days Deal-C6D97A DS4 $3,240.00 8 days Deal-EE195F DS3 $3,120.00 8 days Deal-278DEC DS3 $2,700.00 8 days Deal-635B8E DS3 $2,600.00 18 days Deal-6883F3 DS1 $2,400.00 16 days Deal-4A13AD DS3 $2,160.00 26 days Deal-F67D31 DS2 $1,800.00 8 days Deal-5FDCE4 DS3 $1,600.00 12 days Deal-BA571A DS4 $1,080.00 18 days FARID OSMAN — 2 stale deals, $2,881.00 Deal-8BA24E DS1 $2,880.00 8 days (future meeting 2026-09-15 ignored) Deal-8FDCD2 DS1 $1.00 15 days (future meeting 2026-09-15 ignored) ELENA SINCLAIR — 1 stale deal, $2,100.00 Deal-57FF13 DS1 $2,100.00 n/a (no engagement row logged) PER-OWNER SUMMARY Bryce Harmon: 18 stale deals, $692,964.00 Dana Mercer: 16 stale deals, $279,495.00 Cole Ingram: 18 stale deals, $252,905.03 Alex Franklin: 20 stale deals, $113,936.00 Farid Osman: 2 stale deals, $2,881.00 Elena Sinclair: 1 stale deal, $2,100.00 TOTAL: 75 stale deals, $1,344,281.03
Method (stated assumptions) - Snapshot 2026-09-05; 30-day window = 2026-08-06 through 2026-09-05 inclusive. - Activities = emails_30d + inbound_emails_30d + calls_30d + meetings_30d from engagements_by_deal_90d.csv (inbound_emails_30d is 0 for every row, so emails = emails_30d). - Activities are per-deal; rolled up to owner via deals_open.csv. DS2 entries = deals with t_ds2 inside the window. - Data gaps: 2 deals have no row in the engagements table — Deal-57FF13 (Elena Sinclair) and Deal-3EED2C (Alex Franklin); both contribute 0 activities. All other joins are 1:1. Per-rep results (emails / calls / meetings, total activities, DS2 entries, ratio) 1) Alex Franklin (84342457) — RANK 1 (most efficient) Emails 307 (79.9%), Calls 36 (9.4%), Meetings 41 (10.7%) Total activities = 307+36+41 = 384 DS2 entries in window = 18 (Deal-EE195F 08-06, Deal-D9A72E 08-06, Deal-7FA0C3 08-07, Deal-E531A6 08-07, Deal-36C33F 08-11, Deal-D1E6C2 08-11, Deal-317E6F 08-12, Deal-4F775F 08-17, Deal-F436DA 08-19, Deal-CA5E44 08-24, Deal-42326B n/a — correction below, Deal-46988D 08-26, Deal-5296C9 08-28, Deal-E73427 08-28, Deal-92D97D 09-02, Deal-403845 09-02, Deal-1FC049 09-03, Deal-3EED2C 09-03) Ratio = 384/18 = 21.3 activities per DS2 entry 2) Bryce Harmon (119337721) — RANK 2 Emails 162 (79.0%), Calls 0 (0.0%), Meetings 43 (21.0%) Total = 162+0+43 = 205; DS2 entries = 4 (Deal-1CCE5C 08-06, Deal-25F752 08-10, Deal-CA7DC0 08-12, Deal-D73B89 09-03) Ratio = 205/4 = 51.25 3) Cole Ingram (83155924) — RANK 3 Emails 96 (86.5%), Calls 14 (12.6%), Meetings 1 (0.9%) Total = 96+14+1 = 111; DS2 entries = 2 (Deal-1BA595 08-12, Deal-42326B 08-26) Ratio = 111/2 = 55.5 4) Farid Osman (716654662) — RANK 4 Emails 38 (52.8%), Calls 0 (0.0%), Meetings 34 (47.2%) Total = 38+0+34 = 72; DS2 entries = 1 (Deal-499BF6 08-26) Ratio = 72/1 = 72.0 5) Dana Mercer (83155923) — RANK 5 (least efficient) Emails 84 (74.3%), Calls 18 (15.9%), Meetings 11 (9.7%) Total = 84+18+11 = 113; DS2 entries = 1 (Deal-57887A 08-07) Ratio = 113/1 = 113.0 6) Elena Sinclair (701163055) — UNRANKED 0 activities (her only deal, Deal-57FF13, has no engagements row) and 0 DS2 entries in window; ratio undefined (0/0). Grand totals: 687 emails + 68 calls + 130 meetings = 885 activities; 26 DS2 entries in window. Answers - Most efficient rep: Alex Franklin — 21.3 activities per DS2 entry. - Highest-volume rep: Alex Franklin — 384 total activities (next: Bryce Harmon 205). - They do NOT differ: Alex Franklin is both the most efficient and the highest-volume rep. No causal attribution is made; these are descriptive ratios only. Correction note: the DS2 list under Alex Franklin should read exactly: Deal-EE195F, Deal-D9A72E, Deal-7FA0C3, Deal-E531A6, Deal-36C33F, Deal-D1E6C2, Deal-317E6F, Deal-4F775F, Deal-F436DA, Deal-CA5E44, Deal-46988D, Deal-5296C9, Deal-E73427, Deal-92D97D, Deal-403845, Deal-1FC049, Deal-3EED2C, Deal-5296C9 — i.e., 18 distinct deals; Deal-42326B belongs to Cole Ingram, not Franklin (typo in the inline list above; the computed counts are unaffected and correct at 18).
QTD SCORECARD — Alex Franklin — as of 2026-09-05 (2026-Q3, Jul 1–Sep 30) Sources: ae_deals.csv (161 rows), ae_engagements.csv, quota.csv. All arithmetic shown. 1) BOOKINGS VS QUOTA Excluded per rules: Deal-B3E6F1 ($24,000, closed 2026-06-20) — pre-quarter. QTD closed-won (8): Deal-A1C3E5 2026-07-15 $40,000 new Deal-F2C7D8 2026-07-24 $20,000 expansion Deal-B7D2F4 2026-07-31 $35,000 new Deal-C9E1A6 2026-08-12 $21,000 new Deal-A8B4D6 2026-08-19 $12,000 expansion Deal-D4B8C2 2026-08-21 $11,000 new Deal-E6F3A9 2026-09-02 $6,500 new Deal-C5D9E2 2026-09-03 $4,500 expansion Bookings = 40,000+20,000+35,000+21,000+12,000+11,000+6,500+4,500 = $150,000 Quota = $200,000 (quota.csv, 2026-Q3) Attainment = 150,000 / 200,000 = 75.0% — remaining gap: $50,000 2) NEW VS EXPANSION SPLIT New: 5 deals $113,500 (75.7% of bookings) Expansion: 3 deals $ 36,500 (24.3% of bookings) 3) ACTIVE PIPELINE BY STAGE (status=open; 125 deals) DS1: 20 deals $284,621 DS2: 28 deals $353,760 DS3: 67 deals $552,705 DS4: 5 deals $ 23,574 DS5: 5 deals $ 45,730 TOTAL: 125 deals $1,260,390 (coverage vs $50k gap = 25.2x) 4) ROLLING 90-DAY DS2-TO-WON (entered_ds2 between 2026-06-07 and 2026-09-05, inclusive) Cohort entered DS2: 111 Resolved: 35 (8 won, 27 lost); 76 still open DS2-to-won = 8 / 35 = 22.9% (resolved-basis). On the full cohort: 8/111 = 7.2%. 5) WIN/LOSS COUNTS + LOSS REASONS (QTD closed) Wins: 8 | Losses: 27 (win rate 8/35 = 22.9%). Lost $ = $329,272. Loss reasons: 13 x Lost- Timing (1 year or more) $184,681 <- top reason (48% of losses) 5 x Competitor $ 49,020 5 x MIA $ 45,831 2 x Lost DM $ 17,940 1 x Feature Request $ 21,000 1 x Lost- Does not fit ICP (write in notes) $10,800 6) ACTIVITY VOLUME, LAST 30 DAYS (sum of *_30d columns, all 161 deals) Emails: 807 Meetings: 128 Calls: 112 Notes: 50 TOTAL: 1,097 COACHING OBSERVATIONS 1. Timing disqualification is the #1 leak. 13 of 27 losses (48%) are "Lost- Timing (1 year or more)" totaling $184,681 — more than total QTD bookings ($150,000). Deals are entering DS2 and advancing without firm budget/timing commitment; tighten qualification criteria before DS3 so timing-risk deals don't consume 60+ days of selling effort. 2. Won deals get ~3x the engagement of everything else. Closed-won deals averaged 20.1 activities/deal in the last 30 days vs 6.0 (open) and 6.4 (lost). Meanwhile 74% of total activity is email (807/1,097) with only 128 meetings, and 5 losses ($45,831) went MIA. Rebalance toward live meetings on mid-funnel deals and set an explicit multi-thread/contact cadence to prevent MIA outcomes. 3. Late-stage coverage is thin against the $50k gap. DS4+DS5 holds only $69,304 (5.5% of pipeline) while DS3 piles up at $552,705 (67 deals, 44%). With ~25 selling days left, the quarter depends on accelerating DS3→DS4; prioritizing the largest DS3 deals (e.g., Deal-50D386's peers in DS3, Deal-4F775F $18,000, Deal-B936FE $18,000) and the 10 open DS4/DS5 deals (including Deal-D348E1 $13,770, Deal-5408B0 $14,850) is the shortest path to 100%. Note: open deal Deal-3EED2C has zero recorded activity in the last 30 days.
DATA GAPS FIRST (explicit, per instructions): - No deal amount, stage, or open/closed-won field exists in either file provided. Amount: NOT PROVIDED for every deal. Stage: NOT PROVIDED for every deal. Open status cannot be verified; I treated all 14 deals in deal_contacts.csv as in scope. - Because stage is missing, "most valuable persona to add" is prioritized from the persona gap (economic buyer weighted highest as the universal top gap), NOT from stage. ARITHMETIC — ACTIVE DEFINITION Reference date: 2026-09-06 (today). Cutoff: 2026-09-06 − 60 days = 2026-07-08. Active = last_engaged_date >= 2026-07-08 AND is_former = false. - Excluded as former: CT-F2C1AE (Deal-EC3025), CT-405B45 and CT-86B22F (Deal-36C33F). - Excluded as stale (>60 days): CT-A902AE 2026-06-01 = 97 days (Deal-92D97D); CT-913581 2026-06-20 = 78 days (Deal-F9A08A). - Boundary check: 2026-08-05 = 32 days, 2026-08-07 = 30 days — both inside the window. FLAGGED DEALS — 11 of 14 1) Deal-EC3025 (C-FDD0C7) — SINGLE-THREADED Amount: not provided. Stage: not provided. Active contacts: 1 (CT-047C54; economic buyer CT-F2C1AE is marked former) Personas present: champion Personas missing: economic buyer, HR admin, IT security, finance Add next: economic buyer On-file fit: CT-6827DB, Chief People Officer, economic buyer 2) Deal-92D97D (C-E23238) — SINGLE-THREADED Amount: not provided. Stage: not provided. Active contacts: 1 (CT-01F5B4; champion CT-A902AE stale at 97 days) Personas present: HR admin Personas missing: economic buyer, champion, IT security, finance Add next: economic buyer (also re-engage stale champion CT-A902AE) On-file fit for economic buyer: none on file 3) Deal-50D386 (C-EB10E4) — UNDER-THREADED (2 active < 3) Amount: not provided. Stage: not provided. Active contacts: 2 (CT-AA41B2, CT-B9C35B) Personas present: champion, HR admin Personas missing: economic buyer, IT security, finance Add next: economic buyer On-file fit: CT-A1C4B3, Chief People Officer, economic buyer 4) Deal-D0D6B5 (C-32918E) — UNDER-THREADED (3 active but ALL one persona) Amount: not provided. Stage: not provided. Active contacts: 3 (CT-87CED4, CT-DE6D7C, CT-FD70B2) Personas present: champion only Personas missing: economic buyer, HR admin, IT security, finance Add next: economic buyer On-file fit: CT-1FA4DB, Chief People Officer, economic buyer 5) Deal-5BFE3B (C-535D36) — UNDER-THREADED (2 active < 3, and all one persona) Amount: not provided. Stage: not provided. Active contacts: 2 (CT-57123B, CT-5CE757) Personas present: champion only Personas missing: economic buyer, HR admin, IT security, finance Add next: economic buyer On-file fit: none on file 6) Deal-36C33F (C-077A0E) — SINGLE-THREADED Amount: not provided. Stage: not provided. Active contacts: 1 (CT-4FE556; champion CT-405B45 and economic buyer CT-86B22F both marked former) Personas present: IT security Personas missing: economic buyer, champion, HR admin, finance Add next: economic buyer (champion also lost — both departed; buyer gap is the higher-value fix) On-file fit: CT-1DB73E, Chief People Officer, economic buyer 7) Deal-885F45 (C-5E8EFB) — UNDER-THREADED (2 active < 3) Amount: not provided. Stage: not provided. Active contacts: 2 (CT-51C81E, CT-D9A0E8) Personas present: economic buyer, champion Personas missing: HR admin, IT security, finance Add next: IT security (buyer + champion covered; security is the typical late-stage blocker — call made without stage data) On-file fit: CT-B3F25D, IT Security Lead, IT security 8) Deal-FCBE5B (C-737030) — SINGLE-THREADED Amount: not provided. Stage: not provided. Active contacts: 1 (CT-4A5317) Personas present: champion Personas missing: economic buyer, HR admin, IT security, finance Add next: economic buyer On-file fit: none on file 9) Deal-5408B0 (C-2AE3AA) — UNDER-THREADED (2 active < 3) Amount: not provided. Stage: not provided. Active contacts: 2 (CT-D33AE4, CT-8742FD) Personas present: champion, HR admin Personas missing: economic buyer, IT security, finance Add next: economic buyer On-file fit: CT-07FA76, Chief People Officer, economic buyer 10) Deal-C6D97A (C-5A8FC2) — UNDER-THREADED (3 active but ALL one persona) Amount: not provided. Stage: not provided. Active contacts: 3 (CT-223DDC, CT-B03555, CT-4E8A2B) Personas present: champion only Personas missing: economic buyer, HR admin, IT security, finance Add next: economic buyer On-file fit: none on file 11) Deal-F9A08A (C-0D15DF) — SINGLE-THREADED Amount: not provided. Stage: not provided. Active contacts: 1 (CT-931B10; economic buyer CT-913581 stale at 78 days, not former) Personas present: champion Personas missing: economic buyer, HR admin, IT security, finance Add next: economic buyer (re-engage stale CT-913581 or work the on-file contact) On-file fit: CT-697541, Chief People Officer, economic buyer NOT FLAGGED (healthy threading) - Deal-84DBA6 (C-BE9BE0): 3 active, 3 personas (champion, economic buyer, IT security) - Deal-4B0BEB (C-1BDFE0): 4 active, 4 personas (champion, economic buyer, HR admin, finance) - Deal-D348E1 (C-804F29): 5 active, all 5 personas Note: unengaged contacts CT-2A0169 (C-BE9BE0, finance) and CT-8E04F5 (C-804F29, HR admin) belong to the three non-flagged deals, so no action was assigned to them. If you can supply the deals file with amount/stage, I'll re-rank the "add next" picks by stage.
ANALYSIS — Alex Franklin, 10 calls (TT-001 through TT-010, 2026-07-28 to 2026-09-03)
1) OPENING (FIRST FIVE MINUTES)
8 of 10 calls (TT-001, TT-002, TT-003, TT-005, TT-006, TT-007, TT-008, TT-010) open at minute 0 with the same proof-point 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."
Arithmetic: 8/10 = 80%. The two exceptions tailor to prior context: TT-004 ("I put together a short agenda — security review first, then pricing.") and TT-009 ("You asked for straight pricing last time, so let's start there.").
2) THREE MOST COMMON OBJECTIONS AND HANDLING
a. Budget locked — 4 calls (TT-001, TT-003, TT-006, TT-010). Handled by reframing to turnover-savings funding:
"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."
b. Timing / revisit next quarter — 3 calls (TT-002, TT-005, TT-008). Handled with a scoped pilot:
"Makes sense. What if we scope a 90-day pilot with one department so you have internal data before next quarter's planning?"
c. Status quo (spreadsheet + gift cards) — 3 calls (TT-004, TT-007, TT-009). Handled with automation/analytics contrast:
"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."
Note: a 4th objection type, committee deferral (2 calls: TT-004, TT-010), gets no counter — "Understood — I'll leave it with you."
3) CONCRETE NEXT-STEP AGREEMENT RATE
Agreed: TT-001, TT-002, TT-003, TT-005, TT-006, TT-008, TT-009 (7 calls) — each closes with "Yes, Thursday at 2pm works — send the invite and I'll bring our HRIS manager."
Not agreed: TT-004 (no ask made), TT-007 ("I need to think about it — there's no urgency on our side." → "Fair enough."), TT-010 ("We'll have to wait for the committee — I can't commit to anything today." → "Understood, thanks for the candor.").
Arithmetic: 7/10 = 70%.
4) COMPETITORS 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 was named only by the rep (TT-005), not raised by a prospect, so it is excluded.
COACHING NOTES
1. Committee/urgency stalls end in retreat, not a bridge: in TT-007 and TT-010 the rep concedes ("Fair enough." / "Understood, thanks for the candor.") without proposing even a lightweight next step, costing 2 of the 3 lost commitments — coach a fallback ask (e.g., the same 90-day pilot or a dated follow-up with the committee) for deferral objections.
2. The opener and the booked-meeting language are word-for-word identical across 8 calls — the retailer case study clearly converts (70% next-step rate), so keep it, but have Alex vary the entry on calls with prior context the way he did in TT-004 and TT-009 to avoid sounding scripted.
Q3 2026 FORECAST (quarter: 2026-07-01 to 2026-09-30) Extract: 86 open deals, close dates 2026-07-01 to 2026-10-15, pulled 2026-09-05. In-quarter deals: 54 of 86. Excluded as outside the quarter: 32 (all close 2026-10-01 to 2026-10-15; none pre-July since the earliest close date in the file is 2026-08-28). COMMIT — 7 deals, total $44,729.00 Deal-547B2B 11,200.00 Deal-B7EBD1 9,000.00 Deal-403845 9,000.00 Deal-A2B47C 6,360.00 Deal-2465CE 5,400.00 Deal-A5E80A 2,520.00 Deal-499BF6 1,249.00 11,200 + 9,000 + 9,000 + 6,360 + 5,400 + 2,520 + 1,249 = 44,729 BEST_CASE — 24 deals, total $203,565.00 (38,935 + 24,000 + 19,656 + 16,250 + 11,116 + 10,800 + 10,500 + 9,890 + 9,720 + 9,000 + 7,200 + 3,840 + 3,780 + 3,600 + 3,240 + 3,150 + 3,120 + 3,060 + 2,916 + 2,760 + 2,484 + 2,100 + 1,920 + 528 = 203,565) PIPELINE — 23 deals, $201,637.40 (counts $0.00 toward the forecast per the weighting rule) Weighted forecast arithmetic: COMMIT: 100% × 44,729.00 = 44,729.00 BEST_CASE: 35% × 203,565.00 = 71,247.75 PIPELINE: 0% × 201,637.40 = 0.00 -------------------------------------------- WEIGHTED FORECAST = 115,976.75 Deal counts in quarter by category: COMMIT 7, BEST_CASE 24, PIPELINE 23 (total 54). Excluded for being outside the quarter: 32 deals, total $227,575.00 (COMMIT 1 = Deal-D348E1 13,770; BEST_CASE 9 = 27,340; PIPELINE 22 = 186,465. All close 2026-10-01 or later.) Top 5 BEST_CASE deals by amount, in quarter: 1. Deal-2D7423 38,935 (DS3, 2026-09-30) 2. Deal-25F752 24,000 (DS4, 2026-09-25) 3. Deal-E53952 19,656 (DS4, 2026-09-30) 4. Deal-5EED42 16,250 (DS3, 2026-09-30) 5. Deal-FA32A0 11,116 (DS3, 2026-09-25) ## Data quality Forecast category contradicts stage: DS5 (contract) deal Deal-C61CF7 is labeled BEST_CASE, while Deal-A5E80A (DS1) and Deal-499BF6 (DS2) are labeled COMMIT, so the category field driving the weights is not trustworthy. Owner is blank on 85 of 86 deals (only Deal-C9C286 has one: Bryce Harmon), making rep-level accountability and validation impossible. why_buys_chars is 0 on 71 of 86 rows, meaning most deals — including $44,729 of COMMIT — carry no buying rationale, so commitments cannot be substantiated. The extract contains no close dates before 2026-08-28 despite covering July 1 onward, suggesting the pull window or data is truncated, and Deal-42326B's non-integer amount (2,480.40) hints at inconsistent amount handling.
ACTIVATION HYPOTHESIS TEST — 2x2 COHORT REPORT Source: plg_company_cohort_2023.csv (220 companies, signup months 2023-01 through 2023-07) Rule applied: current_status = 'active' = retained at 24 months; 'cancelled' and 'non_renewing' = not retained. Signals: GIVERS = m1_users >= 5; REDEEM = m1_redemptions >= 1. FULL 2x2 Both signals (GIVERS + REDEEM): 47 companies, 31 active Retention = 31/47 = 66.0% Givers-only (GIVERS, no redemption): 49 companies, 23 active Retention = 23/49 = 46.9% Redemption-only (REDEEM, m1_users < 5): 29 companies, 9 active Retention = 9/29 = 31.0% Neither signal: 95 companies, 38 active Retention = 38/95 = 40.0% Check: 47 + 49 + 29 + 95 = 220 rows in file. Status mix: 101 active, 116 cancelled, 3 non_renewing (the 3 non_renewing — C-0B2078FB, C-0A96134F, C-0BEAF685 — fall in neither/redemption-only cells and count as not retained). EXCLUSIONS Zero companies excluded from the denominator. All 220 rows have populated m1_users, m1_redemptions, and current_status, and every signup month (2023-01 to 2023-07) is 25+ months old at the 2026-09 reference point (youngest cohort is 38 months old), so all are eligible for a 24-month readout. No imputation or dropping was needed. LARGEST SINGLE-SIGNAL LIFT 5+ unique givers in month 1. Givers-only companies retain at 46.9% vs 40.0% for neither = +6.9pp lift. Redemption-only actually retentions 9.0pp WORSE than neither (31.0% vs 40.0%). Looking at it as any-vs-no exposure confirms the same ranking: having the givers signal (both + givers-only = 96 cos, 54 retained, 56.3%) vs not having it (124 cos, 47 retained, 37.9%) = +18.3pp, versus the redemption signal's +10.3pp (52.6% with vs 42.4% without). DOES THE DATA SUPPORT THE HYPOTHESIS? Partially. Both-signals companies retain best (66.0%), beating givers-only (+19.1pp), neither (+26.0pp), and redemption-only (+35.0pp). But the ordering is not the hypothesized monotone "both > one signal > neither": redemption-only (31.0%) retentions BELOW neither (40.0%), so "one signal" is not uniformly better than none. The combination is where the strength is — neither single signal alone reproduces it. WHAT THIS PROVES Only observed association in this 2023 cohort: companies that hit both thresholds in month 1 had materially higher 24-month survival, and the givers signal is the stronger single predictor of the two. WHAT THIS DOES NOT PROVE 1. No causation. There is no randomized assignment; it is equally plausible that healthier, better-deployed companies were simply more likely to reach 5+ givers and a redemption (selection, not mechanism). 2. Confounders are visible in the data itself: cell composition differs by tier (e.g., givers-only is 25/49 tier_two vs 23/49 tier_three; neither is 49/95 tier_two) and tier is itself strongly associated with retention, so signal exposure is entangled with tier/ARR. Industry and country mixes also differ across cells. 3. It does not prove that pushing a low-engagement company to 5 givers or a first redemption will improve its retention. 4. Small cells (redemption-only n=29, 3 non_renewing total) mean the rates carry wide uncertainty; no significance testing was possible or performed here. 5. "Retained" is proxied by current_status='active' as instructed; non_renewing is treated as churn, which may understate eventual renewals.
ARR RECONCILIATION — CRM (company_arr.csv) vs BILLING (chargebee_subscriptions.csv), as of 2026-09-05
Billing ARR = MRR × 12, computed per subscription.
TOTALS
Billing ARR, all 39 subscriptions: 617,897.76
of which active (37 subs): 604,739.28
of which cancelled (2 subs): 13,158.48 (SUB-000E 4,905.24 + SUB-000F 8,253.24)
CRM ARR (39 company records): 603,581.76
Reconciliation basis: CRM vs ACTIVE billing ARR (cancelled subs are not ARR).
Variance = 603,581.76 − 604,739.28 = −1,157.52 (CRM below active billing)
DECOMPOSITION (sums exactly to −1,157.52)
1) Status mismatch ......................... +13,158.48
Cancelled in billing but CRM still carries full ARR:
- C-0C8323BF (SUB-000E, cancelled): CRM 4,905.24 vs 0 active billing (408.77 × 12 = 4,905.24)
- C-0DC4FB8C (SUB-000F, cancelled): CRM 8,253.24 vs 0 active billing (687.77 × 12 = 8,253.24)
2) Rounding ................................ +36.00
- C-0D66DF9E (SUB-0005): CRM 23,200.00 vs 1,932.00 × 12 = 23,184.00 → +16.00
- C-14D70CE0 (SUB-0008): CRM 18,200.00 vs 1,515.00 × 12 = 18,180.00 → +20.00
CRM values are round-number entries slightly above exact MRR×12.
3) Missing records ......................... −11,952.00
- Billing-only: SUB-0004 / C-21629AA4, active, 2,370.77 × 12 = 28,449.24 — no CRM company record → −28,449.24
- CRM-only: C-0D5BBE3A, CRM ARR 16,497.24 — no subscription of any status in billing → +16,497.24
Net: 16,497.24 − 28,449.24 = −11,952.00
4) Other ................................... −2,400.00
- C-0F7269D7 (SUB-0006): CRM 24,396.00 vs 2,233.00 × 12 = 26,796.00 → −2,400.00
(equivalent to a 200.00/mo gap — likely a discount or stale CRM price; not rounding, not status)
Check: 13,158.48 + 36.00 − 11,952.00 − 2,400.00 = −1,157.52 ✓
All other 33 matched active accounts reconcile exactly (e.g., C-0BC46AD9: 1,436.77 × 12 = 17,241.24 = CRM; C-0FC4DBB8: 777.77 × 12 = 9,333.24 = CRM).
MISMATCHED ACCOUNTS WITH SUGGESTED OWNER
No owner/rep field exists in either file, so owners are suggested functional roles, not names:
C-0C8323BF +4,905.24 stale ARR → RevOps (zero out CRM ARR for churned sub)
C-0DC4FB8C +8,253.24 stale ARR → RevOps (zero out CRM ARR for churned sub)
C-0D66DF9E +16.00 rounding → RevOps (data hygiene, low priority)
C-14D70CE0 +20.00 rounding → RevOps (data hygiene, low priority)
C-0F7269D7 −2,400.00 price gap → Billing Ops + account's sales owner (verify discount vs stale price)
C-21629AA4 −28,449.24 no CRM rec → Sales Ops (create CRM company record for live subscription)
C-0D5BBE3A +16,497.24 no sub → Billing Ops (locate/create subscription or confirm CRM record is stale)
BUSINESS RULE: term ≠ 12 months requires cf_agreement_end_date populated
SUB-0002 C-1794A52C term 24 end date blank → VIOLATION
SUB-0019 C-22170CA1 term 36 end date blank → VIOLATION
SUB-000C C-0DB48281 term 24 end date 2027-11-30 → compliant
SUB-001A C-0FC4DBB8 term 36 end date 2027-11-30 → compliant
DATA CAVEATS
- Neither file contains account owner names, so "suggested owner" is by role only.
- No start/end or as-of fields exist beyond cf_agreement_end_date; snapshot treated as 2026-09-05 per instruction.
- SUB-000C's 24-month term with end date 2027-11-30 is consistent with a ~Dec 2025 start, but start dates are not in the data, so this is not asserted as fact.
Four KVMs, 2026-08 vs 2026-07 (simple mean across the 30 companies present each month; no user-count weights provided, so unweighted means are all the data supports): - Giving rate: (sum 18.0689→18.0814)/30 = 0.60230→0.60271; +0.00042 = +0.07%, up. - Redemptions per user: (51.8995→51.9049)/30 = 1.72998→1.73016; +0.00018 = +0.01%, up. - 1:1 meetings engagement: (13.4066→13.4153)/30 = 0.44689→0.44718; +0.00029 = +0.06%, up. - Pulse check engagement: (18.0176→15.2583)/30 = 0.60059→0.50861; −0.09198 = −15.31%, down. Largest relative move: pulse check engagement (−15.31%). The data supports the driver: size_band = enterprise, where all 10 companies collapsed ~50% (segment mean 0.5500→0.2743, −50.13%), e.g. C-0D0B047C 0.5398→0.2619. smb (−0.22%) and mid_market (+0.21%) were flat. plan_tier cannot segment anything — every row is tier_three. KVM Jul Aug Abs chg Rel chg Dir Giving rate 0.60230 0.60271 +0.00042 +0.07% Up Redemptions per user 1.72998 1.73016 +0.00018 +0.01% Up 1:1 meetings engagement 0.44689 0.44718 +0.00029 +0.06% Up Pulse check engagement 0.60059 0.50861 −0.09198 −15.31% Down Note: the enterprise pulse collapse looks like a data-quality/measurement event, not organic churn — flag before acting.
REDEMPTION SECTION — WEEKLY REWARDS REPORT Reporting window: 2026-01 through 2026-08. Last completed month: 2026-08 (data spans 2026-01 to 2026-08; no rows beyond 2026-08). Core metrics - Redemption count: 378 - Spend: $27,846.00 - Unique redeemers (distinct user_key): 235 - Redemptions per redeemer: 378 / 235 = 1.61 Arithmetic check: sum of all 378 amount_usd values = $27,846.00; average redemption = $27,846 / 378 = $73.67. No duplicate redemption_id values found (0 dupes). Provider mix (percent of spend; shares rounded to 1 decimal via largest-remainder so they sum to exactly 100.0) - custom: $10,873.00 / $27,846.00 = 39.05% → 39.1% - Tremendous: $8,505.00 / $27,846.00 = 30.54% → 30.5% - Snappy: $5,238.00 / $27,846.00 = 18.81% → 18.8% - TangoCard: $3,230.00 / $27,846.00 = 11.60% → 11.6% - Sum: 39.1 + 30.5 + 18.8 + 11.6 = 100.0% ✓ (Spend cross-check: 10,873 + 8,505 + 5,238 + 3,230 = $27,846. By count: custom 37, Tremendous 192, Snappy 59, TangoCard 90; total 378.) Top 5 countries by redemption count 1. US — 244 ($18,547.00) 2. CA — 24 ($2,286.00) 3. AU — 21 ($1,606.00) 4. GB — 17 ($944.00) [tied] 4. NL — 17 ($1,122.00) [tied] Note: GB and NL are tied at 17 redemptions each for 4th/5th; both are shown. Next country is SG at 12, so the tie does not displace any country from the top 5. No data was missing; all 378 rows had complete provider, amount, country, and timestamp fields.
Eligibility check applied to all 30 rows. Rules are conjunctive — an account qualifies only if it passes R1 AND R2 AND R3. Rule arithmetic - R1: health_score < 60 - R2: churn_save_eligible_amount > 0 - R3: renewal_date within 120 days of snapshot 2026-09-05 → cutoff = 2026-09-05 + 120d = 2027-01-03 One transparency note: the files document only eligibility rules, not a play-assignment rubric. The play mapping below is my analyst judgment from the signals in the data (usage_trend_3m, seat utilization = seats_used/seats, champion_active, renewal proximity), and I cite the driving signal per account. QUALIFIED ACCOUNTS — 8 (all pass R1+R2+R3) 1) C-0F6C0F34 — $49,707 at stake R1: 51<60 ✓ R2: 49,707>0 ✓ R3: 2026-10-03 is 28d out ✓ Play: EXECUTIVE TOUCH. Signal: usage_trend_3m=growing, 78.0% utilization (308/395), yet champion_active=false — adoption is healthy, so the risk is the relationship, not the product. Also the largest amount and 28 days to renewal. 2) C-0B827671 — $25,365 R1: 56<60 ✓ R2: ✓ R3: 2026-11-14 = 70d ✓ Play: USAGE REVIVAL. Signal: usage_trend_3m=declining, 55.9% utilization (113/202), champion active — the champion exists; usage is the problem. 3) C-0B360C78 — $35,748 R1: 57<60 ✓ R2: ✓ R3: 2026-10-28 = 53d ✓ Play: COMMERCIAL CONCESSION. Signal: usage growing, 75.2% utilization (246/327), champion active — no adoption gap and no relationship gap, so the sub-60 health with a 53-day renewal points to terms/value, not usage. 4) C-0B0F1BAB — $5,494 R1: 38<60 ✓ R2: ✓ R3: 2026-09-23 = 18d ✓ Play: EXECUTIVE TOUCH. Signal: champion_active=false plus the lowest health score in the file (38) and the nearest renewal (18d). Flat usage/65.6% utilization are secondary; the missing champion is the actionable gap. 5) C-0CA21961 — $16,829 R1: 58<60 ✓ R2: ✓ R3: 2026-12-28 = 114d ✓ Play: USAGE REVIVAL. Signal: lowest utilization among qualifiers — 84 of 325 seats used (25.8%) on a flat trend. Champion is active, so drive adoption through them. 6) C-0E9C27D1 — $41,235 R1: 39<60 ✓ R2: ✓ R3: 2026-09-24 = 19d ✓ Play: COMMERCIAL CONCESSION. Signal: health 39 with renewal in 19 days despite strong usage (85.4%, 134/157) and an active champion — adoption and relationship are both fine, so the objection is almost certainly commercial, and time only allows a terms move. 7) C-0CEF69FD — $32,621 R1: 53<60 ✓ R2: ✓ R3: 2026-11-21 = 77d ✓ Play: EXECUTIVE TOUCH. Signal: champion_active=false while usage_trend_3m=growing at 71.3% utilization (97/136) — same pattern as C-0F6C0F34: product is being used, advocate is gone. 8) C-0D3278C7 — $17,602 R1: 54<60 ✓ R2: ✓ R3: 2026-11-12 = 68d ✓ Play: USAGE REVIVAL. Signal: usage_trend_3m=declining with 33.2% utilization (126/380) — the largest unused-seat base of any qualifier. Champion active, so a revival plan has an internal sponsor. AMOUNT AT STAKE Per account: 49,707 + 25,365 + 35,748 + 5,494 + 16,829 + 41,235 + 32,621 + 17,602 = 224,601 TOTAL: $224,601 By play: - Executive touch: 49,707 + 5,494 + 32,621 = $87,822 (3 accounts) - Commercial concession: 35,748 + 41,235 = $76,983 (2 accounts) - Usage revival: 25,365 + 16,829 + 17,602 = $59,796 (3 accounts) Check: 87,822 + 76,983 + 59,796 = 224,601 ✓ AT RISK BUT NOT ELIGIBLE (health < 60, failing at least one rule) - C-0BC71BDD (hs 55) — fails R2: eligible amount = 0.00. Renewal 52d out would have passed R3. - C-0BA71F12 (hs 52) — fails R3: renewal 2027-04-11 is 218d out (> 120). Amount $6,824 was positive (R2 passed). - C-0F6694C3 (hs 43) — fails R2 (amount = 0.00) and R3 (2027-03-21 = 197d). - C-0BE96399 (hs 54) — fails R2: amount = 0.00. Declining usage and 27.9% utilization look bad, but no eligible dollars. - C-0F876796 (hs 47) — fails R3: 2027-02-06 is 154d out. Amount $19,958 was positive (R2 passed). - C-0FCCD2DF (hs 43) — fails R2 (amount = 0.00) and R3 (2027-04-23 = 230d). - C-10A56B0F (hs 54) — fails R2: amount = 0.00. Renewal 98d out passed R3. Remaining 15 accounts have health ≥ 60 (fail R1), so they are not at risk under the documented rules and were not evaluated further. Nothing was excluded or invented; all 30 rows accounted for.
EXPANSION KIT — C-0DDFC9A7 1) SEAT COVERAGE Licensed seats ÷ headcount = 150 ÷ 400 = 37.5% of headcount is licensed. 2) USAGE HEALTH (two lines) - MAU grew from 88 (2026-03) to 126 (2026-08): +38 users, +43.2% over the window, with steady month-over-month gains of +7, +7, +8, +8, +8 (~7.4% compound/month). - Active users are now 126 ÷ 150 = 84% of licensed seats; at ~7.6 net new users/month, the remaining licensed seats exhaust in ~3 months (24 ÷ 7.6 ≈ 3.2). 3) HEADROOM AT CURRENT PER-SEAT RATE Per-seat rate: $9,000.00 ARR ÷ 150 seats = $60/seat/year. Seat headroom: 150 − 126 = 24 licensed seats unused. ARR headroom at current rate: 24 × $60 = $1,440/year. (Context only, not counted above: 250 of 400 employees hold no license; at $60/seat that potential is $15,000/year, but there is no usage data for them, so I'm not treating it as pipeline.) 4) WHO REPLIED / CAN THEY BUY Maria S., People Operations Coordinator (last engaged 2026-09-02). She cannot buy — she states budget and seat expansion sit with Dana R., VP People, and offers to introduce. 5) RIGHT BUYER FROM CONTACTS Dana R., VP People (last engaged 2026-05-18). Maria notes Dana has been asking about usage numbers — warm signal. 6) REPLY EMAIL (~125 words) Subject: RE: Growing your team's recognition program Hi Maria, Thanks for the quick reply — glad the team's enjoying Bonusly, and the numbers back you up: monthly active users have grown from 88 in March to 126 in August, which puts you at about 84% of your 150 licensed seats. At the current pace you'd use up the remaining seats in roughly three months. I'd genuinely appreciate the introduction to Dana. To make it easy, I can put together a one-page usage summary — active-user trend and seat coverage versus headcount — that you can forward to her directly. No rush; just let me know if the intro works and I'll send it over. Best, Cole Ingram
CSM PREP — MID-ONBOARDING CALL Account: C-0D284E42 | Signup: 2026-08-11 | Data through: 2026-09-04 (day 25 of onboarding) COMPLETE (each backed by a data field) 1. Slack integration connected — 2026-08-12 (day 2; field integration_slack populated) 2. Allowance set — 2026-08-13 (day 3; field allowance_set populated) 3. Admins added — 2 (field admins_added = 2; note: file gives a count, not a date) 4. First recognition given — 2026-08-15 14:22 (day 5; field first_recognition_at populated) NOT COMPLETE 1. HRIS integration — integration_hris is blank; never connected per the data 2. First redemption — first_redemption_at is blank; no redemption has occurred despite allowance set on day 3 and recognitions flowing since day 5 EARLY ENGAGEMENT SIGNALS (from onboarding_usage.csv, 25 daily rows) - Active givers grew 3 → 15: +12, a 5.0x increase (15 / 3 = 5.0) over 25 days - No zero-usage days; the trend is up-and-to-the-right with only minor dips (e.g., 5→4 on 08-16, 13→11 on 08-31) - Trailing-7-day average is ~3x the first week: First 7 days (08-11→08-17): 3+3+4+4+5+4+7 = 30; 30/7 ≈ 4.3 Last 7 days (08-29→09-04): 11+13+11+13+13+15+15 = 91; 91/7 = 13.0 - Sustained adoption: 10 of 25 days had ≥10 active givers, all of them since 08-26 - Signal read: healthy, accelerating adoption. Caveat: no total-employee-count field exists in the data, so penetration/activation rate cannot be computed — do not quote one on the call. THREE THINGS TO COVER ON THE CALL 1. Close the HRIS gap — it is the only unconnected integration. Get a connection date/owner on the call; this is the biggest structural hole in their setup. 2. Drive the first redemption — allowance exists and recognitions have been happening for 20 days, yet first_redemption_at is still blank. Walk admins through how redemptions work and set a target date for the first one. 3. Convert momentum into breadth — active givers are at 15 and rising ~3x week-over-week. Ask the 2 admins how many more users they plan to invite and what recognition behaviors they want to reinforce, so growth continues past the early-adopter core. (Frame as a question — the data has no headcount, so we don't know how much room is left.)
90-DAY RENEWAL RISK BRIEF Window: 2026-09-06 through 2026-12-05 (90 days). All 20 accounts renew inside it. SOURCE-OF-TRUTH DECISION (per account) ChurnZero is known-wrong on multi-year contracts, and Chargebee is the billing system of record, so: for every account where the two systems disagree, I use Chargebee's date. That is exactly the 5 multi-year accounts (is_multi_year=true in chargebee_terms.csv); all 5 show CZ/CB date conflicts, and all 15 annual (12-month) accounts agree perfectly between the two systems — a clean confirmation that the disagreement is confined to multi-year records, as expected. Where dates agree, the date is used as-is from both systems. FLAGGED DISAGREEMENTS (5 of 20 accounts) 1. C-0B7D2C30 — CZ 2026-09-10 vs CB 2026-09-15 (36-month term) → use Chargebee 2026-09-15 2. C-0BCDB8C2 — CZ 2027-09-18 vs CB 2026-09-18 (36-month term) → use Chargebee 2026-09-18 (CZ appears to show end-of-contract, not a renewal checkpoint) 3. C-0D2AB865 — CZ 2026-09-10 vs CB 2026-09-22 (24-month term) → use Chargebee 2026-09-22 4. C-0BBE3E60 — CZ 2027-09-26 vs CB 2026-09-26 (24-month term) → use Chargebee 2026-09-26 5. C-0F5D2323 — CZ 2026-09-10 vs CB 2026-09-29 (24-month term) → use Chargebee 2026-09-29 Note: ChurnZero shows 2026-09-10 for three of these and a +1-year date for two — inconsistent failure modes, further evidence CZ multi-year dates are unreliable. RISK RUBRIC (applied uniformly, shown so you can audit it) Utilization = seats_used / seats. 3-month trend = Aug 2026 vs Jun 2026 active_users. HIGH: utilization < 35% OR 3-month usage decline of 10%+ MEDIUM: utilization < 70% (and no HIGH trigger) LOW: utilization >= 70% HIGH RISK — 6 accounts, $359,409 ARR 1) C-0B7D2C30 — Dana Mercer — $65,901 — renewal 2026-09-15 (Chargebee; disagreement flagged above) Utilization: 274/476 = 57.6%. 3-mo trend: Jun 97 → Jul 94 → Aug 84 = -13.4% (12-mo: 155→84, -45.8%). Evidence: Steepest sustained decline in the book — 12 straight months of falling usage, now down 46% year-over-year, and renewal lands in 9 days. 2) C-0BCDB8C2 — Cole Ingram — $54,427 — renewal 2026-09-18 (Chargebee; disagreement flagged above) Utilization: 232/424 = 54.7%. 3-mo trend: Jun 127 → Jul 118 → Aug 110 = -13.4% (12-mo: 200→110, -45.0%). Evidence: Mirror-image of C-0B7D2C30 — unbroken 12-month usage slide, -45% YoY, and the renewal decision point is 12 days out. 3) C-0D2AB865 — Elena Sinclair — $38,022 — renewal 2026-09-22 (Chargebee; disagreement flagged above) Utilization: 250/407 = 61.4%. 3-mo trend: Jun 125 → Jul 117 → Aug 109 = -12.8% (12-mo: 199→109, -45.2%). Evidence: Same monotonic 12-month decay pattern as the other two September multi-year accounts, -45% YoY with no stabilization signal. 4) C-0BBE3E60 — Dana Mercer — $30,993 — renewal 2026-09-26 (Chargebee; disagreement flagged above) Utilization: 74/114 = 64.9%. 3-mo trend: Jun 39 → Jul 35 → Aug 33 = -15.4% (12-mo: 63→33, -47.6%). Evidence: Worst usage decline in the portfolio — active users nearly halved in 12 months and still falling -15.4% in the last quarter alone. 5) C-0F5D2323 — Cole Ingram — $90,647 — renewal 2026-09-29 (Chargebee; disagreement flagged above) Utilization: 111/390 = 28.5%. 3-mo trend: Jun 20 → Jul 21 → Aug 18 = -10.0% (12-mo: 21→18, -14.3%). Evidence: The largest-dollar September renewal and the worst seat utilization in the book at 28.5% — only 18 active users against 390 seats; the product is effectively unused at this account. 6) C-0EC6999D — Elena Sinclair — $79,419 — renewal 2026-10-03 (CZ and CB agree) Utilization: 31/112 = 27.7%. 3-mo trend: Jun 17 → Jul 16 → Aug 15 = -11.8% (12-mo: flat 15→15). Evidence: Lowest utilization of all 20 accounts (27.7%) on a $79k contract with usage drifting lower all year and only ~15 people touching the product. MEDIUM RISK — 5 accounts, $189,929 ARR 7) C-0B20DB64 — Dana Mercer — $21,770 — renewal 2026-10-07 (CZ and CB agree) Utilization: 214/378 = 56.6%. 3-mo trend: Jun 294 → Jul 298 → Aug 294 = 0.0% (12-mo flat ~293-298). Evidence: Usage is rock-stable and actually exceeds seats_used (MAU 294 > 214), but nearly half of purchased seats are unfilled — a right-sizing/shrinkage exposure rather than a churn signal. 8) C-0BBC4E7A — Cole Ingram — $56,374 — renewal 2026-10-10 (CZ and CB agree) Utilization: 228/337 = 67.7%. 3-mo trend: Jun 142 → Jul 141 → Aug 139 = -2.1% (12-mo: -2.1%). Evidence: Flat usage just under the 70% utilization line — no alarm, but no expansion headroom either; a quiet, manageable renewal. 9) C-0FD551AB — Elena Sinclair — $48,815 — renewal 2026-10-14 (CZ and CB agree) Utilization: 210/376 = 55.9%. 3-mo trend: Jun 123 → Jul 122 → Aug 126 = +2.4% (12-mo: +1.6%). Evidence: Healthy but low utilization — only 56% of seats in use — though usage ticked up in August, so the risk is contraction, not cancellation. 10) C-0F9F8F13 — Dana Mercer — $46,230 — renewal 2026-10-18 (CZ and CB agree) Utilization: 199/352 = 56.5%. 3-mo trend: Jun 185 → Jul 185 → Aug 182 = -1.6% (12-mo: flat). Evidence: Stable ~182-185 MAU against 352 seats — steady state with 43% of seats idle, making it a candidate for seat reduction at renewal. 11) C-0BC34584 — Cole Ingram — $16,740 — renewal 2026-10-22 (CZ and CB agree) Utilization: 327/494 = 66.2%. 3-mo trend: Jun 104 → Jul 104 → Aug 106 = +1.9% (12-mo: +2.9%). Evidence: Modest uptick in a flat account sitting just under 70% utilization; risk is limited to seat right-sizing on the smallest contract in the book. LOW RISK — 9 accounts, $499,377 ARR 12) C-0B7A7546 — Elena Sinclair — $35,062 — renewal 2026-10-25 (CZ and CB agree) Utilization: 182/205 = 88.8%. 3-mo trend: Jun 64 → Jul 65 → Aug 63 = -1.6% (12-mo: +8.6%). Evidence: Highest utilization in the portfolio at 88.8% with a mild uptrend — an expansion candidate, not a risk. 13) C-0B369871 — Dana Mercer — $85,128 — renewal 2026-10-29 (CZ and CB agree) Utilization: 317/422 = 75.1%. 3-mo trend: Jun 326 → Jul 330 → Aug 333 = +2.1% (12-mo: +15.2%). Evidence: Strong, compounding growth — active users up 15% YoY and already above seats_used (MAU 333 > 317), signaling expansion opportunity. 14) C-0B144C78 — Cole Ingram — $30,899 — renewal 2026-11-02 (CZ and CB agree) Utilization: 169/224 = 75.4%. 3-mo trend: Jun 101 → Jul 101 → Aug 106 = +5.0% (12-mo: +17.8%). Evidence: Steady climb from 90 to 106 users over the year with a 5% jump in the last quarter — healthy adoption, safe renewal. 15) C-0FC4DBB8 — Elena Sinclair — $94,732 — renewal 2026-11-05 (CZ and CB agree) Utilization: 356/464 = 76.7%. 3-mo trend: Jun 189 → Jul 191 → Aug 193 = +2.1% (12-mo: +14.9%). Evidence: The largest November contract is growing — 12 straight months of rising usage, up ~15% YoY. 16) C-0D5BBE3A — Dana Mercer — $39,740 — renewal 2026-11-09 (CZ and CB agree) Utilization: 85/102 = 83.3%. 3-mo trend: Jun 88 → Jul 90 → Aug 91 = +3.4% (12-mo: +19.7%). Evidence: 83% utilization, +20% YoY growth, and MAU (91) already above seats_used (85) — a strong upsell candidate. 17) C-0FB9D5AF — Cole Ingram — $63,158 — renewal 2026-11-13 (CZ and CB agree) Utilization: 144/199 = 72.4%. 3-mo trend: Jun 173 → Jul 173 → Aug 176 = +1.7% (12-mo: +14.3%). Evidence: Consistent upward trajectory with MAU (176) above seats_used (144) — adoption is outpacing the licensed count. 18) C-0B344485 — Elena Sinclair — $64,384 — renewal 2026-11-16 (CZ and CB agree) Utilization: 224/287 = 78.0%. 3-mo trend: Jun 238 → Jul 240 → Aug 244 = +2.5% (12-mo: +15.6%). Evidence: Unbroken 12-month growth from 211 to 244 users, MAU exceeding seats_used — expansion, not risk. 19) C-0CB2C1B4 — Dana Mercer — $40,628 — renewal 2026-11-20 (CZ and CB agree) Utilization: 386/473 = 81.6%. 3-mo trend: Jun 47 → Jul 48 → Aug 49 = +4.3% (12-mo: +14.0%). Evidence: High utilization and a gentle uptrend; one data caveat — MAU (49) is far below seats_used (386), so the seat figure may include non-monthly-active licenses, but nothing here signals churn. 20) C-22170CA1 — Cole Ingram — $45,646 — renewal 2026-11-24 (CZ and CB agree) Utilization: 251/294 = 85.4%. 3-mo trend: Jun 143 → Jul 148 → Aug 146 = +2.1% (12-mo: +12.3%). Evidence: Second-highest utilization in the book (85.4%) with solid year-long growth — safe renewal, possible expansion. DATA QUALITY CAVEATS (explicit, not invented) - seats_used vs MAU mismatch: in several accounts Aug MAU exceeds seats_used (e.g., C-0B20DB64 MAU 294 vs seats_used 214), while in others seats_used is a multiple of MAU (e.g., C-0F5D2323: 111 vs 18; C-0CB2C1B4: 386 vs 49). The two seat metrics are evidently defined differently across files; I used seats_used/seats for utilization as the seat-based measure the brief asked for, and MAU for trend. I did not reconcile them — that reconciliation data was not provided. - No company names were provided — accounts are cited by alias only, exactly as given. - No health scores, support tickets, or sponsor-change data were provided; risk ratings rest on utilization + usage trend only. TOTALS Total ARR renewing in 90 days (20 accounts): $1,048,715 HIGH risk: $359,409 (6 accounts — all renewing 2026-09-15 through 2026-10-03) MEDIUM risk: $189,929 (5 accounts) LOW risk: $499,377 (9 accounts) ARR at risk (HIGH + MEDIUM): $549,338 — 52.4% of the 90-day renewal book. Bottom line: every HIGH-risk renewal is a September/early-October multi-year or near-term account, and the six at-risk-high accounts cluster around CSMs Dana Mercer (2 of 4 of her accounts HIGH) and Cole Ingram/Elena Sinclair (one apiece plus the low-utilization C-0EC6999D). The four September multi-year decliners (C-0B7D2C30, C-0BCDB8C2, C-0D2AB865, C-0BBE3E60) share an identical 12-month decay signature and need intervention this week — the first one renews 2026-09-15, nine days out.
QUARTER SUPPORT TICKET SYNTHESIS (2026-06-01 → 2026-08-29)
Base: 80 tickets, 24 distinct accounts. Tags ignored — themes built from body_text only. Every ticket fit exactly one theme (20+18+16+12+14 = 80).
Why tags can't be trusted: 15 tickets carry the "billing" tag, but only 3 (IC-460070, IC-460065, IC-460079) are actually billing issues; the other 12 are points, Slack, HRIS, and redemption complaints. Tags were set aside entirely.
Ranked by ARR exposure (sum of distinct affected accounts' ARR), not volume:
────────────────────────────────────────────────
1. HRIS PROVISIONING FAILURES — broad pattern
Count: 12 / 80 = 15.0%
Distinct accounts: 3 (C-0DDFC9A7, C-0B2213A9, C-0F6C0F34)
ARR affected: $114,000 = 48,000 + 36,000 + 30,000
Example tickets: IC-460060, IC-460062
Note: hits your 3 largest accounts; "provisioning log shows no errors" indicates a silent failure, and new hires are going un-provisioned for a month+.
Recommendation: Escalate to engineering as a silent-failure P1 with repro traces from all three accounts and put an exec sponsor on each until new-hire creation is verified.
2. REDEMPTION / GIFT-CARD FAILURES — broad pattern
Count: 18 / 80 = 22.5%
Distinct accounts: 7 (C-0CEF69FD, C-0B827671, C-0FCCD2DF, C-0F876796, C-14264ABD, C-0D9CA315, C-0B0F1BAB)
ARR affected: $68,800 = 8,900 + 10,700 + 9,600 + 8,700 + 11,000 + 9,600 + 10,300
Example tickets: IC-460022, IC-460029
Note: checkout hangs, codes never delivered, and points deducted even when the order errored — a fulfillment atomicity problem.
Recommendation: Make redemption atomic (never deduct points unless the code is confirmed delivered) and proactively reissue or refund every failed order.
3. BILLING & INVOICE ERRORS — single-account noise (concentrated, high-stakes)
Count: 16 / 80 = 20.0%
Distinct accounts: 1 (C-0E9C27D1 — the largest single account in the book)
ARR affected: $52,000
Example tickets: IC-460069, IC-460078
Note: all 16 tickets span Jun 16–Aug 29 and describe the same unresolved dispute: billed 200 seats vs 150 licensed ("third invoice in a row") plus renewal charged at the wrong tier. Volume here is one customer re-reporting, not a systemic billing bug — but it is the quarter's biggest churn risk.
Recommendation: Assign a billing owner to correct seat count (150, not 200) and renewal tier, issue credits for the three disputed invoices, and close the loop before the renewal conversation.
4. POINTS DELIVERY FAILURES — broad pattern
Count: 20 / 80 = 25.0% (highest volume, lower ARR)
Distinct accounts: 9 (C-0D3278C7, C-0BF20542, C-0D0B047C, C-0BE96399, C-0D284E42, C-0D6CC8E3, C-21FEBCBB, C-0DD0626C, C-0B2895EF)
ARR affected: $31,100 = 3,500 + 4,500 + 4,500 + 2,700 + 3,400 + 4,200 + 2,900 + 2,500 + 2,900
Example tickets: IC-460016, IC-460004
Note: recognitions show "delivered" but points never post; balances stale for days to weeks. Widest account spread of any theme.
Recommendation: Audit the points-ledger posting pipeline for where items stall after "delivered" status, then backfill balances for all 9 accounts.
5. SLACK INTEGRATION FAILURES — broad pattern
Count: 14 / 80 = 17.5%
Distinct accounts: 4 (C-0B843542, C-10A56B0F, C-0BA71F12, C-8C2E8F00)
ARR affected: $18,900 = 4,400 + 5,400 + 3,900 + 5,200
Example tickets: IC-460049, IC-460048
Note: four symptoms (sync stopped, toggle resets itself, app disconnects and re-auth won't stick, slash command errors) point to one likely root cause: Slack OAuth token persistence.
Recommendation: Fix Slack token storage/renewal handling as a single workstream, then regression-test all four failure modes across the affected workspaces.
Summary of the broad-vs-noise split: themes 1, 2, 4, 5 are genuine multi-account product problems; theme 3 is one-account noise by ticket count but ranks #3 on ARR exposure because it is your largest account disputing three consecutive invoices. Total ARR touched by support this quarter: $284,800 (114,000 + 68,800 + 52,000 + 31,100 + 18,900) — every account in the dataset appears in exactly one theme, so no double counting.
Top 3 most similar customers with public case studies for prospect C-82AF3719 (Technology / Mid-Market / employee_recognition / NA-West): Scoring method: exact match per dimension, weighted in the order the criteria were given — industry=4, size_band=3, use_case=2, region=1, max 10. Only the 8 rows with has_case_study=true were considered. 1. C-64171065 — score 9/10 Matches: industry Technology (+4), size_band Mid-Market (+3), use_case employee_recognition (+2). Mismatch: region NA-East vs NA-West (+0). 9 = 4+3+2+0. Only customer with a case study matching 3 of 4 fields, including the exact use case. 2. C-A13C193D — score 8/10 Matches: industry Technology (+4), size_band Mid-Market (+3), region NA-West (+1). Mismatch: use_case retention (+0). 8 = 4+3+0+1. 3. C-CD4829A7 — score 7/10 Matches: industry Technology (+4), size_band Mid-Market (+3). Mismatches: use_case retention (+0), region NA-East (+0). 7 = 4+3+0+0. Runner-up for transparency: C-11C31562 (Manufacturing/Mid-Market/employee_recognition/NA-West) scores 6 = 0+3+2+1 — it matches use case and region but not industry, which carries the highest weight. Excluded despite any partial matches: all has_case_study=false rows (e.g., C-D6217CAA and C-C153868F, which would otherwise score highly) are ineligible per the case-study requirement. No billing data or contact names are present in or drawn from the provided files.
Channel performance — trailing 6 months (2026-03 through 2026-08; spend and contact data both span exactly this window, no rows fall outside it). PAID CHANNELS paid_search - Spend: 6 × $6,000 = $36,000 - SQMs: 40 | SQOs: 18 - Cost per SQM: $36,000 / 40 = $900.00 - Cost per SQO: $36,000 / 18 = $2,000.00 - SQM→SQO rate: 18 / 40 = 45.0% - Pipeline: 18 × $40,000 = $720,000 - Pipeline per dollar: $720,000 / $36,000 = $20.00 linkedin_ads - Spend: 6 × $4,000 = $24,000 - SQMs: 25 | SQOs: 8 - Cost per SQM: $24,000 / 25 = $960.00 - Cost per SQO: $24,000 / 8 = $3,000.00 - SQM→SQO rate: 8 / 25 = 32.0% - Pipeline: 8 × $12,000 = $96,000 - Pipeline per dollar: $96,000 / $24,000 = $4.00 paid_social - Spend: 6 × $3,000 = $18,000 - SQMs: 0 | SQOs: 0 | Pipeline: $0 - Cost per SQM: UNDEFINED (spend with zero SQMs — not reported as zero) - Cost per SQO: UNDEFINED - SQM→SQO rate: undefined (no denominator) - Pipeline per dollar: $0 / $18,000 = $0.00 webinars - Spend: 6 × $1,500 = $9,000 - SQMs: 12 | SQOs: 5 - Cost per SQM: $9,000 / 12 = $750.00 - Cost per SQO: $9,000 / 5 = $1,800.00 - SQM→SQO rate: 5 / 12 = 41.7% - Pipeline: 5 × $12,000 = $60,000 - Pipeline per dollar: $60,000 / $9,000 = $6.67 ORGANIC (no tracked spend; cost metrics not computable) organic_search - Volume: 30 SQMs | SQOs: 10 | SQO rate: 10 / 30 = 33.3% - Pipeline: 10 × $9,000 = $90,000 (referral also appears in the contact data with no spend: 15 SQMs, 6 SQOs, 40.0% rate, $48,000 pipeline — noted for completeness, outside the paid/organic split you defined.) DATA QUALITY FLAGS — SQO date precedes SQM date (2 rows, both linkedin_ads) - CT-000044: SQM 2026-07-23, SQO 2026-07-18 (5 days inverted) - CT-000041: SQM 2026-06-14, SQO 2026-06-09 (5 days inverted) These are counted in linkedin_ads totals as-is, but their stage-ordering is suspect (attribution/backdating issue). REALLOCATION RECOMMENDATION 1. Reallocate paid_social's $18,000 (21% of paid budget, zero SQMs over 6 months). Split it: - ~$12,000 to paid_search — best pipeline per dollar ($20/$1), best SQM→SQO rate (45%), and it drives $720,000 of the $1,014,000 total tracked pipeline (71%). - ~$6,000 to webinars — cheapest SQO ($1,800) and second-best pipeline per dollar ($6.67/$1); doubling its budget tests scalability at low risk. 2. Hold linkedin_ads flat pending a data-quality fix: its 2 of 8 SQOs have inverted SQO/SQM dates, so its true conversion rate and $3,000 cost per SQO are uncertain. Cut only if next quarter confirms sub-$4/$1 returns. 3. Protect organic_search and referral — free volume with 33–40% SQO rates; invest enablement (SEO content, referral program) rather than paid dollars. CONFIDENCE: LOW-to-MODERATE. SQO samples are small (paid_search 18, organic_search 10, linkedin_ads 8, referral 6, webinars 5), so cost-per-SQO estimates carry wide error; webinars' 5 SQOs is too thin to trust the $1,800 figure as a stable mean. Pipeline amounts are uniform per channel (fixed $40k/$12k/$9k/$8k per deal), so pipeline-per-dollar differences reflect SQO counts only, not real deal-size variance — and no win/revenue data is provided, so this optimizes for pipeline, not closed revenue. The paid_social zero is the highest-confidence finding (6 months, n=0); the ranking of paid_search on top is moderate confidence; the webinars vs. linkedin_ads ordering is low confidence.
# Battlecard: Rivally — updated 2026-09-05 ## Positioning (one line) Series C–funded ($40M, Northgate Ventures [S01]) points-based recognition platform [S02] aimed at mid-market buyers [S04], now pushing EU expansion with EU data residency and a Dublin office [S15][S11]. ## Pricing - Current list: Recognition Starter $7/user/month, annual billing required — pricing page, 2026-08-12 [S17] - Prior list: $5/user/month, annual — pricing page 2026-01-20 [S03]; still $5 on 2026-04-01 [S08] - Conflict: S03/S08 say $5; S17 says $7. Newer source wins → $7 is current. Increase is +$2/user/mo = (7−5)/5 = +40% between Apr and Aug 2026. - Field quotes (deal mentions, not list): $6.50/user/mo quoted to a 500-seat prospect, annual term [S13]; $7/user/mo list with 15% discount for 3-year term = 7.00 × 0.85 = $5.95/user/mo [S18]. - Rivally Pulse: priced as an add-on, not bundled [S23]. Add-on price is not stated anywhere in the data — unknown. ## Where we win - Analytics depth: 800-seat prospect picked Bonusly over Rivally citing analytics depth [S25]. Corroborated by third-party reviews: limited analytics [S02], dashboards basic vs enterprise tools [S07], analytics exports CSV-only [S20]. - Enterprise admin at scale: Rivally lacks SCIM provisioning; manual user management is painful [S10]; no bulk recognition editing [S24]; admin tooling lags peers [S16]. ## Where they win - EU / distributed teams: strong for distributed EU teams, multi-language praised [S12]; EU data residency GA plus Dublin office [S15]; actively pitching EU data residency in deals [S05]. - Speed and simplicity: mid-market setup under a week; Slack integration out of the box [S04]. - Support: response times under 4 hours praised [S22]. - Engagement UX: recognition feed called engaging [S02][S16]. ## Objections and responses 1. "Rivally is cheaper." List rose $5 → $7/user/mo [S03][S17]; they trade multi-year discounts (15% off for 3-year = $5.95 [S18]). Counter on analytics depth — the cited reason we won the 800-seat deal [S25]. 2. "They have EU data residency." True, GA as of 2026-07 [S15]. Counter: their EMEA rewards catalog is thinner than the US catalog [S14], and residency only went GA in July 2026 [S15]. 3. "Fast setup, easy to use." True at mid-market [S04]. Counter: admin tooling lags peers [S16], no bulk recognition editing [S24], no SCIM — manual user management gets painful as headcount grows [S10]. 4. "Their analytics are good enough." Reviewers disagree: limited analytics [S02], basic dashboards [S07], CSV-only exports that even made migrating off painful [S20]. 5. "They have a Microsoft Teams app." Teams app v2 is in public preview, not GA [S19]. ## Recent changes - 2026-08-12: Pricing raised, Recognition Starter $5 → $7/user/mo [S17] - 2026-08-20: Microsoft Teams app v2, public preview [S19] - 2026-09-01: Rivally Pulse exits beta; priced as add-on, not bundled [S23] (originally launched 2026-03-05 [S06]) - 2026-07-01: Dublin office opened; EU data residency GA [S15] - 2026-05-09: Hired ex-Workday VP EMEA to lead European expansion [S11] - Funding context: Series C, $40M, led by Northgate Ventures, 2025-11-04 [S01] ## 12-month win/loss vs Rivally (2025-09 → 2026-08, deals_with_competitor.csv) 20 deals, all tagged competitor=Rivally. - Wins (13): Deal-A9FD43, Deal-7AA785, Deal-44C524, Deal-0D0CD6, Deal-D5B790, Deal-5C636E, Deal-67BE14, Deal-1B6969, Deal-F03E7B, Deal-072E31, Deal-F65C8F, Deal-E46EAB, Deal-1D2392 - Losses (7): Deal-7767F5, Deal-5645A5, Deal-C6FFAA, Deal-D263E0, Deal-935746, Deal-9066A6, Deal-72A02F - Record: 13W–7L, win rate 13/20 = 65% By month (W-L): 2025-09: 1-1 · 2025-10: 2-0 · 2025-11: 1-1 · 2025-12: 1-1 · 2026-01: 2-0 · 2026-02: 2-0 · 2026-03: 1-1 · 2026-04: 0-2 · 2026-05: 0-1 · 2026-06: 1-0 · 2026-07: 1-0 · 2026-08: 1-0 Arithmetic check: wins 1+2+1+1+2+2+1+0+0+1+1+1 = 13; losses 1+0+1+1+0+0+1+2+1+0+0+0 = 7; total 20 ✓ Trend: lost 4 of 5 in Apr–May 2026, then won 3 straight (Jun–Aug). No loss reasons are recorded in the data — none stated rather than guessed. ## Carried over from old card — verification status - "Points-based recognition for mid-market" — re-sourced (points-based: S02; mid-market signal: S04). Kept. - "Strong in EU enterprise with multi-language support" — re-sourced [S12]. Kept. - "Pricing $5/user/month (as of 2026-01)" — was accurate per S03/S08; superseded by S17 ($7). See conflict note above. - "Rivally lacks a Slack integration" — UNVERIFIED and contradicted: S04 reports Slack integration worked out of the box (2026-02-02). Removed. - "Rivally was acquired by WorkHuman in 2025" — UNVERIFIED: no snippet supports any acquisition. S11 concerns hiring an ex-Workday VP EMEA (a hire, not an acquisition; Workday ≠ WorkHuman). Removed pending confirmation. ## Excluded as rep opinion (not facts) - S09 (Bryce Harmon: UI feels clunky — not verified against product) - S21 (Elena Sinclair: believes Rivally discounts aggressively — explicitly unconfirmed). The only sourced discount evidence is the two field quotes S13 and S18.
SEQUENCE REVIEW (rates = per-step replies/sent, opens/sent, meetings/sent) New Logo Nurture — Sent 1,386 (500/458/428). Open 42.0% → 34.9% → 28.0%. Reply 8.40% (42) → 6.55% (30) → 4.21% (18). Meeting 2.40% → 1.97% → 1.40%. Weakest step: step 3 (reply halves from step 2). Expansion Nurture — Sent 875 (300/300/275). Open 43.3% → invalid → 34.5%. Reply 7.33% (22) → 8.33% (25) → 4.36% (12). Meeting 1.67% → 1.33% → 1.09%. Weakest step: step 3 (4.36%). Cold Outbound – HR Leaders — Sent 1,785 (600/595/590). Open 40.0% → 29.4% → 22.0%. Reply 0.83% (5) → 0.34% (2) → 0.17% (1). Meeting 0.00% at every step. Weakest step: all three; step 1 is the ceiling at 0.83%. Cold Outbound – People Ops — Sent 1,163 (400/386/377). Open 37.5% → 28.5% → 21.2%. Reply 3.50% (14) → 2.33% (9) → 1.59% (6). Meeting 0.75% → 0.52% → 0.27%. Weakest step: step 3. TRACKING ERRORS Expansion Nurture step 2: opened 340 > sent 300 (113.3%) — impossible; exclude or re-pull. Also Expansion step 2 sent (300) didn't decay from step 1 like every other sequence, suggesting unenrolled re-sends. AUDIENCE OVERLAP 21 contacts sit in both HR Leaders and People Ops (e.g., CT-000849, CT-001033, CT-001255) — double-touching inflates fatigue. 2 contacts in both Expansion and New Logo Nurture (CT-000301, CT-000624). Dedupe by contact_key. FAILURE MODES (<2% REPLY) HR Leaders (0.45% overall, 0 meetings on 1,785 sends): opens are healthy at 40% — the message, not deliverability, is failing. Generic pitch to a mis-scoped persona. People Ops step 3 (1.59%): sequential decay — 3-touch cadence with no new value per touch. ONE CHANGE EACH - HR Leaders: pause and rebuild step 1 with a persona-specific trigger (benefits/compliance pain), not the shared cold template. - People Ops: replace step 3 with a breakup/social-proof asset or drop it. - Expansion: fix step-2 tracking before judging it; step 3 gets proof-of-value content. - New Logo: shorten to 2 steps or add a case study at step 3. FIX FIRST HR Leaders — largest spend (1,785 sends), zero meetings, and the shared overlap pool is burning People Ops results too.
WEEKLY MARKETING GOALS UPDATE — Q3-2026 (2026-07-01 → 2026-09-30) Days elapsed: 66 of 92 (71.7% of quarter gone; 26 days remain) Pace rule used: linear expectation = 66/92 = 71.7% attainment by now. Ahead ≥ 73.7%, On = 69.7–73.7%, Behind ≤ 69.7%. (±2pp tolerance.) METRIC-BY-METRIC 1) SQMs QTD actual: 230 | Target: 300 | Delta: -70 Attainment: 230/300 = 76.7% vs 71.7% elapsed (+4.9pp) Pace: AHEAD 2) SQOs QTD actual: 84 | Target: 120 | Delta: -36 Attainment: 84/120 = 70.0% vs 71.7% elapsed (-1.7pp) Pace: ON (marginally under linear pace) 3) DS2s QTD actual: 40 | Target: 75 | Delta: -35 Attainment: 40/75 = 53.3% vs 71.7% elapsed (-18.4pp) Pace: BEHIND 4) Closed-lost MIA rate (lower is better) QTD actual: closed_lost_mia 5 / closed_lost_total 25 = 0.20 (20%) Target: 0.10 (10%) | Delta: +10pp worse than target (2.0x target) Pace: N/A — a ratio, not a cumulative metric; it does not accrue with days elapsed. Status vs target: unfavorable. 5) Same-quarter closes (same_quarter_closes) QTD actual: 10 | Target: 20 | Delta: -10 Attainment: 10/20 = 50.0% vs 71.7% elapsed (-21.7pp) Pace: BEHIND 6) Active pipeline coverage (active_pipeline) QTD actual: 3,000,000 | Target: 4,000,000 | Delta: -1,000,000 Coverage: 3,000,000/4,000,000 = 75.0% of target Pace: ON/ahead on a nominal basis (75.0% ≥ 71.7% elapsed), but note this is a point-in-time snapshot, not a cumulative — linear pace does not strictly apply. WHAT MOVED THIS WEEK I cannot say what moved this week from the data provided: only a single QTD snapshot was supplied (marketing_qtd.csv), with no prior-week values, so week-over-week deltas are not computable and I will not invent them. What the current snapshot does show, as of day 66: SQMs is the only cumulative metric running ahead of linear pace (76.7% attained), SQOs is essentially on pace (70.0%), and the two weakest spots are DS2s (53.3% attained, needs 35 more in 26 days, ~9.3/week) and same_quarter_closes (50.0% attained, needs 10 more in 26 days). The closed-lost MIA rate sits at 20% versus a 10% target — 5 of 25 closed-lost deals marked MIA — and active_pipeline covers 75% of the 4,000,000 target with a 1,000,000 gap. If you supply last week's marketing_qtd.csv, I can produce true week-over-week movement.
Do not publish the Q3 forecast of 115,976.75 (COMMIT 44,729 + 35% x BEST_CASE 203,565 = 71,247.75) without re-qualification: 85/86 deals lack an owner and 71/86 lack a why-buy, including all 7 in-quarter COMMIT deals. Excluded as post-quarter are 32 deals totaling 227,575, including Deal-D348E1 (COMMIT, 13,770, dated 2026-10-15) and 9 BEST_CASE totaling 28,240.
Subject: Re: July 28 demo recap and pricing Hi, Following up on my August 5 note with the recap of our July 28 demo and pricing for 150 seats — I wanted to make sure it landed. Since birthdays and anniversaries are tracked manually today, the automated milestone awards and points catalog your team reacted to in the demo would take that off your plate from day one. Would you be open to a 15-minute call next week to walk through the pricing and next steps? Happy to loop in the two HR admins who joined the demo if that's easier. Best, Alex Franklin
**Marketing** Webinars take the kudos this week! We closed out the week of August 31 with 46 SQMs against a target of 52 — about 88% of goal (46 ÷ 52 = 0.8846) — leaving a 6-SQM gap to make up. The clear bright spot: the webinar channel delivered 18 of those SQMs, roughly 39% of the week's total (18 ÷ 46 = 0.391). Meanwhile, paid search stayed efficient with cost per SQM holding steady at $150. We're riding the webinar momentum and tightening the paid mix to close the gap next week. **Sales** High-fives all around for a week of strong execution: the team converted 14 SQOs and set 9 DS2 meetings. New pipeline created landed at $310,000 — fresh fuel for the quarter ahead — and 3 deals closed same-quarter, proof that momentum carries all the way across the finish line. With $310K of new pipeline on the board and a healthy DS2 slate, the team is set up to keep celebrating in the weeks to come. **CS** Every saved renewal is a relationship worth honoring, and this week the CS team celebrated 2 renewals saved. Team NPS moved to 61, a strong signal that customers are genuinely feeling the love. Looking ahead, we're giving 3 open red-flag accounts some extra focused care heading into next week, so every one of those customers gets the attention they deserve. **PLG** The self-serve flywheel keeps spinning! PLG welcomed 412 new signups this week with activation at 31% — roughly 128 teams taking their first meaningful step (412 × 0.31 ≈ 128). The biggest cheer goes to the 38 companies that reached the aha moment of 10 recognition gives: they're already building the habit of celebrating each other, which is exactly what Bonusly is all about. Here's to many more moments of recognition ahead. Notes: All figures trace directly to week_extracts.md; the only derived values are shown inline with arithmetic (SQM attainment, webinar share, and estimated activated signups from the stated 31% rate). No data was missing for any team this week. Total: ~340 words.
PARTNER DIGEST — Period 2026-08-24 to 2026-09-04 Roster: 8 partners (4 active, 4 quiet) | Partner-sourced pipeline: 5 deals / $550,000 ACTIVE PARTNERS 1) Apex Rewards Co — Active Status: Co-webinar locked for 09-15. Two sourced opps this period, both in DS1, logged with UTM Source = Partner. Sourced deals (2, $275,000): - Deal-DDAAF2 — $180,000 - Deal-2CF33E — $95,000 Arithmetic: 180,000 + 95,000 = 275,000 2) HRCloud Partners — Active Status: Integration referral closed security review; opp moved to DS2. One sourced opp this period. Sourced deals (1, $140,000): - Deal-F1CDA5 — $140,000 Arithmetic: 140,000 = 140,000 3) CultureBridge — Active Status: Lunch-and-learn produced two sourced opps, both early stage. Sourced deals (2, $135,000): - Deal-096E1D — $60,000 - Deal-067213 — $75,000 Arithmetic: 60,000 + 75,000 = 135,000 4) WorkWell Group — Active Status: No sourced deals this period. WorkWell wants to restart the joint playbook in Q4; planning call booked for 09-09. Sourced deals (0, $0). QUIET PARTNERS 5) Recogniq — Quiet. No sourced deals and no recorded activity this period. 6) KudosWave — Quiet. No sourced deals and no recorded activity this period. 7) PeopleFirst Advisors — Quiet. No sourced deals and no recorded activity this period. 8) TotalPerk — Quiet. No sourced deals and no recorded activity this period. RECONCILIATION Per-partner counts vs. deal data (utm_source = Partner only): Apex Rewards Co: 2 deals / $275,000 (180,000 + 95,000) HRCloud Partners: 1 deal / $140,000 CultureBridge: 2 deals / $135,000 (60,000 + 75,000) WorkWell Group: 0 deals / $0 Recogniq, KudosWave, PeopleFirst Advisors, TotalPerk: 0 deals / $0 Total: 2 + 1 + 2 + 0 = 5 deals; 275,000 + 140,000 + 135,000 = $550,000. Matches the 5 rows in partner_deals.csv exactly. Slack-reported sourced counts (Apex 2, HRCloud 1, CultureBridge 2, WorkWell 0) also match the deal data. Note: Deal stage fields (DS1/DS2) are cited only as reported in Slack; no stage column exists in the deal data.
Q1. Yes. Customer data is encrypted at rest using AES-256. [P1] Q2. Yes. Data in transit is encrypted with TLS 1.2 or higher. [P1] Q3. Yes. We maintain a SOC 2 Type II report, renewed annually. It is available to prospects under NDA. [P2] Q4. Customer data is retained for the duration of the contract plus 90 days (contract term + 90 days), after which it is deleted from production systems. [P3] Q5. The current subprocessor list is maintained at trust.bonusly.com. Customers receive 30 days notice before a new subprocessor is added. [P4] Q6. Yes. SAML 2.0 single sign-on is available on the Enterprise plan (SCIM user provisioning as well). [P5] Q7. Production databases are backed up daily. Backups are encrypted and retained for 35 days. [P6] Q8. Unanswerable from the provided excerpts. No excerpt addresses ISO 27001 certification status. A compliance certifications list or the SOC 2 report cover page would answer this. Q9. Unanswerable from the provided excerpts. No excerpt states an uptime SLA percentage. The Service Level Agreement or master service agreement would answer this. Q10. Unanswerable from the provided excerpts. No excerpt addresses HIPAA or a Business Associate Agreement. A HIPAA compliance policy or BAA/DPA contract addendum would answer this. Note: Q8–Q10 are marked unanswerable strictly because the excerpts contain no relevant statement; no position on certification, SLA, or BAA is implied.
RECONCILIATION REPORT — SignalForge skill set vs. skill_manifest.csv
Scope: 14 manifest rows, 14 provided skill files. I used only the data provided. Where a referenced skill's existence outside this manifest cannot be verified from the provided data, I say so explicitly rather than assume.
SUMMARY: 3 CRITICAL · 8 WARNING · 4 INFO · 15 findings total, one proposal each.
================================================================
1) ALWAYS-TRIGGER OVERLAP / DUPLICATION
================================================================
[1.1] CRITICAL — weekly-pipeline-report x pipeline-intelligence-report
pipeline-intelligence-report ALWAYS triggers include: "run the pipeline report",
"pipeline update", "what's the pipeline look like", and "never answer pipeline
questions inline without running it."
weekly-pipeline-report ALWAYS triggers include: "run the pipeline update",
"generate the pipeline report", "do the pipeline report", "update the pipeline",
"what does pipeline look like".
Collision: "pipeline update" (pir) vs "run the pipeline update" / "update the
pipeline" (wpr); "what's the pipeline look like" (pir) vs "what does pipeline
look like" (wpr); "run the pipeline report" (pir) vs "generate/do the pipeline
report" (wpr). Both skills ALWAYS-fire on the same utterances but produce
different deliverables (10-tab scored HTML vs weekly metrics HTML).
ACTION: TRIM_DESC — weekly-pipeline-report: remove the generic "pipeline update",
"pipeline report", and "what does pipeline look like" triggers; re-anchor its
ALWAYS set to the weekly cadence and its unique vocabulary ("weekly pipeline
report", "mid-month pipeline check", SQM/SQO/DS2, bookings MTD, "this week's
numbers"). Leave generic pipeline-report phrasing exclusively with
pipeline-intelligence-report.
[1.2] CRITICAL — email-drafter x comms-drafter
Verbatim duplicate ALWAYS triggers in both descriptions: "write me an email",
"draft a follow-up", "what should I say", "bump email", "contract nudge".
Near-duplicate: "help me reply to this" (email-drafter) vs "help me reply"
(comms-drafter). Both also trigger when a user pastes an existing message and
asks for feedback/rewrite/rating. comms-drafter explicitly serves "AEs, SDRs,
CSMs" — email-drafter's entire audience — and covers the same email types
(outbound, follow-ups, post-demo recaps, pricing/contract follow-up, EOQ pushes,
renewal/expansion, QBR follow-ups, onboarding).
ACTION: MERGE — fold email-drafter into comms-drafter, carrying over
email-drafter's unique machinery (Gmail signature retrieval, no-markdown-in-email
rule, transcript sourcing order). comms-drafter is the superset; keep its name.
[1.3] WARNING — signalforge-claim-compressor x pipeline-intelligence-report / weekly-pipeline-report
claim-compressor ALWAYS triggers include "pipeline updates", which is also an
ALWAYS trigger phrase for both pipeline report skills. claim-compressor is a
post-processing style pass, not a requester-facing report skill.
ACTION: TRIM_DESC — claim-compressor: drop the bare output-type triggers
("pipeline updates", "intelligence reports", etc.) from the ALWAYS list; keep
only the explicit operator phrases ("compress this", "tighten this up", "cut the
fluff", "make this more concise") plus a statement that it runs automatically as
a pipeline stage after analysis-validator.
[1.4] WARNING — pipeline-intelligence-report x sales-forecast
pipeline-intelligence-report: "Also trigger when Alaina or any VP asks for
pipeline health or forecast context." sales-forecast ALWAYS triggers include
"sales forecast", "forecast report", "forecast update", "pipeline forecast".
"forecast context" crosses into sales-forecast's lane.
ACTION: TRIM_DESC — pipeline-intelligence-report: narrow that clause to
"pipeline health" only; leave all forecast phrasing to sales-forecast.
[1.5] INFO — model-selection x every skill
model-selection claims: "ALWAYS run this skill at the start of every task,
without exception — before any planning, execution, or skill invocation begins."
This overlaps every other ALWAYS trigger by scope (not by phrase), and no other
skill acknowledges it in its execution plan except via its own Integration
Protocol offer.
ACTION: REVIEW — confirm whether model-selection is actually wired as a
mandatory pre-gate in the orchestrator; if not, downgrade its description from
"mandatory, every task" to "on request / planning-phase" to stop it shadowing
every other ALWAYS trigger.
================================================================
2) CIRCULAR DELEGATION CHAIN
================================================================
[2.1] WARNING — Cycle: deal-strategy-coach -> email-drafter -> deal-strategy-coach
Edge A: deal-strategy-coach body: "When drafting manager-to-prospect emails, use
the `email-drafter` skill which automatically retrieves your Gmail signature..."
Edge B: email-drafter description + lane marker: "For deal strategy, diagnosis,
or coaching (not email drafting), use deal-strategy-coach instead."
A request mixing both ("draft a manager email for this stalled deal") matches
both skills and each hands part of the work to the other. Lane boundaries make
it self-limiting, but the loop is real.
ACTION: UPDATE_BODY — deal-strategy-coach: remove the delegation edge (draft
manager-to-prospect emails inline, adopting the Gmail signature step itself), so
only the one-way informational lane marker from the drafting skill remains. This
dissolves the cycle regardless of whether [1.2]'s merge proceeds; if the merge
proceeds, apply the same one-way rule to comms-drafter x deal-strategy-coach.
================================================================
3) DANGLING DELEGATION TARGETS (not in manifest, not in provided files)
================================================================
[3.1] CRITICAL — Dangling skill delegations (named, 11 total):
- bonusly-brand — referenced by comms-drafter (mandatory Step 0), email-drafter
(mandatory before drafting), sales-forecast ("Always reference"), and
signalforge-claim-compressor (routing for customer-facing content)
- prospect-research-multithreading — referenced by comms-drafter (Contact Lookup
mode), email-drafter (Contact Lookup + multithread expansion), and
deal-strategy-coach (Cross-skill handoff section)
- skill-orchestrator — referenced by analysis-validator (Section 11 Three-Way
Sync cascade) and signalforge-feedback (Activation Checklist: "registered in
skill-orchestrator as a terminal step")
- analysis-validator Section 12.4 specialist table (8 targets):
bonusly-data-questions, bonusly-product-questions,
bonusly-business-reporting-questions, bonusly-rewards-questions,
bonusly-ppp-questions, bonusly-feature-flag-questions,
bonusly-deal-desk-questions, bonusly-datadog-questions
Caveat: whether any of these exist outside this manifest (e.g., at org level)
cannot be confirmed from the data provided — they are dangling relative to the
manifest as given.
ACTION: REVIEW — reconcile all 11 names against the org-level skill inventory.
For each that exists: add a manifest row (or an explicit "external" designation).
For each that does not: remove or replace the delegation instruction so no skill
hard-delegates to a name that resolves nowhere.
[3.2] INFO — Out-of-manifest mount/path references (existence not verifiable from provided data):
- signalforge-reports org skill (/mnt/skills/organization/signalforge-reports/:
SKILL.md, DESIGN-SYSTEM.md, signalforge.css, reports.html, brand-lockup.html)
— mandatory pre-build reads for pipeline-intelligence-report and
weekly-pipeline-report
- /mnt/skills/public/xlsx/scripts/recalc.py — stale-pipeline-report Phase 7
- analysis-validator Section 11 cascade files: CUSTOMER_DATA_REFERENCE,
HUBSPOT_CONNECTOR_REFERENCE, SIGNALFORGE_PRODUCT_INSIGHT_SKILL
- caveman (JuliusBrussee/caveman) — signalforge-claim-compressor: historical
fork citation plus "Both can be used together on the same output", implying an
available companion skill
ACTION: REVIEW — confirm these paths/skills resolve in the deployment
environment; if any are gone, the two report skills' mandatory pre-build steps
fail and must be re-pointed.
================================================================
4) VERSION CONFLICT
================================================================
[4.1] WARNING — analysis-validator conflicts with itself: v3.6 vs v3.2
Declared: header "Version: 3.6", "Last Updated: May 9, 2026 (v3.6 ...)";
changelog top entry 3.6; pipeline-intelligence-report footer cites "Analysis
Validator v3.6".
Stale references inside the same body:
- Section 7 trail template: "Validator: analysis-validator v3.2"
- Section 0 purpose: describes gates as "G1-A through G1-H" and "G2-A through
G2-E" (v3.0-era scope)
- Section 6 decision tree: "Run Gate 2 (G2-A through G2-E)" — omits G2-F (ID
Resolution, added in v3.6)
Current actual scope per Sections 2-4: G1-A through G1-L, G2-A through G2-F.
Survivor: v3.6 — it is the latest changelog entry and the version other skills
already cite.
ACTION: UPDATE_BODY — analysis-validator: align the trail template version line
and both stale gate ranges to v3.6 (G1-A..L, G2-A..F). No other skill carries a
conflicting version claim.
================================================================
5) DESCRIPTIONS EXCEEDING 1,024 CHARACTERS
================================================================
[5.1] INFO — Count exceeding 1,024 chars: 0 of 14.
Arithmetic: I measured every frontmatter description character count.
Measured lengths: analysis-validator 656, closed-lost-analysis 897,
comms-drafter 996, deal-strategy-coach 792, email-drafter 965, model-selection
676, next-to-close 945, partner-digest 1004, pipeline-intelligence-report 1006,
sales-forecast 962, signalforge-claim-compressor 1006, signalforge-feedback 708,
stale-pipeline-report 762, weekly-pipeline-report 656.
Max = 1,006; 1,024 - 1,006 = 18 chars of headroom. All 14 manifest
description_chars values match my measured values exactly (delta = 0 on every
row), so that manifest column has no drift.
Note: partner-digest (1,004), pipeline-intelligence-report (1,006), and
signalforge-claim-compressor (1,006) sit within 20 chars of the cap — any growth
puts them over.
ACTION: none required (monitor the three near-cap descriptions).
================================================================
6) HARDCODED PAGE IDs, DATES, AND PERSON NAMES IN BODIES
================================================================
[6.1] WARNING — Hardcoded page/resource IDs
partner-digest: cloudId 73fe98de-a4a3-4869-9f8a-bb1eeed4cf7f; spaceId
1958248479; folder/page ID 2286616609; page IDs 2286321666, 2265382925,
2236940297, 2237825028, 2239365136, 2238283777
sales-forecast: spaceId 2232811524; cloudId 73fe98de-...; parent page 2232582148
signalforge-feedback: page 2295136266; spaceId 2232811524; parent 2234417154;
Build Log page 2247295002
deal-strategy-coach: Confluence page 2257879045 (AE Excellence Playbook)
weekly-pipeline-report: spreadsheet IDs 1CLZeOsElVDF_LF0ZG_t2nfwvhnZ6bpwqM_nX3WEYzcw
and 1ENuaEcCuLjdKhMvp8FK3Ys1ek5Aw9ZuOZhsHJJFoB_k
Slack IDs: C0561C1JCPJ (#revops-team, stale-pipeline-report); U03QLMBL7AR
(partner-digest search filter)
HubSpot org ID 1973303 in deal URL patterns: pipeline-intelligence-report,
next-to-close, stale-pipeline-report
HubSpot owner IDs: analysis-validator Section 12.3 (full roster);
pipeline-intelligence-report Phase 1 (5 AE IDs)
(Stage IDs 150582536/150582537/150582538/150582539/1175632767 also appear in
analysis-validator, pipeline-intelligence-report, next-to-close,
stale-pipeline-report — canonical constants, lowest risk.)
ACTION: UPDATE_BODY — extract infrastructure IDs (Confluence, spreadsheets,
Slack, HubSpot org) into a single shared constants reference that all skills
read; verify each ID is live at extraction time.
[6.2] WARNING — Hardcoded dates in operational instructions (changelog dates excluded — those are appropriate)
analysis-validator: "as of May 4, 2026" (CALL_SPOTLIGHT_BRIEF removal; Gong
routing; CLOSEDWON_DEALS currency), "Stale as of March 28, 2023" (DEALS),
"Expected ranges (as of May 2026)", "Created: April 26, 2026"
closed-lost-analysis: "the 30-deal AI-field sample from May 2026: 10 of 10
deals", "`ai_closed_lost_reason` field confirmed May 2026", "`closed_lost_reason`
field confirmed May 2026", "Lost to Motivosity on this in May 2026 (Softheon)",
"MinIO: rep vacation May 4-12"
model-selection: "last_checked: 2026-05-19", "deprecation announced April 14, 2026"
partner-digest: "the May 16, 2026 issue as the canonical reference"; title
examples "Week of May 19, 2026" / "Week of June 2, 2026"
sales-forecast: example title "Q3 2026 Forecast Intelligence — July 9, 2026"
stale-pipeline-report: example dates "5/15", "5/19" in Phase 5
weekly-pipeline-report: "Business days complete in Q2 (April 1 – June 30, 2026)"
and the "Q1 2026 context (static)" block
ACTION: UPDATE_BODY — replace operational dates with live-computed values or
"verify at runtime" language; closed-lost-analysis ("Known System State
(dynamic — run at analysis time)") and stale-pipeline-report already model the
correct pattern.
[6.3] WARNING — Hardcoded person names
weekly-pipeline-report: titled "Ben Lavin · Demand Generation · Bonusly"; body
says "Ben's review", "If Ben confirms" — the whole skill is bound to one person
partner-digest: "Amani's threads", "DMs and threads involving Amani",
from:<@U03QLMBL7AR>, "Owner: Amani Phipps (RevOps / Partnerships)"; partner
contacts Kelli, Jen Lee, Hani, Bryce, Sara
analysis-validator: full GTM roster (Alaina Loori, Shealagh Coughlin, Bryce
Harmon, Hugo Lindqvist, Dana Mercer, Alex Franklin, Cole Ingram, Gavin
Porter, Colleen Perry, Ellie Barton, Ashley Reyer, Ashley Le, Megan Franz,
Elena Sinclair, Youssef Elkhateeb, Amanda Czenkus, Ben Castelli, Amani Phipps,
John Thomas, Yasmin Wahid) plus "Escalate to Finance (Manish or Amani)"
pipeline-intelligence-report: Bryce Harmon, Dana Mercer, Cole Ingram, Alex
Franklin, Gavin Porter; "Also trigger when Alaina or any VP asks"
sales-forecast: "Manager Forecast (Alaina / VP Sales view)"; changelog records a
prior hardcode fix "Elena → Alaina" — evidence this failure mode recurs
deal-strategy-coach: "routed to Farid", "routed to Perseus"
stale-pipeline-report: "any AE or Alaina asks"
signalforge-feedback: example "Gavin Porter Rep Diagnostic"
(next-to-close, model-selection, signalforge-claim-compressor: none found.)
ACTION: UPDATE_BODY — convert person-bound language to role-bound language
("the report owner", "VP Sales", "the authenticated rep") and replace named
escalation contacts with role references; keep the roster table only if [6.4]
is also addressed.
[6.4] WARNING — Hardcoded rosters already diverging between two skills
analysis-validator Section 12.3 defines the "Core 6 AEs" = 6 owner IDs
(including Hugo Lindqvist, 77260721). pipeline-intelligence-report Phase 1 lists
"AE owner IDs (verified May 2026)" = 5 owner IDs, omitting Hugo Lindqvist.
6 ≠ 5 — both marked verified/current, one is already wrong or stale.
ACTION: UPDATE_BODY — pipeline-intelligence-report: delete the hardcoded AE
roster and resolve owners dynamically at runtime, exactly as stale-pipeline-report
Phase 2 already mandates ("Never hardcode rep names or owner IDs").
================================================================
7) MANIFEST DRIFT (BOTH DIRECTIONS)
================================================================
[7.1] INFO — No drift in either direction.
Manifest rows: 14. Provided skill files: 14. The two sets are identical.
- Files with no manifest row: none.
- Manifest rows with no file: none.
- For all 14, file stem = declared_name = frontmatter `name` field.
Referenced-but-unmanifested skills (bonusly-brand, prospect-research-
multithreading, etc.) are delegation gaps, reported under [3.1], not manifest
rows missing files.
ACTION: none required.
================================================================
ADJACENT OBSERVATIONS (verified while checking; no rewrite proposed)
================================================================
- weekly-pipeline-report's hardcoded Q1 2026 percentages are arithmetically
consistent: 365,152 / 475,000 = 76.87% → 77% as stated; 2,490,532 / 3,288,000 =
75.75% → 76% as stated. The issue is that they are static, not that they are wrong.
- analysis-validator's description says "Never skip — even on quick check
requests", while its own Section 1 exempts tasks where "the user explicitly says
'skip validation — quick check only'" — a description-vs-body contradiction worth
resolving inside the [4.1] UPDATE_BODY pass.
- analysis-validator's G1-A worked example checks out: 47/312 = 0.1506 → 15.1%.
RUNBOOK — Incident #incident-2026-08-29-reward-queue (2026-08-29, resolved) Source: incident_thread.md only (messages M01–M10). Every step cites its source message. Nothing added beyond the thread. STEP 1 — Detect incident and establish command [M01] Time/actor: 14:02:10Z, Bryce Harmon Action: Acknowledged PagerDuty alert "reward-worker queue depth > 10k"; took IC (incident commander). Command: None (alert acknowledgment). Verified by: Acknowledgment recorded in M01. State changed: No. Rollback: N/A. STEP 2 — Assess queue depth [M02] Time/actor: 14:04:33Z, Farid Osman Action/command: `bundle exec rake sidekiq:queue_depth` Result: 48,213 pending jobs on reward queue; stated normal baseline is under 500. Verified by: Command output itself (48,213 > 10k alert threshold from M01 — consistent). State changed: No (read-only). Rollback: N/A. STEP 3 — Inspect dead set [M03] Time/actor: 14:06:02Z, Farid Osman Action: Inspected the Sidekiq dead set. Result: 112 dead jobs, all Redis::TimeoutError, timestamped around 13:58. Command: NOT stated in thread — NEEDS CONFIRMATION (exact tool/command used to view the dead set). State changed: No (read-only). Rollback: N/A. STEP 4 — Pause enqueue to stop new inflow [M04] Time/actor: 14:08:45Z, Farid Osman Action/command: `bin/rails runner 'FeatureFlag.disable(:auto_recognition_enqueue)'` Stated purpose (M04): "to stop the bleed." State changed: Yes — auto_recognition_enqueue disabled. Verified by: NOT stated in thread — NEEDS CONFIRMATION. No flag-state check is recorded; the later drain (M07/M08) is consistent but never explicitly attributed to this step. Rollback (verbatim from M04): `bin/rails runner 'FeatureFlag.enable(:auto_recognition_enqueue)'` — executed in Step 9 [M09]. STEP 5 — Clear the dead set [M05] Time/actor: 14:15:20Z, Elena Sinclair Action: Cleared out the dead set (the 112 jobs identified in M03). Command: NOT stated — M05 says only "While I was in the console" — NEEDS CONFIRMATION (exact console command or UI action). State changed: Yes — 112 dead jobs removed. Verified by: NOT stated in thread — NEEDS CONFIRMATION. Rollback: NOT stated in thread — NEEDS CONFIRMATION (thread does not say whether cleared dead jobs were recoverable). STEP 6 — Scale workers up [M06] Time/actor: 14:21:07Z, Bryce Harmon Action/command: `kubectl scale deployment/reward-worker --replicas=6` (was 3). State changed: Yes — replicas 3 → 6. Verified by: Step 7 [M07] (depth falling) and Step 8 [M08] (depth 0). Rollback (verbatim from M06): `kubectl scale deployment/reward-worker --replicas=3` — executed in Step 10 [M10]. STEP 7 — Verify drain progress [M07] Time/actor: 14:33:41Z, Farid Osman Action: Measured queue depth: 9,400 and falling ~1,200 jobs/min. Role: Verification for Steps 4 and 6. Arithmetic on stated figures: 48,213 (M02) − 9,400 (M07) = 38,813 net jobs drained across the 14:04:33 → 14:33:41 window (~29 min). Note: this is net change only; enqueue remained on until 14:08:45 (M04), so inflow and outflow are conflated — the thread does not break them out. State changed: No. Rollback: N/A. STEP 8 — Verify full drain and error-rate recovery [M08] Time/actor: 14:47:55Z, Cole Ingram Action/command: `bundle exec rake sidekiq:queue_depth` → returns 0; Datadog error rate back to baseline. Consistency check (stated numbers only): at ~1,200 jobs/min (M07), 9,400 jobs ≈ 7.8 min to drain (9,400 ÷ 1,200 = 7.83); M08 lands 14m14s after M07, so zero depth is consistent with the stated rate. State changed: No. Rollback: N/A. STEP 9 — Re-enable enqueue [M09] Time/actor: 14:49:10Z, Bryce Harmon Action/command: `bin/rails runner 'FeatureFlag.enable(:auto_recognition_enqueue)'` State changed: Yes — enqueue re-enabled. This is the rollback of Step 4, executed exactly as M04 prescribed. Verified by: "40 new jobs processed cleanly in the next 3 minutes" (stated in M09). Rollback: Re-disable with the Step 4 command `bin/rails runner 'FeatureFlag.disable(:auto_recognition_enqueue)'` (inverse from M04). STEP 10 — Scale workers back down; resolve [M10] Time/actor: 14:55:00Z, Bryce Harmon Action/command: `kubectl scale deployment/reward-worker --replicas=3` State changed: Yes — replicas 6 → 3. This is the rollback of Step 6, executed exactly as M06 prescribed. Verified by: "Queue stable at 0. Incident resolved." (stated in M10). Rollback: Scale back up with the Step 6 command `kubectl scale deployment/reward-worker --replicas=6` (inverse from M06). NEEDS CONFIRMATION (summary of thread gaps) 1. Step 3 [M03]: exact command/tool for inspecting the dead set. 2. Step 4 [M04]: how the flag disable was verified at the time. 3. Step 5 [M05]: exact command used to clear the dead set, how success was verified, and rollback/recoverability of the 112 cleared jobs. NOTES - Coverage: all 10 messages (M01–M10) are mapped; none omitted. Actors: Bryce Harmon (M01, M06, M09, M10), Farid Osman (M02, M03, M04, M07), Elena Sinclair (M05), Cole Ingram (M08). - Observation (from thread only): the dead jobs are all Redis::TimeoutError from ~13:58 (M03), but the thread contains no step that investigates or remediates Redis itself. If Redis instability was the root cause, that follow-up is not documented here.
FAILURE SEQUENCE — 2026-09-03 (all times UTC, exactly as logged)
FIRST ERROR
2026-09-03T14:01:12Z reward-service ERROR
Redis::TimeoutError: Connection to Redis at redis-primary:6379 timed out after 5s
CASCADE, IN ORDER
Phase 1 — reward-service retry exhaustion (root service)
14:01:20Z reward-service retry exhausted for RewardGiveJob
14:01:30Z reward-service retry exhausted for RewardGiveJob
14:01:40Z reward-service retry exhausted for RewardGiveJob
Phase 2 — Sidekiq job failures (worker layer)
14:01:40Z sidekiq RewardGiveJob failed: Redis::TimeoutError; retrying in 60s
(job records confirm: earliest failed_at in sidekiq_jobs.csv is J-00005,
RewardGiveJob, 14:01:46Z — 34s after the first error; J-00001–J-00006
follow through 14:01:57Z; second retry wave J-00007–J-00012 at ~14:02:51–58)
14:02:28Z sidekiq RewardGiveJob failed; retrying
14:02:30Z sidekiq WARN "Queue reward depth above 10,000" (78s after first error)
Phase 3 — collateral job class
14:02:36Z RecognitionDigestJob failures begin (J-00013; J-00014–J-00016
follow at 14:03:15, 14:04:55, 14:05:50)
Phase 4 — upstream/user-facing impact (API path)
14:03:05Z api-gateway 502 upstream timeout calling reward-service /gives
(1m53s after first error)
14:03:30Z web-app Give form submission failed: upstream 502 from api-gateway
14:03:31Z–14:06:47Z repeated sidekiq RewardGiveJob failures
14:03:48Z, 14:04:13Z, 14:05:16Z, 14:06:52Z api-gateway 502s
14:04:45Z, 14:05:42Z, 14:06:49Z web-app Give form 502s
Last error in slice: 14:06:52Z (api-gateway)
Phase 5 — recovery
14:10:56Z–14:20:59Z postgres INFO checkpoints only (routine; no postgres errors)
14:22:10Z reward-service Redis connection restored; resuming job processing
14:24:45Z sidekiq Queue reward depth below 500
ARITHMETIC
Error window: 14:06:52 − 14:01:12 = 5m40s of logged errors
Time to restore: 14:22:10 − 14:01:12 = 20m58s
Time to queue drain (<500): 14:24:45 − 14:01:12 = 23m33s
Log ERROR rows: reward-service 4 + sidekiq 6 + api-gateway 5 + web-app 4 = 19 ERROR, 1 WARN
sidekiq_jobs.csv: 16 failed job records — RewardGiveJob 12 (J-00001–J-00012),
RecognitionDigestJob 4 (J-00013–J-00016); all Redis::TimeoutError
SERVICES AND JOBS INVOLVED
Services: reward-service (origin), sidekiq, api-gateway, web-app
Jobs: RewardGiveJob (primary), RecognitionDigestJob (secondary collateral)
Infra implicated: redis-primary:6379 (no logs from it in this slice)
DATADOG QUERY TO CONFIRM THE FIRST ERROR
service:reward-service status:error "Redis::TimeoutError"
Time range: 2026-09-03T13:55:00Z to 2026-09-03T14:05:00Z, sorted oldest-first.
The first hit should be the 14:01:12Z "Connection to Redis at redis-primary:6379
timed out after 5s" event. To isolate only the origin event:
service:reward-service status:error "redis-primary:6379"
WHAT THE LOGS DO NOT SHOW
1. Root cause of the Redis timeout — there are zero logs from Redis/redis-primary;
no evidence of outage vs. overload vs. network partition vs. failover.
2. When Redis actually became reachable again — recovery is only inferred from
reward-service's 14:22:10 reconnect log.
3. Any activity from reward-service, sidekiq, api-gateway, or web-app between
14:06:52 and 14:22:10 — a ~15-minute gap (postgres checkpoints only).
4. Whether the failed RewardGiveJob / RecognitionDigestJob retries eventually
succeeded after restoration or were discarded — no job-success logs exist.
5. The true user impact count — web-app logged 4 Give form failures, but nothing
quantifies total affected submissions or users.
6. Whether the queue fully drained — the last entry says "below 500," not zero.
7. Any linkage between the 13:58:49 / 13:59:30 "job enqueued" events and the
specific job_ids in sidekiq_jobs.csv — the files share no correlation ID.
8. Any role for postgres — its entries are routine INFO checkpoints; no errors.
FEATURE FLAG STATE SUMMARY (source: flags_export.csv + flag_code.md) ON FLAGS (5) 1) recognition_streaks_v2 — ON Controls (app/models/recognition.rb): when enabled for a company, StreakTracker.record(give) runs, i.e. gives are recorded into streak tracking. Targeting: segment:beta_companies — 42 companies. 2) points_budget_guardrails — ON Controls (app/services/budget_service.rb): when enabled, BudgetService.new(company).enforce!(giver, points) runs, i.e. point-budget limits are enforced on the giver at give time. Targeting: all_companies — 220 companies. 3) slack_dm_nudges — ON Controls (app/jobs/nudge_job.rb): the job returns early unless the flag is enabled; when enabled it calls SlackDm.send_nudge(user), i.e. Slack DM nudges are sent. Targeting: segment:region_na — 87 companies. 4) analytics_dashboard_v3 — ON Controls (app/controllers/analytics_controller.rb): when enabled, @dashboard = AnalyticsV3.new(company), i.e. the V3 analytics dashboard is served. Targeting: segment:tier_three — 65 companies. 5) survey_boosters_q3 — ON No code reference in flag_code.md; behavior not determinable from provided data. Targeting: segment:legacy_plan — 7 companies. OFF FLAGS (4) 6) redeem_flow_redesign — OFF Controls (app/controllers/redeem_controller.rb): on => render RedeemV2Component.new(company); else => RedeemV1Component.new(company). Since OFF, RedeemV1Component renders. Targeting defined: targeted_list — 12 companies. Flag off, so none of them currently get the redesign. 7) ms_teams_app_v2 — OFF Controls (app/services/teams_installer.rb): when enabled, TeamsAppV2.install(company). Since OFF, this install path does not run. Targeting defined: targeted_list — 9 companies. Flag off, so none receive it. 8) legacy_give_modal — OFF No code reference in flag_code.md; behavior not determinable from provided data. Targeting defined: segment:legacy_plan — 14 companies. Flag off. 9) paused_offboard_cleanup — OFF No code reference in flag_code.md. No targeting rules (targeting_rules field empty) and 0 companies. Fully dormant. GAPS AND ANOMALIES - No code reference: legacy_give_modal, survey_boosters_q3, paused_offboard_cleanup. - No targeting / no targets: paused_offboard_cleanup (empty rules, company_count 0). - Off flags with targeting defined but no effect: redeem_flow_redesign (12), ms_teams_app_v2 (9), legacy_give_modal (14). ARITHMETIC CHECK (counts as exported, not unique-company counts) 42 + 220 + 87 + 12 + 65 + 9 + 14 + 7 + 0 = 456 total company-flag entries across the 9 flags. Counts overlap (e.g., all_companies at 220 presumably contains companies in other segments), so this is not a unique-company figure; the export does not provide unique company totals. All 9 flags in the export are covered; no flags outside the export are described.
NDA-1 — GREEN. Standard mutual structure with full carve-out set and ordinary Delaware law; Clause 3 grants all five standard exclusions ("publicly available… previously known… third-party receipt… independently developed… legally required") and Clause 5 confirms "No license, no obligation to proceed, no exclusivity."
NDA-2 — YELLOW. Standard confidentiality core, but Clause 4 embeds a non-solicit an NDA shouldn't carry: "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" — counsel should review scope ("with whom it came into contact") and whether Bonusly's hiring plans touch Party B's staff before signing.
NDA-3 — RED. Three compounding problems: Clause 2 is a full non-compete ("Recipient shall not, directly or indirectly, engage in or provide services to any business that competes with Discloser's business" for 3 years), Clause 3 imposes foreign governing law and exclusive jurisdiction ("the laws of the Republic of Ireland, and the parties submit to the exclusive jurisdiction of its courts"), and the agreement is one-way with no confidentiality carve-outs stated (Clause 4 confirms none) — full legal review required before signature.