Sales operations
n8n workflow automation
Lead Operations Automation is my own name for a self-directed build. It is not a product on the market.
Three n8n workflows that take the admin out of sourcing and outreach — enrich a contact, verify it, route it, and record what happened.
Interface built in code for this case study — not a client screen capture.
01Business problem
Nobody quits a sales job because of selling. They quit because of the forty minutes between finding a company and being ready to contact it.
Who feels it
The sourcing work I was doing had a shape to it. Find a company. Open the site. Work out what they run on. Find the right person. Guess an email address. Check whether the guess bounces. Write something that refers to what the company actually does. Paste it into a sheet so the follow-up in nine days is not a surprise. Repeat.
Each of those steps takes a minute or two and none of them is difficult. That is exactly why they get skipped. The email goes out unverified and bounces. The sheet gets updated tomorrow, and tomorrow it does not. Two weeks later the same company is contacted twice by two different routes, and nothing reads as unserious faster than that.
I built these as automations, not as a script, because the useful version had to be triggerable from wherever I already was — a Slack message, a voice note on Telegram, a row pasted into a sheet — and it had to keep running when a step failed instead of dying silently at three in the morning.
02Product overview
A trigger, a validation gate, enrichment, a drafting step, then a routing decision taken from the verification result — not from what the model hoped.
Engineering notes
The first workflow starts from a Slack message. It pulls the company and contact out of the text, enriches the contact through a data provider, drafts copy appropriate to the channel, then verifies the email address. What happens next depends entirely on that verification result: a deliverable address goes to email, an undeliverable or risky one is routed to LinkedIn instead, and a hard failure stops and reports itself. Nothing is ever sent to an address that will bounce.
The second takes a spoken request in Telegram — a voice note, usually, because that is faster than typing on a phone — transcribes it, turns it into a structured search — not a keyword string — runs the sourcing job, and writes normalised rows back into the sheet the request came from. The person asking never opens the tool doing the work.
The third reads a column of domains, fetches and reads each site, and classifies the technology stack into a fixed set of categories so the results are comparable across a thousand rows. A free-text answer per row would have been easier to build and useless to sort.
The part that took the longest was not any of the happy paths. It was deciding what each workflow does when a provider returns a 429, when a domain resolves but serves nothing readable, and when the same lead arrives twice from two triggers. Those three cases account for most of the node count.
03Key features
8 capabilities, of which 2 are model-backed. The rest are ordinary deterministic software, and the distinction is marked so the AI claim stays honest.
Slack message, Telegram voice note, or a new row in a sheet. Nobody logs into an automation tool to start a job — that friction is the reason the manual version persists.
Required fields, domain format and a duplicate check run before any paid enrichment call. A malformed row costing an API credit is a bug, not an edge case.
Freeform text or a transcript becomes a typed object — company, contact, role, intent — with a fixed schema, so a downstream node branches on a field and never parses a sentence.
Every enriched field records which provider supplied it and when. When a bounce happens later, the question "where did this address come from" has an answer.
Copy is drafted against what the enrichment actually returned, and refers only to facts present in the payload. An opener that invents a detail about the company is worse than a generic one.
The send channel is chosen by the verification result. Deliverable goes to email; risky or undeliverable goes to a manual channel; unknown holds for review rather than guessing.
Each run computes a key from the domain and contact, and a repeat key updates the existing row instead of appending a second one. Re-running a failed workflow is safe.
A failed node posts the run ID, the failing step and the payload shape back to the channel that triggered it. Silent automation failure is worse than no automation.
04User flow
The path from the trigger to the finished record, with each step attributed to whoever performs it — a person or the system.
05Architecture
The processing path first, then the layers it runs on, then the constraints that shaped both.
Path through the system
Slack event, Telegram message or sheet row. The trigger normalises into one payload shape immediately, so the rest of the workflow does not care where the job came from.
Required fields, domain sanity, and a duplicate lookup. Failing here costs nothing; failing after enrichment costs an API credit and leaves a half-written record.
Loose text or a transcript becomes a typed object with a fixed schema. Optional fields are explicitly null, never absent, so later branches can test them.
Contact and company lookups, each with a per-provider timeout and a fallback. A slow provider degrades the run; it does not fail it.
An idempotent upsert keyed on domain plus contact. The write happens before the notification, so a notification is never sent about a record that does not exist.
A one-line summary back to the channel that triggered the run, with the record link and anything held for review.
Run ID, node path, provider responses and timings retained per execution. A failure found two weeks later is diagnosable from that record alone.
Layers
Why it is shaped this way
06Technical decisions
Every decision here was contested by a reasonable alternative. The trade-off column is the part usually left out.
Why
The failure surface of this kind of work is almost entirely integration glue — auth, pagination, retries, webhook signatures. n8n already has that, and its execution log makes a failed run legible without adding observability code.
Trade-off
Logic that would be four lines in Python becomes three nodes and a JSON expression, and complex branching gets visually noisy fast. Anything genuinely algorithmic belongs in a code node, not in the canvas.
Why
Both jobs are constrained: pull named fields out of short text, and write two sentences from a fixed payload. Per-run cost matters far more than eloquence when the workflow fires a few hundred times.
Trade-off
Ambiguous input is handled less gracefully, so the schema has to tolerate nulls and the validation gate has to be stricter than it would be with a stronger model.
Why
Domain reputation is cumulative and slow to repair. Routing an unverified address to email trades a permanent cost for a few seconds of latency.
Trade-off
A verification provider becomes a hard dependency in the middle of the run, and a slow response delays every job in the queue behind it.
Why
Cleaning duplicates after the fact means the second contact has already been sent. Keying the write makes a re-run safe — and a re-run is what actually happens once a workflow is fixed and replayed.
Trade-off
The key has to be chosen carefully — too loose and distinct contacts at one company collapse into a single row; too tight and a corrected job title creates a new record.
07Challenges
Not the setup work. These are the problems where the first implementation was wrong and had to be reconsidered.
Approach
Per-node retry with exponential backoff, plus a run-level retry budget that stops the whole execution once it is exhausted, and a queue mode so a stalled run does not block the next trigger.
Outcome
A rate-limited provider now slows the batch and reports it. One job no longer turns into a hundred requests and leaves the key throttled for the rest of the day.
Approach
A reader service that executes the page, with a fallback chain: reader, then plain fetch, then a detection-only result. Each fallback records which path produced the answer.
Outcome
Rows now carry a confidence-by-source, and "we could not read this site" is a recorded state, not a silently empty column.
Approach
A normalised key from the registrable domain and a slug of the contact name, checked before enrichment and used again as the upsert key on write.
Outcome
Duplicate triggers now converge on one row. The check before enrichment also removed the wasted credits that were the first symptom of the problem.
08Business value
Stated qualitatively on purpose. Invented percentages are the easiest thing to put on a portfolio and the easiest thing to see through.
Operational effect
What would change at scale
09Interface
Dense operational views rather than dashboards. These are used for hours at a time, so the priorities are legibility, keyboard flow and state that is never ambiguous.
Run list
Executions with their trigger, duration and terminal state. The interesting rows are the failures, so they are not tucked behind a filter.
Node path
The stages a single run passed through, where it branched, and which provider answered at each step.
Branch decision
The verification result and the routing choice it produced, shown together — the decision is only checkable next to its input.
Failure detail
A rate-limited enrichment call, its retry attempts, and the point at which the run-level budget stopped it.
A diagram of the automation as built: its trigger, its steps, the services it touches and what it does when one of them fails. Drawn for this page from the workflow itself — it is not a capture of the editor, and it is not someone else’s published workflow.
Screenshots of the real thing
Outreach routing workflow
The actual canvas, captured in the n8n editor. The branch on the right is the verification decision — email one way, manual channel the other.
Voice-to-lead sourcing
Transcription, then structured search, then a normalised write back to the sheet the request came from.
Stack enrichment
Read the sheet, fetch and read each site, classify into fixed categories, write back in place.
Unlike the coded interface above, these are unedited captures of the real tool. Identifying details in the payloads have been removed; nothing has been rearranged to look tidier than it actually is.
10Technologies
Chosen for the shape of the problem, not for novelty. Anything unusual is justified in the decisions section above.
Implementation detail
11Technical preview
There is no repository link on this site. What is available instead is the module structure, the data model, the interface contracts and annotated excerpts written for this case study — enough for a technical reviewer to judge the engineering.
Technical preview
Selected implementation details are available for technical review: component structure, data models, architecture notes and sanitized code excerpts. Some client-specific source material stays private because of confidentiality. Enter the project access keyword if you have been given one — the same one works across every case study.
A presentation convenience, not authentication. This is a static site, so the keyword ships to your browser with the page and anyone reading the bundle can find it — worth saying plainly rather than dressing it up. Nothing confidential is stored behind it.
Inside this section
For private client work, contact me for a walkthrough.
Next step
Send the process, the constraints and the deadline. You will get an honest scope, an architecture sketch and a timeline before any commitment.