The Augmented Community Model

Community management is having an identity crisis. AI tools promise to automate outreach, scheduling, and reporting. Most maturity models available today reward whoever automates the most with AI. The Augmented Community Model (ACM) takes the opposite position: AI automation is not the finish line, intentional AI use is.

ACM moves teams through three active stages: Manual, Assisted, and Augmented. Reaching Augmented does not mean maximizing AI automation. It means using AI with intention to strip away administrative drag, so leaders and members spend their time on each other instead of on logistics. This is a deliberate departure from prior maturity models, which treat full AI automation as peak performance.

A team that automates its newsletter with AI but forgets to check on a struggling member has not matured. A team that uses AI to free up two hours a week for 1:1 conversations has. The difference is not how much AI a team uses, it’s whether that AI clears space for connection or replaces it. The future of community is human + intention + AI.

ACM is a maturity model that community-based teams, nested within a larger institution, use to assess their team’s maturity. It measures three pillars: Community, Development, and Alignment. Community measures visibility and connection, Development measures how well the team grows future leaders, and Alignment measures how well the team’s work ties to institutional priorities. Each pillar is assessed on its own, and every pillar keeps a human-centered approach even as it adopts AI.

ACM is built for community builders who lead teams nested within a larger institution. It gives them a structured way to grow their team’s visibility, develop members into future leaders, and align with organizational priorities. It does this without asking them to trade away the human connection that makes the team worth joining in the first place. The chapters that follow walk through the three stages and define each pillar, with concrete markers for where a team stands and where it can grow.

Purpose

Since 2020, organizations have shifted from in-person strategies to online ones, and the operational impacts of that shift have been felt since early 2021 [1–3]. Teams have reported immediate post-meeting exhaustion, slower recovery between meetings and tasks, and lower meeting quality with less engagement [2]. That strain compounds emotional exhaustion and reduced well-being [3], and it makes the work itself more demanding and, at times, alienating [4]. Layer the loneliness epidemic on top of that [6], and the need for real community has never been more evident.

At the same time, artificial intelligence keeps gaining momentum, and organizations are struggling to balance community with innovation [5]. Show me an organization that isn’t trying to leverage AI, and I’ll buy you a drink. As a mentor once said, if I’m wrong, at least we’ll be having a drink together. As community builders adopt new tools, the question that keeps surfacing is simple: what does good look like? Ask any IT support engineer for the honest answer, and you’ll get the same one every time: it depends.

ACM was built to answer that question with something more useful than “it depends.” It draws on tested principles from organizations that have worked to grow community while also adopting AI, and it was designed to sit on top of whatever community model a team already uses. Having a roadmap means a team can tell whether they’re actually making progress or just throwing spaghetti at the wall and hoping it sticks. This whitepaper lays out that roadmap: Pillars and Stages.

The Community Maturity Model

The Community Roundtable developed the Community Maturity Model in 2009 to help organizations with community management, defining eight competencies and four stages that most significantly impact the development of a healthy, productive, and effective community [7]. Rather than treating community management as a static function, the model frames it as a journey of growth, and The Community Roundtable positions it as a tool for training stakeholders, assessing the community approach, benchmarking progress, and developing a roadmap [7]. The model also emphasizes the shift from treating community as a communication channel to treating it as a business driver, where the focus moves from member acquisition and moderation toward member value and actionable insight. That last move, from intuition to evidence, is the part most teams skip.

The Community Roundtable’s own 2026 research shows how hard that shift is in practice. Practitioners report that community is more strategic than ever and still under-resourced, with expansive roles, small teams, and a widening gap between what teams are expected to deliver and what they are resourced to sustain [8]. That study also found that measurement and ROI remain a persistent pain point, and that community leaders are being asked to operate as strategists, operators, facilitators, analysts, and advocates at once [8]. The model is sound, and the conditions under which it is applied are the problem.

The ERG Movement Model

The ERG Movement Model, introduced by Maceo Owens in 2022, is a targeted model for Employee Resource Groups. It is a business development framework rebuilt for ERG programs, and it deliberately parallels the development stages of a startup rather than the older progression from affinity group to ERG to business resource group [9]. Its five phases run from Infancy through Maturity, each with its own priorities, challenges, and milestones, and it names a sixth state, Broken Adolescence, for a program that launched without first laying its foundation. Its value lies in treating an ERG program as an operating system instead of a collection of events.

The model is also explicit about sequence, since the phases are developmental rather than optional, and what varies is the time spent in each phase, not the order [9]. That sequencing extends to technology, and the model argues that specialized ERG software belongs in the final phase, where it reinforces an operating model that already works rather than fixing a broken strategy [9]. That position is deliberate and defensible because it prevents a program from buying a platform to solve a governance problem. It also treats technology as something acquired at the end, which is a poor fit for a team whose institution already deployed AI tools across the entire company.

AI Maturity Models

Several reputable organizations have released an AI maturity model, including Microsoft, the U.S. General Services Administration, Gartner, and MIT Sloan. Two of them are close enough to each other to be treated together here. The UNESCO AI Maturity Framework helps organizations understand their current capacity to adopt and use AI responsibly, identify gaps, and determine how to progress toward a desired future state [10]. It declines to prescribe a single endpoint, treats AI maturity as a capability that develops across six pillars, and describes four levels that run from informal or reactive practices toward integrated, measured, and continuously improving capabilities [10].

The MITRE AI Maturity Model

The MITRE AI Maturity Model is similarly intended to help organizations assess where they are in their AI adoption journey and establish a practical path for increasing their ability to implement AI successfully [11]. Its orientation is more explicitly focused on organizational adoption, and it ships with an assessment tool that scores one multiple-choice question per dimension [11]. MITRE also recognizes that the appropriate level of maturity depends on an organization’s mission and circumstances, and states plainly that the highest maturity level in all dimensions may not be practicable or relevant [11]. Both models share a premise worth noting: AI maturity is an organizational progression toward more intentional and measurable capability, not a tally of tools purchased.

How ACM is different

Every model above solves half of the problem. The Community Maturity Model and the ERG Movement Model both take community seriously as an operating discipline, and both stop before AI enters the picture. UNESCO and MITRE both take AI seriously as an organizational capability and assess the institution rather than the teams within it. Nobody wrote the model for the team, which is the unit where the community is actually built and the unit that each of these models scopes beyond.

What ACM takes from the models that came first

ACM borrows liberally, and the sources are worth naming.

1. 01

   Progression, not a pass/fail grade. The Community Maturity Model treats community management as a journey rather than a static function, and ACM keeps that posture across every sub-pillar [7].

2. 02

   Maturity is not a mandate. MITRE says the appropriate level of maturity depends on the organization’s mission and circumstances, and that the highest level may not be practicable or relevant [11]. ACM says the same thing out loud.

3. 03

   Structure underneath the headline. The Community Maturity Model’s competencies and MITRE’s dimensions both proved that a maturity model needs sub-parts to be usable [7], [11]. ACM’s sub-pillars do that job.

4. 04

   The team is an operating system. The ERG Movement Model treats an ERG as a structured, governed program rather than a pile of events, and ACM applies the same approach to any nested team [9].

5. 05

   Descriptive states over prescriptive steps. UNESCO describes capability states and declines to prescribe a target level [10], which is why ACM is a model and not a framework.

Where ACM breaks from them

The first break happens at the top stage. In the ERG Movement Model, specialized software belongs in the final phase, where it reinforces an operating model that already works [9]. In the AI maturity models, higher maturity reads as more integrated, more automated, and more measured, with UNESCO’s top level describing deeply embedded capabilities and MITRE’s top level describing continuous improvement through monitoring [10], [11]. Both of those are reasonable positions, and both point in the same direction: the more the machine does, the more mature you are.

The Augmented Community Model points somewhere else. Its top stage is not the stage where AI does the most work, it is the stage where a team uses AI with intention. AI should support human connection, not automate it away, and the goal is to remove the administrative friction so people can spend their time building community with each other. A team that has automated its welcome message, its check-ins, and its recognition has not matured; it has reached a place where nobody has to talk to anybody.

That position is not a hunch. The Community Roundtable’s 2026 research found that AI is reshaping community without replacing its core value, and that while AI is efficient at delivering answers, it cannot replicate trust, shared context, judgment, or lived experience [8]. Practitioners in that study caution specifically against letting AI replace peer interaction or obscure the human presence that gives communities their meaning, and recommend using AI behind the scenes to synthesize insights instead [8]. McKinsey makes a parallel argument about work generally, and observes that as AI absorbs coordination, execution, and routine decision-making, human roles shift up the value stack toward setting objectives and making trade-offs [12]. ACM is the community-side version of that same move.

The second break is scope. The Community Maturity Model and the AI maturity models are built for the enterprise, and they assess the organization as a whole [7], [10], [11]. The ERG Movement Model gets closer, and it is still scoped to the ERG program rather than to the individual team inside it [9]. ACM is scoped to the team, which is where the work of building community actually happens and where nobody has ever been given a scorecard.

The third break is the floor. McKinsey’s manifesto argues that companies can accelerate through building capabilities, but cannot skip the foundational work, because value compounds as capabilities build on one another [12]. ACM applies that to the team, and its lowest active stage is not a failure state. It is the stage where a team learns what its work actually consists of before handing any of it to a tool. Skipping that step produces a team with automated workflows and no idea what those workflows are for.

Manual

Manual means the team runs on ad-hoc or manual effort, with no AI or consistent tooling involved in that pillar. This isn’t a failure state. Most teams start here in most pillars, and newer or smaller teams often have no business being anywhere else yet, since manual work is what forces a team to figure out what actually needs doing before automating any of it. The risk isn’t being at Manual, it’s staying there past the point where manual effort is quietly burning out the people doing it.

Assisted

Assisted means the team uses AI and other tools, but inconsistently, without a shared process behind them. This is the messiest of the three stages, the one where several tools run in parallel, one leader has a workflow nobody else uses, and part of the team is still doing by hand what another part has already automated. It’s also, counterintuitively, riskier than it looks, because inconsistent tooling creates the appearance of progress without the friction reduction that progress should actually deliver. A team at Assisted has usually reached for AI before agreeing on what problem it was supposed to solve.

Augmented

Augmented means the team uses AI intentionally to remove friction, and intentionally is the entire point of that sentence. This is not “automate everything,” and a team that maximizes automation without asking what it costs in human connection has misunderstood Augmented entirely. A team at this stage has made a specific, deliberate decision about what AI should touch, administrative drag, scheduling, tracking, reporting, and what it shouldn’t, mentorship, belonging, the actual relationships. This is the stage the model is built around, not because it’s the top of a ladder to climb, but because it’s the only stage where AI is doing its job, clearing space for people to spend more time on each other.

Pillar one

Community

Community measures how visible and connected a team is, among its members, within the institution, and to the outside world. This pillar exists because visibility and connection don’t happen automatically just because a team is doing good work. A team can execute flawlessly on its core mission and still be functionally invisible to the people who decide its budget next year. Community is often the first thing sacrificed when a team is stretched thin, which is exactly why it needs its own dedicated metric rather than being folded into a general sense of how things are going. It breaks into three sub-pillars: Team, Organization, and External.

Pillar two

Development

Development measures how well the team grows its members into future leaders. This pillar exists because a team that delivers excellent results today but produces no future leaders is a machine running on its current operators, not an organization built to outlast them. Growth has to be intentional because the default state of most teams is that whoever is willing to do the work keeps doing it indefinitely until they burn out or leave. Development is what turns a team from a set of current contributors into a pipeline of people ready to take over when today’s leaders inevitably move on. It breaks into two sub-pillars: Individual and Pipeline.

Pillar three

Alignment

Alignment measures how well the team’s goals and progress align with institutional priorities. This pillar exists because a team can be valued by its members and still be functionally irrelevant to the institution hosting it, and irrelevance is what gets a budget zeroed out during the next round of cuts. Being valued internally is not the same as mattering to the institution, and teams that confuse the two are usually the ones blindsided when support disappears. Alignment is the pillar that keeps a team’s existence tied to something the institution actually needs, not just something its members enjoy. It breaks into two sub-pillars: Objective and Awareness.

Manual to Assisted

Moving from Manual to Assisted is usually the easiest transition to start and the easiest one to get wrong. The hard part isn’t finding an AI tool; it’s picking the right task to point that tool at first. A team that lets AI automate the wrong thing, say, a newsletter nobody reads, ends up with a shinier version of a problem that didn’t need solving. The right first move is a task that’s both repetitive and currently eating time that could go toward people instead: outreach, scheduling, or logistics tracking are the usual suspects. Getting this transition right means the team feels friction disappear somewhere specific, not “AI everywhere all at once.”

What Manual looks like:

• Individual members may be experimenting with AI tools, but the team has no shared approach
• Leadership is still learning what AI could do for the team and how other teams are using it
• Any AI use lives with one person. Nothing is documented, so each new leader starts from scratch

Steps to move to Assisted:

1. 01Identify which sub-pillar is burning the most manual hours right now
2. 02Pick one recurring task in that sub-pillar and introduce a single AI tool to handle it
3. 03Leave every other sub-pillar alone for now
4. 04Give the tool a few cycles to prove itself before layering on a second one
5. 05Check whether the time saved actually went to people, not just to a different task

Assisted to Augmented

Moving from Assisted to Augmented is a different kind of work because the team already has AI in the building. The problem is that there isn’t a shared vision for it. This transition is less about adding tools and more about pulling the scattered ones into a single, intentional approach the whole team actually uses. That usually means retiring the workaround one leader built for themselves and replacing it with something everyone can rely on. It also means drawing a hard line around what AI still shouldn’t touch: mentorship, belonging, and the actual relationships, so intentional use doesn’t slide into maximum automation by accident. The signal a team has crossed into Augmented isn’t more automation, it’s leaders spending measurably more time on people instead of process.

What Assisted looks like:

• The team is testing AI on specific tasks, but there’s no consistent process for it yet
• Different members use AI differently. Some approaches free up time for connection, others don’t, and there’s no shared standard to tell which is which

Steps to move to Augmented:

1. 01Audit every AI tool already in informal use across the team
2. 02Consolidate overlapping tools into one shared, documented process
3. 03Decide explicitly what AI should never touch in this sub-pillar
4. 04Track whether reclaimed time is going toward relationships, not just a new task
5. 05Revisit the decision periodically, since intentional today doesn’t guarantee intentional next year

Maturing the Community pillar

Community moves through its three sub-pillars in a rough order, even though nothing forces a team to follow it. A team can be strong on Team belonging while External sits at Manual with nobody minding it, and that’s not a contradiction, it’s the model working as intended. The sensible path starts with Team, since a team that hasn’t secured its own members’ belonging has no business worrying about visibility to the institution or the outside world. Organization comes next, because institutional support depends on that internal strength being visible before anyone asks the team to represent itself externally. External comes last, since a reputation built outside the institution rarely survives scrutiny if nothing solid backs it up on the inside.

Maturing the Development pillar

Development’s two sub-pillars move in a specific order, and it’s not optional. Individual growth has to exist before Pipeline means anything, since a succession plan is worthless if there’s nobody being developed to fill it. A team that jumps straight to formalizing Pipeline without investing in Individual coaching first ends up with a tracking spreadsheet and no one ready to use it. The realistic path builds consistent, AI-supported growth conversations at the Individual level first, then layers succession tracking on top once there’s an actual bench to track. Teams that get this backwards discover the gap the same way every time, at the exact moment a leader leaves and the “plan” turns out to be a name on a slide.

Maturing the Alignment pillar

Alignment is the one pillar where the two sub-pillars can, and often should, move together. Objective without Awareness leaves a team doing the right work and getting no credit, while Awareness without Objective is just marketing for effort that was never institutionally relevant to begin with. The two reinforce each other closely enough that maturing one without the other is rarely worth the trouble. A team ready to move Alignment forward should treat “surface the priorities” and “report the work” as one initiative, not two, since an AI research tool identifying institutional priorities is only half useful without the reporting habit that shows leadership the connection was made. Teams that mature Alignment well are the ones nobody has to explain their value to twice.

Assess your team with the ACM assessment tool

Assess Your Team Today