Build guides

Build a client job you can hand over — for consultants

By Aghassi Sargsyan · Published 2026-07-04 · Reviewed 2026-08-18

If you build automations for clients, the thing you are short of is not another builder — you already own n8n or Make. What you are short of is evidence you can put in front of a client when they ask whether the thing you built is still working.

This build takes about ten minutes and ends with a run record you can send. I build this product, so read the framing as interested and the numbers as checkable.

The job: qualify inbound and route it

A generic first job that suits almost any client: read an inbound enquiry, score it, write a two-line summary, and notify whoever owns the follow-up. The summary is the part that earns its place — a score nobody reads is a number in a database.

Step 1 — the agent

Agents → Create agent. Name it for the client, not for you: Acme — Inbound Qualifier. Type CUSTOMER_SUPPORT or CUSTOM — it is a label and is never sent to the model. Then the only field that matters, Configuration (JSON):

{
  "system_prompt": "You qualify inbound enquiries for a B2B services firm. Return JSON with: band (hot|warm|cold), reason (one sentence), summary (two lines a salesperson can read without opening the email), and next_step. Most enquiries are cold - say so. Disqualify on wrong region, no budget signal, or a request we do not serve, even if the enquiry is enthusiastic.",
  "temperature": 0.2,
  "response_format": "json"
}

Two deliberate choices there. response_format: "json" so a later step can branch on band instead of parsing a sentence — you can also set it with the JSON-output checkbox on the form, which writes that key for you. And an explicit instruction that most enquiries are cold, because an agent asked to be helpful avoids the word and everything comes back warm.

Step 2 — one tool, and what the client has to connect

Tick slack_message or send_email in the Tools section. The checkbox writes "tools": [...] into the Configuration for you.

Integrations are per account, not per client. If the notification has to land in the client’s Slack, that connection lives in whichever account runs the workflow — which is the first thing to decide before you build, not after.

Step 3 — the receipt, which is the actual deliverable

Run it on twenty real enquiries, then open one from Executions. Every step records what it received, what it returned, its status and duration, and — on agent steps — its tokens and cost. A step that was skipped writes its own row saying so and why.

That last one is what makes a claim checkable. *"Nothing was escalated on Tuesday"* stops being something you hope and becomes a row you can point at.

Source: three runs opened up step by step, which you can send a client before you have built anything at all — it needs no account to read.

And Replay re-runs a past execution with its original input against the current definition. So when a client reports a problem, you fix the workflow and replay the exact input that broke — *"I fixed it"* becomes something you demonstrate.

What to tell a client before you sell this

There is no client separation

Agents and workflows belong to your account. There is no per-client workspace, no client login, no read-only view to hand over, and no per-client bill. Tags on an agent are the only labelling mechanism. For a multi-client book, the honest arrangement is an account per client, with them paying for theirs.

Nothing answers "which client went quiet"

You can see every run and filter by agent. There is no client dimension to group by, so the question you most want answered across five clients is not answerable today. Build the count into each workflow instead — have it report how many items it processed, and a silent week becomes visible.

It will not replace their n8n

Ten tools here against a catalogue of hundreds. Put the judgment step here and leave the wiring where it is. A consultant who frames this as a replacement will lose the argument on connectors, deservedly.

What it costs you, and what you can charge

Pro is $29 a month flat for your account — not per client, not per task. Runs are billed in tokens: a job of this size measured $0.0144, one that escalated as well $0.0204, one that failed early $0.0024. Source: the same three runs.

So 500 qualifications a month across a client book is single-digit dollars of usage on top of the $29. Attach your own Anthropic or OpenAI key and the daily ceilings disappear — you pay the provider directly at cost, with no markup from us, which is also the arrangement that lets you bill a client for their own usage cleanly.

The failure to warn them about

An agent whose lookup fails can still write a confident answer and finish COMPLETED. Source: a logged run of mine — two calls returned HTTP 403 while the tool result recorded "ok": true, so the agent proceeded as though it had the data and told a customer it had checked. Read the tool result’s status, not the run’s.

For client work the rule that follows is simple: draft, do not send. A wrong draft costs a second of reading; a wrong sent message costs your client’s customer, and then costs you.

Next

1. The full click-by-click on one agent — see Build a support agent that answers a refund ticket.
2. Have the client’s form start the run — see Automate: schedules & webhook triggers.
3. What we do not do, in one page — see agent-mesh.org/consultants.