Qualify Product-Qualified Leads

Why static PQL rules go stale almost immediately

Most PQL programs start with a whiteboard session: a sales lead, a growth lead, and a product manager argue about what counts as “qualified.” Someone draws a funnel. Someone else suggests a threshold — “five logins in seven days,” or “two seats invited,” or “connected an integration.” It gets written into HubSpot or Pipedrive as a property update rule, and the team moves on.

Three months later, the rule fires for half the free tier. The product shipped a feature that made one of those actions trivial — maybe single sign-on bumped logins, maybe a new template flow inflated seat invites. Sales reps stop trusting the PQL flag because the signal-to-noise has collapsed. The growth lead schedules another whiteboard session.

This isn’t a fault of the team. It’s a structural problem with rule-based PQL scoring: the rules are written against a snapshot of your product, but your product keeps moving. Every release shifts the meaning of the same event. Every new persona drags the average behavior in a new direction. Every onboarding revamp re-routes the path users take to value. Static thresholds can’t keep up, and the cost of keeping them current is a permanent tax on whoever owns the model.

Beton was built for teams who have run this loop and don’t want to run it again.

What Beton actually does

Beton sits between PostHog (where the product usage data already lives) and your CRM. Instead of asking you to define PQL criteria upfront, it analyzes the behavior of users who did convert to paid versus those who didn’t, surfaces the behavioral combinations that correlate with conversion, and emits a signal when a user matches that pattern. The signal lands in Attio, HubSpot, Zoho, Pipedrive, or a webhook — wherever your reps already work.

A few things to be specific about:

• It runs on your existing PostHog data. No extra instrumentation. No SDK swap. If PostHog already captures the events your sellers care about, Beton already has what it needs.
• It detects behavioral patterns, not single events. A login isn’t a PQL signal. A login plus a workspace creation plus an integration connect within a 48-hour window — that’s a pattern. Beton looks for the combinations.
• It updates as your product changes. When a new release shifts what “engaged” looks like, the heuristic adapts to the new converter cohort. No re-tuning sessions.
• It doesn’t store granular product data. Beton reads events from PostHog, computes signals, and routes results. The granular event data stays in PostHog. We don’t replicate your warehouse and we don’t build a parallel one.

Patterns Beton typically surfaces in PLG data

These aren’t hard-coded — they’re the kinds of patterns that emerge from looking at real PostHog data — but they’re the ones we see most often:

• Activation depth — users who explore three or more core features within their first session, not just the one feature they signed up for. The breadth signal usually predicts conversion better than depth on any single feature.
• Collaboration signals — invitations, shared resources, comments. The first invite is the strongest predictor in most B2B SaaS data we’ve seen, because it converts an individual evaluator into an organizational champion.
• Integration adoption — connecting a tool from a different vendor (a CRM, a Slack, a GitHub) is a high-cost action that almost always correlates with retention, because it creates switching cost the user just paid in advance.
• Return cadence — a user who logs in three days in a row is rarely on a casual tour. Daily-active early in the trial is one of the cleanest signals of intent.
• API key creation — for developer-facing products, the moment a user generates a key and writes integration code is roughly the moment they’ve decided. The buying decision precedes the procurement conversation by days or weeks.

The point isn’t that any of these are universal. The point is that Beton finds the ones that are universal in your data and routes them, instead of leaving you to guess.

How this fits with your CRM

Sales teams don’t want a new dashboard. They already have one — it’s called the CRM, and it’s where their pipeline, their tasks, and their context live. Beton’s design choice is that the signal goes to the CRM, not to a Beton UI. A new lead opens a deal record. A returning lead updates an existing one. The PQL signal becomes a CRM field that Smart Views, sequences, and routing rules already know how to consume.

That has two consequences worth calling out:

1. You don’t have to retrain anyone. The rep’s workflow is unchanged. They open Attio (or HubSpot, or Pipedrive), they see a new note or a new field, they reach out.
2. You can chain Beton signals with the rest of your stack. A PQL signal can trigger an Apollo sequence, an Outreach cadence, or a Clay enrichment flow without anyone writing custom Zapier glue.

When PQL signals matter most

The honest answer is: not every PLG company needs them. If your free tier is small enough that an SDR can review the list manually each week, and the list isn’t growing, manual review is fine. PQL automation matters when:

• The free or trial cohort is too large to review by eye.
• The activation patterns are subtle enough that “look at the dashboard for 10 minutes” doesn’t surface them.
• The sales team is scaling and the cost of an SDR catching up on every account weekly stops penciling out.
• The product is changing fast enough that the criteria from 90 days ago are already noise.

If two or more of those are true, you’re at the point where a rule-based PQL program either gets ignored or gets written off. That’s the gap Beton fills.

Getting started

Beton is open source — if you want to see exactly how the heuristic works, the code is on GitHub. Self-hosted installs run for free with your own LLM key. The cloud version starts at $0.50 per tracked user per month with a free trial; no credit card required to connect a PostHog instance and watch signals come in. Most teams have their first signal in their CRM within an hour of connecting.

If you’ve been running PQL scoring in HubSpot or Pipedrive and the rules have drifted, the fastest way to see the difference is to run Beton in parallel against the same PostHog data for a week and compare what each one flags. The patterns that show up in Beton but not in your existing model are usually the ones worth re-routing.