TeamIA prospecting automation with Lemlist and n8n

TeamIA needed more than a contact list. Each campaign had its own offer, targeting rules, decision-maker roles, exclusions and messaging instructions. Once enrichment completed, a reviewer still needed to understand why the company was relevant and whether the proposed message was usable.

I built the review interface, campaign and segment configuration, prospect ingestion APIs and persistence of review decisions, connected to the n8n engine. The resulting workspace gives the team an actionable queue without requiring it to inspect individual automation executions.

Campaigns can be draft, active or paused. Their settings include the offer, target pain points, included and excluded job titles, and message instructions. Segments specify country, location, industries, company size and quotas. These settings feed the workflow instead of remaining scattered across automation nodes.

The inspected implementation caps active campaigns at ten prospects per day in total. This is an operating limit for the initial scope, not a throughput benchmark. Segment pagination supports continued research; future scaling must account for provider quotas and the team's review capacity.

Each prospect has four views: contact, company, AI analysis and message. They bring together the company score, contact information, email status, recorded technologies, research summary and suggested automation opportunity. Filters narrow the queue by campaign, market and review status.

Research signals have source URL and date fields, giving reviewers context for checking the proposed approach. The score prioritizes review; it is not a predicted conversion rate. AI summaries and verification labels still require judgment before the information is used for outreach.

Next.js and React provide the dashboard and API routes. PostgreSQL on Supabase stores campaigns, segments, processed companies and prospects. n8n reads active segments and orchestrates research and preparation; Lemlist supplies the company search and enrichment capabilities used by that pipeline.

An ingestion API accepts normalized results, validates inputs on the server and links returning data through a prospect deduplication key. Browser access and automation requests use separate authentication mechanisms. Integration secrets and the PostgreSQL connection remain server-side.

The system derives a company key from its normalized domain or an available identifier. It reserves selected companies in the database, where a uniqueness constraint and conflict-safe insert exclude previously processed accounts before new decision-maker research.

Company reservation and pagination progress are committed together in a transaction. Prospect ingestion has its own deduplication key. These boundaries address separate needs: avoiding repeated company research and attaching enrichment to the right contact. They make recovery more controlled without implying every provider failure is automatically resolved.

Prospects have explicit states: awaiting enrichment, to review, approved, changes requested or rejected. Reviewers can edit the subject and message body and leave a comment. A review action persists the status, draft and comment to the prospect record.

Approval does not mean delivery. The presented dashboard contains no prospect-email sending action. Connecting an outbound tool would be a separate scope, with suppression rules, frequency limits and explicit approval conditions.

The deliverable connects campaign configuration to prospect review, with persistent decisions and accessible supporting information. Screenshots show the real interface populated exclusively with fictional companies, contacts and messages. Neither a client prospect list nor access to the private dashboard is published here.

No verified time savings, meeting counts or attributed revenue are claimed. Useful operational measures would include excluded duplicates, enrichment cost per usable record, review time and the proportion of corrected or approved drafts. Commercial outcomes require separate tracking after outreach.

This approach suits B2B agencies and sales teams with specific targeting criteria, multiple offers and a need to review AI-prepared messages. Discovery starts with permitted data sources, qualification rules, existing tools and ownership of the review process.

An initial version can cover one campaign, one enrichment path and a review queue. Volumes, access rights, CRM integrations and any sending functionality should then be scoped against real constraints. A concrete campaign and its current process provide a useful starting point for a custom prospecting project.