Running an Agency on Openbook: Client Delivery, Proofing and Reporting

Agencies run on a stack that grew one emergency at a time: a project tool for internal tracking, a proofing tool for creative review, email for client approvals, a chat app for the team, spreadsheets for resourcing, and a slide deck rebuilt every month for client reporting. Each tool made sense when it arrived. Together they make every project a relay race where the baton is context, and the baton gets dropped between tools.

Openbook consolidates that stack into one workspace with a structure that happens to fit agencies unusually well: Organization → Space → Room. Your agency is the organization. Each client gets a space. Inside each space, rooms handle delivery, review, reporting, and communication — with per-room visibility deciding exactly what the client sees. One login for your team, one clean window into the work for each client, no export-import shuffle between the tool where work happens and the tool where clients look at it.

This guide is the operating manual: how to structure client spaces, run the delivery board, move creative through proofing to formal approval, report through live dashboards, and keep the agency's internal machine running in the same place.

The client-space model

The foundational decision is one space per client. Not one giant "Clients" space with everything mixed together, and not a space per project (unless the engagement is genuinely one project — more below). Per-client spaces give you:

• Clean membership. A space has its own members. Your account team joins the client's space; the client's stakeholders join the same space. Nobody from Client A can ever see Client B's space, because they are simply not in it.
• Clean permissions. Within the space, per-room visibility separates client-facing rooms from internal ones. The client sees the delivery board, the proofing room, the dashboard, and the update feed. They do not see the internal room where your team talks candidly about scope creep.
• Clean offboarding. When an engagement ends, the space archives as a complete record — every deliverable, every approval, every update, in one place.

Openbook ships an Agency space template that provisions this composition in one click, seeded so the space demos itself. Use it for every new client and you also get consistency: every account manager knows where everything is in every client space, because every client space has the same bones. (Template mechanics in depth: Space Templates: One-Click Workspaces for Every Team.)

The standard room set for a client space:

Room	Audience	Job
Feed	Client + team	Updates, milestones, announcements
Kanban Board	Client + team	Deliverables moving through stages
Proofing	Client + team	Creative review and formal approval
Dashboard	Client + team	Live status reporting
Docs	Client + team	Briefs, scopes, meeting notes
Internal board or chat	Team only (visibility-restricted)	Candid coordination

For project-based engagements rather than retainers — a single campaign, a rebrand — the same composition works with a start and end date, plus a Gantt room if the timeline has real dependencies and milestones. If a one-project client later becomes a retainer client, the space simply keeps going.

Client access: roles and visibility

Getting client access right is what makes the single-workspace model safe. Two mechanisms do all the work.

Roles. Openbook has four: Owner, Admin, Member, Viewer. Your team members are Members (Admins for account leads). Clients get one of two roles depending on how collaborative the engagement is:

• Viewer for clients who should watch but not touch: they see the rooms you expose — board progress, dashboards, proofs, updates — without edit rights. Right for exec stakeholders and cautious first engagements.
• Member for clients who actively participate: commenting on proofs, discussing in the feed, adding requests. Most working-level client contacts end up here, because proofing feedback is participation.

Per-room visibility. Any room can be limited to certain people. The pattern for client spaces is a small set of restricted internal rooms inside every client space — typically an internal board or notes doc where estimates, staffing tensions, and candid assessments live. Set visibility on these rooms before the first client invite goes out. Auditing visibility after a client is already inside is the wrong order of operations.

Two norms keep this airtight as the agency grows:

1. Default client spaces to client-visible. If most rooms in the space are hidden, the client portal feels like a facade. Keep the internal set small and deliberate.
2. Name internal rooms unambiguously. "Internal — Team Notes" leaves no doubt for your own staff about where candor is safe.

The full permission model, including how these patterns extend company-wide, is covered in Roles, Permissions and Visibility in Openbook.

The delivery board

The Kanban Board is the spine of each client space: every deliverable is a card, and the columns are your delivery stages — something like Briefed, In Progress, Internal Review, Client Review, Approved, Delivered. The board room type brings more than columns:

• Multiple views of the same work. Board view for the team working it; list view for the account manager's weekly sweep; timeline view when a client asks "when does all of this land?"
• Checklists on cards for the sub-steps of a deliverable (copy, design, revisions, export) without cluttering the board with micro-cards.
• Custom fields for what agencies actually track per deliverable: channel, format, round number, billable hours bucket — whatever your operation needs.
• Card templates so "new deliverable" starts with your standard checklist and fields pre-attached, instead of being rebuilt from memory each time.
• 36 board templates to start from, and a per-board AI chat scoped to that board's work.

For retainer clients with request-queue dynamics — "we need a banner by Thursday" arriving weekly — some agencies add a Table Board as an intake surface: a structured request list with status, requester, due date, and priority columns (nine column types available), which the team then promotes onto the kanban board when work is accepted. Requests stay legible to the client; the working board stays clean.

One rule turns the board from tracker into contract: the board is the single source of truth for status. When a client asks where something is, the answer is on the board they can already see. This retrains clients out of status-by-email — the most expensive communication habit in agency life — because the answer is always a glance away, at whatever hour they wonder.

The proofing workflow, step by step

Proofing is the room that makes Openbook feel built for agencies. It replaces the review cycle of annotated PDFs, screenshot markups, and "see my comments in the email below" with one canonical loop:

1. Post the work. The deliverable — artwork, layouts, video — goes into the proofing room. For video, annotations are time-coded, so "the logo feels late" becomes a comment pinned to the exact moment, not a vague note about "around the middle."

2. Reviewers annotate. Feedback is pinned directly on the artwork, where the issue is. This single mechanic kills the most expensive ambiguity in creative review — which headline, which image, where exactly — because every comment carries its own coordinates.

3. Each reviewer gives a formal decision: approve or changes required. This is the load-bearing feature. Not a thumbs-up emoji, not "looks good, tiny thing though" in an email — a recorded decision per reviewer. Ambiguous approval is where agency margins go to die, because ambiguity means an extra round, and extra rounds are unbilled hours. A formal decision state means round three ends with a fact, not a feeling.

4. Revise as a new version. Proofing tracks versions, so round two lives alongside round one rather than overwriting it. When a client asks to "go back to how the first one handled the header," the first one still exists. The version trail is also your paper trail: what changed, in response to whose feedback, and who approved the result.

5. Approved work moves on the delivery board. Card to Approved, then Delivered. Review state and delivery state stay in sync because they live in the same space, ten seconds apart — or delegate the sweep to the AI assistant, which can move the routine updates and post the milestone note to the feed from one instruction.

Two process norms multiply the room's value:

• Run internal review in Proofing too, before the client round. Same annotations, same decisions, team reviewers only. Work reaches the client having already survived one round of pinned scrutiny, and juniors learn the review standard from the trail seniors leave.
• Agree with the client, in writing, on who the approvers are. Formal per-reviewer decisions only settle things if the reviewer set is settled. Put the approver list in the scope doc in the docs room. When someone's cousin's opinion arrives by email in round three, the doc is your polite backstop.

Client reporting without rebuilding decks

The monthly client report is agency overhead at its purest: an account manager spends hours pulling numbers into slides that are stale before the call ends. The Dashboard room replaces the ritual with a live surface.

A client dashboard is a drag-and-resize canvas of widgets, and the important ones wire directly to boards in the space:

• Stat tiles for the headline numbers — deliverables shipped, in progress, awaiting client review.
• Progress bars for phase or campaign completion.
• Bar and donut charts for the shape of the work — deliverables by type, by status, by channel.
• Recent-cards tables showing live board activity, so "what happened this week" answers itself.
• Manual-data widgets for the numbers that live outside Openbook — media performance, spend pacing — entered when they update, displayed alongside everything else.
• Text widgets for the narrative frame: this month's focus, next month's plan, a headline takeaway.

Because board-wired widgets update from the live boards, the dashboard is accurate on the random Tuesday the client checks it, not just the Friday you groomed it. The monthly call stops being a reveal of the deck and becomes a conversation in front of the live state — and the pre-call scramble shrinks to updating manual widgets and the narrative text. Deeper patterns in Dashboards and Reporting in Openbook.

Pair the dashboard with a written cadence: a weekly update post on the space feed — shipped, in review, next, needs-from-you — takes ten minutes and preempts the Friday-afternoon "any update?" email. For bigger engagements, a Project Status room adds structure: standing questions answered weekly, goals with red-amber-green status, and a narrative history a new client stakeholder can read to catch up on the whole engagement.

The internal agency space

Client spaces face outward. The agency itself needs one space that faces inward — the studio, with no clients in it:

• A feed for agency life: wins, announcements, kudos when a launch lands. With client work distributed across spaces, this is where the agency feels like one company. The feed's bulletin sidebar keeps announcements and birthdays visible.
• A new-business pipeline on a table board — the template library includes a sales pipeline — tracking prospects from lead to signed, with status, owner, value, and close-date columns.
• Time Off — request types, an approval queue, the who's-off view, and the team capacity chart. For an agency, capacity is the business: seeing that two of your three designers are out the week a campaign is due is the difference between reshuffling calmly this week and apologizing to a client next week.
• A resourcing board mapping people to client work, so account leads negotiate over a shared surface instead of competing calendar invites.
• Q&A for agency knowledge — how we handle rush fees, where brand assets live, what the revision policy is. Voted, accepted answers beat asking the ops lead the same question monthly.
• Retrospective rooms for post-project reviews. Agencies repeat project shapes constantly; an agency that retros its projects compounds, one that doesn't repeats its round-three overruns forever.

Meanwhile Chat — channels, DMs, presence, plus the floating widget on every page — carries the fast conversation layer everywhere, so coordinating on a proof does not mean leaving the proof.

Keeping rounds and scope honest

Revision rounds are where agency profitability quietly leaks, so it is worth wiring round-tracking into the workspace rather than into anyone's memory. Three mechanisms, all built from rooms you already have:

Count rounds where the rounds happen. Proofing's versioning gives you an objective round count per deliverable — version three is round three, visible to everyone. When the scope doc says two rounds are included, the conversation about round four starts from a shared fact ("we're on version four of this proof") instead of a reconstruction of email threads. Pair it with a custom field on the delivery board for round number, and the account manager can see at a glance which deliverables are running hot.

Make scope a living doc, not an attachment. The scope, the approver list, and the revision policy live in the space's docs room, where both sides can always find the current version. When scope changes mid-engagement — it will — the doc gets updated and the change gets a feed post. Six weeks later, nobody is arguing about which email amended what.

Convert scope creep into cards. When a request lands that is outside scope, the move is not to refuse it in a comment thread — it is to add it to the intake board flagged as out-of-scope, and let the client see it queued pending approval. The request is acknowledged, visible, and priced, all without a confrontation. Most scope disputes are really visibility disputes; a shared board dissolves them early.

Failure modes to avoid

The client-space model is robust, but a few recurring mistakes undermine it. All are cheap to prevent and expensive to fix.

• Inviting the client before visibility is set. The one mistake you cannot fully take back. Restricted rooms get configured before the first external invite, every time, checklist-enforced.
• Letting approval sneak back into email. One partner replying "approved!" to an emailed preview and the formal decision trail is broken. The countermeasure is gentle and total: work is reviewed in the proofing room, and emailed feedback gets a friendly "dropped this into the proof for you — decisions live there."
• A dashboard built once and never touched. Board-wired widgets stay live on their own, but the narrative text and manual-data widgets need their weekly minute. A dashboard with March's narrative in May reads worse than no dashboard.
• Overfilling the client space. Clients need four or five rooms, not eleven. Every extra surface dilutes the ones that matter. Keep the client-facing set minimal; add rooms only when the engagement demonstrably needs them.
• Skipping the internal space. Agencies that give every client a tidy space while running their own operation on scattered chat threads have consolidated for everyone but themselves. The studio space is not optional overhead; it is where capacity, pipeline, and learning live.

Onboarding a new client: the checklist

The first week of an engagement sets the collaboration pattern. The repeatable sequence:

1. Create the space from the Agency template. Name it predictably: "Client — Acme."
2. Prune and configure rooms. Drop what this engagement doesn't need; set per-room visibility on internal rooms now.
3. Load the scope. Brief, scope doc, and approver list into Docs; deliverables onto the board with dates and owners.
4. Build the dashboard before the client ever sees the space. A live dashboard on day one signals how the engagement will run.
5. Invite your team, then the client. Team first, so the space is inhabited; client contacts as Members (working level) or Viewers (exec level).
6. Post the welcome. A pinned feed post: what lives where, how review works, when the weekly update lands.
7. Run the first proof early. Even something small. The first annotate-decide-revise loop teaches the client the workflow better than any explanation, and it sets the norm that approval happens in the room, not in email.

An hour of setup per client, most of it template-assisted — and every subsequent client space is familiar ground for your whole team.

What this consolidates, and what it costs

The stack a client-space model replaces: a project management tool, a dedicated proofing tool, a client-portal product, a reporting deck workflow, and some fraction of email. Fewer licenses, but the larger win is the end of baton-passing — status, review, approval, and reporting stop being synchronization work between systems because they happen in one.

On cost: Proofing and Dashboards are Pro-plan features, so agencies should evaluate at the Pro tier — $15 per user per month ($12 annual), with a 14-day free Pro trial that fits a full client cycle. Business ($15, or $12 annual) adds SSO/SAML, audit logs, API access, and advanced permissions, which mid-size agencies tend to want once client count grows. Full details on pricing; the platform tour is at /product.

Next steps

• Pick one client — ideally a new engagement, where there are no habits to unwind — and run it fully on Openbook for one cycle: space, board, proofing loop, dashboard, weekly update.
• Use the trial to pressure-test the proofing workflow specifically; it is the piece that changes client behavior fastest.
• Once the first client space works, template your version of it mentally (room set, visibility pattern, dashboard layout) and roll it to the next two clients.
• Then build the internal agency space — pipeline, capacity, retros — so the studio runs where the client work runs.

Agencies sell coordination as much as creativity. Running delivery, review, and reporting in one workspace means the coordination stops being the product you rebuild every week — and starts being the thing your tools just do.