beantownbabeandClaude Sonnet 5
95eac39434
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>
3.2 KiB
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.