# APAC PQL × NexusCRM — what was already in the pipeline before we surfaced these tenants

**Date:** 2026-08-26 · **Author:** Heidi (Growth) · **Question asked:** *"現在 APAC 提到的這些帳戶，
他們原本在被 surface 出來之前，整體在 pipeline 裡有些什麼 signal？"*

**Method.** Every current P0 and P1 tenant in `apac_active_tenants` (43 + 110 = 153 tenants,
117 distinct email domains), joined to NexusCRM by email domain. CRM read live through the
read-only OAuth app (`external.records.read`, acting as the signed-in user), 2026-08-26:
**2,620 Leads · 72 Accounts · 229 Opportunities.**

**Caveats, stated up front.** (a) Matching is by email domain, so free-mail and internal domains
(`gmail.com`, `naver.com`, `pingcap.com` — 25 of the 153 tenants) match strangers and are excluded
from every percentage below; those three were also the only domains to hit the SOQL `LIMIT 200`
cap. (b) Domain matching misses the login-domain ≠ CRM-domain cases the digest agent bridges via
Lead.Company (DigiPlus, MEGAHARD), so the figures below are a **floor**, not a ceiling.

---

## 1. The headline: there is no such thing as a net-new P0/P1 in APAC

| | P0 | P1 |
|---|---|---|
| Tenants | 43 | 110 |
| On a corporate domain (basis for the rows below) | 39 | 89 |
| **Already had ≥1 NexusCRM Lead** | **39 / 39 — 100%** | **89 / 89 — 100%** |
| Had a Lead **before the tenant ever signed up** | **30 / 39 — 77%** | 38 / 89 — 43% |

**Every single corporate-domain tenant in the actionable queue was already known to CRM.** For most
of P0, marketing or sales had touched the company *before* the product signup we are now scoring.
The PQL queue is not discovering companies; it is re-surfacing companies the funnel already holds,
with a product-behaviour reason attached.

That is not a failure — a product signal on a known account is exactly what a PQL should be. But it
means **"✨ Net-new" as the digest currently labels rows is measuring "no Account record", not "new
to us"**, and those are very different claims.

## 2. Where each tenant actually sits in the funnel

| CRM state | P0 (43) | P1 (110) |
|---|---|---|
| Already a won customer | 5 | 3 |
| Has an **open** opportunity | 9 | 22 |
| Previously lost — genuine win-back | 12 | 3 |
| Account exists, no opportunity | 0 | 1 |
| Leads only, never converted to an Account | 17 | 81 |

**14 of 43 P0 (33%) are accounts sales already owns or has already won** — five are live customers,
nine have an open opportunity in stages from Prospecting through Negotiation and Launched. They are
occupying the PLG hand-off queue while an AE is already working them:

| Tenant | Domain | CRM state | Open stage(s) |
|---|---|---|---|
| Tokenpocket | tokenpocket.pro | 3 open opps | Discovery & Qualification · Launched |
| Frank's Org | longbridge.sg | 2 open opps | Launched · Prospecting |
| LangGenius | dify.ai | won customer | Launched |
| DigiPlus's Org | tbu.net | won customer | Launched |
| Hang's Org / Bigdata's Org | plaud.ai (×2 tenants) | 2 open opps each | Launched · Technical Validation |
| PT. Tri Adi Bersama + reynald-…'s Org | anteraja.id (×2 tenants) | won customer, 14 opps | Launched · Negotiation |
| Coupang | coupang.com | 2 open opps | Business Validation · Negotiation |
| bbt-'s Org | bitkub.com | open opp | Technical Validation |
| tidb's Org | thelionparcel.com | open opp | Technical Validation |
| Shiprocket's Org | shiprocket.com | open opp | Technical Validation |
| Rohit 's Org | nslhub.com | won customer | — |
| KickAss Products | kickassproducts.com.au | open opp | Prospecting |

Note the shape of the noise: **the same company appears as two tenants** (plaud.ai, anteraja.id),
each holding its own P0 slot. The digest agent's own R10 rule already tells it to flag active
customers — but the *queue* is upstream of that rule, so the slot is consumed either way.

Meanwhile the 12 P0 marked "previously lost" are the real win-back pool, and the 17 "leads only"
are the genuinely unclaimed ones. **A P0 board of 43 is really ~29 actionable, of which 12 are
win-backs.**

## 3. The KickAss Products case, corrected

The monthly review records it as *"以淨新身分上榜（07-22），連續 9 個運行日無人認領，08-04 被認領"*.
CRM says otherwise:

| Date | What existed |
|---|---|
| 2026-04-08 | Tenant signs up **and** a Lead is created the same day — `Ryan Murtagh`, LeadSource **Direct Traffic**, owner **Mike Taylor**, Status **Nurture** |
| 2026-07-15 | Layer 1 scores it 70 / **P0** (QPS 298.6, 4 clusters, card on file) — and holds it there every day since |
| 2026-07-08 | A second Lead, Status **Customer**, **converted to Account "KickAss Products Pty Ltd"** |
| 2026-07-22 | The digest surfaces it as ✨ net-new |
| 2026-08-04 | Claimed; opportunity created — now Prospecting |

So on the day it was called "net-new" it had been a converted Account for two weeks, had carried a
Lead since April, and had been P0 in our own scoring table for a week. Two different lags, both real
and both fixable:

- **7 days** between Layer 1 calling it P0 (07-15) and the digest showing it (07-22).
- **20 days** between Layer 1 calling it P0 and a human claiming it (08-04).

The "net-new" label came from `no_active_owner` in the owner snapshot — Mike Taylor is not an active
owner — which is a true and useful fact, but it means **unclaimed**, not **unknown**.

## 4. What this changes

1. **Rename the category.** ✨ Net-new → **"unclaimed"**, and add a real net-new test (no Lead on the
   domain at all). Today that test would return approximately zero tenants, which is itself the
   finding.
2. **Exclude active-opportunity accounts from the P0 board, don't just flag them.** 14 of 43 P0
   slots are held by accounts an AE already owns. Suppressing them frees a third of the board with
   no change to scoring — the largest single de-noising available, larger than the dormancy work.
3. **Deduplicate by company, not by tenant.** plaud.ai and anteraja.id each burn two P0 slots.
4. **Win-back is the queue's real product.** 12 of 43 P0 are previously-lost accounts with fresh
   product behaviour — that is the highest-value pattern in this data and nothing in the model
   scores it explicitly.
5. **Lead Status is the follow-up truth, and it is queryable** — `Working` / `Nurture` /
   `UNQUALIFIED` / `Open Opportunity` are all present and populated. That is exactly the field the
   tenure-release rules need, and it is one grant away from being joinable
   ([`../universal/REQUEST_nexuscrm_read_access.md`](../universal/REQUEST_nexuscrm_read_access.md)).

## 5. Reproducing this

Live CRM reads run through the read-only OAuth app; the per-domain pull, the join and the
categorisation are in the session scratchpad (`fetch2.py` / `fetch3.py` / `p0p1_crm.csv`).
**The CSV is not committed** — it carries tenant and contact PII, which this repo does not hold.
Re-run the pull to regenerate it; the numbers above are as-of 2026-08-26 and will drift.