5
16 Comments

Support tool bills tend to grow faster than the business does. Here's the pattern in the reviews.

Hey all, I do marketing at BigRadar, and while going through reviews on G2, Capterra, and Reddit about support tools, one complaint kept coming up. It hits two types of founders the hardest: Shopify store owners and early SaaS teams.

The complaint is that the bill becomes unpredictable right when things start going well.

For Shopify stores, it usually shows up around a sale or Black Friday. Ticket volume jumps 3 to 5x for a few days, and helpdesks that bill per ticket or per AI resolution send an invoice that looks nothing like the month before. Some reviewers point out that a single AI-handled conversation can get billed twice, once as a resolution and once as a ticket.

For SaaS founders, it's usually the per-resolution model. Paying around a dollar per AI resolution sounds fair until a launch, a viral post, or a bug sends a wave of people into support. A few reviewers say the pricing feels like a penalty for the AI working well.

Other patterns I keep seeing:

Tools with cheap entry plans where AI, WhatsApp, or extra seats sit behind higher tiers, so the real cost ends up 2 to 3x the advertised price
Three separate meters (conversations, AI, automations) that are hard to forecast
Teams running live chat, email, and WhatsApp in different tools and losing context between them

None of this means usage-based pricing is wrong. It works well for larger teams that can model cost per resolution. But for a store doing $1M a year or a SaaS with a 5 person team, a predictable bill matters more than a "fair" one.

That's the reasoning behind how we priced BigRadar: one flat price, unlimited seats and conversations, with chat, WhatsApp, email, and an AI agent in one inbox.

Are you paying for support tooling right now? Has the bill ever surprised you after a launch or a sale, and if so, what did you do about it?

on September 28, 2026
  1. 1

    This is a pattern worth watching closely, support tooling especially tends to scale on seat count or ticket volume rather than revenue, so it quietly becomes a bigger share of costs even while the business looks healthy on the top line. What was the actual gap you found, pricing structure, feature bloat nobody uses, or something else?

    1. 1

      Good point on it scaling with seat count or ticket volume instead of revenue, that's exactly the mismatch that seems to trigger the "this doesn't feel worth it anymore" moment.

      The gap I found is mostly pricing structure, not feature bloat. Most of these tools have the features people actually use (chat, some kind of AI agent, maybe WhatsApp), so it's not that people are paying for unused stuff. It's that the base price looks reasonable and then AI resolutions, seats, or ticket volume get metered separately, so the real cost ends up higher than what's advertised, and it moves the most right when volume spikes (a sale, a launch, a bug). A few reviewers specifically called out plans where AI or WhatsApp sit behind a higher tier, so the "cheap" plan isn't really usable once you need those.

      Feature bloat might be a real problem too, just not what showed up in the reviews I've gone through so far.

  2. 1

    SIGNAL: Mining G2/Capterra/Reddit for the same complaint across Shopify and early SaaS is the right research move — and the pattern you found is a decision signal, not just a pricing rant. Unpredictable support cost shows up exactly when volume (sales, launches, bugs) proves the product is working.

    GAP: Reviews name the pain (“invoice looks nothing like last month”) but rarely name the buyer’s near-term decision: keep the meter and cap usage, switch to flat, or split channels and accept context loss. Without that decision frame, the takeaway stays “usage-based feels unfair” instead of “which bill shape survives a 3–5× Black Friday week without punishing the win.”

    ACTION: For the next round of review pulls, tag each quote with (1) trigger (sale / launch / bug), (2) meter that broke (ticket vs AI resolution vs seat), and (3) what the team did next (capped AI, dual-billed, switched, churned). That turns a complaint pile into a competitive pricing brief a D2C or early SaaS buyer can act on in one sitting — evidence → interpretation → choice, with uncertainty labeled when n is small.

    Curious: across the reviews you read, which single meter surprise most often preceded a switch — double-billed AI resolutions, seat/AI upsell after the cheap tier, or the Black Friday volume spike itself?

    — Francisco / TrixellaIQ — competitive intelligence for D2C brands

    1. 1

      Good breakdown, and the tagging framework is smart. That's the actual research I should be doing instead of just noting the complaint pattern.

      To your question: from what I've seen, the double-billed AI resolution (counting as both a resolution and a ticket) shows up most often right before someone mentions switching, at least in the Gorgias-specific complaints. Seat/AI upsell after the cheap tier comes up a lot too, but it reads more like slow-burn frustration than a single triggering event. The Black Friday spike seems to trigger the "support is breaking" realization generally, then the team starts looking at what's actually costing them money and finds the meter.

      That said, this is a rough read across scattered reviews, not something tagged the way you're describing, so treat it as low confidence. Going to try trigger/meter/outcome tagging on the next pass. That's a much better way to turn this into something usable instead of just "pricing feels unpredictable."

  3. 1

    Yes—the launch or sale spike is where I’d watch contribution margin, not just top-line revenue: put support cost per conversation (including AI, seats, and channels) beside revenue and model the 3–5× volume case before choosing a plan. I’d review that mini P&L monthly and reprice or set a usage cap when support cost pushes the margin below your target. For a simple starting point, the free lite workbooks are at https://solopreneurpl.com; if you want both workbooks in one file with months rolling to quarters plus owner pay, the Pro version is $19 at https://buy.polar.sh/polar_cl_FNp5fjRfVQQkg1Xr5qXLGeus9hrmScjVMTwZG2mcHbr.

  4. 1

    Flat pricing has its own hidden meter, and it's worth naming: the fair-use policy. Every "unlimited" plan has a boundary somewhere, it's just enforced by a person instead of a counter. So the question I'd actually ask before switching isn't the price, it's what happens when one customer uses 50x the median. Friendly email, throttle, or a quiet nudge toward the exit?

    That's not an argument against flat. But the honest version names the limit up front. And predictability doesn't require flat pricing either: a spend cap plus an overage alert gives the same peace of mind without asking the light users to subsidize the whale. Curious how you handle the outlier customer on a flat plan — that's the part of the pricing page I'd read first.

    1. 1

      Good catch, and this deserves a real answer instead of dodging it. I need to correct something from earlier in this thread too: BigRadar isn't actually flat across the board. Seats and conversations are unlimited on every plan, but Ethan (the AI agent) is metered. Growth and Pro plans include 500–1,500 free AI resolutions a month, and beyond that it's $0.79 per resolution.

      So to your actual question: there's no quiet throttle or fair-use nudge, because it's not framed as unlimited to begin with. An outlier customer just pays $0.79 per resolution past their included amount, same as anyone else, light users and heavy users included. It's metered, just priced lower than the ~$0.99/resolution most competitors charge, with a decent free allotment baked into the plan.

      Your framing is fair though. "Predictable" and "flat" aren't the same thing, and I was conflating them in the post. Appreciate you pushing on it.

  5. 1

    The core problem credolopes names is a measurement misalignment. For the helpdesk vendor, each resolution is identical—they see "resolution = billable event". For you, a resolution is never neutral: it's either a customer saved or a problem solved, and both are signals of success. Usage goes up when things work. When the vendor charges per outcome, they've accidentally created a meter that measures "success" but charges for it. Flat-rate pricing removes that paradox—volume is decoupled from cost, so high volume is purely a win. Predictable costs are a side effect of fixing the measurement system itself.

    1. 1

      That's a much better way to describe the actual problem than "unpredictable." The meter is charging more exactly when the AI is doing its job well, which is a strange thing to optimize a business model around.

      I'll be straight though, since I just corrected something similar in this thread: BigRadar isn't fully decoupled from volume either. Seats and conversations are unlimited, but AI resolutions are metered past a free monthly allotment, just at $0.79 instead of ~$0.99, with more included before it kicks in. So the paradox you're describing is softened, not solved. A true "volume is purely a win" model would need AI cost detached from usage entirely, and I'm not sure how sustainable that is for any vendor once volume gets large enough, since the underlying compute isn't free either.

      Curious if you've seen anyone actually pull that off, or if it always turns into some form of metering once you look closely enough.

  6. 1

    The pattern you documented is the correct diagnosis, and it is worth naming the mechanism rather than only the symptom: per-resolution pricing is short a call option on your own traffic, and the buyer holds it for free.

    A predictable bill is an insurance premium. When a helpdesk charges per resolution, the vendor is not selling support software, it is selling the customer a promise that volume spikes will be absorbed, without charging for the risk. That works until it does not, and the failure is not gradual. One launch or one bad week and the invoice reprices the whole relationship. Founders then do the rational thing and stop routing volume through the tool, which means the product gets used least precisely when it is needed most. You can see this in your own review data as a churn pattern rather than a pricing complaint.

    I have watched this from the other side of the same wall. The failure that actually breaks teams is not the high bill, it is the bill arriving without a decision attached to it, so the only lever left is to reduce usage. That is a bad position for a tool whose value is proportional to the work it absorbs.

    Two things I would want to know if I were choosing a helpdesk today, and they are not on the pricing page. First, what happens at ten times your normal volume: is there a queue, a degradation, or a conversation limit that was never called a limit. Second, whether the AI resolution counter can bill the same conversation twice, because your reviewers found exactly that, and it means the meter is not auditable from the customer side at all.

    I build Piramyd, so I have a preference for throughput limits over usage meters, and you should discount this accordingly. But the auditability point stands on its own. A meter the customer cannot independently verify is not a price, it is trust.

    1. 1

      The "insurance without pricing the risk" framing is a sharper way to put what's basically the same pattern people described earlier in this thread, and I like that it points at the mechanism instead of just the symptom. The bit about the tool getting used least right when it's needed most is a real pattern too, not just a theory, that matches what shows up in review complaints around Black Friday and launch spikes.

      On your two questions, I honestly don't know the answers well enough to state them here. From what's on the pricing page, BigRadar bills a single meter per AI resolution, not resolution plus ticket the way one competitor does, so at least that specific double-billing pattern shouldn't apply. But whether one conversation could get counted twice in some edge case (a handoff to a human and back, for example) isn't something I can confirm from the outside, and neither is what happens at 10x normal volume, queue, degradation, or otherwise. Both are fair questions to have documented publicly instead of buried in a support thread, and I'll go find out rather than guess.

      Appreciate the Piramyd disclosure, makes it easier to weigh the throughput-limit argument on its own terms rather than wondering about the angle.

  7. 1

    Have early merchants actually changed their checkout based on Clovia's session evidence, or is the main signal so far that they find the diagnosis interesting?

  8. 1

    The unpredictability is probably the biggest issue with usage-based support pricing. A predictable base cost makes budgeting much easier, especially for smaller teams where one unusually busy week can distort the whole month's economics.
    I also like the idea of having email, chat, WhatsApp, and AI in one place. The part I'd want to understand is how “unlimited” works in practice—particularly during a major traffic spike. Are there any fair-use limits or performance differences at higher volumes?
    That would probably be one of the first things I'd look at before switching from an existing helpdesk.

    1. 1

      That predictable-budgeting point is exactly the pattern that keeps showing up, one unusual week shouldn't distort the whole month's numbers, especially for a smaller team.

      On "unlimited," worth being precise here since I got this wrong earlier in the thread. Seats and conversations are genuinely unlimited, no fair-use cap on those. The AI agent (Ethan) is metered though, each plan includes a set number of free AI resolutions monthly, and it's $0.79 per resolution beyond that, versus roughly $0.99 elsewhere. So it's not fully volume-decoupled, it's cheaper metering with a generous free allotment, which is a meaningfully different claim than "unlimited."

      On performance at high volume specifically, I don't have a confirmed answer on whether there's any degradation or queueing at extreme spikes, and I'd rather say that honestly than guess. That's a fair thing to want documented before switching helpdesks, and I'll go find out rather than assume.

  9. 1

    The per-resolution model is particularly brutal during exactly the moments you want to celebrate. Your AI is working well, volume spikes, and the invoice looks like a punishment. That misalignment of incentives is why so many founders I know run the AI on deflection and manually handle anything over a certain volume — which mostly defeats the point.

    The Black Friday spike scenario is the clearest version of the problem: your CS costs jump right when your margins are already squeezed from discounts. Flat pricing removes one variable from a stressful week.

    One thing worth thinking about on the BigRadar side: how do you handle feature parity requests? Usage-based tools often justify their pricing by shipping features fast, because bigger customers have pricing leverage. With flat pricing, the pressure for that kind of iteration comes from different places.

    1. 1

      That framing of "the invoice looks like a punishment" is one of the clearest ways anyone's put it in this thread. And the deflection behavior you're describing, manually capping AI use to control cost, is a genuinely bad outcome, since it means the tool gets used least right when the team needs it most.

      Quick correction since it came up earlier in the thread too: BigRadar isn't fully flat, seats and conversations are unlimited, but AI resolutions are metered past a free monthly allotment, at $0.79 versus roughly $0.99 elsewhere. So the Black Friday margin-squeeze problem is softer here, not eliminated.

      On feature parity, I don't have a confident answer on how that pressure gets prioritized internally without guessing, so I'd rather say that than make something up. It's a fair question though, usage-based vendors do have an obvious lever (big spender wants X, ship X), and I don't know yet what replaces that lever here. Going to ask internally and see if there's a real answer worth sharing.