John Zebell III

Revenue Operations · GTM Systems & Integrations · AI Automation

I build the systems
revenue teams run on.

CRM architecture, lead lifecycle, routing, reporting, and the AI workflows that take the manual grind out of them. I build for the failure case first, because the way these systems break is quietly: the workflow reports success, the report still runs, and the number is wrong. Every build below shows the live wiring next to a plain-language map of how it runs.

Denver, Colorado· Remote· johnzeb22@gmail.com
HubSpot Revenue Operations Certified HubSpot Marketing Hub Software Certified HubSpot Reporting Certified SQL Certified, HackerRank

Selected builds

Purview Ops

Full stack · site, intake pipeline, assistant, verification · Next.js + Supabase + n8n + Claude

Problem

A revenue operations practice that argues systems fail quietly has to prove it on its own property. Every part of this had to capture before it called out, fail loudly when it broke, and be checkable from outside.

What I built

Six pages on Next.js, a form that writes capture-first to Postgres before any external call, a Discord notifier that fires only after the row exists, and a site assistant running through n8n with structured output and full conversation logging. Every external call has its own error path.

Result

A submission survives a database outage, a model timeout, or a failed notification, because the record is written before any of them run. Failures return a real error rather than a success the visitor can’t act on. Live at purviewops.com.

How it runs
Purview intake flow Form three fields Capture first row written Notify after the row Real error on fail never a false ok The write happens before anything that can fail. Everything after it is recoverable.

The order is the point. A provider timeout, a failed notification, or a model error all happen after the record already exists.

The build

Next.js on Vercel, statically prerendered, no client JS beyond the assistant. Postgres on Supabase with row level security and no policies, so the table is unreachable except through a server-side key. The assistant runs through n8n with a structured output schema, so the classification it returns is one of four values rather than prose that has to be parsed. Both sides of every conversation are logged, including the ones where the model call failed.

Visit the site

Lead Generation Engine

Go-to-market · end-to-end sourcing, enrichment, scoring & sync · n8n + Apollo + ZeroBounce + GHL + Airtable

Problem

A form fill is not a qualified lead. It is only worth acting on if it is real, reachable, and ranked. Most intake skips that work, so junk contacts flood the CRM, reps chase bad emails, and nobody knows which lead is actually worth a call. The qualification has to happen before anything hits the CRM, not after.

What I built

An eight-stage pipeline that takes an inbound form submission and turns it into a verified, scored, CRM-ready lead. It matches the lead to its campaign, enriches it through a per-campaign configurable path (Apollo, UpLead, or both), dedups, verifies the email, scores and grades on firmographics and reachability, assigns outreach sequences, and only then syncs the clean record to the CRM. It finishes with an AI mini-audit that scrapes the prospect’s site, checks their visibility, and drafts a personalized email.

Result

Only verified, scored, routed leads reach the CRM, so the data layer stays clean by design. Ran live, and the same enrichment-and-scoring architecture also handled standalone lead sourcing at volume. Each stage logs a summary, so a failure surfaces instead of silently dropping leads.

How it runs
Lead Generation Engine flow Form + enrich per-campaign Verify ZeroBounce Score + route grade & segment Sequence assign + sync Sync + audit CRM + AI report

A form fill comes in, gets enriched per its campaign, and only reaches the CRM once it is verified and scored. The sync is deliberately last.

The build

Eight connected n8n workflows. A form submission is matched to its campaign and enriched on a configurable path, then verification, scoring, audience-building, sequencing, CRM sync, partner qualification, and an AI mini-audit each run as their own stage.

View the n8n wiring

Event Lead-Capture & Nurture System

Two verticals · capture, consent, routing, nurture, reporting · GoHighLevel

107
Leads captured live
81
Email opt-ins
29
Discovery-call requests

Problem

A wellness and medical-tourism business captured leads at events but had no system behind it. Leads sat unworked, attribution was lost, and value stalled at the entry stage. The constraint was conversion infrastructure, not lead volume.

What I built

An end-to-end capture and nurture system across two isolated sub-accounts: QR-to-form intake, standalone email-consent gating with DND suppression, interest-based routing into vertical pipelines, a discovery-call branch for high-intent leads, multi-email nurture sequences, and live dashboards with smart lists for attribution.

Result

Live at a single 2,500-person event. 107 leads captured without losing one, 81 opted in to email marketing, and 29 requested a discovery call, routed to a closer in real time. Built and debugged solo, in three days, on two days notice.

How it runs
Event lead-capture and nurture system Capture, consent gate, route, nurture Event QR scan vertical-specific landing form Capture workflow event tag, lead source stamped Consent gate opt-in checkbox checked? unchecked checked Enable DND no nurture, captured only Email Opt In tag enters nurture track Interest routing into correct vertical pipeline Nurture sequence staggered multi-email drip High-intent branch Discovery-call requested wants-call tag, routed to closer in real time Why the consent gate matters Only opted-in leads enter nurture. Captured-but-unconsented leads are held under DND, so the system stays compliant while still recording every lead for attribution. Two verticals, one architecture The same capture, consent, routing, and reporting pattern runs in two isolated sub-accounts, so each vertical stays clean and nothing cross-contaminates.
Live results
Event capture results Captured at one live event Total leads 107 Consented to email 81 Discovery-call requests 29 Consent split Opted in — 81 26 Captured live, consent-gated, tagged, routed into pipelines, and surfaced on dashboards in real time. Two verticals, isolated sub-accounts.

Real figures from a single live event. Counts only, and each one is what the system recorded.

View the full case study

Medical Knowledge Base Generator

Content ops · AI generation with compliance gating & self-testing · n8n + Claude + Postgres

Problem

Building a medical knowledge base by hand is slow and risky. A paid specialist wrote cards one at a time, and nothing checked whether an answer was actually supported by its source before it went live.

What I built

An eight-stage pipeline that generates cards across three content types, runs every one through a compliance auditor, then tests its own output: a separate model answers questions from each card and a judge scores those answers against the source. Only cards that clear the threshold auto-publish.

Result

Publication was gated at an 80% pass threshold and 95% of cards cleared it, so roughly 5% routed to manual review rather than shipping. The work replaced a paid outside specialist. Anything flagged unsafe never publishes.

How it runs
Medical Knowledge Base Generator pipeline GENERATE Medications FAQs Workflows Compliance auditor gates every card, unsafe blocked Q&A generation question and answer pairs per card Test and judge harness Generate Qs Answer from card Judge vs source Auto-publish cards that clear threshold Human review below threshold or flagged

The judge is a separate model from the generator, so a card can’t pass by grading its own work. That test loop is what backs the 95% number.

The build

Eight coordinated n8n workflows, one per stage. Generation across three content types, a compliance gate, Q&A generation, the generate-answer-judge test harness, and export with verification.

View the n8n wiring

Deal Intent Signal

Back of funnel · behavioral deal scoring, model validation · PostgreSQL

Problem

Reps decide where to spend their week on vibes. Which open deals are actually heating up and which are quietly dead looks the same in a pipeline list, so time goes to the loud deal instead of the winnable one.

What I built

A model that learns the behavioral fingerprint of past won and lost deals, then scores the open pipeline against it. The signal weights are derived from each signal’s real separating power, not hand-picked, and the model is validated on held-out deals so it proves rather than memorizes.

Result

A ranked call list with a plain-English action per deal. Each row shows the signals behind the score, so a rep sees why a deal is hot, not just a number.

Runs on standard CRM engagement data. The queries and validation are in the repo.

How it works
Deal Intent Signal method The method Closed deals, won and lost the behavior that preceded each outcome Learn the winning pattern multi-threading and recency, weighted by real separating power Validate on held-out deals train on one set, score another it never saw, confirm it still separates Score the open pipeline each live deal measured against the learned winning fingerprint Ranked call list for reps hottest to coldest, with the reason and a plain-English next action
Sample pipeline output
Deal intent scoring output Open deals, scored and ranked Same model. Learned from closed deals. Willow Labs 4.65 6 contacts engaged · active 1 day ago HOT — engage now Ridge Logic 2.32 4 contacts engaged · active 3 days ago HOT — engage now Cobalt Systems 0.92 4 contacts engaged · quiet 12 days Warm — keep working Pine Data -1.25 2 contacts engaged · quiet 13 days Cooling — needs attention South Consulting -1.88 2 contacts engaged · quiet 17 days Cold — deprioritize

Synthetic pipeline. The score is learned from closed-deal behavior and validated on held-out deals, not hand-tuned.

View the code & validation

AI Deal-Audit Pipeline

Back of funnel · AI risk scoring, guardrails, audit logging · n8n + Airtable + Postgres

Problem

Deal health lives in call notes nobody re-reads. A rep can miss that a deal is single-threaded, has no timeline, or that the buyer is quietly weighing an in-house build, until it’s too late to act.

What I built

A one-click audit that reads a deal’s call history, scores its risk, flags the red flags, and writes the assessment back to the record. Every run is logged with cost, latency and outcome, so the system can be checked, not just trusted.

Result

Reps see risk before the deal goes quiet. The score is advisory and the rep still runs the deal. Failures surface to a human queue instead of disappearing.

Then I built the queries that could prove the whole thing useless, and the report they generate. Both are in the repo.

How it runs
AI Deal-Audit Pipeline The pipeline Trigger on the deal record passes the record ID to the workflow Fetch that deal’s activity scoped to the record, not a global list Dedupe and normalize clean the input before the model sees it Model reads the calls fixed schema, low temperature Validate before writing score in range, momentum in enum Write the audit back labeled AI-generated and advisory Guardrails, at every step One audit per deal per hour a double-click cannot double-charge or write the note twice Edge cases go to a human a deal with one note is not a deal the model should confidently score Bad output is logged, not written a schema violation is a failure to fix, not something to paper over Every run is logged cost, latency, status, drift, so it can be checked, not just trusted The question that decides whether it stays Did a high risk score actually predict a loss? If deals scored 8 to 10 close at the same rate as deals scored 1 to 3, the audit is decoration and should be killed. Every AI feature I build ships with a query that could prove it useless. The CRM is the swappable part Built against Airtable because that’s what I had. Swap it for HubSpot or Salesforce and the fetch and the write change. Nothing else does. The guardrails and the reasoning stay put.
Three deals, three verdicts
Deal audit results Same prompt. Same pipeline. Northwind Logistics 2 Increasing · 4 logged calls Three stakeholders. Named pain, quantified. Budget confirmed. Revised quote with finance, decision expected in two weeks. Flagged: a competing vendor is in play. Cascade Health Partners 8 Declining · 5 logged calls Single-threaded for 97 days. In-house build still on the table. No timeline, only “sometime this year.” Reschedules, then silence. The CFO has questions and has never been introduced. Fielder Manufacturing 2 Increasing · 4 logged calls Two stakeholders on the first call. Pain tied to a customer they lost. Hard date: live before the Q3 audit. Controller approved. In legal. Flagged: competitor named, net-45 requested. What the log says Cost per audit ~$0.005 End-to-end latency 14–19 seconds Runs completed, schema clean 3 / 3 The contrast is the proof. It is reading the calls.

Sample deal data, real pipeline. Every audit above was generated live by the workflow, not written by hand.

View the code & audit report

Competitive Intelligence & Outbound Engine

Go-to-market · agent-driven competitive intel & personalized outreach · n8n + Claude + Qdrant + Apollo

Problem

Good outbound is an intelligence problem, not a volume one. Writing every email from scratch ignores what the market already proves works, and generic personalization at scale reads like exactly what it is. The hard part is knowing which angle fits which lead.

What I built

A three-stage agent pipeline. It monitors 200+ competitor newsletters and distills them into a deduplicated library of proven strategies using vector search, matches each lead to the best-fit strategy semantically, and drafts personalized outreach with a two-stage writer that generates then edits. Formatted to read human, with a full multi-touch sequence per lead.

Result

Competitor sources analyzed into a deduplicated, evidence-weighted strategy library, and lead-specific campaign plans with subject lines, angles, offers, and cadence generated end to end. Built, tested, and validated, and designed to move to a new vertical by swapping prompts and sources.

How it runs
Competitive Intelligence and Outbound Engine flow Newsletter intel analyze + dedup Match strategy vector search Write + edit two-stage draft Draft to CRM

Vector search does the matching and dedup, the model handles judgment and prose, and idempotency tagging means no lead is drafted twice.

The build

Three connected n8n workflows: a newsletter intelligence engine with semantic dedup, a campaign matcher that searches the strategy library, and a two-stage email writer that drafts then edits before writing to the CRM.

View the n8n wiring

Also built

MedKB Generator

AI document pipeline

An eight-stage automated pipeline that generates compliance-checked medical knowledge-base content, validates it with built-in Q&A testing, and formats it for delivery into different systems.

Generation, a HIPAA compliance audit gate, and a hallucination eval harness run as separate stages, with a judge model from a different family scoring output against source so nothing self-grades.

Salesforce Documentation Agent

Retrieval-augmented generation, Qdrant

Production RAG assistants on a Qdrant vector store that serve instant, sourced answers from large document sets, so staff and customers get fast answers instead of reading manually.

Turns static document libraries into searchable, sourced, on-demand answers for internal and customer use.

What I work with

CRM & RevOps

HubSpot, GoHighLevel, lifecycle stage management, lead routing and follow-up, pipeline and deal-stage setup, systems integration, regular audits, data governance.

Automation & reporting

Workflow automation, nurture and re-engagement sequences, email and SMS systems, n8n, Zapier, Make, Airtable, reporting dashboards, KPI tracking, data hygiene and deduplication.

AI in production

Claude and OpenAI in daily use, RAG assistants, prompt engineering with schema-constrained output, API and webhook integrations, idempotent workflows, human review on the edge cases, and audit logging in SQL so the system can be checked rather than trusted.