Skip to content

Competitor & Influencer Monitoring System — Design Handoff

Date: 2026-07-27 Status: Design agreed, not yet built Purpose: Portable spec for an automated monitoring system that watches competitors, industry publications and influencers, then surfaces content opportunities for approval.

This document is self-contained. It was written in the legacy VoiceNut marketing repo and is meant to be copied into the current Vibe Marketing repo. It deliberately contains no relative links to the old repo — where it refers to project documents (brand voice, positioning, ICPs), substitute the equivalents in the new repo.

1. The Problem Being Solved

Monitor suppliers, competitors and key influencers in the wealth-management-AI space — their social posts, blogs, newsletters and websites. When something relevant appears, get a summary plus an assessment of whether it's a topic Dean should have a public view on. Approved topics become briefs for a contract writer.

Key constraint discovered during design: Dean approves content; a contractor writes it. So the output is not a reading list — it is a decision queue that produces contractor-ready briefs.

2. The Core Architectural Decision

Do not let the LLM do the polling. Split the system in two:

Layer Runs Cost Job
Collector (deterministic script) Often ~0 Fetch sources → diff against seen-store → emit only genuinely-new items
Judge (Claude) Only when the collector finds something Low Score relevance against positioning, propose an angle, draft a hook

Pointing an LLM straight at websites produces duplicate reports, missed items, hallucinated posts and real cost. The seen-store is what makes the system trustworthy.

Collector (scheduled)  →  New-items queue  →  Claude judge  →  Digest + email
  RSS + page-diff          state.json          reads brand voice,   INBOX.md
  + Google News RSS        (URL/content         positioning, ICPs   + daily email
                            hashes)

3. Hosting Decision: Azure Pipelines

Chosen: Azure Pipelines scheduled job.

The repo is a git repo hosted on Azure DevOps Repos (dev.azure.com/nutcracker2/AIMarketing/_git/...). A pipeline runs inside a checkout of the repo, so the seen-store and digest markdown are just files it commits and pushes. The repo is the database — no storage account, no Azure DevOps REST API plumbing, no container to keep alive.

schedules:
  - cron: "30 4 * * *"        # 06:30 SAST — daily digest
    branches: { include: [master] }
    always: true

Script step → git commit && git push. Secrets as pipeline variables. Microsoft-hosted agents include 1,800 free minutes/month; this job uses roughly one per run.

Alternatives considered and why they lost

  • Azure Function (timer trigger). Better for sub-minute latency or an HTTP surface — neither is needed. Would require pushing markdown back through the Azure DevOps REST API, pure overhead versus a checkout. Becomes the right answer when you want one-click approve/reject links in the email (see §7). Plan it as v2, not v1.
  • n8n in Docker (local). n8n earns its keep when you need dozens of SaaS connectors you don't want to code. This integration surface is narrow — RSS, HTTP, Claude, SMTP, git — and in code it's diffable, testable and reviewable rather than JSON in a browser UI. It also needs an always-on host, at which point the pipeline is free and already in the ecosystem.
  • GitHub Actions. Not applicable — repo is on Azure DevOps, not GitHub. Azure Pipelines is the equivalent mechanism.

Caveat to handle first

Azure DevOps private projects require a one-off free-parallelism grant request from Microsoft before hosted agents will run (typically a couple of days' turnaround). If you don't want to wait, register a self-hosted agent on any always-on machine — works immediately.

4. Cadence Decision: Daily Digest + Tripwire

The original ask was 4–5 checks per day; the delivery preference is a daily email. These reconcile as two pipelines:

Pipeline Schedule Behaviour
Daily digest 06:30 SAST Full sweep of all sources, writes markdown, sends the one email
Tripwire Every 4 hours Tier-1 triggers only — competitor pricing-page diffs, funding keywords in Google News, competitor product-page changes. Silent unless it fires.

Rationale: across ~20 sources in this niche, genuinely new items appear maybe 5–10 times per week. Four digests a day trains you to ignore them. This gives one predictable email plus same-day alerting on things that actually matter (e.g. a competitor dropping UK pricing).

5. Sources — Three Tiers

Tier A — RSS / feeds (free, covers ~80% of what matters)

Competitors (verify feed URLs — not all confirmed to expose RSS): - Jump — jump.ai (blog + the pre-meeting-prep product page) - Zocks — zocks.io (blog + /press) - Zeplyn — zeplyn.ai - Marloo — marloo.com (UK/US — highest-priority for UK go-to-market) - Practifi — practifi.com (CRM bundling threat) - Vestmark — vestmark.com/press-releases

Industry commentary / influencers: - Kitces.com — the single highest-signal source in the space - WealthManagement.com - WealthTech Today - XY Planning Network advisor blog

UK: Citywire, Money Marketing, FTAdviser SA: Moneyweb

Underrated free source — Google News RSS. Gives funding rounds, launches and press coverage with zero scraping: 

https://news.google.com/rss/search?q="Zocks"+OR+"Zeplyn"+advisor
Substack and beehiiv newsletters all expose /feed.

Tier B — No feed, monitor by diffing

Fetch → strip boilerplate → hash → compare. This is where the highest-value competitive intel lives: - Competitor pricing pages (Marloo publishes $99/adviser/month; Zeplyn ~$60–120/seat/month) - Product pages (Jump's pre-meeting-prep page changing matters more than any blog post) - Changelogs - Careers pages — a competitor hiring a UK salesperson is a strategic signal

Tier C — LinkedIn and X (be realistic)

LinkedIn has no API for reading other people's posts, and direct scraping violates their ToS and gets accounts restricted. Do not build a LinkedIn scraper. Options in order of preference:

  1. A third-party feed service (RSS.app, Fetchrss) producing RSS from public company pages — ~$10–40/month, and they carry the operational risk
  2. Google Alerts scoped to site:linkedin.com
  3. Accept that founders repost substantive content to a blog or newsletter you can watch legitimately

X now requires a paid API tier for anything useful.

Recommendation: ship Tiers A and B first. Add Tier C via a paid feed service only once the digests prove worth reading.

6. The Relevance Filter — The Actual Differentiator

Generic tools (Feedly et al.) tell you what happened. The value here is "does this touch my positioning, and do I have a contrarian take?" — which only works because the judge reads the project's own strategy documents: brand voice profile, positioning canvas, ICP definitions, and the competitive landscape analysis.

Per-item output: - Two-line summary - Relevance score 1–5 with reasoning (competitor claim / market signal / content angle / noise) - The angle — most often the systems-first vs transcript-first counter-position, an SA or UK spin, or an explicit "no view, skip" - A drafted hook in Dean's voice, so it's judgeable in three seconds

Only surface 3+. Everything else lands in a rolling log that's never read unless wanted.

Positioning context the judge must carry

  • Retired framing: "meeting prep is an overlooked problem nobody is addressing." As of mid-2026 this is demonstrably false and signals a lack of homework.
  • Live differentiation: competitors build prep primarily from meetings they recorded, so their output is thin until the advisor has months of history in their tool. The counter is prep synthesised from the advisor's existing systems — full value in week one.
  • Whitespace: South Africa (effectively untouched), UK (contested by Marloo but not saturated), and the solo/small price band as incumbents drift enterprise.

7. Output Shape — Built Around the Approval Workflow

research/monitoring/
  sources.yaml              # the watchlist
  state.json                # seen-hashes, committed each run
  INBOX.md                  # needs-your-call items, with checkboxes
  archive/2026-07-27.md     # daily digest snapshots
content/briefs/             # approved items become contractor briefs

The loop:

  1. Email lands at 06:30 with 1–3 candidates — what happened, why it touches the positioning, the angle, a drafted hook
  2. Dean ticks - [x] on the items worth pursuing in INBOX.md and pushes
  3. Next pipeline run detects checked items and expands each into a full brief in content/briefs/ — angle, key points, source links, voice constraints pulled from the brand voice and positioning docs
  4. The contract writer works from the brief

Git is the workflow engine; there is no UI to build.

Upgrade path: if ticking a checkbox in a file is too much friction, that is precisely the justification for the Azure Function — approve/reject URLs embedded in the email, function commits the decision. Do this only after the digest proves useful.

8. Two Implementation Details That Decide Whether This Works

Two-stage judging. Route every new item through a cheap model (Haiku) for relevance scoring against the ICPs and positioning — high volume, low cost. Only 3+ scorers go to Opus for the angle and hook. Keeps running cost in the low single-digit dollars per month rather than tens.

Strip boilerplate before hashing. Naive HTML hashing on Tier-B pages fires on every rotating testimonial and CSRF token. Extract the main content node, normalise whitespace, then hash. Otherwise you get a "Jump changed their pricing page" alert every single day and stop trusting the system — which kills it.

9. Build Order

  1. Request the Azure DevOps free-parallelism grant (do this first — it has a lead time)
  2. sources.yaml seeded with the competitor and publication list in §5, Tiers A and B only
  3. Collector script — fetch, boilerplate-strip, hash, diff against state.json, emit new-items queue
  4. Two-stage judge prompt, carrying the positioning context from §6
  5. Digest template (INBOX.md) and contractor brief template (content/briefs/)
  6. Two pipeline YAMLs — daily digest and tripwire
  7. Fill in secrets: Anthropic API key, SMTP or Resend/SendGrid/Azure Communication Services credentials
  8. Confirm the source list, then first run

Deferred to v2: Tier C social monitoring via paid feed service; Azure Function with one-click approve/reject.

10. Open Items

  • [ ] Verify which competitor sites actually expose RSS (assumed, not confirmed)
  • [ ] Decide email transport — Resend, SendGrid, or Azure Communication Services
  • [ ] Confirm the influencer list beyond publications — named individuals to watch were never enumerated
  • [ ] Confirm SAST vs UTC for the cron expressions (Azure Pipelines cron is UTC; 30 4 = 06:30 SAST)
  • [ ] Decide whether the monitoring folders live in the marketing repo or a separate one

Appendix: Prompt to Resume This Work in the New Repo

I want to build the competitor/influencer monitoring system described in MONITORING-SYSTEM-HANDOFF.md. Read that file first. Start at build step 2 — scaffold sources.yaml, the collector, the two-stage judge prompt, the digest and brief templates, and both Azure Pipelines YAMLs. Use the brand voice, positioning and ICP documents in this repo for the relevance filter context. Leave secrets as placeholders and let me confirm the source list before the first run.