# 02 · Lightweight PQL Ops Memo

**To:** Lijia, Kerry, Yujie
**From:** Heidi
**Date:** 2026-06-23
**Re:** Three high-value action queues for EMEA — keep it simple

---

## TL;DR

EMEA has effectively **two downstream operators**. We are *not* rebuilding the scoring model or adding dashboards. We are adding **three small, well-defined action queues** on top of what the bot already produces, fixing one bot filter bug, and asking dev for one BQ lookup. That's the whole round.

---

## Why now (the business asks)

- **Lijia:** paid is outpacing direct engagement → prioritize paying-but-unconnected accounts.
- **Kerry:** can send targeted emails to credit-card-bound-but-unconnected accounts → he needs a clean list with contact columns.
- **Heidi:** can we fully monitor spending-limit changes? → **yes**, via `UpdateSpendingLimit` (473 tenants live).
- **A teammate:** should opening TiDB Cloud Premium be treated like Import? → **No** (see below).

---

## The three queues

> All three are **non-exclusive** — a tenant can appear on more than one. When an operator works the lists, **precedence = Import > Paid-but-unconnected > Spending-limit**, so the same account isn't worked from three angles at once.

### 1. `paid_but_unconnected` — **P1 (floored)**
- **Definition:** `has_credit_card = 1 AND COALESCE(track_step,0) <> 2`
- **Owner:** Kerry (targeted email).
- **Why P1:** real commercial commitment + no human channel yet = the highest-leverage outreach we have.
- **Floor:** these are **guaranteed at least P1** even if their computed score is lower — so a quiet-but-paying account can't slip to P2/P3 and get missed.

### 2. `spending_limit_unconnected` — **P1 (floored)**
- **Definition:** tenant has a succeeded `UpdateSpendingLimit` event **in the last 30 days** AND `COALESCE(track_step,0) <> 2` (distinct tenant, latest event). The 30-day window keeps it to *recent* commercial intent — an all-time list is ~473 tenants and would bury two operators.
- **Why P1, not P0:** raising a spending limit is a strong **capacity / commercial intent** signal, but not a confirmed workload. It earns priority attention, not emergency status.
- **Floor:** also **guaranteed at least P1**.

### 3. `recent_imports` — **P0 / P1**
- **Definition:** `CreateImport` succeeded in the **last 7 days** (run-date-anchored).
- **Why strongest:** import = clear **workload / migration intent**. This is the closest thing to "they are actually doing the thing." P0 when combined with strong usage/fit; P1 otherwise.

---

## Premium is **watch / context**, not Import

| Signal | Meaning | Priority effect |
|---|---|---|
| **Import** | clear workload / migration intent | strong — can drive P0/P1 |
| **Premium (alone)** | commercial curiosity / capacity exploration | **context only — watch, do not auto-prioritize** |

Premium raises priority **only when combined** with import, sustained QPS, paid, or spending-limit. Premium alone never equals import.
(Note: `premium_cluster_count>0` = **0 tenants** in EMEA live DB today, so this is a forward-looking guardrail, not a backlog item.)

---

## What `connected` means (so nobody misreads the queues)

`connected` (`track_step=2`) = **a human channel has been established** (Slack accepted / clear comms), **not** a product DB connection. "Unconnected" in every queue means we have signal but **no human channel yet** — exactly the accounts worth reaching out to.

---

## Explicit non-goals this round

- ❌ No frontend "why did they come" intent tracking (team is understaffed).
- ❌ No intent keyword clustering.
- ❌ No NexusCRM dependency.
- ❌ No `total_score` weight rewrite. The only scoring change is a **P1 floor**: paid-unconnected and spending-limit-unconnected accounts are guaranteed **at least P1** (raises priority, never lowers; already-P0 stays P0). This ensures low-scored-but-commercially-real accounts don't get missed. Premium alone gets **no floor**, and nothing auto-promotes to P0.
- ❌ No new dashboards or workflows.

---

## What we're asking dev for

See [03-engineering-handoff.md](03-engineering-handoff.md). In one line: fix the weekly filter, expose the three queues, add a BQ channel/UTM lookup by `tenant_id`. SQL drafts in [04-sql-drafts.sql](04-sql-drafts.sql).