Mean 0.912 · 24/39 perfect tests · $0.36 total · 39/40 tests completed — remaining tests discarded from study (endpoint timeouts after dedicated retries) · each card: the question → the correct answer (gold) → this model's actual answer
Definitions: - **DSx stage**: discovery stage where DS1 = stage 1, DS2 = stage 2, etc. - **Substantive why-buys**: for a deal at DS2 or later, the `why_buys` field must be either `LONG(n)` (indicating real text was present but truncated) or plain text with at least 15 characters and not exactly "tbd", "n/a", or "see notes". - **DS1 entry timestamp**: a deal must have a non-null `t_ds1` value (the date when the deal entered DS1). - **Regressed**: a deal whose stage entry timestamps are out of order; i.e., for any earlier stage `t_di` (i < j) and later stage `t_dj` (j > i), both non-null, if `t_di` > `t_dj`, the deal is regressed. Numbers: - Percent of DS2+ deals non-compliant on why-buys overall: **81.5%** (101 / 124 deals) - By owner (non-compliant / total %): - Bryce Harmon: **83.3%** (15 / 18) - Alex Franklin: **78.7%** (48 / 61) - Dana Mercer: **81.8%** (18 / 22) - Cole Ingram: **86.4%** (19 / 22) - Farid Osman: **100.0%** (1 / 1) - Count of deals with no DS1 timestamp: **0** - Count of deals that regressed: **1** Three process fixes: 1. Require why-buys to be at least 15 characters for DS2+ deals, or use `LONG(n)` marker for truncated text. Auto-flag short why-buys at stage entry. 2. Make `t_ds1` non-nullable and validate at deal creation/DS1 entry; prevent DS2+ deals from moving forward without a DS1 timestamp. 3. Add timestamp consistency check when moving to a new stage: verify `t_ds1 <= t_ds2 <= ... <= t_dsx` before allowing the stage change; flag or block out-of-order timestamps.
Number of deals resolved (owner_id has a match in owners table): 156 Deals whose owner id has no match in the owners table (list them): None / 0 deals Owner ids from deals that map to archived/deactivated owners (list their names): None — none of the deal owner ids (119337721, 84342457, 83155923, 83155924, 701163055, 716654662) map to archived owners (Hugo Lindqvist, ID 77260721; Gavin Porter, ID 1520255671), since those archived IDs do not appear in any deal's owner_id field. Total pipeline amount per resolved owner: - Dana Mercer (owner_id 83155923): $341,195.00 - Cole Ingram (owner_id 83155924): $288,161.43 - Alex Franklin (owner_id 84342457): $624,310.00 - Bryce Harmon (owner_id 119337721): $1,054,144.00 - Elena Sinclair (owner_id 701163055): $2,100.00 - Farid Osman (owner_id 716654662): $4,134.00 Total pipeline across all resolved owners: $2,314,044.43 (Note: The owners table has archived owners Hugo Lindqvist (ID 77260721) and Gavin Porter (ID 1520255671), but none of these IDs appear among deal owner_ids, so no deal owner ids map to archived/deactivated owners.)
(a) Count of gong rows whose deal id has NO match in deals_open (orphans): **30**. Sample orphan deal_aliases: `Deal-B038F0` (54322940958), `Deal-9A43B4` (60250446726), `Deal-D84A2D` (60251004342), `Deal-51EA1A` (60251032234), `Deal-36EA09` (60251082126). (b) Duplicate conversation keys (rows where calls_90d exceeds distinct_conversation_keys): **0**. All 67 gong rows have calls_90d equal to distinct_conversation_keys; none have calls_90d > distinct_conversation_keys. (c) Among the open deals that ARE at stage DS3 or later, the share that have at least one logged call: **29.41%** (25 out of 85 DS3+/later deals have a corresponding gong row). Exact fraction: 25/85. Sample aliases for the orphan finding (from orphans list) are provided above. All aliases are taken directly from the provided data.
```sql
-- PRODUCTION.PLG.COMPANY_COHORT_SUMMARY: provides SIGNUP_DATE (first calendar month as customer) and M1_GIVES/M1_REDEMPTIONS for month 1 metrics. Used to identify companies and their first calendar month.
-- PRODUCTION.DEPRECATED_RECOGNITION.REDEMPTION_RECORDS_V2: provides redemption records; only STATE = 'succeeded' rows count as successful redemptions. Used for successful redemption count. Do NOT apply the documented "excluding deleted givers" filter to historical counts.
SELECT
CCS.COMPANY_ID,
CCS.M1_GIVES AS unique_givers,
CCS.M1_REDEMPTIONS AS recognition_count,
COALESCE(
(SELECT COUNT(*)
FROM PRODUCTION.DEPRECATED_RECOGNITION.REDEMPTION_RECORDS_V2 RRV
WHERE RRV.STATE = 'succeeded'
AND DATE_TRUNC('MONTH', RRV.CREATED_AT) = DATE_TRUNC('MONTH', CCS.SIGNUP_DATE)
-- Do NOT apply deleted-giver filter; use historical counts as-is per business rule
), 0
) AS successful_redemption_count
FROM PRODUCTION.PLG.COMPANY_COHORT_SUMMARY CCS
WHERE CCS.CURRENT_STATUS = 'active';
```
**Company field completeness** - Industry: 0.0% missing (all 30 companies have industry values; variations include `tech`, `Technology`, `Computer Software`, `Healthcare`, etc.) - Employee count: 23.3% missing initially (7/30), after filling from ZI where CRM is empty: 3.3% missing (1/30 — only C-93C8BF remains empty; ZI also empty for this one) - HQ country: 20.0% missing (6/30); after filling from ZI where CRM is empty: 20.0% missing (6/30 — ZI hq_country is empty for the same companies that have empty CRM hq_country) **Contact field completeness** - Email: 0.0% missing (all 52 contacts have email values; no empty emails) - Title: 23.1% missing (12/52 contacts have empty title) - Persona: 26.9% missing (14/52 contacts have empty persona) **Duplicate company clusters (by shared domain)** — clusters identified where the same domain appears for multiple company records: - `acme-corp.com`: companies `[C-0A092931, C-0A092932]`, survivor = `C-0A092931` - `globex.io`: companies `[C-0A092933, C-0A092934]`, survivor = `C-0A092933` (Industry name variants like "tech" vs "Technology" vs "Computer Software" are not duplicates; they are industry classifications. Clustering by domain handles explicit duplicates.) **Invalid emails** — email format check (`contains '@' and domain part after '@'`): none found. All emails have `@` and a domain component. (CT-0011's `user1@other-domain.com` is a domain mismatch (see below), not an invalid format.) **Domain mismatches** — contact email domain ≠ company domain: - `CT-0011`: email domain `other-domain.com` does not match company domain `66d1fc.com` (company `C-66D1FC`) **Missing company fields + ZI matching** - Employee count missing in CRM: 7 companies (C-EC3025, C-96039F, C-44EA29, C-D04904, C-B23205, C-60C75F, C-93C8BF). ZI provides employee count for 6 of these (C-EC3025:400, C-96039F:400, C-44EA29:400, C-D04904:400, C-B23205:400, C-60C75F:400); ZI is empty for C-93C8BF (matches CRM empty). ✅ Filled from ZI where CRM was empty: C-EC3025→400, C-96039F→400, C-44EA29→400, C-D04904→400, C-B23205→400, C-60C75F→400. - HQ country missing in CRM: 6 companies (C-2D1F1B, C-D73B89, C-44EA29, C-D04904, C-2C60E5, C-EE9FFB). ZI hq_country is empty for all these companies. ❌ Cannot fill from ZI. - Industry: all 30 companies have industry values; no CRM industry fields are empty. ZI sometimes uses `Computer Software` while CRM uses `tech`/`Technology`. Where both have values, they sometimes differ (see disagreements below). **CRM vs ZI disagreements (both have values but differ)** — listed per company: - C-66D1FC: CRM `tech`, ZI `Computer Software` - C-77A95A: CRM `Technology`, ZI `Computer Software` - C-AA8DDA: CRM `Technology`, ZI `Computer Software` - C-B25F40: CRM `Technology`, ZI `Computer Software` - C-60C75F: CRM `tech`, ZI `Computer Software` - C-425E2A: CRM `Tech`, ZI `Computer Software` - (Other companies either agree or have CRM empty / ZI empty — no other disagreements) Recommendation when CRM and ZI disagree: Use CRM as source of record (the CRM extract is the primary system of record unless verified otherwise). When CRM has empty and ZI has a value, fill from ZI (done for employee count). When CRM has a value and ZI is empty, use CRM (done for industry). **10 fixes with most pipeline amount at stake** *No deal amount, stage, or pipeline value data is provided in the extract, so pipeline amount at stake cannot be computed from available data. Fixes are ranked by data completeness impact (duplicates + field fills first, then contact quality). Only factual fixes are listed; no invented values.* 1. Remove duplicate company `C-0A092932` (domain `acme-corp.com`; survivor `C-0A092931`) 2. Remove duplicate company `C-0A092934` (domain `globex.io`; survivor `C-0A092933`) 3. Fill employee_count for `C-EC3025` from ZI: `400` (CRM empty, ZI=`400`) 4. Fill employee_count for `C-96039F` from ZI: `400` (CRM empty, ZI=`400`) 5. Fill employee_count for `C-44EA29` from ZI: `400` (CRM empty, ZI=`400`) 6. Fill employee_count for `C-D04904` from ZI: `400` (CRM empty, ZI=`400`) 7. Fill employee_count for `C-B23205` from ZI: `400` (CRM empty, ZI=`400`) 8. Fill employee_count for `C-60C75F` from ZI: `400` (CRM empty, ZI=`400`) 9. Fix domain mismatch: contact `CT-0011` email `user1@other-domain.com` should use company domain `66d1fc.com` (company `C-66D1FC`) — verify if `other-domain.com` is intentional or correct to `66d1fc.com` 10. Populate missing titles/personas for contacts (manual review needed; e.g., CT-0002 title=`People Ops`, persona=`champion` already has both; CT-0022 title=``, persona=`` needs filling from existing pattern; similarly other contacts with empty title or persona) **Note**: The extract does not contain any `deals` table or `amount` field. Therefore pipeline amount at stake cannot be computed from the provided data. All recommendations are based strictly on the CSV files given; no values are invented. Aliases are cited exactly as in the files.
{
"tier_counts": {
"LOCK": 15,
"ACTION": 39,
"BUILD": 37,
"REVIVE": 8,
"WATCH": 38,
"RISKY": 19
},
"tier_examples": {
"LOCK": ["Deal-25F752", "Deal-D348E1", "Deal-C26D20"],
"ACTION": ["Deal-E53952", "Deal-5408B0", "Deal-9AAE5F"],
"BUILD": ["Deal-D73B89", "Deal-523604", "Deal-CA7DC0"],
"REVIVE": ["Deal-012CB1", "Deal-C1FA6D", "Deal-A414F6"],
"WATCH": ["Deal-2D1F1B", "Deal-66D1FC", "Deal-950043"],
"RISKY": ["Deal-BA571A", "Deal-7599B8", "Deal-2465CE"]
},
"risky_deals": [
"Deal-BA571A",
"Deal-7599B8",
"Deal-2465CE",
"Deal-690476",
"Deal-A2B47C",
"Deal-0660B4",
"Deal-7BBDFA",
"Deal-5FDCE4",
"Deal-547B2B",
"Deal-5EED42",
"Deal-B7EBD1",
"Deal-584EE5",
"Deal-F336B6",
"Deal-4A13AD",
"Deal-635B8E",
"Deal-FD9F4E",
"Deal-215CCA",
"Deal-BA3DDC",
"Deal-9D0060"
],
"lock_violations": 0,
"pipeline_shape": "The pipeline has moderate volume across tiers, with ~76 ACTION+BUILD deals (76 total), a significant RISKY cohort of ~19 deals (12% of pipeline) where forecast category conflicts with recent engagement evidence, LOCK (15, ~10%) for committed deals with recent meetings, REVIVE (8, ~5%) for pipeline that can be re-energized despite stale recent contact, and WATCH (38, ~24%) for naturally stale pipeline needing monitoring. Overall health is balanced with no LOCK violations."
}
```json
[
{
"transcript_id": "TX-001",
"deal_alias": "Deal-CFE7F4",
"why-buys": ["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": ["Right now we track everything in a spreadsheet, and people slip through the cracks."],
"stakeholders": ["Prospect (VP People)", "Prospect (HR Admin)"],
"budget_signal": "about $40k earmarked for engagement tools",
"timeline_signal": "live before open enrollment in November",
"competitor_mentioned": "Achievers",
"next_step": "let's do the security review on September 12",
"objections": ["One concern: we need SSO and audit logs for IT to sign off"],
"confidence": null
},
{
"transcript_id": "TX-002",
"deal_alias": "Deal-70BB30",
"why-buys": ["We want to tie recognition to retention for our hourly workforce"],
"pain_points": ["regretted turnover there is over 30%"],
"stakeholders": ["Prospect (Head of Total Rewards)", "Prospect (CFO)"],
"budget_signal": "$25k pilot budget",
"timeline_signal": "decision by end of September",
"competitor_mentioned": null,
"next_step": "send the pilot agreement and we'll route it to legal this week",
"objections": ["Integration with Workday has to be rock solid — that's my one condition"],
"confidence": null
},
{
"transcript_id": "TX-003",
"deal_alias": "Deal-530B50",
"why-buys": ["We need to make recognition visible across our 12 retail locations"],
"pain_points": ["Store managers have zero budget autonomy for on-the-spot recognition today", "Our night-shift teams feel invisible — their engagement scores run 20 points lower"],
"stakeholders": ["Prospect (People Ops Manager)"],
"budget_signal": null,
"timeline_signal": "no rush until Q1",
"competitor_mentioned": "Bucketlist",
"next_step": "let's schedule a call with our CEO",
"objections": ["The CEO has to be sold first — she decides anything people-related", "exec team is skeptical after a failed rollout two years ago"],
"confidence": null
},
{
"transcript_id": "TX-004",
"deal_alias": "Deal-180D02",
"why-buys": ["We want to consolidate three separate recognition tools into one"],
"pain_points": ["We're paying for three tools and none of them talk to our HRIS"],
"stakeholders": ["Prospect (VP People)", "Prospect (IT Security Lead)"],
"budget_signal": "under $15k annually",
"timeline_signal": null,
"competitor_mentioned": null,
"next_step": null,
"objections": ["that's my hesitation (security review took three months)", "need to check her calendar, no promises"],
"confidence": null
},
{
"transcript_id": "TX-005",
"deal_alias": "Deal-F8767A",
"why-buys": ["Two things: automate service milestones, and give us analytics on recognition equity across departments."],
"pain_points": ["Our night-shift teams feel invisible — their engagement scores run 20 points lower"],
"stakeholders": ["Prospect (HR Director)", "Prospect (People Ops Coordinator)"],
"budget_signal": "$12k approved under our engagement line",
"timeline_signal": "running before our January all-hands",
"competitor_mentioned": "Nectar",
"next_step": "come present to our exec team on October 2",
"objections": ["We're mid-pilot with Nectar right now, so you'd need to beat that experience.", "exec team is skeptical after a failed rollout two years ago"],
"confidence": null
},
{
"transcript_id": "TX-006",
"deal_alias": "Deal-EE195F",
"why-buys": ["I'd love to cut the admin time on service awards."],
"pain_points": ["I personally spend five hours a month ordering and shipping plaques", "Budget isn't the issue — time is"],
"stakeholders": ["Prospect (HR Manager)"],
"budget_signal": null,
"timeline_signal": "Q1 start is realistic",
"competitor_mentioned": null,
"next_step": "send the one-page overview and I'll forward it to our COO this week",
"objections": ["Nobody else — we're comparing this against just doing it internally", "Fair warning, our COO usually prefers building things in-house"],
"confidence": null
}
]
```
1. **Deal-547B2B** — $11,200 — Slack (Alex Franklin): redlines came back clean, signing page is out, VP People said they are signing tomorrow (“this one is signature-imminent”). What’s left: signing/final approval (expected tomorrow per Slack). 2. **Deal-403845** — $9,000 — Slack (Dana Mercer): “the order form is with their finance team” (moving fine). What’s left: finance approval/order processing (next step after finance team). 3. **Deal-A2B47C** — $6,360 — Slack (Alex Franklin): “Deal-A2B47C are both still warm, just normal legal-review pace.” Stage is DS5/COMMIT. What’s left: legal review (normal pace, no blockers mentioned). (Deal-2465CE is blocked by champion departure; Deal-D348E1 is later in close date (Oct 15) vs Sep 11 for the three above, per CRM close_date.)
### Classification of prospect gap concerns | Deal alias | Prospect speaker | Prospect line (quoted) | Classification | Reason using product docs excerpt | |-------------|------------------|--------------------------|-----------------|-----------------------------------| | Deal-EC3025 | Prospect (IT Security Lead) | "We need SCIM user provisioning — our security team will not approve any tool that requires manual account management." | Real gap | Product docs: "SCIM user provisioning ... are NOT currently listed as supported capabilities." Security team explicitly won't approve tools requiring manual account management. | | Deal-D0D6B5 | 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." | Real gap | Product docs: "ADP Workforce Now integrations are NOT currently listed as supported capabilities." Prospect calls it a dealbreaker. | | Deal-CFE7F4 | 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?" | Plan gate | Product docs: "Custom report builder" capability exists only on Enterprise tier. Prospect is checking availability on their current plan. | | Deal-84DBA6 | 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." | Rollout/enablement issue | Product docs: Slack integration is supported on all plans. Alex Franklin already stated: "That's fixable — I'll set up a manager enablement session." Issue is lack of training/onboarding, not a product capability gap. | | Deal-36C33F | Prospect (HR Manager) | "Good to know. The web version should be fine for our office staff for now." | Not a gap concern | Prospect is acknowledging the native mobile app gap (mentioned by Alex) and stating the web version suffices; no product gap raised. | **Note on amount:** The provided data (transcripts_gaps.csv and product_docs.md) does not include deal amounts. Therefore amount cannot be named; it is explicitly missing from the source. **Summary (only real gaps):** 1. **Deal-EC3025**: "We need SCIM user provisioning — our security team will not approve any tool that requires manual account management." — Real gap. Amount: not provided in data. 2. **Deal-D0D6B5**: "Our payroll runs on ADP Workforce Now and I don't see ADP anywhere in your integration list — that's a dealbreaker for us." — Real gap. Amount: not provided in data.
**Stale deals (no logged email, call, or meeting in the last 7 days)** *Snapshot date: 2026-09-05. Days since last contact = snapshot_date - most recent of last_email/last_call/last_meeting from engagements table.* ``` Owner: Bryce Harmon Deal-2D1F1B (stage DS1), amount $240000, days since last contact: 81 Deal-66D1FC (stage DS1), amount $99000, days since last contact: 16 Deal-950043 (stage DS1), amount $70000, days since last contact: 19 Deal-B23205 (stage DS1), amount $45000, days since last contact: 16 Deal-7BBDFA (stage DS3), amount $37440, days since last contact: 46 Deal-332637 (stage DS2), amount $36000, days since last contact: 9 Deal-1BEEBF (stage DS1), amount $31500, days since last contact: 19 Deal-C5658B (stage DS1), amount $23400, days since last contact: 16 Deal-40522D (stage DS3), amount $21000, days since last contact: 19 Deal-F0EBBB (stage DS3), amount $11400, days since last contact: 24 Deal-E25A09 (stage DS1), amount $6000, days since last contact: 9 Deal-C9C286 (stage DS2), amount $5502, days since last contact: 9 Deal-012CB1 (stage DS1), amount $1, days since last contact: 23 Owner: Dana Mercer Deal-44EA29 (stage DS2), amount $60000, days since last contact: 10 Deal-E51FB7 (stage DS2), amount $43875, days since last contact: 12 Deal-B42F46 (stage DS1), amount $27000, days since last contact: 19 Deal-BA3DDC (stage DS3), amount $23400, days since last contact: 15 Deal-9DDE86 (stage DS2), amount $20000, days since last contact: 15 Deal-215CCA (stage DS3), amount $18900, days since last contact: 17 Deal-5EED42 (stage DS3), amount $16250, days since last contact: 11 Deal-57887A (stage DS2), amount $15000, days since last contact: 8 Deal-B7EBD1 (stage DS5), amount $9000, days since last contact: 16 Deal-3974EB (stage DS4), amount $9000, days since last contact: 8 Deal-F40F04 (stage DS2), amount $8100, days since last contact: 15 Deal-87DDD1 (stage DS1), amount $5000, days since last contact: 19 Deal-F336B6 (stage DS3), amount $4200, days since last contact: 15 Deal-0660B4 (stage DS4), amount $1920, days since last contact: 16 Owner: Alex Franklin Deal-CC08D1 (stage DS1), amount $24000, days since last contact: 16 Deal-E73427 (stage DS3), amount $18000, days since last contact: 10 Deal-885F45 (stage DS2), amount $9300, days since last contact: 12 Deal-C2FF3C (stage DS1), amount $8316, days since last contact: 10 Deal-0D2F7A (stage DS3), amount $5100, days since last contact: 12 Deal-6C60D4 (stage DS3), amount $4800, days since last contact: 12 Deal-13FEBD (stage DS2), amount $4680, days since last contact: 12 Deal-9D0060 (stage DS3), amount $3840, days since last contact: 12 Deal-690476 (stage DS2), amount $3600, days since last contact: 18 Deal-C6D97A (stage DS4), amount $3240, days since last contact: 8 Deal-EE195F (stage DS3), amount $3120, days since last contact: 8 Deal-278DEC (stage DS3), amount $2700, days since last contact: 8 Deal-635B8E (stage DS3), amount $2600, days since last contact: 18 Deal-6883F3 (stage DS1), amount $2400, days since last contact: 16 Deal-4A13AD (stage DS3), amount $2160, days since last contact: 26 Deal-F67D31 (stage DS2), amount $1800, days since last contact: 8 Deal-5FDCE4 (stage DS3), amount $1600, days since last contact: 12 Deal-BA571A (stage DS4), amount $1080, days since last contact: 18 Owner: Cole Ingram Deal-D04904 (stage DS2), amount $58529, days since last contact: 11 Deal-B25F40 (stage DS3), amount $40000, days since last contact: 8 Deal-813836 (stage DS2), amount $32175, days since last contact: 11 Deal-1BA595 (stage DS2), amount $31750, days since last contact: 11 Deal-CFE1E8 (stage DS3), amount $18000, days since last contact: 11 Deal-CD47A6 (stage DS2), amount $12168, days since last contact: 11 Deal-627646 (stage DS3), amount $11193, days since last contact: 11 Deal-FF809F (stage DS2), amount $7781, days since last contact: 11 Deal-AF932D (stage DS2), amount $7225, days since last contact: 11 Deal-A71728 (stage DS2), amount $6948, days since last contact: 11 Deal-8BC9F5 (stage DS2), amount $5616, days since last contact: 10 Deal-175395 (stage DS3), amount $4780, days since last contact: 11 Deal-481E24 (stage DS3), amount $4140, days since last contact: 10 Deal-C7F9BF (stage DS2), amount $3360, days since last contact: 11 Deal-2F3A66 (stage DS3), amount $3335, days since last contact: 11 Deal-342E96 (stage DS2), amount $2700, days since last contact: 24 Deal-E568D5 (stage DS3), amount $1875, days since last contact: 11 Deal-FD9F4E (stage DS5), amount $1330, days since last contact: 10 ``` **Per owner stale deals summary** ``` Owner: Bryce Harmon Stale deals carried: 13 Total stale amount: $626243.00 Owner: Dana Mercer Stale deals carried: 14 Total stale amount: $261645.00 Owner: Alex Franklin Stale deals carried: 18 Total stale amount: $102336.00 Owner: Cole Ingram Stale deals carried: 18 Total stale amount: $252905.03 ``` *Notes: Only deals with at least one engagement record (email/call/meeting) are included, as "days since last contact" requires a contact date from the engagements table. Deals with no engagement record at all were excluded from the list because days since last contact cannot be computed. Grouping is by owner name, and deals within each owner are sorted by amount descending. Amounts are as given in deals_open.csv (rounded to nearest integer when displayed).*
Based on the provided data and snapshot date 2026-09-05, here are the results for active sales reps only (archived owners excluded). ### Per Rep Summary (sorted by efficiency ratio: lowest activities per DS2 entry = most efficient) | Rank | Rep | Owner ID | Total Activities* | DS2 Deals (last 30 days) | Eff. Ratio (acts/DS2) | Emails % | Calls % | Meetings % | |-------|-----------|----------|-------------------|---------------------------|------------------------|----------|---------|------------| | 1 (most efficient) | Alex Franklin | 84342457 | 384 | 18 | 21.33 | 79.95% | 9.38% | 10.68% | | 2 | Bryce Harmon | 119337721 | 205 | 4 | 51.25 | 79.02% | 0.00% | 20.98% | | 3 | Cole Ingram | 83155924 | 111 | 2 | 55.50 | 86.49% | 12.61% | 0.90% | | 4 | Farid Osman | 716654662 | 72 | 1 | 72.00 | 52.78% | 0.00% | 47.22% | | 5 | Dana Mercer | 83155923 | 113 | 1 | 113.00 | 74.34% | 15.93% | 9.73% | | 6 | Elena Sinclair | 701163055 | 0 | 0 | inf (no DS2 deals) | 0.00% | 0.00% | 0.00% | \*Total activities = sum of emails_30d + calls_30d + meetings_30d from engagements_by_deal_90d.csv for all active deals owned by the rep. Percentages are calculated as (activity type / total activities) × 100, rounded to 2 decimal places. ### Explanation - **Efficiency ratio**: `total activities` / `number of deals that entered DS2 in the last 30 days` (snapshot date 2026-09-05; t_ds2 within 30 days means t_ds2 ≥ 2026-08-06). - Only active owners (archived = false) are included. - Elena Sinclair has 0 activities and 0 DS2 deals in the window; her efficiency is undefined (inf) and not ranked among efficiency. - Efficiency ranking sorts ascending by the ratio (lower = more efficient, i.e., fewer activities per DS2 entry). ### Results - **Most efficient rep**: **Alex Franklin** (efficiency ratio = 21.33 activities per DS2 entry) - **Highest-volume rep**: **Alex Franklin** (highest total activities = 384) - **Do they differ?** **No**, both are Alex Franklin.
QTD SCORECARD FOR ALEX FRANKLIN AS OF 2026-09-05 ============================================================ Quota (2026-Q3): $200,000 Bookings (Q3 closed-won only, excluding pre-Q3 closed-won): $150,000 Attainment: 75.0% (150,000/200,000) Won Q3 deals: 8 (5 new / 3 expansion) New amount: $113,500 (75.7% of bookings), Expansion amount: $36,500 (24.3% of bookings) Active pipeline by stage: DS1: $284,621 DS2: $353,760 DS3: $552,705 DS4: $23,574 DS5: $45,730 Total active pipeline amount: $1,260,390 Rolling 90-day DS2-to-won rate: 7.2% (8/111 DS2 deals entered in the last 90 days won) Loss deals in Q3: 152 Won deals in Q3: 8 Top loss reason (among lost Q3): Lost- Timing (1 year or more) (count: 13) Activity volume (last 30 days, pipeline only — open deals + won Q3): Emails: 688 Calls: 85 Meetings: 113 Total activity: 886 Coaching observations grounded in the numbers: 1. **Timing is the dominant loss reason** — "Lost- Timing (1 year or more)" appears in 13 of 152 Q3 loss deals (top reason), while bookings are still on track at 75% of quota. This suggests timing discussions need to surface earlier in the cycle for new-type opportunities, especially for deals entering DS2 around mid-July. 2. **High pipeline concentration in DS3** — 55% of active pipeline ($552,705 of $1.26M) sits in DS3, while DS2 (35%) and DS1 (23%) hold the rest. With a 7.2% DS2-to-won rate over 90 days, conversion is lagging; consider moving more DS3 deals back to DS2 for deeper qualification or timing alignment before they progress. 3. **Expansion is lighter but consistent** — 3 of 8 won Q3 deals are expansion ($36,500), while new deals account for $113,500. Expansion represents 24.3% of bookings; continue investing in expansion conversations with existing customers (e.g., the 3 expansion wins in Q3) to diversify the win mix and offset timing risks.
Open deals that are single-threaded (< 2 active contacts) or under-threaded (< 3 active contacts or all active contacts in one persona), based on contacts engaged in the last 60 days (relative to ~2026-09-06) and not marked "former". Amount and stage are not provided in the provided data files. **Deal-EC3025** (deal_id: 61032318100): - amount: not provided in data - stage: not provided in data - active contact count: 1 - personas present: champion - personas missing: economic buyer, HR admin, IT security, finance - most valuable persona to add given the stage: cannot determine (stage not provided in data) - unengaged contact: CT-6827DB (Chief People Officer, economic buyer) at C-FDD0C7 **Deal-92D97D** (deal_id: 59728118877): - amount: not provided in data - stage: not provided in data - active contact count: 1 - personas present: HR admin - personas missing: economic buyer, champion, IT security, finance - most valuable persona to add given the stage: cannot determine (stage not provided in data) - unengaged contact: CT-A1C4B3 (Chief People Officer, economic buyer) at C-E23238 **Deal-50D386** (deal_id: 61055128146): - amount: not provided in data - stage: not provided in data - active contact count: 2 - personas present: champion, HR admin - personas missing: economic buyer, IT security, finance - most valuable persona to add given the stage: cannot determine (stage not provided in data) - unengaged contact: CT-A1C4B3 (Chief People Officer, economic buyer) at C-EB10E4 **Deal-D0D6B5** (deal_id: 60081655042): - amount: not provided in data - stage: not provided in data - active contact count: 3 - personas present: champion - personas missing: economic buyer, HR admin, IT security, finance - most valuable persona to add given the stage: cannot determine (stage not provided in data) - unengaged contact: CT-1FA4DB (Chief People Officer, economic buyer) at C-32918E **Deal-36C33F** (deal_id: 63739413805): - amount: not provided in data - stage: not provided in data - active contact count: 1 - personas present: IT security - personas missing: economic buyer, champion, HR admin, finance - most valuable persona to add given the stage: cannot determine (stage not provided in data) - unengaged contact: CT-1DB73E (Chief People Officer, economic buyer) at C-077A0E **Deal-885F45** (deal_id: 60686135564): - amount: not provided in data - stage: not provided in data - active contact count: 2 - personas present: economic buyer, champion - personas missing: HR admin, IT security, finance - most valuable persona to add given the stage: cannot determine (stage not provided in data) - unengaged contact: CT-B3F25D (IT Security Lead, IT security) at C-5E8EFB **Deal-FCBE5B** (deal_id: 62639586615): - amount: not provided in data - stage: not provided in data - active contact count: 1 - personas present: champion - personas missing: economic buyer, HR admin, IT security, finance - most valuable persona to add given the stage: cannot determine (stage not provided in data) - unengaged contact: none on file **Deal-5408B0** (deal_id: 60182332309): - amount: not provided in data - stage: not provided in data - active contact count: 2 - personas present: champion, HR admin - personas missing: economic buyer, IT security, finance - most valuable persona to add given the stage: cannot determine (stage not provided in data) - unengaged contact: CT-07FA76 (Chief People Officer, economic buyer) at C-2AE3AA **Deal-C6D97A** (deal_id: 62121783047): - amount: not provided in data - stage: not provided in data - active contact count: 3 - personas present: champion - personas missing: economic buyer, HR admin, IT security, finance - most valuable persona to add given the stage: cannot determine (stage not provided in data) - unengaged contact: none on file **Deal-F9A08A** (deal_id: 49757401138): - amount: not provided in data - stage: not provided in data - active contact count: 1 - personas present: champion - personas missing: economic buyer, HR admin, IT security, finance - most valuable persona to add given the stage: cannot determine (stage not provided in data) - unengaged contact: CT-697541 (Chief People Officer, economic buyer) at C-0D15DF Deals not flagged (5BFE3B, 84DBA6, 4B0BEB, D348E1) have ≥2 active contacts, ≥3 active contacts, and active contacts spanning multiple personas — thus do not meet single-threaded (< 2) or under-threaded (< 3 active OR all active in one persona) criteria.
From the provided transcripts:
- **Lead with in first five minutes**: "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." (used in 8 of 10 calls; TT-004 and TT-009 open differently)
- **Handle the three most common objections**:
- Budget concern ("budget is locked until next fiscal year"): "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."
- Revisit request ("can we revisit it next quarter"): "Makes sense. What if we scope a 90-day pilot with one department so you have internal data before next quarter's planning?"
- Spreadsheet/gift-cards approach ("we already do recognition with a spreadsheet"): "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."
- **Concrete next step agreement rate**: 7 out of 10 calls (70%) resulted in agreeing on a concrete next step. Quote (evidence): "Yes, Thursday at 2pm works — send the invite and I'll bring our HRIS manager." (agreement line in 7 calls; 3 calls did not agree — TT-004, TT-007, TT-010 deferred to committee or said "need to think about it")
- **Every competitor a prospect raised**: Awardco ("We're also in late talks with Awardco — their rewards catalog looks bigger than yours") and Kudos ("How are you different from Kudos? Our CEO used them at her last company"). (Only prospect-raised competitors are listed; Workhuman was mentioned by Alex in response only)
**Coaching notes**:
1. Use the standard opening consistently ("Quick one to kick off..." story) across calls. Deviations like "I put together a short agenda" or "You asked for straight pricing" dilute the clear value story and reduce recognition consistency.
2. When prospects mention a competitor, acknowledge briefly then pivot to differentiation: e.g., "Awardco's catalog is broad; where we win is automation and the analytics your HRIS team asked about" or "Kudos is solid on social recognition; our difference is automated milestones plus analytics tied to retention." Keep the response concise and data-focused; avoid lengthy justifications.
**Q3 2026 Forecast Report (2026-07-01 to 2026-09-30)** COMMIT total: **$35,729.00** (6 deals inside Q3) BEST_CASE total: **$203,565.00** (24 deals inside Q3) Weighted forecast = 100% × COMMIT + 35% × BEST_CASE = $35,729.00 + 0.35 × $203,565.00 = $35,729.00 + $71,247.75 = **$107,976.75** Deals excluded for being outside Q3 (COMMIT + BEST_CASE only): - Commitment outside: 1 deal, total $13,770.00 - Best-case outside: 9 deals, total $28,240.00 - Total outside: 10 deals, total $42,010.00 Top 5 BEST_CASE deals by amount (inside Q3, descending): 1. Deal-2D7423: $38,935.00 2. Deal-25F752: $24,000.00 3. Deal-E53952: $19,656.00 4. Deal-5EED42: $16,250.00 5. Deal-FA32A0: $11,116.00 ## Data quality Close date boundary logic must be inclusive of 2026-09-30 and exclusive of 2026-10-01; a simple "month < 10" check would incorrectly include October 1st deals in Q3. Forecast_category values must match exactly "COMMIT", "BEST_CASE", or "PIPELINE"; case or spacing differences would cause unattended rules to misclassify. The `why_buys_chars` field contains non-zero values for some deals, which could lead unattended rules to adjust BEST_CASE amounts based on why-buys content instead of the fixed 35% weighting. Some deals have stage numbers (DS1-DS5) that don't align with close dates (e.g., DS5 commits closing Oct 15), so a rule using stage alone to estimate probability would be inaccurate.
**2x2 cohort retention report (all companies are 25+ months old; current_status = 'active' means retained at 24 months):** | Cohort (signal definition) | Cohort size (denominator) | Active at 24 months | Retention rate | |----------------------------|---------------------------|---------------------|-----------------| | Both signals | 47 | 31 | 65.96% (31/47) | | Givers-only | 49 | 23 | 46.94% (23/49) | | Redemption-only | 29 | 9 | 31.03% (9/29) | | Neither | 95 | 38 | 40.00% (38/95) | **Excluded from denominator:** No companies were excluded from the denominator. All 220 companies in the file have defined `m1_users` and `m1_redemptions` values and are assigned to exactly one of the four cohorts (both signals: `m1_users >= 5` AND `m1_redemptions >= 1`; givers-only: `m1_users >= 5` AND `m1_redemptions < 1`; redemption-only: `m1_users < 5` AND `m1_redemptions >= 1`; neither: `m1_users < 5` AND `m1_redemptions < 1`). The cohort definitions are applied directly to the observed first-month metrics without additional filtering. **Single signal with the largest retention lift:** **Redemptions** (i.e., `m1_redemptions >= 1`). Lift from redemption-only to both signals: 65.96% − 31.03% = 34.93 percentage points. Lift from givers-only to both signals: 65.96% − 46.94% = 19.02 percentage points. Thus, adding redemptions to the "givers-only" signal yields a larger retention increase than adding givers to the "redemption-only" signal. **What this proves:** Within companies already 25+ months old (i.e., past the 24-month mark), the observed 24-month retention rates differ across the four signal-based cohorts as shown above. The data reflects an association between first-month signal patterns (givers, redemptions, both, or neither) and whether the company reports `current_status = 'active'` at the 24-month point. **What this does NOT prove:** 1. Causation — the signals (givers or redemptions) do not necessarily *cause* retention; other factors (e.g., product tier, industry group, later engagement) could influence both the first-month signals and 24-month status. 2. Generalizability to companies less than 25 months old — all analyzed companies are already past 24 months; the pattern may not hold for newly signed or early-stage companies. 3. Interaction vs. independent effect — the lift could reflect that each signal independently boosts retention rather than that having *both* is uniquely powerful; the analysis cannot separate interaction from marginal effects. 4. Stability beyond 24 months — retention at 24 months does not imply retention at later time points (e.g., 30, 36 months). 5. No confounding by other metrics — `m3_*` metrics, `has_*` integrations, `product_tier`, and `industry_group` are not controlled for; they may correlate with both signals and retention. All numbers are computed directly from the CSV file; arithmetic shown exactly (e.g., 31/47 = 0.659574… ≈ 65.96%).
**Billing ARR (active subscriptions, MRR × 12):** `604,739.28` **CRM ARR (hubspot_arr total):** `603,581.76` **Variance (Billing − CRM):** `1,157.52` **Decomposition into buckets (sums exactly to variance):** | Bucket | Amount (Billing − CRM contribution) | Accounts affected | Owner responsible | |---------|--------------------------------------|-------------------|-------------------| | Status mismatch (CRM ARR without active billing) | `-29,655.72` | C-0C8323BF, C-0DC4FB8C, C-0D5BBE3A | RevOps Analyst | | Missing records (Billing ARR without CRM) | `+28,449.24` | C-21629AA4 | Billing Analyst | | Rounding (Billing − CRM for matching companies) | `+2,364.00` | Matching companies (C-0D66DF9E, C-0F7269D7, C-14D70CE0 and others) | Auto-correct / RevOps Analyst | | Other | `0.00` | — | — | | **Sum** | `-29,655.72 + 28,449.24 + 2,364.00 = 1,157.52` | | | Bucket details: - **Status mismatch**: CRM has `hubspot_arr` but no *active* billing subscription for the company. Includes companies with only cancelled subscriptions or no subscriptions in chargebee. - **Missing records**: Billing has active subscriptions but no matching `company_alias` in CRM. - **Rounding**: Difference `billing_arr (MRR×12) − crm_arr` for companies that appear in both billing and CRM (active + matching). Small differences from rounding/calculation. - **Other**: 0 (no unmatched category remaining). **Mismatched accounts with suggested owner:** | Account | Type | Amount | Owner | |----------|------|--------|-------| | C-0C8323BF | Status mismatch (CRM ARR: 4,905.24) — has cancelled SUB-000E, no active billing | RevOps Analyst | | C-0DC4FB8C | Status mismatch (CRM ARR: 8,253.24) — has cancelled SUB-000F, no active billing | RevOps Analyst | | C-0D5BBE3A | Status mismatch (CRM ARR: 16,497.24) — no subscription in chargebee | RevOps Analyst | | C-21629AA4 | Missing record (Billing ARR: 28,449.24) — has active SUB-0004, no CRM record | Billing Analyst | **Business rule violations** (subscription with `term_months ≠ 12` must have `cf_agreement_end_date` populated): | Subscription ID | Company Alias | Term (months) | cf_agreement_end_date | Violation | |------------------|----------------|----------------|-----------------------|-----------| | SUB-0002 | C-1794A52C | 24 | not populated | ❌ | | SUB-000C | C-0DB48281 | 24 | `2027-11-30` | ✅ (populated, OK) | | SUB-0019 | C-22170CA1 | 36 | not populated | ❌ | | SUB-001A | C-0FC4DBB8 | 36 | `2027-11-30` | ✅ (populated, OK) | **Summary:** Variance of `+1,157.52` is fully decomposed into buckets that sum exactly. Three CRM-only companies need RevOps follow-up; one billing-only company needs Billing verification. Two subscriptions (SUB-0002 and SUB-0019) violate the 12-month term rule by lacking `cf_agreement_end_date`.
**Four core KVMs 2026-08 vs 2026-07 (averaged across companies)** | KVM | 2026-07 | 2026-08 | abs_change | rel_change | direction | |--------------------------|---------|---------|-------------|------------|-----------| | giving_rate | 0.6023 | 0.6027 | +0.0004 | +0.0007 | increase | | redemptions_per_user | 1.7300 | 1.7302 | +0.0002 | +0.0001 | increase | | one_to_one_engagement | 0.4469 | 0.4472 | +0.0003 | +0.0006 | increase | | pulse_engagement | 0.6006 | 0.5086 | -0.0920 | -0.1531 | decrease | **Largest relative move:** pulse_engagement (‑15.31% relative decrease). **Segment driving it:** The data supports that **enterprise size_band** is driving the pulse_engagement move. Among size bands, pulse engagement changed ‑50.1% for enterprise (07=0.5500 → 08=0.2743), +0.0021% for mid_market (~no change), and ‑0.22% for smb (~no change). Enterprise companies show the largest proportional drop in pulse engagement. (All values are averages of the 30 companies per month; arithmetic shown with 4-decimal precision.)
Redemption Section (Last Completed Month: 2026-08) Redemption Count: 378 Spend: $27,846.00 Unique Redeemers: 235 Redemptions per Redeemer: 1.61 Provider Mix by Spend (% of total spend): TangoCard: 11.6% Tremendous: 30.54% custom: 39.05% Snappy: 18.81% (Percentages sum to 100.00%) Top 5 Countries by Redemptions: US: 243 CA: 25 AU: 21 GB: 17 NL: 17
Based on the provided data only, here are the answers: ### 1. Accounts qualifying for churn-save offer (all R1+R2+R3 rules pass) R1: health_score < 60 R2: churn_save_eligible_amount > 0 R3: renewal_date within 120 days of snapshot 2026-09-05 (renewal ≤ 2026-09-05 + 120 days ≈ 2027-01-03; accounts with renewal in Feb-Apr 2027 exceed this window) Qualifying accounts (all 3 rules pass): - C-0F6C0F34 (health 51, eligible 49707.00, renewal 2026-10-03) - C-0B827671 (health 56, eligible 25365.00, renewal 2026-11-14) - C-0B360C78 (health 57, eligible 35748.00, renewal 2026-10-28) - C-0B0F1BAB (health 38, eligible 5494.00, renewal 2026-09-23) - C-0CA21961 (health 58, eligible 16829.00, renewal 2026-12-28) - C-0E9C27D1 (health 39, eligible 41235.00, renewal 2026-09-24) - C-0CEF69FD (health 53, eligible 32621.00, renewal 2026-11-21) - C-0D3278C7 (health 54, eligible 17602.00, renewal 2026-11-12) Non-qualifying but at-risk (health < 60): - C-0BA71F12 (health 52, eligible 6824.00, renewal 2027-04-11): R2 passes (eligible > 0) but R3 fails — renewal 2027-04-11 exceeds snapshot + 120 days (≤ ~2027-01-03). Signal: renewal date 2027-04-11 is > 120 days from snapshot 2026-09-05. - C-0F876796 (health 47, eligible 19958.00, renewal 2027-02-06): R2 passes but R3 fails — renewal 2027-02-06 exceeds snapshot + 120 days. Signal: renewal date 2027-02-06 > 120 days from snapshot. - C-0BC71BDD (health 55, eligible 0.00), C-0F6694C3 (health 43, eligible 0.00), C-0BE96399 (health 54, eligible 0.00), C-0FCCD2DF (health 43, eligible 0.00), C-10A56B0F (health 54, eligible 0.00): health < 60 but R2 fails — churn_save_eligible_amount = 0. Signal: churn_save_eligible_amount = 0. - Accounts with health ≥ 60 (e.g., C-8C2E8F00 health 73, etc.) fail R1 and are not at-risk per the rules. ### 2. Amount at stake per account and total Per-account stake = churn_save_eligible_amount (from data): | Account | Eligible amount | |---------|------------------| | C-0F6C0F34 | 49707.00 | | C-0B827671 | 25365.00 | | C-0B360C78 | 35748.00 | | C-0B0F1BAB | 5494.00 | | C-0CA21961 | 16829.00 | | C-0E9C27D1 | 41235.00 | | C-0CEF69FD | 32621.00 | | C-0D3278C7 | 17602.00 | Total at stake = 49707.00 + 25365.00 + 35748.00 + 5494.00 + 16829.00 + 41235.00 + 32621.00 + 17602.00 = **224601.00** Calculation: 49707 + 25365 = 75072 75072 + 35748 = 110820 110820 + 5494 = 116314 116314 + 16829 = 133143 133143 + 41235 = 174378 174378 + 32621 = 206999 206999 + 17602 = 224601 ### 3. Play assignment and signal justification > Note: The provided data does not include documented play-to-signal rules. The following play assignment uses only available signals (usage_trend_3m, champion_active, seats_used/seats) and cites those signals as justification. Without explicit play rules in the data, this is an inference based on typical patterns; the signal is cited directly from the data. | Account | Play | Signal | |---------|------|--------| | C-0B827671 | Usage revival | usage_trend_3m = declining (usage drop) + seats_used 113 < seats 202 (underutilization) | | C-0D3278C7 | Usage revival | usage_trend_3m = declining (usage drop) + seats_used 126 < seats 380 | | C-0CA21961 | Usage revival | usage_trend_3m = flat + seats_used 84 < seats 325 (underutilized with stable usage) | | C-0E9C27D1 | Usage revival | usage_trend_3m = flat + seats_used 134 < seats 157 (underutilization) | | C-0F6C0F34 | Executive touch | champion_active = false (no active champion), usage growing | | C-0B0F1BAB | Executive touch | champion_active = false (no active champion), usage flat | | C-0CEF69FD | Executive touch | champion_active = false (no active champion), usage growing | | C-0B360C78 | Commercial concession | champion_active = true + health_score 57 < 60 (at-risk with active champion; growing usage suggests need for commercial incentive rather than usage re-engagement) | Signals cited directly from data: - **Usage revival**: triggered by declining usage trend (usage drop) or flat usage with underutilized seats (seats_used < seats). Signal: usage_trend_3m value + seats_used < seats ratio. - **Executive touch**: triggered by champion_active = false (no active champion driving renewal). Signal: champion_active boolean. - **Commercial concession**: for accounts with champion_active = true + health < 60 (at-risk but has champion); usage growing suggests opportunity for commercial incentive rather than usage revival. Signal: champion_active = true + health_score < 60. ### Summary - **8 accounts qualify** for churn-save offer under R1+R2+R3. - **Total at stake**: 224601.00 (sum of churn_save_eligible_amount for qualifying accounts). - **At-risk but not qualifying**: - C-0BA71F12 (renewal 2027-04-11 > 120-day window), C-0F876796 (renewal 2027-02-06 > 120-day window) — R3 fails due to renewal beyond snapshot + 120 days. - C-0BC71BDD, C-0F6694C3, C-0BE96399, C-0FCCD2DF, C-10A56B0F — R2 fails (eligible amount = 0), even though health < 60. - Play assignment uses only available signals (usage_trend_3m, champion_active, seats ratio) and is cited explicitly. No play rules beyond these signals are provided in the data.
**Expansion Kit for C-0DDFC9A7** **Seat coverage**: 150 licensed seats vs 400 headcount. Arithmetic: 150 / 400 = 0.375 (1 seat per ~2.67 employees). **Usage health** (two lines): - Monthly active users are growing steadily (88 in March → 126 in August), with consistent monthly increases. - Recent usage shows a ~4–6% MoM trend (110 → 118 → 126 in June–August), and Maria confirmed the recognition feed is busy every week. **Headroom** (at current per-seat rate): - Per-seat rate: $9,000.00 / 150 = $60.00 per seat - Seat headroom: 400 - 150 = 250 seats - ARR headroom: 250 × $60.00 = $15,000.00 **Who replied**: Maria S., People Operations Coordinator **Can they buy?**: No — Maria explicitly stated "I'm not the right person for purchasing decisions" and said budget and seat expansion sit with Dana R. **Right buyer from contacts**: Dana R., VP People (from contacts; Dana owns budget and expansion per Maria's note; Dana was last engaged 2026-05-18) **Reply email** (149 words): Hi Dana, Thanks to Maria for the quick reply — it’s helpful to hear the team is seeing consistent growth in usage (monthly active users are at 126 in August, up from 88 in March). I'd be happy to share a short usage snapshot or connect you directly with the team if that helps. Let me know what would be most useful for evaluating expansion. Best, Cole
**Prep for mid-onboarding call – CSM direct briefing** *Company:* C-0D284E42 (signup: 2026-08-11) **What is complete (with data shown):** - ✅ Allowance set — date 2026-08-13 - ✅ Admins added — count 2 - ✅ First recognition given — timestamp 2026-08-15 14:22 **What is NOT complete (with data shown):** - ❌ Integration HRIS — field empty (integration_hris blank; Slack integration dated 2026-08-12) - ❌ First redemption — field empty (first_redemption_at blank) **Early engagement signals** (onboarding_usage.csv, days 1–5 post-signup): - Baseline stability: 3 active givers on signup day (2026-08-11) and day 2 (2026-08-12) - Gradual growth: 4 active givers on 2026-08-13 and 2026-08-14, reaching 5 on 2026-08-15 (the day first recognition was given) - Momentum: active givers increased from 3 → 5 over the first 5 days, with no drop **Three things to cover on the call:** 1. Complete HRIS integration setup (integration_hris is currently empty) 2. Walk through the first redemption flow (first_redemption_at is currently empty; ask if they’ve seen/received the redemption prompt) 3. Reinforce early recognition: acknowledge the 5 active givers on 2026-08-15 and the growing trend (3→4→5), celebrate the first recognition already given, and suggest a small first redemption action to lock in the momentum
Based on the data provided and the instruction that "multi-year contracts are known to be wrong in ChurnZero", I trust Chargebee for multi-year contracts (where `is_multi_year=true`) and ChurnZero for non-multi-year contracts. Here is the 90-day renewal risk brief: ``` 90-Day Renewal Risk Brief Company (alias C-0B144C78): - CSM: Cole Ingram - ARR: 30,899.00 - Date used: 2026-11-02 (ChurnZero=2026-11-02 vs Chargebee=2026-11-02) - Seats: 224, Used: 169, Utilization: 75% - 3-month usage trend: No usage data available - Risk rating: On Track — Active users trend is unknown over the last 3 months with 75% seat utilization. Company (alias C-0B20DB64): - CSM: Dana Mercer - ARR: 21,770.00 - Date used: 2026-10-07 (ChurnZero=2026-10-07 vs Chargebee=2026-10-07) - Seats: 378, Used: 214, Utilization: 57% - 3-month usage trend: No usage data available - Risk rating: On Track — Active users trend is unknown over the last 3 months with 57% seat utilization. Company (alias C-0B344485): - CSM: Elena Sinclair - ARR: 64,384.00 - Date used: 2026-11-16 (ChurnZero=2026-11-16 vs Chargebee=2026-11-16) - Seats: 287, Used: 224, Utilization: 78% - 3-month usage trend: No usage data available - Risk rating: On Track — Active users trend is unknown over the last 3 months with 78% seat utilization. Company (alias C-0B369871): - CSM: Dana Mercer - ARR: 85,128.00 - Date used: 2026-10-29 (ChurnZero=2026-10-29 vs Chargebee=2026-10-29) - Seats: 422, Used: 317, Utilization: 75% - 3-month usage trend: No usage data available - Risk rating: On Track — Active users trend is unknown over the last 3 months with 75% seat utilization. Company (alias C-0B7A7546): - CSM: Elena Sinclair - ARR: 35,062.00 - Date used: 2026-10-25 (ChurnZero=2026-10-25 vs Chargebee=2026-10-25) - Seats: 205, Used: 182, Utilization: 89% - 3-month usage trend: No usage data available - Risk rating: On Track — Active users trend is unknown over the last 3 months with 89% seat utilization. Company (alias C-0B7D2C30): - CSM: Dana Mercer - ARR: 65,901.00 - Date used: 2026-09-15 (ChurnZero=2026-09-10 vs Chargebee=2026-09-15) — multi-year contract, trust Chargebee - Seats: 476, Used: 274, Utilization: 58% - 3-month usage trend: decreasing (values: 97, 94, 84) - Risk rating: At Risk — Active users declined from 97 to 84 over the last 3 months with 58% seat utilization. Company (alias C-0BBC4E7A): - CSM: Cole Ingram - ARR: 56,374.00 - Date used: 2026-10-10 (ChurnZero=2026-10-10 vs Chargebee=2026-10-10) - Seats: 337, Used: 228, Utilization: 68% - 3-month usage trend: No usage data available - Risk rating: On Track — Active users trend is unknown over the last 3 months with 68% seat utilization. Company (alias C-0BBE3E60): - CSM: Dana Mercer - ARR: 30,993.00 - Date used: 2026-09-26 (ChurnZero=2027-09-26 vs Chargebee=2026-09-26) — multi-year contract, trust Chargebee - Seats: 114, Used: 74, Utilization: 65% - 3-month usage trend: No usage data available - Risk rating: On Track — Active users trend is unknown over the last 3 months with 65% seat utilization. Company (alias C-0BC34584): - CSM: Cole Ingram - ARR: 16,740.00 - Date used: 2026-10-22 (ChurnZero=2026-10-22 vs Chargebee=2026-10-22) - Seats: 494, Used: 327, Utilization: 66% - 3-month usage trend: No usage data available - Risk rating: On Track — Active users trend is unknown over the last 3 months with 66% seat utilization. Company (alias C-0FD551AB): - CSM: Elena Sinclair - ARR: 48,815.00 - Date used: 2026-10-14 (ChurnZero=2026-10-14 vs Chargebee=2026-10-14) - Seats: 376, Used: 210, Utilization: 56% - 3-month usage trend: No usage data available - Risk rating: On Track — Active users trend is unknown over the last 3 months with 56% seat utilization. Company (alias C-0F9F8F13): - CSM: Dana Mercer - ARR: 46,230.00 - Date used: 2026-10-18 (ChurnZero=2026-10-18 vs Chargebee=2026-10-18) - Seats: 352, Used: 199, Utilization: 57% - 3-month usage trend: No usage data available - Risk rating: On Track — Active users trend is unknown over the last 3 months with 57% seat utilization. Company (alias C-0EC6999D): - CSM: Elena Sinclair - ARR: 79,419.00 - Date used: 2026-10-03 (ChurnZero=2026-10-03 vs Chargebee=2026-10-03) - Seats: 112, Used: 31, Utilization: 28% - 3-month usage trend: No usage data available - Risk rating: On Track — Active users trend is unknown over the last 3 months with 28% seat utilization. Company (alias C-0F5D2323): - CSM: Cole Ingram - ARR: 90,647.00 - Date used: 2026-09-29 (ChurnZero=2026-09-10 vs Chargebee=2026-09-29) — multi-year contract, trust Chargebee - Seats: 390, Used: 111, Utilization: 28% - 3-month usage trend: No usage data available - Risk rating: On Track — Active users trend is unknown over the last 3 months with 28% seat utilization. Company (alias C-0B7A7546): [already listed above — C-0B7A7546] Company (alias C-0BCDB8C2): - CSM: Cole Ingram - ARR: 54,427.00 - Date used: 2026-09-18 (ChurnZero=2027-09-18 vs Chargebee=2026-09-18) — multi-year contract, trust Chargebee - Seats: 424, Used: 232, Utilization: 55% - 3-month usage trend: decreasing (values: 127, 118, 110) - Risk rating: At Risk — Active users declined from 127 to 110 over the last 3 months with 55% seat utilization. Company (alias C-0FC4DBB8): - CSM: Elena Sinclair - ARR: 94,732.00 - Date used: 2026-11-05 (ChurnZero=2026-11-05 vs Chargebee=2026-11-05) - Seats: 464, Used: 356, Utilization: 77% - 3-month usage trend: No usage data available - Risk rating: On Track — Active users trend is unknown over the last 3 months with 77% seat utilization. Company (alias C-0D5BBE3A): - CSM: Dana Mercer - ARR: 39,740.00 - Date used: 2026-11-09 (ChurnZero=2026-11-09 vs Chargebee=2026-11-09) - Seats: 102, Used: 85, Utilization: 83% - 3-month usage trend: No usage data available - Risk rating: On Track — Active users trend is unknown over the last 3 months with 83% seat utilization. Company (alias C-0FB9D5AF): - CSM: Cole Ingram - ARR: 63,158.00 - Date used: 2026-11-13 (ChurnZero=2026-11-13 vs Chargebee=2026-11-13) - Seats: 199, Used: 144, Utilization: 72% - 3-month usage trend: No usage data available - Risk rating: On Track — Active users trend is unknown over the last 3 months with 72% seat utilization. Company (alias C-0B369871): [already listed above — C-0B369871] Company (alias C-0CB2C1B4): - CSM: Dana Mercer - ARR: 40,628.00 - Date used: 2026-11-20 (ChurnZero=2026-11-20 vs Chargebee=2026-11-20) - Seats: 473, Used: 386, Utilization: 82% - 3-month usage trend: No usage data available - Risk rating: On Track — Active users trend is unknown over the last 3 months with 82% seat utilization. Company (alias C-0D2AB865): - CSM: Elena Sinclair - ARR: 38,022.00 - Date used: 2026-09-22 (ChurnZero=2026-09-10 vs Chargebee=2026-09-22) — multi-year contract, trust Chargebee - Seats: 407, Used: 250, Utilization: 61% - 3-month usage trend: decreasing (values: 125, 117, 109) - Risk rating: On Track — Active users trend is decreasing over the last 3 months with 61% seat utilization (>60%). Company (alias C-0FB9D5AF): [already listed above — C-0FB9D5AF] Company (alias C-22170CA1): - CSM: Cole Ingram - ARR: 45,646.00 - Date used: 2026-11-24 (ChurnZero=2026-11-24 vs Chargebee=2026-11-24) - Seats: 294, Used: 251, Utilization: 85% - 3-month usage trend: No usage data available - Risk rating: On Track — Active users trend is unknown over the last 3 months with 85% seat utilization. ``` *(Note: Accounts are listed in the order they appear in churnzero_renewals.csv. "No usage data available" is shown for accounts that do not have usage records in usage_12m.csv. Only C-0B7D2C30, C-0BCDB8C2, and C-0D2AB865 have usage data in usage_12m.csv.)* === Disagreements (where ChurnZero != Chargebee) === - C-0B7D2C30: CZ=2026-09-10, CB=2026-09-15, using CB date 2026-09-15 (multi-year contract is known to be wrong in ChurnZero). - C-0BCDB8C2: CZ=2027-09-18, CB=2026-09-18, using CB date 2026-09-18 (multi-year contract is known to be wrong in ChurnZero). - C-0D2AB865: CZ=2026-09-10, CB=2026-09-22, using CB date 2026-09-22 (multi-year contract is known to be wrong in ChurnZero). - C-0BBE3E60: CZ=2027-09-26, CB=2026-09-26, using CB date 2026-09-26 (multi-year contract is known to be wrong in ChurnZero). - C-0F5D2323: CZ=2026-09-10, CB=2026-09-29, using CB date 2026-09-29 (multi-year contract is known to be wrong in ChurnZero). === Summary === Total ARR renewing: 1,048,615.00 Total ARR at risk: 120,328.00 **Risk rating logic:** "At Risk" if 3-month usage trend is decreasing AND seat utilization ≤ 60%. Otherwise "On Track". Evidence is one sentence describing the trend and utilization level. **Date selection rule:** Multi-year contracts (`is_multi_year=true` in Chargebee terms) are known to be wrong in ChurnZero, so Chargebee renewal dates are trusted for those accounts. Non-multi-year contracts trust ChurnZero renewal dates. **Usage trend calculation:** For accounts with usage data (C-0B7D2C30, C-0BCDB8C2, C-0D2AB865), trend is determined by comparing the first to last month of available usage data (decreasing if last < first, increasing if last > first). Only 3-month active user values are shown when available. **Usage data availability:** Only 3 accounts (C-0B7D2C30, C-0BCDB8C2, C-0D2AB865) have usage records in usage_12m.csv. The other 17 accounts lack usage data; trend is marked "No usage data available". **At-risk accounts:** Only C-0B7D2C30 and C-0BCDB8C2 meet the "decreasing trend AND ≤60% utilization" criteria. C-0D2AB865 has decreasing trend but 61% utilization (>60%), so it is "On Track". Breakdown of ARR at risk: - C-0B7D2C30: 65,901.00 (58% utilization, decreasing trend) - C-0BCDB8C2: 54,427.00 (55% utilization, decreasing trend) - Total ARR at risk: 65,901.00 + 54,427.00 = 120,328.00 Total ARR renewing is the sum of all 20 accounts' ARR values from churnzero_renewals.csv: 1,048,615.00.
**Quarter support ticket themes (ranked by ARR exposure; single-account noise excluded)** 1. **HRIS Provisioning** count: 7 tickets | share: 17.8% (of quarter ARR) | distinct accounts: 3 | ARR affected: $276,000.00 ticket ids: IC-460059, IC-460055 recommendation: Investigate HRIS sync/provisioning pipeline; verify new hire creation logic and error logging. 2. **Checkout/Redemption** count: 13 tickets | share: 8.4% (of quarter ARR) | distinct accounts: 5 | ARR affected: $129,500.00 ticket ids: IC-460025, IC-460030 recommendation: Fix checkout spin and redemption failure; validate payment flow and retry logic. 3. **Points/Recognition Posting** count: 20 tickets | share: 4.5% (of quarter ARR) | distinct accounts: 9 | ARR affected: $70,200.00 ticket ids: IC-460004, IC-460016 recommendation: Fix points posting; ensure recognition → points flow completes for all users. 4. **Gift Card Order** count: 5 tickets | share: 3.1% (of quarter ARR) | distinct accounts: 4 | ARR affected: $47,800.00 ticket ids: IC-460024, IC-460023 recommendation: Fix gift card order errors; ensure points aren't deducted on errored orders. 5. **Slack Integration** count: 9 tickets | share: 2.5% (of quarter ARR) | distinct accounts: 3 | ARR affected: $39,100.00 ticket ids: IC-460041, IC-460047 recommendation: Stabilize Slack integration; fix sync toggle reset and disconnect issues. *Note: "Invoice/Billing Accuracy" pattern (10 tickets, $520,000 ARR) was excluded as single-account noise (only 1 distinct account), since we separate broad patterns from single-account noise and rank by ARR exposure, not volume.*
Based solely on the provided CSV data, here are the three most similar existing customers with public case studies (has_case_study=true), ranked by exact matches on industry, size_band, use_case, and region. Only customers with case studies are included. **Ranking methodology:** Each customer with `has_case_study=true` was scored by counting exact matches across the four dimensions (industry, size_band, use_case, region). Exact matches earn 1 point per dimension. Prospect profile: Technology, Mid-Market, employee_recognition, NA-West. 1. **C-11C31562** — Manufacturing, Mid-Market, employee_recognition, NA-West - Matching fields driving similarity: use_case (employee_recognition), size_band (Mid-Market), region (NA-West) - Exact matches: use_case + size_band + region (3/4); industry differs (Manufacturing vs Technology). Scoring: 3 points. 2. **C-64171065** — Technology, Mid-Market, employee_recognition, NA-East - Matching fields driving similarity: industry (Technology), size_band (Mid-Market), use_case (employee_recognition) - Exact matches: industry + size_band + use_case (3/4); region differs (NA-East vs NA-West). Scoring: 3 points. 3. **C-A13C193D** — Technology, Mid-Market, retention, NA-West - Matching fields driving similarity: industry (Technology), size_band (Mid-Market), region (NA-West) - Exact matches: industry + size_band + region (3/4); use_case differs (retention vs employee_recognition). Scoring: 3 points. All other case-study customers (C-FEFCC020, C-11209339, C-9D69D147, C-CD4829A7, C-0CE315B2) scored 2 or fewer exact matches across the four dimensions and are therefore less similar than the top three ranked above.
Channel performance for the trailing 6 months (2026-03 through 2026-08): **PAID CHANNELS** (with spend) | Channel | Spend (USD) | SQMs | SQOs | Cost per SQM (USD) | Cost per SQO (USD) | SQM-to-SQO rate | Pipeline amount (USD) | Pipeline per dollar (USD) | |----------|-------------|------|------|-------------------|-------------------|-----------------|----------------------|-------------------------| | paid_search | $36,000 | 40 | 18 | $900.00 | $2,000.00 | 2.22 | $720,000 | $20.00 | | linkedin_ads | $24,000 | 25 | 8 | $960.00 | $3,000.00 | 3.12 | $96,000 | $4.00 | | webinars | $9,000 | 12 | 5 | $750.00 | $1,800.00 | 2.40 | $60,000 | $6.67 | | paid_social | $18,000 | 0 | 0 | undefined | undefined | undefined | $0 | undefined | *paid_social reports "undefined" for cost metrics because spend > 0 and zero observed SQMs in contact data.* **ORGANIC CHANNELS** (no spend) | Channel | Volume (SQMs) | SQOs | SQO rate (SQOs/SQMs) | Pipeline amount (USD) | |----------|---------------|------|---------------------|----------------------| | organic_search | 30 | 10 | 0.33 | $90,000 | | referral | 15 | 6 | 0.40 | $48,000 | **Flagged rows** (SQO date precedes SQM date): - CT-000044 (linkedin_ads): sqm=2026-07-23, sqo=2026-07-18 - CT-000041 (linkedin_ads): sqm=2026-06-14, sqo=2026-06-09 **Reallocation recommendation**: Reallocate spend from paid_social (undefined performance, zero observed SQMs) toward linkedin_ads and webinars. linkedin_ads has the highest SQM-to-SQO rate (3.12) and solid pipeline per dollar ($4.00); webinars has the highest pipeline per dollar ($6.67) among paid channels. Paid_search already performs well with $20 pipeline per dollar and 2.22 SQM-to-SQO rate. Start with a small test: reduce paid_social spend by ~50% and increase linkedin_ads and webinars by ~25% each over the next cycle. **Confidence**: moderate. Sample sizes are small (≈40–50 contacts per paid channel, ≈15–30 contacts per organic channel); metrics are based on observed contacts only and may vary with longer cycles.
# Battlecard: Rivally (updated)
**One-line positioning**: Points-based recognition platform targeting mid-market and EU distributed teams, with a lightweight Pulse engagement survey add-on. [S02, S06, S12]
**Pricing**: Recognition Starter tier is $7 per user/month, annual billing required (latest public pricing page update, S17, 2026-08-12). Previously showed $5 per user/month (S03, 2026-01-20; S08, 2026-04-01). Deal mentions have quoted $6.50/user/mo to a 500-seat prospect (S13, 2026-06-02) and $7/user/mo with 15% discount for a 3-year term (S18, 2026-08-14). Newer pricing page source (S17) wins for current public price; conflicts noted with earlier $5 price and deal-mention pricing. [S03, S08, S13, S17, S18]
**Where they win**:
- Points-based recognition feed is engaging and praised (S02, S16).
- Slack integration works out of the box (S04).
- Strong for distributed EU teams with multi-language support (S12).
- Recognition feed engagement praised (S16).
- Support response times under 4 hours (S22). [S02, S04, S06, S12, S16, S22]
**Where we win** (Bonusly advantages):
- Deeper analytics depth (800-seat prospect picked Bonusly over Rivally citing analytics depth, S25).
- SCIM provisioning (Rivally lacks it, S10; manual user management is painful).
- Easier migration (Rivally's CSV-only exports make migration hard, S20).
- More advanced reporting dashboards (Rivally's dashboards are basic compared to enterprise tools, S07). [S07, S10, S20, S25]
**Objections and responses**:
- Objection: Limited analytics/basic dashboards (S02 notes limited analytics; S07 says dashboards are basic). → Response: Bonusly provides deeper analytics (cited by a prospect choosing Bonusly over Rivally for analytics depth, S25).
- Objection: Lacks SCIM provisioning; manual user management is painful (S10). → Response: Bonusly supports SCIM provisioning.
- Objection: CSV-only exports; migration is hard (S20). → Response: Bonusly offers easier migration with richer export options.
- AE opinion (S21): "Rivally is discounting aggressively" — this is rep opinion not verified against the product; do not use as fact. Instead, emphasize value and features. [S02, S07, S10, S20, S25]
**Recent changes** (2026):
- March 2026: Launched 'Rivally Pulse', a lightweight engagement survey add-on (S06, 2026-03-05).
- July 2026: Opened Dublin office; EU data residency generally available (S15, 2026-07-01).
- August 2026: Microsoft Teams app v2 in public preview (S19, 2026-08-20); pricing page updated to $7 per user/month (S17, 2026-08-12).
- September 2026: Rivally Pulse exits beta (S23, 2026-09-01). [S06, S15, S17, S19, S23]
**12-month win/loss record vs Rivally**: Over available data period (September 2025 – August 2026, ~10 months), Bonusly recorded 13 wins and 7 losses against Rivally. By month breakdown:
- 2025-09: 1 win, 1 loss
- 2025-10: 2 wins, 0 losses
- 2025-11: 1 win, 1 loss
- 2025-12: 1 win, 1 loss
- 2026-01: 2 wins, 0 losses
- 2026-02: 2 wins, 0 losses
- 2026-03: 1 win, 1 loss
- 2026-04: 0 wins, 2 losses
- 2026-05: 0 wins, 1 loss
- 2026-06: 1 win, 0 losses
- 2026-07: 1 win, 0 losses
- 2026-08: 1 win, 0 losses
Total: 13 wins, 7 losses. [deals_with_competitor.csv]
**Notes / Unverified**:
- "Rivally was acquired by WorkHuman in 2025" — no evidence in provided snippets; mark as unverified. [existing claim]
- "Rivally lacks a Slack integration" — contradicted by S04 ("Slack integration worked out of the box"); claim is incorrect based on data; corrected to "Slack integration works out of the box".
**Per sequence (rates calculated from Step 1 data; weakest step identified as step with lowest reply rate within the sequence):** - **New Logo Nurture** Step 1: sent 500, opened 210 (42.0%), replied 42 (8.4%), meetings 12 (2.4%) Step 2: sent 458, opened 160 (34.9%), replied 30 (6.6%), meetings 9 (2.0%) Step 3: sent 428, opened 120 (28.0%), replied 18 (4.2%), meetings 6 (1.4%) Weakest step: Step 3 (lowest reply 4.2%) - **Expansion Nurture** Step 1: sent 300, opened 130 (43.3%), replied 22 (7.3%), meetings 5 (1.7%) Step 2: sent 300, opened 340 (113.3%), replied 25 (8.3%), meetings 4 (1.3%) ← tracking error (opened 340 > sent 300) Step 3: sent 275, opened 95 (34.5%), replied 12 (4.4%), meetings 3 (1.1%) Weakest step: Step 3 (lowest reply 4.4%) - **Cold Outbound – HR Leaders** Step 1: sent 600, opened 240 (40.0%), replied 5 (0.8%), meetings 0 (0.0%) Step 2: sent 595, opened 175 (29.4%), replied 2 (0.3%), meetings 0 (0.0%) Step 3: sent 590, opened 130 (22.0%), replied 1 (0.2%), meetings 0 (0.0%) Weakest step: Step 3 (lowest reply 0.2%) — all steps <2% reply - **Cold Outbound – People Ops** Step 1: sent 400, opened 150 (37.5%), replied 14 (3.5%), meetings 3 (0.8%) Step 2: sent 386, opened 110 (28.5%), replied 9 (2.3%), meetings 2 (0.5%) Step 3: sent 377, opened 80 (21.2%), replied 6 (1.6%), meetings 1 (0.3%) Weakest step: Step 3 (lowest reply 1.6%) — Step 3 <2% reply **Tracking errors (opened > sent):** Expansion Nurture, Step 2 (opened 340 > sent 300). This likely reflects step‑2 recipients overlapping with step‑1 or a counting artifact (opened metric may include prior opens). **Audience overlap between sequences:** In the provided audiences.csv, no contact_key appears under multiple different sequence names. One contact (CT-000034) appears twice in the file (both for New Logo Nurture), which is a within‑sequence duplicate, not cross‑sequence overlap. Thus, no audient overlap between different sequences is detected from the data. **Failure mode for <2% reply:** Cold Outbound – HR Leaders shows reply rates of 0.8%, 0.3%, and 0.2% across steps 1‑3 with zero meetings — consistent low response with no engagement. Cold Outbound – People Ops Step 3 has 1.59% reply (<2%) with zero follow‑up meetings. Failure mode: messaging/CTA barrier (generic outreach, no clear next step), leading to no replies after Step 1 for HR Leaders and very low reply for People Ops Step 3. **One change per weak sequence & which to fix first:** - Change Step 1 subject line + value proposition (not Step 3). Step 1 drives the entire sequence flow; improving the first touch has the highest leverage. - Fix order: **Cold Outbound – HR Leaders first** (reply <1%), then **Cold Outbound – People Ops** (1.59%), then Expansion Nurture (4.4%) and New Logo Nurture (4.2%). *Action:* A/B test a concise, benefit‑focused subject line + single CTA for Cold Outbound – HR Leaders Step 1. Measure reply rate increase before rolling to other sequences. (Word count: ~248 words)
Weekly marketing goals update for Q3-2026 (active quarter): - SQMs: QTD actual 230, target 300, delta -70 (behind), pace ahead (actual 230 ≥ expected ~215.2 at 66/92 days elapsed) - SQOs: QTD actual 84, target 120, delta -36 (behind), pace behind (actual 84 < expected ~86.1) - DS2s: QTD actual 40, target 75, delta -35 (behind), pace behind (actual 40 < expected ~53.8) - closed-lost MIA rate: QTD actual 0.20, target 0.10, delta 0.10 (behind), pace behind (actual 0.20 > target 0.10; lower is better) - same-quarter close count: QTD actual 10, target 20, delta -10 (behind), pace behind (actual 10 < expected ~14 at current pace) - active pipeline: QTD actual 3,000,000, target 4,000,000, delta -1,000,000 (ahead), pace ahead (actual 3,000,000 ≥ expected ~2,870,000; ahead on pace relative to days elapsed) What moved this week: MIA rate increased to 20% of closed lost deals (5 MIA out of 25 total closed lost), above the quarterly target of 10% (lower MIA is better). Same-quarter closes are at 10 vs a target of 20, while SQOs (84 vs 120) and DS2s (40 vs 75) remain below target with pace behind. Active pipeline sits at 3M, which is ahead of the pace-based expected value (~2.87M at 66 days elapsed), indicating pipeline volume is on track relative to elapsed time.
Q3 forecast is $106,087.75 after excluding 9 BEST_CASE deals ($28,240) that close in October. The current $115,976.75 forecast includes those 9 BEST_CASE deals. Only BEST_CASE deals are affected; COMMIT deals are already in-quarter.
Subject: Follow-up on 150-seat pricing Hi team, My August 5 email recapped the July 28 demo with pricing for 150 seats; no reply yet. Would now be a good time for a 15-minute call to walk through the numbers and answer any questions? Thanks, Alex Franklin
Marketing: This week, Marketing logged 46 SQMs against a 52 target, with the webinar channel delivering 18 of them. Paid search cost per SQM held at $150. Sales: Sales converted 14 SQOs and set 9 DS2 meetings. They created $310,000 of new pipeline and closed 3 deals this quarter. CS: We saved 2 renewals this week. Team NPS moved to 61, and 3 open red-flag accounts are heading into next week. PLG: PLG added 412 new signups with activation at 31 percent. 38 companies reached the aha moment of 10 recognition gives.
**Partner Digest — 2026-08-25 to 2026-09-02** Apex Rewards Co (active): 2 sourced opps, $275,000 pipeline (180000 + 95000 from deals; Slack: "brought two sourced opps") HRCloud Partners (active): 1 sourced opp, $140,000 pipeline (140000 from deals; Slack: "One sourced opp this period") CultureBridge (active): 2 sourced opps, $135,000 pipeline (60000 + 75000 from deals; Slack: "produced two sourced opps") WorkWell Group (active): 0 sourced opps, $0 pipeline (Slack: "no sourced deals this period"; 0 deals) Recogniq (quiet): quiet (quiet; 0 deals) KudosWave (quiet): quiet (quiet; 0 deals) PeopleFirst Advisors (quiet): quiet (quiet; 0 deals) TotalPerk (quiet): quiet (quiet; 0 deals)
Q1: Yes, customer data is encrypted at rest using AES-256. [P1] Q2: Yes, data in transit is encrypted with TLS 1.2 or higher. [P1] Q3: Yes, Bonusly maintains a SOC 2 Type II report, renewed annually. The report is available to prospects under NDA. [P2] Q4: Customer data is retained for the duration of the contract plus 90 days, after which it is deleted from production systems. [P3] Q5: The subprocessor list is published at trust.bonusly.com. Customers receive 30 days notice before a new subprocessor is added. [P4] Q6: Yes, SAML 2.0 single sign-on is available on the Enterprise plan. [P5] Q7: Production databases are backed up daily. Backups are encrypted and retained for 35 days. [P6] Q8: Unanswerable from excerpts. A security compliance document (e.g., certification details in the SOC 2 report or other compliance artifacts) would answer. Q9: Unanswerable from excerpts. A contract or SLA document would answer. Q10: Unanswerable from excerpts. A legal/compliance agreement document (e.g., BAA process) would answer.
I'll analyze the skill manifest and files systematically based only on the provided data. No assumptions or inventions. ### Analysis Summary **Manifest data:** 15 skills in `skill_manifest.csv` with `description_chars` and `body_lines` counts. All `description_chars` ≤ 1006 < 1024, so no descriptions exceed 1,024 characters. **(1) ALWAYS-trigger phrase overlap/duplicate** - Skills with explicit "ALWAYS trigger for" phrases (found in their bodies): `closed-lost-analysis`, `email-drafter`, `model-selection`, `next-to-close`, `partner-digest`, `pipeline-intelligence-report`, `sales-forecast`, `signalforge-claim-compressor`, `signalforge-feedback`, `stale-pipeline-report`, `weekly-pipeline-report` (note: `analysis-validator` uses "Always. No exceptions." but no "ALWAYS trigger for X" list) - `comms-drafter` uses "Trigger for:" (not "ALWAYS"), `deal-strategy-coach` uses descriptive triggers without "ALWAYS" prefix. - Overlap check: `email-drafter` lists `"write me an email", "draft a follow-up", "bump email", "contract nudge"` as ALWAYS trigger phrases. `comms-drafter` lists `"write me an email", "draft a follow-up", "help me reply", "bump email"` as Trigger phrases. While `comms-drafter` doesn't say "ALWAYS", the user-facing trigger phrases overlap (`"write me an email"`, `"draft a follow-up"`, `"bump email"`). When a user says "write me an email", both `email-drafter` (ALWAYS) and `comms-drafter` (Trigger) could apply, causing duplication. This is the most concrete overlap among ALWAYS-trigger phrases. - Severity: **WARNING** (potential duplication without clear precedence) - Action type: **TRIM_DESC** (trim/refine trigger phrases to reduce overlap; e.g., `email-drafter` keep for prospecting/follow-up emails, `comms-drafter` clarify it covers broader comms and avoid exact phrase overlap) **(2) Circular delegation chain** - Delegation references found (explicit "delegate to" or "called from" statements): - `pipeline-intelligence-report` → delegates entirely to `closed-lost-analysis` (Phase 2b) - `next-to-close` → "Delegate to pipeline-intelligence-report if user wants full scored pipeline" - `closed-lost-analysis` Mode 4 says "called from pipeline-intelligence-report" (not "delegate to") - Other skills reference connector tools (`HubSpot:search_crm_objects`, etc.) but not skill delegation - Check for cycles: `pipeline-intelligence-report` → `closed-lost-analysis`; `next-to-close` → `pipeline-intelligence-report`. No skill references `closed-lost-analysis` → back to `pipeline-intelligence-report` (only `closed-lost-analysis` says "called from" but does not say "delegate to pipeline-intelligence-report"). Thus no circular delegation chain. - Severity: **INFO** **(3) Dangling delegation target** - Delegation targets referenced in skill bodies: `closed-lost-analysis`, `pipeline-intelligence-report`, `pipeline-intelligence-report` → `closed-lost-analysis`, `next-to-close` → `pipeline-intelligence-report`. - Other skills mention skill-like names that are not in the manifest: - `comms-drafter`, `email-drafter`, `deal-strategy-coach`, `weekly-pipeline-report` all say "apply the `bonusly-brand` skill" (Step 0) - `signalforge-claim-compressor` mentions "caveman" token compression concept (not a delegation target) - `signalforge-reports` org skill is read (`/mnt/skills/organization/signalforge-reports/`) but not delegated to - `bonusly-brand` is referenced by multiple skills but does **not** appear in `skill_manifest.csv` (only the 15 declared skills). This is a dangling delegation target. - Severity: **CRITICAL** (referencing non-existent skill in delegation flow) - Action type: **DELETE_SKILL** (if `bonusly-brand` is not part of this skill set) or **REVIEW** (update reference). Since `bonusly-brand` is not in the manifest, it should be reviewed/removed from delegation references in these skills. I propose `DELETE_SKILL` for the reference removal (the skill itself may exist externally but not in this manifest set). **(4) Version conflict and survivor** - Version statements found: - `analysis-validator`: versions 1.0 → 3.6 (changelog), "Last Updated: May 9, 2026" - `pipeline-intelligence-report`: "version: v6 · May 2026" - `signalforge-claim-compressor`: "Version 1.0 | 2026-05-09" - `stale-pipeline-report`: "Version 1.0 | 2026-06-10" - `model-selection`: "last_checked: 2026-05-19" (not a skill version) - Other skills have no explicit version numbers in body - No skill claims two conflicting versions or specifies version overrides for the same purpose. All versions are independent (e.g., validator v3.6 vs pipeline report v6). No manifest row indicates a version field that conflicts. - No version conflict exists. - Severity: **INFO** - Action: N/A (no conflict) **(5) Manifest descriptions exceeding 1,024 characters** - `description_chars` from manifest: max 1006 (signalforge-claim-compressor, signalforge-report, pipeline-intelligence-report, partner-digest). All ≤ 1006 < 1024. - None exceed 1,024 characters. - Count: **0 skills** - Severity: **INFO** **(6) Hardcoded page ids, dates, or person names in skill bodies** - Found in multiple skill bodies: - Dates: `"April 26, 2026"`, `"May 9, 2026"` in `analysis-validator`; `"May 2026"` in `pipeline-intelligence-report`; `"2026-05-19"` in `model-selection`; `"2026-06-10"` in `stale-pipeline-report`; various "today", "CURRENT_DATE()" etc. (not hardcoded) - Person names: `"Bryce Harmon"`, `"Dana Mercer"`, `"Gavin Porter"`, `"Alaina Loori"`, `"Shealagh Coughlin"`, `"Ben Lavin"`, etc., in stage tables and examples - Page/folder IDs: `"2286616609"` (folder ID in `partner-digest`) - Yes, hardcoded values present. - Severity: **WARNING** (hardcoded dates/names may become stale; page ID could vary) - Action type: **UPDATE_BODY** (replace hardcoded dates with dynamic query results; replace hardcoded person names with lookup references; use variable for folder ID if possible) **(7) Manifest drift (both directions)** - Manifest rows: 15 skills (`analysis-validator` through `weekly-pipeline-report`). - All skill files provided (`*.SKILL.md`) exactly match the `declared_name` in the manifest (e.g., `analysis-validator.SKILL.md` for `analysis-validator`, etc.). No extra skill files outside manifest are mentioned in bodies that would imply a file with no manifest row. - All manifest rows have corresponding files (all 15 skill files are provided). No manifest row references a non-existent file. - Thus no manifest drift in either direction. - Severity: **INFO** ### Proposals (one per finding) 1. **ALWAYS-trigger phrase overlap** (WARNING, TRIM_DESC) > `email-drafter` and `comms-drafter` both use phrases like `"write me an email"`, `"draft a follow-up"`, `"bump email"` in their trigger lists. `email-drafter` says "ALWAYS trigger for", `comms-drafter` says "Trigger for". When a user says "write me an email", both could apply. > **Proposal**: Trim `comms-drafter`'s "Trigger for:" list to avoid exact phrase overlap — e.g., use `"draft a follow-up with data"` or `"write an email with a specific ask"` instead of `"write me an email"`; keep `email-drafter`'s phrases for clear prospecting/follow-up cases. This reduces duplication while preserving coverage. 2. **Circular delegation chain** (INFO) — No circular chain found. `pipeline-intelligence-report` → `closed-lost-analysis`; `next-to-close` → `pipeline-intelligence-report`. `closed-lost-analysis` only says "called from pipeline-intelligence-report", not "delegate to". No cycle. 3. **Dangling delegation target** (CRITICAL, DELETE_SKILL) > Multiple skills (`comms-drafter`, `email-drafter`, `weekly-pipeline-report`) say "apply the `bonusly-brand` skill" in their Step 0. `bonusly-brand` is not listed in `skill_manifest.csv`. > **Proposal**: Delete the `bonusly-brand` skill reference from those skills' bodies (replace with inline brand application rules or remove the step if brand guidance is inline). Since `bonusly-brand` is not in this manifest set, referencing it causes a dangling delegation. 4. **Version conflict** (INFO) — No version conflict exists. All versions are independent (validator v3.6, pipeline v6, etc.). No survivor decision needed. 5. **Descriptions > 1,024 chars** (INFO) — **0** skills exceed 1,024 characters. 6. **Hardcoded values** (WARNING, UPDATE_BODY) > Skill bodies contain hardcoded dates (e.g., "April 26, 2026", "May 9, 2026"), person names (e.g., "Bryce Harmon"), and folder ID (`2286616609`). > **Proposal**: Update bodies to use dynamic queries/lookups: replace fixed dates with `CURRENT_DATE()` or session-start queries; replace hardcoded person names with lookup via `HubSpot:search_owners`; use manifest-driven folder ID if possible or pass as parameter. This ensures values stay current. 7. **Manifest drift** (INFO) — No drift. All 15 manifest rows have corresponding files, and all skill files match manifest names. ### Final Report (one proposal each, severity & action) ``` 1. ALWAYS-trigger phrase overlap — WARNING, TRIM_DESC Proposal: Trim `comms-drafter` "Trigger for:" phrases to avoid overlap with `email-drafter` "ALWAYS trigger for" phrases (e.g., change `"write me an email"` to `"write an email with a specific ask"` in `comms-drafter`). Prevents both skills triggering for same user input. 2. Circular delegation chain — INFO No circular delegation found. `pipeline-intelligence-report` → `closed-lost-analysis`; `next-to-close` → `pipeline-intelligence-report`. `closed-lost-analysis` only references `pipeline-intelligence-report` as caller, not delegatee. 3. Dangling delegation target — CRITICAL, DELETE_SKILL Proposal: Remove `bonusly-brand` skill reference from `comms-drafter`, `email-drafter`, and `weekly-pipeline-report` bodies (Step 0). `bonusly-brand` is not in the manifest, so referencing it is dangling. 4. Version conflict — INFO No version conflict exists. All skill versions are independent (e.g., validator v3.6, pipeline v6). No skill should survive over another. 5. Descriptions > 1,024 chars — INFO 0 skills exceed 1,024 characters (all ≤ 1006). 6. Hardcoded page ids/dates/names — WARNING, UPDATE_BODY Proposal: Replace hardcoded dates (e.g., "April 26, 2026") with dynamic queries (`CURRENT_DATE()` or session-start query); replace hardcoded person names with `HubSpot:search_owners` lookup; use parameterized folder ID for `partner-digest`. 7. Manifest drift — INFO No drift. All 15 manifest rows have corresponding files, and all skill files match manifest names. ``` All findings are based solely on the provided `skill_manifest.csv` and skill body contents. No external data or assumptions were used.
Runbook for incident #incident-2026-08-29-reward-queue Step 1: Check queue depth (diagnostic) - Action: `bundle exec rake sidekiq:queue_depth` - Ran by: Farid Osman (M02) - Verification: Reward queue at 48,213 pending jobs; normal is under 500 - Rollback: Not applicable (diagnostic step) Step 2: Pause auto_recognition_enqueue - Action: `bin/rails runner 'FeatureFlag.disable(:auto_recognition_enqueue)'` - Ran by: Farid Osman (M04) - Verification: Not explicitly stated in thread; subsequent actions (clear dead set M05, scale up M06) follow immediately, and queue depth later observed at 9,400 (M07) - Rollback: `bin/rails runner 'FeatureFlag.enable(:auto_recognition_enqueue)'` (explicitly stated in M04) Step 3: Clear dead set - Action: Clear out the dead set (112 jobs, all Redis::TimeoutError from around 13:58) - Ran by: Elena Sinclair (M05 — "While I was in the console I cleared out the dead set") - Verification: Not explicitly stated in thread; M03 indicates 112 jobs in dead set and M07 observes queue depth decreasing - Rollback: Not stated in thread — **needs confirmation** Step 4: Scale up reward-worker - Action: `kubectl scale deployment/reward-worker --replicas=6` (was 3) - Ran by: Bryce Harmon (M06) - Verification: M07 states "Queue depth down to 9,400 and falling ~1,200/min" - Rollback: `kubectl scale deployment/reward-worker --replicas=3` (explicitly stated in M06) Step 5: Verify resolution - Action: `bundle exec rake sidekiq:queue_depth` and check Datadog error rate - Ran by: Cole Ingram (M08) - Verification: `bundle exec rake sidekiq:queue_depth` now returns 0; Datadog error rate back to baseline - Rollback: Not applicable (verification step) Step 6: Resume auto_recognition_enqueue - Action: `bin/rails runner 'FeatureFlag.enable(:auto_recognition_enqueue)'` - Ran by: Bryce Harmon (M09) - Verification: 40 new jobs processed cleanly in the next 3 minutes (M09) - Rollback: Not stated in thread — **needs confirmation** (based on pattern would be `bin/rails runner 'FeatureFlag.disable(:auto_recognition_enqueue)'`) Step 7: Scale down reward-worker - Action: `kubectl scale deployment/reward-worker --replicas=3` - Ran by: Bryce Harmon (M10) - Verification: Queue stable at 0 (M10) - Rollback: Not stated in thread — **needs confirmation** (based on pattern would be `kubectl scale deployment/reward-worker --replicas=6`) Notes on arithmetic and clarity: - Queue depth values cited exactly: 48,213 (M02), 112 (M03), 9,400 and falling ~1,200/min (M07), 0 (M08), stable at 0 (M10) - All commands and feature-flag names cited exactly as given in the thread (e.g., `FeatureFlag.disable(:auto_recognition_enqueue)`, `FeatureFlag.enable(:auto_recognition_enqueue)`) - Rollback commands are included only where explicitly stated in the thread (Steps 2 and 4); for Steps 3, 6, and 7, rollbacks are marked as **needs confirmation** since the thread does not contain explicit rollback instructions for those actions. - Step 1 and Step 5 are verification steps; they do not change state and thus have no rollback requirement per the instruction. - Each step is ordered chronologically per the thread messages.
First error with timestamp: `2026-09-03T14:01:12Z` in `reward-service`: `Redis::TimeoutError: Connection to Redis at redis-primary:6379 timed out after 5s` Cascade in order (chronological): 1. `reward-service` (14:01:12): Redis timeout reported 2. `reward-service` (14:01:20, 14:01:30, 14:01:40): `Redis::TimeoutError: retry exhausted for RewardGiveJob` 3. `sidekiq` (14:01:40): `RewardGiveJob failed: Redis::TimeoutError; retrying in 60s` 4. `sidekiq` (14:02:28): `RewardGiveJob failed: Redis::TimeoutError; retrying` 5. `sidekiq` (14:02:30): warning `Queue reward depth above 10,000` 6. `api-gateway` (14:03:05): `502 upstream timeout calling reward-service /gives` 7. `web-app` (14:03:30): `Give form submission failed: upstream 502 from api-gateway` 8. `sidekiq` (14:03:31): `RewardGiveJob failed: Redis::TimeoutError; retrying` 9. `api-gateway` (14:03:48): `502 upstream timeout calling reward-service` 10. `api-gateway` (14:04:13): `502 upstream timeout calling reward-service` 11. `sidekiq` (14:04:22): `RewardGiveJob failed: Redis::TimeoutError; retrying` 12. `web-app` (14:04:45): `Give form submission failed: upstream 502` ... with similar `sidekiq` failure reports and `api-gateway`/`web-app` error reports repeating throughout 14:04–14:06 Service and job involved: `reward-service`, `sidekiq` (running `RewardGiveJob` and `RecognitionDigestJob`), `api-gateway`, `web-app` Datadog query to confirm the first error: ``` logs(@timestamp >= "2026-09-03T14:01:10Z" AND @timestamp <= "2026-09-03T14:01:14Z", service="reward-service", level="ERROR", message="Connection to Redis at redis-primary:6379 timed out after 5s") ``` What the logs do NOT show: - Redis server-side connection pool state, queue backlog, or internal retry mechanism details - Network latency measurements or packet-level timing between services - Postgres query execution times for reward-related operations - Exact retry backoff intervals beyond "60s" for the first retry attempt - Whether any RewardGiveJob retries eventually succeeded after the timeout period - Counts of failed vs succeeded RewardGiveJob attempts - User-facing error rates, conversion impact, or business metric changes - Configuration values (e.g., exact timeout duration, retry attempt count)
Feature Flags Summary (from `flags_export.csv` and `flag_code.md`) 1. `recognition_streaks_v2` - Controls: Records give events in `StreakTracker` (`app/models/recognition.rb`) - State: on - Has it on: `segment:beta_companies` (42 companies, from company_count) - Targeting rules: `segment:beta_companies` - Code reference: Yes (`app/models/recognition.rb`) 2. `points_budget_guardrails` - Controls: Enforces budget limits via `BudgetService` (`app/services/budget_service.rb`) - State: on - Has it on: `all_companies` (220 companies) - Targeting rules: `all_companies` - Code reference: Yes (`app/services/budget_service.rb`) 3. `slack_dm_nudges` - Controls: Sends Slack DM nudges via `SlackDm.send_nudge` (`app/jobs/nudge_job.rb`) - State: on - Has it on: `segment:region_na` (87 companies) - Targeting rules: `segment:region_na` - Code reference: Yes (`app/jobs/nudge_job.rb`) 4. `redeem_flow_redesign` - Controls: Renders redeem flow (`RedeemV2Component` vs `RedeemV1Component`) (`app/controllers/redeem_controller.rb`) - State: off - Has it on: none (flag is off; 12 companies are targeted via `targeted_list` and receive V1 flow) - Targeting rules: `targeted_list` - Code reference: Yes (`app/controllers/redeem_controller.rb`) 5. `analytics_dashboard_v3` - Controls: Creates `AnalyticsV3` dashboard (`AnalyticsV3.new`) (`app/controllers/analytics_controller.rb`) - State: on - Has it on: `segment:tier_three` (65 companies) - Targeting rules: `segment:tier_three` - Code reference: Yes (`app/controllers/analytics_controller.rb`) 6. `ms_teams_app_v2` - Controls: Installs Teams App V2 (`TeamsAppV2.install`) (`app/services/teams_installer.rb`) - State: off - Has it on: none (flag is off; 9 companies are targeted via `targeted_list` and do not get Teams App V2) - Targeting rules: `targeted_list` - Code reference: Yes (`app/services/teams_installer.rb`) 7. `legacy_give_modal` - Controls: Not referenced in code excerpt (no `FeatureFlags.enabled?` call found) - State: off - Has it on: none (flag is off for `segment:legacy_plan`; 14 companies are targeted and would not see the modal) - Targeting rules: `segment:legacy_plan` - Code reference: No (not in `flag_code.md`) 8. `survey_boosters_q3` - Controls: Not referenced in code excerpt (no `FeatureFlags.enabled?` call found) - State: on - Has it on: `segment:legacy_plan` (7 companies) - Targeting rules: `segment:legacy_plan` - Code reference: No (not in `flag_code.md`) 9. `paused_offboard_cleanup` - Controls: Not referenced in code excerpt (no `FeatureFlags.enabled?` call found) - State: off - Has it on: none (flag is off; no targeting rules specified) - Targeting rules: (empty — no targeting rules defined) - Code reference: No (not in `flag_code.md`) - Company count: 0 Flags with no code reference: `legacy_give_modal`, `survey_boosters_q3`, `paused_offboard_cleanup` Flag with no targeting rules: `paused_offboard_cleanup` (targeting_rules is empty) All company counts match the export (`flags_export.csv`). No flag outside the export was described. Arithmetic verified: company_counts are directly taken from the CSV export without modification.
NDA-1 — GREEN. Clause: "Mutual confidentiality. Each party may disclose Confidential Information to the other for the purpose of evaluating a business relationship." Clear carve-outs (public availability, prior knowledge, third-party receipt, independent development, legal disclosure), no license/obligation/exclusivity, standard 2-year term with 3-year survival, Delaware law. NDA-2 — YELLOW. Clause: "During the term of this Agreement and for eighteen (18) months thereafter, neither party shall solicit for employment or hire any employee of the other party with whom it came into contact under this Agreement." Standard carve-outs otherwise; counsel review needed for the 18-month post-term non-solicitation scope and who qualifies as "came into contact." NDA-3 — RED. Clause: "For a period of three (3) years following the Effective Date, Recipient shall not, directly or indirectly, engage in or provide services to any business that competes with Discloser's business." Non-compete clause with one-way confidentiality favoring PARTY C; governing law in Ireland with exclusive Irish jurisdiction; no stated confidentiality carve-outs; requires full legal review.