Managing multiple client websites from one workspace
Five client sites fit in your head. Twenty don't. The difference between an agency that copes and one that firefights is a handful of rules decided once: where every site lives, how it's named, who may publish, where each client's enquiries go, and a short weekly look across all of them. Here's that system, with the parts Anticode provides and the parts you keep in your own tools.
One workspace, clear roles
On a Team or Agency plan, every project and published site lives in one shared workspace owned by the subscribing account. People you invite work inside it with one of three roles, and access ends the moment someone is removed. Agency adds white-label client sites with no Anticode branding.
- Owner
- The subscribing account. Holds everything, including billing, and receives form notification emails.
- Admins
- Invite and remove people, delete projects and take sites down. Keep this to one or two senior people.
- Members
- Build, edit and publish. They can't delete projects or take a site offline, which protects you from the worst mistakes.
Note what that means: members can publish. If you want a rule that only a lead publishes client work, it's a team agreement, not a switch. Write it down and make the release checklist part of it.
Naming and ownership rules
- One project per client site, named
client-sitenameso the dashboard sorts by client. Avoid "New site 3" and "Final v2". - A named lead per client, recorded in your own client sheet with the site's addresses, domain registrar, who controls DNS, contract dates and the client's approver.
- Separate experiments. Pitches and trial layouts go in projects with a
pitch-prefix and are deleted by an admin when the pitch closes. - A note on who owns what. The site lives in your workspace while you manage it. Agree in the contract what happens at the end: a handover to the client's own account, an export, or continued hosting.
Routing each client's enquiries
Connectors are set for the workspace, not per site, so a single Slack connector receives submissions from every client site. Each submission is tagged with the name of the site it came from, which is one more reason for clear project names. That shapes your options:
- One internal channel for everything. Simplest: your team sees all enquiries in one Slack or Discord channel and forwards them. Fine for a few low-volume sites; risky once a client expects replies within the hour.
- A webhook into your own automation. Send everything to one webhook in Zapier, Make or n8n and route by the site field to each client's inbox or channel. More setup, but each client gets only their own enquiries.
- A sheet as the record. Send everything to one Google Sheet or Airtable base as well, filtered by site, so nothing depends on someone reading a channel.
Each submission goes to each connector once, without retries. Test every client's form after any change to connectors, not only after site changes.
The weekly check, about twenty minutes
- Open each live site's analytics. Page views per day by source sit in the dashboard. You're looking for sudden drops, which usually mean a domain or DNS change on the client's side.
- Scan the submissions lists for sites that have gone quiet. A busy site with no enquiries for a week deserves a test submission.
- Check each site's integrity result on its public security report at
/.well-known/anticode-security. Published files are re-hashed by a scan that reaches each site about once a day; you're confirming nothing was flagged. - Review who has access. Remove freelancers whose work has finished. A removed person loses access immediately.
- Note anything for the client in your monthly report.
What goes wrong
| Problem | Prevention |
|---|---|
| A member publishes a half-finished change to a client site | A publish rule, the release checklist first, and version history to restore |
| A client's enquiries land in the wrong client's inbox | Route by the site field, and test after any connector change |
| Nobody notices a site's domain stopped working | The weekly analytics glance |
| A former contractor still has access | Access review each week; remove on the last day of their contract |
Limits
Anticode gives you one workspace, roles, per-site analytics and submissions, public security reports and version history. It doesn't keep a client CRM, track contracts or domains you don't host, bill clients, offer per-site connectors or restrict publishing to certain members. Keep those in your own tools. For the monthly routine on top of this, see the maintenance retainer and monthly client report, and the Team workspaces feature for seats and roles.
Questions people ask
Can each client site send enquiries to a different Slack channel?
Not directly: connectors are set per workspace. Send them to one webhook and route by the site name in your automation tool, or forward from one shared channel.
Can I stop team members from publishing?
Not with a setting. Members can build, edit and publish; only owners and admins can delete projects or take sites down. Use a team rule for publishing.
Do client sites show Anticode branding?
Free sites carry a small badge; paid plans don't, and Agency sites are white-label.