n8n Project Scope of Work: What Real Failures Taught Me to Write

An n8n project scope of work, clause by clause. What I found opening a Florida brokerage's automations, and the written line that would have caught each failure.

By Carlos Familia, CRM & AI automation expert. Updated October 17, 2026. 6 min.

Spanish reminders were reaching English speakers, and lead alerts had gone quiet. Those two complaints brought me into a Florida mortgage brokerage's automations. Inside, the alert step had been logging "accepted" for days, even though the platform could no longer reach the WhatsApp Business Account. Twelve workflows also assigned tasks to a named person, 24 times in all.

Little of that was a coding error. My guess is that no written scope had ever asked who reads an alert, who owns a task or which language tag is the real one.

A scope of work for an n8n project should settle those questions before the first node exists. It names the systems, volumes and triggers. It says what counts as a failure and who gets told. It says who owns the instance and the keys, how the work is tested, what you receive at handover and what is excluded. Below is what I found and the clause that would have caught each item, then the full template.

A dead alert channel that still said "accepted"

My reading is that the step recorded that its request had been taken, not that a person had seen anything. The cause sat outside the automation: the office line had moved to another phone system, and the WhatsApp connection went with it.

I swapped that alert for a plain text message. The next real lead reached 4 staff phones.

Clause: every alert channel is proven by a real test message to a named person, on the phone they carry. The test is repeated after any change to the phone or messaging setup.

Tasks pinned to named people

My guess at how the 24 assignees got there: picking a name in a dropdown is the fastest way to build, and nobody asked what happens when that person changes jobs. In n8n the same habit shows up as an email address or user ID typed into a node.

The fix was one rule. The task goes to the contact's owner, and a single assignment workflow holds that logic.

Clause: tasks follow the contact owner. The assignment rule lives in one workflow, and no person's name appears inside any other.

Two language tags on one contact

Two signals for one fact will disagree sooner or later. Here they did, and English speakers got Spanish reminders. Cleaning it up meant moving 33 contacts onto one language tag.

Clause: every fact has one home. The scope lists them: language, owner, status, source. If a second place needs the value, it reads the first.

The error handler that never ran

In n8n, each workflow's settings name an error workflow. It must begin with an Error Trigger, and one error workflow can cover many others. At the brokerage, one covers all 33 active workflows. A failure produces a single alert keyed to the workflow, the step and the error, and a repeat of the same alert is held back for 30 minutes. Separately, an hourly check flags any workflow someone switched off and any schedule that skipped its run.

It stayed silent until I published it. An unpublished error workflow never runs.

Clause: the scope states how many workflows are active and how many are covered. The builder breaks one on purpose and shows you the alert.

Numbers nobody had checked

Before I trusted the brokerage's metrics, I checked them three times against a separate script. The same review turned up 111 open opportunities sitting in the Funded stage.

Clause: every figure on a report is reconciled against a count made another way before handover, and the difference is written down.

What other builds added to the list

• Volumes and caps. A New Mexico real estate buyer's enrichment step is capped at 25 records per run, because each skip-traced record costs money: about $0.12 in a three-record test. n8n Cloud meters executions, and its pricing page counts one run of a whole workflow as one, with Starter at 2,500 a month (October 2026). Clause: expected events per day, the peak, and a cap on any step that costs money per call.
• Duplicates. A med spa's chat bot in New Jersey answered the same message twice when two scheduled polls overlapped. Clause: the same event arriving twice produces one result, and the builder shows it.
• Time limits. On a 32-contact night, a real estate wholesaler's summary job hit the Code node's 300-second limit and wrote zero records. Clause: the largest batch the job must handle, and a run at that size.
• Test mode. A roofing contractor's bot in Kentucky sent a test-mode string to a real lead. Clause: test runs use named test contacts, every step that writes checks a test flag, and the run stops if the flag cannot be read.
• Prepaid balances. A life insurance agency in California had 8 phone numbers behind one prepaid voice account. When the balance ran dry, all 8 went dead. Clause: every prepaid balance has a low-balance alert and a named person who tops it up.

Whose account is it, and what gets handed over?

The scope has to name an owner. The New Mexico buyer's four workflows live in an n8n Cloud account the buyer owns, so they stay put whoever maintains them later. That job taught me one more line for the scope: turning workflows on with the Cloud public API did not register their triggers. Write "one real run per trigger", not "activated".

On a self-hosted free edition, sharing is off. n8n's edition comparison says only the instance owner and the user who created a workflow or credential can open it, and Git version control is a paid feature. So the handover clause carries extra weight: every workflow exported, a credential list by name, one page of notes per workflow, where alerts go and how to pause everything.

The scope I would sign

SCOPE OF WORK: [project name]
1. Outcome: [what changes for the business, one sentence]
2. Systems: [each system, its plan, who owns the account]
3. Triggers and volumes: [events per day, peak, largest batch]
4. Caps: [any step that costs money per call, limit per run]
5. Failure rules: [system down, event arrives twice, balance runs out]
6. Alerts: [error workflow on N of N active workflows, channel,
   named reader, test message sent and received]
7. Ownership: [n8n account or server in the client's name,
   builder has a user, keys in the credential store]
8. Testing: [test contacts only, test flag on every write,
   one real run per trigger shown]
9. Handover: [export, credential list, one page per workflow, runbook]
10. Support window: [days after launch, response time, what is covered]
11. Not included: [list]

Ask any builder to fill this in before they quote. How they answer lines 5 and 6 tells you more than their rate does. For budgets, see how much an n8n developer costs. For the call itself, use my n8n developer interview questions.

If something already runs without a scope, an n8n consultant review writes the missing one backwards from what exists, and n8n maintenance covers the support window in line 10. The same exercise for other builds is in the GoHighLevel scope of work and the AI automation scope of work. The wider audit of that brokerage's account is in the mortgage CRM audit. To fill the template in for your own project, book a call.

About the author

Carlos Familia, CRM & AI automation expert. GoHighLevel, n8n, AI agents, servers. Full-stack developer.

I build CRM systems in GoHighLevel, n8n automations on my own servers and AI voice and chat agents for service businesses. Full-stack developer: I write the workflow, the API integration, the database and the server it runs on, and I test every build with real journeys before handoff.