# EMEA — Account-Relationship Categorization (business proposal)

**Author:** Heidi · 2026-07-24 (revised)
**Owner:** GTM / Yujie (eng, for whatever implementation they choose)

> **Revision note:** an earlier draft of this doc proposed porting a `·`-joined reason-string SQL
> pattern and a set of "reconciliation gates" modeled on APAC's shadow notification build
> ([`yybaroq/plg-notification`](https://github.com/yybaroq/plg-notification)). That build's own
> scoring/gating logic turned out to be actively buggy and non-authoritative (see the companion PR
> `apac-scoring-source-of-truth`, `apac/execution/apac-scoring-model-divergence-note.md`) —
> so this proposal no longer borrows any of its engineering. What's left below is the part that's
> actually worth taking from APAC: **the business categorization and routing judgments**, which have
> nothing to do with whether the SQL underneath them is correct. How EMEA engineering implements this
> (a new field, a lookup table, a manual tag — whatever fits `emea_lambda_tasks`) is entirely their
> call; this document only states the business requirement. (Filename kept its original date; renamed
> from "reason-signal-reconciliation" to reflect the narrower, business-only scope.)

---

## The idea worth taking from APAC

APAC's enrichment step classifies every P0/P1 account into one of six **relationship categories**
before deciding what to do with it, instead of treating every high-scoring account the same way:

| Category | Meaning |
|---|---|
| Net-new | No prior relationship — genuinely new lead |
| Open opportunity | Already has an open deal in CRM |
| Win-back | Was a customer before, later churned/disconnected, now showing renewed interest |
| Account, no opportunity | Known CRM account, no active deal |
| Partner/Verify | Looks like a systems integrator or services firm — needs a human check before treating usage as a genuine buying signal |
| Active customer | Already paying / already connected |

This is a **business** idea, not a technical one: it doesn't require any particular scoring model,
database, or delivery mechanism. EMEA's daily brief today (`EMEA-Daily-Intelligence-Brief.md` §2)
routes purely on `entity_ai_category` + usage signals; it has no equivalent notion of "have we already
got a relationship with this account, and what kind."

## Why EMEA should adopt it

Without this distinction, EMEA's existing routing can misfire in ways that cost AE trust in the
digest:

1. **An already-connected, paying customer can re-trigger a P0/P1 alert** (e.g. a usage spike) and get
   routed as if it were a fresh lead (`slg_same_day_outreach`) instead of to the existing
   TAM/expansion motion (`tam_escalation`, which EMEA already has as a route). The category alone
   tells you which one is right.
2. **A win-back (a former customer re-engaging) is arguably a *higher*-value event than a same-scoring
   fresh signup**, but nothing today distinguishes the two — they'd score and route identically.
3. **A services/SI/reseller firm's usage isn't the firm's own buying intent** — it may be running a
   client's workload. Counting it as a normal PQL risks an AE outreach that misreads the account
   entirely. This needs a manual verify step, not an automatic P0.

**This isn't hypothetical — case #1 already happened in APAC.** On 2026-07-24, `plg-notification`
shipped a fix for exactly this failure mode: a domain that didn't directly resolve to a CRM account
was flagging an already-converted customer ("DigiPlus") as a fresh net-new lead. The fix was a
domain→Lead-Company/ConvertedAccountId bridge lookup plus a hard rule ("a domain with an Open
Opportunity or a Converted Account is never net-new"). The fix itself is APAC-specific plumbing (not
being ported here — see the note at the top), but the failure mode it corrects is precisely why EMEA
needs the category distinction *before* hitting the same bug, not after.

## What EMEA-specific behavior this implies (business rules, not implementation)

- **Active customer + newly high-scoring → route to the existing expansion/TAM motion, not a
  same-day cold-outreach action.** This only requires knowing "is this account already a customer,"
  which EMEA can determine from existing CRM/billing data — no new signal needed.
- **Win-back accounts should be called out distinctly and treated as elevated priority**, not folded
  silently into the regular P0/P1 list. The business ask is visibility ("this is a win-back"), not a
  scoring formula change.
- **Suspected SI/partner/services accounts should be held for a quick human check** (real end-user vs.
  running someone else's workload) before an AE treats it as a standard qualified lead.
- **A known account with no open opportunity is a different conversation than a net-new lead** —
  worth a distinct label so AEs calibrate their outreach accordingly (re-engagement vs. first contact).

## Explicitly not part of this proposal

- No SQL, no reason-string format, no gating/priority logic, no schema — all of that in APAC's build
  is either unofficial, unverified, or (as of 2026-07-24) directly buggy. See the divergence note.
- No claim about *how* to detect these categories technically (CRM lookups, an enrichment step,
  whatever) — that is an engineering decision, made against EMEA's own data sources
  (`emea_active_tenants`, HubSpot), not a port of APAC's NexusCRM/Reo-based enrichment.
- No change to `total_score` or `priority` thresholds.

## Open question for GTM/eng to resolve together

Which of EMEA's existing fields (`sales_owner_email`, `track_step`, HubSpot deal/company data) are
sufficient to derive these categories today, and which require a new lookup? That scoping is the
actual next step, separate from agreeing the categories are worth having.