Sources: 33 meeting transcripts, Nov 2025 – Jun 2026 (kc3-transcripts/)
Purpose: Inventory KC3's business processes, identify pain points, and propose feature ideas (platform-agnostic) for the most painful problems.
KC3 is a small (~10–15 person) NYC sustainability consultancy led by Daphany Rose Sanchez, specializing in outreach, technical assistance, and case management for affordable multifamily building decarbonization. They are matrix-managed, fully remote, and a Microsoft/SharePoint shop. They have no PE on staff and no CRM of their own — on every contract they use whatever software the prime provides.
List building and targeting. Staff build target lists from criteria (oil burners, one-pipe steam, C/D grades, high fines, flood zones) using Momentum advanced search plus their own Excel workbooks. Con Ed/Willdan stopped supplying eligible-customer lists years ago, so the team approximates utility territory by zip code. Building→owner/PM matching is done by hand via Property Shark and Who Owns What subscriptions.
Mass outreach (HPD 3-2-1 Go). Nanda segments the HPD list, sends batched BCC emails with HPD CC'd for legitimacy, and tracks sends/responses/bounces in an Excel tracker shared with HPD via SharePoint. Follow-up rounds are planned by bucket (oil buildings, near-2030 fines, co-ops, solar candidates). Response rates to generic mass email are very low (~750 sent, "a handful responded").
Campaigns (NYCA). Willdan's comms lead runs staggered re-engagement email campaigns (≤1,000/week), each requiring city approval.
NYCA inbound. Leads arrive via web form (auto-creates Salesforce Lead), call center, email, or Momentum signup. Staff manually convert Lead → Account/Contact/Opportunity, run a due-diligence lookup (legacy interaction history, Momentum building data, compliance pathway on the city CBL, affordability status), and route: refer out / self-service / KC3 queue (affordable) / Willdan queue (market rate).
Weekly triage. Ivan exports the Salesforce opportunity list as a PDF; Marc uses AI to convert opportunity names into addresses; they build a Momentum "Salesforce Inbound" collection sorted by fine size and spend ~3 min/building cross-checking data and deciding actions, logging back to Salesforce manually.
HPD intake. Website form → secondary spreadsheet → notification email to a shared inbox → manual scheduling → manual transfer into Momentum.
Case managers find the building in Momentum (often resorting to asking the owner for the BBL because address matching fails), verify/correct inferred data (heating type, square footage), build a scope from suggested packages, and share it via link, PDF, or screen-share. On AMEEP, Jennifer builds comp (points-based) and non-comp (per-measure) incentive scopes and cross-checks them against utility fact sheets. After scoping, Momentum historically dropped out of the workflow entirely.
AMEEP suffers triple entry: the same status update goes into Emily's master Excel, Willdan's Monday.com (coarse statuses, so detail lives in notes columns), and Momentum. True status lives in Willdan's Viewpoint/SMART systems, which KC3 cannot see — "Willdan is like the middleman for us to confirm statuses." Troubleshooting is reactive: scan trackers by eye, chase contractors if "committed" >1 month, chase Willdan if pre-inspection >2–3 weeks, chase incentive checks for months after completion.
NYCA case work spans Salesforce (interactions, tasks, handoffs to finance/technical specialists) and Momentum (building data, scopes, projects with lifecycle phases). The two systems share no identifier; linkage is manual via street address.
Emily compiles a comprehensive quarterly report for Willdan by hand, including Momentum scope counts that C15 already sends Willdan separately. Ansa builds Excel forecasting charts manually. Chris built a "back-of-napkin" spreadsheet to model the 120K-ton GHG target, since rebuilt by Marc/Jon as a TAM model (segments × measures × penetration) — conclusion: efficiency alone can't reach the target; heat pumps are required. Marissa is standing up Power BI dashboards but hit Momentum's 2,000-record export limit.
Each new program launch involves recreating materials from scratch: the legacy ICF accelerator's documents were lost in vendor transition, QR codes are dead, and institutional knowledge (LL97 runbook, referral lists, escalation paths) lives in people's heads. Lisa (Willdan) maintains a Box-based launch inventory: call scripts, data dictionary, intake questionnaire, financing toolkit, email templates, Momentum runbooks.
Clustered by theme, ranked roughly by frequency × severity across the 7 months of transcripts.
A. Fragmented tracking and multi-system double entry — the dominant theme#
The same project update is entered two or three times (Excel + Monday.com + Momentum on AMEEP; Salesforce + Momentum + spreadsheets on NYCA; website sheet + engagement tracker + Momentum on HPD). Excel persists as a shadow system because of data-loss distrust: "too many times has data gone missing… we're not ever going to be in a position where we can't justify our work" (Emily). Daphany, plainly: "The more you can get my team off of spreadsheets, we will be forever grateful."
B. No automated follow-up; stalled work is invisible #
Warm leads are tracked by cell color in Excel; staleness is found by scanning by eye. "It'd be great if we could have Momentum automate some of those reminders instead of Jen having to search through her Excel spreadsheet" (Madeline). Non-responders ("I sent them a message back in April and they never replied" — Ivan) and stalled projects surface only when a human notices.
Address matching between Salesforce/HPD lists and Momentum fails routinely (dashes break lookup, opportunity names like "MFC LLC" carry no address, ~50 BIN mismatches on the HPD list, multi-BIN developments). The BBL→BIN transition is systemic: affordability and filing data are BBL-level. Public data is wrong in known ways: square footage excludes basements ("no building is ever 45,000 square feet"), heating systems are guessed (wrong on post-1990 buildings), Energy Star 100 scores signal bad data. Owners "shop around" between conflicting LL97 fine numbers from different sources.
Blocks scoping (can't recommend EMS if it's already installed — "you can't double-dip"), blocks readiness labels, and blocks the TAM model. DOB hasn't shared Article 321 compliance data, so KC3 must ask every owner what they've already done.
Viewpoint integration was descoped; KC3 waits on Willdan as middleman for the true status of its own projects. Pre-inspections sit 6 weeks instead of 2–3; NTPs/PIOLs delayed (National Grid budget exhaustion); incentive checks take "a couple weeks to a year" — "a project can be complete and then we're on ice for six months waiting for the incentive."
Every Q1 the team is "winging it" awaiting annual guidelines. Retired measures stayed selectable in Momentum; non-comp scopes showed comp rebate math; the auto comp/non-comp switch can silently shrink a payout. LL97 rules changed "literally every single day" under DOB, making the accelerator's own information stale. The ECP pathway collapse stranded already-funded scopes.
Technical Q&A to SWA was never logged; NIKA→AMEEP/HPD lead handoffs lack protocol; Salesforce task UX forces copy-paste navigation and out-of-band email replies; "stuff always falls through the cracks" when information relays through one person.
H. Contractor/service-provider quality and matching #
The legacy accelerator handed owners a 50-provider list — "you have no idea who to go to… that's where a lot of things ended up dropping off." Bad contractors stay on qualified lists, ghost buildings, refuse affordable housing, or bait-and-switch; there's no removal mechanism, no track record, no ratings. Owners can't validate quotes ($84K single-quote heat-pump conversion, "seems high") and boards demand case studies that don't exist.
Emailed scope links go "off into the ether" with zero engagement visibility. Advisors can't see scopes owners build themselves. Momentum's share emails bypass Salesforce, breaking the all-email-through-CRM assumption. No per-contact send history; bounce handling is manual.
"We're basically asking people to do projects that a lot of times don't pencil out." First-generation NYCA financing went unused. Affordable buildings hit the readiness wall: "do you have money? And the answer will be no." Incentive eligibility intelligence is fragmented — staff ask owners for data (prior incentives, LL87 audits) the program could look up itself.
Login chaos (Cloudflare codes, SSO confusion) marred the launch training and is a warning sign for owner self-service. Demos lag releases; no recorded trainings; weeks of use needed before a user knows what to ask. Self-service skepticism is explicit: overburdened owners "will just put in a ticket to get someone to talk to anyways."
Quarterly reports compiled manually, with data Willdan already receives elsewhere; export limits block BI; and the team can't track progress against the 120K-ton goal — "we're already behind. We need to be talking to these buildings."
1. Single-pipeline CRM with custom phases and staleness alerts(A, B)
One system of record for lead → outreach → intake → scoping → bidding → construction → closeout, with program-configurable phases (KC3 already defined them for AMEEP and HPD), time-in-stage timestamps, and automatic flags when an item exceeds its expected duration (committed >1 month, pre-inspection >3 weeks, no owner reply in 5 business days). Kills the color-coded-Excel scan and makes bottleneck analysis a report instead of a project.
2. Outreach campaign and follow-up engine(B, I)
Segmented sends from saved building cohorts, mail-merge personalization (named greeting, building-specific fine/measure hooks), per-contact send/open/reply history, automatic bounce handling, scheduled follow-up sequences, and a booking link in every touch. The HPD workflow (segment → BCC batch → Excel tracker → manual follow-up) becomes one screen.
3. Building identity resolution service(C)
A crosswalk of BBL ↔ BIN ↔ address variants ↔ HPD ID ↔ CRM record, with fuzzy matching plus a human QC queue for ambiguous matches (the "wrong adjacent building" fear). Handles multi-BIN developments as one entity. This is the prerequisite for any CRM↔building-data integration and for trustworthy reporting.
4. Measure-completion registry ("building work history")(D)
Structured capture of what's already been done — populated from intake answers, program completions, permit data, and owner self-report — surfaced as readiness labels ("50% of prescriptive list done") and used to suppress already-installed measures from recommendations. Directly unblocks scoping, double-dip prevention, and the TAM model.
5. Status bridge to program administrators(E)
Even without full Viewpoint integration: a structured status-request workflow (request → Willdan responds → status logged with timestamp) or a periodic status-file import. Eliminates the middleman email chase and creates an auditable delay record — useful leverage when pre-inspections sit for six weeks.
6. Versioned program-rules engine(F)
Incentive rates, measure eligibility, and pathway logic stored as dated versions with effective dates; retired measures auto-hidden; pathway selection always picks the higher payout, with a visible toggle and tooltip showing which pathway applied and why. A "rules changed" diff view for each annual update would end Q1 winging-it.
7. Tracked handoff and escalation objects(G)
First-class handoff records (NIKA→AMEEP, case manager→technical/finance SME, KC3→SWA) with source tags, owners, SLAs, and bidirectional reporting of counts. In-task reply threads so responses don't fork into email.
8. Service-provider quality layer(H)
SP profiles with verified project counts, measure mix, ratings/testimonials, license validity, and cross-checks against utility removal lists; an opt-in "dispatch" RFP mode (minimal building info to qualified SPs, first ~5 responders engage — Morissa's "Uber-style" idea, endorsed in-session); pricing benchmarks per measure (per-unit brackets) so advisors can sanity-check single quotes; and a case-study library to answer risk-averse boards.
9. Intake-to-system pipeline(A, I, K)
Web form writes directly into the CRM/building record (no intermediate spreadsheet), with a structured intake questionnaire (goals, completed measures, capital events, refi timing, existing SP relationships), self-bucketing prompts, automatic welcome email with scheduling link, and contact import for existing trackers.
10. Engagement-visible scope sharing(I) — share links report viewed/not-viewed; advisors get opt-in view access to owner-built scopes; outbound shares logged to the CRM. Fixes "off into the ether."
11. Data-confidence layer(C, K) — provenance and confidence shown per field (measured vs. inferred), anomaly auto-flags (sq ft below plausible floor, Energy Star = 100, post-1990 building with "guessed" steam), owner-verified overrides, and standard disclaimer language for advisor use. Anomalies double as outreach triggers.
12. Targeting workbench(B, L) — saved cohort collections per measure/segment (one-pipe steam Bronx, pre-1950 roofs, Mitchell-Lama, HDFC co-ops, near-2030 fines), auto-tag rules, assignment to outreach analysts with weekly quotas, sub-collections, and missing filters added (utility territory, flood zone, EUI).
13. Goal-vs-actual dashboard + open data feed(L) — GHG tonnage tracked against the 120K target by segment, pipeline conversion funnels, seasonality; uncapped exports or a direct feed (API/Metabase) for Power BI. Auto-generate the recurring numbers in quarterly reports.
14. AI triage assistant(B, G) — classify inbound inquiries against the known patterns (oil pre-war steam / quick-win EMS / capital-event trigger / bad data / out-of-scope / compliance confusion / board risk-aversion / tenant-driven / quote validation), attach the matching playbook, and route. The 05-27 session explicitly asked for this: "AI can pull out like these are the five or six patterns."
15. Incentive & financing intelligence(J) — a maintained catalog of programs with eligibility rules evaluated per building (auto-flag qualifying programs, including knockouts like >300 kW demand), prior-incentive history surfaced, and lender matching with knockout screening — so "do you have money?" becomes a navigable path rather than a dead end.
16. Knowledge base with freshness ownership(F, K) — LL97/program updates as a maintained feed with a named owner, short modular training videos auto-refreshed per release, and searchable runbooks — replacing lost-in-transition institutional memory.
Three patterns cut across everything. First, KC3's deepest pains are not feature gaps but integration gaps — every dataset, CRM, and admin back-end is an island, and KC3 staff are the human API between them. Identity resolution (#3) is the keystone: most other integrations depend on it. Second, the shadow Excel system is rational — it exists because of data-loss distrust and justify-our-work audit needs; any replacement must offer exports, history, and provenance before the spreadsheets will die. Third, the team repeatedly asks for proactivity — stalled-item flags, anomaly triggers, follow-up automation, activity-based outreach ("contact owners who built scopes but never reached out"). The current tooling is a lookup tool; what they describe needing is a system that taps them on the shoulder.
Strategy Notebook
KC3 Process Mining Report
Sources: 33 meeting transcripts, Nov 2025 – Jun 2026 (
kc3-transcripts/) Purpose: Inventory KC3's business processes, identify pain points, and propose feature ideas (platform-agnostic) for the most painful problems.1. Who KC3 Is and What They Run #
KC3 is a small (~10–15 person) NYC sustainability consultancy led by Daphany Rose Sanchez, specializing in outreach, technical assistance, and case management for affordable multifamily building decarbonization. They are matrix-managed, fully remote, and a Microsoft/SharePoint shop. They have no PE on staff and no CRM of their own — on every contract they use whatever software the prime provides.
Active programs #
Key people: Chris Rogers (NYCA + HPD lead), Claudette Pichardo (case mgmt), Nanda (outreach/intake), Ivan Ruiz (case manager, Willdan-side but works the advisor queue), Jennifer Maldonado (AMEEP non-comp), Emily Baumbach (AMEEP PM), Yangchen Dolma (analyst), Ansa Khan (outreach), Madeline Kostic (program ops), Marissa (new BI analyst, Power BI). C15/Cadence (Jon Braman, Bomee Jung, Marc Zuluaga, Jason Block) builds Momentum.
2. Business Process Inventory #
2.1 Outreach & lead generation #
List building and targeting. Staff build target lists from criteria (oil burners, one-pipe steam, C/D grades, high fines, flood zones) using Momentum advanced search plus their own Excel workbooks. Con Ed/Willdan stopped supplying eligible-customer lists years ago, so the team approximates utility territory by zip code. Building→owner/PM matching is done by hand via Property Shark and Who Owns What subscriptions.
Mass outreach (HPD 3-2-1 Go). Nanda segments the HPD list, sends batched BCC emails with HPD CC'd for legitimacy, and tracks sends/responses/bounces in an Excel tracker shared with HPD via SharePoint. Follow-up rounds are planned by bucket (oil buildings, near-2030 fines, co-ops, solar candidates). Response rates to generic mass email are very low (~750 sent, "a handful responded").
Campaigns (NYCA). Willdan's comms lead runs staggered re-engagement email campaigns (≤1,000/week), each requiring city approval.
2.2 Intake & triage #
NYCA inbound. Leads arrive via web form (auto-creates Salesforce Lead), call center, email, or Momentum signup. Staff manually convert Lead → Account/Contact/Opportunity, run a due-diligence lookup (legacy interaction history, Momentum building data, compliance pathway on the city CBL, affordability status), and route: refer out / self-service / KC3 queue (affordable) / Willdan queue (market rate).
Weekly triage. Ivan exports the Salesforce opportunity list as a PDF; Marc uses AI to convert opportunity names into addresses; they build a Momentum "Salesforce Inbound" collection sorted by fine size and spend ~3 min/building cross-checking data and deciding actions, logging back to Salesforce manually.
HPD intake. Website form → secondary spreadsheet → notification email to a shared inbox → manual scheduling → manual transfer into Momentum.
2.3 Scoping & advising #
Case managers find the building in Momentum (often resorting to asking the owner for the BBL because address matching fails), verify/correct inferred data (heating type, square footage), build a scope from suggested packages, and share it via link, PDF, or screen-share. On AMEEP, Jennifer builds comp (points-based) and non-comp (per-measure) incentive scopes and cross-checks them against utility fact sheets. After scoping, Momentum historically dropped out of the workflow entirely.
2.4 Contractor bidding / RFP #
Legacy process: confirm eligibility (~1 week) → email curated contractor lists → site surveys (~2-week turnaround) → bids → proposal to customer — all managed through email follow-ups, SharePoint folders, and Excel trackers. Now migrating to Momentum's RFP feature (e.g., the Wavecrest 50–60 building pipe-insulation portfolio): upload buildings via CSV, create scopes/projects, publish RFP with auto-generated bid forms, side-by-side bid comparison against Momentum's cost estimate.
2.5 Project tracking & case management #
AMEEP suffers triple entry: the same status update goes into Emily's master Excel, Willdan's Monday.com (coarse statuses, so detail lives in notes columns), and Momentum. True status lives in Willdan's Viewpoint/SMART systems, which KC3 cannot see — "Willdan is like the middleman for us to confirm statuses." Troubleshooting is reactive: scan trackers by eye, chase contractors if "committed" >1 month, chase Willdan if pre-inspection >2–3 weeks, chase incentive checks for months after completion.
NYCA case work spans Salesforce (interactions, tasks, handoffs to finance/technical specialists) and Momentum (building data, scopes, projects with lifecycle phases). The two systems share no identifier; linkage is manual via street address.
2.6 Reporting & program management #
Emily compiles a comprehensive quarterly report for Willdan by hand, including Momentum scope counts that C15 already sends Willdan separately. Ansa builds Excel forecasting charts manually. Chris built a "back-of-napkin" spreadsheet to model the 120K-ton GHG target, since rebuilt by Marc/Jon as a TAM model (segments × measures × penetration) — conclusion: efficiency alone can't reach the target; heat pumps are required. Marissa is standing up Power BI dashboards but hit Momentum's 2,000-record export limit.
2.7 Program setup & knowledge management #
Each new program launch involves recreating materials from scratch: the legacy ICF accelerator's documents were lost in vendor transition, QR codes are dead, and institutional knowledge (LL97 runbook, referral lists, escalation paths) lives in people's heads. Lisa (Willdan) maintains a Box-based launch inventory: call scripts, data dictionary, intake questionnaire, financing toolkit, email templates, Momentum runbooks.
3. Pain Points #
Clustered by theme, ranked roughly by frequency × severity across the 7 months of transcripts.
A. Fragmented tracking and multi-system double entry — the dominant theme #
The same project update is entered two or three times (Excel + Monday.com + Momentum on AMEEP; Salesforce + Momentum + spreadsheets on NYCA; website sheet + engagement tracker + Momentum on HPD). Excel persists as a shadow system because of data-loss distrust: "too many times has data gone missing… we're not ever going to be in a position where we can't justify our work" (Emily). Daphany, plainly: "The more you can get my team off of spreadsheets, we will be forever grateful."
B. No automated follow-up; stalled work is invisible #
Warm leads are tracked by cell color in Excel; staleness is found by scanning by eye. "It'd be great if we could have Momentum automate some of those reminders instead of Jen having to search through her Excel spreadsheet" (Madeline). Non-responders ("I sent them a message back in April and they never replied" — Ivan) and stalled projects surface only when a human notices.
C. Building identity and data quality #
Address matching between Salesforce/HPD lists and Momentum fails routinely (dashes break lookup, opportunity names like "MFC LLC" carry no address, ~50 BIN mismatches on the HPD list, multi-BIN developments). The BBL→BIN transition is systemic: affordability and filing data are BBL-level. Public data is wrong in known ways: square footage excludes basements ("no building is ever 45,000 square feet"), heating systems are guessed (wrong on post-1990 buildings), Energy Star 100 scores signal bad data. Owners "shop around" between conflicting LL97 fine numbers from different sources.
D. No record of measures already completed #
Blocks scoping (can't recommend EMS if it's already installed — "you can't double-dip"), blocks readiness labels, and blocks the TAM model. DOB hasn't shared Article 321 compliance data, so KC3 must ask every owner what they've already done.
E. Upstream status opacity #
Viewpoint integration was descoped; KC3 waits on Willdan as middleman for the true status of its own projects. Pre-inspections sit 6 weeks instead of 2–3; NTPs/PIOLs delayed (National Grid budget exhaustion); incentive checks take "a couple weeks to a year" — "a project can be complete and then we're on ice for six months waiting for the incentive."
F. Program-rule churn outruns the tooling #
Every Q1 the team is "winging it" awaiting annual guidelines. Retired measures stayed selectable in Momentum; non-comp scopes showed comp rebate math; the auto comp/non-comp switch can silently shrink a payout. LL97 rules changed "literally every single day" under DOB, making the accelerator's own information stale. The ECP pathway collapse stranded already-funded scopes.
G. Handoffs and escalations are untracked #
Technical Q&A to SWA was never logged; NIKA→AMEEP/HPD lead handoffs lack protocol; Salesforce task UX forces copy-paste navigation and out-of-band email replies; "stuff always falls through the cracks" when information relays through one person.
H. Contractor/service-provider quality and matching #
The legacy accelerator handed owners a 50-provider list — "you have no idea who to go to… that's where a lot of things ended up dropping off." Bad contractors stay on qualified lists, ghost buildings, refuse affordable housing, or bait-and-switch; there's no removal mechanism, no track record, no ratings. Owners can't validate quotes ($84K single-quote heat-pump conversion, "seems high") and boards demand case studies that don't exist.
I. Communications happen outside any system #
Emailed scope links go "off into the ether" with zero engagement visibility. Advisors can't see scopes owners build themselves. Momentum's share emails bypass Salesforce, breaking the all-email-through-CRM assumption. No per-contact send history; bounce handling is manual.
J. Financing is the project killer #
"We're basically asking people to do projects that a lot of times don't pencil out." First-generation NYCA financing went unused. Affordable buildings hit the readiness wall: "do you have money? And the answer will be no." Incentive eligibility intelligence is fragmented — staff ask owners for data (prior incentives, LL87 audits) the program could look up itself.
K. Adoption, training, and onboarding friction #
Login chaos (Cloudflare codes, SSO confusion) marred the launch training and is a warning sign for owner self-service. Demos lag releases; no recorded trainings; weeks of use needed before a user knows what to ask. Self-service skepticism is explicit: overburdened owners "will just put in a ticket to get someone to talk to anyways."
L. Reporting burden and goal anxiety #
Quarterly reports compiled manually, with data Willdan already receives elsewhere; export limits block BI; and the team can't track progress against the 120K-ton goal — "we're already behind. We need to be talking to these buildings."
4. Feature Ideas #
Platform-agnostic; each maps to the pain clusters above. Ordered by expected impact.
Tier 1 — attack the dominant pain #
1. Single-pipeline CRM with custom phases and staleness alerts (A, B) One system of record for lead → outreach → intake → scoping → bidding → construction → closeout, with program-configurable phases (KC3 already defined them for AMEEP and HPD), time-in-stage timestamps, and automatic flags when an item exceeds its expected duration (committed >1 month, pre-inspection >3 weeks, no owner reply in 5 business days). Kills the color-coded-Excel scan and makes bottleneck analysis a report instead of a project.
2. Outreach campaign and follow-up engine (B, I) Segmented sends from saved building cohorts, mail-merge personalization (named greeting, building-specific fine/measure hooks), per-contact send/open/reply history, automatic bounce handling, scheduled follow-up sequences, and a booking link in every touch. The HPD workflow (segment → BCC batch → Excel tracker → manual follow-up) becomes one screen.
3. Building identity resolution service (C) A crosswalk of BBL ↔ BIN ↔ address variants ↔ HPD ID ↔ CRM record, with fuzzy matching plus a human QC queue for ambiguous matches (the "wrong adjacent building" fear). Handles multi-BIN developments as one entity. This is the prerequisite for any CRM↔building-data integration and for trustworthy reporting.
4. Measure-completion registry ("building work history") (D) Structured capture of what's already been done — populated from intake answers, program completions, permit data, and owner self-report — surfaced as readiness labels ("50% of prescriptive list done") and used to suppress already-installed measures from recommendations. Directly unblocks scoping, double-dip prevention, and the TAM model.
Tier 2 — high value, clear demand #
5. Status bridge to program administrators (E) Even without full Viewpoint integration: a structured status-request workflow (request → Willdan responds → status logged with timestamp) or a periodic status-file import. Eliminates the middleman email chase and creates an auditable delay record — useful leverage when pre-inspections sit for six weeks.
6. Versioned program-rules engine (F) Incentive rates, measure eligibility, and pathway logic stored as dated versions with effective dates; retired measures auto-hidden; pathway selection always picks the higher payout, with a visible toggle and tooltip showing which pathway applied and why. A "rules changed" diff view for each annual update would end Q1 winging-it.
7. Tracked handoff and escalation objects (G) First-class handoff records (NIKA→AMEEP, case manager→technical/finance SME, KC3→SWA) with source tags, owners, SLAs, and bidirectional reporting of counts. In-task reply threads so responses don't fork into email.
8. Service-provider quality layer (H) SP profiles with verified project counts, measure mix, ratings/testimonials, license validity, and cross-checks against utility removal lists; an opt-in "dispatch" RFP mode (minimal building info to qualified SPs, first ~5 responders engage — Morissa's "Uber-style" idea, endorsed in-session); pricing benchmarks per measure (per-unit brackets) so advisors can sanity-check single quotes; and a case-study library to answer risk-averse boards.
9. Intake-to-system pipeline (A, I, K) Web form writes directly into the CRM/building record (no intermediate spreadsheet), with a structured intake questionnaire (goals, completed measures, capital events, refi timing, existing SP relationships), self-bucketing prompts, automatic welcome email with scheduling link, and contact import for existing trackers.
Tier 3 — strong supporting features #
10. Engagement-visible scope sharing (I) — share links report viewed/not-viewed; advisors get opt-in view access to owner-built scopes; outbound shares logged to the CRM. Fixes "off into the ether."
11. Data-confidence layer (C, K) — provenance and confidence shown per field (measured vs. inferred), anomaly auto-flags (sq ft below plausible floor, Energy Star = 100, post-1990 building with "guessed" steam), owner-verified overrides, and standard disclaimer language for advisor use. Anomalies double as outreach triggers.
12. Targeting workbench (B, L) — saved cohort collections per measure/segment (one-pipe steam Bronx, pre-1950 roofs, Mitchell-Lama, HDFC co-ops, near-2030 fines), auto-tag rules, assignment to outreach analysts with weekly quotas, sub-collections, and missing filters added (utility territory, flood zone, EUI).
13. Goal-vs-actual dashboard + open data feed (L) — GHG tonnage tracked against the 120K target by segment, pipeline conversion funnels, seasonality; uncapped exports or a direct feed (API/Metabase) for Power BI. Auto-generate the recurring numbers in quarterly reports.
14. AI triage assistant (B, G) — classify inbound inquiries against the known patterns (oil pre-war steam / quick-win EMS / capital-event trigger / bad data / out-of-scope / compliance confusion / board risk-aversion / tenant-driven / quote validation), attach the matching playbook, and route. The 05-27 session explicitly asked for this: "AI can pull out like these are the five or six patterns."
15. Incentive & financing intelligence (J) — a maintained catalog of programs with eligibility rules evaluated per building (auto-flag qualifying programs, including knockouts like >300 kW demand), prior-incentive history surfaced, and lender matching with knockout screening — so "do you have money?" becomes a navigable path rather than a dead end.
16. Knowledge base with freshness ownership (F, K) — LL97/program updates as a maintained feed with a named owner, short modular training videos auto-refreshed per release, and searchable runbooks — replacing lost-in-transition institutional memory.
5. Observations #
Three patterns cut across everything. First, KC3's deepest pains are not feature gaps but integration gaps — every dataset, CRM, and admin back-end is an island, and KC3 staff are the human API between them. Identity resolution (#3) is the keystone: most other integrations depend on it. Second, the shadow Excel system is rational — it exists because of data-loss distrust and justify-our-work audit needs; any replacement must offer exports, history, and provenance before the spreadsheets will die. Third, the team repeatedly asks for proactivity — stalled-item flags, anomaly triggers, follow-up automation, activity-based outreach ("contact owners who built scopes but never reached out"). The current tooling is a lookup tool; what they describe needing is a system that taps them on the shoulder.
Appendix: Source Transcripts #
33 files in
gitlocal/momentum/claude-working-files/kc3-transcripts/, 2025-11-24 through 2026-06-09. Highest-density sources:2026-01-13-Momentum-Workflow.md(AMEEP workflow),2026-02-17Sections 4–5 (case management & SP program design),2026-03-05-AMEEP-workflow-workshop.md,2026-03-25/03-31case-management design,2026-04-01Account Manager Q&A + Cadence TB,2026-04-09-NYCA-Launch-Training.md,2026-05-27-NYCA-Triage-Pattern-Identification-part-2.md.