Episode 004 · Recorded September 30, 2026

Stop Making Up Your Community's Numbers

AI can build the dashboard in an afternoon. Proving what your community is worth still takes math you can check and the people you serve.

With Mark Birch, Founder, TribeROI · Author, Community in a Box

One idea

Community ROI has never been short of numbers; it has been short of numbers anyone can check. Mark Birch's answer is a bridge: C2 metrics that translate community signals into the business outcomes executives already measure, calculated with plain, deterministic math instead of proxy numbers picked to make the totals work. AI earns its place building your own tools and turning insights into next steps, like a draft email to members who are drifting. What stays human is the people connecting and the stakeholder conversations that define what value means, and what changed is that the dashboard is now the easy part.

Show notes

Overview

Sooner or later, every community manager hears the same question from an executive: what has the community done for us lately? It is the hardest question in the job, and it is getting harder as AI gets better. A dashboard now takes an afternoon to build, and so does a number that looks like value. Neither proves anything to the person who signs the budget. The work that does prove something has not changed: knowing which signals count, how they connect to the business, and showing your math.

Chris Heuer and his co-host Marius Ciortea build on the Daily Brief from the last episode by moving from what happened today to how the community is doing overall. Marius starts with the one health number he trusts. Then Mark Birch joins them. He is the author of Community in a Box and the founder of TribeROI, a platform that connects community activity to business outcomes. He walks through the framework behind it, the two mistakes he sees most often in community ROI, and the dashboard he built to avoid them. The episode ends on the metric Mark would retire for good.

Start with the login

Marius has looked at monthly active users in every report of his career, and he defines “active” more simply than most people are comfortable with. For him, it means a login. Starting a thread is worth more than replying to one, and updating a profile adds little, but those are later conversations. If people log in, they are doing something. If they don’t, they aren’t.

His rule of thumb is that a community under five percent monthly active can probably do better, with exceptions for communities built mostly for reading. His second number is daily active users divided by monthly active users. It shows how often the people who do show up actually come back: daily, weekly, or less. Those two numbers are his barometer. Everything after them gets complicated, and that is where the rest of the episode goes.

A community is a hypothesis

Mark came to community by accident. He started a New York meetup so other founders could talk about B2B sales without picking his brain one at a time. It grew into the Enterprise Sales Forum, which he describes as twenty-four chapters and thirty thousand members around the world. From there he went to Stack Overflow, working on its internal Q&A product, and then to AWS as a startup advocate in developer relations. Community in a Box, now in its second edition, came out of that work, and so did the question he has been chasing since: how valuable is a community?

The book’s core idea is to treat a community like a startup, and Mark’s version of that idea is a warning as much as an encouragement. AI can build the software. It can suggest ideas and point you somewhere you hadn’t thought to look. It cannot do the work of connecting people, and he calls relying on it for that a very poor decision. In a startup, distribution is most of the work. In a community, the equivalent is the conversations on the ground that tell you what people actually care about.

His own forum is the example. It began as founders over pizza and beer, swapping stories about selling to big companies. Then salespeople came, then sales leaders, then people from around the world, and the community became something its founder never planned. That is why Mark calls “build it and they will come” a terrible approach. Building still matters. It builds the muscle memory, and the experience of being wrong, that lets you build the next thing better. But the hypothesis only gets tested by talking to people.

Build what’s yours, lease what isn’t

The tools are real, and anyone can now use them. Mark built a browser extension in about half a day that hides the posts and sponsored content he doesn’t want to see on LinkedIn. Marius built the Daily Brief the same way: a first draft, then rounds of telling the AI what wasn’t right. Chris’s point is that this is open to every community manager. You are the solution to your own problems, and AI has given you the tools to act on that.

Mark draws the line at software other people depend on. Building something companies would pay for takes experience, taste and an understanding of architecture. Chris adds the costs that come after the build: maintenance, security updates and new features. He frames the old IT choice of build, buy or lease as a new one, build or lease. Build the tools that are unique to you. Lease the ones that carry a methodology, someone else’s years of experience, and improvements you would never get to on your own.

Signals, bridges, outcomes

Mark’s framework starts from something he noticed across the community world: everyone builds the same things in different ways and makes the same mistakes. In the book, he describes a community flywheel of content, events and connections. He also describes a way to tie activity to results that he calls C1, C2, C3.

C3 is the signals: what happens in forums, Slack, events and every other place the community lives. C1 is the business outcomes the community is expected to deliver. C2 is the part most teams skip, the bridge metrics that translate noisy signals into something a business stakeholder would recognize. At AWS, Mark had plenty of signals and no way to connect them to anything that mattered to the people funding the work. TribeROI is his attempt to build that bridge, and to make the result deterministic: the same inputs always give the same answer.

Marius adds the mistake he sees junior community managers make: tying the community to the department they sit in. A community that reports to marketing measures only marketing signals and misses what it does for support, sales and product. The community is responsible to the whole business, so it should count value the whole business can use.

Chris connects the bridge metrics to an idea he calls success proofs. Success proofs show the messy middle: what it actually took to get the result, not just the case study’s headline number.

Why proxy metrics fail

Mark sees two mistakes most often. The first is the proxy metric, a number someone picked to stand for value because it made the totals work.

“If I’m a CFO, I’m kind of wondering, like, okay, well, how did you come up with that number? What is your proof?” (Mark Birch, 24:42)

When there is no proof, the whole argument falls apart. The second mistake is forcing everything into a causal model, where every outcome needs direct attribution back to the community. Some value can be traced that way. Much of it can’t, and a model that counts only what it can trace throws away most of the value. Mark’s alternative is to measure across a full range of business outcomes, including retention, support cost deflection, education, expansion pipeline, hiring, referrals, product feedback and advocacy. He has defined fourteen of them in TribeROI.

Math you can check

The center of TribeROI is a health dashboard. Content, events and connections each get a pulse metric, and the three roll up into what Mark calls the community quotient, the community’s health score. All of it is calculated with plain math. He is blunt about why: he has watched people demo AI-generated community dashboards with obvious errors on screen, because the AI will tell you anything and nobody double-checks it. Here, every calculation is visible, and you can tune it to your type of community.

AI does have a place in his product, and it is the same place it has in the Daily Brief. It turns an insight into a next step. When members start to drift, one click produces a list of who is drifting and a draft email to reach them, ready for your email platform. A second view, the contribution dashboard, shows what the community has delivered for each business function over the last thirty or ninety days, or the past year. Mark calls it the “what have you done for me lately” dashboard. He shows both views on a demo community built with sample data.

Getting started without waiting on IT

You will probably need to partner with IT eventually, because live data connectors need API access. But you can start with CSV exports and work up from there, which Chris frames as crawl, walk, run. Mark says the platform is GDPR compliant and multi-tenant, so no one, including him, can see a customer’s community data. On cost, he describes a small setup fee and a monthly subscription of one to five thousand dollars, depending on the size of the organization and its data.

Start with the outcome

Marius’s closing advice is for anyone starting a community from scratch: start with the ROI. If you know which business outcome the community is meant to drive, you build it differently, and working backward from that outcome leads to better results.

Asked which metric everyone should retire, Mark doesn’t hesitate: drop the proxy metrics. Stop inventing numbers to make the business case work. Instead, ask your business stakeholders how they already measure their own results, because marketing and product teams have formulas proven in their own data. Use those.

Chris’s closing point covers the whole episode. AI is making the work easier, but someone still has to do it, and more importantly, choose which work is worth doing.

What’s ahead

The Daily Brief from the last episode is still free to download for Claude and ChatGPT. It is the daily half of this picture, and a good place to start your own community’s health report. To see how Mark connects community signals to business outcomes, visit TribeROI.

Chapters

Time Chapter
00:00 Welcome
01:35 Marius heads to Lisbon: zero to community in 20 minutes with MCP
03:41 How the Daily Brief skill was built
05:05 From a daily brief to a community health report
06:43 Marius’s one health metric: logins, MAU and DAU
09:37 Mark Birch joins
10:11 From a New York meetup to Community in a Box
13:18 Why AI can’t do the people connecting
15:31 “Build it and they will come” is a terrible approach
17:33 You are the solution to your own problems
18:18 Our sponsor: Higher Logic
19:05 TribeROI: C1, C2, C3 and bridge metrics
22:37 Don’t measure to your org chart
24:06 Why proxy metrics fail the CFO test
26:12 Build or lease your community tools
28:26 Inside the health dashboard: the community quotient
31:06 The “what have you done for me lately” dashboard
33:26 IT, security and cost
36:08 Start with the ROI
36:41 The one metric to retire

Key takeaways

  • Health starts with the login. Marius tracks monthly active users and counts a login as active. Under five percent monthly active, most communities can probably do better.
  • Two numbers make a barometer. Daily active users divided by monthly active users shows how often the people who do show up come back.
  • A community is a hypothesis. Like a startup, it changes once real people arrive, and only conversations on the ground show you what it is becoming.
  • AI can’t do the people connecting. It can build the software and suggest ideas. Relying on it to connect people is, in Mark’s words, a very poor decision.
  • Build what’s yours, lease what isn’t. Build the personal tools that are unique to you. Lease the software that carries a methodology, security and upkeep you would never get to on your own.
  • Bridge the signals to the outcomes. C3 is community signals, C1 is business outcomes, and C2, the bridge metrics, translates one into the other.
  • Measure for the whole business. Tying the community only to the department it reports to misses what it does for support, sales and product.
  • Proxy metrics fail the CFO test. A number picked to make the totals work falls apart the first time someone asks how you got it.
  • Not all value is causal. Insisting on direct attribution throws away most of what a community creates, from retention to support cost deflection.
  • Show your math. A health score built on deterministic, visible math can be checked. An AI-generated dashboard often can’t.

CommunityAssistant.ai Links

Co-host & sponsor

In this episode

About the show

CommunityAssistant.ai is the podcast and open resource library exploring the human work of community management: what AI can take off your plate, what only you can do, and how to grow into the role that’s coming. Hosted by Chris Heuer and Marius Ciortea. Season sponsor: Higher Logic.

Our sponsor. CommunityAssistant.ai is made possible by Higher Logic, supporting the practitioners who build the communities that matter.

Our independence. Sponsors make this show possible. They don’t make this show. Marius works at Higher Logic; he appears here as a practitioner speaking for himself, not for his employer.

Clips

What is the one metric to retire?

Asked which metric everyone should retire, Mark Birch doesn't hesitate: drop the proxy metrics, and use the numbers your business stakeholders already trust.

Can AI do the people connecting?

Mark Birch on what stays human: relying on AI to do the people connecting is a very poor decision.

What is the login metric?

Marius Ciortea keeps "active" simple: everything starts with the login. Measure it, set a baseline, and under 5% means you can probably do better.

Where should a new community start?

Marius Ciortea's advice for a fresh community: start with the ROI, and work backwards from the business outcome.

If AI makes it easier, what's left to do?

Chris Heuer's closing thought: things are getting easier, but we still have to put in the work and choose which work to do.

Made with Claude, not by it · CC BY-NC 4.0