LeadFlow
A working orchestration demo that makes qualification, policy, and routing decisions visible rather than hiding them behind a single AI response.
Overview
LeadFlow is a working orchestration demo for turning inconsistent inbound lead data into a validated and explainable outcome. It makes mode selection, confidence, fallback policy, routing, and dispatch planning visible.
It is not presented as a production SaaS or a source of measured business impact.
- Role
- System design and workflow implementation
- System
- Qualification and routing orchestration
- Launch state
- Working demo
Problem
Lead automation becomes difficult to trust when input shape, qualification logic, confidence boundaries, and delivery decisions are hidden inside one workflow. Failures can become silent and a score can be mistaken for an explanation.
LeadFlow treats each boundary as a visible system decision rather than a single black-box output.
Intended users
The system is designed as an engineering demo for teams evaluating how to structure qualification and routing automation before operational deployment.
- An operator reviewing why a lead received a particular outcome.
- An engineer configuring qualification modes and failure policy.
- A team separating routing intent from actual dispatcher delivery.
System walkthrough
The native diagram explains the five-stage mental model. The full n8n canvas then provides implementation evidence, followed by three carefully distinguished outputs: an executed sample qualification, a routing plan, and a configured reliability policy.
Selected stageIntakeAccept a lead payload and validate required inputs.
The real n8n workflow shows the orchestration and its explicit failure branches.
Sample qualified result with score, confidence and explicit reasons.
A qualified result is converted into an explicit priority route and destination plan.
Hybrid qualification policy with versioned rules and a fallback-to-rules failure policy.
What I built
I designed the canonical lead model, validation and normalization boundaries, company-context enrichment, qualification modes, policy configuration, routing states, dispatcher interfaces, and audit-oriented result shape.
- Input
- Validation, normalization, and canonical lead shape
- Context
- Company enrichment boundary
- Decision
- Rules-only, AI-only, and hybrid qualification
- Safety
- Fallback-to-rules and manual-review boundaries
- Routing
- Qualified, nurture, and disqualified outcomes
- Dispatch
- Webhook and notification destination planning
Architecture
The orchestrator advances through explicit stages and returns structured state at each boundary. Error handlers feed a visible policy decision instead of silently converting an exception into a normal outcome.
IntakeAccept a lead payload and validate required inputs.
Important decisions
Inbound lead payloads are inconsistent and downstream logic needs one stable shape.
Normalize into a canonical lead model before enrichment and qualification.
The intake layer does more work, but later stages are simpler and more auditable.
Teams may need deterministic decisions, AI assistance, or a controlled combination.
Make rules-only, AI-only, and hybrid modes explicit configuration.
Configuration requires careful validation, but the decision boundary stays visible.
A planned route is not proof that an external webhook accepted delivery.
Represent routing and dispatcher destinations as an explicit plan.
Operational delivery needs separate evidence, but the workflow avoids overstating success.
Reliability and testing
The workflow validates inputs, checks stage results, builds failure outputs, and makes the configured fallback policy visible. The supplied policy evidence shows configuration—not a recorded AI failure or a demonstrated manual-review event.
A production deployment would additionally need delivery receipts, secrets management, retries, monitoring, and a broader automated workflow test harness.
- Input validation and normalization.
- Explicit failure branches between stages.
- Versioned rules and fallback policy.
- Audit-friendly structured orchestration results.
Challenges and trade-offs
The main design challenge is separating decision quality from system reliability. A confident qualification does not prove that enrichment was complete, and a routing plan does not prove delivery. The case study therefore labels each artifact by what it actually demonstrates.
Current limitations
- The project is a working demo, not a production client system.
- The supplied routing output does not prove successful webhook delivery.
- The policy screenshot does not prove an AI failure or manual-review event occurred.
- Operational monitoring, delivery receipts, and production-scale retry behaviour are not demonstrated.
Next improvements
- Add a repeatable end-to-end test harness for representative lead outcomes.
- Persist delivery attempts and external acknowledgement states.
- Add secrets management and environment-specific dispatcher configuration.
- Instrument retry, dead-letter, and manual-review queues.