# EMEA TSE Outreach — Kerry Email Pack v1 **Owner:** Kerry Li (TSE, Europe) · **GTM alignment:** Heidi Liu **Use with:** P0 / P1 tenants from EMEA Tenants Monitor · `track_step`: `email` → `connected` (Slack accepted) **Placeholders:** `{first_name}` `{company}` `{country}` `{website}` **Internal only (never in customer email):** `{qps}` `{clusters}` `{plan}` `{score}` `{priority}` — use these to pick tier, not to quote. --- ## Privacy & outreach (EMEA / GDPR) — read before sending **Legal basis (typical B2B SaaS):** Contact is usually **contract / legitimate interest** — you are a TiDB Cloud service contact offering **technical support**, not cold marketing. Still apply **data minimization** and **transparency** (GDPR Arts 5–6, UK GDPR equivalent). | Do in email | Do not in email | |-------------|-----------------| | Identify yourself + PingCAP / TiDB Europe **support** role | “I was reviewing / scanning / monitoring EMEA accounts” | | “Your organization’s TiDB Cloud account” (they know they signed up) | Exact **QPS**, internal **scores**, **P0/P1**, bot field names | | “If you’re running workloads in production…” (conditional) | “We see you running **434 QPS**” unless **they** raised that metric | | Public facts (company name, their public site) | “From your profile: …” (sounds like undisclosed profiling) | | Offer opt-out: “Reply **no outreach** if you prefer email only for tickets.” | Imply blanket surveillance across all tenants | **Enrichment (`business_description`):** Treat as **internal research**. In copy, either cite **their public website** (“I read on {website} that…”) or **don’t cite** — ask what they’re building. **Subject lines:** No usage metrics. No “we noticed your usage.” See [Subject lines — open rate](#subject-lines--open-rate-without-spam) below. **Before scale send:** Confirm with **Legal / DPO** that EMEA proactive TSE outreach is covered under TiDB Cloud **Terms + DPA** and regional register. This pack is **operational guidance**, not legal advice. **F1 (errors):** Only contact if your process is tied to **support obligation** or **service health** under contract; avoid “our monitoring flagged you” unless approved wording exists. --- ## Design principles (why v0 felt “off” to technical readers) | Avoid | Use instead | |-------|-------------| | “Early Adopter Program”, “users like you” | “I’m on the Europe support engineering team” | | Long free-benefit bullet lists | One concrete offer: “reply with your blocker or accept Slack” | | Generic AI paragraph | Only if `company_ai_core` / `company_ai_related` — tie to *their* stack (agents, vector, scale) | | “Looking forward to connecting!” | Specific next step + low pressure | | Slack invite buried at end of a sales email | **Email 1:** offer help · **Email 2 or same day:** Slack invite + one-line why | | Quoting internal usage metrics (QPS, scans) | Role-based offer of support; let **them** share metrics if useful | **Success metric:** Slack invite **accepted** → mark `connected`. Email reply counts as warm; still send Slack if they prefer async. --- ## Tier map (which template to send) | Tier | Who | Signal (examples) | Template | |------|-----|-------------------|----------| | **A** | P0 · high usage | QPS ≥ 10 or clusters ≥ 3 with real QPS | [A1](#a1-first--high-usage-p0) · [A2](#a2-follow-up--high-usage) | | **B** | P0 · POC + AI company | `plan = poc`, AI core/related | [B1](#b1-first--poc--ai) · [B2](#b2-follow-up--poc) | | **C** | P0 · AI core, early / quiet | `new_user`, low QPS, AI core | [C1](#c1-first--ai-core-quiet-p0) · [C2](#c2-follow-up--quiet) | | **D** | P1 · AI core / related | Score ≥ 45, AI categories | [D1](#d1-first--p1-ai) · [D2](#d2-follow-up--p1-ai) | | **E** | P1 · non-AI corporate | `company_non_ai` + corp domain | [E1](#e1-first--p1-non-ai--observe-or-send) · [E2](#e2-follow-up--non-ai) | | **F** | P0/P1 · error on account | `error_message` set | [F1](#f1-first--blocked-by-error) | **Do not use this pack for:** `individual` / free-email P2 (PLG automation). **Unknown category:** enrich first ([Daily Brief](../EMEA-Daily-Intelligence-Brief.md) `manual_enrich_then_route`). **P1 rollout (Lijia pilot):** send **D1/D2** for `company_ai_core` + `company_ai_related` first; hold **E1** 1–2 weeks unless QPS ≥ 1 or `cluster_count` ≥ 3. --- ## Credits & programs — when to mention (not in A2 by default) | Tenant signal | A1/A2 high-usage (Tier **A**) | POC (Tier **B**) | Quiet / new (Tier **C**) | P1 no card / multi-cluster | |---------------|-------------------------------|------------------|--------------------------|----------------------------| | **Goal** | Trust → Slack / engineering reply | Unblock POC | Activation | Billing setup | | **Lead with** | Support only | Support + POC session | Support + quickstart | Support; **optional** billing walkthrough | | **Startup / TiDB credits** | **No** — reads as promo after silence | **Maybe in B2** if still `poc` / `free_trial` and they didn’t reply | **Maybe one line in C2** if `plan=new_user` | **One line in E1/E2 or HubSpot**, not Kerry cold spam | | **AWS Activate credits** | **No** — separate program & queue ([Operating Brief](../AWS-Activate-Program-Operating-Brief.md)); applicant must come via AWS batch | Same | Only if **you have a row** in `program_application` for their email | Same | **Why A2 should stay support-only** 1. **Tier A = already using the product** (high QPS / clusters). They need architecture help, not “free credits.” 2. **Second email + credits** = classic sales follow-up pattern → undermines TSE positioning and GDPR-light touch. 3. **AWS Activate** is low-volume, ops-owned (Hazel/BizOps), not something Kerry promises in 1:1 mail. 4. **A1 already allows “tier/cost fit”** if they reply — that opens a *conversation*; don’t lead follow-up with programs they didn’t ask for. **If they reply asking about cost:** answer in thread; route AWS Activate applicants to Program Ops, don’t invent amounts in email. --- ## Subject lines — open rate (without spam) **Why current subjects underperform:** phrases like *engineering support (Europe)*, *quick engineering intro*, *resources for {country} teams* read like **vendor bulk mail** or HR — not a person with a specific question. Technical inboxes optimize for **short + concrete + human**. | Principle | Do | Don’t | |-----------|-----|--------| | Length | **≤ 45 chars** when possible (mobile inbox) | Long parentheticals, region tags | | Specificity | **TiDB Cloud**, **POC**, **connection**, **vector** — nouns they recognize | “intro”, “program”, “opportunity”, “partnership” | | Human | Reads like one engineer wrote it | “TiDB Europe support team”, “Dedicated Support Program” | | Honest | Question only if email asks one | Fake `Re:` to a thread that doesn’t exist | | Follow-up | **Same thread:** `Re: [exact first subject]` | New subject on follow-up (breaks thread, lowers opens) | | Compliance | No QPS, no “we monitored you” | “Your usage”, “account review” | **Opens depend heavily on `From:`** — use a **person + company**, e.g. `Kerry Li · TiDB` <kerry.li@pingcap.com>, not `TiDB Cloud Team` or `noreply`. **Preview text** (first line after subject) matters as much as subject — keep it specific: *“One question on your TiDB Cloud account — …”* not *“I wanted to reach out…”*. ### Recommended subjects (canonical — use exactly what's in each tier section below) | Tier | First email (canonical) | Alt | Notes | |------|------------------------|-----|-------| | **A** | `one TiDB Cloud question — {company}` | `production on TiDB Cloud — {company}` | Don't assert a specific problem in the subject; body proposes the hypothesis | | **B** | `TiDB Cloud POC — where are you stuck?` | `TiDB POC + agent state — {company}` *(AI POC only)* | | | **C** | `first TiDB Cloud connection — {company}` | `TiDB Cloud + agent memory — {company}` *(clear AI builder)* | | | **D** | `[technical noun] — {company}` (e.g. `agent state on TiDB Cloud — Finaloop`) | n/a — varies per tenant | See D1 examples | | **E** | `MySQL at scale — {company}` | `one question about your TiDB Cloud setup` | | | **F** | `TiDB Cloud cluster issue — {company}` | `{company} — TiDB Cloud error` | Use only when `error_message` is real | **Follow-up:** always `Re: [exact first subject]` — body can change; subject should not. **A/B for EMEA pilot:** Kerry sends **canonical** to half of P1 AI batch, **Alt** to half; track reply + Slack accept in sheet. --- ## A1 · First — high usage (P0) **When:** Quickfire, Pixl8, Dave's Org, Mustapha's Org, etc. *(internal: QPS ≥ 10 or clusters ≥ 3)* **Subject:** `one TiDB Cloud question — {company}` **Alt:** `production on TiDB Cloud — {company}` Hi {first_name}, Once an account is past early testing, the friction points are usually one of three: **connection pooling, hot key / index design, or tier fit** (Serverless vs Dedicated). I can look at your setup and tell you which one is biting — or if it's something else entirely. Reply with your client/driver stack (one line) or paste a slow query, and I'll respond with something concrete. If everything's running smoothly, ignore this. Kerry Li · TiDB Europe *(Reply **no outreach** if you'd prefer I only respond when you contact support.)* --- ## A2 · Follow-up — high usage **When:** 5–7 days after A1, no reply. **Do not add:** credits, program, or AWS Activate — see [Credits & programs](#credits--programs--when-to-mention-not-in-a2-by-default). **Subject:** `Re: one TiDB Cloud question — {company}` *(exact match to A1)* Hi {first_name}, Different angle in case the first email wasn't relevant: one thing that often surprises teams running steady load is **monitoring blind spots** — slow query log and TopSQL show patterns that aren't visible from app-side latency. Worth 5 minutes in the TiDB Cloud console under Diagnostic → Top SQL. If you'd like a second pair of eyes on any of that, share what you see and I'll comment. Kerry --- ## B1 · First — POC + AI **When:** Arkbauer, Workday, Sinch (robin.venneman), Tomasz, Zachary, etc. **Subject:** `TiDB Cloud POC — where are you stuck?` **Alt (AI companies only):** `TiDB POC + agent state — {company}` Hi {first_name}, POCs on TiDB Cloud usually stall in one of three places: networking/SSL to the cluster, schema migration from an existing DB, or uncertainty about whether to use Serverless or Dedicated for the workload you're actually testing. Which one is it — or is it something else? One sentence is enough. I can do a 20-minute working session on the specific blocker, not a general walkthrough. Kerry Li · TiDB Europe *(Reply **no outreach** if you'd prefer I only respond when you contact support.)* --- ## B2 · Follow-up — POC **When:** 7 days after B1, no reply. **Subject:** `Re: TiDB Cloud POC — where are you stuck?` *(exact match to B1)* Hi {first_name}, Last note — if you've already chosen a different path, no need to reply. If the POC is still open: what's the one test that would make it a clear yes or no for you? (Query latency, migration complexity, pricing, compliance — pick one.) I'll answer directly. **Optional** — only if internal signal shows `plan = poc` or `free_trial` still active and they haven't run meaningful queries: > If the blocker is budget for extending the POC, reply **credits** and I'll share what's available — I can't approve anything in this email, but I can point you to the right channel. Kerry --- ## C1 · First — AI core, quiet (P0) **When:** `new_user` or `free_trial`, low/zero QPS, `company_ai_core` (e.g. Vadym @ Merck, codemine). **Subject:** `first TiDB Cloud connection — {company}` **Alt (clearly agent/AI builder):** `TiDB Cloud + agent memory — {company}` Hi {first_name}, Most new TiDB Cloud accounts get stuck in the same first place: the **SSL CA cert path** for the driver. If you're hitting a connection error, paste the error text (no passwords) and I'll tell you in one reply whether it's cert, network, or account config. If you're building an AI app and not sure where to start, the agent memory quickstart in TiDB Cloud docs is a better first test than a generic CRUD example — happy to point you to the specific page if useful. Kerry Li · TiDB Europe *(Reply **no outreach** if you'd prefer I only respond when you contact support.)* > **Kerry verify before sending:** the exact path to "agent memory quickstart" on docs.pingcap.com — link only if you've opened the page yourself this week. --- ## C2 · Follow-up — quiet **When:** 5 days after C1, no reply. **Subject:** `Re: first TiDB Cloud connection — {company}` *(exact match to C1)* Hi {first_name}, One more thing to try: TiDB Cloud → your cluster → **Connect** → copy the connection string → run `SELECT 1` with your driver. If it fails, paste the error text here (redact any passwords) and I'll diagnose it. **Optional** — only if internal signal shows `plan = new_user` or `free_trial`: > If budget is a concern during testing, reply **credits** and I'll share what's available for your company stage. Kerry --- ## D1 · First — P1 AI (core / related) **When:** P1 + `company_ai_core` or `company_ai_related` **How to use this section:** Read the three worked examples first — they show the pattern. Then adapt for your actual company. --- ### D1 worked example — Finaloop (fintech AI, 6.9 QPS, 1 cluster) **Subject:** `agent state on TiDB Cloud — Finaloop` Hi Kfir, Real-time financial reconciliation has a specific backend pattern that often gets ugly: keeping transactional state consistent while running analytics queries on the same data, without standing up a separate analytics replica. Teams who try to bolt a vector store onto Postgres usually find the two drift apart under load. TiDB handles transactional and analytical workloads in one engine (HTAP) — the analytics queries don't block writes. If that maps to what you're building, happy to share how a couple of fintech teams structured the schema. One paragraph from you is enough to know if it's relevant. Kerry Li · TiDB Europe *(Reply **no outreach** if you'd prefer I only respond when you contact support.)* --- ### D1 worked example — Wild Vision (wildlife AI, 10.9 QPS, 1 cluster) **Subject:** `vision AI + TiDB Cloud — Wild Vision` Hi Andrew, For vision AI moving past the prototype stage, the recurring question is usually what state to keep between runs — detections, classifications, spatial metadata, session history — and whether that lives in one place or gets split across a vector store and a relational DB. TiDB keeps it unified in one engine: vector index, structured queries, and full-text search. If you're about to design the state layer (or rework it), worth comparing notes before committing to a multi-DB setup. What does your current stack look like? Kerry Li · TiDB Europe *(Reply **no outreach** if you'd prefer I only respond when you contact support.)* --- ### D1 worked example — Philipp's Org / logiks.solutions (4 clusters, low QPS) **Subject:** `agent memory architecture — logiks` Hi Philipp, Multiple clusters with low query volume usually means active development rather than production scale — building out the loop before optimizing it. The architectural decision that catches teams at this stage: once an agent needs to resume across sessions or share context between instances, local state (JSON files, SQLite) stops being good enough. Migrating off it later is expensive. The pattern that works well is an independent SQL substrate — session history, task records, retrieval metadata — that the agent framework reads from but doesn't own. What's the agent stack at logiks, and is state portability something you're thinking about yet? Kerry Li · TiDB Europe *(Reply **no outreach** if you'd prefer I only respond when you contact support.)* --- ### D1 default (use for the ≈11 other AI P1 tenants — works when you don't have public context) **Subject:** `agent state on TiDB Cloud — {company}` **Alt:** `vector search on TiDB Cloud — {company}` *(if their product clearly involves vectors/embeddings)* Hi {first_name}, For AI products that move from prototype toward production, the part that usually needs rethinking first is **state**: where session history, embeddings, task records, and user data actually live, and whether they stay consistent across services. Most stacks end up with a vector store + a relational DB + a cache, and the integration cost grows. TiDB keeps vector search, structured queries, and full-text in one engine — one connection, one source of truth. If you're at that design point, what does your current state layer look like? Even one sentence helps me say something useful back instead of a generic overview. Kerry Li · TiDB Europe *(Reply **no outreach** if you'd prefer I only respond when you contact support.)* --- ### D1 personalization rules (when adapting the default) - **Pull one fact from their website** before sending. If you can't find one in 60 seconds, send the default unchanged — don't fabricate. - **Don't name their framework** (LangGraph, LlamaIndex, etc.) unless you've seen it in their public docs or GitHub. Ask instead. - **Don't quote QPS or cluster count.** Use it to pick the tier, not to write the email. - **The hook in sentence 1 must be about them, not Kerry.** --- ## D2 · Follow-up — P1 AI **When:** 5–7 days after D1, no reply. **Subject:** `Re: [exact D1 subject]` **Pattern:** Don't re-explain TiDB. Drop one specific technical artifact — a schema snippet, a benchmark number, a doc link — that's useful even without a reply. Make it easy to forward internally. --- ### D2 worked example — Finaloop Hi Kfir, One follow-up — here's the schema pattern most fintech teams start with for agent state on TiDB: ```sql CREATE TABLE agent_sessions ( session_id VARCHAR(64) PRIMARY KEY, user_id VARCHAR(64), created_at DATETIME(3), state_json JSON ); CREATE TABLE agent_events ( event_id BIGINT AUTO_INCREMENT PRIMARY KEY, session_id VARCHAR(64), event_type VARCHAR(32), payload JSON, ts DATETIME(3), INDEX idx_session (session_id, ts) ); ``` Vector index goes on a separate `embeddings` table — or on the `payload` column if you're keeping it simple. The point is the events table stays queryable: you can reconstruct any agent run, filter by type, join to user records. If that's close to what you need, I can show you the HTAP query pattern on top of it. Otherwise — what does your current reconciliation state look like? Kerry --- ### D2 worked example — Philipp / logiks Hi Philipp, Following up once. The fastest way to test independent agent state on TiDB Cloud is via the Serverless tier — instance live in seconds, MySQL-compatible, no infra to configure. From the TiDB Cloud console: create cluster → Connect → copy the connection string → use any MySQL driver. If portable agent state is something you're evaluating, I can point to the specific docs page that covers the framework-agnostic pattern (rather than a marketing overview). Kerry > **Kerry verify before sending:** name the actual tier ("Serverless" vs "Zero" — whichever is current product naming) and only link a docs page you've opened this week. --- ### D2 template Hi {first_name}, [One specific technical thing — a code snippet, a schema, a doc link, a benchmark — useful on its own. Not "just checking in." Not a re-pitch.] [Optional: one open question if the first email's question went unanswered. Don't ask a new one.] Kerry --- ## E1 · First — P1 non-AI (observe or send) **When:** P1 + `company_non_ai` + corporate email — after AI P1 batch, or when QPS/clusters justify outreach. **Subject:** `MySQL at scale — {company}` **Alt:** `one question about your TiDB Cloud setup` Hi {first_name}, Teams that move from MySQL to TiDB Cloud usually do it because they've hit one of three walls: replication lag at write volume, throughput ceiling on a single primary, or operational overhead from sharding. If that's roughly the context, I can share how similar setups were structured. What workload are you evaluating TiDB for? Kerry Li · TiDB Europe *(Reply **no outreach** if you'd prefer I only respond when you contact support.)* --- ## E2 · Follow-up — non-AI **When:** 7 days after E1, no reply. **Subject:** `Re: MySQL at scale — {company}` *(exact match to E1)* Hi {first_name}, Last one from me. If you're in the middle of evaluating, the [production checklist](https://docs.pingcap.com/tidbcloud/) is the most useful starting point — it covers the migration steps most teams wish they'd read earlier. If you want a human on a specific architecture or billing question at any point, reply here. Kerry --- ## F1 · First — blocked by error **When:** `error_message` populated. Send in parallel to whichever P tier applies. **Subject:** `TiDB Cloud cluster issue — {company}` **Alt:** `{company} — TiDB Cloud error` Hi {first_name}, If you're seeing connectivity issues or errors in your TiDB Cloud console, reply with the exact error text (redact passwords) and I'll diagnose it. If everything is working fine on your end, ignore this. Kerry Li · TiDB Europe --- ## Opt-out line — canonical wording **Every first email already includes this.** Use this exact line, no variants: > *(Reply **no outreach** if you'd prefer I only respond when you contact support.)* **Internal:** if a recipient replies "no outreach," log it in the sheet under `track_step = opted_out` and do not contact them proactively again. This is a manual process — no automation behind it. If we move to higher volume, replace with a real preference-management link via HubSpot. --- ## Optional public context (one sentence max) Use **only** when sourced from the customer's **public** website or press — not from internal `business_description` alone: > I had a quick look at {website} — {one_public_sentence}. Place after the first paragraph. Skip if you cannot cite a public URL. --- ## Slack invite — clarify before promising channels **Open question for Kerry / Heidi to resolve before sending Slack at scale:** - The **TiDB Community Slack** is a public OSS workspace — you can't create per-customer support channels there. - A **per-customer support channel** requires either (a) a separate PingCAP-controlled Slack Connect setup, or (b) inviting them to an existing private workspace. **Until that's decided, do not promise `#support-{company}` channels in email.** Use this wording instead, which is honest about what Slack actually offers right now: > Happy to move this to chat if it's easier — I can send you a TiDB Community Slack invite where I'm reachable async. (No obligation to join calls or stay active.) **Internal:** On Slack accept → `track_step = connected`. If they reply by email but decline Slack → `track_step = email_replied`. Both count as success for this pilot. --- ## Personalization cheat sheet (30 seconds before send) | Field | Source | Customer email? | |-------|--------|-----------------| | `{first_name}` | Email local part or LinkedIn — avoid "Hi ," | Yes | | `{company}` `{country}` `{website}` | Bot / CRM / public site | Yes | | `{one_public_sentence}` | **Public** website only — not bot `business_description` alone | Yes, if public | | `{qps}` `{clusters}` `{plan}` `{score}` | Daily summary — **tier selection only** | **No** | | Wrong email (e.g. Robin @ Sinch left) | **Do not send** — note in sheet, try alternate from LinkedIn/community | — | **Jacob's Org (individual, high QPS):** treat as edge case — optional A1 with lighter tone; confirm with Lijia before SLG-style outreach. --- ## Suggested send order (week of 2026-05-26) 1. **P0 remaining** without `track_step=email`: A1/B1/C1 by tier. 2. **P1 AI (≈14):** D1 at ~5/day — avoid same-domain duplicates (two Sinch → one thread). 3. **P1 non-AI:** hold E1 unless cluster ≥ 3 or QPS ≥ 0.1. 4. **Follow-ups:** A2/D2/B2 at +5–7 days for no reply / no Slack accept. --- ## Changelog | Date | Change | |------|--------| | 2026-05-26 | v1 — rewrite from Kerry draft; tiered first + follow-up; technical tone | | 2026-05-26 | v1.1 — GDPR/data minimization: no account scanning language; no QPS in customer copy; public-context only | | 2026-05-26 | v1.2 — subject line guide + shorter, question-led subjects; follow-ups thread on Re: | | 2026-05-27 | v1.3 — full rewrite A/B/C/E/F: no Kerry intro opener, reader-first hook, technical subject lines | | 2026-05-27 | v1.4 — self-challenge pass: stale subject table fixed; A1 subject less presumptuous; A2 different angle; D1 default added for the other 11 P1 AI tenants; opt-out wording unified; Slack channel promise rolled back to truthful version; "Kerry verify" notes on CLI commands and doc links |