MarketStar

Good Leads. Broken Research Process.

MarketStar is a boutique B2B sales consultancy with a six-person team. Their pipeline was strong — well-targeted outbound, warm referrals — but getting a lead from initial contact to outreach-ready was entirely manual. Every new prospect required the same 45-minute ritual: search Apollo, open the LinkedIn profile, read the bio, scroll recent posts, check the email, paste everything into a sheet.

At 20–25 leads per week, that's 15–18 hours of research before a single message was sent. The team knew exactly who they wanted to reach. What was broken was the process of knowing enough about each person to reach them well.

Four Principles That Shaped the Build.

Each workflow handles one concern. The pipeline is modular by design — any stage can be updated, swapped, or monitored independently without touching the others.

1. Google Sheets as the source of truth

   Every workflow reads from and writes to Google Sheets. Each row has a status column per enrichment stage — pending, done, failed — and all workflows are trigger-based: they fire on row changes, not on a schedule. This means the pipeline is reactive, not polling-based, and the sheet is always an accurate reflection of where each lead is in the process.

   The team already lived in Google Sheets. Zero onboarding friction — they could see exactly what the pipeline was doing to each row in real time.

2. Validate email before enriching — not after

   mails.so checks MX records and deliverability before any downstream enrichment runs on a lead. An invalid email address means the lead can't be reached — spending RapidAPI credits enriching an unreachable contact wastes budget. Email validity is the gate that determines whether profile and posts enrichment proceeds.

   ~18% of Apollo-sourced emails failed mails.so validation. Without the gate, those leads would have consumed enrichment budget and clogged outreach sequences.

3. Profile and posts as separate workflows

   Profile summary enrichment and posts scraping run as independent sub-workflows triggered by their own status columns. This means a failure in posts scraping doesn't block profile enrichment, and vice versa. Each workflow can be retried, debugged, and rate-limited independently — a failure in one stage doesn't cascade.

   LinkedIn Data API on RapidAPI has per-plan rate limits. Separate workflows with independent Limit nodes let us throttle each call type without slowing the whole pipeline.

4. Smart retry on every failure

   Failed rows in each stage — invalid email marked recoverable, profile API timeout, RapidAPI rate limit — are automatically reset to pending by scheduled retry workflows that fire after a configurable delay (default: 2 weeks). The retry logic tracks status per row, not per batch, so partial failures don't require re-running everything.

   Three separate retry sub-workflows cover profile summary failures, posts failures, and email scrape failures independently — each with its own schedule and logic.

Same Team. Three Times the Volume.

Measured at 60 days post-launch. The headline number — 480 hours reclaimed per year — understates the impact, because those hours came from the team's most productive selling time.

Research time per lead Down from 45 minutes. A rep opens the Enriched Leads Database, reads the AI summary and posts hook, and is ready to write a personalised first message — without opening Apollo, LinkedIn, or Google.

3min

Email validity rate After mails.so validation. ~18% of Apollo-sourced emails were invalid or undeliverable — filtered before reaching the outreach sequence. Bounce rate dropped and sender reputation improved within the first month.

91%

Annual hours reclaimed Based on 20 leads per week at 45 minutes saved each. Returned from research to writing, calling, and closing — the work that actually generates revenue.

480hrs

Pipeline volume handled From 20 to 60+ leads per week within 45 days — no new hires, no additional tooling spend beyond the pipeline. The research bottleneck was the only constraint on volume.

3×

What I'd Do Differently.

Three weeks to design, build, and calibrate. A few things I'd approach differently next time.

• Would change: Email validation should be the first step, not the third

  In the first version, email validation happened after username extraction. That meant rows with invalid emails had already consumed username extraction credits before being filtered out. Moving mails.so validation earlier — immediately after Apollo email retrieval — would have saved enrichment budget and reduced the number of rows in the pipeline that were doomed from the start.

• Would change: RapidAPI rate limits needed explicit Limit nodes from day one

  The first run hit RapidAPI rate limits within minutes because the workflow processed all pending rows simultaneously. Adding Limit nodes to cap rows per execution was a retrofit. Any workflow that calls a rate-limited external API should have explicit throughput controls built in before the first production run — not added after the first failure.

• Would change: LinkedIn URLs from Apollo weren't always valid

  Apollo returned malformed or missing LinkedIn URLs for roughly 12% of leads — blank fields, company page URLs instead of personal profiles, or URLs with trailing parameters that broke username extraction. A URL validation and normalisation step should have been in the pipeline from the start, not added after discovering the failure pattern in week two.

• Would keep: Separate workflows per enrichment stage was the right call

  Keeping profile enrichment and posts scraping as independent workflows — each with their own trigger, status column, Limit node, and retry logic — meant a RapidAPI timeout on posts never blocked profile enrichment from completing. Modularity at the workflow level, not just the node level, is what made the pipeline debuggable and reliable in production.