Practical patterns for LLM scoring in n8n workflows

My n8n workflows follow one hard rule, learned the hard way: rules are cheap, deterministic, and auditable, so they run first. Language models are none of those things, so they run second, on the small population of cases where rules thrash. Lead qualification is the classic example. Company size, email domain, seniority — a lookup table handles those. "Is this inbound request actually a fit for what we sell?" — that is where the rule-based version of me wrote forty brittle IF nodes and lost.

Here are the five patterns I use when adding LLM scoring to a workflow. They are the same principles behind my job-search pipeline, scaled down to node size.

Pattern 1: demand structured output, not prose

Never let the model write you a paragraph you then parse with string matching. Most LLM nodes in n8n (and raw API calls via the HTTP node) support a JSON response format. Ask for exactly this shape and nothing else:

{
  "score": 0-100,
  "verdict": "sales" | "nurture" | "reject",
  "reasons": ["one line each"]
}

Temperature 0. A schema the model cannot deviate from. Prose is for humans; pipelines eat JSON.

Pattern 2: the model scores, the rules route

Put the scoring step behind your existing rule chain, and put an IF node after it. The model's verdict feeds the IF. The model never writes to your CRM, never sends the alert, never decides anything at the edge. It fills a field. Nodes that do things stay deterministic.

Pattern 3: every error branch lands on a default

The model will time out, return malformed JSON on a bad day, or rate-limit you during a burst. Every one of those cases must land somewhere sensible: error branch to a Set node that writes a default score and a reasons: ["model_unavailable"] flag. The workflow keeps running. This is the n8n version of errors-are-data: a full run report with a few defaulted scores beats a dead pipeline with a perfect one.

Pattern 4: cheap model, precise prompt

Scoring a lead against a rubric is not frontier-model work. A small, fast, cheap model with a prompt that contains your actual rubric — with examples — beats a big model with a vague prompt. Put the rubric in the prompt: what makes a 90, what makes a 30, what is an instant reject. The money you save buys a lot of retries.

Pattern 5: log the reasons, not just the scores

Write score and reasons to your log store every single run. Two weeks later you will find the leads that scored 61 and deserved 90, and the exact sentence in the rubric that caused it. Without logged reasons you have a black box; with them you have a reviewable system. The template library runs 1,892-plus alert cycles at 99.7% for exactly this kind of reason — you cannot fix what you do not log.

Status and links

I am applying these to the lead-qualification template in my open-source n8n library, and the job-search engine that taught me these patterns is public too: n8n-automation-templates and remote-job-engine. The bigger version of this story — 1,500+ postings scored, rules first, model second — is here.

I am a junior automation and data builder, career-changer, fully remote from Germany (or UK). If your team runs n8n or needs LLM integrations that do not hallucinate their way into production: reaver1000.github.io.