G2 is one of the largest public repositories of software opinion on the internet. Customers leave reviews there when something works well enough to recommend, or when something frustrated them enough to write it down. The negative reviews are where the real signal lives.
This article draws on patterns documented across a large sample of public G2 reviews, combined with what practitioners and researchers have published about software complaints. It does not represent a single proprietary dataset, and no percentage tables here claim original research. What it does offer is a structured reading of what those complaints say, why they cluster the way they do, and what a product or customer success team can actually do with that knowledge.
If you manage a product, run a support team, or sit in a customer success role, this is the complaint map that keeps appearing regardless of category.
What this article is based on
This article synthesises patterns from publicly available G2 reviews, published analyses of software review sites, and widely reported practitioner observations. It does not claim a proprietary dataset. No percentage figures in this article represent original research conducted by FlagUp. Where a specific claim cannot be verified from a real external source, it is framed as a pattern or a tendency rather than a statistic.
The short answer
Across SaaS products, negative G2 reviews cluster around four themes: pricing surprises, support quality and response time, UX friction, and missing or incomplete integrations. Complaints about bugs and reliability appear throughout but rarely dominate unless the product has a specific stability problem. The pattern holds across categories from project management to billing tools to HR platforms.
Pricing complaints: the gap between what customers expect and what they pay
Pricing is the most emotionally charged complaint category in software reviews, and it rarely means "this product costs too much." The underlying frustration is almost always about surprise.
Customers describe discovering mid-contract that a feature they assumed was included sits behind a higher tier. They write about usage-based pricing that scaled faster than they anticipated. They mention annual billing locked them in before they understood the product fully. They flag that cancellation required a phone call or a sales conversation rather than a button.
What "too expensive" usually means
When a reviewer writes "too expensive," they are rarely comparing price per seat to a competitor. They are expressing a perceived mismatch between what they paid and what they received. The complaints that follow that phrase tend to describe onboarding that never resolved, a feature they requested that was never built, or support interactions that felt transactional.
A pricing complaint is frequently a satisfaction complaint that has found the wrong label. What customers mean when they say "too expensive" unpacks this distinction in more detail.
What teams miss in this signal
The pricing complaint shows up on G2 after the frustration has compounded. By the time a customer writes publicly about cost, the window for intervention has usually closed. Teams that wait for reviews to surface this pattern are always working with historical data.
Support complaints: response time is the symptom, not the cause
The second major cluster in negative reviews describes support experiences. These complaints split cleanly into two types.
The first is speed. Customers describe waiting days for a response to a blocking issue. They describe following up multiple times before someone engaged. They mention being passed between agents without resolution.
The second is quality. Customers received a response quickly, but the answer did not solve the problem. They were directed to documentation that did not address their specific case. They felt the support agent was reading from a script rather than engaging with the actual issue.
Why the speed complaint is often a symptom
Slow support responses are real and frustrating. But reviews that describe slow support often embed a second complaint: the product created a situation where support was necessary in the first place. An unclear onboarding flow, a feature that behaves unexpectedly, or a billing process that generated a charge the customer did not understand, all of these send customers to support. If the product itself were clearer, fewer contacts would happen.
Teams that treat support volume as a queue management problem rather than a product signal miss the underlying message.
UX and onboarding friction: the complaints no one files a ticket about
UX complaints are the most underreported category in reviews because many customers do not recognise a bad interface as something worth complaining about. They simply stop using the feature.
The reviews that do surface UX complaints tend to describe navigation that felt unintuitive, workflows that required too many steps, or a setting that was difficult to find. The phrase "steep learning curve" appears frequently and almost always refers to onboarding rather than ongoing complexity.
Onboarding as a standalone complaint category
Onboarding gets its own complaint patterns. Customers describe signing up, not knowing what to do next, and either reaching out to support or abandoning the workflow. They describe documentation that covered features but not use cases. They mention that they never found the thing the product was supposed to help them do.
This is distinct from a feature gap. The capability existed. The path to it did not.
The most frustrating SaaS onboarding experiences covers this pattern in more depth.
What UX complaints reveal about product assumptions
Every UX complaint in a public review represents a much larger number of users who had the same friction and said nothing. The review is the visible fraction. Product teams that treat UX complaints as isolated edge cases tend to underestimate how widely the friction is distributed.
Integration gaps: the request that never becomes a roadmap item
The third-largest complaint cluster describes missing integrations. Customers name specific tools they expected the product to connect with. They describe building manual workarounds. They mention that a competitor offered the integration and they switched.
Integration complaints are notable because they are often highly specific. A reviewer will name the exact tool they needed to connect. That specificity makes this category directly actionable, and it makes it one of the most useful signals for roadmap prioritisation.
Why integration requests get deprioritised
Integration requests are frequently underweighted in backlog decisions because they are submitted by a vocal minority, not necessarily a majority. A team that relies on volume alone to prioritise will consistently underinvest in integrations, because no single integration gathers as many requests as a core feature improvement.
The customers who needed a specific integration and did not get it quietly leave. The reviews appear months later. How to prioritize feature requests without building everything customers ask for covers the prioritisation logic in detail.
What the patterns have in common
Reading across these clusters, a structural pattern emerges. Customers rarely complain about a single isolated failure. The reviews that read most harshly describe a sequence: an unclear pricing structure led to a surprise charge, support took three days to respond, and the underlying feature that caused the problem still has not been fixed.
Compound frustration is what drives someone to leave a public review. A single bad experience, handled well, rarely produces a one-star rating. The reviews that damage a product's reputation are the ones where multiple failure points connected.
The feedback that does not reach the team
G2 reviews are written after the customer has already decided to say something publicly. A much larger body of frustration never appears in reviews because customers either did not bother to write, resolved their frustration internally, or left without saying why.
Teams that rely on public review monitoring are reading the most extreme tail of the complaint distribution. Structured internal feedback collection, using a tool that captures signals before they become public grievances, gives teams access to the middle of that distribution while there is still time to respond.
FlagUp gives teams a place to collect that feedback centrally, where customers can submit concerns and vote on shared frustrations before those feelings harden into a public review. The free plan covers collection, a suggestion box, voting, and a read-only roadmap and changelog. FlagUp also gives teams early visibility into client health, so problems get resolved before they become lost accounts. Sentiment scoring and churn signal features are available on paid plans, see pricing for details.
Acting on review patterns without waiting for reviews
The practical value of understanding G2 complaint patterns is not in responding to reviews. It is in recognising these categories as early-warning signals and building collection mechanisms that surface them sooner.
A few approaches teams use effectively:
- Close the feedback loop after support interactions. Customers who contact support and receive a resolution are often willing to share what caused the confusion. That information is more actionable than a public review written three months later.
- Ask directly about integration needs during onboarding. Customers who just signed up know which tools they are running alongside your product. Capturing that information early is cheaper than reading it in a cancellation review.
- Make it easy to submit a complaint without publishing it publicly. Many customers would prefer to tell you before telling G2. A visible, low-friction internal channel gives them that option. A feedback widget placed in the product can surface frustration at the moment it occurs rather than weeks later.
- Track complaint categories over time, not just volume. A single integration request means little. The same integration named by thirty separate customers across six months is a roadmap signal.
Frequently Asked Questions
Are pricing complaints always about the price itself?
No. Pricing complaints in software reviews most often describe a perceived mismatch between expectation and outcome. Customers who felt well-informed and received clear value at their price point rarely complain about cost, even at high price points. The frustration usually starts with surprise billing, feature gates that were not clearly communicated, or a product that did not deliver what the onboarding implied.
Do bug reports appear more often than UX complaints in G2 reviews?
No, at least not in aggregate across categories. Bugs produce reviews when they block a critical workflow and support does not resolve them quickly. UX complaints appear more broadly because every customer encounters the interface, while not every customer experiences a bug. The bug-driven reviews tend to be more urgent in tone; the UX complaints tend to accumulate more quietly.
Can reading G2 reviews replace internal feedback collection?
No. G2 reviews capture the most frustrated fraction of customers who chose to write publicly. The majority of customer frustration is never expressed in a public review. Internal feedback channels, including in-product widgets, suggestion boxes, and direct follow-up after support interactions, capture a broader and more representative signal.
How should teams prioritise complaints that appear in reviews?
Start by categorising complaints into the main clusters: pricing, support, UX, integrations, and reliability. Then assess which cluster is generating reviews at the highest rate relative to your customer base. Prioritise the cluster that is growing, not just the one with the most total mentions. A small and growing integration complaint cluster is often more urgent than a stable and large pricing complaint cluster.
Do negative reviews always reflect product failure?
No. Some negative reviews reflect a customer who was a poor fit for the product from the start. Others reflect expectations set by marketing or sales that the product could not meet. Both are useful signals, but they call for different responses. A pattern of poor-fit complaints suggests a positioning or qualification problem. A pattern of unmet expectations suggests an onboarding or communication problem.
What to do next
The complaint categories described here: pricing surprises, support gaps, UX friction, and missing integrations, are not unique to any product or category. They are the default failure modes when teams stop listening before customers have decided to leave. The reviews are a lagging indicator. The signal was available earlier.
The teams that act on feedback before it reaches a public platform do so because they have a structured way to collect and respond to that signal internally.
FlagUp helps teams collect feedback, spot friction early, and close the loop before customers head to review sites. Start free.