PQL isnt MQL with extra steps

Most PQL content was written by people who learned lead scoring in B2B sales-led environments and tried to port the framework over. The result is PQL definitions that look like MQL definitions with uses-product stapled on. Thats not what PQL is.

MQL is interest-based. The lead downloaded the whitepaper, attended the webinar, visited the pricing page. They showed marketing-channel intent. They might not have actually used the product or experienced its value.

SQL is sales-readiness based. The lead met budget, authority, need, timing criteria. Sales reps have evaluated whether the lead is ready to enter the pipeline.

PQL is product-value-realized based. The user actually used the product, hit the aha moment, and demonstrated through their behavior that the product is delivering value. The signal source is product behavior, not marketing engagement or sales evaluation.

The clean case is a SaaS with one obvious activation event. User connects a store. User imports their first dataset. User invites a teammate. PQL definition is whether the user hit that event in the last X days. Easy.

The hard case is a SaaS with multiple compounding activation milestones. Maybe activation is did-3-of-these-5-things. Maybe its weighted (did the high-value thing once OR did the medium-value thing 3 times). Maybe its time-window-sensitive (did the activation behaviors AND has logged in within the last 14 days).

The methodology for the fuzzy case is to weight signals by predictive power for 90-day retention OR for trial-to-paid conversion, depending on which is your bottleneck. Build the regression. Find the signal combination that best predicts the outcome you care about. Define PQL as users whose composite score crosses a threshold.

Then test the threshold. If your PQL definition flags 60% of trial users, the bar is too low and sales will burn time on weak leads. If it flags 5%, the bar is too high and youre missing real opportunity. Adjust based on whats actionable for the team that operates on PQLs.

For pure self-serve PLG, PQLs surface to lifecycle marketing for in-app prompts and email expansion offers. No sales team in the loop. The routing is automated, the response is product UI plus email.

For PLG with sales-assist, high-value PQLs get routed to AEs based on plan tier, company size, or expansion potential. Routing rules need to define what high-value means specifically (ACV threshold, plan tier, team size). The PQL alert architecture has to push the lead to the right rep in real time, not in a weekly batch.

For sales-led with product-led signals, PQLs are treated as a sub-segment of SQLs. The product behavior accelerates a lead that was already in pipeline. Routing rules are about updating the existing CRM record with the product signal rather than creating a new lead.

PQLs decay fast. A user who hit the aha moment today is a hot lead today. A week from now, the moment has passed and the user is either going to convert on their own or churn for unrelated reasons. The team that operates on PQLs needs to receive the signal within hours, not days.

Realistically: PQL alert fires within 1 hour of the qualifying behavior. The owner (AE, CSM, lifecycle marketer, depending on routing) gets a clear next-action prompt with the users recent behavior summary, not a raw event log. Action gets taken within 24 hours for high-value PQLs, within 72 hours for the broader population.

Teams that batch PQL review weekly will see weak conversion on PQL motions because the timing is off. Build the alerting around real-time webhooks or near-real-time syncs, not nightly ETL jobs.

Product fires event. Event lands in product data layer (warehouse, ESP, or both). PQL definition logic evaluates against the users recent behavior. If criteria met, alert fires to routing layer. Routing layer decides who gets the alert based on user attributes. Alert lands in the operators tool of choice (Slack, CRM, email, in-app notification).

The technical pieces are straightforward for most SaaS stacks: product events to a warehouse or directly to the ESP, segmentation logic in the ESP or via reverse-ETL, alerts via Slack/Salesforce/Hubspot. The hard part isnt the plumbing, its the definition and the speed-to-action discipline.

The behavioral conversion scoring piece at /insights/behavioral-conversion-scoring covers the scoring side in depth. The saas onboarding cornerstone at /saas-onboarding-checklist covers how to find the activation event that anchors a PQL definition. Tool: activation audit at /tools/activation-audit for a fast read on whether your activation event is the right one to build PQL on.

If your PQL definition is firing too many or too few leads and you want a sharper read on the threshold, book a discovery call with the current definition laid out.