You know your company needs a community. You've watched support teams drown in tickets that engaged users could answer for each other, and you've seen product teams fly blind without a feedback loop.
But you can't get anyone to fund it.
You're pitching to executives who can't quantify the ROI of customer conversations, who reflexively compare a purpose-built platform to a Facebook Group they could set up for free, and who won't own a budget line item they can't defend in a downturn. The approval cycle stretches into quarters because no one on the buying committee has "community" in their job title.
My advice: make community happen without waiting for the org chart to catch up.
Community platforms have a specific problem in any organization with a procurement process: the value is real, but it's both diffuse and long-term. When someone pitches a CRM, they point to pipeline metrics. When pitching a help desk, they cite ticket resolution times. When you ask for a community, you're promising customer relationships, knowledge sharing, reduced support burden, and product feedback. All of it real, all of it hard to quantify in a procurement spreadsheet.
The people who understand community value are practitioners: developer advocates, customer success managers, support leads, and product managers who've seen what an engaged user community can do. The people who control budgets are executives who may not know what community participation even looks like.
Getting a community approved top-down means convincing skeptical executives to fund something they don't viscerally understand; going bottom-up means demonstrating value so clearly that the organization has no choice but to invest in what you've already built.
You need a place for users to ask questions and share knowledge. You don't have budget approval for a community platform, but you have free time and a free tier.
So what do you do? You go for it.
You start a community, invite some power users, and funnel support questions there instead of into the ticketing system.
Six months later, the community is load-bearing infrastructure. Support costs are down because users answer each other's questions. Product monitors discussions for feature requests and bug reports. Marketing pulls success stories from community threads, and sales points prospects to the community as proof of an engaged customer base. Your scrappy experiment has become something the company depends on, and the conversation with procurement is about upgrading to a paid plan, not whether to adopt a platform at all.
This is how communities built on Discourse spread in companies: one practitioner at a time, one unsanctioned experiment at a time, until the platform is too embedded to rip out.
If you want to build a community your organization can't live without, move before anyone tells you that you can.
Pick a platform with a free tier generous enough to prove value before anyone asks hard questions. Skip procurement approval, legal review, IT security assessments, and budget cycles. Use templates and defaults that make your community look alive rather than empty, and get your first engaged members within a week. If you can't show early results, you'll lose organizational patience before you've built anything worth defending.
Slack understood this when they built their freemium model around team adoption rather than company-wide procurement. A single team could start using Slack without asking permission, and by the time IT noticed, twelve teams depended on it. The same playbook works for community: make something useful enough that removing it would cause visible organizational pain.
Think of it as building proof before you need permission, rather than going rogue permanently.
Bottom-up adoption changes the internal conversation.
You're not persuading executives that community software is worth buying (painful), you're justifying what you've already built (much easier). The community exists with active members and generates measurable value. The discussion is about investing in better infrastructure for something that already works, not taking a chance on an unproven category.
The burden of proof flips. In a top-down pitch, you argue hypotheticals against procurement's default skepticism. When you've built something bottom-up, you point at results and ask whether the organization wants more of them.
At this point, the sales team at your platform vendor become allies. They provide security documentation and negotiate the contract, while connecting you with the people who can approve larger budgets. But you've already done the hard part: you built something your organization can't live without.
To turn your experiment into a company commitment, you need to be holding some specific cards:
Building your own bottom-up adoption is slower than landing top-down approval, but it's more durable. You built this thing, and you have skin in the game that a top-down buyer never develops. You'll fight for your platform when procurement suggests cheaper alternatives, because you know what it actually does for your organization.
The fastest path to getting community adopted at your company doesn't run through procurement. It runs through you, the contributor with a problem, with passion, and a platform with a free tier.
If you build something your company depends on, the rest will take care of itself.
Sarah manages the team that builds Discourse. She's passionate about technology and people — online community is what happens when the two collide.
