Skip to content
FCR Dashboard Docs

SayMore Engagement Programme — Hub & Monthly Refresh

The SayMore engagement hub (quick.fcrinsights.ie/saymore) is the internal home for growing engagement across the managed SayMore estate — the population, the action lists (the “plays”), and the supporting data. It is regenerated each month by the /saymore-refresh skill so every page reconciles to one baseline.

The baseline

Section titled “The baseline”

Everything is a slice of 1,947 active SayMore accounts — the denominator the whole hub reconciles to.

SegmentN
Yext managed estate~1,996
— on a current SayMore billing line (current_saymore)1,592
— SayMore via Yext, grandfathered, no billing line (via_yext)355
— orphan / status-check (excluded)49
Active SayMore (baseline)1,947
— Ultimate (review-response entitlement)452

Classifier (“353 method”): baseline = present in v_subscriber_mrr ∪ active_clients; a PMS billing line (SayMore or SnapSync) ⇒ current_saymore; has MRR but no PMS line ⇒ via_yext; in neither ⇒ orphan. Source of truth for the estate + Ultimate is the Yext Active Services export, not the order system (the order under-counts Ultimate ~61%).

The plays (action lists)

Section titled “The plays (action lists)”
PlayNOwnerPage
Review-response activation123CS/saymore-ultimate-activation
Upsell to Ultimate952 (366 warm)AM/saymore-ultimate-upsell
Licence transfer (free, unused Ultimate)137AM/saymore-licence-transfer
App onboarding (content hook, net of already-onboarded)1,415CS/saymore-app-onboarding

Ownership rule: CS run activation / engagement / onboarding on the AM’s behalf. AM own the commercial sell (upsell + licence transfer). CS do not upsell.

Narrative + data pages: decision-brief · engagement-plan · order↔Yext recon · Ultimate base · CS/AM plays · GMB & Yext roster (pms-gmb-stats).

The monthly refresh (/saymore-refresh)

Section titled “The monthly refresh (/saymore-refresh)”

One command regenerates the whole hub (12 pages) + the backing CSVs. Skill: .claude/skills/saymore-refresh/SKILL.md; pipeline: scripts/saymore-refresh/.

node scripts/saymore-refresh/run.cjs --pings <kibana-events.csv> \
     [--refresh-roster] [--refresh-reviews] [--publish]

Default is a dry-run (writes CSVs + build/ pages + the verify gate, no publish); --publish goes live. Stages: 00-population → 01-cohorts → 01b-onboarding → 01c-reviews-refresh → 01d-pms-roster → 02-render/02b-narrative → 03-verify.

Inputs (manual until automated):

  • Yext Active Services export (~/Downloads/activeservices_*.csv) — drives the population + the four Ultimate cohorts.
  • Kibana pings EVENTS export (--pings) — the in-app usage feed for the onboarding exclusion. Feed the Discover events export (has email_address), not the “Top Subscribers” page-view rollup.

Monthly order: the onboarding hooks read the GMB+Yext roster (SayMore_PMS_Master.csv), so run --refresh-roster (rebuilds the roster) and --refresh-reviews (current review counts) before publishing.

Data sources & the GMB-feed caveat

Section titled “Data sources & the GMB-feed caveat”
SignalSource
Population / Ultimate / ProfessionalYext Active Services export
MRR · account/AM/CS · productsv_subscriber_mrr · active_clients · v_saymore_program_universe
Reviews (all-time + 90d) + responsesv_gmb_reviews_latest + GMB shards — see caveat
Posts (90d)GMB_LOCALPOSTS_* (union of last 3 shards, deduped) — see caveat
Gallery photos + connected socialYext entities API (lib/yext.cjs)
App usage (onboarded vs not)Kibana saymore-analytics-pings export

⚠ The GMB feeds are stale/broken upstream — not a Superset or query problem:

  • Reviews: the core GMB_REVIEWS_* ingestion runs on schedule but has written 0 rows since 2026-04-15 (empty May/June shards). v_gmb_reviews_latest silently self-heals to the last populated shard via MAX(_TABLE_SUFFIX), so the staleness is invisible. Workaround: 01c-reviews-refresh backfills the gap via SerpApi (google_maps_reviews, newest-first, real iso_date) and captures the all-time count + rating from the free SerpApi archive — giving current reviews_last_90d and account-facing review counts. The durable fix is repairing the upstream reviews ingestion.
  • Posts: GMB_LOCALPOSTS_* is stale to ~2026-05-08. Posts are ephemeral, so the roster unions the last 3 shards and reports posting data-anchored to the feed’s last sync (“posts as of …”), not to today — a today-anchored window would falsely read as a posting decline.

Customer-self vs CS-assisted: in the pings, @fcrmedia.ie logins on a real account are CS-assisted (CS acting for the client), kept separate from the client’s own use. “Already onboarded” = customer-self only; CS-only accounts stay in the onboarding target (flagged CS-aware). login pings carry no subscriber_id — attribute by page-view/action.

Section titled “Related”
  • Skill runbook (operational detail): .claude/skills/saymore-refresh/SKILL.md
  • Listings (SnapSync / SayMore) deep dives: see Product Deep Dives
  • Pings API spec (the dependency for full automation): SAYMORE_PINGS_API_DEV_SPEC_2026-06-19.md
Ask the docsRAG over this site
Ask anything about the FCR Dashboard platform — architecture, BigQuery, the worker routes, billing rules, the LRC stack, scoring… Answers are grounded in this documentation, with source links.
How does the deal-brief refresh work? Which routes are Worker vs n8n? How is account health scored?