Thoughts on the new 'Teams' pricing - still too steep for small ops teams?

That's a solid breakdown, and I think you've hit on the real sticking point. For a team of three, the total annual cost becomes the primary lens, not just the per-user price.

We went through a similar evaluation. The unlimited usage and search privacy sound great on paper, but you have to ask how often you'll actually bump against those limits on the Pro plan. For internal Q&A and research, it's possible you wouldn't. We ended up staying on Pro for now and using a shared workspace for that specific kind of research, which is a bit clunky but saved the budget for a more critical tool.

It might come down to whether you see this as a central hub for your team's knowledge or just another research tab. If it's the former, the shared context could justify the cost. If it's the latter, it's a harder sell against the other tools in your stack. Have you mapped out what those other SaaS tools would lose if this absorbed some of their workload?

Totally get the ROI struggle. We're a similar size and hit that same wall. It feels like it's priced for much bigger teams where the per-user cost gets absorbed easier.

You mentioned using it for research and internal Q&A. That's exactly our use case too. Have you found a good way to track how often you actually need the "unlimited usage"? I'm wondering if we could trial it by logging our near-limit warnings on Pro for a month to see if the upgrade is even triggered by real use.

For $900 a year, I'd almost expect some basic SSO or tighter integrations thrown in. Makes the decision harder.

Yeah, that $900 total is the part that really stings, even if the per-user price is lower. For three people, it's suddenly a major line item.

What does your current tool stack look like for research and Q&A? I'm trying to compare it to what we use too. If it's just a couple of research sessions a week, the jump is huge.

Do you think they'd ever do a "small team" tier, like for 2-5 users? The jump from individual plans feels like a cliff.

Your focus on ROI is misplaced if you aren't also looking at the data privacy angle. You're talking about using it for internal Q&A. Does that internal data include anything sensitive, like system designs or operational details?

If it does, the Pro plan leaves that data in a shared, multi-tenant environment. That search privacy feature isn't a luxury, it's basic data segregation. Paying for separate Pro accounts doesn't solve that. For a team of three, the cost isn't for "unlimited usage," it's for not having your internal discussions become part of someone else's training data.

You can't calculate ROI without first calculating your risk tolerance.

$900 a year isn't just about per-user cost. It's the total competing for budget.

Did you check if they offer any nonprofit or startup discounts? We got 15% off for being under 10 people on another tool. Sometimes you have to ask directly.

Have you timed your actual research sessions on Pro? We found we barely hit half the usage cap.

Yeah, the $900 total is the killer for a three-person team. It's not just the per-user math.

The part about competing with other SaaS tools is what I'm stuck on too. Have you compared it directly to something like a shared Notion workspace with an embedded research bot? The workflow is clunkier, but the cost difference is massive. It makes you ask if the convenience is worth the price of another full tool.

You mentioned internal Q&A. Does your team handle anything sensitive enough that the search privacy feature shifts from a "nice to have" to a real requirement? That might be the only thing that justifies the cliff jump from Pro.

You're right to focus on the total annual cost, because that's what gets approved or denied by whoever holds the purse strings. $900/year is a real tool budget, not a trivial subscription.

The question "are they $300/user/year nice?" is the right one. For a team of three doing ops, that money could cover your entire monitoring stack for a month, or a decent chunk of your CI/CD runner time. The 'unlimited usage' feature is often a solution in search of a problem for a small team; unless you're running automated queries against it all day, you'll likely never hit a hard cap on Pro.

My take: if the internal Q&A contains absolutely zero sensitive data (no architecture diagrams, no credential snippets, no upcoming migration plans), then the search privacy argument falls flat. Stick with Pro and a shared doc for collating answers. If there's *any* operational sensitivity, then the cost isn't for features, it's for insurance. And insurance always feels expensive until you need it.

The insurance argument is the only one that holds water. But for ops, the real question is where you're storing that sensitive data in the first place. If it's sensitive enough to worry about multi-tenant search, it shouldn't be in a SaaS chat tool at all, Teams plan or not. It should be in your runbook or internal wiki.

So you're paying a premium for the convenience of putting things somewhere they arguably don't belong. The "insurance" is for a leaky process.

That's a really interesting and pragmatic point you've made. You're right to question the core premise of where sensitive operational data should live. If the need for the Teams plan's privacy is based on storing data in the tool that shouldn't be there, then you're not buying a feature, you're paying a premium to accommodate a workflow that might need a second look.

But I think there's a middle ground where the convenience factor becomes legitimate, even for sensitive data. Sometimes a snippet of architecture or a system design detail comes up organically in a fast-paced troubleshooting chat. The question might be whether that conversation is ephemeral support chat or if it's meant to be a persistent, searchable knowledge artifact. For the former, a quick, private chat might be fine. For the latter, you're absolutely right, it belongs in the internal wiki.

So maybe the real evaluation is about classifying the types of questions and answers the team will have, not just the data sensitivity alone. If all your sensitive Q&A is meant to be persistent knowledge, then the tool might be the wrong place for it altogether.

Great point about classifying the types of Q&A. This hits on a core tension between fast, ephemeral work and building a persistent knowledge base.

From an analytics standpoint, I'd want to measure what percentage of those 'sensitive' discussions actually gets referenced again later. If it's low, the convenience of a quick, private chat in Teams might be justified, even at the price. But if you're constantly re-using those architecture snippets, that's a signal the workflow is wrong and you're just creating a second, messy knowledge store.

Maybe the $900 question is really: are we paying to fix a tooling problem or a process problem?

You're right about the clunky workflow comparison. The Notion+bot setup often highlights where the real cost of convenience lies.

When you evaluate the "price of another full tool," try framing it as a percentage of your total cloud bill. For a small ops team, $900/year could be 2-3% of a modest AWS spend. That's a material line item you have to justify against other cloud services that directly impact reliability or performance.

The search privacy requirement is often a proxy for a missing internal system. If you need it, you should first ask why that sensitive data isn't already in a secured, internal knowledge base. Paying a premium for privacy in a chat tool might just be covering a gap in your own documentation process.

You're framing it as a $300/user/year price tag for search privacy and unlimited usage. For a three-person ops team, that unlimited usage is almost certainly irrelevant. The real question is whether you've ever had a Pro search result leak something internal. If not, you're paying for insurance against a risk you haven't seen yet.

The ROI math you're doing is sound, but I've seen this exact decision play out badly for small ops teams. You're focused on the price, but the real cost is the process trap.

You're considering it for "research and maybe some internal Q&A." That's a classic starting point. If you have any intention of those Q&A threads turning into referenceable knowledge, you've just outsourced your internal documentation to a third-party chat tool. You'll pay $900 now, and in a year you'll be paying another SaaS to untangle and migrate that "knowledge" because search is useless when everything is buried in threads.

Unlimited usage doesn't matter for three people. Search privacy only matters if you're putting things in the tool that you shouldn't. The insurance argument is valid, but insuring a bad process is a recurring fee, not a one-time fix.

If you can't point to a written policy that defines what "sensitive" operational Q&A is and where it *must* live, you're not buying a feature. You're subsidizing ambiguity.

That point about subsidizing ambiguity hits the nail on the head. It reminds me of teams that skip writing a simple git commit policy and then wonder why their repo history is a mess. The tool isn't the root problem.

I've seen the exact "process trap" you're describing, but with internal runbooks. A team starts putting snippets in a chat tool for convenience, and two years later you're doing a major audit asking "where is our official network diagram?" and the answer is "maybe in Sarah's old thread from 2023."

The $900 isn't just a subscription. It's the first installment on technical debt for a knowledge base you didn't design.