clickSomo

Agencies

One funnel, twenty clients,twenty reputations kept separate.

A three-person agency running marketing for twenty local businesses has the same problem twenty times, and the same solution twenty times — except that each client's list, sending identity, domain and consent record must stay entirely their own. The interesting work is in that "except".

A project per client,
and the boundary is the database's job.

Everything here is scoped to a tenant and a project together — contacts, funnels, creatives, campaigns, sending identities, reports. That scoping is enforced by row-level security in the database, not by a clause somebody has to remember to add to a query. A forgotten project sees nothing rather than the first project's rows.

Which means a client's list cannot leak into another client's campaign by mistake, and it means a report is about one client because it structurally cannot be about two.

Each client sends as themselves

A sending identity belongs to a project: their domain, their DKIM keys, their mailbox or their provider account, their rate cap. One client's unfortunate campaign cannot damage another client's deliverability, because they were never sharing anything to damage.

It also settles an awkward conversation early. The client owns their sending, their list and their consent record. When they leave — and some will — they leave with all of it, and you did not build a hostage situation you would have to explain.

Twenty projects, one agencyScoping
  • 1ContactsPer project. Enforced in the database, not by a query you have to remember.
  • 2SendingTheir domain, their DKIM, their mailbox or provider, their rate cap.
  • 3ConsentTheir ledger. It travels with them, evidence included, if they leave.
  • 4ReportsPer project by construction. There is no way to accidentally aggregate two clients.
  • iWhat you keepThe funnel definitions and the way you work. That is your product, and it is the part worth reusing.

No shared reputationNo shared list

Reuse without copy-paste

Build the funnel once.
Deploy it as many times as you have clients.

A funnel is a graph, and a graph is JSON with a published schema. Which means the thing you are reusing is a document, not a screenshot of a screen you have to rebuild by hand in each account.

Your house funnels

Welcome, abandoned basket, no-show, interval, win-back. Written once by whoever is best at it, kept in your own repository, and created in a client project with one API call.

Checked the same way everywhere

The validator runs on your funnel in every project it lands in. A graph that would loop without a wait, or send without a subject, is refused there just as it would be here.

Simulated before it runs

Dry-run a real contact from that client's list through the funnel and read back what it would send them. Do that once per deployment and the "it went out wrong" conversation stops happening.

Improved in one place

When you learn something — the second reminder does better at ten in the morning — you change your definition and roll it forward. The clients already running the old version finish on the old version; nobody in flight is disturbed.

Creatives too

A creative is a document with merge variables. The same welcome e-mail, rendered with each client's brand, colours and logo — picked up from their own website on the first run.

Or let an agent do it

Point an assistant at the MCP server, scoped to one project, and have it draft and check the funnel for that client. Everything that reaches a real person still needs an explicit confirmation and stays inside the quota.

Eleven clients, eleven senders,
one place to look.

The monthly report problem.

Most of an agency's reporting pain is not producing numbers. It is producing numbers that survive the client asking a follow-up question, and producing them without three hours of screenshotting on the first of the month.

Two things help here. Reports are API routes, so the monthly pack can be assembled by a script and exported as a PDF rather than by a person and a spreadsheet. And the numbers are honest about bots: raw and filtered are both available, labelled, so when a client asks why the open rate dropped after they moved, you can explain it in one sentence rather than defend it in four.

The same tiles land in dash-b — campaign performance, funnel drop-off, list growth, deliverability by domain — so a client who wants a live board can have one, on their own account, with their own credentials and no key of yours in the page.

The first of the monthScripted
  • 1For each projectOne token, one project scope, the same script.
  • 2PullCampaign performance, funnel drop-off, list growth, deliverability by domain.
  • 3RenderTheir creative document as a report page, then to PDF.
  • 4SendOr drop into their board. Whichever that client actually reads.
  • iWhat changedThree hours of screenshots became a scheduled job, because the reports were routes all along.

Raw and filtered, both labelled

The conversation about consent,
had early.

Every agency has met the client who arrives with a spreadsheet of four thousand addresses and a vague answer about where they came from. Here that is not an argument you have to win; it is a field.

The import lands as legitimate interest at best, never as consent, and the basis mix is shown before any campaign goes out. If a list cannot be sent to, it says so at the point of import rather than at the point of a complaint. That turns an uncomfortable judgement call into a shared reading of the same screen — which is a much better position for you to be in when the client insists.

Worth saying out loud to the client: the reputation being risked by a bad list is theirs, on their own domain, because each project sends as itself. That is a stronger argument than any regulation, and it is the one that tends to land.

Tell us what you send today,
and to how many.

We will show you what it looks like here — usually with the funnel drawn, because that is faster than a paragraph about it.

Open ClickSomo Talk to a person

Illustrations by Pixeltrue (Minimalistic pack).