Mean 0.958 · 33/40 perfect tests · $8.01 total · modalities in: text, image, file · out: text · each card: the prompt → the correct answer (gold) → this model's actual answer
Modalities in means what you can send this model: text, images, files, video, or audio. Modalities out means what it can send back. Bench tasks feed text extracts, so modalities do not change the score. They are here so you know what this model can handle in real work.
**Definitions** - **DS2+ population:** open deals whose stage is DS2, DS3, DS4 or DS5. That is 124 of the 156 open deals (DS2 39 + DS3 61 + DS4 14 + DS5 10). The other 32 are DS1. - **Why-buys compliant:** the text is at least 15 characters and isn't a placeholder, or it has the form LONG(n), which counts as present. Non-compliant means blank, shorter than 15 characters, or a placeholder. In this data every why_buys value is either blank or LONG(n); no short text or placeholders appear. - **No DS1 timestamp:** t_ds1 is blank. - **Regressed:** among the stage timestamps that are filled in (t_ds1 to t_ds5), an earlier stage's date is strictly later than a later stage's date. Equal dates on the same day count as in order. **1. Why-buys non-compliance at DS2+** - Overall: 101 / 124 = 81.5% non-compliant (124 − 23 LONG values = 101 blank). | Owner | Non-compliant / DS2+ | % | |---|---|---| | Bryce Harmon | 15 / 18 | 83.3% | | Alex Franklin | 48 / 61 | 78.7% | | Dana Mercer | 18 / 22 | 81.8% | | Cole Ingram | 19 / 22 | 86.4% | | Farid Osman | 1 / 1 | 100.0% | | Elena Sinclair | 0 / 0 | not applicable (no DS2+ deals) | | Total | 101 / 124 | 81.5% | Check: 15 + 48 + 18 + 19 + 1 = 101, and 18 + 61 + 22 + 22 + 1 = 124. **2. Deals with no DS1 timestamp: 0 of 156.** **3. Regressed deals by your definition: 0 of 156.** Other data issues outside your definitions: - **Deals that moved backward:** 4 deals have a timestamp for a stage beyond their current stage. - Deal-0D0211 (DS3, has t_ds4) - Deal-BE3D9D (DS3, has t_ds4) - Deal-7E2131 (DS3, has t_ds4) - Deal-C7F9BF (DS2, has t_ds3) Their timestamps are in order, so the rule above doesn't count them, but their stage did go backward. - **Missing timestamp for the current stage:** 11 deals. - All 10 DS5 deals have a blank t_ds5. - Deal-317E6F (DS3) has a blank t_ds3. - **Misaligned row:** Deal-57FF13 appears to have its columns shifted (source = "3"; last_contacted and n_contacts are blank). **Three process fixes** 1. **Require why-buys to leave DS1.** Make why_buys a required field, at least 15 characters with a placeholder blocklist, on the move into DS2 and every later stage. Then run a one-time backfill of the 101 blank deals, starting with DS4 and DS5 (which are also forecast as COMMIT or BEST_CASE). 2. **Make stage timestamps reliable.** Fix the automation so t_ds5 is written when a deal enters DS5 (0 of 10 DS5 deals have it) and every current stage gets a timestamp. Also require a reason code when a deal moves backward, and clear or flag timestamps for stages above the current one (the 4 deals above). 3. **Weekly hygiene report by owner.** Track DS2+ why-buys compliance, missing current-stage timestamps, backward moves and malformed rows, with a target such as ≥90% compliance. Review it in forecast calls, and don't let a deal be COMMIT or BEST_CASE while its why-buys is blank.
**Resolved deals: 156 of 156.** I extracted the owner_id and amount from each row by hand and summed them with a script. Note: the extract has no owner-name column at all, not just a blank one. Owner names below come only from owners.csv, joined on owner_id. **Owner IDs with no match in owners.csv: none.** All six owner_ids in the deals file appear in owners.csv, so no deal is unresolved and no name was guessed. **Owner IDs that map to archived owners: none in the open pipeline.** - owners.csv marks two owners as archived: Gavin Porter (1520255671) and Hugo Lindqvist (77260721). - Neither ID appears on any open deal. - All six owners who do hold deals are marked archived=false. **Pipeline by resolved owner** | owner_id | Owner | Deals | Pipeline amount | |---|---|---|---| | 119337721 | Bryce Harmon | 35 | $1,054,144.00 | | 84342457 | Alex Franklin | 67 | $624,310.00 | | 83155923 | Dana Mercer | 24 | $341,195.00 | | 83155924 | Cole Ingram | 22 | $288,161.43 | | 716654662 | Farid Osman | 7 | $4,134.00 | | 701163055 | Elena Sinclair | 1 | $2,100.00 | | **Total** | | **156** | **$2,314,044.43** | Arithmetic: - Deal count: 35 + 67 + 24 + 22 + 7 + 1 = 156. - Amounts: 1,054,144 + 624,310 + 341,195 + 288,161.43 + 4,134 + 2,100 = 2,314,044.43. - Farid Osman in full: Deal-499BF6 $1,249 + Deal-8BA24E $2,880 + five $1 deals (Deal-03BA69, Deal-117863, Deal-F17780, Deal-2B39B0, Deal-8FDCD2) = $4,134. **Data-quality flags** 1. **Deal-57FF13 (owner 701163055, Elena Sinclair) has shifted columns.** last_contacted_field and n_contacts are blank, and source contains "3". The owner_id and $2,100 amount look intact, so I included it, but the row should be checked. 2. **Two owner IDs differ by one digit:** 83155923 (Dana Mercer) and 83155924 (Cole Ingram). Both are valid in owners.csv, so both resolve. Still, a keying error between them would move pipeline between these two reps without anyone noticing. 3. **Seven deals carry a $1 placeholder amount.** Bryce Harmon has 3 (Deal-012CB1, Deal-483B2D, Deal-3795AD) and Farid Osman has 5 of his 7 deals at $1. These overstate deal counts compared with real dollar pipeline.
I joined gong.hs_deal_id to deals_open.deal_id. I didn't use gong_owner_id, because it's a Gong user id and not a HubSpot owner id. The gong file has 67 rows and 465 calls. deals_open has 156 open deals. (a) Orphans: 30 of 67 gong rows have no match in deals_open - 67 rows − 37 matched = 30 orphans, which is 30/67 = 44.8% of rows. - The orphan rows hold 304 of the 465 calls (65.4%). - Sample aliases: Deal-8FA85D (46 calls), Deal-8FC3F9 (24), Deal-3B7945 (21), Deal-42B265 (21), Deal-9CCC42 (17), Deal-B038F0 (5), Deal-422BA6 (6), Deal-3B6668 (4). - These deals are probably closed, in a different pipeline, or deleted. The data doesn't say which. - Two other patterns show up in the orphans: - 26 of the 30 have calls_with_ds2_date = 0 and calls_with_sqo_date = 0. - Many have last_call dates after today (2026-09-24). Examples: Deal-8FA85D 2026-11-05, Deal-9CCC42 2026-11-27, Deal-42B265 2026-11-25. Calls dated in the future suggest scheduled meetings, or a date error in the source. - All 37 matched rows have the same alias in both files. (b) Duplicate conversation keys: none - In all 67 rows, calls_90d equals distinct_conversation_keys, so 0 rows have calls_90d above the key count. (c) Call coverage for open deals at DS3 or later - There are 85 open deals at DS3, DS4 or DS5 (current stage field): 61 DS3 + 14 DS4 + 10 DS5. - 25 of them have at least one logged call. 25/85 = 29.4%. | Stage | With a call | Share | |---|---|---| | DS3 | 12 of 61 | 19.7% | | DS4 | 6 of 14 | 42.9% | | DS5 | 7 of 10 | 70.0% | - That leaves 60 late-stage deals with no Gong call in the last 90 days. - Uncovered examples: Deal-9AAE5F (DS4, $11,250), Deal-403845 (DS5, $9,000), Deal-2465CE (DS5, $5,400), Deal-B25F40 (DS3, $40,000), Deal-530B50 (DS3, $31,200). - The data can't tell us whether these deals had no calls or had calls that weren't mapped to them, and some orphan rows might belong to them.
```sql
-- DATA GAPS. The catalog does not document these items, so this query will not run until they are confirmed:
-- 1. The catalog has no recognition/give event table. <RECOGNITION_EVENTS_TABLE>, GIVER_ID and ID are placeholders.
-- 2. PRODUCTION.PLG.COMPANY_COHORT_SUMMARY does not list a company key column. COMPANY_ID is assumed.
-- 3. PRODUCTION.DEPRECATED_RECOGNITION.REDEMPTION_RECORDS_V2 documents only STATE. COMPANY_ID, CREATED_AT and ID are assumed.
-- 4. COMPANY_COHORT_SUMMARY covers self-serve companies only. The catalog has no customer start date for sales-led customers.
-- 5. The precomputed M1_USERS, M1_GIVES and M1_REDEMPTIONS columns are not used. The catalog does not say whether:
-- "M1" means the first calendar month, M1_USERS means unique givers,
-- M1_GIVES excludes deleted givers, or M1_REDEMPTIONS counts only succeeded redemptions.
WITH customer_start AS (
SELECT
cs.COMPANY_ID, -- ASSUMED column name
DATE_TRUNC('month', cs.FIRST_SUB_PAYMENT_DATE) AS first_customer_month
-- COMPANY_COHORT_SUMMARY is the only catalog table with a per-company customer start date.
-- FIRST_SUB_PAYMENT_DATE (first paid subscription) defines the start. The HubSpot deal tables are not used:
-- V2_LIVE.OBJECTS_DEALS is unpopulated, PRODUCTION.HUBSPOT.DEALS is stale (last sync 2023-03),
-- and V2_DAILY.OBJECTS_DEALS has no company-level customer start date.
FROM PRODUCTION.PLG.COMPANY_COHORT_SUMMARY cs
WHERE cs.FIRST_SUB_PAYMENT_DATE IS NOT NULL
),
recognitions AS (
SELECT
c.COMPANY_ID,
COUNT(DISTINCT r.GIVER_ID) AS unique_givers, -- PLACEHOLDER column
COUNT(DISTINCT r.ID) AS recognition_count -- PLACEHOLDER column
-- Start from the customer set so each company is scoped to its own first month.
FROM customer_start c
-- PLACEHOLDER: the catalog has no recognition event table.
-- There is deliberately NO deleted-giver filter here. The business rule says that filter understates historical giving counts.
JOIN <RECOGNITION_EVENTS_TABLE> r
ON r.COMPANY_ID = c.COMPANY_ID -- PLACEHOLDER column
AND r.CREATED_AT >= c.first_customer_month -- PLACEHOLDER column
AND r.CREATED_AT < DATEADD('month', 1, c.first_customer_month)
GROUP BY c.COMPANY_ID
),
redemptions AS (
SELECT
c.COMPANY_ID,
COUNT(DISTINCT rr.ID) AS successful_redemption_count -- ASSUMED column name
-- Start from the customer set so each company is scoped to its own first month.
FROM customer_start c
-- REDEMPTION_RECORDS_V2 is the documented source for redemption counts, despite the DEPRECATED schema name.
-- The catalog says to confirm it before using it for finance-grade numbers.
JOIN PRODUCTION.DEPRECATED_RECOGNITION.REDEMPTION_RECORDS_V2 rr
ON rr.COMPANY_ID = c.COMPANY_ID -- ASSUMED column name
AND rr.CREATED_AT >= c.first_customer_month -- ASSUMED column name
AND rr.CREATED_AT < DATEADD('month', 1, c.first_customer_month)
WHERE rr.STATE = 'succeeded' -- business rule: succeeded rows only
GROUP BY c.COMPANY_ID
)
SELECT
c.COMPANY_ID,
c.first_customer_month,
COALESCE(rec.unique_givers, 0) AS unique_givers,
COALESCE(rec.recognition_count, 0) AS recognition_count,
COALESCE(red.successful_redemption_count, 0) AS successful_redemption_count
-- Base: one row per customer company with its first calendar month.
FROM customer_start c
-- LEFT JOIN keeps companies that had no recognitions in their first month (they show 0).
LEFT JOIN recognitions rec
ON rec.COMPANY_ID = c.COMPANY_ID
-- LEFT JOIN keeps companies that had no successful redemptions in their first month (they show 0).
LEFT JOIN redemptions red
ON red.COMPANY_ID = c.COMPANY_ID
ORDER BY c.first_customer_month, c.COMPANY_ID;
```
CRM Data Quality Audit
Scope: companies.csv (34 rows), contacts.csv (52 rows), zoominfo_enrichment.csv (25 rows).
Missing data up front: I didn't receive a deals file. That means I can't audit owner, stage, amount, close date or why-buys, and I can't rank fixes by pipeline amount. The fix list at the end is ranked by records affected instead.
1. Completeness by field
Deals (owner, stage, amount, close date, why-buys): no data, so not measurable.
Companies (n=34):
- industry: 34/34 = 100.0%
- Populated, but the labels aren't standardized: "tech", "Tech " (trailing space), "Technology", "SaaS", "health care", "Healthcare".
- employee_count: 25/34 = 73.5%
- Missing: C-EC3025, C-96039F, C-44EA29, C-D04904, C-B23205, C-60C75F, C-7BBDFA, C-50D386, C-93C8BF
- hq_country: 28/34 = 82.4%
- Missing: C-2D1F1B, C-D73B89, C-44EA29, C-D04904, C-2C60E5, C-EE9FFB
- Populated values mix formats: US / USA / United States
Contacts (n=52):
- email populated: 52/52 = 100.0%
- email valid: 48/52 = 92.3% (4 invalid, see section 3)
- title: 39/52 = 75.0%
- Missing: CT-0000, CT-0022, CT-0072, CT-0080, CT-0081, CT-0092, CT-0120, CT-0121, CT-0122, CT-0132, CT-0141, CT-0162, CT-0170
- persona: 37/52 = 71.2%
- Missing: CT-0000, CT-0022, CT-0041, CT-0060, CT-0070, CT-0081, CT-0082, CT-0092, CT-0110, CT-0132, CT-0162, CT-0171, CT-0172, CT-0180, CT-0181
2. Duplicate company clusters
There's no company name field in the extract, so I couldn't check for name variants. Clusters below are based on shared domain only. None of the four records in these clusters has linked contacts.
Cluster A, acme-corp.com:
- C-0A092931: Technology, 500, US
- C-0A092932: tech, 510, USA
- Survivor: C-0A092931. It already uses the standard industry and country labels, so fewer edits are needed.
- Conflict: employee_count is 500 vs 510. There's no ZoomInfo row for this domain, so verify manually before merging.
Cluster B, globex.io:
- C-0A092933: SaaS, 200, US
- C-0A092934: Technology, 200, US
- Survivor: C-0A092934. It's identical except industry, and "Technology" matches the standard label.
3. Invalid emails and domain mismatches
Invalid (missing domain after @): 4
- CT-0010 user0@ (C-66D1FC)
- CT-0080 user0@ (C-92D97D)
- CT-0081 user1@ (C-92D97D)
- CT-0192 user2@ (C-425E2A)
Domain mismatch: 1
- CT-0011 user1@other-domain.com vs account domain 66d1fc.com (C-66D1FC)
The contact domain column matches the linked company's domain on all 52 rows.
4. Enrichment fills (only where ZoomInfo has a matching row)
employee_count (8 fills, all values from ZoomInfo = 400):
- C-EC3025, C-96039F, C-44EA29, C-D04904, C-B23205, C-60C75F, C-7BBDFA, C-50D386
- After fills: 25 + 8 = 33/34 = 97.1%
- Still missing: C-93C8BF (no ZoomInfo row)
hq_country (0 fills):
- ZoomInfo is also blank for C-2D1F1B, C-D73B89, C-44EA29, C-D04904 and C-2C60E5.
- C-EE9FFB has no ZoomInfo row.
- Stays at 28/34 = 82.4%.
industry: nothing to fill.
No ZoomInfo row for 9 companies, so no fill is possible: C-BA969B, C-332637, C-93C8BF, C-EE9FFB, C-C9BB20, C-0A092931, C-0A092932, C-0A092933, C-0A092934.
5. Where CRM and ZoomInfo disagree
- employee_count: no disagreements. Wherever both sources have a value, they match.
- industry (a taxonomy difference, not a factual one):
- CRM "Technology/tech/Tech" vs ZoomInfo "Computer Software" on C-66D1FC, C-EC3025, C-44EA29, C-92D97D, C-D04904, C-77A95A, C-AA8DDA, C-B25F40, C-60C75F and C-425E2A.
- Recommendation: keep the CRM taxonomy and map "Computer Software" to "Technology".
- Standardize "tech", "Tech " and "SaaS" to "Technology", and "health care" to "Healthcare". ZoomInfo itself uses "health care" for 7bbdfa.com and 50d386.com.
- hq_country (format only):
- CRM US/USA vs ZoomInfo "United States" on C-66D1FC, C-950043, C-EC3025, C-96039F, C-77A95A, C-B23205, C-E51FB7, C-D0662E, C-425E2A and C-2D7423.
- No country values actually conflict.
- Recommendation: standardize on one format. ZoomInfo's "United States" is the consistent option.
6. Top 10 fixes
These can't be ranked by pipeline amount without a deals file. Ranked by records affected instead:
1. Load the deals extract and audit owner, stage, amount, close date and why-buys. This is needed before any pipeline-weighted ranking.
2. Backfill persona on 15 contacts (listed in section 1).
3. Backfill title on 13 contacts (listed in section 1).
4. Standardize industry labels on 12 companies ("tech", "Tech ", "SaaS", "health care").
5. Standardize hq_country format on 13 companies (US/USA to one value).
6. Fill employee_count = 400 from ZoomInfo on 8 companies (section 4).
7. Research hq_country for 6 companies. There's no enrichment source for these today.
8. Fix the 4 invalid emails: CT-0010, CT-0080, CT-0081, CT-0192.
9. Merge C-0A092932 into C-0A092931 after resolving the 500 vs 510 employee count, and merge C-0A092933 into C-0A092934.
10. Verify CT-0011's email domain (other-domain.com vs 66d1fc.com), and source enrichment for the 9 companies with no ZoomInfo match.
I classified all 90 deals from the tag and free text only. Together they total $1,267,945.16. Data caveats: - The file only covers close dates from 2026-07-29 to 2026-09-30. That's about 2 months, not 6. Nothing from the earlier 4 months was provided. - Deal-DB0AAC has a close date of 2026-09-30, which is after today (2026-09-24). How I assigned side: "Bonusly" means the text names a fit, product, price or value reason on our end. "Buyer" means an internal reason on their end (budget, priorities, approval, an incumbent tool, a preference). "Unknown" means no reason was given. 1. Classification Format: deal | amount | category | side - Deal-DB0AAC | 5,115 | timing | buyer - Deal-F7F635 | 3,600 | competitor | unknown - Deal-AC944F | 3,400 | no decision | unknown - Deal-214060 | 2,880 | no decision | unknown - Deal-91A056 | 2,975 | timing | buyer - Deal-29326C | 6,300 | timing | buyer - Deal-5DB9B0 | 10,800 | other (spam) | unknown - Deal-831B7B | 7,200 | timing | buyer - Deal-F97C37 | 4,320 | competitor | Bonusly (the other vendor had more diversified offerings) - Deal-13E9CF | 33,750 | no decision | buyer - Deal-39E25C | 3,360 | timing | buyer - Deal-7ED004 | 60,000 | pricing | buyer (no budget approval) - Deal-21B045 | 11,700 | no decision | unknown - Deal-B3ABED | 40,001 | timing | buyer - Deal-422BA6 | 3,000 | competitor | Bonusly (the winner is an ADP PEO partner with integrations) - Deal-ED9AE7 | 2,340 | timing | buyer - Deal-988493 | 8,400 | no decision | unknown - Deal-381C8C | 4,800 | competitor | unknown - Deal-F308CA | 30,321 | no decision | unknown - Deal-F1E8A6 | 3,150 | competitor | unknown - Deal-B6AC09 | 3,000 | timing | buyer - Deal-70F704 | 3,000 | other (scope: anniversary awards only) | buyer - Deal-E6E80A | 24,000 | timing | buyer - Deal-B038F0 | 2,340 | timing | buyer - Deal-4664E1 | 12,000 | no decision | unknown - Deal-175756 | 2,880 | timing | buyer - Deal-E74A73 | 2,100 | no decision | buyer - Deal-DDAB52 | 4,000 | competitor | Bonusly (Rippl offers more at the same cost, no FX issue) - Deal-ACE061 | 3,600 | competitor | unknown - Deal-BB78F3 | 6,600 | timing | buyer - Deal-D48E0B | 14,931 | no decision | unknown - Deal-15DA99 | 19,600 | timing | buyer - Deal-F4AF5D | 5,760 | timing | buyer - Deal-79B7A1 | 25,000 | timing | buyer - Deal-583ADB | 3,600 | no decision | unknown - Deal-8E27DA | 21,000 | other (bought swag only, no R&R) | buyer - Deal-2D2F8D | 4,800 | competitor | unknown - Deal-E0441F | 2,405 | no decision | unknown - Deal-7CB44D | 31,860 | no decision | unknown - Deal-0F96AA | 76,800 | competitor | unknown - Deal-1BCA50 | 15,000 | pricing | unknown - Deal-7CC678 | 11,116 | competitor | unknown - Deal-FAC17C | 2,100 | no decision | buyer - Deal-242273 | 60,000 | competitor | Bonusly (the other vendor could digitize points and allow spending at onsite facilities) - Deal-50E5D8 | 4,800 | no decision | buyer - Deal-A2C349 | 21,600 | competitor | buyer (stayed with Awardco) - Deal-9F176A | 54,600 | timing | buyer - Deal-7B2236 | 72,000 | pricing | Bonusly (wanted something simpler and cheaper) - Deal-AFA56C | 3,000 | no decision | unknown - Deal-C7156E | 13,818 | competitor | unknown - Deal-C33D91 | 7,200 | pricing | buyer - Deal-9048EB | 41,790 | product gap | Bonusly - Deal-5E64CE | 3,360 | timing | buyer (locked into Nectar until Oct 2027) - Deal-8A0992 | 7,336.56 | competitor | buyer (chose a Canadian provider) - Deal-D0C698 | 2,000 | competitor | buyer (client is a past Kudos user) - Deal-69CF3D | 11,520 | timing | buyer - Deal-ECBF89 | 7,200 | timing | buyer - Deal-3618CC | 15,600 | product gap | Bonusly (wanted surveys) - Deal-EECC02 | 66,690 | competitor | unknown - Deal-5AD03E | 24,000 | competitor | Bonusly (wanted more defined budget access; ambiguous) - Deal-D1A623 | 25,200 | timing | buyer - Deal-413C56 | 2,760 | no decision | buyer - Deal-47F1A1 | 10,004.40 | competitor | buyer (staying with WorkTango) - Deal-BF2A98 | 8,400 | competitor | buyer (already deployed HiThrive) - Deal-2A292B | 6,000 | other (building internally) | buyer - Deal-D1AABF | 23,400 | no decision | unknown - Deal-FEDBCB | 2,000 | no decision | buyer - Deal-1E7DA9 | 26,400 | competitor | unknown - Deal-2BBA21 | 2,310 | no decision | unknown - Deal-286F9C | 13,860 | competitor | unknown - Deal-7FBAC6 | 7,200 | no decision | buyer - Deal-369281 | 2,400 | competitor | buyer (used what they have in Paylocity) - Deal-386F6E | 13,895 | no decision | unknown - Deal-9FCD0D | 4,300 | competitor | buyer (CEO preferred a Canadian company) - Deal-55867E | 7,200 | timing | unknown - Deal-DAFB82 | 30,000 | pricing | buyer - Deal-2FEDDB | 2,200 | no decision | buyer - Deal-64B19A | 3,240 | competitor | buyer (likely stayed with Motivosity) - Deal-3F86A0 | 3,840 | no decision | unknown - Deal-096750 | 2,880 | no decision | unknown - Deal-F325A5 | 14,400 | champion left (layoffs, leadership change) | buyer - Deal-ABD14C | 5,002.20 | no decision | buyer - Deal-79E61A | 7,020 | no decision | unknown - Deal-8A119B | 3,250 | pricing | buyer - Deal-AE7C4E | 2,800 | no decision | unknown - Deal-DAB4F1 | 3,450 | no decision | unknown - Deal-B4B50F | 21,060 | no decision | unknown - Deal-981AD4 | 36,855 | product gap | Bonusly (UI, not UK-focused) - Deal-DC77FE | 8,000 | competitor | Bonusly (the other system had more customization, e.g. labelling points as dollars) - Deal-5885B9 | 7,200 | no decision | unknown 2. Category counts | Category | Deals | Amount | |---|---|---| | No decision | 30 | $274,264.20 | | Competitor | 25 | $391,234.96 | | Timing | 21 | $265,551.00 | | Pricing | 6 | $187,450.00 | | Other | 4 | $40,800.00 | | Product gap | 3 | $94,245.00 | | Champion left | 1 | $14,400.00 | | Total | 90 | $1,267,945.16 | Deal check: 30 + 25 + 21 + 6 + 4 + 3 + 1 = 90. 3. Side split | Side | Deals | Amount | |---|---|---| | Buyer | 45 | $524,394.16 | | Unknown | 35 | $473,986.00 | | Bonusly | 10 | $269,565.00 | | Total | 90 | $1,267,945.16 | Deal check: 45 + 35 + 10 = 90. 4. Tag vs. free-text disagreement Six deals have a tag that clearly contradicts the text: - Deal-70F704: tagged Lost DM, but the text says they only wanted anniversary awards and went MIA. - Deal-8E27DA: tagged Feature Request, but they bought a swag provider and didn't want R&R. - Deal-1BCA50: tagged Competitor, but the text says it was "mostly about the budget." - Deal-9048EB: tagged MIA, but the text says it was a bad fit with multiple feature gaps. - Deal-5E64CE: tagged Doing nothing, but they're locked into a Nectar contract until Oct 2027. - Deal-3618CC: tagged Lost DM, but the text says "Wanted Surveys." Five more are borderline and not counted above: - Deal-13E9CF: the tag includes "Cost," but the text says "Not a budget issue." - Deal-381C8C, Deal-F1E8A6 and Deal-7CC678: tagged Competitor, but the text never mentions a competitor. - Deal-55867E: tagged Timing, but the text gives no timing reason. 5. Two patterns most worth acting on Pattern 1: Buyers going silent is the most common loss. - 21 of the 30 no-decision deals are ghosting losses (MIA, unresponsive or no response), worth $212,352. - Several went quiet right after the intro or demo and ignored repeated rep and ADR outreach: Deal-F308CA $30,321, Deal-7CB44D $31,860, Deal-4664E1 $12,000, Deal-2BBA21, Deal-096750. - Including these, 35 of 90 deals ($473,986, 37%) record no usable loss reason. - Action: tighten qualification and next-step commitments after the intro and demo, and require a real reason when closing a deal as MIA. Pattern 2: Competitor is the biggest category by dollars ($391,234.96), and when a reason exists it points to specific capability gaps. - 11 of the 25 competitor losses ($228,634) have no stated reason. These include the two biggest: Deal-0F96AA $76,800 (cut before the RFP finalist stage) and Deal-EECC02 $66,690. - 6 of the 25 ($103,320) are on Bonusly's side, and each names a specific gap: - points currency spendable at onsite facilities (Deal-242273, $60,000) - ADP PEO partner integration (Deal-422BA6) - customization such as labelling points as dollars (Deal-DC77FE) - broader offerings beyond R&R (Deal-F97C37) - value for cost without FX exposure (Deal-DDAB52) - budget access (Deal-5AD03E) - Two more deals went to a Canadian provider (Deal-8A0992, Deal-9FCD0D). - Action: run win/loss interviews on the unexplained competitor losses, and send the named gaps (points customization, onsite points, ADP/PEO, Canada/UK localization) to product.
```json
{
"tier_counts": {"LOCK": 6, "ACTION": 10, "BUILD": 39, "REVIVE": 13, "WATCH": 53, "RISKY": 35},
"tier_examples": {
"LOCK": ["Deal-25F752", "Deal-D348E1", "Deal-C26D20"],
"ACTION": ["Deal-C6FE92", "Deal-499BF6", "Deal-1FC049"],
"BUILD": ["Deal-D73B89", "Deal-03BA69", "Deal-93C8BF"],
"REVIVE": ["Deal-2D1F1B", "Deal-66D1FC", "Deal-950043"],
"WATCH": ["Deal-6787C2", "Deal-EC3025", "Deal-92D97D"],
"RISKY": ["Deal-E53952", "Deal-547B2B", "Deal-7BBDFA"]
},
"risky_deals": ["Deal-E53952","Deal-5408B0","Deal-9AAE5F","Deal-547B2B","Deal-B7EBD1","Deal-A2B47C","Deal-2465CE","Deal-C61CF7","Deal-62D607","Deal-584EE5","Deal-C6D97A","Deal-7B3B0F","Deal-F9A08A","Deal-0660B4","Deal-FD9F4E","Deal-BA571A","Deal-FC22A3","Deal-7BBDFA","Deal-60C2C2","Deal-4A13AD","Deal-8AD4A5","Deal-15D24F","Deal-9D0060","Deal-690476","Deal-635B8E","Deal-ED725A","Deal-55164C","Deal-3BA5EA","Deal-5FDCE4","Deal-F336B6","Deal-5EED42","Deal-BA3DDC","Deal-7599B8","Deal-F9A3C1","Deal-FA32A0"],
"lock_violations": 0,
"pipeline_shape": "156 open deals. Counts: 6+10+39+13+53+35 = 156. The late-stage forecast is weak. 51 deals are marked COMMIT or BEST_CASE (6 LOCK + 10 ACTION + 35 RISKY). Of those, 35 have zero meetings_30d, which is 35/51 = 68.6%. The RISKY group totals $291,746. LOCK is only 6 deals, all DS4/DS5 with at least 1 meeting, 3+ contacts, and contact since 08-28, totaling $79,770 (24,000+13,770+13,500+10,500+9,000+9,000). By comparison, RISKY holds 3.7x the LOCK value. Most PIPELINE deals are either BUILD (39, with meetings and mostly new DS1-DS3 deals created in Aug-Sep) or WATCH (53, recently emailed but no meetings). REVIVE is 13 deals with no contact since 2026-08-20. That includes the largest deal, Deal-2D1F1B ($240,000, last contact 2026-06-16). Assumptions: the as-of date is 2026-09-04 (the latest date in the data) and 'recent' means contact within 14 days. Data gaps: Deal-3EED2C has no engagement row and no last_contacted date. Deal-57FF13's columns are shifted and it has no engagement row. Both are tiered REVIVE because their data is missing, not because of their actual engagement."
}
```
```json
[
{
"transcript_id": "TX-001",
"deal_alias": "Deal-CFE7F4",
"why_buys": [
"Automate anniversary and birthday awards (VP People)"
],
"pain_points": [
"HR team of three cannot keep up with awards manually (VP People)",
"Everything is tracked in a spreadsheet and people slip through the cracks (HR Admin)"
],
"stakeholders": [
"Prospect (VP People)",
"Prospect (HR Admin)"
],
"stakeholders_note": "An IT lead is referenced but was not on the call, so they are not listed.",
"budget_signal": "About $40k earmarked for engagement tools this fiscal year (VP People). This is the budget for the whole engagement-tools category, not an amount for this deal.",
"timeline_signal": "Ideally live before open enrollment in November (VP People)",
"competitor_mentioned": "Achievers. The prospect looked at it last year and found it too heavy for a team their size. The prospect named it in answer to the rep's question.",
"next_step": "Security review on September 12 (agreed by VP People)",
"objections": [
"IT sign-off requires SSO and audit logs (HR Admin). The rep said SSO/SAML is supported, but the prospect has not confirmed audit logs."
],
"confidence": "High. The prospect stated the budget, timeline and pain, and the next step has a date."
},
{
"transcript_id": "TX-002",
"deal_alias": "Deal-70BB30",
"why_buys": [
"Tie recognition to retention for the hourly workforce (Head of Total Rewards)"
],
"pain_points": [
"Regretted turnover in the hourly workforce is over 30% (Head of Total Rewards)"
],
"stakeholders": [
"Prospect (Head of Total Rewards)",
"Prospect (CFO)"
],
"budget_signal": "Finance approved a $25k pilot budget for this quarter (CFO)",
"timeline_signal": "Decision wanted by end of September (CFO)",
"competitor_mentioned": null,
"competitor_note": "The prospect said this is the first vendor they've had a real demo with.",
"next_step": "Rep sends the pilot agreement, and the prospect routes it to legal this week (agreed by CFO)",
"objections": [
"CFO's one condition: Workday integration must be rock solid. The rep said the integration is standard, but the prospect has not confirmed it."
],
"confidence": "High. The CFO is on the call, the budget is approved, the decision date is near and the next step is agreed."
},
{
"transcript_id": "TX-003",
"deal_alias": "Deal-530B50",
"why_buys": [
"Make recognition visible across 12 retail locations (People Ops Manager)"
],
"pain_points": [
"Store managers have zero budget autonomy for on-the-spot recognition today (People Ops Manager)"
],
"stakeholders": [
"Prospect (People Ops Manager)"
],
"stakeholders_note": "The CEO is referenced as the decision-maker for anything people-related but was not on the call.",
"budget_signal": null,
"budget_note": "The prospect stated no budget. The ~$8 per employee per month figure came from the rep and is excluded.",
"timeline_signal": "No rush until Q1 (People Ops Manager)",
"competitor_mentioned": "Bucketlist. The CEO used it at her last company and liked it. The prospect raised this without being asked.",
"next_step": "Schedule a call with the CEO. The People Ops Manager will send two times; no date is set yet.",
"objections": [
"The CEO has to be sold first and decides anything people-related",
"The CEO already has a positive view of Bucketlist"
],
"confidence": "Medium-low. There is no budget, the timeline is soft, and the decision-maker hasn't been engaged and favors a competitor."
},
{
"transcript_id": "TX-004",
"deal_alias": "Deal-180D02",
"why_buys": [
"Consolidate three separate recognition tools into one (VP People)"
],
"pain_points": [
"Paying for three tools, and none of them connect to the HRIS (VP People)"
],
"stakeholders": [
"Prospect (VP People)",
"Prospect (IT Security Lead)"
],
"stakeholders_note": "A CFO was mentioned by the rep, and the VP People referred to 'her calendar'. The CFO was not on the call.",
"budget_signal": "VP People can approve without the board if the cost is under $15k per year. This is an approval limit, not an allocated budget.",
"timeline_signal": "Procurement takes six to eight weeks minimum (IT Security Lead). No target go-live or decision date was stated.",
"competitor_mentioned": null,
"next_step": null,
"next_step_note": "Nothing was agreed. The CFO follow-up got 'Maybe... no promises', and 'I'll follow up' was the rep's own commitment.",
"objections": [
"The last vendor's security review took three months (IT Security Lead)",
"Procurement takes six to eight weeks minimum (IT Security Lead)"
],
"confidence": "Low. There is no agreed next step, no budget amount, a long procurement and security path, and the CFO isn't engaged."
},
{
"transcript_id": "TX-005",
"deal_alias": "Deal-F8767A",
"why_buys": [
"Automate service milestones (HR Director)",
"Analytics on recognition equity across departments (HR Director)"
],
"pain_points": [
"Night-shift teams feel invisible, and their engagement scores run 20 points lower (People Ops Coordinator)"
],
"stakeholders": [
"Prospect (HR Director)",
"Prospect (People Ops Coordinator)"
],
"stakeholders_note": "The exec team is referenced but was not on the call.",
"budget_signal": "$12k approved under the engagement line (HR Director)",
"timeline_signal": "Must be running before the January all-hands (HR Director)",
"competitor_mentioned": "Nectar. The prospect is mid-pilot with it, and Bonusly would need to beat that experience. The prospect raised this without being asked.",
"next_step": "Present to the exec team on October 2 (agreed by HR Director)",
"objections": [
"Must beat the current Nectar pilot experience",
"The exec team is skeptical after a failed rollout two years ago"
],
"confidence": "Medium-high. Budget, timeline and a dated next step are all in place, but there is an active competitor pilot and the exec team is skeptical."
},
{
"transcript_id": "TX-006",
"deal_alias": "Deal-EE195F",
"why_buys": [
"Cut admin time on service awards (HR Manager)"
],
"pain_points": [
"HR Manager personally spends five hours a month ordering and shipping plaques (5 hrs x 12 months = 60 hrs per year, derived)"
],
"stakeholders": [
"Prospect (HR Manager)"
],
"stakeholders_note": "The COO is referenced but was not on the call.",
"budget_signal": "Budget isn't the issue, time is (HR Manager). No amount was stated. The rep's offer to flex on pricing is excluded.",
"timeline_signal": "Fiscal year resets in February, so a Q1 start is realistic (HR Manager)",
"competitor_mentioned": null,
"competitor_note": "The prospect is comparing against doing it internally, not against another vendor.",
"next_step": "Rep sends a one-page overview, and the HR Manager forwards it to the COO this week (agreed by HR Manager)",
"objections": [
"The COO usually prefers building things in-house"
],
"confidence": "Medium-low. There is only one stakeholder, no budget amount, and a decision-maker who leans toward building in-house."
}
]
```
Top 3 closest to signature (Slack thread dated 2026-09-04): 1. Deal-547B2B: $11,200 (Alex Franklin, DS5/COMMIT, close 2026-09-11) - Why close: Redlines came back clean, the signing page is out, and their VP People said they would sign "tomorrow" (2026-09-05). This is the strongest signal in the data. - What's left: Only the signature itself. 2. Deal-403845: $9,000 (DS5/COMMIT, close 2026-09-11) - Why close: The order form is with their finance team, which is the final approval step. - What's left: Finance approval, then signature. - Flag: The CRM lists Alex Franklin as owner, but Dana Mercer calls it "on my side." The owner needs to be confirmed. 3. Deal-A2B47C: $6,360 (Alex Franklin, DS5/COMMIT, close 2026-09-11) - Why close: Slack says it's "still warm, just normal legal-review pace," and CRM has it in COMMIT with an early close date. - What's left: Finish legal review, then signature. No signing date is given. Combined: $11,200 + $9,000 + $6,360 = $26,560. Left out: - Deal-2465CE ($5,400, still COMMIT in CRM): The champion left and procurement froze new vendors. Dana is pulling it from commit and now sees it as Q4. CRM needs updating. - Deal-D348E1 ($13,770): Same legal-review status as A2B47C, but its close date is later (2026-10-15). - Deal-B7EBD1 ($9,000, DS5/COMMIT, 2026-09-10): Slack doesn't mention it, so its status can't be confirmed. Caveat: The Slack thread is from 2026-09-04. Nothing in the data shows whether Deal-547B2B actually signed on 2026-09-05. The CRM close dates of 2026-09-10 and 2026-09-11 may also have passed without updates.
Candidate review 1. Deal-EC3025, amount not provided Prospect (IT Security Lead): "We need SCIM user provisioning — our security team will not approve any tool that requires manual account management." Classification: REAL GAP. The docs say SCIM user provisioning is "NOT currently listed as supported capabilities." 2. Deal-D0D6B5, amount not provided Prospect (HRIS Manager): "Our payroll runs on ADP Workforce Now and I don't see ADP anywhere in your integration list — that's a dealbreaker for us." Classification: REAL GAP. The supported HRIS integrations are Workday, BambooHR, Gusto and Rippling. The docs say ADP Workforce Now is "NOT currently listed." 3. Deal-CFE7F4, amount not provided 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?" Classification: PLAN GATE. The custom report builder is available on Enterprise only (Core and Pro show "—"). 4. Deal-84DBA6, amount not provided 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." Classification: ROLLOUT/ENABLEMENT ISSUE. The Slack integration is supported on all plans. The problem is that managers weren't trained, not a missing capability. 5. Deal-36C33F, amount not provided Excluded. The gap (no native mobile app for hourly workers) was raised by the rep, Alex Franklin, so it doesn't count as prospect voice. The prospect's only line, "The web version should be fine for our office staff for now," doesn't raise a gap. Mobile apps also don't appear in the docs excerpt. Summary: real gaps only | Deal | Gap | Amount | |---|---|---| | Deal-EC3025 | SCIM user provisioning | not provided | | Deal-D0D6B5 | ADP Workforce Now integration | not provided | Total amount at risk: can't be calculated because deal amounts aren't in the data. It would be the amount of Deal-EC3025 plus the amount of Deal-D0D6B5. Missing data: - No deal amounts are provided. - No deal stage or status is provided, so I can't confirm that these deals are active.
I found 73 open deals with no email, call or meeting logged in the last 7 days, worth a combined $1,334,981.03. That covers 5 of the 6 owners. How I calculated it: - Last contact is the latest of the deal's last_email, last_call and last_meeting dates from engagements_by_deal_90d.csv, counting only dates on or before 2026-09-05. I ignored last_contacted_field. - Days since last contact = 2026-09-05 minus that date. A deal is stale if the result is more than 7, so the last date that counts as stale is 2026-08-28. - Some last_meeting dates fall after 2026-09-05. I treated those as scheduled meetings, not logged contact, and left them out. The deals affected are marked with an asterisk (*). Alex Franklin (19 deals): | Deal | Stage | Amount | Days | |---|---|---|---| | Deal-CC08D1 | DS1 | $24,000 | 16 | | Deal-E73427 | DS3 | $18,000 | 10 | | Deal-885F45 | DS2 | $9,300 | 12 | | Deal-C2FF3C | DS1 | $8,316 | 10 | | Deal-0D2F7A | DS3 | $5,100 | 12 | | Deal-6C60D4 | DS3 | $4,800 | 12 | | Deal-13FEBD | DS2 | $4,680 | 12 | | Deal-819506 * | DS1 | $4,400 | 8 | | Deal-9D0060 | DS3 | $3,840 | 12 | | Deal-690476 | DS2 | $3,600 | 18 | | Deal-C6D97A | DS4 | $3,240 | 8 | | Deal-EE195F | DS3 | $3,120 | 8 | | Deal-278DEC | DS3 | $2,700 | 8 | | Deal-635B8E | DS3 | $2,600 | 18 | | Deal-6883F3 | DS1 | $2,400 | 16 | | Deal-4A13AD | DS3 | $2,160 | 26 | | Deal-F67D31 | DS2 | $1,800 | 8 | | Deal-5FDCE4 | DS3 | $1,600 | 12 | | Deal-BA571A | DS4 | $1,080 | 18 | Bryce Harmon (18 deals): | Deal | Stage | Amount | Days | |---|---|---|---| | Deal-2D1F1B | DS1 | $240,000 | 81 | | Deal-66D1FC | DS1 | $99,000 | 16 | | Deal-950043 | DS1 | $70,000 | 19 | | Deal-B23205 | DS1 | $45,000 | 16 | | Deal-7BBDFA | DS3 | $37,440 | 46 | | Deal-332637 | DS2 | $36,000 | 9 | | Deal-1BEEBF | DS1 | $31,500 | 19 | | Deal-A414F6 * | DS1 | $25,200 | 19 | | Deal-C5658B | DS1 | $23,400 | 16 | | Deal-40522D | DS3 | $21,000 | 19 | | Deal-C1FA6D * | DS1 | $18,000 | 16 | | Deal-01E193 * | DS1 | $12,600 | 8 | | Deal-F0EBBB | DS3 | $11,400 | 24 | | Deal-927338 * | DS1 | $10,920 | 18 | | Deal-E25A09 | DS1 | $6,000 | 9 | | Deal-C9C286 | DS2 | $5,502 | 9 | | Deal-012CB1 | DS1 | $1 | 23 | | Deal-3795AD * | DS2 | $1 | 8 | Cole Ingram (18 deals): | Deal | Stage | Amount | Days | |---|---|---|---| | Deal-D04904 | DS2 | $58,529.25 | 11 | | Deal-B25F40 | DS3 | $40,000 | 8 | | Deal-813836 | DS2 | $32,175 | 11 | | Deal-1BA595 | DS2 | $31,750 | 11 | | Deal-CFE1E8 | DS3 | $18,000 | 11 | | Deal-CD47A6 | DS2 | $12,168 | 11 | | Deal-627646 | DS3 | $11,193 | 11 | | Deal-FF809F | DS2 | $7,781.20 | 11 | | Deal-AF932D | DS2 | $7,225.40 | 11 | | Deal-A71728 | DS2 | $6,947.50 | 11 | | Deal-8BC9F5 | DS2 | $5,616 | 10 | | Deal-175395 | DS3 | $4,779.88 | 11 | | Deal-481E24 | DS3 | $4,140 | 10 | | Deal-C7F9BF | DS2 | $3,360 | 11 | | Deal-2F3A66 | DS3 | $3,334.80 | 11 | | Deal-342E96 | DS2 | $2,700 | 24 | | Deal-E568D5 | DS3 | $1,875 | 11 | | Deal-FD9F4E | DS5 | $1,330 | 10 | Dana Mercer (16 deals): | Deal | Stage | Amount | Days | |---|---|---|---| | Deal-44EA29 | DS2 | $60,000 | 10 | | Deal-E51FB7 | DS2 | $43,875 | 12 | | Deal-B42F46 | DS1 | $27,000 | 19 | | Deal-BA3DDC | DS3 | $23,400 | 15 | | Deal-9DDE86 | DS2 | $20,000 | 15 | | Deal-215CCA | DS3 | $18,900 | 17 | | Deal-5EED42 | DS3 | $16,250 | 11 | | Deal-57887A | DS2 | $15,000 | 8 | | Deal-944310 * | DS4 | $10,500 | 33 | | Deal-B7EBD1 | DS5 | $9,000 | 16 | | Deal-3974EB | DS4 | $9,000 | 8 | | Deal-F40F04 | DS2 | $8,100 | 15 | | Deal-7599B8 * | DS3 | $7,350 | 18 | | Deal-87DDD1 | DS1 | $5,000 | 19 | | Deal-F336B6 | DS3 | $4,200 | 15 | | Deal-0660B4 | DS4 | $1,920 | 16 | Farid Osman (2 deals): | Deal | Stage | Amount | Days | |---|---|---|---| | Deal-8BA24E * | DS1 | $2,880 | 8 | | Deal-8FDCD2 * | DS1 | $1 | 15 | Totals per owner: | Owner | Stale deals | Stale amount | |---|---|---| | Bryce Harmon | 18 | $692,964.00 | | Dana Mercer | 16 | $279,495.00 | | Cole Ingram | 18 | $252,905.03 | | Alex Franklin | 19 | $106,736.00 | | Farid Osman | 2 | $2,881.00 | | Elena Sinclair | 0 | $0 | | All owners | 73 | $1,334,981.03 | Arithmetic: - Deal count: 18 + 16 + 18 + 19 + 2 = 73 - Total amount: 692,964 + 279,495 + 252,905.03 + 106,736 + 2,881 = 1,334,981.03 Two open deals have no row in the engagements table, so I couldn't calculate their recency. They are not in the counts above: - Deal-3EED2C (Alex Franklin, DS2, $7,200) - Deal-57FF13 (Elena Sinclair, DS1, $2,100). Its row in deals_open.csv also looks misaligned: the source column holds "3" and n_contacts is blank.
Rep activity efficiency per DS2 entry (last 30 days, snapshot 2026-09-05) How I counted - Window: 2026-0806 to 2026-09-05, both days included. - Activities = emails_30d + calls_30d + meetings_30d from engagements_by_deal_90d.csv. Each deal is assigned to its owner_id in deals_open.csv. Notes and inbound emails are not counted. - DS2 entries = open deals with t_ds2 inside the window. Per-rep results 1. Alex Franklin (84342457) - Activities: 307 emails + 36 calls + 41 meetings = 384 - Mix: emails 307/384 = 79.9%, calls 36/384 = 9.4%, meetings 41/384 = 10.7% - DS2 entries (18): Deal-403845, Deal-1FC049, Deal-3EED2C, Deal-7FA0C3, Deal-E531A6, Deal-5296C9, Deal-36C33F, Deal-EE195F, Deal-F436DA, Deal-317E6F, Deal-D1E6C2, Deal-D9A72E, Deal-CA5E44, Deal-4F775F, Deal-898FC5, Deal-46988D, Deal-E73427, Deal-92D97D - Activities per DS2 entry: 384 / 18 = 21.33 2. Bryce Harmon (119337721) - Activities: 162 + 0 + 43 = 205 - Mix: emails 79.0%, calls 0.0%, meetings 21.0% - DS2 entries (4): Deal-25F752, Deal-CA7DC0, Deal-D73B89, Deal-1CCE5C - Activities per DS2 entry: 205 / 4 = 51.25 3. Cole Ingram (83155924) - Activities: 96 + 14 + 1 = 111 - Mix: emails 86.5%, calls 12.6%, meetings 0.9% - DS2 entries (2): Deal-1BA595, Deal-42326B - Activities per DS2 entry: 111 / 2 = 55.50 4. Farid Osman (716654662) - Activities: 38 + 0 + 34 = 72 - Mix: emails 52.8%, calls 0.0%, meetings 47.2% - DS2 entries (1): Deal-499BF6 - Activities per DS2 entry: 72 / 1 = 72.00 5. Dana Mercer (83155923) - Activities: 84 + 18 + 11 = 113 - Mix: emails 74.3%, calls 15.9%, meetings 9.7% (adds to 99.9% because of rounding) - DS2 entries (1): Deal-57887A - Activities per DS2 entry: 113 / 1 = 113.00 Not ranked: Elena Sinclair (701163055) had 0 activities and 0 DS2 entries, so the ratio can't be calculated. Her only deal, Deal-57FF13, has no engagement row. Efficiency ranking (fewest activities per DS2 entry first) 1. Alex Franklin: 21.33 2. Bryce Harmon: 51.25 3. Cole Ingram: 55.50 4. Farid Osman: 72.00 5. Dana Mercer: 113.00 Answer - Most efficient: Alex Franklin (21.33 activities per DS2 entry). - Highest volume: Alex Franklin (384 activities). - It's the same rep, not two different ones. Caveats about the data - Window edge: three deals entered DS2 on 2026-08-06, exactly 30 days before the snapshot: Deal-1CCE5C (Bryce), Deal-EE195F and Deal-D9A72E (Alex). If that day is excluded: - Bryce: 205 / 3 = 68.33 - Alex: 384 / 16 = 24.00 - Cole (55.50) moves above Bryce. Alex stays first on both measures. - Only open deals are covered. Closed deals, and activity not linked to a deal, aren't in the files. Any closed deal that entered DS2 in the window is missing from the counts. - Deal-3EED2C (Alex) has no engagement row, so its activity is counted as 0.
**QTD Scorecard: Alex Franklin, 2026-Q3 (as of 2026-09-05)** Quarter window: 2026-07-01 to 2026-09-05. Sources: ae_deals.csv, ae_engagements.csv, quota.csv. **1. Bookings vs quota** - Closed-won in the quarter: 8 deals, $150,000. - Excluded: Deal-B3E6F1 ($24,000, closed 2026-06-20). It closed before the quarter started. - Quota: $200,000. - Attainment: 150,000 / 200,000 = **75.0%**. - Gap to quota: $50,000. **2. New vs expansion split (QTD won)** | Type | Deals | Amount | Share | |---|---|---|---| | New | 5 | $113,500 | 75.7% | | Expansion | 3 | $36,500 | 24.3% | - New: Deal-A1C3E5 40,000 + Deal-B7D2F4 35,000 + Deal-C9E1A6 21,000 + Deal-D4B8C2 11,000 + Deal-E6F3A9 6,500 = $113,500 (113,500 / 150,000 = 75.7%). - Expansion: Deal-F2C7D8 20,000 + Deal-A8B4D6 12,000 + Deal-C5D9E2 4,500 = $36,500 (36,500 / 150,000 = 24.3%). - Open deals have no deal_type value, so I can't split pipeline into new vs expansion. **3. Active pipeline by stage (status = open)** | Stage | Deals | Amount | |---|---|---| | DS1 | 20 | $284,621 | | DS2 | 28 | $353,760 | | DS3 | 67 | $552,705 | | DS4 | 5 | $23,574 | | DS5 | 5 | $45,730 | | Total | 125 | $1,260,390 | - Past due: Deal-7A2454 (DS3, $1,275) had a close date of 2026-09-04 and is still open. - Open deals with close dates from 2026-09-05 to 2026-09-30: 21 deals, $108,088. - Of those, DS4/DS5 deals total $34,204: - DS4: Deal-1FC049 1,920 + Deal-F9A08A 2,484 + Deal-C6D97A 3,240 - DS5: Deal-403845 9,000 + Deal-547B2B 11,200 + Deal-A2B47C 6,360 **4. Rolling 90-day DS2-to-won rate (2026-06-07 to 2026-09-05)** - Basis: deals that reached DS2 and closed within the window. - Won 9, lost 27, so 9 / 36 = **25.0%** by count. - By dollars: $174,000 / $503,272 = 34.6%. - The 9 wins include Deal-B3E6F1 (closed 2026-06-20). It falls inside the 90-day window even though it's outside the quarter. Without it: 8 / 35 = 22.9%. - Cohort view (deals that entered DS2 inside the window): 111 deals, 8 won, 27 lost, 76 still open. That gives 7.2% won so far, but the cohort is immature. **5. Win and loss counts (QTD)** - Won: 8 ($150,000). Lost: 27 ($329,272). - Win rate: 8 / (8 + 27) = 22.9% by count; 150,000 / 479,272 = 31.3% by dollars. | Loss reason | Count | Amount | |---|---|---| | Lost- Timing (1 year or more) | 13 (48.1%) | $184,681 (56.1%) | | Competitor | 5 | $49,020 | | MIA | 5 | $45,831 | | Lost DM | 2 | $17,940 | | Feature Request | 1 | $21,000 | | Lost- Does not fit ICP (write in notes) | 1 | $10,800 | - **Top loss reason: Lost- Timing (1 year or more).** **6. Activity volume, last 30 days (all 161 deals, from the 30d columns)** | Type | Count | |---|---| | Emails | 807 | | Calls | 112 | | Meetings | 128 | | Notes | 50 | | Total | 1,097 | - Per-deal averages: - QTD won (8 deals: 89 emails, 31 calls, 23 meetings, 21 notes): 11.1 emails, 3.9 calls, 2.9 meetings. - Lost (27 deals: 109 emails, 25 calls, 13 meetings, 25 notes): 4.0 emails, 0.93 calls, 0.48 meetings. - Open (125 deals: 599 emails, 54 calls, 90 meetings, 1 note): 4.8 emails, 0.43 calls, 0.72 meetings. - The file has no activity dates, so I can't check the 30-day window myself. The totals include Deal-B3E6F1's activity (10 emails, 2 calls, 2 meetings, 3 notes). **Coaching observations** 1. **Late-stage pipeline can't close the $50,000 gap.** The DS4/DS5 deals closing in September total $34,204, which leaves $15,796 short even if every one closes. The rest has to come from DS3 deals with September close dates, and a quarter-to-date win rate of 22.9% makes that unlikely. Deal-7A2454 is also past due and should be updated. 2. **Timing losses are a qualification problem.** "Lost- Timing (1 year or more)" accounts for 13 of 27 losses and $184,681 of $329,272 (56.1%). All 27 lost deals had reached DS2 before losing. Buying timeline should be confirmed before a deal moves into DS2. 3. **Open deals get far less contact than deals that won.** Won deals averaged 3.9 calls and 2.9 meetings each in the last 30 days. Open deals averaged 0.43 calls and 0.72 meetings, and 62 of the 125 open deals had no calls or meetings at all. There was 1 note across all $1,260,390 of open pipeline. The open profile looks more like the lost deals than the won ones.
Assumptions and gaps:
- Amount and stage are not in either file, so both are "not provided" for every deal. That means I can't tailor the persona to add by stage. The recommendation below uses coverage gaps only: economic buyer first if missing, then whichever persona has a contact on file.
- Open or closed status is also not provided, so I treated all 14 deals as open.
- As-of date is 2026-09-24 (today). 60 days back gives a cutoff of 2026-07-26. "Active" means last_engaged_date on or after 2026-07-26 and is_former = false.
Flagged deals: 11 of 14.
SINGLE-THREADED (fewer than 2 active contacts)
1. Deal-EC3025 (C-FDD0C7)
- Amount / stage: not provided
- Active contacts: 1. CT-047C54 counts. CT-F2C1AE is excluded because is_former = true.
- Personas present: champion
- Personas missing: economic buyer, HR admin, IT security, finance
- Most valuable to add: economic buyer
- On-file unengaged fit: CT-6827DB (Chief People Officer, economic buyer)
2. Deal-92D97D (C-E23238)
- Amount / stage: not provided
- Active contacts: 1. CT-01F5B4 counts. CT-A902AE is excluded because 2026-06-01 is before the cutoff.
- Personas present: HR admin
- Personas missing: champion, economic buyer, IT security, finance
- Most valuable to add: economic buyer. Re-engaging the lapsed champion CT-A902AE is also an option.
- On-file unengaged fit: none on file
3. Deal-36C33F (C-077A0E)
- Amount / stage: not provided
- Active contacts: 1. CT-4FE556 counts. CT-405B45 and CT-86B22F are both excluded as former.
- Personas present: IT security
- Personas missing: champion, economic buyer, HR admin, finance
- Most valuable to add: economic buyer
- On-file unengaged fit: CT-1DB73E (Chief People Officer, economic buyer)
4. Deal-FCBE5B (C-737030)
- Amount / stage: not provided
- Active contacts: 1 (CT-4A5317)
- Personas present: champion
- Personas missing: economic buyer, HR admin, IT security, finance
- Most valuable to add: economic buyer
- On-file unengaged fit: none on file
5. Deal-F9A08A (C-0D15DF)
- Amount / stage: not provided
- Active contacts: 1. CT-931B10 counts. CT-913581 is excluded because 2026-06-20 is before the cutoff.
- Personas present: champion
- Personas missing: economic buyer (lapsed), HR admin, IT security, finance
- Most valuable to add: economic buyer
- On-file unengaged fit: CT-697541 (Chief People Officer, economic buyer)
UNDER-THREADED (fewer than 3 active contacts, or all active contacts in one persona)
6. Deal-50D386 (C-EB10E4)
- Amount / stage: not provided
- Active contacts: 2 (CT-AA41B2, CT-B9C35B)
- Personas present: champion, HR admin
- Personas missing: economic buyer, IT security, finance
- Most valuable to add: economic buyer
- On-file unengaged fit: CT-A1C4B3 (Chief People Officer, economic buyer)
7. Deal-D0D6B5 (C-32918E)
- Amount / stage: not provided
- Active contacts: 3 (CT-87CED4, CT-DE6D7C, CT-FD70B2), all champions
- Personas present: champion only
- Personas missing: economic buyer, HR admin, IT security, finance
- Most valuable to add: economic buyer
- On-file unengaged fit: CT-1FA4DB (Chief People Officer, economic buyer)
8. Deal-5BFE3B (C-535D36)
- Amount / stage: not provided
- Active contacts: 2 (CT-57123B, CT-5CE757), both champions
- Personas present: champion only
- Personas missing: economic buyer, HR admin, IT security, finance
- Most valuable to add: economic buyer
- On-file unengaged fit: none on file
9. Deal-885F45 (C-5E8EFB)
- Amount / stage: not provided
- Active contacts: 2 (CT-51C81E, CT-D9A0E8)
- Personas present: economic buyer, champion
- Personas missing: HR admin, IT security, finance
- Most valuable to add: IT security. The economic buyer is already engaged, and this is the only missing persona with a contact on file.
- On-file unengaged fit: CT-B3F25D (IT Security Lead, IT security)
10. Deal-5408B0 (C-2AE3AA)
- Amount / stage: not provided
- Active contacts: 2 (CT-D33AE4, CT-8742FD)
- Personas present: champion, HR admin
- Personas missing: economic buyer, IT security, finance
- Most valuable to add: economic buyer
- On-file unengaged fit: CT-07FA76 (Chief People Officer, economic buyer)
11. Deal-C6D97A (C-5A8FC2)
- Amount / stage: not provided
- Active contacts: 3 (CT-223DDC, CT-B03555, CT-4E8A2B), all champions
- Personas present: champion only
- Personas missing: economic buyer, HR admin, IT security, finance
- Most valuable to add: economic buyer
- On-file unengaged fit: none on file
NOT FLAGGED
- Deal-84DBA6: 3 active contacts across 3 personas (champion, economic buyer, IT security).
- Deal-4B0BEB: 4 active contacts across 4 personas.
- Deal-D348E1: 5 active contacts across all 5 personas.
Totals: 5 single-threaded + 6 under-threaded = 11 flagged. 7 of the 11 have a fitting unengaged contact on file; 4 have none on file.
Scope: 10 calls (TT-001 to TT-010), rep Alex Franklin, 2026-07-28 to 2026-09-03.
**1. What the rep leads with in the first five minutes (minutes 0–4)**
- **Customer proof story: 8 of 10 calls (80%).** Calls TT-001, 002, 003, 005, 006, 007, 008 and 010 all open with the same line:
"Quick one to kick off: a 400-person retailer we work with cut regretted turnover 18% in two quarters after automating milestone awards, and I wanted to walk you through exactly how they did it."
- **Agenda or pricing first: 2 of 10 (20%).** TT-004 (Deal-403845) opens with a security-review-then-pricing agenda. TT-009 (Deal-1E2498) opens on pricing because the prospect asked for it last time.
- **Rep names a competitor unprompted: 1 of 10.** In TT-005 (Deal-C61CF7) at minute 2 the rep brings up Workhuman.
**2. The three most common objections and how the rep handles them**
Counts: budget locked 4, timing ("revisit next quarter") 3, status quo 3. Next most common were committee stalls (2: TT-004, TT-010) and competitor comparisons (2).
a) **Budget locked until next fiscal year: 4 calls** (TT-001, 003, 006, 010)
- Handling: he reframes funding as coming out of turnover savings, using the retailer case.
- Line: "Most teams fund this out of turnover savings — that retailer saved about $210k in avoided backfills, which is how their finance team signed off."
- Outcome: next step agreed in 3 of 4 (75%). TT-010 (Deal-84DBA6) then stalled at "wait for the committee."
b) **Timing / revisit next quarter: 3 calls** (TT-002, 005, 008)
- Handling: he offers a smaller first step, a 90-day pilot with one department.
- Line: "What if we scope a 90-day pilot with one department so you have internal data before next quarter's planning?"
- Outcome: next step agreed in 3 of 3 (100%).
c) **Status quo (spreadsheet plus gift cards): 3 calls** (TT-004, 007, 009)
- Handling: he pitches automation and analytics features.
- Line: "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."
- Outcome: next step agreed in 1 of 3 (33%). Only TT-009 converted.
**3. How often a concrete next step is agreed**
- **Agreed: 7 of 10 calls (70%)** — TT-001, 002, 003, 005, 006, 008, 009.
- **No next step: 3 of 10 (30%)** — TT-004 (Deal-403845), TT-007 (Deal-EDC141), TT-010 (Deal-84DBA6).
- The rep asked for a next step in 7 of 10 calls. The prospect said yes all 7 times (7 of 7 = 100%). In all three calls with no next step, he never asked.
**4. Competitors raised by a prospect**
- **Awardco** — TT-003, Deal-547B2B, minute 4: "We're also in late talks with Awardco — their rewards catalog looks bigger than yours."
- **Kudos** — TT-007, Deal-EDC141, minute 4.
- Total: 2 competitors across 2 of 10 calls.
- Not counted: Workhuman (TT-005) was raised by the rep, not the prospect.
**Data caveat:** the transcripts repeat the exact same lines word for word across different deals. For example, the prospect reply "Yes, Thursday at 2pm works — send the invite and I'll bring our HRIS manager." appears in all 7 calls with an agreed next step. The rates above are accurate for this file, but this may be templated or sample data rather than real call audio.
**Coaching notes**
1. **Ask for the next step every time, especially after a late stall.** When the prospect stalled on a committee or lack of urgency, he accepted it with no counter-offer ("I'll leave it with you," "Fair enough," "Understood, thanks for the candor"). Those three calls produced no next step. Every time he did ask, the answer was yes (7 of 7). The 90-day pilot offer converted 3 of 3 timing objections, so it's a ready-made step to offer when a prospect says "we'll wait for the committee."
2. **Answer the status-quo objection with results, not features.** His automation-and-analytics reply converted only 1 of 3. The turnover-savings story converted 3 of 4 budget objections. He should use his own proof point here (18% less regretted turnover, about $210k in avoided backfills) to show what the spreadsheet is costing them. The same fix applies to TT-004 and TT-009: neither call opened with that proof story, and it's his strongest opener.
# Q3 2026 Forecast (2026-07-01 to 2026-09-30, extract as of 2026-09-05) The weighted Q3 forecast is **$115,976.75**. That is $44,729 of COMMIT plus 35% of $203,565 in BEST_CASE. The extract has 86 open deals. 54 close inside the quarter and 32 close after it. ## Totals inside the quarter | Category | Count | Total amount | Weight | Weighted | |---|---|---|---|---| | COMMIT | 7 | $44,729.00 | 100% | $44,729.00 | | BEST_CASE | 24 | $203,565.00 | 35% | $71,247.75 | | PIPELINE | 23 | $201,637.40 | 0% | $0.00 | | **Total** | **54** | | | **$115,976.75** | **COMMIT arithmetic:** 11,200 (Deal-547B2B) + 9,000 (Deal-B7EBD1) + 9,000 (Deal-403845) + 6,360 (Deal-A2B47C) + 5,400 (Deal-2465CE) + 2,520 (Deal-A5E80A) + 1,249 (Deal-499BF6) = **44,729** **BEST_CASE arithmetic:** 38,935 + 24,000 + 19,656 + 16,250 + 11,116 + 10,800 + 10,500 + 9,890 + 9,720 + 9,000 + 7,200 + 3,840 + 3,780 + 3,600 + 3,240 + 3,150 + 3,120 + 3,060 + 2,916 + 2,760 + 2,484 + 2,100 + 1,920 + 528 = **203,565** **Weighted forecast:** - 203,565 × 0.35 = 71,247.75 - 44,729 + 71,247.75 = **115,976.75** The PIPELINE total ($201,637.40, 23 deals) is shown for reference only and adds nothing to the forecast. ## Excluded: close date after 2026-09-30 32 deals totalling **$227,575** were excluded. | Category | Count | Amount | |---|---|---| | COMMIT | 1 | $13,770 | | BEST_CASE | 9 | $28,240 | | PIPELINE | 22 | $185,565 | - **COMMIT (1):** Deal-D348E1, $13,770, closes 2026-10-15. - **BEST_CASE (9):** 5,400 (Deal-C61CF7) + 5,160 (Deal-48B656) + 3,600 (Deal-901332) + 3,600 (Deal-47AE31) + 3,600 (Deal-15D24F) + 2,400 (Deal-ED725A) + 1,800 (Deal-8AD4A5) + 1,600 (Deal-5FDCE4) + 1,080 (Deal-F5A622) = 28,240 - **PIPELINE (22):** 185,565. The largest is Deal-E51FB7 at $43,875, closing 2026-10-01. - **Check:** 13,770 + 28,240 + 185,565 = 227,575 No deals close before 2026-07-01. The earliest close date is 2026-08-28. ## Top 5 BEST_CASE deals inside the quarter | # | Deal | Stage | Amount | Close | |---|---|---|---|---| | 1 | Deal-2D7423 | DS3 | $38,935 | 2026-09-30 | | 2 | Deal-25F752 | DS4 | $24,000 | 2026-09-25 | | 3 | Deal-E53952 | DS4 | $19,656 | 2026-09-30 | | 4 | Deal-5EED42 | DS3 | $16,250 | 2026-09-30 | | 5 | Deal-FA32A0 | DS3 | $11,116 | 2026-09-25 | Together these five total $109,957, which is 54.0% of in-quarter BEST_CASE (109,957 ÷ 203,565). ## Data quality 1. Owner is blank on 85 of 86 deals (only Deal-C9C286 has one, Bryce Harmon), and why_buys_chars is 0 on 72 of 86 (50 of the 54 in-quarter deals), so the forecast can't be attributed to anyone or checked against a documented buying reason. 2. Stage and forecast category contradict each other on several deals: Deal-A5E80A is DS1 and Deal-499BF6 is DS2, yet both are COMMIT ($3,769 counted at 100%); Deal-C61CF7 is DS5 but only BEST_CASE; and Deal-6787C2 is DS4 but PIPELINE. 3. Close dates look like placeholders: 17 in-quarter deals sit on 2026-09-30, and four open deals already had close dates before the 2026-09-05 pull (Deal-333EBB, Deal-57FF13, Deal-31AD2C, Deal-7A2454). 4. The extract has no currency field, no company name and no last-modified or stage-date field, and it contains a fractional amount (Deal-42326B at $2,480.40), so currency mix, duplicate deals and stale records can't be checked.
**Activation hypothesis test: 2023 PLG cohort (220 companies)** **Short answer:** The raw numbers support the hypothesis. Companies with both signals retained at 66.0%, compared with 40.0% for companies with neither. But the result mostly reflects product tier, and it doesn't hold once tier is controlled for. The one signal that stays strong is 5+ givers. **The 2x2 table** Retained means current_status = 'active'. The file has 220 rows with 220 unique company_keys and no blank m1 values. | Cell | Rule | Companies | Active | 24-month retention | |---|---|---|---|---| | Both signals | users ≥ 5 and redemptions ≥ 1 | 47 | 31 | 31/47 = 66.0% | | Givers only | users ≥ 5 and redemptions = 0 | 49 | 23 | 23/49 = 46.9% | | Redemption only | users < 5 and redemptions ≥ 1 | 29 | 9 | 9/29 = 31.0% | | Neither | users < 5 and redemptions = 0 | 95 | 38 | 38/95 = 40.0% | | Total | | 220 | 101 | 101/220 = 45.9% | Check: 47 + 49 + 29 + 95 = 220 companies, and 31 + 23 + 9 + 38 = 101 active. - **Both vs. neither:** 66.0 − 40.0 = +26.0 points. - **Givers only vs. neither:** +6.9 points. - **Redemption only vs. neither:** −9.0 points. **Exclusions: none** All 220 companies are in the denominator. Three companies are 'non_renewing' and are counted as not retained, because they are not 'active': - C-0B2078FB and C-0A96134F (neither cell) - C-0BEAF685 (redemption-only cell) If those three were excluded instead, neither would be 38/94 = 40.4% and redemption only would be 9/27 = 33.3%. The conclusions don't change. **Largest single-signal lift: 5+ givers in month 1** - **5+ givers:** 54/96 = 56.2% retained, compared with 47/124 = 37.9% for companies without it. Lift = +18.3 points. - **1+ redemption:** 40/76 = 52.6% retained, compared with 61/144 = 42.4% without it. Lift = +10.2 points. Here 54 = 31 + 23 (both + givers only) and 40 = 31 + 9 (both + redemption only). **What this does not prove** 1. **Tier drives the outcome.** All 97 tier_two companies are cancelled (0/97 retained). Tier_two makes up a different share of each cell: - Both: 13/47 = 27.7% - Redemption only: 10/29 = 34.5% - Givers only: 25/49 = 51.0% - Neither: 49/95 = 51.6% Looking only at tier_three and tier_alpha: - Both: 31/34 = 91.2% - Givers only: 23/24 = 95.8% - Redemption only: 9/19 = 47.4% - Neither: 38/46 = 82.6% Within these tiers, "both" does not beat "givers only." Redemption has a negative lift: (31 + 9)/(34 + 19) = 75.5%, compared with (23 + 38)/(24 + 46) = 87.1%. The givers lift holds up: 54/58 = 93.1% vs. 47/65 = 72.3%, or +20.8 points. 2. **Correlation, not causation.** This is observational data with no controls for company size, industry or integrations. The givers signal may just reflect headcount. 3. **Small cells.** Tier_three and tier_alpha have only 24 and 19 companies in two of the cells, and I ran no significance tests. 4. **The data has quirks:** - Six companies show m1_redemptions ≥ 1 with m1_gives = 0: C-0B8435BE, C-0B2213A9, C-0B057828, C-F0A562FF, C-0E8B0E96 and C-0D66DF9E. - C-F0A562FF has 0 m1_users but 10 redemptions. - m3_users is often lower than m1_users. That suggests the users field may not be defined consistently, so I did not use m3 fields. 5. **Retention only.** Status is the only outcome measured. current_arr_usd was not analyzed, so this says nothing about revenue retained. **What it does show:** In this extract, 5+ month-1 givers is associated with higher 24-month retention, both overall and within tier_three/tier_alpha. The combined "both signals" rule adds nothing beyond the givers signal once tier is accounted for. Month-1 redemption alone is not a positive retention signal here.
ARR Reconciliation: HubSpot (CRM) vs Chargebee (billing), as of 2026-09-05
Assumptions
- Billing ARR = MRR x 12, counting status = active only. Cancelled subscriptions count as $0 ARR.
- Variance = Billing − CRM.
- Owner data is not in the files, so the suggested owners below are functional roles, not named people.
1. Totals
Billing, all 39 subscriptions (MRR x 12) 617,897.76
Less cancelled SUB-000E (408.77 x 12) −4,905.24
Less cancelled SUB-000F (687.77 x 12) −8,253.24
Billing ARR (active) 604,739.28
CRM hubspot_arr, all 39 companies 603,581.76
Variance: 604,739.28 − 603,581.76 = +1,157.52 (billing is higher)
2. Variance decomposition (Billing − CRM)
Status mismatch −13,158.48
C-0C8323BF: 0 − 4,905.24 = −4,905.24
C-0DC4FB8C: 0 − 8,253.24 = −8,253.24
Missing records +11,952.00
C-21629AA4 (billing only): 28,449.24 − 0 = +28,449.24
C-0D5BBE3A (CRM only): 0 − 16,497.24 = −16,497.24
Rounding −36.00
C-0D66DF9E: 23,184.00 − 23,200.00 = −16.00
C-14D70CE0: 18,180.00 − 18,200.00 = −20.00
Other +2,400.00
C-0F7269D7: 26,796.00 − 24,396.00 = +2,400.00
Check: −13,158.48 + 11,952.00 − 36.00 + 2,400.00 = +1,157.52 ✓
3. Mismatched accounts
C-0C8323BF (SUB-000E)
Issue: cancelled in billing, but CRM still shows 4,905.24 ARR (= 408.77 x 12)
Suggested owner: CS/Account Manager to confirm churn; RevOps to zero out CRM ARR
C-0DC4FB8C (SUB-000F)
Issue: cancelled in billing, but CRM still shows 8,253.24 ARR (= 687.77 x 12)
Suggested owner: CS/Account Manager to confirm churn; RevOps to zero out CRM ARR
C-21629AA4 (SUB-0004)
Issue: active subscription with MRR 2,370.77 (ARR 28,449.24), but no CRM company record
Suggested owner: RevOps / CRM admin to create or link the company record
C-0D5BBE3A
Issue: CRM shows 16,497.24 ARR, but there is no billing subscription
Suggested owner: Billing/Finance to check for a missing or unlinked subscription; Sales/AE to confirm the deal is real
C-0D66DF9E (SUB-0005)
Issue: CRM 23,200.00 vs billing 23,184.00, a 16.00 gap. CRM appears rounded to the nearest $100.
Suggested owner: RevOps to sync CRM ARR to the exact billing value
C-14D70CE0 (SUB-0008)
Issue: CRM 18,200.00 vs billing 18,180.00, a 20.00 gap. CRM appears rounded to the nearest $100.
Suggested owner: RevOps to sync CRM ARR to the exact billing value
C-0F7269D7 (SUB-0006)
Issue: billing 26,796.00 vs CRM 24,396.00, a 2,400.00 gap (exactly 200.00 MRR). This could be an upsell or price change that never reached the CRM, but the data doesn't show the cause.
Suggested owner: Account owner/AE and Billing to confirm the contracted price
The other 32 accounts match exactly.
4. Rule violations: term ≠ 12 months without cf_agreement_end_date
SUB-0002 | C-1794A52C | 24 months | cf_agreement_end_date is blank
SUB-0019 | C-22170CA1 | 36 months | cf_agreement_end_date is blank
Both multi-year terms that do have the date (SUB-000C, 24 months, and SUB-001A, 36 months, both 2027-11-30) comply. Suggested owner for the fixes: Billing/Finance ops.
KVMs for 2026-08 vs 2026-07. Each value is a simple unweighted mean across 30 companies. The file has no user or headcount weights, so these are not user-weighted figures. | KVM | 2026-07 | 2026-08 | Abs Δ | Rel Δ | Direction | |---|---|---|---|---|---| | Giving rate | 0.6023 (18.0689/30) | 0.6027 (18.0814/30) | +0.0004 | +0.07% | Flat/up | | Redemptions per user | 1.7300 (51.8995/30) | 1.7302 (51.9049/30) | +0.0002 | +0.01% | Flat | | 1:1 engagement | 0.4469 (13.4066/30) | 0.4472 (13.4153/30) | +0.0003 | +0.06% | Flat/up | | Pulse engagement | 0.6006 (18.0176/30) | 0.5086 (15.2583/30) | −0.0920 | −15.31% | Down | Rel Δ = (Aug − Jul) / Jul. Pulse engagement had the largest relative move, and the data shows which segment drove it. By size_band, pulse engagement (10 companies each): - smb: 0.6588 → 0.6573 (−0.0015, −0.22%) - mid_market: 0.5930 → 0.5942 (+0.0013, +0.21%) - enterprise: 0.5500 → 0.2743 (−0.2757, −50.13%) Enterprise pulse sums fell by 5.4998 − 2.7428 = 2.7570. That accounts for about 100% of the total drop of 18.0176 − 15.2583 = 2.7593. All 10 enterprise companies fell by between −0.2633 and −0.2865, so the decline is uniform across the segment and not caused by one outlier. plan_tier can't explain it: every company is tier_three. The data doesn't show why the drop happened, so it can't tell a real behavior change from a data or instrumentation problem.
**Rewards Report: Redemptions, YTD 2026-01-01 through 2026-08-31** **Last completed month: August 2026 (2026-08).** The file has redemptions from 2026-01-01 to 2026-08-31 and nothing in September, so all 378 rows fall inside the window. There are no duplicate redemption_ids and no blank user_key or country fields. **Headline metrics** | Metric | Value | Arithmetic | |---|---|---| | Redemption count | 378 | Row count | | Spend | $27,846.00 | Sum of amount_usd (by provider: 10,873 + 8,505 + 5,238 + 3,230) | | Unique redeemers | 235 | Distinct user_key values | | Redemptions per redeemer | 1.61 | 378 / 235 = 1.6085 | **Redemptions by month** | Month | Redemptions | |---|---| | Jan | 45 | | Feb | 36 | | Mar | 50 | | Apr | 52 | | May | 43 | | Jun | 46 | | Jul | 58 | | Aug | 48 | | **Total** | **378** | **Provider mix (share of spend)** | Provider | Redemptions | Spend | Share of spend | |---|---|---|---| | custom | 37 | $10,873.00 | 10,873 / 27,846 = 39.05% | | Tremendous | 192 | $8,505.00 | 8,505 / 27,846 = 30.54% | | Snappy | 59 | $5,238.00 | 5,238 / 27,846 = 18.81% | | TangoCard | 90 | $3,230.00 | 3,230 / 27,846 = 11.60% | | **Total** | **378** | **$27,846.00** | **100.00%** | The shares add up: 39.05 + 30.54 + 18.81 + 11.60 = 100.00. "custom" is the provider value exactly as it appears in the data. The file doesn't say which vendor or vendors it stands for. It is the largest share of spend from only 37 redemptions, averaging 10,873 / 37 = $293.86 each. **Top 5 countries by redemptions** | Rank | Country | Redemptions | Share of count | Spend | |---|---|---|---|---| | 1 | US | 244 | 244 / 378 = 64.6% | $18,547.00 | | 2 | CA | 24 | 6.3% | $2,286.00 | | 3 | AU | 21 | 5.6% | $1,606.00 | | 4 (tie) | GB | 17 | 4.5% | $944.00 | | 4 (tie) | NL | 17 | 4.5% | $1,122.00 | GB and NL are tied, and both fit in the top 5. Together the top 5 account for 244 + 24 + 21 + 17 + 17 = 323 of 378 redemptions (85.4%). The next country is SG with 12. **Data gaps** - There's no redemption status field, such as fulfilled, failed or refunded, so every row counts as a completed redemption. - There's no prior-year data, so year-over-year comparisons can't be made. - All amounts come from the amount_usd column as given. The file doesn't show whether any currency conversion was applied.
# Churn-Save Eligibility (snapshot 2026-09-05) **Rules applied:** An account qualifies only if it passes all three: - R1: health score below 60 - R2: churn-save eligible amount above $0 - R3: renewal within 120 days of the snapshot, so on or before 2027-01-03 15 accounts are at risk (health below 60). 8 of them qualify. ## Qualifying accounts | Account | Health | Renewal (days out) | Seats used | Usage | Champion | Eligible amount | |---|---|---|---|---|---|---| | C-0B0F1BAB | 38 | 2026-09-23 (18) | 238/363 = 65.6% | flat | false | $5,494 | | C-0E9C27D1 | 39 | 2026-09-24 (19) | 134/157 = 85.4% | flat | true | $41,235 | | C-0F6C0F34 | 51 | 2026-10-03 (28) | 308/395 = 78.0% | growing | false | $49,707 | | C-0B360C78 | 57 | 2026-10-28 (53) | 246/327 = 75.2% | growing | true | $35,748 | | C-0D3278C7 | 54 | 2026-11-12 (68) | 126/380 = 33.2% | declining | true | $17,602 | | C-0B827671 | 56 | 2026-11-14 (70) | 113/202 = 55.9% | declining | true | $25,365 | | C-0CEF69FD | 53 | 2026-11-21 (77) | 97/136 = 71.3% | growing | false | $32,621 | | C-0CA21961 | 58 | 2026-12-28 (114) | 84/325 = 25.8% | flat | true | $16,829 | **Total eligible amount at stake:** 5,494 + 41,235 + 49,707 + 35,748 + 17,602 + 25,365 + 32,621 + 16,829 = **$224,601** **Total ARR on these accounts:** 15,391 + 75,093 + 86,741 + 60,427 + 33,815 + 72,088 + 79,324 + 31,501 = **$454,380** ## Play per account The data doesn't document a rule for matching plays to accounts, so I used this logic: - **Usage revival:** usage declining or seat use low, with a champion still active. - **Executive touch:** champion inactive. - **Commercial concession:** usage and champion both look healthy but health is still low, so price or value is the remaining lever. **Usage revival ($59,796 total)** - **C-0D3278C7 ($17,602):** Usage declining and only 33.2% of seats used. The champion is active, so they can drive re-adoption. - **C-0B827671 ($25,365):** Usage declining and 55.9% of seats used. The champion is active. - **C-0CA21961 ($16,829):** Only 25.8% of seats used (the lowest of the qualifiers), usage flat, champion active. If revival fails, a seat right-size is a fallback. **Executive touch ($87,822 total)** - **C-0F6C0F34 ($49,707):** Champion inactive even though usage is growing and 78.0% of seats are used. The relationship is the gap, not adoption. This is the largest amount at stake, with renewal in 28 days. - **C-0CEF69FD ($32,621):** Champion inactive, usage growing, 71.3% of seats used. - **C-0B0F1BAB ($5,494):** Champion inactive and the lowest health score (38). Renewal was 18 days after the snapshot, so the executive touch is urgent. **Commercial concession ($76,983 total)** - **C-0E9C27D1 ($41,235):** 85.4% of seats used and the champion is active, but health is 39 and renewal was 19 days after the snapshot. Nothing in the data points to an adoption or relationship problem. - **C-0B360C78 ($35,748):** Usage growing, 75.2% of seats used, champion active, but health is 57. There's no adoption or champion gap to fix. For both, the data doesn't show what is driving the low health score. Confirm the cause before making an offer. **Check:** 59,796 + 87,822 + 76,983 = $224,601, which matches the total. **Caveat:** C-0B0F1BAB (renewal 2026-09-23) and C-0E9C27D1 (renewal 2026-09-24) qualify against the 2026-09-05 snapshot. Their current renewal status isn't in the data, so verify both before acting. ## At risk but not qualifying | Account | Health | Eligible amount | Renewal (days out) | Fails | Signals | |---|---|---|---|---|---| | C-0BC71BDD | 55 | $0 | 2026-10-27 (52) | R2 | 59/197 = 29.9% seats used, flat, no champion | | C-0BE96399 | 54 | $0 | 2026-10-29 (54) | R2 | 43/154 = 27.9% seats used, declining | | C-10A56B0F | 54 | $0 | 2026-12-12 (98) | R2 | 85/176 = 48.3% seats used, declining, no champion | | C-0F876796 | 47 | $19,958 | 2027-02-06 (154) | R3 | 22/95 = 23.2% seats used, declining, no champion | | C-0BA71F12 | 52 | $6,824 | 2027-04-11 (218) | R3 | 23/98 = 23.5% seats used, declining | | C-0F6694C3 | 43 | $0 | 2027-03-21 (197) | R2 and R3 | 39/96 = 40.6% seats used, declining | | C-0FCCD2DF | 43 | $0 | 2027-04-23 (230) | R2 and R3 | 27/63 = 42.9% seats used, flat, no champion; $65,957 ARR | - **C-0BC71BDD, C-0BE96399 and C-10A56B0F** renew within the window but have no eligible amount. They carry $54,515, $52,319 and $25,717 ARR, which is $132,551 in near-term renewals with no save-offer budget. - **C-0F876796** fails only on timing. It will enter the 120-day window about 34 days after the snapshot (154 − 120 = 34). The other 15 accounts have health of 60 or above, so they aren't at risk under R1.
# Expansion Kit: C-0DDFC9A7 ## 1. Seat coverage (licensed ÷ headcount) 150 ÷ 400 = **37.5%**. The other 250 employees (62.5%) have no license. ## 2. Usage health - Monthly active users rose every month, from 88 in March to 126 in August 2026. That's a gain of 38 users (38 ÷ 88 = **+43.2%**). The monthly gains were +7, +7, +8, +8, +8. - August use is 126 of 150 licensed seats (126 ÷ 150 = **84.0%**). 24 seats are left. If the recent pace of about 8 users a month holds, all seats would be in use in about 3 months (24 ÷ 8 = 3). That's a projection, not a fact in the data. ## 3. Headroom - Seats: 400 − 150 = **250 seats** - Current per-seat rate: $9,000.00 ÷ 150 = **$60.00 per seat**. This assumes current_arr is annual. - ARR headroom: 250 × $60.00 = **$15,000.00** - ARR if every employee had a seat: 400 × $60.00 = $24,000.00, which is 2.67× today's $9,000.00. ## 4. Who replied and whether they can buy Maria S., People Operations Coordinator, replied on 2026-09-02. **She can't buy.** She wrote: "I'm not the right person for purchasing decisions." She is a supporter who offered to make an introduction. ## 5. The right buyer **Dana R., VP People.** Maria named her as the owner of "budget and seat expansion" and said Dana has "been asking about our usage numbers lately." - Dana was last engaged on 2026-05-18, about 3.5 months before Maria's reply, so the contact is stale. - Sam K. (Office Manager) was last engaged on 2025-11-03. Nothing shows buying authority, so don't target Sam. ## 6. Reply email (84 words) Subject: RE: Growing your team's recognition program Hi Maria, Thanks so much. It's great to hear the team is enjoying Bonusly. Since Dana has been asking about usage numbers, here's one worth sharing: your monthly active users grew from 88 in March to 126 in August. I'd welcome an introduction to Dana. I can put together a short usage summary ahead of time so she has the numbers in hand and can decide whether a conversation makes sense. No rush on timing. Whatever works best for you both. Thanks again, Cole ## Data not provided - Renewal or contract dates - Pricing tiers or volume discounts. Headroom assumes the flat $60 per seat continues. - Whether current_arr is annual (assumed) - Contact details for Dana R. - September 2026 usage
# Mid-Onboarding Call Prep: C-0D284E42 **Snapshot:** Signed up 2026-08-11. Usage data runs through 2026-09-04, which is day 24. ## Milestone status | Milestone | Status | Evidence | |---|---|---| | Slack integration | Complete | integration_slack = 2026-08-12 (day 1) | | HRIS integration | **Not complete** | integration_hris is blank | | Allowance set | Complete | allowance_set = 2026-08-13 (day 2) | | Admins added | Complete | admins_added = 2 (no date given) | | First recognition | Complete | first_recognition_at = 2026-08-15 14:22 (day 4) | | First redemption | **Not complete** | first_redemption_at is blank. That's 20 days since the first recognition (08-15 to 09-04). | ## Early engagement signals (active_givers) - **Overall:** active givers went from 3 on 08-11 to 15 on 09-04. That's +12, or 5.0x (15 ÷ 3). - **Weekly averages:** | Week | Daily values | Average | |---|---|---| | Wk1 (08-11 to 08-17) | 3+3+4+4+5+4+7 = 30 | 30 ÷ 7 = 4.29 | | Wk2 (08-18 to 08-24) | 5+7+6+9+8+9+9 = 53 | 53 ÷ 7 = 7.57 | | Wk3 (08-25 to 08-31) | 9+11+10+10+11+13+11 = 75 | 75 ÷ 7 = 10.71 | | Wk4 (09-01 to 09-04, partial) | 13+13+15+15 = 56 | 56 ÷ 4 = 14.00 | - **Growth rate:** - Week over week: +76%, then +41%, then +31%. - The percentage is slowing, but the absolute gain is steady: +3.29, +3.14 and +3.29 givers per week. - **Peak:** 15 active givers on 09-03 and 09-04, the highest so far. - **Dips:** small one-day dips (for example 08-17 to 08-18 went 7 to 5, and 08-30 to 08-31 went 13 to 11). None reversed the trend. - **Data conflict to check:** active_givers shows 3 on 08-11, 08-12, 08-13 and 08-14. But first_recognition_at is 08-15. Either the field definitions differ or one of the sources is wrong. ## Missing data (can't assess) - Headcount or seats, so I can't calculate what share of the company is giving. - Recognition volume and number of recipients. - Redemption activity beyond the blank first-redemption field. - Admin names and when they were added. - HRIS connection status or blockers. ## Three things to cover on the call 1. **HRIS integration is not connected.** - Find out whether it has been attempted, what's blocking it, who owns it on the customer side, and agree a target date. 2. **No first redemption yet, 20 days after the first recognition.** - Ask whether recipients know how to redeem and whether anything is stopping them. - Aim to get one redemption done soon. 3. **Keep the giver growth going and get the numbers to measure it.** - Active givers are adding about 3 per week. - Get total headcount so participation can be measured as a share of the company. Right now, 15 givers can't be judged. - Clear up why active givers appear before the first recognition date (08-11 to 08-14 vs. 08-15).
# 90-Day Renewal Risk Brief **As-of date:** The files don't include one. Usage runs through 2026-08, so I used 2026-09-01 as the as-of date, which makes the window 2026-09-01 to 2026-11-30. All 20 accounts renew inside it using the trusted dates. Today is 2026-09-24, so three renewal dates have already passed (see below). The data doesn't say whether those renewals closed. **Risk rules I used:** - **High:** active users fell every month from Jun to Aug and dropped at least 10% overall, or seat utilization is under 40%. - **Medium:** the trend is flat (within ±5%) and utilization is 40–65%. - **Low:** the trend is flat or growing and utilization is 65% or higher. Utilization is seats_used ÷ seats. The trend compares active users in Jun 2026 with Aug 2026. ## 1. Date disagreements (5 of 20, all multi-year) For all five I used the Chargebee date. Chargebee holds the contract term (is_multi_year=true), and ChurnZero is known to be wrong on multi-year contracts. The other 15 accounts are 12-month terms, and both systems show the same date. | Account | ChurnZero date | Chargebee date (used) | Term | |---|---|---|---| | C-0B7D2C30 | 2026-09-10 | 2026-09-15 | 36 months | | C-0BCDB8C2 | 2027-09-18 | 2026-09-18 | 36 months | | C-0D2AB865 | 2026-09-10 | 2026-09-22 | 24 months | | C-0BBE3E60 | 2027-09-26 | 2026-09-26 | 24 months | | C-0F5D2323 | 2026-09-10 | 2026-09-29 | 24 months | Using ChurnZero's dates would push C-0BCDB8C2 and C-0BBE3E60 out to 2027 and hide them from this window. That's $54,427 + $30,993 = $85,420 of High-risk ARR. ## 2. Renewals | # | Account | CSM | ARR | Date used | Seat utilization | Trend (Jun→Aug) | Risk | |---|---|---|---|---|---|---|---| | 1 | C-0B7D2C30 | Dana Mercer | $65,901 | 09-15 (CB) | 274/476 = 57.6% | 97→94→84 = −13.4% | HIGH | | 2 | C-0BCDB8C2 | Cole Ingram | $54,427 | 09-18 (CB) | 232/424 = 54.7% | 127→118→110 = −13.4% | HIGH | | 3 | C-0D2AB865 | Elena Sinclair | $38,022 | 09-22 (CB) | 250/407 = 61.4% | 125→117→109 = −12.8% | HIGH | | 4 | C-0BBE3E60 | Dana Mercer | $30,993 | 09-26 (CB) | 74/114 = 64.9% | 39→35→33 = −15.4% | HIGH | | 5 | C-0F5D2323 | Cole Ingram | $90,647 | 09-29 (CB) | 111/390 = 28.5% | 20→21→18 = −10.0% | HIGH | | 6 | C-0EC6999D | Elena Sinclair | $79,419 | 10-03 | 31/112 = 27.7% | 17→16→15 = −11.8% | HIGH | | 7 | C-0B20DB64 | Dana Mercer | $21,770 | 10-07 | 214/378 = 56.6% | 294→298→294 = 0.0% | MEDIUM | | 8 | C-0BBC4E7A | Cole Ingram | $56,374 | 10-10 | 228/337 = 67.7% | 142→141→139 = −2.1% | LOW | | 9 | C-0FD551AB | Elena Sinclair | $48,815 | 10-14 | 210/376 = 55.9% | 123→122→126 = +2.4% | MEDIUM | | 10 | C-0F9F8F13 | Dana Mercer | $46,230 | 10-18 | 199/352 = 56.5% | 185→185→182 = −1.6% | MEDIUM | | 11 | C-0BC34584 | Cole Ingram | $16,740 | 10-22 | 327/494 = 66.2% | 104→104→106 = +1.9% | LOW | | 12 | C-0B7A7546 | Elena Sinclair | $35,062 | 10-25 | 182/205 = 88.8% | 64→65→63 = −1.6% | LOW | | 13 | C-0B369871 | Dana Mercer | $85,128 | 10-29 | 317/422 = 75.1% | 326→330→333 = +2.1% | LOW | | 14 | C-0B144C78 | Cole Ingram | $30,899 | 11-02 | 169/224 = 75.4% | 101→101→106 = +5.0% | LOW | | 15 | C-0FC4DBB8 | Elena Sinclair | $94,732 | 11-05 | 356/464 = 76.7% | 189→191→193 = +2.1% | LOW | | 16 | C-0D5BBE3A | Dana Mercer | $39,740 | 11-09 | 85/102 = 83.3% | 88→90→91 = +3.4% | LOW | | 17 | C-0FB9D5AF | Cole Ingram | $63,158 | 11-13 | 144/199 = 72.4% | 173→173→176 = +1.7% | LOW | | 18 | C-0B344485 | Elena Sinclair | $64,384 | 11-16 | 224/287 = 78.0% | 238→240→244 = +2.5% | LOW | | 19 | C-0CB2C1B4 | Dana Mercer | $40,628 | 11-20 | 386/473 = 81.6% | 47→48→49 = +4.3% | LOW | | 20 | C-22170CA1 | Cole Ingram | $45,646 | 11-24 | 251/294 = 85.4% | 143→148→146 = +2.1% | LOW | All dates are 2026. "(CB)" marks a Chargebee date that overrides ChurnZero. For rows 6–20 the two systems agree. **Evidence for each rating:** 1. **C-0B7D2C30:** Active users have fallen for 12 straight months, from 155 to 84 (−45.8%), with 36 months of ARR renewing. 2. **C-0BCDB8C2:** Steady 12-month decline from 200 to 110 (−45.0%), and ChurnZero shows the renewal a year late. 3. **C-0D2AB865:** Steady 12-month decline from 199 to 109 (−45.2%). 4. **C-0BBE3E60:** Steady 12-month decline from 63 to 33 (−47.6%), and ChurnZero shows the renewal a year late. 5. **C-0F5D2323:** Only 18 active users on 390 seats (4.6%), and it's the second-largest ARR in the window. Usage has sat at 17–21 all year, so the 3-month dip is noise and utilization is the real risk. 6. **C-0EC6999D:** Only 15 active users on 112 seats (13.4%), flat at 14–17 for 12 months, with $79,419 renewing. 7. **C-0B20DB64:** Usage is stable, but 43% of seats are unused, which creates downsell exposure. 8. **C-0BBC4E7A:** Usage is flat at 139–142 all year, and utilization is above 65%. 9. **C-0FD551AB:** Usage is stable, but 44% of seats are unused, which creates downsell exposure. 10. **C-0F9F8F13:** Usage is stable, but 43% of seats are unused, which creates downsell exposure. 11. **C-0BC34584:** Usage is flat to slightly up, and utilization is 66%. 12. **C-0B7A7546:** Highest utilization in the book at 88.8%, with a 12-month trend of 58 to 63. 13. **C-0B369871:** Active users grew every month for 12 months, from 289 to 333 (+15.2%). 14. **C-0B144C78:** Active users grew from 90 to 106 over 12 months (+17.8%). 15. **C-0FC4DBB8:** Largest ARR in the window, with active users growing from 168 to 193 (+14.9%) over 12 months. 16. **C-0D5BBE3A:** Active users grew from 76 to 91 over 12 months, and 83% of seats are used. 17. **C-0FB9D5AF:** Active users grew from 154 to 176 over 12 months (+14.3%). 18. **C-0B344485:** Active users grew from 211 to 244 over 12 months (+15.6%). 19. **C-0CB2C1B4:** 81.6% of seats are used and usage is rising, although active users (49) are far below seats_used (386). 20. **C-22170CA1:** Active users grew from 130 to 146 over 12 months, and 85.4% of seats are used. ## 3. Data gaps and flags - **Renewal dates already past:** As of today (2026-09-24), three accounts have passed their Chargebee date: C-0B7D2C30 (09-15), C-0BCDB8C2 (09-18) and C-0D2AB865 (09-22). All three are High risk, totaling $65,901 + $54,427 + $38,022 = $158,350. The data doesn't show whether they renewed. - **Active users higher than seats_used:** Five accounts report more active users in August than ChurnZero's seats_used, so one of the two sources is stale or defined differently: - C-0B20DB64: 294 vs 214 - C-0B369871: 333 vs 317 - C-0D5BBE3A: 91 vs 85 - C-0FB9D5AF: 176 vs 144 - C-0B344485: 244 vs 224 - **Missing data:** - Chargebee doesn't carry ARR, so ARR comes only from ChurnZero and can't be cross-checked. - There's no September usage. - There's no renewal status, health score or CSM notes. ## 4. Totals | Risk | ARR | Share of total | Accounts | |---|---|---|---| | **Total renewing** | **$1,048,715** | 100% | 20 | | **ARR at risk (High)** | **$359,409** | 34.3% | 6 | | Medium (watch) | $116,815 | 11.1% | 3 | | Low | $572,491 | 54.6% | 11 | **Arithmetic:** - **High:** 65,901 + 54,427 + 38,022 + 30,993 + 90,647 + 79,419 = 359,409 - **Medium:** 21,770 + 48,815 + 46,230 = 116,815 - **Low:** 56,374 + 16,740 + 35,062 + 85,128 + 30,899 + 94,732 + 39,740 + 63,158 + 64,384 + 40,628 + 45,646 = 572,491 - **Check:** 359,409 + 116,815 + 572,491 = 1,048,715, which matches the sum of all 20 ChurnZero ARR values. - **Shares:** 359,409 ÷ 1,048,715 = 34.3%. High plus Medium is $476,224, or 45.4%.
# Q2–Q3 2026 Support Ticket Themes (80 tickets, 2026-06-01 to 2026-08-29) I grouped tickets by reading the body text and ignored the tags. The tags don't match the content: for example, IC-460014 is a missing-points ticket tagged "billing", and IC-460071 is an invoice error tagged "feedback". Every ticket fit exactly one theme, and the five theme counts add up to 80 (20 + 18 + 16 + 14 + 12). No account appears in more than one theme, so there are 24 distinct accounts with $284,800 in total ARR. ARR is counted once per distinct account. ## Ranked by ARR exposure **1. HRIS provisioning not creating new-hire accounts** (a multi-account pattern, but concentrated) - **Count:** 12 tickets - **Share:** 12/80 = 15.0% - **Accounts:** 3. C-0B2213A9 has 7 tickets, C-0DDFC9A7 has 3 and C-0F6C0F34 has 2. - **ARR:** 36,000 + 48,000 + 30,000 = **$114,000** - **Tickets:** IC-460060, IC-460059 - **Recommendation:** Treat this as a P1 engineering issue. The sync skips hires silently and the log shows no errors (IC-460062, IC-460060, IC-460064), so add failure alerting and reconcile each of the 3 accounts by hand. **2. Redemption / gift card checkout failures** (broad pattern) - **Count:** 18 tickets - **Share:** 18/80 = 22.5% - **Accounts:** 7 - **ARR:** 8,900 (C-0CEF69FD) + 10,700 (C-0B827671) + 9,600 (C-0FCCD2DF) + 8,700 (C-0F876796) + 11,000 (C-14264ABD) + 9,600 (C-0D9CA315) + 10,300 (C-0B0F1BAB) = **$68,800** - **Tickets:** IC-460025, IC-460038 - **Sub-pattern:** In 5 of the 18 tickets, the order failed but points were still deducted (IC-460023, 024, 026, 027, 037). These affect 4 accounts. - **Recommendation:** Make checkout transactional, so points roll back automatically when an order fails. Refund the points already deducted. **3. Invoice seat-count and renewal-tier billing errors** (single-account noise, but high value) - **Count:** 16 tickets - **Share:** 16/80 = 20.0% - **Accounts:** 1 (C-0E9C27D1) - **ARR:** **$52,000** - **Tickets:** IC-460069, IC-460078 - **Recommendation:** Handle this as a single-account escalation, not a product fix. Assign one owner from Finance and CS to reissue corrected invoices. The customer bills for 150 seats but was charged for 200, and the renewal was charged at the wrong tier. **4. Recognition points not posting to balances** (broadest pattern) - **Count:** 20 tickets - **Share:** 20/80 = 25.0% - **Accounts:** 9 - **ARR:** 3,500 (C-0D3278C7) + 4,500 (C-0BF20542) + 4,500 (C-0D0B047C) + 2,700 (C-0BE96399) + 3,400 (C-0D284E42) + 4,200 (C-0D6CC8E3) + 2,900 (C-21FEBCBB) + 2,500 (C-0DD0626C) + 2,900 (C-0B2895EF) = **$31,100** - **Tickets:** IC-460004, IC-460016 - **Recommendation:** Investigate the points ledger job, especially "after the weekend" batch processing (IC-460016, IC-460001). This theme has the most tickets and the most accounts but low ARR per account. **5. Slack integration: sync, auth and slash-command failures** (multi-account, partly concentrated) - **Count:** 14 tickets - **Share:** 14/80 = 17.5% - **Accounts:** 4. C-0BA71F12 has 6 of the 14 tickets. - **ARR:** 4,400 (C-0B843542) + 5,400 (C-10A56B0F) + 3,900 (C-0BA71F12) + 5,200 (C-8C2E8F00) = **$18,900** - **Tickets:** IC-460047, IC-460051 - **Recommendation:** Fix the OAuth token persistence and the sync toggle that resets itself. The slash-command errors appear in 4 of 14 tickets, from 3 accounts, and should be triaged as a separate bug. ## Broad patterns vs single-account noise - **Broad (4+ accounts):** points not posting (9 accounts), redemption failures (7), Slack (4). Together: $118,800 ARR across 20 accounts. - **Concentrated:** HRIS covers only 3 accounts, but they are the largest ARR in the dataset, and 58% of its tickets (7/12) come from C-0B2213A9. - **Single-account noise:** billing is entirely C-0E9C27D1. It's 20% of ticket volume but only one customer. ## Missing data The file has no renewal dates, health scores, ticket resolution status or CSAT. Because of that, ARR exposure here means total ARR of the affected accounts, not ARR that is actually at risk.
Ranking: top 3 case-study customers similar to prospect C-82AF3719 Prospect profile: Technology, Mid-Market, employee_recognition, NA-West How I scored it - Only customers with has_case_study = true were considered. That leaves 8 of the 25 customers. - Each of the 4 fields (industry, size_band, use_case, region) scores 1 point on an exact match, for a maximum of 4. - The data gives no field weights. Three customers tie at 3/4, so I broke the tie with an assumed rule: industry match first, then use_case. Social proof usually lands best from the same industry. Scores for all 8 case-study customers - C-64171065: 1+1+1+0 = 3 - C-A13C193D: 1+1+0+1 = 3 - C-11C31562: 0+1+1+1 = 3 - C-CD4829A7: 1+1+0+0 = 2 - C-9D69D147: 0+1+0+1 = 2 - C-FEFCC020: 0+0+0+0 = 0 - C-11209339: 0+0+0+0 = 0 - C-0CE315B2: 0+0+0+0 = 0 Ranked results 1. C-64171065, score 3/4 - Matches: industry (Technology), size_band (Mid-Market), use_case (employee_recognition) - Miss: region (NA-East vs NA-West) - Why first: it's the only customer that matches both industry and use case. 2. C-A13C193D, score 3/4 - Matches: industry (Technology), size_band (Mid-Market), region (NA-West) - Miss: use_case (retention vs employee_recognition) 3. C-11C31562, score 3/4 - Matches: size_band (Mid-Market), use_case (employee_recognition), region (NA-West) - Miss: industry (Manufacturing vs Technology) Notes - No customer matches all 4 fields. - If region or use case should count for more than industry, the order of the top 3 changes. The same three customers stay in, because no other case-study customer scores above 2. - The data has no billing or contact fields, so none are included.
Channel performance for the trailing 6 months (2026-03 to 2026-08) Scope: the spend file covers 2026-03 to 2026-08, and every SQM date in the contacts file falls in that range. I checked all 122 contacts and none are duplicated. "Pipeline" means the pipeline_amount on contacts that reached SQO. No contact without an SQO has pipeline above zero. PAID CHANNELS Spend is monthly spend × 6 months: - paid_search: $6,000 × 6 = $36,000 - linkedin_ads: $4,000 × 6 = $24,000 - paid_social: $3,000 × 6 = $18,000 - webinars: $1,500 × 6 = $9,000 - Total paid spend: $87,000 paid_search - Spend: $36,000 - SQMs: 40 - SQOs: 18 - Cost per SQM: 36,000 / 40 = $900 - Cost per SQO: 36,000 / 18 = $2,000 - SQM-to-SQO rate: 18 / 40 = 45.0% - Pipeline: 18 × $40,000 = $720,000 - Pipeline per $: 720,000 / 36,000 = $20.00 linkedin_ads - Spend: $24,000 - SQMs: 25 - SQOs: 8 - Cost per SQM: 24,000 / 25 = $960 - Cost per SQO: 24,000 / 8 = $3,000 - SQM-to-SQO rate: 8 / 25 = 32.0% - Pipeline: 8 × $12,000 = $96,000 - Pipeline per $: 96,000 / 24,000 = $4.00 paid_social - Spend: $18,000 - SQMs: 0 - SQOs: 0 - Cost per SQM: UNDEFINED (18,000 / 0) - Cost per SQO: UNDEFINED (18,000 / 0) - SQM-to-SQO rate: UNDEFINED (0 / 0) - Pipeline: $0 - Pipeline per $: 0 / 18,000 = $0.00 webinars - Spend: $9,000 - SQMs: 12 - SQOs: 5 - Cost per SQM: 9,000 / 12 = $750 - Cost per SQO: 9,000 / 5 = $1,800 - SQM-to-SQO rate: 5 / 12 = 41.7% - Pipeline: 5 × $12,000 = $60,000 - Pipeline per $: 60,000 / 9,000 = $6.67 Paid totals: 77 SQMs, 31 SQOs, $876,000 pipeline. Pipeline per $ = 876,000 / 87,000 = $10.07. ORGANIC CHANNELS (no spend data) organic_search - SQMs: 30 - SQOs: 10 - SQO rate: 10 / 30 = 33.3% - Pipeline: 10 × $9,000 = $90,000 referral - SQMs: 15 - SQOs: 6 - SQO rate: 6 / 15 = 40.0% - Pipeline: 6 × $8,000 = $48,000 DATA QUALITY FLAGS SQO date is before the SQM date on 2 rows, both linkedin_ads: - CT-000044: SQM 2026-07-23, SQO 2026-07-18 (5 days earlier), $12,000 - CT-000041: SQM 2026-06-14, SQO 2026-06-09 (5 days earlier), $12,000 If you exclude those two rows, linkedin_ads becomes: - 6 SQOs, so 6 / 25 = 24.0% SQO rate - Cost per SQO: 24,000 / 6 = $4,000 - Pipeline: $72,000, so $3.00 per $ Other things to note: - CT-000007 (paid_search) has its SQM and SQO on the same day, 2026-03-28. That's not an error, but it's worth a look. - Every SQO in a channel has exactly the same pipeline amount: $40,000 for paid_search, $12,000 for linkedin_ads and webinars, $9,000 for organic_search, and $8,000 for referral. That looks like placeholder or modeled values, not real deal amounts. So the pipeline figures above measure deal-size assumptions as much as channel performance. - There is no closed-won or revenue data, so none of this says anything about bookings or ROI. - paid_social has $18,000 of spend and not a single contact attributed to it. That could mean the channel produces nothing, or that tracking or attribution for it is broken. The data can't tell these apart. REALLOCATION RECOMMENDATION 1. Pause paid_social ($3,000/month) once you've confirmed its tracking works. It has produced $0 pipeline on $18,000. 2. Move that $3,000/month to paid_search. It leads on every measure except cost per SQM: $2,000 per SQO, 45% SQO rate and $20.00 pipeline per $. 3. Keep webinars at $1,500/month. Its cost per SQO ($1,800) and SQO rate (41.7%) are strong, but the sample is small. 4. Keep linkedin_ads at $24,000 for now, but don't add money. It's the most expensive per SQO ($3,000, or $4,000 after the date fixes) and returns $3 to $4 of pipeline per $. Fix the two date errors and review it next quarter. Confidence given sample sizes: - paid_search (40 SQMs / 18 SQOs): moderate. It's the largest sample. However, 100% of its pipeline advantage comes from the flat $40,000 deal value, and there's no data on whether returns shrink at 1.5x spend. - linkedin_ads (25 / 8): low to moderate. Two of its 8 SQOs (25%) have date errors. - webinars (12 / 5): low. One SQO more or less moves the SQO rate by about 8 points. - paid_social (0 SQMs on $18,000): the zero result is certain. Whether it reflects real performance or a tracking gap is unknown. - organic_search and referral: no spend data, so no efficiency comparison with paid is possible. Overall confidence is moderate on the direction (cut paid_social, favor paid_search) and low on the exact dollar amounts.
# Battlecard: Rivally (updated 2026-09-24) ## One-line positioning Rivally sells points-based recognition built around an engaging recognition feed [S02, S16], and is now pushing into EU enterprise [S11, S12, S15]. - Old card said "for mid-market." The only direct support is one mid-market reviewer [S04]. Enterprise reviewers also appear [S10, S12], so the mid-market-only framing is unverified. ## Pricing - **Current list price:** Recognition Starter costs $7 per user/month, annual billing required. Source: pricing page, 2026-08-12 [S17]. This is the newest source, so it wins. - **Conflict with older sources:** - Pricing page, 2026-01-20: "Rivally Recognition" at $5 per user/month, annual [S03]. - Pricing page, 2026-04-01: Recognition Starter still at $5 [S08]. - Both are superseded by S17. The list price rose $2, from $5 to $7, which is +40% ($2 / $5). - **Quotes seen in deals (call notes, not list price):** - 2026-06-02: $6.50/user/mo to a 500-seat prospect, annual term [S13]. This is between the old $5 list and the current $7 list. - 2026-08-14: $7 list with 15% off for a 3-year term [S18]. That works out to $7 × 0.85 = $5.95/user/mo. - **Rivally Pulse:** sold as a separate add-on, not bundled [S23]. Its price is not in the data. - **Our pricing:** not in the data, so no price comparison is possible. ## Where they win - The recognition feed is engaging [S02, S16]. - Setup is fast (under a week) and the Slack integration works out of the box [S04]. - EU data residency is generally available [S15], and they pitch it in deals [S05]. - EU presence: Dublin office [S15], an ex-Workday VP running EMEA [S11], and multi-language support that EU reviewers praise [S12]. - Support responds quickly, in under 4 hours [S22]. - Microsoft Teams app v2 is in public preview [S19]. ## Where we win These are mostly Rivally weaknesses. The data does not document Bonusly's own capabilities in these areas, apart from S25. - **Analytics and reporting are weak:** - Limited analytics [S02]. - Basic dashboards [S07]. - Exports are CSV-only, which made one customer's migration off Rivally hard [S20]. - An 800-seat prospect chose Bonusly over Rivally citing analytics depth [S25]. - **Admin tooling lags peers:** - General admin gaps [S16]. - No bulk recognition editing [S24]. - No SCIM provisioning, so user management is manual [S10]. - **Rewards catalog:** the EMEA catalog is thinner than the US one [S14]. ## Objections and responses - **"Rivally is cheaper."** - Their list price is now $7, not $5 [S17]. - Even the 3-year discount only brings it to $5.95 [S18]. - Pulse costs extra on top [S23]. - **"Rivally has EU data residency."** - Confirmed as generally available [S15]. - Response: move the discussion to their thinner EMEA rewards catalog [S14]. - Bonusly's data residency position is not in the data. Get it from product before claiming parity. - **"Setup is fast and it works in Slack."** - Concede both points [S04]. - Response: ask about admin at scale: no SCIM [S10], no bulk editing [S24], admin lags peers [S16]. - **"Their feed drives engagement."** - Response: point to the reporting gaps [S02, S07], CSV-only exports [S20], and the 800-seat win on analytics depth [S25]. - **"They have engagement surveys too."** - Pulse is an add-on priced separately, not bundled [S23]. It only launched in 2026-03 and exited beta in 2026-09 [S06, S23]. ## Recent changes - 2025-11-04: Series C, $40M, led by Northgate Ventures [S01]. - 2026-03-05: Rivally Pulse launched as a survey add-on [S06]. - 2026-05-09: Hired an ex-Workday VP to lead EMEA [S11]. - 2026-07-01: Dublin office opened; EU data residency became generally available [S15]. - 2026-08-12: List price went from $5 to $7 [S17]. - 2026-08-20: Teams app v2 entered public preview [S19]. - 2026-09-01: Pulse exited beta; sold as an add-on [S23]. ## Our 12-month win/loss record against Rivally - **Window:** 2025-09 to 2026-08. That is all 20 deals in the file, and it is the last 12 full months. - **Wins (13):** Deal-A9FD43, Deal-7AA785, Deal-44C524, Deal-0D0CD6, Deal-D5B790, Deal-5C636E, Deal-67BE14, Deal-1B6969, Deal-F03E7B, Deal-072E31, Deal-F65C8F, Deal-E46EAB, Deal-1D2392. - **Losses (7):** Deal-7767F5, Deal-5645A5, Deal-C6FFAA, Deal-D263E0, Deal-935746, Deal-9066A6, Deal-72A02F. - **Win rate:** 13 / 20 = 65%. - **Loss clustering:** 4 of the 7 losses fell in 2026-03 to 2026-05: Deal-9066A6, Deal-5645A5, Deal-72A02F and Deal-C6FFAA. Since then (2026-06 to 2026-08) we are 3-0: Deal-67BE14, Deal-1B6969, Deal-F03E7B. - **Not counted:** the 2026-09 win in S25 has no deal alias and is not in the deals file. - **Missing data:** loss reasons and deal sizes. ## Removed or unverified from the old card - "Starts at $5, annual (as of 2026-01)": **Superseded.** It was correct at the time [S03], but the current list price is $7 [S17]. - "Lacks a Slack integration": **Contradicted.** A reviewer says the Slack integration works out of the box [S04]. Removed. - "Acquired by WorkHuman in 2025": **Unverified.** No snippet supports it. A 2025-11 Series C [S01] points to an independent company, but that does not prove it wasn't acquired. - "Mid-market positioning": **Partially sourced** [S04]; see the positioning note above. - "Strong in EU enterprise with multi-language": **Re-sourced** [S12, S15]. ## Excluded as rep opinion - S09 (Bryce Harmon: "UI is clunky"). - S21 (Elena Sinclair: "discounting aggressively"). Neither is used as fact. The only discount on record is the 15% for a 3-year term [S18].
**Per-sequence results** (all rates are divided by total sends across steps 1–3) New Logo Nurture - Sent: 500+458+428 = 1,386 - Open rate: 490/1,386 = 35.4% - Reply rate: 90/1,386 = 6.5% - Meeting rate: 27/1,386 = 1.9% - Weakest step: Step 3. It had 28.0% opens (120/428), 4.2% replies (18/428) and 1.4% meetings (6/428). Expansion Nurture - Sent: 300+300+275 = 875 - Open rate: 565/875 = 64.6%. This number isn't valid (see tracking error). Without Step 2 it's 225/575 = 39.1%. - Reply rate: 59/875 = 6.7% - Meeting rate: 12/875 = 1.4% - Weakest step: Step 3. It had 4.4% replies (12/275) and 1.1% meetings (3/275). Cold Outbound - HR Leaders - Sent: 600+595+590 = 1,785 - Open rate: 545/1,785 = 30.5% - Reply rate: 8/1,785 = 0.45% - Meeting rate: 0/1,785 = 0% - Weakest step: Step 3. It had 0.17% replies (1/590) and 22.0% opens (130/590). Cold Outbound - People Ops - Sent: 400+386+377 = 1,163 - Open rate: 340/1,163 = 29.2% - Reply rate: 29/1,163 = 2.5% - Meeting rate: 6/1,163 = 0.5% - Weakest step: Step 3. It had 1.6% replies (6/377) and 0.3% meetings (1/377). **Tracking error** - Expansion Nurture Step 2 shows 340 opens against 300 sends (113%). This row can't be trusted. **Audience overlap** (I checked audiences.csv by hand, not with a script) - HR Leaders and People Ops share 21 contacts: CT-000849, 000884, 000890, 000908, 001033, 001097, 001101, 001103, 001105, 001130, 001153, 001159, 001217, 001227, 001236, 001255, 001258, 001277, 001285, 001311, 001345. - Expansion Nurture and New Logo Nurture share 2 contacts: CT-000301 and CT-000624. The same contact being treated as both an existing customer and a new logo is a segmentation conflict. - The audience file lists far fewer contacts than the sends. Step 1 sent 500/300/600/400, so these rows look like a sample. That means the overlap counts are a minimum. **Why replies are under 2%** - HR Leaders (0.45%): opens are fine (Step 1 is 240/600 = 40%) but almost nobody replies. The emails are being delivered and read, so the likely problem is the message or offer not fitting this persona. Very few contacts drop out of later steps (600 → 595 → 590), so non-responders keep getting emails. It produced 0 meetings from 1,785 sends. - People Ops Step 3 (1.6%): replies fall at every step (3.5% → 2.3% → 1.6%). Each follow-up is doing less than the one before. **One change per weak sequence** 1. HR Leaders: rewrite Step 1 around a persona-specific offer. Until then, pause Steps 2–3 and remove the 21 contacts it shares with People Ops. 2. People Ops: replace Step 3 with a different angle or channel instead of another similar follow-up. 3. Expansion Nurture: fix open tracking on Step 2 before judging its performance. 4. New Logo Nurture: rewrite Step 3, which has the lowest meeting rate in the sequence (1.4%). **Fix first:** HR Leaders. It has the most sends (1,785), the lowest reply rate (0.45%) and zero meetings.
Weekly Marketing Goals Update: Q3-2026 (2026-07-01 to 2026-09-30) Time elapsed: 66 of 92 days, so 66 / 92 = 71.7%. Pace method: expected-to-date = target × 0.717. A metric is "on pace" if it's within ±5% of that expected value. Note: quarter_meta.csv says 66 days have elapsed. Counting from 2026-07-01 to today (2026-09-24) gives 86 days. I used the file's value as given. If 86 is correct, every count-based pace below is worse. Metric QTD actual Target Delta vs target Expected-to-date % of expected Pace SQMs 230 300 -70 215.2 106.9% Ahead SQOs 84 120 -36 86.1 97.6% On (slightly under) DS2s 40 75 -35 53.8 74.3% Behind Closed-lost MIA 20.0% ≤10.0% +10.0 pp (worse) n/a (rate) n/a Behind Same-qtr closes 10 20 -10 14.3 69.7% Behind Active pipeline $3,000,000 $4,000,000 -$1,000,000 n/a (stock) 75.0% of tgt Behind Arithmetic - SQMs: 300 × 0.717 = 215.2. 230 / 215.2 = 106.9%. Full-quarter run-rate: 230 / 0.717 = 320.6, which beats the target of 300. - SQOs: 120 × 0.717 = 86.1. 84 / 86.1 = 97.6%. Run-rate: 84 / 0.717 = 117.1, about 3 short of 120. - DS2s: 75 × 0.717 = 53.8. 40 / 53.8 = 74.3%. Run-rate: 40 / 0.717 = 55.8, about 19 short of 75. - MIA rate: 5 MIA / 25 closed-lost = 20.0%. That is double the 10% ceiling. At 25 losses, the ceiling allows 2.5 MIA. - Same-quarter closes: 20 × 0.717 = 14.3. 10 / 14.3 = 69.7%. Run-rate: 10 / 0.717 = 13.9, about 6 short of 20. - Active pipeline: $3.0M / $4.0M = 75.0%, a $1.0M gap. Pipeline is a point-in-time balance, so I measured it against the full target rather than pro-rating by days. The data has no bookings quota, so a coverage multiple (pipeline ÷ remaining quota) can't be calculated. Funnel conversion (from the provided data): SQM to SQO is 84 / 230 = 36.5%. SQO to DS2 is 40 / 84 = 47.6%. The volume problem starts after SQO. SQMs are ahead of pace and SQOs are roughly on pace, but DS2s, same-quarter closes and pipeline are all behind. What moved this week I can't say what moved week over week. The files only have QTD totals, with no prior-week snapshot and no deal- or company-level records, so there are no weekly deltas or deals to attribute. As of this snapshot, marketing is producing enough top-of-funnel volume: SQMs are 6.9% ahead of pace and on track for about 321 against 300. That volume isn't reaching late-stage outcomes. DS2s are at 74% of expected, same-quarter closes at 70%, and active pipeline is $1.0M short of $4.0M. The MIA rate of 20% is double the target, which suggests deals are being lost to disengagement instead of being worked to a decision. With 26 days left by the file's count, closing the DS2 gap would take 35 more DS2s, about 1.35 per day. The QTD rate so far is 40 / 66 = 0.61 per day. To report actual weekly movement, I'd need last week's QTD snapshot.
Don't commit to the Q3 forecast of 115,977 (44,729 COMMIT + 0.35 x 203,565 BEST_CASE) until reps re-qualify it, because none of the 7 in-quarter COMMIT deals has a documented reason to buy. The biggest BEST_CASE bet is Deal-2D7423 at 38,935. 32 deals worth 227,575 have October close dates, including COMMIT Deal-D348E1 (13,770), which suggests reps are pushing dates instead of re-qualifying deals.
Subject: Pricing for 150 seats: next step? Hi [Name], Following up on the recap and 150-seat pricing I sent on August 5, after our July 28 demo with you and your two HR admins. Your team responded well to the automated milestone awards and the points catalog. Those would replace the manual birthday and anniversary tracking you described on our discovery call. Would you be open to a 20-minute call in the next two weeks to go through the pricing and answer any questions before you decide? Best, Alex Franklin (Word count: about 85. The contact's name isn't in the data, so I left [Name] as a placeholder.)
Weekly GTM Digest: Week of 2026-08-31 Marketing: This week we generated 46 SQMs against a target of 52. That's 6 short (52 − 46 = 6), or 88.5% of goal (46 ÷ 52). Webinars carried the week with 18 SQMs, about 39% of the total (18 ÷ 46 = 39.1%). Paid search held steady at $150 per SQM. The extracts don't give channel counts beyond webinars, a prior-week comparison, or total spend, so we can't yet say where the other 28 SQMs (46 − 18) came from or how the gap trended. Next week we close the gap by building on what's working. Sales: Sales converted 14 SQOs and set 9 DS2 meetings, keeping pipeline moving. The team created $310,000 in new pipeline and closed 3 same-quarter deals this week. The extracts have no targets, win rates, or deal-level detail for Sales, so we're reporting what happened this week without judging it against a goal. CS: Customer Success saved 2 renewals this week, and team NPS now stands at 61. The extracts don't give last week's NPS, so we can't say whether it went up or down. We're heading into next week with 3 open red-flag accounts, and those are where the team's focus goes first. The extracts don't include the ARR tied to these renewals or accounts. PLG: Self-serve brought in 412 new signups, with activation at 31%. That implies about 128 activated signups (412 × 0.31 = 127.7), but this is our calculation, not a reported figure. 38 companies reached the aha moment of 10 recognition gives. The extracts don't show how those 38 companies overlap with this week's signups, and they have no targets or prior-week numbers to compare against.
Partner Digest: 2026-08-24 to 2026-09-04 Partner-sourced pipeline (partner_deals.csv, all utm_source = Partner) 5 deals, $550,000 total Arithmetic: $275,000 (Apex) + $140,000 (HRCloud) + $135,000 (CultureBridge) + $0 (WorkWell) = $550,000 Active partners Apex Rewards Co: 2 sourced opps, $275,000 - Deal-DDAAF2 $180,000 + Deal-2CF33E $95,000 = $275,000 - Slack says both deals are in DS1 and both were logged with UTM Source = Partner (Cole Ingram). - Co-webinar is locked for 09-15. HRCloud Partners: 1 sourced opp, $140,000 - Deal-F1CDA5 $140,000 - The integration referral cleared its security review and moved to DS2 (Slack). CultureBridge: 2 sourced opps, $135,000 - Deal-096E1D $60,000 + Deal-067213 $75,000 = $135,000 - Both came from the lunch-and-learn. Slack only calls them "early stage" and gives no specific stage. WorkWell Group: 0 sourced opps, $0 - No deals in partner_deals.csv, which matches Slack. - WorkWell wants to restart the joint playbook in Q4. A planning call is booked for 09-09. Quiet partners Recogniq: quiet. No deals or Slack activity this period. KudosWave: quiet. No deals or Slack activity this period. PeopleFirst Advisors: quiet. No deals or Slack activity this period. TotalPerk: quiet. No deals or Slack activity this period. Data gaps - partner_deals.csv has no stage column. All stages above come from Slack only. - The deal file has no close dates or created dates, so I can't confirm from it that the deals were created inside the period.
Security Questionnaire Response (source: Trust portal policy excerpts P1–P8) Q1. Is customer data encrypted at rest? If so, how? Yes. All customer data is encrypted at rest using AES-256. [P1] Q2. Is data encrypted in transit? Yes. Data in transit is encrypted with TLS 1.2 or higher. [P1] Q3. Do you hold a SOC 2 report, and can we obtain a copy? Yes. Bonusly has a SOC 2 Type II report that is renewed every year. Prospects can get a copy under NDA. [P2] Q4. How long is customer data retained after contract termination? We keep customer data for 90 days after the contract ends. After that, it is deleted from production systems. [P3] Note: P3 covers production systems only. The excerpts do not say whether the 35-day encrypted backup retention in [P6] applies after termination. The data retention and deletion policy would answer that. Q5. Where is your subprocessor list published and how are changes notified? The current list is published at trust.bonusly.com. Customers get 30 days' notice before a new subprocessor is added. [P4] Note: The excerpts do not say how the notice is sent (for example, email or portal). A subprocessor notification procedure or the DPA would answer that. Q6. Do you support SAML single sign-on? Yes. SAML 2.0 SSO is available on the Enterprise plan. SCIM user provisioning is also available on that plan. [P5] Q7. What is your production backup schedule and retention? Production databases are backed up daily. Backups are encrypted and kept for 35 days. [P6] Q8. Do you hold an ISO 27001 certification? Unanswerable from the excerpts. P1–P8 only mention SOC 2 Type II [P2]. An ISO 27001 certificate or a compliance certifications statement would answer this. Q9. What is your contractual uptime SLA percentage? Unanswerable from the excerpts. None of P1–P8 give an uptime commitment. The Service Level Agreement, or the SLA exhibit in the MSA, would answer this. Q10. Will you sign a HIPAA Business Associate Agreement? Unanswerable from the excerpts. None of P1–P8 mention HIPAA or BAAs. A HIPAA compliance statement or Legal's BAA policy would answer this. Summary: 7 items answered (Q1–Q7). Q4 and Q5 each have a gap noted. 3 items are unanswerable (Q8–Q10).
# Skill set vs. manifest reconciliation
**Scope:** 14 SKILL.md files and 14 manifest rows. I found 34 issues and made one proposal for each. Nothing was rewritten.
**Limits:** Anything outside this skill set is treated as "not found in the provided data." Some delegation targets may exist elsewhere, but I can't confirm that from the files I was given.
## 1) Always-trigger phrase overlaps
**F01 · CRITICAL · TRIM_DESC · pipeline-intelligence-report vs weekly-pipeline-report**
- pipeline-intelligence-report always-triggers on "pipeline update" and "what's the pipeline look like". It also says: "never answer pipeline questions inline without running it."
- weekly-pipeline-report always-triggers on "run the pipeline update", "update the pipeline" and "what does pipeline look like".
- "pipeline update" is a substring of "run the pipeline update". The two "look like" phrases differ by one word.
- **Proposal:** Remove "pipeline update", "what's the pipeline look like" and "forecast context" from the pipeline-intelligence-report description. Narrow its catch-all line to scored or tiered pipeline requests only.
**F02 · CRITICAL · MERGE · comms-drafter vs email-drafter**
- Six trigger phrases appear in both:
- "write me an email"
- "draft a follow-up"
- "help me reply"
- "what should I say"
- "bump email"
- "contract nudge"
- Both also trigger on "pasted message → feedback/rewrite."
- The bodies duplicate each other too: the contract-follow-up benchmark (word for word), the response format, the review rubric (rate 1–10) and the lane marker.
- **Proposal:** Merge email-drafter into comms-drafter, with comms-drafter as the survivor (see V03). Carry over email-drafter's unique parts: the Gmail signature retrieval and the no-markdown-in-body rule.
**F03 · WARNING · TRIM_DESC · sales-forecast vs next-to-close**
- sales-forecast always-triggers on "what do we think we're going to close" and "deal-level confidence".
- next-to-close always-triggers on "what's about to close" and "which deals are most likely to close".
- **Proposal:** Remove "what do we think we're going to close" and "deal-level confidence" from sales-forecast. That leaves deal-level shortlists to next-to-close.
**F04 · WARNING · TRIM_DESC · next-to-close vs deal-strategy-coach**
- next-to-close always-triggers on "which deals are most likely to close".
- deal-strategy-coach triggers on "asks which deals are likely to close".
- **Proposal:** Remove "asks which deals are likely to close" from deal-strategy-coach.
**F05 · WARNING · TRIM_DESC · stale-pipeline-report vs deal-strategy-coach**
- stale-pipeline-report always-triggers on "deals that haven't been touched", "who hasn't been contacted" and "any AE or Alaina asks which deals they haven't touched recently".
- deal-strategy-coach triggers on "identifies stalled deals", "reviews a rep's pipeline" and "where is [rep] spending their time".
- **Proposal:** Remove "identifies stalled deals" from deal-strategy-coach.
**F06 · INFO · REVIEW · Always-on gates that fire alongside everything**
- These four skills fire with every always-trigger above:
- model-selection: "start of every task, without exception"
- analysis-validator: "Always. No exceptions."
- signalforge-claim-compressor
- signalforge-feedback (final step)
- The order validator → compressor → feedback is written down. No other skill in the set says where model-selection sits in that order.
- **Proposal:** Confirm this co-firing is intended, and document where model-selection sits relative to the validator chain.
## 2) Circular delegation
**F07 · CRITICAL · UPDATE_BODY · deal-strategy-coach → email-drafter → deal-strategy-coach**
- deal-strategy-coach says: "When drafting manager-to-prospect emails, use the email-drafter skill."
- email-drafter says: "For deal strategy, diagnosis, or coaching … use deal-strategy-coach instead." Its lane marker also points back to deal-strategy-coach.
- comms-drafter also points to deal-strategy-coach, so it enters the same loop.
- A request like "diagnose and draft a manager email" has no final owner.
- No other cycles exist:
- next-to-close → pipeline-intelligence-report → closed-lost-analysis stops at closed-lost-analysis.
- sales-forecast → analysis-validator → compressor → feedback runs in a straight line.
- **Proposal:** deal-strategy-coach should draft manager emails itself (it already contains the 4 frameworks) and borrow only the signature retrieval. Remove the handoff. If F02 goes ahead, point it to comms-drafter instead, whose lane marker only points one way.
## 3) Delegation targets that don't exist
**F08 · CRITICAL · UPDATE_BODY · pipeline-intelligence-report expects things closed-lost-analysis doesn't provide**
- pipeline-intelligence-report expects closed-lost-analysis to supply:
- a `loss_risk_score`
- penalty weights
- a "5-section" Loss Intel spec
- risk bands: ≥6 high, 3–5 moderate, ≥9 extreme
- closed-lost-analysis Mode 4 defines none of these. Its output is "High risk (2+ signals), Moderate (1 signal)."
- The time window also conflicts. Phase 2b and the footer say 6 months (T180D), but the Loss Profile says "trailing 12 months."
- **Proposal:** Add a Mode 4 scoring contract to closed-lost-analysis: score, weights, bands and the 5-section spec.
None of the targets below are in this set or the manifest:
**F09 · CRITICAL · REVIEW · bonusly-brand**
- It is a mandatory "Step 0 … Always" in comms-drafter.
- It is also used by email-drafter, sales-forecast and signalforge-claim-compressor.
- **Proposal:** Confirm it exists elsewhere, or add it to the set and manifest.
**F10 · CRITICAL · REVIEW · signalforge-reports**
- pipeline-intelligence-report lists "MANDATORY PRE-BUILD" reads at `/mnt/skills/organization/signalforge-reports/`: SKILL.md, DESIGN-SYSTEM.md, signalforge.css, reports.html and brand-lockup.html.
- weekly-pipeline-report Step 4 also requires it.
- **Proposal:** Confirm the path exists, or add the skill to the set and manifest.
**F11 · WARNING · REVIEW · prospect-research-multithreading**
- Used by comms-drafter, email-drafter and deal-strategy-coach.
- **Proposal:** Confirm it exists, or add it.
**F12 · WARNING · REVIEW · skill-orchestrator**
- Referenced in analysis-validator §11 (cascade) and in the signalforge-feedback activation checklist ("registered in skill-orchestrator").
- **Proposal:** Confirm it exists, or add it.
**F13 · WARNING · REVIEW · The 8 specialist skills in analysis-validator §12.4**
- bonusly-data-questions (also cited in G1-J), -product-, -business-reporting-, -rewards-, -ppp-, -feature-flag-, -deal-desk- and -datadog-questions.
- **Proposal:** Confirm all 8 exist, or add them.
**F14 · INFO · REVIEW · analysis-validator §11 cascade files**
- CUSTOMER_DATA_REFERENCE, HUBSPOT_CONNECTOR_REFERENCE and SIGNALFORGE_PRODUCT_INSIGHT_SKILL.
- **Proposal:** Confirm they exist.
**F15 · INFO · REVIEW · "caveman"**
- signalforge-claim-compressor says "both can be used together" but doesn't name a skill.
- **Proposal:** Confirm the skill exists, or remove the co-use line.
**F16 · INFO · REVIEW · Reference files that weren't provided**
- sales-forecast `references/`: data-sources.md, report-structure.md, cadence.md, report-template.html and TEMPLATE_README.md.
- weekly-pipeline-report: `references/report-spec.md` and `queries.md`.
- stale-pipeline-report: `/mnt/skills/public/xlsx/scripts/recalc.py`.
- pipeline-intelligence-report: `references/html-spec.md`, which it says itself is deprecated.
- **Proposal:** Verify each file exists.
**F17 · INFO · UPDATE_BODY · Unnamed target in closed-lost-analysis**
- It says "Churn skills handle…" and "CS/ChurnZero analysis" without naming a skill.
- **Proposal:** Name the actual skill, or say there isn't one.
## 4) Version conflicts and which skill survives
**V01 · CRITICAL · UPDATE_BODY · Gong transcript column**
- closed-lost-analysis selects `t.SNIPPET` from GONG_TRANSCRIPTS_AGG.
- stale-pipeline-report v1.1 (2026-06-10) says that table has exactly two columns, CONVERSATION_KEY and TRANSCRIPT, and that "no SNIPPET … will error."
- analysis-validator v3.6 §13.7 also uses `t.TRANSCRIPT`.
- **Survivor:** the TRANSCRIPT definition used by stale-pipeline-report and analysis-validator.
- **Proposal:** Fix the query in closed-lost-analysis.
**V02 · WARNING · REVIEW · GONG_HUBSPOT_MAP.DEAL_ID**
- closed-lost-analysis and stale-pipeline-report both filter on `m.DEAL_ID`.
- The analysis-validator §13.7 field list (updated May 4, 2026) has no DEAL_ID column: it lists CONVERSATION_KEY, CALL_DATE, HS_COMPANY_ID, BONUSLY_COMPANY_ID and OWNER_ID.
- **Survivor:** can't be decided from this data.
- **Proposal:** Check the live schema.
**V03 · CRITICAL · MERGE · comms-drafter vs email-drafter**
- Neither has a version number or changelog, so I picked the survivor on scope.
- **Survivor:** comms-drafter. It covers all 13 of email-drafter's email types, plus support/Intercom, partner, and rewards-vendor messages.
- **Proposal:** Carried out by F02. No separate action.
**V04 · WARNING · UPDATE_BODY · AE roster**
- pipeline-intelligence-report lists 5 AEs ("verified May 2026").
- analysis-validator §12.3 (updated May 4, 2026) lists the "Core 6", including Hugo Lindqvist (77260721), and says the Core 6 filter "must include all six IDs."
- stale-pipeline-report v1.1 says "Never hardcode rep names or owner IDs."
- pipeline-intelligence-report is missing 1 of the 6 AEs.
- **Survivor:** stale-pipeline-report's rule to look owners up at runtime.
- **Proposal:** Remove the fixed AE list from pipeline-intelligence-report.
**V05 · WARNING · UPDATE_BODY · analysis-validator contradicts itself**
- The header says v3.6, but the trail template says "analysis-validator v3.2."
- G2-F was added in v3.6, but §1 Full Mode and the §6 decision tree still say "G2-A through G2-E."
- G1-J says "all five conditions," but its check table has 6 rows and the trail says "all 6."
- G1-B says "all three required together" for USERS, but lists only 2 conditions.
- §8 says "Do not use hardcoded figures," yet G1-J hardcodes ~452,000 users and ~110,097 dormant users.
- **Survivor:** the v3.6 header.
- **Proposal:** Align every internal reference to v3.6.
**V06 · WARNING · UPDATE_BODY · sales-forecast v1.1 is only partly quarter-agnostic**
- The v1.1 changelog says it moved from Q2 to "current quarter throughout."
- The body still says "1A — HubSpot: Open Q2 Deals" and has a tab called "Q2 Narrative."
- **Survivor:** the v1.1 intent.
- **Proposal:** Replace the remaining Q2 references with the current quarter.
**V07 · WARNING · REVIEW · stale-pipeline-report ZoomInfo scope**
- Phase 4 says run ZoomInfo "for every deal, regardless of ARR or stage."
- Execution Sequence step 4 says "DS3+ or ARR ≥ $20K with empty ai_why_buys."
- The v1.1 changelog says "enrichment for thin deals," which leans toward the narrower rule.
- **Proposal:** Decide which rule applies and make both sections match.
**V08 · WARNING · UPDATE_BODY · signalforge-feedback target page**
- Step 4 writes to page 2295136266 under the heading "## Feedback Entries."
- The Activation Checklist names the Build Log page 2247295002 and a "## Feedback Log" section.
- **Survivor:** Step 4.
- **Proposal:** Update the checklist to match Step 4.
**V09 · WARNING · REVIEW · Demand Gen owner name**
- weekly-pipeline-report says "Ben Lavin · Demand Generation."
- analysis-validator §12.3 says "Ben Castelli, Director of Demand Generation."
- **Survivor:** can't be decided from this data.
- **Proposal:** Confirm the correct name.
**V10 · INFO · UPDATE_BODY · HubSpot deal URL format**
- pipeline-intelligence-report and next-to-close use `/contacts/1973303/record/0-3/{id}`.
- stale-pipeline-report uses `/contacts/1973303/deal/{id}`.
- **Survivor:** record/0-3. Two of the three skills use it, and it's a non-negotiable in pipeline-intelligence-report v6.
- **Proposal:** Switch stale-pipeline-report to the record/0-3 format.
**V11 · INFO · UPDATE_BODY · Stage names**
- analysis-validator: "DS3 Eval / Proposal", "DS4 Vendor Choice", "DS5 Procurement."
- deal-strategy-coach: "Evaluation / Proposal", "Vendor of Choice", "Procure." It also adds a DS0 stage that has no stage ID anywhere in the set.
- **Survivor:** analysis-validator, which owns canonical terminology under G1-H.
- **Proposal:** Rename the stages in deal-strategy-coach to match.
**V12 · INFO · REVIEW · model-selection example contradicts its own rubric**
- Example 4 scores 9, which the rubric maps to Tier 2 (Sonnet).
- The example recommends Opus through an "override" the rubric never defines.
- **Proposal:** Define the override in the rubric or fix the example.
## 5) Descriptions over 1,024 characters
**Result: 0 of 14.** The highest declared value is 1,006.
Four descriptions are close to the limit:
| Skill | Declared chars | Headroom (1,024 − declared) |
|---|---|---|
| pipeline-intelligence-report | 1,006 | 18 |
| signalforge-claim-compressor | 1,006 | 18 |
| partner-digest | 1,004 | 20 |
| comms-drafter | 996 | 28 |
These are the manifest's declared values. My rough counts agreed with them, but I didn't verify them character by character.
**D01 · INFO · TRIM_DESC**
- **Proposal:** Trim these 4 descriptions so any future edit doesn't push them over 1,024. The F01 trim already cuts pipeline-intelligence-report.
## 6) Hardcoded page IDs, dates and person names
**H01 · WARNING · UPDATE_BODY · analysis-validator**
- Names: a 19-person roster with owner IDs (6 AEs, 7 CSMs, Alaina Loori, Shealagh Coughlin, Ben Castelli, Amani Phipps, John Thomas, Yasmin Wahid). Escalations go to "Manish / Amani." Examples use "Dana Mercer" and "Gavin Porter."
- Dates: April 26, 2026; May 9, 2026; May 4, 2026 (roster, CALL_SPOTLIGHT_BRIEF, CLOSEDWON_DEALS); March 28, 2023; "as of May 2026" ranges.
- **Proposal:** Move the roster and anchors into a lookup that runs at runtime, following the V04 survivor rule.
**H02 · INFO · UPDATE_BODY · closed-lost-analysis**
- Names 10 companies: Softheon, Estee Lauder, LIFTOFF, Nestlé, Ozinga, MinIO, Aurora Innovation, GCash, Ethos Cannabis, StickerYou.
- Dates: "May 2026" and "May 4–12".
- Hardcoded rates: 17%, 8% and 14%+.
- The line "30-deal AI-field sample … 10 of 10 deals" mismatches its own denominator (30 vs 10).
- **Proposal:** Mark these as dated examples and fix the 30-vs-10 denominator.
**H03 · WARNING · UPDATE_BODY · deal-strategy-coach**
- Confluence page ID: 2257879045 ("AE Excellence Playbook April 2026").
- Names: "Farid" (.edu routing) and "Perseus" (India routing).
- Also hardcodes "Pricing — 2026" and "200+ Gong calls / 370+ deals".
- **Proposal:** Move the page ID and routing owners into config.
**H04 · WARNING · UPDATE_BODY · model-selection**
- Dates: `last_checked: 2026-05-19` and "April 14, 2026."
- The skill's own rule is to self-update when more than 14 days have passed since the last check:
- The update was due on 2026-06-02 (May 19 + 14 days).
- Days since the last check: 12 + 30 + 31 + 31 + 24 = 128.
- Days overdue: 128 − 14 = 114.
- **Proposal:** Run the self-update procedure the skill already defines.
**H05 · WARNING · UPDATE_BODY · partner-digest**
- Confluence cloud ID: 73fe98de-a4a3-4869-9f8a-bb1eeed4cf7f.
- Confluence space ID: 1958248479.
- Confluence folder ID: 2286616609.
- Confluence page IDs: 2286321666, 2265382925, 2236940297, 2237825028, 2239365136 and 2238283777.
- Slack user ID: U03QLMBL7AR.
- Names: Amani Phipps, Kelli, Jen Lee, Hani, Bryce and Sara.
- Dates: May 16, 2026 and May 19 / June 2 examples.
- **Proposal:** Move the IDs and contacts into a partner config.
**H06 · WARNING · UPDATE_BODY · pipeline-intelligence-report**
- Names: 5 AEs with owner IDs, plus "Alaina" in the description.
- Versions and dates: "v6 · May 2026", "verified May 2026", and "Analysis Validator v3.6" in the footer, which will drift as the validator changes.
- **Proposal:** Remove these per V04 and read the validator version at runtime.
**H07 · WARNING · UPDATE_BODY · sales-forecast**
- Confluence space ID: 2232811524.
- Confluence parent page ID: 2232582148.
- Confluence cloud ID: 73fe98de-a4a3-4869-9f8a-bb1eeed4cf7f.
- Names: Alaina and Elena.
- Dates: April 27, 2026 and a July 9, 2026 example.
- **Proposal:** Move the Confluence IDs into config.
**H08 · WARNING · UPDATE_BODY · stale-pipeline-report**
- It hardcodes owner ID 55483190, which breaks its own "never hardcode" rule.
- Slack channel ID: C0561C1JCPJ.
- Also hardcodes the name "Alaina", a "97 deals" count, and example dates 5/7, 5/15 and 5/19.
- **Proposal:** Replace the ID and count with runtime lookups.
**H09 · WARNING · UPDATE_BODY · weekly-pipeline-report**
- Name: "Ben Lavin" (see V09).
- Spreadsheet IDs: 1CLZeOs… and 1ENuaEc….
- Q2 2026 window "April 1 – June 30, 2026." That quarter ended 86 days ago (31 + 31 + 24).
- Q1 static figures (the arithmetic checks out):
- Bookings: $365,152 / $475,000 = 76.9%, stated as 77% ✓
- Pipeline additions: $2,490,532 / $3,288,000 = 75.7%, stated as 76% ✓
- **Proposal:** Compute the current quarter at runtime instead of hardcoding Q2.
**H10 · INFO · UPDATE_BODY · signalforge-feedback**
- Confluence page IDs: 2295136266, 2234417154 and 2247295002.
- Confluence space ID: 2232811524.
- Names in examples: "Gavin Porter Rep Diagnostic" and "Lowe's".
- **Proposal:** Move the IDs into config and use neutral examples.
**H11 · INFO · REVIEW · signalforge-claim-compressor**
- Example companies: Panopto, Schneider Downs and Felix Construction.
- Dates: 2026-05-09 and a "JuliusBrussee/caveman" reference.
- **Proposal:** These are illustrative only. Keep or anonymize.
**Clean:** comms-drafter and email-drafter have no page IDs, dates or person names. next-to-close has only system constants (portal ID 1973303 and stage IDs), which is acceptable.
## 7) Manifest drift
- **Files with no manifest row:** 0.
- **Manifest rows with no file:** 0.
- The `declared_name` matches the frontmatter `name` for all 14.
**M01 · INFO · REVIEW · Checks I couldn't complete**
- I couldn't verify `body_lines` from the provided text, so drift inside line counts is still possible.
- pipeline-intelligence-report is the only file with a `version` key in its frontmatter.
- The manifest has no version column, so the conflicts in section 4 can't be tracked through it.
- **Proposal:** Recount `body_lines` from the source files, and consider adding a version column to the manifest.
## Totals
**By severity:** 8 CRITICAL, 16 WARNING, 10 INFO.
- CRITICAL: F01, F02, F07, F08, F09, F10, V01, V03.
**By action:** 12 UPDATE_BODY, 5 TRIM_DESC, 2 MERGE, 15 REVIEW, 0 DELETE_SKILL.
- No DELETE_SKILL is proposed. email-drafter goes away through the merge, not a delete.
RUNBOOK: reward-worker queue backlog / Redis timeouts
Source: #incident-2026-08-29-reward-queue (resolved), messages M01 to M10
Legend: [NC] = needs confirmation (the thread doesn't cover it)
STEP 1: Acknowledge the alert and take IC (M01)
Trigger: PagerDuty alert, reward-worker queue depth > 10k
Action: Acknowledge the alert and take Incident Commander
Who: Bryce Harmon, 2026-08-29 14:02:10Z
Verification: Not documented [NC]
Rollback: No system state changed
STEP 2: Measure queue depth (M02)
Command: bundle exec rake sidekiq:queue_depth
Who: Farid Osman, 14:04:33Z
Result: 48,213 pending jobs in the reward queue. Normal is under 500.
Rollback: Read-only, no state changed
STEP 3: Inspect the dead set (M03)
Command: Not documented [NC]
Who: Farid Osman, 14:06:02Z
Result: 112 jobs in the dead set, all Redis::TimeoutError, from around 13:58
Rollback: Read-only as reported, no state changed
STEP 4: Pause enqueue to stop the bleed (M04)
Command: bin/rails runner 'FeatureFlag.disable(:auto_recognition_enqueue)'
Who: Farid Osman, 14:08:45Z
Verification: No check that the flag was disabled [NC]
Rollback: bin/rails runner 'FeatureFlag.enable(:auto_recognition_enqueue)'
(stated in M04)
STEP 5: Clear the dead set (M05) [NC]. This deleted data.
Command: Not documented. Elena Sinclair says only "while I was in the
console I cleared out the dead set." [NC]
Who: Elena Sinclair, 14:15:20Z
Verification: Not documented [NC]
Rollback: Not documented [NC]
Note: The thread doesn't say this step was planned or approved as a
fix. The 112 Redis::TimeoutError jobs from M03 were removed and
the thread doesn't say they were retried or kept. Confirm with
Elena Sinclair and the IC before this becomes a standard step.
STEP 6: Scale workers up (M06)
Command: kubectl scale deployment/reward-worker --replicas=6 (was 3)
Who: Bryce Harmon, 14:21:07Z
Verification: No check of the replica count [NC]
Rollback: kubectl scale deployment/reward-worker --replicas=3
(stated in M06)
STEP 7: Watch the queue drain (M07)
Command: Not documented [NC]
Who: Farid Osman, 14:33:41Z
Result: Queue depth 9,400 and falling about 1,200/min
Rollback: Read-only, no state changed
STEP 8: Confirm the queue is empty and errors are back to normal (M08)
Command: bundle exec rake sidekiq:queue_depth
Who: Cole Ingram, 14:47:55Z
Result: Returns 0. Datadog error rate back to baseline. The thread
doesn't name the Datadog monitor or dashboard [NC].
Rollback: Read-only, no state changed
STEP 9: Re-enable enqueue (M09)
Command: bin/rails runner 'FeatureFlag.enable(:auto_recognition_enqueue)'
Who: Bryce Harmon, 14:49:10Z
Verification: 40 new jobs processed cleanly in the next 3 minutes. The
thread doesn't say how this was checked [NC].
Rollback: Not documented for this step [NC]
STEP 10: Scale workers back down and close the incident (M10)
Command: kubectl scale deployment/reward-worker --replicas=3
Who: Bryce Harmon, 14:55:00Z
Verification: Queue stable at 0. The thread doesn't say how this was checked,
and there's no check of the replica count [NC].
Rollback: Not documented for this step [NC]
Outcome: Incident declared resolved (M10)
OPEN ITEMS TO CONFIRM
1. M03: the command used to inspect the dead set.
2. M05: the exact command for clearing the dead set, whether it was approved,
whether the 112 jobs needed to be kept or retried, and any rollback.
3. M04 and M06: direct checks that the flag was disabled and the deployment
reached 6 replicas.
4. M07: the command behind the 9,400 figure and the ~1,200/min rate.
5. M08: which Datadog monitor or dashboard was used.
6. M09 and M10: how each result was checked, and whether rollback exists for
these two steps.
7. The thread gives no root cause for the Redis::TimeoutError errors around
13:58.
**Redis timeout incident on reward-service, 2026-09-03 (UTC)**
**First error**
2026-09-03T14:01:12Z, reward-service, ERROR: "Redis::TimeoutError: Connection to Redis at redis-primary:6379 timed out after 5s"
- The last healthy reward-service lines were a health check ok at 13:59:09Z and a job enqueued at 13:59:30Z.
- There are no log lines from any service between 13:59:30Z and 14:01:12Z, a gap of 1m42s.
**Cascade, in order**
1. 14:01:12Z, reward-service: cannot connect to Redis at redis-primary:6379.
2. 14:01:20Z, 14:01:30Z and 14:01:40Z, reward-service: "retry exhausted for RewardGiveJob", three times, 10s apart.
3. 14:01:40Z, sidekiq: "RewardGiveJob failed: Redis::TimeoutError; retrying in 60s".
4. 14:01:46Z to 14:01:57Z, sidekiq_jobs: first batch of RewardGiveJob failures, J-00001 to J-00006 (6 jobs). The earliest is J-00005 at 14:01:46Z.
5. 14:02:28Z, sidekiq: RewardGiveJob fails again on retry.
6. 14:02:30Z, sidekiq WARN: "Queue reward depth above 10,000".
7. 14:02:36Z, sidekiq_jobs: a second job class fails, RecognitionDigestJob J-00013.
8. 14:02:51Z to 14:02:58Z, sidekiq_jobs: second batch of RewardGiveJob failures, J-00007 to J-00012 (6 jobs).
9. 14:03:05Z, api-gateway: "502 upstream timeout calling reward-service /gives". This is the first upstream impact.
10. 14:03:30Z, web-app: "Give form submission failed: upstream 502 from api-gateway". This is the first user-facing failure.
11. 14:03:31Z to 14:06:52Z, all three layers keep failing:
- sidekiq retry failures at 14:03:31, 14:04:22, 14:05:26 and 14:06:47.
- api-gateway 502s at 14:03:48, 14:04:13, 14:05:16 and 14:06:52.
- web-app failures at 14:04:45, 14:05:42 and 14:06:49.
- RecognitionDigestJob failures at 14:03:15 (J-00014), 14:04:55 (J-00015) and 14:05:50 (J-00016).
12. 14:06:52Z: last ERROR line.
13. 14:22:10Z, reward-service: "Redis connection restored; resuming job processing".
14. 14:24:45Z, sidekiq: "Queue reward depth below 500".
**Timings**
| Interval | Arithmetic | Duration |
|---|---|---|
| First error to first api-gateway 502 | 14:01:12 → 14:03:05 | 1m53s |
| First error to first web-app failure | 14:01:12 → 14:03:30 | 2m18s |
| First error to Redis restored | 14:01:12 → 14:22:10 | 20m58s |
| First error to queue below 500 | 14:01:12 → 14:24:45 | 23m33s |
**Counts**
- Datadog ERROR lines: reward-service 4 + sidekiq 6 + api-gateway 5 + web-app 4 = 19. There is also 1 WARN.
- Failed jobs: 12 RewardGiveJob + 4 RecognitionDigestJob = 16.
**Service and job involved**
- Service: reward-service. Its dependency, redis-primary:6379, is the component that timed out.
- Primary job: RewardGiveJob, processed by sidekiq.
- Also affected: RecognitionDigestJob. It appears only in sidekiq_jobs.csv, not in the Datadog logs.
**Datadog query to confirm the first error**
```
service:reward-service status:error "Redis::TimeoutError" "redis-primary:6379"
```
- Time range: 2026-09-03 13:55:00Z to 14:01:40Z, sorted by oldest first.
- This confirms 14:01:12Z as the earliest match and checks for anything in the 13:59:30Z to 14:01:12Z gap.
- To see whether other services hit Redis first, widen the scope to `"Redis::TimeoutError"` with no service filter.
- I assumed the facet names (service, status); they are not in the CSV.
**What the logs do not show**
- **Root cause:** there are no logs or metrics from Redis itself (memory, CPU, connections, network, failover, evictions). Nothing explains why redis-primary timed out.
- **Whether 14:01:12Z is truly the first error:** the slice starts at 13:55:13Z, and the 1m42s silence before the first error is unexplained.
- **14:06:52Z to 14:22:10Z (15m18s):** only postgres "checkpoint complete" lines. There are no errors, no remediation, and no record of what restored Redis or whether anyone intervened.
- **Peak queue depth:** only the thresholds ">10,000" and "<500" are logged.
- **Links between the two files:**
- No job IDs appear in the Datadog lines.
- The sidekiq log shows a failure at 14:01:40Z, but the earliest failed_at in sidekiq_jobs is 14:01:46Z, a 6s mismatch.
- The 60s retry notice fits the second batch of failures, but the job IDs differ, so I can't confirm those were retries.
- **Job outcomes:** it's unknown whether the 16 failed jobs later succeeded, went to the dead set, or were dropped.
- **Why the api-gateway 502s happened:** they appear causally tied to reward-service waiting on Redis, but there are no request IDs or traces to prove it.
- **User impact:** the number of gives or users affected is not shown; only 4 web-app failure lines are logged.
- **Postgres:** there is no evidence it was involved. It only logged routine checkpoints.
Feature flag summary (9 flags in flags_export.csv) ON flags (5) 1. recognition_streaks_v2: on, segment:beta_companies, 42 companies What it controls (app/models/recognition.rb): when enabled, StreakTracker.record(give) runs on each recognition. 2. points_budget_guardrails: on, all_companies, 220 companies What it controls (app/services/budget_service.rb): when enabled, BudgetService.new(company).enforce!(giver, points) runs, which applies budget rules to points given. 3. slack_dm_nudges: on, segment:region_na, 87 companies What it controls (app/jobs/nudge_job.rb): NudgeJob stops early unless the flag is enabled. When enabled, SlackDm.send_nudge(user) runs. 4. analytics_dashboard_v3: on, segment:tier_three, 65 companies What it controls (app/controllers/analytics_controller.rb): when enabled, @dashboard = AnalyticsV3.new(company). The excerpt has no else branch, so it doesn't show what happens when the flag is off. 5. survey_boosters_q3: on, segment:legacy_plan, 7 companies What it controls: not in the code excerpt. OFF flags (4) 6. redeem_flow_redesign: off, targeted_list, 12 companies What it controls (app/controllers/redeem_controller.rb): renders RedeemV2Component when enabled and RedeemV1Component otherwise. With the flag off, V1 is the expected path. 7. ms_teams_app_v2: off, targeted_list, 9 companies What it controls (app/services/teams_installer.rb): when enabled, TeamsAppV2.install(company) runs. 8. legacy_give_modal: off, segment:legacy_plan, 14 companies What it controls: not in the code excerpt. 9. paused_offboard_cleanup: off, no targeting rule, 0 companies What it controls: not in the code excerpt. Flags with no code reference in flag_code.md (3) - survey_boosters_q3 (this one is on, with 7 companies) - legacy_give_modal - paused_offboard_cleanup Flags with no targets (1) - paused_offboard_cleanup: targeting_rules is empty and company_count = 0. It is off, has no targets and has no code reference. Data gaps and inconsistencies - The export doesn't name the companies in the targeted lists for redeem_flow_redesign (12) and ms_teams_app_v2 (9), or the members of any segment. - Two flags use segment:legacy_plan but show different counts: legacy_give_modal = 14 and survey_boosters_q3 = 7. The export doesn't explain why. - redeem_flow_redesign and ms_teams_app_v2 are off but still carry targeting and company counts. The export doesn't confirm whether those targeted companies are actually getting the flag while it's off. - The export doesn't give segment sizes, so I can't tell whether a count is the whole segment or part of it. Arithmetic (these are company-to-flag assignments, not unique companies, because the export doesn't show overlap) - On flags: 42 + 220 + 87 + 65 + 7 = 421 - Off flags: 12 + 9 + 14 + 0 = 35 - Total: 421 + 35 = 456
NDA triage NDA-1 [PARTY A]: GREEN Clause: Section 3, "(a) is or becomes publicly available through no breach, (b) was known prior to disclosure, (c) is received from a third party without duty of confidence, (d) is independently developed, or (e) must be disclosed by law or court order." Reasoning: It's mutual and has all five standard carve-outs, Delaware law, and "no license, no obligation to proceed, no exclusivity." There's no non-solicit or non-compete. The longest exposure is 2 years of term plus 3 years of survival, so 5 years from the Effective Date. That's within normal range. NDA-2 [PARTY B]: YELLOW Clause: Section 4, "During the term of this Agreement and for eighteen (18) months thereafter, neither party shall solicit for employment or hire any employee of the other party with whom it came into contact under this Agreement." Reasoning: Delaware law and standard carve-outs are fine, but it contains a non-solicit that also bans hiring. It lasts 3 years of term plus 18 months, which is 36 + 18 = 54 months (4.5 years), so counsel should narrow or remove it. Data gaps: The carve-outs are only summarized as "standard," with no verbatim text provided. No survival period after the term is stated. NDA-3 [PARTY C]: RED Clause: Section 2, "For a period of three (3) years following the Effective Date, Recipient shall not, directly or indirectly, engage in or provide services to any business that competes with Discloser's business." Reasoning: This non-compete could stop Bonusly from doing its core business for 3 years. It's also one-way in [PARTY C]'s favor with a 5-year term. Section 3 adds foreign law with exclusive courts: "the laws of the Republic of Ireland, and the parties submit to the exclusive jurisdiction of its courts." Section 4 states "No confidentiality carve-outs are stated in this Agreement." That's four problems in one agreement. This is a text-only review of the file you provided. I didn't check prior Bonusly exceptions or the master NDA template.