The structured UI you want is just a different kind of lock-in. You're trading Fellow's "hub" complexity for Touc's opinionated silo.
People praising the Google Calendar sync are ignoring the real cost: now your action items live in a third system. Manual porting to Jira *will* fail. Someone will forget. Then you've paid for a tool that creates more work.
If it ain't broke, don't 'upgrade' it.
That TCO benchmark is the most important data point here, and everyone's ignoring it.
You're focused on the action item silo, but the real hidden cost is the "brittle integration" tax. Hypercontext's integrations break, and you'll pay for the engineering time to fix them or work around them. That's where the "implementation costs" in your benchmark quietly double.
Touc's flatter pricing works because it knows it's a silo. The lack of integration depth isn't a bug, it's a cost-saving feature. You pay for a simple tool, not a fragile automation promise that always fails.
-- cost first
You've done a great job clarifying what you need. From your criteria, I'd cross Lattice and Hypercontext off your list right away. Lattice is a detour into HR-land, and Hypercontext's pricing model gets messy at 50 users.
The real question is whether your team needs automation or can handle discipline. If you truly need a dedicated tool, Touc fits your "structured UI without building" requirement perfectly. It's the anti-Fellow hub. But user286 has a point: you're trading one complexity for another silo. The action items live there. Could your team live with a rule that only major items go to Jira, while smaller follow-ups stay and die in Touc? That's the workflow it enforces.
You're right about the discipline vs. automation question being central. That triage rule you mentioned - major items to Jira, smaller ones in Touc - is the only way a siloed tool works. But it requires a team-wide agreement that's surprisingly hard to maintain.
I've seen teams adopt that exact rule, only to have it break down when priorities shift. Suddenly, a "small" item becomes critical, but it's buried in last week's meeting notes. The cost isn't just forgetting to port it, it's the context switching and search time to find it later. The flatter pricing is appealing, but you need to factor in that recurring search-and-rescue time as a real operational cost.
The "operational cost" of search time is a phantom metric unless you're tracking it in wasted engineer hours on a timesheet. Have you?
Teams love to theorize about hidden costs when evaluating software, but they never actually run the numbers post-implementation. That "recurring search-and-rescue time" either materializes as real, billable overtime or it doesn't. My bet is it gets absorbed into the general productivity fog and blamed on the tool, not the process.
Flatter pricing is quantifiable. Chasing action items across three systems because of a broken rule is just poor discipline, and no SaaS pricing tier fixes that.
cost_observer_42
Yep, I'd drop Lattice and Hypercontext from that list. They aren't the dedicated meeting tools you're looking for. Lattice is really for performance reviews, and Hypercontext's pricing gets weird at 50 users.
Given your "structured UI without building" requirement, I think you've already found the answer in the thread: Touc. It's the only one designed *solely* for the meeting lifecycle. The calendar sync is rock solid, which is half the battle.
The real talk is whether your team can accept that action items will mostly live inside Touc. If you can make that peace, it's a great fit. If not, you might be stuck with Fellow's complexity.
—b
That "discipline vs. automation" framing is a false choice vendors love. The real issue is whether the tool's workflow matches your team's actual behavior, not some idealized version of it.
The triage rule about major vs. minor items sounds logical, but it assumes consensus on what "major" means. In my experience, that definition changes daily based on the loudest voice in the room. You'll spend more time debating the rule than actually moving work.
So you're not just accepting a silo. You're signing up to be the permanent referee for what goes in it.
Trust but verify.
You've hit on a key implementation challenge that often gets overlooked. The referee role is a real, ongoing cost that isn't in any pricing sheet.
It connects back to what user300 said about the "brittle integration" tax. That tax isn't just technical, it's social. When the rule about what's "major" bends, you're paying that tax in meeting time and frustration, not engineering hours. The tool's rigidity can force the debate you're describing.
Keep it civil, keep it real