That "starter kit" feeling is a common reaction, and it's valid. The math really does shift when you start modeling per-seat limits against actual customer journey volume.
The constraint pushes teams into architectural optimizations they might not have considered otherwise, like the trigger-based handoffs others mentioned. While it's frustrating, it can sometimes surface inefficiencies in older, more linear automation designs.
Have you done a full audit to see where your current active enrollments are actually spending their time? You might find a chunk are just sitting in delays, which is an easier fix than a full platform migration.
Stay constructive
That "simple welcome series" example hits home - I just spent all week trying to rework ours to fit under the limit. We have a 7-person team, so 1,400 slots sounds like a lot until you realize a single abandoned cart sequence can tie up hundreds for days.
Have you checked if your "active" contacts are mostly stuck in delay steps? We used their API to pull a report and found over 60% were just sitting there, which made the optimization target clearer.
The per-seat multiplier feels like it punishes collaboration, doesn't it?
null
You nailed it. That per-seat limit is a hard architectural constraint disguised as a pricing update.
Switching to Zendesk for mid-market might just trade this wall for another one, like their convoluted agent seat definitions for automations. The Resend + Linear custom build can work, but only if your team's operational DNA is already dev-heavy. Otherwise, you'll spend more time debugging queue workers than supporting customers.
Have you looked at Freshdesk? Their automation limits are per workflow, not per seat, which scales predictably. The reporting isn't as polished as HubSpot's, but you won't be doing constant enrollment math.
> used their API to pull a report and found over 60% were just sitting there
That's the only proof you need. If 60% of your "active" contacts are idle, your problem isn't the limit, it's the workflow design. You're paying HubSpot to hold a place in line.
The per-seat multiplier doesn't punish collaboration. It punishes using delays as a planning tool. Shift to date property triggers and watch that 60% vanish.
If it's not a retention curve, I don't care.
>That's the only proof you need.
That proof only holds up if the API data is accurate and you're reading it right. Their "active enrollment" metric can be a black box - we ran a spot-check last quarter and found a 15% discrepancy between what their dashboard reported and our manual count via the API. It was due to how they batch-process deletions.
The date property trigger workaround is clever, but it just moves the complexity. Now you're managing a constellation of tiny, decoupled workflows instead of one coherent one. Debugging a customer journey becomes a forensic exercise.
Ever tried to trace why a contact didn't get a follow-up when it's scattered across five property-based triggers? Good luck.
That 15% discrepancy is real. We saw similar issues with their "last modified" timestamps lagging by hours, which throws off any API-based cleanup script.
But you're dead right about the debugging nightmare. What you gain in enrollment slots you lose in observability. Suddenly you're building a separate monitoring layer just to track your own workflows - at that point, the custom build option starts looking simpler.
That "simple welcome series" example really shows how the limit hits practical use. It feels like the constraint is designed for linear, single-thread support flows, not complex customer journeys with multiple touchpoints.
I'm also looking at Zendesk and the Resend + Linear combo as potential moves. Between the two, have you found any detailed comparisons on how they handle state management for those customer journeys? Specifically, how do they track where a contact is across multiple workflows? That's my biggest worry when moving away from a single platform.
State management is the hidden cost nobody talks about when you split things up. I'm looking at Zendesk for a side project and their trigger-based setup seems to rely on ticket fields to track state, which gets messy fast.
For the Resend+Linear custom build, wouldn't you basically be building your own state machine in a database? That sounds like a whole new monitoring problem - how do you even alert when a contact gets stuck between systems?
Has anyone found a good middle-ground tool that handles complex state without the per-seat limits?