From spreadsheet ops to an n8n + LLM lead pipeline

The client had a working business and a broken intake. Leads arrived through the website form, three email aliases, and DMs on two social channels. Someone copied them into a spreadsheet by hand, sometimes the same day, sometimes Monday morning. Customer queries were triaged from the same inbox by the same person.

That person was the bottleneck. When they were on holiday, response times slipped from hours to days. Two leads in the last quarter were noticed only when the prospect followed up to ask if anyone was reading. The CRM was a separate world entirely — populated retroactively, once a week, from the spreadsheet.

There was no analysis layer. A new query about pricing for a 50-seat package looked the same as a request to update a billing address. The operator decided what was urgent based on the subject line and their memory of the sender. The team had built a real business on top of a workflow that did not scale past one human.

We picked n8n as the orchestration layer because the client wanted to read the workflows themselves after we left. n8n's visual graph is honest about what it is — a directed series of HTTP calls, transformations, and branches — and it doesn't hide a proprietary runtime underneath. Trade-off acknowledged out loud: n8n is slower to write than raw code for a single engineer, and faster to maintain for a non-engineer owner. The client is the second case.

The intake side is a fan-in. Inbound webhooks from the website form, an email poller for the three aliases, and the official channels for the two social platforms all land in the same n8n entry point. We normalise the payload into a single schema — source, channel, raw_body, contact, received_at — and write it to a database before doing anything else. If the model step or the downstream CRM fails, nothing is lost; we replay from storage.

The analysis step is a single call to an LLM with a structured-output schema. The prompt is short and deliberately conservative: classify intent, extract contact fields, estimate urgency on a three-level scale, flag anything that looks like spam or a job application. We measured the model on two hundred historical messages before going live and tuned the prompt until classifications matched the operator's judgment on the cases that mattered. Edge cases that the model gets wrong route to a human review queue rather than a confident wrong answer.

The notification dispatcher is rule-based on top of the classification. High-urgency sales leads page the account owner on a chat channel they already check. Support queries notify the support shared inbox and a team channel. Anything classified as spam or off-topic is logged and dropped. The rules live in a small JSON file the client can edit; we didn't hide them in a database table because reading them is more important than writing them.

The final step pushes the structured lead into the CRM via its API, with the original raw message attached as a note for context. The CRM is the source of truth from that point. n8n keeps a copy of every run for thirty days for debugging, then prunes.

We added a small dashboard — one page, server-rendered, no framework — showing the last twenty-four hours of intake, the classification breakdown, and any items in the human review queue. The operator opens it once in the morning instead of refreshing a spreadsheet all day.

• Lead response time cut from a median of several hours to under fifteen minutes during business hours.
• Roughly a full working day per week of manual ops eliminated for the operator.
• Zero leads lost since launch — every inbound message is in storage within seconds of arriving.
• The CRM now has a clean, structured lead record for every contact, populated automatically.
• Spam and off-topic noise dropped out of the operator's day entirely.
• High-urgency leads now reach the account owner on the chat channel they already use, in real time, on the device they're already holding.

What we cut

A few things we deliberately did not build, and would push back on if asked to add them later.

No custom CRM. The client already had one and used it. Replacing it would have been a six-month project that solved a problem they didn't have. We integrated against its API and moved on.

No outbound agent that drafts replies. The LLM classifies and routes; humans still write the responses. Drafted replies sound plausible and are wrong often enough that the trust cost is not worth the time saved at this scale.

No real-time streaming dashboard. The intake volume does not justify the engineering. A page that refreshes on demand is sufficient and far cheaper to maintain.

No proprietary middleware. Everything sits in n8n, the database, and the client's existing CRM. We added no service the client cannot run themselves.

Hand-over

The client owns the n8n instance, the database, the prompt, the routing rules, and the dashboard. We deployed everything on infrastructure they already paid for. There is no Houdrik-hosted component in the critical path.

We wrote a short runbook covering the three failure modes we actually saw during the build: the model API being slow, the CRM API rate-limiting under burst load, and an n8n workflow being edited into a broken state. Each has a concrete recovery procedure that a non-engineer can follow. We did not write a runbook for hypothetical failures; we documented what broke and how we fixed it.

The hand-over took half a sprint. Two of the client's people now edit the routing rules and the prompt themselves. We're available for the occasional question, but the system has been running for six weeks without us touching it.