0 Fork 0

Files

T

beantownbabeandClaude Sonnet 5 95eac39434 Build out CRM Research: Requirements and Pricing pages, click-to-toggle info badges

From the CRM Research session: replaces the plain comparison table with a
richer one (origin, catch column), adds a full Requirements page (must-have/
nice-to-have, other names looked at, sources) and a new Pricing page,
following the same hero-nav + drill-view pattern as Marketing/Sales. Adds
click-triggered info-badge popovers for contested/unverified facts (Zoho's
EU/DPA tier, Capsule's IMAP support, etc.), replicating the info_popover()
pattern from linkedin_analytics as vanilla JS since this dash has no Dash
runtime. Also adds CRM_Research_README.md documenting the whole section,
and tracks CRM_Research_Notes.md's latest revisions.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-08-17 22:12:50 +02:00

3.2 KiB

Raw Blame History

CRM Research

Research into what CRM (if any) TXproducts should get — requirements first, no product chosen yet. Lives in the Sales & Marketing dash's CRM Research tab (localhost:8500), as a sixth sidebar section below a divider, separate from the five main department branches.

Where it lives

Unlike Opportunities (see ../opportunities/README.md), this section is authored directly inside index.html, not fetched as its own module. It's a three-view drill-down under #tab-crm-research, using the same shared DRILL_CONFIG / setDrillView machinery as Marketing and Sales:

CRM Research (crm-root, the default view) — the main candidate comparison table: 8 non-US vendors, checked against CSV import, sales pipeline, generic IMAP/SMTP, EU hosting/GDPR, self-hosting, and cost.
Requirements (notes, reached via the hero-bar "Requirements" pill) — the full must-have/nice-to-have list, "other names looked at" but not fully checked, and sources.
Pricing (pricing, reached via the hero-bar "Pricing" pill) — cost and free-tier status only, pulled from the same survey.

address_book/CRM_Research_Notes.md is the underlying research doc these views are built from — same data, fuller prose reasoning per candidate. It isn't linked from the page anymore (all its content now lives inline in the tabs above); it stays as the working notes file for whoever continues this research.

Why non-US vendors only

TXproducts requires a signed EU DPA and wants to avoid US corporate/legal exposure (not just data-center location) — so any US-headquartered or US-owned vendor is excluded from the survey entirely, not just flagged. See CRM_Research_Notes.md for the full reasoning on each candidate's corporate origin.

Caveats: click-triggered info badges, not hover tooltips

A handful of facts in the tables are contested, unverified, or need a live vendor check (e.g. Zoho's EU/DPA tier requirement, Capsule's IMAP support, EspoCRM's inconsistent cloud pricing). These show as a yellow "?" badge next to the relevant CRM's name or page title — click to open a popover, click elsewhere to close it.

This is the same pattern already used in ~/Documents/linkedin_analytics/ (the info_popover() helper in app.py, replicated as vanilla JS/CSS here since this dash has no Dash/React runtime): .crm-info-badge is the yellow circle, .crm-popover is the popup, and crmTogglePopover() in index.html wires them together. Deliberately not the native HTML title attribute — that has a slow, OS-controlled hover delay; this opens instantly on click.

To add a new caveat: add a badge (<span class="crm-info-badge" id="crm-info-X" onclick="crmTogglePopover(this)">?</span>) next to whatever it's about, and a matching <div class="crm-popover" data-target="crm-info-X">...</div> anywhere inside the same drill-view.

Updating the data

No build step — the candidate tables are plain HTML directly in index.html, hand-maintained alongside CRM_Research_Notes.md. When a candidate's status changes (e.g. a live trial resolves one of the "unclear" marks), update both: the relevant <td> in whichever view(s) show that candidate, and the corresponding row in CRM_Research_Notes.md.

3.2 KiB Raw Blame History