GTM Vault
Menu

Skills/Signals

PQL scoring and routing agent

A PRD-style agent spec with a 100-point scoring sheet, a backtested sales-ready threshold, a routing table and visitor suppression rules.

Built from the system ofMichael BartimerGTM engineer, Clarify · SMYS 9

Download pql-scoring-agent.zip

Needs: Product analytics, a CRM, signup outcome history and ICP definitions. Or run it without installing: connect the GTM Vault MCP and ask Claude to run pql-scoring-agent.

Built from the system Michael Bartimer, GTM engineer at Clarify, described on GTM Vault SMYS 9 (https://pro.gtmvault.co/episodes/smys-09). Published free by GTM Vault. Numbers below are the operator's own, from the episode; your results will differ.

When to use this

Use this when a product-led company has signups arriving faster than sales can judge them, and the product analytics and the CRM hold the evidence but nobody joins them. It also covers the upstream website visitor agent, for teams that want de-anonymized traffic turned into worked records instead of noise.

The system on the record

Michael runs two signal systems inside Clarify, the CRM he works at, both built with Rep, Clarify's built-in AI.

The website visitor agent runs in a fixed order (SMYS 9, 4:05):

  1. A webhook ingests the de-anonymization payload from Vector.
  2. The agent parses name, title, LinkedIn and company.
  3. It disqualifies before it classifies: employees visiting the site, certain competitors, and existing customers are removed.
  4. Survivors are classified by segment and ICP at the company level.
  5. Only companies that pass ICP get person-level persona resolution, against about six personas.
  6. Records are written into the CRM.
  7. The agent opens the LinkedIn profile from the payload to find the current company, because vendor data is often stale, and re-runs the whole workflow on the corrected record.
  8. Contacts are enrolled in persona-specific campaigns in Instantly, with outcomes such as meetings booked written back to the CRM for reporting.
  9. Every record posts to a Slack channel called Website Visitors for visibility and enrollment confirmation.

He treats the Slack stream as the version any team can ship first, calling it "the first like basic simple use case that any team can stand up" (SMYS 9, 12:00). Outbound comes after visibility.

The PQL pair is two agents (SMYS 9, 13:35 and 15:35):

  1. The scoring agent fires on PLG deals created through website signups and scores each one out of 100 using seven product usage signals. In his words, "half of these data points are a tool call out to PostHog" (SMYS 9, 13:35). The other half are properties already in the CRM.
  2. The routing agent sends each scored account down one of four paths. Path one is immediate sales outreach based on firmographic data points, with a human in the loop: a rep reviews the account and enrolls it in a sales campaign with one click. Path two nurtures the account toward a PQL score of 60 or greater, the threshold at which it is classified sales ready (SMYS 9, 15:35). The episode does not describe paths three and four.

The build path matters as much as the agent. He did the analysis in Claude Code, wrote the output into a Notion doc, took a few quick rounds of team feedback on that doc, then handed it to Rep, which built the agent in minutes (SMYS 9, 13:35). He calls the result "a lightweight V1" of a product-led sales motion (SMYS 9, 15:35).

The result

  1. Seven signals produce a score out of 100 for each PLG website signup (SMYS 9, 13:35).
  2. About half of those signals are live tool calls to PostHog, the other half CRM properties (SMYS 9, 13:35).
  3. A score of 60 or greater marks an account sales ready (SMYS 9, 15:35).
  4. The sales team's human review on path one takes 10 to 20 seconds per account (SMYS 9, 15:35).
  5. The PQL agent was built in minutes from the reviewed Notion spec (SMYS 9, 13:35).
  6. The website visitor agent was stood up in a day or a couple of days once the de-anonymization vendor was bought (SMYS 9, 10:40).
  7. Vendor contact data was often 6 or 12 months out of date, and he has seen many instances of 24 months or more (SMYS 9, 4:05).

Run it on your company

  1. Ask the user once, in one message, for: the product analytics tool and the events it tracks; the CRM and the account and deal properties available; how a PLG signup is identified (deal type, source, form); ICP firmographics and up to six personas; a history of signups with outcomes (converted to paid, opportunity created, churned, ignored), or an honest statement that none exists; the website de-anonymization vendor if any; the employee email domain, the competitor list and the customer list; and how many accounts sales can review per day.
  2. Run the analysis before writing anything. With the signup history, compare signups that converted against those that did not on every product event and CRM property supplied. Output a candidate signal table: signal, source system, converters versus non-converters, and a one-line read on predictive strength. With no history, mark every signal as an assumption to be tested.
  3. Select seven signals. Aim for roughly half from product usage, fetched live at scoring time, and half from CRM properties, matching Michael's split. Reject any signal that cannot be pulled reliably by an agent tool call.
  4. Build the scoring sheet as a Markdown table with columns: Signal, Source (analytics call or CRM property), Exact event or property name, Condition, Points, Rationale. Points must sum to exactly 100.
  5. Set the sales-ready threshold. Start at 60, the line Clarify uses, then backtest it against the history: report how many past signups would have crossed it and what share of those converted. Move the threshold until the daily volume above it fits the sales review capacity from step 1.
  6. Write the routing table with four paths: Path, Entry rule, Action, Owner, Human step. Path one is immediate outreach on firmographic fit, with a human review sized at seconds, not a research task, and a one-click enroll. Path two is nurture toward the threshold, with a re-score trigger. Paths three and four are the user's call, for example disqualify and recycle; state them explicitly, since the episode does not.
  7. If the user runs website de-anonymization, write the visitor agent spec in the same order as section two: parse, suppress employees, competitors and customers, classify ICP, resolve persona, verify current employer from the LinkedIn profile and re-run on mismatch, write to CRM, enroll, post to a Slack visibility channel. Suppression must come before classification.
  8. Assemble everything into one PRD-style Markdown spec: Purpose, Trigger, Data sources and tool calls, Scoring sheet, Threshold and backtest, Routing table, Suppression rules, Write-back fields, Slack notifications, Open questions. Close with a short agent instruction block the user can paste into their agent builder.
  9. Tell the user to take a few rounds of team feedback on the spec before building, and to ship Slack visibility first.

Tools on the record

  1. PostHog: product usage data, about half the signals in the PQL score.
  2. Vector: website de-anonymization, payload ingested by webhook into the visitor agent.
  3. Claude Code: analysis behind the PQL agent spec.
  4. Notion: spec doc the PQL agent was built from, after team review.
  5. Instantly: marketing-led outbound by persona, outcomes written back to the CRM.
  6. Slack: Website Visitors channel, visibility as step one of the play.

Clarify is the CRM and system of record, and its built-in AI, Rep, built the agents from the spec. Any tool doing the same job works; the method is the point. Full stack: https://pro.gtmvault.co/stack/operator/michael-bartimer

Where it breaks

  1. Low traffic. Rick noted that most B2B sites get little traffic without a paid budget, so other motions must exist before a visitor agent has anything to work (SMYS 9, 13:07).
  2. Stale vendor data. Without the LinkedIn current-employer check, records point at a previous role 6, 12 or 24 or more months old (SMYS 9, 4:05).
  3. Persona coverage. Michael expects most companies to find far less of their traffic inside their named ICPs and personas than they assume (SMYS 9, 12:00), so plan for a small qualified share.
  4. Native gaps. Clarify campaigns suit sales-led outbound and have gaps for marketing-led, which is why persona enrollment runs through Instantly as a workaround (SMYS 9, 4:05 and 17:36).
  5. A weak spec. When the build takes minutes, the analysis and the reviewed document decide the quality. Skipping step 2 produces a confident score with no evidence behind it.

Every GTM Vault skill · The SMYS 9 episode