Nick QuirkMost agencies build one client dashboard, share the link with everyone on the account, and wonder why the CMO never opens it while the marketing manager asks questions that are answered on line four. The problem isn't the data. It's that a single view is trying to serve people with completely different jobs.
Custom client views solve this by filtering the same underlying project data through different lenses. One source of truth, three or four presentations. The executive sees outcomes and budget. The day-to-day contact sees this week's tasks and what's blocked. The in-house developer sees the technical backlog with ticket-level detail. Nobody has to scroll past someone else's priorities to find their own.
Why one shared view fails everyone
Run this test on your biggest account: open the client-facing project and count how many rows are relevant to the person who signs the invoice. On a typical SEO retainer with 60–80 active tasks per quarter, the answer is usually three to five. Everything else is implementation detail that dilutes the signal.
Meanwhile the marketing manager who lives in the account daily wants the opposite — she needs the 75 rows, because her job is unblocking them. Give her the executive summary and she'll email you for status three times a week.
The cost of getting this wrong is measurable. Agencies I've talked to spend 4–8 hours per month per client on status communication that exists only because the wrong people are looking at the wrong screen. On a book of 15 retainers, that's most of an FTE.
The four stakeholder archetypes
Almost every client organization sorts into the same four roles, regardless of company size. Build views for the roles, not for the individuals — people leave, roles don't.
1. The economic buyer (CMO, VP Marketing, founder)
Checks in monthly, maybe quarterly. Renews or cancels your contract. Cares about: is this working, are we on schedule, are we on budget.
Their view should contain no more than six elements: the two or three business outcomes you're accountable for (organic revenue, qualified sessions, share of voice), phase progress at a high level, retainer hours used versus contracted, and any decision that's waiting on them. That last one matters more than people think — a "waiting on you" block on the exec view has resolved more stalled approvals than any follow-up email I've sent.
What to leave out: task lists, individual keyword rankings, anything with a Jira-style ID. If you're tempted to include activity counts, read why activity metrics belong nowhere near an executive report first.
2. The day-to-day operator (marketing manager, content lead)
Logs in weekly or more. This is the person who actually uses your tool. Their view is closest to your internal board, minus internal margin data and rough drafts.
Include: active tasks with owners and due dates, items awaiting client input (highlighted, with a name attached), the next two weeks of scheduled work, and a running log of completed deliverables with links. Add a comment thread per task so questions land in context instead of in a Slack channel at 6pm.
The single most valuable field here is blocked by client. When a technical fix has been sitting with their dev team for 19 days, that number should be visible without anyone having to be diplomatic about it. It changes the conversation from "why isn't SEO working" to "we need dev capacity."
3. The technical implementer (in-house dev, IT, platform owner)
Doesn't care about your campaign narrative at all. Wants a queue: what to change, where, why, and how to verify it.
Their view is a filtered list of technical tickets only — audit findings, redirect maps, schema implementations, Core Web Vitals fixes — sorted by priority with acceptance criteria attached. Include the exact URL patterns, the current state, the target state, and a validation step. If your audit produces 340 findings, do not hand over 340 rows. Batch them into 8–12 tickets that map to a sprint.
Give this view its own notification settings. Developers will mute anything that pings them about content calendars.
4. Finance and procurement
Only worth building on retainers above roughly $10k/month or where a procurement team audits spend. Contents: contracted hours, hours delivered, deliverables completed against the SOW, invoice status, and contract end date. Nothing else.
This view has quietly saved renewals. When a new CFO asks "what are we paying these people for," a link that shows 142 of 160 contracted hours delivered against a documented deliverable list answers the question faster than a meeting.
Build once, filter many
The mistake that kills this approach is treating each view as a separate artifact. A 12-person agency with 20 clients and three views each is maintaining 60 dashboards. That collapses within a quarter.
The rule: every view must read from the same task and time data, with no manual re-entry. You change the filter, the permission set, and the layout — never the underlying record. If updating a client's status requires touching two places, one of them will be wrong.
Practically, that means:
- Tag at the task level. Every task gets a stakeholder tag (exec-visible, ops, technical) and a phase. Views are just saved filters on those tags.
- Set field permissions once. Internal notes, cost rates, and margin fields are hidden at the template level, not per project. One misconfigured project is a bad afternoon.
- Template the whole structure. New client onboarding should spin up all three views in under 10 minutes, pre-tagged, with the right people invited.
Tools differ a lot here. Some are excellent at internal flexibility but treat client access as a paid guest seat, which gets expensive fast at 3–4 stakeholders per account. Others let you share read-only views freely but can't hide cost data. It's worth checking how different PM tools handle client-facing views and permissions before you commit to a structure you'll have to rebuild. PeakKR was built around this specific problem — client views, hidden internal fields, and retainer hours in one place — but the principle holds whichever tool you use.
Naming, cadence, and access
Name views for the person, not the function. "Sarah's weekly view" gets opened. "Client Portal — Ops Layer" does not.
Match cadence to view. The exec view pairs with a monthly or quarterly call. The operator view pairs with a weekly 20-minute standup. The technical view pairs with whatever their sprint rhythm is. When the view and the meeting share the same data, the meeting gets shorter — we've seen 60-minute monthly calls drop to 30 because nobody spends the first half catching up.
Give real logins, not PDF exports. A client who can check status at 9pm on Tuesday doesn't email you Wednesday morning. If you're nervous about opening the doors, the case for letting clients into your PM tool covers the objections — and the failure modes to avoid.
Three mistakes to avoid
Building views before you've agreed on metrics. If the CMO thinks success is leads and you're reporting sessions, a beautiful dashboard just makes the disagreement more visible. Settle the KPIs that actually matter during onboarding, then build.
Hiding bad news in the ops view. If a campaign is underperforming, the exec view needs to say so before the exec finds out from their own analytics. A view that only shows green is a view nobody trusts by month four.
Over-customizing per client. Three templates covering 90% of accounts beats 20 bespoke setups. Reserve custom builds for your top three accounts by revenue.
A two-week rollout
Week one: pick your two largest accounts. Map who's actually on them (usually 4–6 people, more than you think). Build three views on one account. Week two: walk each stakeholder through their view on a 15-minute call, ask what's missing, adjust once. Then templatize and roll to the rest over the following month.
Expect one round of pruning. The first version of
