Build a lead router.
Then prove it works.
Learn the engineering discipline behind a basic business automation: defining inputs, validating data, routing requests and testing different outcomes. Start with plain business rules before introducing an AI model.
Define the problem and success criteria
A service business receives enquiries with inconsistent details. Staff must decide which to prioritize. Our goal is to turn those enquiries into predictable routing outcomes, not to pretend that an LLM's response is always correct.
Lead ID, service, budget in euros, deadline in days, and contact consent.
Exactly one routing decision: invalid, do_not_contact, human_review, priority, standard or nurture.
Identical inputs produce identical decisions; invalid data never creates an outbound action.
Try the router with synthetic data
Change the fields below and run the deterministic rules. Everything runs locally in your browser. The example simulates classification only; no email, CRM entry or network request is made.
Submit the form to evaluate the synthetic request.
No data leaves your browser. No message is sent.
The same logic is implemented in the readable JavaScript example. You can inspect it and then reproduce it using n8n Edit Fields, IF/Switch, and data-table nodes.
Understand the routing rules
| Order | Condition | Decision |
|---|---|---|
| 1 | Malformed ID, budget or timeline | invalid |
| 2 | No contact consent | do_not_contact |
| 3 | Requested service not recognized | human_review |
| 4 | Timeline ≤ 7 days AND budget ≥ €1,000 | priority |
| 5 | Budget ≥ €500 | standard |
| 6 | Otherwise | nurture |
These thresholds are illustrative business requirements, not recommended pricing or a universal sales policy.
Test it, don't just demonstrate it
Download the six synthetic test scenarios (JSON). Build the same rules inside n8n or another workflow tool. Test each route and record the observed result against its expected result.
Priority, standard, nurture, invalid, no-consent and human-review routes.
Make malformed inputs explicit. Never silently label uncertain data as a negative response.
Run the same fixture twice. Discuss how a unique lead ID would prevent duplicate external actions.
Capture the workflow diagram and each outcome. Explain one rejected input and one boundary condition.
Create a client-style deliverable
Write a short handover document: the customer's problem, an architecture diagram, accepted inputs, decision table, test evidence, privacy safeguards and the limitations of your simulation. Do not claim production deployment without authenticated triggers, persistent deduplication, permission checks, monitored failures and real integration tests.