Every client’s social account, run like the work has your name on it.

Every client gets a completely separate world.

The reason social tools break at agency scale is that they were built for one brand and stretched to fit many. Beacon starts the other way round.

Every project in the Hub gets its own Beacon: its own connected accounts, its own brand voice and banned phrases, its own approval chain, its own quiet hours and posting cadence, its own calendar, its own numbers. Nothing crosses. A member of the Northwind team cannot see Acme’s queue, and Acme’s disclaimer will never turn up on Northwind’s post — not by policy, but because the account boundary is enforced on every single query.

• Per-project by construction. Connect a client’s handles once, inside their project. Their settings, their history, their audit log.
• More than one handle per network. The brand account and the founder’s account, side by side, and each post says which one it goes out from.
• Roles that match how agencies actually work. Anyone on the project can draft and schedule. Publishing, connecting an account and changing compliance need an owner or admin.

Everything ships once, and only once it’s cleared.

The two things that end an agency relationship are a post that should never have shipped and a post that shipped three times. Beacon is built around both.

Define the approval chain the client asked for — a copy lead, then legal, then the client themselves — and posts work through it in order. A stage passes when its required approvals are in. Request changes sends the post back with the note attached. Every decision stays on the post, permanently, next to the copy it was made about.

Then, before every send, eight preflight checks run: a connected account, a live token, no rate limit in force, the network’s length limit, media present and of a supported type, the disclaimers still in the copy, the client’s own rules, and every link resolving. A failure blocks the send and names the check that stopped it rather than reporting a generic error. A post that went out on three networks of five shows you exactly that, and offers a retry on just the failures.

• Sent once, provably. A variant that already has an id at the network is never sent again, whatever happens to the queue.
• A rate limit is “later”, not a failure. The send defers itself and retries rather than dropping the post on the floor.
• An audit log any project member can read. Every action, who did it, when — in plain English, filterable, and kept for as long as the client’s retention setting says.

The reporting a client actually asks for

Performance by network, by campaign, by theme track and over time — impressions, engagements, engagement rate and clicks, taken from the networks’ own metrics and always labelled with how fresh the numbers are.

Save a report with its date range and run it whenever the client asks: a row per send, a total per campaign, or an executive summary that totals by network with an all-networks line. Out as CSV, into the deck, done before the call.

• Campaigns that group the work. A launch is one campaign across five networks and six weeks, read together rather than one post at a time.
• Theme tracks with target shares. Set the editorial mix you promised, and see an unbalanced month on the calendar rather than calculating it later.
• Creators you already know. Keep the list, the tier, the status and the notes in Beacon and take it out as a CSV.

• It is already in the project. The same place the research, the prototypes, the brand kit and the video live. No new login, no export, no seam.
• The brand kit is the brand kit. Colour and type come from the project, so a post made on Tuesday matches the deck made on Monday.
• Attachments come from the client’s own library. Anything in their Data Management files or generated for them, with the per-network type and count rules enforced as you pick.