Keep decisions explainable
Deterministic, centrally configured rules choose the route. Optional local Ollama extraction returns structured fields that are validated, with a fallback path when the model is unavailable or its response is invalid.
Case study · Lead operations
Make each enquiry traceable and recoverable.
A self-initiated local prototype for turning a service-business enquiry into a validated lead, an explainable qualification decision, and follow-up work an operator can review.
Enquiries cross several handoffs.
A lead can be lost between intake, qualification, a CRM entry, a first response, and later follow-up. When all those responsibilities sit in one long workflow, it can be hard to see what happened or safely recover from a partial failure. This prototype separates those jobs into five n8n workflows around a versioned lead contract and a local PostgreSQL database.
System design
A lead moves through five clear boundaries.
An authenticated event is normalized and checked before storage or downstream actions. The workflow records what happened so duplicate events and partial outcomes can be reviewed.
- IntakeChecks a shared n8n credential, maps source fields into a versioned lead contract, validates required contact details, and records the first-seen event. Invalid input stops before downstream actions; repeated event IDs return a duplicate result.
- Qualification and routingCentrally configured deterministic rules select the route. Optional local Ollama extraction can enrich structured fields, but does not replace the routing rules. Ambiguous or low-confidence cases can be held for review.
- Delivery adaptersWrite a local CRM projection and run only permitted response and alert actions. Each action has its own outcome record so a failure in one does not erase another action’s success.
- Follow-up workerClaims due jobs atomically, rechecks status and consent, records an accepted receipt, and bounds retries. Completed jobs are not repeated on replay; exhausted or ambiguous outcomes need review.
- Error recoveryStores sanitized failure details, classifies the outcome, deduplicates operator alerts, and avoids treating an empty provider receipt as success.
Build and design choices
Explainable rules and cautious recovery.
I designed and built the workflow boundaries, JSON contract, database schema and migrations, local adapters, verification fixtures, and documentation.
Record before acting
PostgreSQL event and action keys support the tested duplicate-replay paths and create a record of what happened.
Handle uncertainty carefully
Delivery actions track separate outcomes and bounded retries. A missing or ambiguous receipt goes to review rather than triggering a blind resend that could duplicate a message.
Package for local review
The prototype includes five separated n8n workflows, eight PostgreSQL migrations, configurable rules, fixture data, sanitized exports, setup notes, an operations runbook, and a repeatable demo script.
Workflow detail
Intake validation and follow-up recovery.
These static topologies show the node names and connections in the sanitized workflow exports. They are diagrams, not captured workflow-editor screens.
Verification record
What the local checks covered.
Verification used n8n 2.8.4, local PostgreSQL, local Ollama, Mailpit, and loopback provider mocks. No paid provider calls were used in the clean-package tests.
Two clean matrix passes
Two clean passes of a 32-scenario matrix (32 cases per pass), plus a separate fresh-instance import, migration, and functional smoke.
Failure and receipt guards
Eighteen focused SMTP/Telegram result-classification checks and seven operator-receipt guard checks.
Duplicate work was not repeated
Duplicate replay left downstream SMTP, Telegram, and model counters unchanged. Invalid input returned HTTP 422; missing authentication returned HTTP 403.
Single claim and recoverable retries
Concurrent follow-up workers claimed one job and produced one accepted local receipt. Exhausted retries reached error recovery. All eight migrations applied to an empty test database.
Five exports stayed inactive
All five exported workflows imported inactive with their subworkflow and error references intact.
Receipts have limits
Mailpit acceptance does not prove an email reached an inbox. A Telegram mock receipt is not a real Telegram send. A model mock checks integration plumbing, not model quality.
Test evidence image
Recorded fresh-import and validation summary.
This image renders the recorded Phase 11 test evidence. It is explicitly an evidence report, not a screenshot of the n8n execution screen.
Disclosure and limits
A local prototype, not a client deployment.
The test data is synthetic. The provider paths used local Mailpit SMTP and loopback mocks. The original workflows remain inactive by default.
No live customer operation
No real customer message, booking, external CRM integration, provider delivery, public deployment, uptime, or production model quality was tested.
No client or business outcomes
This is self-initiated prototype work with synthetic leads—not client work, production software, evidence of revenue, conversion improvement, or other business results.
Agree operating requirements
A real setup would need a defined intake source, contact consent, routing and escalation, real provider accounts and credentials, retention, security, backup and restore, costs, and operational ownership.
Test real providers with approval
Provider acceptance checks would need to run in a client-approved environment. The local mock checks do not establish that external services are connected or ready for use.
Demo label: “Fictional details · Local workflow test.”
Workflow diagrams and the verification summary are included as project evidence. They are not screenshots of a live n8n run, proof of external message delivery, or evidence of customer outcomes.
Workflow diagrams and the verification summary are included as project evidence. They are not screenshots of a live n8n run, proof of external message delivery, or evidence of customer outcomes.
Discuss your process
Message @apps.bymukarram Where does a new enquiry get stuck?
DM “CALLS” on Instagram with your trade and how you currently handle new enquiries.