Design the Workflow: Specifying a Lead Enrichment and Routing Chain Node-by-Node
Objective: Design a complete node-by-node workflow specification (trigger, enrichment call, conditional branch, two output paths) for a B2B lead-routing automation, ready to hand to a developer or build directly in n8n or Make.
You're the demand-gen lead at Bansal Wire Industries, the NSE/BSE-listed steel wire manufacturer, and the sales team is manually triaging every website form submission. You've been asked to spec the automation before anyone touches a build tool.
Spec every node in a lead enrichment and routing workflow: trigger, enrichment call, conditional branch, two distinct output paths, and the exact data each node passes to the next.
Before you start
What you'll need
Free path (everything below is enough to finish)
Free, no automation account needed to plan
1,000 free credits/month is enough to test the routing logic before committing
Paid upgrades (optional, faster/deeper)
Execution-based billing scales better than Make's operation count at high volume
The process
2 steps
Step 01 of 02
The lesson's lead-enrichment workflow (#2) shows the shape: a webhook trigger, an enrichment call, a conditional node on fit quality, then two branches.
A steel wire manufacturer's form fills range from a curious student to a 500-ton/month buyer. What field decides which branch a lead goes down, and what does each branch actually do?
Procedure
- Row 1: Webhook trigger, capture form fields (company, monthly volume, product category)
- Row 2: Enrichment node, call an enrichment service for company size and industry classification
- Row 3: Conditional node, branch on 'monthly volume >= 50 tons' as the fit threshold
- Row 4a (high-fit branch): assign to a named sales rep in CRM, send Slack alert
- Row 4b (low-fit branch): tag 'nurture' in CRM, add to a drip sequence, no rep alert
NODE SPEC: Lead Enrichment & Routing 1. Webhook Trigger - fields: company, monthly_volume_tons, product_category 2. Enrichment (Clay) - adds: company_size, industry, gst_verified 3. Conditional - IF monthly_volume_tons >= 50 THEN branch A ELSE branch B 4A. High-fit - CRM: assign_rep=true, Slack: #sales-hot-leads 4B. Low-fit - CRM: tag=nurture, sequence: drip-email-8-touch
Healthy
Every node has a named input field and a named output field, a developer could build this without asking a clarifying question.
Unhealthy
A spec that says 'enrich the lead' with no named fields, the developer has to guess what data actually moves between nodes.
What this means
A workflow spec is only build-ready when every node's input and output fields are named. Vague verbs like 'enrich' or 'route' are not a spec.
So what do I do about it?
| Symptom | Action | Effort |
|---|---|---|
| Developer keeps asking what data each node passes | Add named input/output fields to every row before handoff | 30 min |
Step 02 of 02
The lesson's rule of thumb: a team with a developer or a technical marketer should pick n8n for AI capability and long-term cost; a pure marketing/ops team without coding comfort should pick Make.
Bansal Wire's marketing team has no developer and no plans to hire one this year. Does the spec from Step 1 belong in n8n or Make, and why?
Procedure
- Check whether any node in the spec requires custom code or an unsupported integration
- Confirm the team has zero developer hours allocated this quarter
- Match against the lesson's rule of thumb: no coding comfort -> Make
- Note the fallback: if volume later requires self-hosting for cost, revisit n8n
PLATFORM DECISION Spec requires: webhook, 1 API call, 1 conditional, CRM write, Slack post - no custom code needed. Team technical comfort: none, no developer allocated. Decision: Make. Reason: matches the spec's complexity without requiring a developer, and Make's circular builder handles the conditional branch cleanly. Revisit trigger: if monthly lead volume exceeds 5,000 and Make's operation costs exceed $150/month, re-evaluate n8n self-hosted.
Healthy
The platform choice is justified by team capability and spec complexity, not by which tool is trendiest.
Unhealthy
Picking n8n because it's 'more powerful' when nobody on the team can debug a broken workflow.
What this means
The right platform is the one the team can actually maintain, not the one with the most features.
So what do I do about it?
| Symptom | Action | Effort |
|---|---|---|
| A workflow breaks and nobody on the team can fix it | Match platform choice to actual team technical comfort before building, not after | 5 min |
Final deliverable
A complete node-by-node workflow specification (trigger, enrichment, conditional, two branches) plus a justified platform recommendation.
See a reference example
Sula Vineyards, DTC restock-alert workflow spec (excerpt) 1. Webhook Trigger - fields: customer_email, sku, last_order_date 2. Conditional - IF days_since_order >= 60 THEN branch A ELSE branch B 3A. Re-engagement branch - CRM tag: winback, sequence: 3-email offer 3B. Active branch - no action, suppress Platform: Make selected, no developer on the DTC team.
Success criteria
You're done when you can:
- Every node in the spec names its input and output fields
- Platform recommendation is justified against the team's actual technical comfort, not just feature count