The first three clients are easy. The agency owner has the credentials in a password manager and logs in to "Acme Marketing Forms" once a week to download leads. By client ten the password manager is a graveyard, by client twenty there is a shared inbox nobody owns, and by client fifty the agency has the same problem every agency has: who has access to what, who can change which form, and what happens when an employee leaves.

This is the operational shape that lets a small agency run forms for fifty clients without the chaos.

The core principle: one workspace per client

The temptation is to put every client's forms into one big agency account. It feels efficient. It is the source of every future incident.

The shape that scales:

  • One workspace per client, with its own data boundary.
  • The agency team has access to every client workspace via membership, not via shared credentials.
  • Each client has their own billing on their workspace, or the agency pays for all of them under a parent account that consolidates the invoice.
  • Data never crosses workspaces. A submission to Acme's form is never visible from Globex's workspace, even if both are managed by the same agency.

This is the structure that makes "client X is leaving us" a one-click operation instead of a data-extraction project.

Membership models that work

Three common patterns. Pick one and apply it consistently — mixing them is where the chaos comes back in.

Pattern A: Agency-led. The agency owns every client workspace. The client has read-only access to view submissions. The agency handles all configuration. This works for clients who do not want to think about the tool, ever.

Pattern B: Client-owned, agency-managed. The client owns the workspace and the billing. The agency is invited as an admin. If the relationship ends, the agency is removed and the workspace stays. This is the cleanest model for compliance-sensitive clients (healthcare, finance, legal) who need to be able to prove they own their data.

Pattern C: Co-owned. Both the agency and the client have admin access. Billing is shared or pass-through. This works for long-term partnerships but is the messiest to unwind.

Pattern B is the right default. It is friendly to "what if our agency disappears tomorrow?" conversations, which sophisticated clients will have.

Naming and tagging conventions

The single biggest operational improvement: a naming convention that scales to fifty clients.

  • Workspace name: Client Name. No abbreviations, no campaign suffixes.
  • Form name within a workspace: Purpose — Channel. "Contact — Website", "Demo Request — Paid Search", "Newsletter — Footer".
  • Tags on each form: client tier (gold/silver/bronze), industry, account manager initials.

The naming is for the agency team, not the client. The client only sees their own workspace, so they do not care that yours starts with "Acme — ". You do, because at the end of the year you will run a report across all workspaces and the prefix is what makes the report sortable.

The admin handoff

When a new client signs up, the handoff should take less than an hour. The shape:

  1. Create the workspace in the client's name.
  2. Invite the agency team members who will manage it.
  3. Invite the client's team members who need to see submissions.
  4. Set up the first form from the appropriate template.
  5. Configure the destinations (email notifications, Slack, CRM webhook).
  6. Verify a test submission lands in all destinations.
  7. Document the workspace in the agency's internal CRM with the URL, the contacts, and the account manager.
  8. Brief the client on the workspace URL, the login flow, the data-isolation guarantees, and who at the agency they should contact for what. A 10-minute call is enough; a written one-pager works too.

Skip step 7 once and you will lose a workspace inside a year. The internal CRM entry is the index that makes the rest navigable.

What does a workspace-permission model look like in practice?

Workspace isolation is the wall. Permissions inside the wall are the rooms. The combinations that scale:

Admin. Can edit any form, see every submission, manage webhooks, rotate API tokens, invite and remove members. One per workspace at minimum — typically the agency's account manager plus a backup. The admin role is the only one that can hand off the workspace at the end of an engagement, which is why concentrating it in a single person who might leave the agency is a known operational risk.

Editor. Can build and edit forms, configure spam protection, set up automations and webhooks. Cannot rotate the workspace's API tokens or invite new members. The right role for an agency operator running day-to-day form work. The lack of token-rotation power is intentional — it means an editor leaving the agency does not silently retain external API access.

Viewer. Can read submissions, export CSVs, reply to senders. Cannot edit forms or change configuration. The right role for the client's own team — they get the data they need without the ability to break the configuration the agency set up. A client viewer who needs more should get a defined upgrade path, not silent promotion.

Billing. Can see the invoice, update the payment method, change the plan. No data access. The right role for the client's finance contact who needs the receipt without needing the leads.

The permission combinations that produce incidents: an agency junior with admin rights on every workspace, a client contact with editor rights they forget they have and accidentally change a form's spam threshold, a former agency employee whose access was never revoked because they were invited as an admin and the agency assumes admins clean up after themselves. Build a quarterly permission review into the agency's operations calendar — pick a Friday, go through every workspace's member list, revoke anyone who should no longer be there. The review takes 30 minutes per fifty workspaces and prevents the incident class that ends client relationships.

Tokens deserve their own discipline. Each token should have a stated purpose, a scoped permission set (read-only where possible), and a rotation date on the calendar. A token that has been active for three years without rotation is a token that has been read by more people than the agency can name; treat it as compromised and replace it.

How do you offboard a client cleanly?

Every engagement ends. The healthy offboarding shape:

  1. Confirm the destination. Will the client take ownership of the workspace, or are they migrating to another tool, or are they sunsetting the forms? Each path has a different runbook.
  2. Export everything. Submissions to CSV per form, form configuration as a portable schema, webhook endpoint list with stated purpose, automation configuration, any custom rules or AI-moderation thresholds. The export goes to a shared folder the client owns. The export is the deliverable; the workspace handover is the transfer of control over it.
  3. Transfer the admin role. If the client owns the workspace post-engagement, promote a client contact to admin first, then demote the agency contacts to viewer, then have the new client admin remove the agency entirely. Order matters — never remove the agency admin until a client admin is confirmed, or the workspace becomes ownerless.
  4. Rotate every secret. Webhook signing secrets, API tokens, any third-party integration credentials that the agency had access to. The agency cannot retain operational access to anything after offboarding, even if it would be easier for both sides if they could.
  5. Revoke agency member access. Every agency team member who had access to the workspace is removed in one batch, after the secret rotation, after the admin transfer.
  6. Archive the agency's internal CRM entry. Mark the engagement as ended, note the offboarding date, retain the audit trail for the agency's own records. This is the entry the agency will want when a compliance auditor asks "who had access to client X, between when and when".
  7. Send the client a clean offboarding letter. Confirm what was transferred, what was deleted, what the agency retains (typically nothing beyond the offboarding letter itself), and when. The letter is the boundary marker. The client knows the engagement is complete; the agency has a written record that the data is no longer theirs to handle.

The unhealthy version of offboarding is what happens by default: nobody triggers any of the above, the workspace sits dormant with agency members still in it, the webhook keeps firing into a destination nobody at the agency owns anymore, and six months later someone notices a former employee's email address is still receiving submission notifications. The discipline of running the offboarding checklist is what prevents that future.

What does data portability look like under GDPR Article 20?

GDPR Article 20 gives data subjects the right to receive their personal data in a structured, commonly-used, machine-readable format. For an agency running client forms, the obligation flows through the client (the controller) to the agency (the processor) — but in practice, when a data subject request lands, the agency has to be able to fulfil it within the window.

The capabilities that matter:

  • Per-workspace CSV export of every submission. The basic case — the data subject's form submissions are in a workspace, and the export covers them. Should be available without a vendor support ticket; should be possible for the agency to run end-to-end in under an hour.
  • Search by email or identifier. A data subject identifies themselves by an email address. The platform should be able to surface every submission across every form in a workspace that contains that email. If the search has to be done manually across CSVs, the response time blows out.
  • Selective deletion. Article 17 — the right to erasure — needs the ability to remove specific submissions, not just truncate the entire workspace. The platform should let the agency delete a single submission by ID and have it stay deleted, including on backups within the retention window.
  • Audit trail of access. When the data subject asks "who saw my data", the platform should be able to answer. Audit logs on submission views, exports, and edits are not a nice-to-have for an agency operating across many clients; they are the document trail that survives a compliance review.

The agencies that have not thought about this in advance discover the gap when the first data-subject request lands and they spend a week building the process from scratch. The agencies that have thought about it have a documented runbook, a designated responder, and a target response time well inside the regulatory 30-day window.

When a workspace is deleted at the end of an engagement, the deletion should propagate to backups within a defined window — typically 30 days. A "soft delete" that retains submissions indefinitely is a Article 17 violation waiting to be reported. The agency should be able to articulate to the client exactly how the platform handles workspace deletion at the storage layer, because the client will be asked.

What admin invariants keep the agency out of trouble?

The rules that, if held consistently, prevent the categories of incident that end agency-client relationships:

Invariant 1: Every workspace has at least two admins. A workspace with one admin is a workspace one car accident away from being unmanageable. The second admin can be another agency operator, the client's primary contact, or both.

Invariant 2: Every token has a named owner. A token in production with no documented owner is a token that gets rotated by accident or never rotated at all. Both outcomes are bad. The owner is the person who knows what breaks if the token is replaced.

Invariant 3: Every webhook destination is tested monthly. A webhook that has been firing into the void for three weeks because the client's CRM changed an endpoint is a stack of missed leads. A monthly test — submit a known payload, verify it lands — catches the silent breakage class. In our experience, perhaps 2-5% of long-running webhooks silently drift into broken states each quarter, and the only way to know is to test.

Invariant 4: No shared logins, anywhere. A shared login is the single failure mode that turns "we revoked their access" into "they still know the password". The workspace's member-management UI exists specifically so this is never necessary.

Invariant 5: The handover letter is sent on every offboarding, no exceptions. The letter is the artefact that proves the engagement ended cleanly. The cost of writing it is 15 minutes. The cost of not writing it is a future ambiguity over who is responsible for a workspace nobody owns anymore.

Invariant 6: The quarterly access review actually happens. Calendared, owned by a specific person, documented as completed. The review is the agency's defence against the slow accumulation of stale access that every multi-client operation eventually accumulates.

These invariants are simple in principle and easy to slip on in practice. The agencies that keep them are the ones running fifty workspaces without incident; the ones that drop them are the ones who discover, halfway through year three, that their access map is uncertifiable.

Data isolation: what the client needs to know

Sophisticated clients (and increasingly, all clients) ask data-isolation questions. The answers that pass scrutiny:

  • Their submissions are stored in their workspace, never visible from another workspace.
  • API tokens are scoped to a single workspace. An agency admin's token for Workspace A cannot read Workspace B.
  • Audit logs show who accessed what, including agency staff actions.
  • Data export is available without depending on the agency. The client can pull their own data on demand.

If your form vendor does not give you these guarantees per-workspace, the multi-tenant model collapses. This is the table-stakes question to ask before you build an agency offering on top of any platform.

Billing without surprises

Two viable models for agency-managed billing:

Model 1: Agency pays, agency invoices. The agency holds the credit card for all workspaces and bills the client at a markup. Simple, but the agency carries credit risk if a client churns mid-cycle.

Model 2: Client pays, agency adds an admin. The client's card is on file, the agency does not handle payments. No credit risk, but the agency is exposed to the client downgrading the workspace without warning.

The most resilient setup is Model 2 with a contractual clause that the client cannot downgrade or cancel without 30 days written notice. The notice gives the agency time to migrate data or renegotiate.

When to move a client off

Forms are sticky — the URL on a thousand brochures cannot be changed without a reprint. But sometimes a client outgrows the agency-managed model:

  • Their submission volume is high enough that the data integration warrants a custom pipeline.
  • Their compliance requirements (HIPAA Security Rule, GDPR Article 28) make the agency a sub-processor in a way both sides want to unwind.
  • They hire an internal ops team that wants direct ownership.

The healthy version of this: hand them the workspace, remove the agency members, and keep the relationship as advisory. The unhealthy version: refuse to release the workspace and lose the relationship anyway.

Related from this desk

The shape of a well-run agency form practice

  • One workspace per client, no shared accounts.
  • Pattern B membership: client owns, agency manages.
  • A naming convention applied to every form on day one.
  • An internal CRM index of every client workspace.
  • Data isolation guarantees the agency can articulate to compliance teams.
  • Clear billing model with written handover terms.
  • A one-hour handoff checklist for new clients.

That structure works at five clients and at five hundred. The difference is the number of rows in the CRM, not the operational shape.