Agency reporting tool: live dashboards without per-seat fees

Shopping for an agency reporting tool usually means shopping for a pricing table: tiers by number of clients, add-ons by number of seats, an enterprise call when you outgrow both. The reporting work itself is nearly identical for client five and client fifty — connect sources, apply definitions, publish something the client can read — yet the bill climbs with every logo you add. This article lays out a different architecture: an AI-agent-driven data backend where each client is a workspace, each deliverable is a live self-refreshing URL, and the people reading reports are never billable seats. It's not the right choice for every agency — the last section is honest about who shouldn't use it — but if your team already works with agents, the cost curve looks very different.

The cost curve every agency reporting tool hides

Reporting SaaS pricing has a shape, and the shape is the problem:

• Per-client tiers. Ten clients is one price, twenty-five is another, "unlimited" is a sales conversation. Growth in your book of business is growth in your tooling bill, mechanically.
• Per-seat charges. Every account manager who needs to touch a report is a line item. Teams route around it by sharing logins — which tells you what the pricing model is really worth.
• The viewer tax. Some tools even meter dashboard viewers or white-label portals, so your client's CMO opening a report costs you money.

None of this maps to actual marginal cost. Once the connectors exist, syncing the eleventh client's Google Ads account costs the vendor pennies. The tiering is a rent on your growth, priced against the assumption that humans do the reporting work and humans are what you'll pay for.

A different architecture: the agent does the reporting

That assumption is what changed. TableBI is built as "the data backend for your Claude Code" — Claude Code being Anthropic's terminal-based coding agent. The model splits cleanly: your agent is the brain (it writes queries, reads results, drafts the week's narrative), and TableBI is the data layer underneath — it syncs the sources, enforces consistent metric definitions, and freezes analyses into live dashboard URLs. Three verbs cover the whole workflow: Pipe sources in, Ask read-only SQL, Pin dashboards.

Two properties of that split matter for agency economics:

• TableBI hosts no LLM — $0 inference. The reasoning runs in your own agent session under your own key. The backend serves deterministic SQL results with lineage, so there's no metered "AI insights" line item.
• Deliverables are public read-only URLs. A pinned dashboard refreshes itself (on access and on schedule) and anyone with the link can open it. Clients, their bosses, your whole pod — viewers are structurally not seats.

We walk through the single-client version of this workflow — the live link as the deliverable, the "ask" button that routes client follow-ups back to you — in the client reporting tool guide. Here, the interesting part is what happens at ten or forty clients.

One workspace per client

Multi-client separation is a first-class flag, not an enterprise feature. Every TableBI command takes -w (workspace); each client's sources, queries and dashboards live inside their own workspace and can't bleed across:

# onboarding two clients — each into its own workspace
tablebi connect gsc --site sc-domain:example.com -w acme
tablebi connect meta_ads -w acme
tablebi connect google_ads -w acme

tablebi connect ga4 -w bristol
tablebi connect google_ads -w bristol

# offline sources normalize in the same way
tablebi connect csv --file tiktok-export.csv --platform tiktok_ads -w bristol

Each connect is one OAuth round-trip in the browser, once. After that the client's data syncs into two altitudes: facts — the cross-channel table where every platform's spend, clicks, conversions and conversion value share one set of definitions — and the raw layer (meta_ads_raw, search_console_raw, …) holding each platform's native rows lossless. Onboarding client eleven is the same five minutes as client one. That's the marginal cost story: the expensive part of multi-client reporting was never storage — it was human hours, and those moved to the agent.

The Monday morning run

Here's the loop that replaces reporting week. Before the Monday standup, your agent iterates the roster — same questions, every workspace:

# for each client workspace: what moved last week?
tablebi ask -w acme "SELECT platform, campaign, SUM(cost) AS spend,
             roas(SUM(conversion_value), SUM(cost)) AS roas
             FROM facts WHERE date >= (SELECT MAX(date) FROM facts) - 7
             GROUP BY platform, campaign ORDER BY spend DESC"

# anything burning money with nothing to show for it?
tablebi ask -w acme "SELECT campaign, ad_group, SUM(cost) AS spend
             FROM facts WHERE date >= (SELECT MAX(date) FROM facts) - 7
             GROUP BY campaign, ad_group
             HAVING SUM(cost) > 0 AND SUM(conversions) = 0
             ORDER BY spend DESC"

The agent reads the results, flags what changed, and updates or pins dashboards where the story moved — tablebi pin -w acme --title "Acme — weekly" --widget "…" publishes straight to that client's URL space. The client-facing links themselves never needed the run: they re-pull from sources on access and on schedule. What the Monday run produces is the part machines can't skip and humans shouldn't do by hand at 7am — knowing which of forty clients needs a conversation today.

Every answer arrives with a trust block — per-source freshness, caveats, metric lineage — which is what makes it safe to let an agent brief you. When Meta's numbers are a day behind Google's, the answer says so; nobody walks into a client call with a mismatch they can't explain. If paid social is your heaviest reporting surface, the Meta ads reporting walkthrough goes deeper on exactly these queries.

The portfolio view: every account in one query

Workspaces are a separation boundary you choose, and there are two useful patterns. For strict client isolation, one workspace per client — a client-facing link can only ever show that client's data. But for properties you're allowed to see side by side — your agency's own sites, a portfolio you run under one engagement — connect them into a single workspace and the account dimension gives you the bird's-eye view in one query:

# every account in the workspace, ranked — one query
tablebi ask "SELECT account, platform, SUM(cost) AS spend,
             roas(SUM(conversion_value), SUM(cost)) AS roas,
             cpa(SUM(cost), SUM(conversions)) AS cpa
             FROM facts WHERE date >= (SELECT MAX(date) FROM facts) - 28
             GROUP BY account, platform ORDER BY spend DESC"

That's the query a traditional stack answers with an all-hands spreadsheet exercise: which accounts are scaling, which are stalling, where the next churn risk is hiding. Pin it, and the partners have a portfolio dashboard that's never out of date.

What scaling actually costs

Put the pieces together and the cost curve flattens:

• Viewers are free by construction — dashboards are public read-only URLs, so clients and stakeholders never become seats.
• The analyst headcount is an agent — the querying, comparing and narrating runs in Claude Code sessions your team already has open, at $0 additional inference on the TableBI side.
• Onboarding is constant-time — a new client is a workspace plus a few OAuth clicks, not a plan upgrade.

We deliberately don't quote numbers in blog posts — plans change; the pricing page is the source of truth. The structural point stands regardless of plan: nothing in the architecture meters your client count against your report readers, because neither of those is where the work happens anymore. For the broader workflow this unlocks beyond reporting — anomaly checks, budget questions, ad-hoc analysis — see Claude Code for marketing.

When a traditional reporting SaaS is still the right call

Honesty over conversion: if nobody on your team uses a CLI or works with an agent, don't buy this. TableBI has no drag-and-drop editor, no template gallery your junior AM can click through, and no white-label PDF export — dashboards carry a "Powered by TableBI" footer. A traditional agency reporting platform earns its price when the people doing the reporting work are humans who want a GUI, and that's a perfectly good way to run an agency.

The fit test is one question: is there at least one person (or one standing agent workflow) in your shop that lives in the terminal? If yes, that one person plus an agent can carry the reporting load for the whole roster, and the economics above are real. If no, revisit this when your workflow changes — the category is moving in this direction faster than most pricing pages are.

FAQ

npm i -g @tablebi/cli && tablebi install