Replace Zendesk with a Community: How Fly.io, Vercel, Cursor, and n8n Do It (and How to Do It on WordPress)

If you opened a support ticket with Fly.io, Vercel, Cursor, n8n, or Cloudflare in the last 12 months, you probably did not open a ticket at all. You posted in their public community forum. An engineer or an experienced community member answered. The thread got indexed by Google. The next person with the same question found the answer without contacting support at all. That pattern, public-first customer support, has quietly become the default at modern developer-facing SaaS companies. It is also one of the largest single cost-saving moves a SaaS team can make. Zendesk pricing per agent does not scale; community-first support compounds.

This post is about why the shift is happening, the architecture pattern that makes it work, and how to run it on WordPress with a forum plugin instead of paying a SaaS community platform to host the same thing on their stack. It is a technical post about a business decision. By the end you will know whether the model fits your company, what to build if it does, and what the real cost difference looks like at 1,000, 10,000, and 100,000 supported users.

This is also the underlying argument for why we built Jetonomy, which is the WordPress forum and Q&A plugin we ship for clients running this pattern. The pattern works on Discourse too. The pattern works on Khoros and Vanilla. It works wherever you have public threads, search, accepted answers, and trust levels. The question this post answers is: when does it make sense to run it on WordPress instead.

The economic problem with ticket-based support

Zendesk publishes their per-agent pricing on the front page. As of mid-2026, the Suite Team plan is $55 per agent per month. Suite Growth is $89. Suite Professional is $115. Suite Enterprise is $169. That is the floor. Most companies running Zendesk in production also pay for the answer bot add-on, the workforce management add-on, the WhatsApp add-on, and the AI agent add-on, which push the effective per-agent cost to $200 to $400 per month at any meaningful scale.

The per-agent number is the headline. The per-ticket number is the real cost. Industry studies from Forrester and Zendesk’s own benchmark data put the fully loaded cost per ticket at $15 to $25 for digital channels (chat, email, ticket forms) and $35 to $65 for voice. That number folds in agent salary, software, training, management overhead, and tooling. At a steady-state 200 tickets per week for a small SaaS, that is $156,000 to $260,000 per year in support cost. At 2,000 tickets per week for a mid-stage SaaS, the same math runs to $1.5 million to $2.6 million per year.

This is the cost growing teams quietly accept as their support volume scales. It is also the cost a community-first pattern can cut by 20 to 40 percent.

How Fly.io, Vercel, Cursor, n8n, and Cloudflare actually do it

The companies above all run customer support primarily through a public community forum, with private ticket escalation reserved for paying tiers and security-sensitive issues. The architecture is consistent across all five. Look at any of them and you will see the same shape:

• Fly.io runs community.fly.io on Discourse. Their engineers respond publicly. Issues get categorized, tagged, and become permanent indexed knowledge.
• Vercel runs support through GitHub Discussions on the Next.js repository plus a Discord, with private ticket escalation reserved for Pro and Enterprise customers.
• Cursor runs forum.cursor.com on Discourse for community support and bug reports.
• n8n runs community.n8n.io on Discourse and answers a substantial portion of customer questions there.
• Cloudflare has run community.cloudflare.com on Discourse for years and uses it as the primary first-tier support channel for free and lower-tier customers.

Other companies running the same pattern publicly: Hashicorp on discuss.hashicorp.com, Supabase on GitHub Discussions, Pulumi on GitHub Discussions, Stripe on Discord plus a forum, Sentry on Discord plus GitHub Discussions, and dozens of OSS-backed SaaS companies whose product itself ships with a developer audience.

The companies that have not switched yet tend to be in two camps: enterprise-only SaaS where every customer is paying a five-figure ACV and ticket-based SLAs are part of the contract, and consumer SaaS where users do not self-organize into a help-each-other community pattern. Most B2B SaaS in between, especially developer-tool and creator-tool companies, are either already on the pattern or actively planning the migration.

Why this pattern compounds (and the ticket queue does not)

The reason ticket queues feel like a treadmill is that every ticket creates value only for the one customer who opened it. The answer, the workaround, the version note, the link to the documentation, all of it gets sent in a private email and then disappears. Three weeks later, a different customer hits the same issue and opens a new ticket. The agent writes the same answer. The cycle does not break.

A public community thread breaks the cycle. The answer is written once. The thread is indexed by Google. The next person searches and finds it without ever contacting support. The thread accumulates. Over 12 months, the forum becomes the primary self-service knowledge base, and it is written by your engineers, validated by your power users, and updated by the community as things change.

Three measurable effects compound:

• Ticket deflection. Industry data from Khoros, Higher Logic, and Vanilla puts deflection rates at 20 to 40 percent for mature community-first support programs. That is the percentage of would-be tickets that get answered by community search before the customer contacts you.
• Answer reuse. The same Q&A thread can answer hundreds or thousands of users over its lifetime. We have seen single Discourse threads at fly.io accumulate 20,000+ views from search traffic, all of which would have been tickets in a private model.
• SEO surface. Public forum content gets indexed. As Reddit and Stack Overflow have demonstrated, forum content ranks well on Google for long-tail technical queries. Your forum becomes a top-of-funnel acquisition channel, not just a support cost center.

The flip side, the part the marketing pitches for these platforms tend to gloss over: community-first support is a structural commitment, not a tooling decision. The forum will not run itself. You need engineers willing to answer publicly. You need a community manager. You need trust levels that promote helpful users to moderators. You need to set the cultural expectation that posting publicly is normal. Most teams that fail at this pattern fail at the cultural commitment, not the tooling.

The architecture: public Q&A plus private escalation

The pattern that works is not “fire the support team and tell customers to use the forum.” It is a tiered architecture:

1. Tier 0: Documentation. Static docs, written by the docs team. First answer for known questions.
2. Tier 1: Public community Q&A. The forum, with Q&A mode enabled, accepted-answer flagging, and trust levels that let proven users help moderate. Free customers, lower-tier paid customers, and curious prospects all post here. The forum is searchable and indexed by Google.
3. Tier 2: Private escalation. A ticket form (could still be Zendesk, could be Plain or HelpScout, could be email) reserved for higher-tier paid customers and security or billing issues that should not be public. The forum has a “this needs private support” button that routes to the ticket system with context attached.
4. Tier 3: Direct engineering escalation. Slack Connect or shared Slack channels with enterprise customers, for the rare cases that need a real-time engineer in the loop.

The deflection happens between Tier 0 and Tier 1. Customers who would otherwise have opened a ticket search the forum first, find the answer, and never escalate. The forum is sized for the broad customer base. The ticket system is sized only for the cases that genuinely need privacy or paid SLA response.

This is the architecture Fly.io, Cursor, Cloudflare, and the others all converged on independently. It is not a coincidence. It is what works when you do the math on per-ticket cost vs per-thread cost at scale.

Why WordPress is a serious option for tier 1

If you accept the pattern, the next question is where to run the public forum. The realistic options are:

• Discourse (self-hosted or hosted). The default choice. Mature. Excellent. Self-hosted is free; the hosted plans start around $100 per month and scale with active users.
• GitHub Discussions. Free if your product is in a public GitHub repo. Works well for OSS-flavored SaaS. Limited for non-developer audiences.
• Vendor SaaS (Khoros, Vanilla, inSided, Higher Logic). Enterprise-grade. Per-active-user pricing. Quotes start in the tens of thousands per year and scale fast.
• Hosted community platforms (Circle, Mighty, Skool). Designed for paid creator communities, not customer support. Lack Q&A mode and accepted-answer flagging that customer support actually needs.
• WordPress with a forum plugin. The architecture this post is about.

The case for WordPress is straightforward and the case against is also straightforward, so we will name both.

The case for WordPress:

• You probably already run WordPress. The marketing site, the blog, the docs site, the customer portal, the changelog all live on a WordPress install for many SaaS companies. The support forum lives in the same admin, with the same user accounts, the same SSO, the same theme, the same brand surface. No second login, no second tool, no second team to maintain.
• SEO and content integration. Your forum threads, your marketing pages, your docs all share one domain and one site map. Google treats it as one trusted source. Forum content boosts the entire domain’s topical authority. Discourse-on-subdomain gets a fraction of this benefit.
• Cost structure. Self-hosted WordPress with a forum plugin is a one-time license plus hosting. No per-user, per-agent, or per-active-member pricing. A community that grows from 1,000 to 100,000 supported users does not cost 100x more.
• Custom development is normal. WordPress’s plugin and theme ecosystem means custom workflows (escalation routing, SSO with your auth provider, custom badges, integration with your billing system) are straightforward to build. Discourse can do this too with their plugin system, but the WordPress ecosystem for custom dev is broader.

The case against WordPress:

• Discourse is the proven default. If you want the absolute best-in-class forum software with the deepest feature set, Discourse is still it. WordPress forum plugins have closed most of the gap (Q&A mode, trust levels, accepted answers, REST API) but Discourse has 12 years of dedicated focus on this exact use case.
• Operational discipline matters. Self-hosted WordPress requires you to handle updates, backups, security patching, and scaling. Discourse hosted absorbs all of that. If your team does not already operate WordPress in production, the operational cost may eat the licensing savings.
• Mobile and notification UX. Discourse’s mobile experience and notification handling are slightly more polished than what most WordPress forum plugins ship out of the box.

For SaaS companies that already run WordPress in production and have engineering bandwidth to operate it, the WordPress route is the lowest-cost, highest-integration option. For teams that do not run WordPress, Discourse is the safer choice and we recommend it without hesitation.

How Jetonomy implements the pattern

Jetonomy is the WordPress forum and Q&A plugin we ship for clients running the community-first support pattern. The free version on WordPress.org covers everything in the tier-1 description above. The specific features that matter for this use case:

• Q&A mode per category. A support category can run in Q&A mode, which means each thread has a question, multiple proposed answers, votes, and one accepted answer flagged by the original poster or a staff member. This matches the Stack Overflow pattern that customers expect from a technical support forum.
• Six trust levels. Modeled on Discourse. New users start with limited posting rights and earn moderation privileges as they contribute. Promoted users handle the routine moderation that would otherwise eat your community manager’s day.
• 48 REST API endpoints (free) plus more in Pro. Every forum action (post, reply, vote, flag, escalate) is accessible via REST. This is what lets you build the escalation bridge to your private ticket system. When a thread hits a “needs paid escalation” criterion, an automation pushes the thread context into Zendesk or Plain.
• SSO with your existing auth. Forum users authenticate through the same provider as your main product. No second account. The user’s plan tier (free, Pro, Enterprise) is visible in their forum profile and used for escalation routing.
• Schema-marked Q&A. Threads in Q&A mode emit QAPage schema markup, which is what triggers the rich Q&A snippet treatment in Google search results. This is how forum threads end up at the top of long-tail technical searches.

The Pro tier adds AI moderation, semantic search, real-time reactions, web push notifications, custom badges, and a few other things that matter at higher scale. For a forum under a few thousand active users per month, free Jetonomy plus a properly configured WordPress install is enough.

The ROI math at three sizes

Concrete numbers. We will compare three scenarios using industry-standard cost-per-ticket assumptions and our own client data on community deflection rates.

Scenario 1: Small SaaS, 200 tickets per week.

• Ticket-only cost: 200 tickets x 52 weeks x $20 per ticket = $208,000 per year.
• Community-first cost: 30 percent deflection saves $62,400. Plus the forum cost (WordPress hosting $50/month, Jetonomy free, community manager 0.25 FTE at $60k = $15k) = $15,600 per year. Net savings: $46,800 per year, plus a permanent searchable knowledge base.

Scenario 2: Mid-stage SaaS, 1,000 tickets per week.

• Ticket-only cost: 1,000 x 52 x $20 = $1,040,000 per year.
• Community-first cost: 35 percent deflection saves $364,000. Plus the forum cost (WordPress hosting $200/month, Jetonomy Pro $399 lifetime, community manager 0.75 FTE at $60k = $45k) = $47,800 per year. Net savings: $316,200 per year.

Scenario 3: Established SaaS, 5,000 tickets per week.

• Ticket-only cost: 5,000 x 52 x $20 = $5,200,000 per year.
• Community-first cost: 40 percent deflection saves $2,080,000. Plus the forum cost (WordPress hosting $1,000/month + CDN, Jetonomy Pro Agency $399 lifetime, community manager + community engineer combined 2 FTE at $130k each = $260k) = $272,000 per year. Net savings: $1,808,000 per year.

These numbers are conservative on the deflection side. Mature community-first programs in developer SaaS routinely hit deflection rates of 50 percent or higher. They are also missing the second-order benefit: the SEO value of forum content as an acquisition channel, which on a meaningful community can drive five-figure or six-figure monthly organic visits over time.

What this looks like in the first 90 days

If you decide to run this pattern, the actual implementation is not exotic. Most of the work is cultural and operational, not technical. A reasonable 90-day rollout:

• Days 1 to 30: Stand up the forum. Pick categories (we recommend Questions, Bug reports, Feature requests, Show and tell, Announcements). Configure Q&A mode on Questions. Set trust levels. Theme to match the main product. Set up SSO so forum login uses the same provider as the product. Pin the canonical “how this community works” thread.
• Days 31 to 60: Seed the forum. Pick the 30 to 50 most common support questions from your ticket history and create them as forum threads with the canonical answer, marked as accepted. Train your support team to respond on the forum instead of in email when a ticket is genuinely public-friendly. Start measuring deflection.
• Days 61 to 90: Promote the first cohort of helpful community members to trust level 3 (moderators). Set up the escalation bridge so threads tagged “needs private follow-up” route into your ticket system with full context. Publish the deflection metric internally so the team sees the cost savings hit the support budget.

By day 90 the forum should be carrying its weight and the support team should see weekly ticket volume drop. By month 6 the SEO traffic from indexed forum content should be measurable.

FAQ

What if my customers will not post publicly? They will, if your community manager seeds the early threads with genuinely useful answers and your engineers respond fast. Customers are willing to post in public when they see other people doing it and getting answered. The first 60 days require active seeding by the team. After that the behavior is self-sustaining.

What about security-sensitive issues? Tier 2 in the architecture above handles this. The forum has a private-escalation path for issues that involve customer data, billing, or security disclosures. Public posting is not the rule for everything, just for technical questions and product usage that benefits from being searchable.

Will my support team be replaced? No. The team shifts work from answering the same question 100 times to writing the canonical answer once, moderating the public conversation, and handling the higher-value cases that genuinely need private support. Most teams that adopt this pattern do not reduce headcount; they redirect headcount toward higher-leverage work.

What about competitors reading our public threads? Competitors can already see your product, your docs, and your pricing. They can also create a fake account and open a Zendesk ticket if they really want to see how you handle support. Public threads make the support quality visible, which is a feature for prospects evaluating your product.

What if we are too small for this pattern to make sense? If you are pre-launch or under 100 paying customers, you probably do not need a community yet. Slack or Discord plus direct email is fine. The community-first pattern starts to pay off around the point where weekly ticket volume exceeds what a small support team can handle without compounding hiring. That is typically 50 to 100 tickets per week.

Can we run this alongside Zendesk? Yes, and most teams do. The community handles tier-1 deflection. Zendesk or Plain or HelpScout handles tier-2 paid escalation. You do not have to pick one. The savings come from shifting tier-1 volume out of the ticket system, not from cancelling the ticket system entirely.

Migration path and how we help

For SaaS teams ready to add a community-first support layer, we run two engagement types. Setup is a 30-business-day engagement that stands up a Jetonomy-on-WordPress forum, configures SSO with your existing auth, seeds the initial 30-50 canonical Q&A threads from your ticket history, builds the escalation bridge to your existing ticket system, and trains your support team on the new workflow. Pricing starts at $8,500 for a community under 5,000 monthly active users. Hardening is a 60-business-day engagement that adds custom integrations (SSO with non-standard providers, billing-tier-aware permissions, custom escalation routing, branded mobile experience) for teams that need more than the standard implementation. Pricing starts at $18,500.

If you want to evaluate the platform first, Jetonomy free is enough to validate the pattern on a staging site before committing to the rollout. Most teams will not need Pro until they exceed a few thousand active monthly users or want the AI moderation features.

If you are migrating off a different community SaaS (Circle, Skool, Mighty, or X Communities), we covered the migration shape in the 72-hour migration sprint guide and the platform comparison in the alternatives breakdown. The export step differs by source but the destination architecture is the same.

If you are evaluating whether self-hosted is the right call vs another SaaS community platform, the longer comparison lives in our custom community platform vs SaaS guide. And if you are running BuddyBoss and concerned about the March 2026 supply-chain incident, our IOC checklist post covers what affected operators should do.

The takeaway

The shift from private-ticket support to public-community support is happening because the math works. Companies that have made the switch (Fly.io, Vercel, Cursor, n8n, Cloudflare, Hashicorp, Supabase, and a long tail of developer-tool SaaS) report deflection rates of 20 to 40 percent and growing SEO benefit. The economics at scale are not subtle.

The choice that matters is not whether to make the shift. For most B2B SaaS in 2026, the question is when. The choice that matters after that is where to host the community. WordPress with a forum plugin is the lowest-cost, highest-integration option for teams already running WordPress. Discourse is the proven default for teams that prefer hosted infrastructure. Either works. The worst choice is the third one: doing nothing, paying per-agent forever, and letting every answer your team writes disappear into a private email thread that will never help the next customer with the same question.