Fintalent OSW — Lean Launch v3: Setup → Segments → SDR Loop → KAM Calls

v3 — re-walk toàn bộ trên build UAT 19/07 (UI redesign lớn: Segments, bảng Simple/Full, Inbox, SDR list độc quyền), re-verify 20/07 với FE develop @ 714f6e4cf2 (đọc source + đi live). Kế thừa v1 (nền 23 flows + verify API 15–17/07) và v2 (delta 17/07 chiều); mọi khác biệt của build mới nằm ở §Δ3 và đã cập nhật vào từng flow. Ảnh mới: bộ v3s-* (19/07) + v3s-140 (view-as-role, 20/07). Guideline người dùng song hành: v4.html.

0 · Cách đọc & Thuật ngữ

Δ3 · Build 19/07 — re-walk toàn bộ, có gì đổi ✅ verify UI + behavior 19/07

Đi lại toàn bộ chuỗi flow bằng admin (dev@fintalent.io) + Login-as SDR Internal Fintalent + Login-as KAM Fintalent; test hành vi trên list QA tự tạo/tự xoá. Xếp theo mức ảnh hưởng:

SDR-list gate — semantics đã kiểm chứng

flowchart LR
  ADD["Add contact C vào SDR list B"] --> Q{"C đã thuộc
SDR list khác (A)?"}
  Q -->|"Không"| OK["C vào B (membership bình thường)"]
  Q -->|"Có"| SKIP["BYPASS — C giữ nguyên ở A
toast: skipped (đã thuộc SDR list khác)"]
  SKIP -.-> W1["⚠️ form text nói 'removes from other SDR lists' — copy sai"]
  SKIP -.-> W2["⚠️ Timeline của B vẫn ghi 'Members added' — log sai"]
  classDef default fill:#fff,stroke:#CCC8D5;

Không đổi (re-verified 19/07): Create Contact dedupe (Duplicate Found panel) · Add-to-list semantics thường (Selected/All matching cap 10.000/run · dedup im lặng · add nhiều list 1 lần "Add to N list(s)") · add-members drawer auto-exclude · Remove from list + confirm · xoá list còn members được · Assign theo role badge · Update Admin Information 5 tab.

1 · Tổng quan motion

1.1 · Bức tranh end-to-end

flowchart TD
  subgraph P0["Phase 0 · Setup (Admin)"]
    direction LR
    A1["ADM.0.1
Users + roles ✅"] --> A3["ADM.0.3
Import data ✅"] --> A7["ADM.0.7
Admin sửa info ✅"]
  end
  subgraph P1["Phase 1 · Contact lists (Ops)"]
    direction LR
    L1["SDR.1.20
Create list ✅"] --> L2["OPS.0.8
Assign list ✅"] --> L3["OPS.0.6
List rules ❌"]
  end
  subgraph P2["Phase 2 · SDR Loop — làm việc trên contact list được giao"]
    direction LR
    Q["SDR.0.1
List + lọc ✅"] --> W["SDR.0.3
Workspace ✅"] --> E["SDR.0.11
Compose ✅"] --> S["SDR.0.12
Send→log ✅"] --> F["SDR.0.13
Follow-up ✅"] --> R["SDR.0.15
Reply ✅"] --> C["SDR.0.16
Classify ✅"]
  end
  subgraph P3["Phase 3 · KAM ❌"]
    direction LR
    H["SDR.0.17
Handoff ❌"] --> K1["KAM.0.1
Book Zoom ❌"] --> K5["KAM.0.5
Call+record ❌"] --> K7["KAM.0.7
AI outcome ❌"]
  end
  P0 --> P1
  P1 --> P2
  P2 -->|"Interested"| P3
  click A1 "#adm01"
  click A3 "#adm03"
  click A7 "#adm07"
  click L1 "#sdr120"
  click L2 "#ops08"
  click L3 "#ops06"
  click Q "#sdr01"
  click W "#sdr03"
  click E "#sdr011"
  click S "#sdr012"
  click F "#sdr013"
  click R "#sdr015"
  click C "#sdr016"
  click H "#sdr017"
  click K1 "#kam"
  click K5 "#kam"
  click K7 "#kam"
  classDef default fill:#fff,stroke:#CCC8D5;

✅ đã chạy được · 🟡 một phần (nền tảng có, còn thiếu mảnh nhỏ) · 🔵 đang làm · ❌ chưa có — chi tiết từng flow ở §3–§6

Nhìn nhanh — flow chưa trọn vẹn đang thiếu đúng cái gì (click mã flow để xem chi tiết)

SDR.0.18 hiển thị ✅ nhưng còn 1 gap an toàn: chưa chặn cứng suppression trên mọi send path (mới cảnh báo) — G1/P0, xem §8.

1.2 · Lifecycle = state machine của contact list chốt 16/07

Trục xương sống của toàn bộ SDR loop là contact lifecycle. Không có "queue" nào khác ngoài contact list — trạng thái contact nhảy trên ladder này, và cách nhìn list (cột Lifecycle / Last Contact + quick-filter pin) chỉ là các lát cắt của ladder.

flowchart LR
  P["Prospect (Lead)
chưa đụng vào"] -->|"send email đầu tiên
(tự động qua date filter — xem ⚠️ §1.3)"| IC["In Conversation
đã connect · Replied / No reply"]
  IC -->|"khách reply → SDR classify (đặt lifecycle)"| CL{" "}
  CL --> OKG["✅ Interested"] --> SC["Schedule call"] --> PS["Platform signup"] --> PJ["Projects…"]
  CL --> COLD["🥶 Not Now · OOO ·
Email Updated · No Categories"]
  CL --> DEAD["🆘 OptedOut · Do Not Contact ·
Left The Company · Not Interested"]
  COLD -.->|"re-entry theo rule OPS.0.6
(hằng số CHƯA chốt)"| IC
  classDef default fill:#fff,stroke:#CCC8D5;

[20/07 recount từ FE HEAD] ContactLifecycleEnum = 18 giá trị (không phải 20) — ngoài các nhãn trên còn nhãn hệ thống/tự động: Open · Click · Bounce · Dropped · PlatformSignUp · InProject · ProjectCompleted (KHÔNG có 'Replied' — verify source graphql.ts 22/07). Row lifecycle dropdown render 14 option (CONTACT_LIFECYCLE_OPTIONS): 9 nhãn SDR set tay + No Categories · Call Scheduled · Platform Sign Up · In Project · Project Completed (3 cái cuối read-only khi đã set). Bộ nhãn classify (EmailLogCategorizeEnum) = 11 giá trị (CallScheduled · DoNotContact · EmailUpdated · Interested · LeftTheCompany · NoCategories · NotInterested · NotNow · NotResponded · OptedOut · OutOfOffice — verify FE HEAD 20/07). Lưu ý drift: constant options của row dropdown có InConversation (KHÔNG có trong ContactLifecycleEnum) và thiếu OutOfOffice (có trong enum + facet) — cần BE confirm.

1.3 · Không còn “queue” / 3 view — SDR làm việc trên list, gửi mail theo trường hợp cập nhật 22/07

Không có "queue" riêng, và SDR KHÔNG dựng được "3 view" bằng filter: trên members bar của list, SDR/KAM bị khoá "+ Add filter" (lockFilters = isRoleSdr‖isRoleKam → showAddFilter=false, contacts-list-template/index.tsx:772) — chỉ còn quick-filter pin sẵn (Lifecycles · Has signal · New signal since follow-up), comment source gọi là "a fixed slice, not a filter workbench". Vì thiếu filter In Conversation / Last Email Sent Date, SDR không lọc ra được Replies/Follow-ups trên list. Thay vào đó SDR làm việc trên list + Inbox và quyết định gửi mail theo TRƯỜNG HỢP. Bảng dưới: mỗi trường hợp = 1 lý do gửi + cách SDR nhận biết (số kiểm chứng API 16/07 vẫn đúng ở tầng logic):

Nguyên liệu của các công thức lọc không chỉ có trên UI — chúng là field chính thức của ContactV2ConditionInput (API): bListIds · bLifeCycles · bSyncDateRepliedEmailLog · bLastEmailSentDate (introspect 16/07, xem DTO §5.1).

Các mốc tự vận hành ở tầng data (không cần code thêm): gửi xong → sync ghi lastEmailSentDate (trễ cỡ phút) → contact hết là "chưa gửi". Khách reply → sync ghi syncDateRepliedEmailLog → nổi lên Inbox. Signal mới về sau email cuối → khớp aHasSignalSinceReply. Số kiểm chứng 16/07 (list 16072026v1): 369 chưa gửi + 29 đã gửi (3 reply + 26 im lặng) = 398 = cả list ✓ — verify ở tầng API/admin; SDR trên members bar chỉ tiếp cận tập con qua quick-filter pin sẵn.

1.4 · Readiness 23 flows (sau các quyết định 16/07)

So với audit 15/07 (5 ✅ / 7 🟡 / 11 ❌), bức tranh sáng lên đáng kể nhờ 2 quyết định: "queue" = chính contact list + view filter (không cần hệ thống riêng) và ADM.0.7 đổi nghĩa thành admin sửa info (đã có sẵn).

2 · Catalog GraphQL operations

Toàn bộ operation mà chuỗi lean flows chạm vào, đã verify qua target/uat-lean-flow-check.py (15/07, 23 bước PASS) và session UI 16/07:

3 · Phase 0 — Setup (Admin)

3.1 · ADM.0.1 — Tạo user + gán role SDR / KAM ✅ Có

3.2 · ADM.0.3 — Import companies + contacts ✅ Có

Data companies + contacts đã có sẵn trong hệ thống (import từ nguồn crawl/CRM cũ). SDR có quyền sửa record và tạo contact mới khi thiếu:

DTO — tạo contact lẻ + dedupe (verify introspection)

3.3 · ADM.0.7 — Admin cập nhật info cho SDR / KAM ✅ Có

4 · Phase 1 — Chuẩn bị contact lists (PIC: Ops)

4.1 · SDR.1.20 — Tạo list + add contacts ✅ Có · UAT 4/4 PASS

DTO input/output — verify UAT 16/07

Sequence — tạo list & add members xuyên tầng

sequenceDiagram
  autonumber
  participant Ops as Ops (UI /contacts · Add to list)
  participant GQL as GraphQL admin-api-uat
  participant DB as Mongo (custom_lists · contacts)
  Ops->>GQL: createCustomList(input{name, type: Contact})
  GQL->>DB: insert custom_lists
  GQL-->>Ops: AdminCustomListDetail {id, memberCount: 0}
  Ops->>GQL: addContactsCustomList(ids:[listId], input{contactIds})
  GQL->>DB: push members
  GQL-->>Ops: [AdminCustomList]
  Note over GQL,DB: memberCount sync Atlas trễ vài giây
(verify nên retry)
  Ops->>GQL: customList(id) — verify memberCount

4.1b · Bản đồ Add-to-list — 7 entry point + hành vi membership ✅ deep-check UI 17/07

Add-to-list không chỉ có 1 đường từ /contacts — có 7 entry point, tất cả hội tụ về cùng 1 kho membership (custom_lists.members) với cùng semantics. Đã chạy thật từng đường trên list QA riêng (tự tạo → verify count → tự xoá):

flowchart LR
  subgraph EP["Entry points (UI)"]
    E1["/contacts — tick n người
hoặc All matching (cap 10.000/run)"]
    E2["Chip Lists trên từng contact row
→ drawer Manage lists for ‹contact›"]
    E3["List detail → + Add members
(drawer tự exclude member cũ
qua chip ✕ Custom List)"]
    E4["Company detail → tab Employees"]
    E5["/companies — tick company
→ Add to list (list Company)
+ Preview contacts"]
    E6["Campaign detail → tab People"]
    E7["Marketing Email → tab People"]
  end
  P["Drawer Add to list
Apply to: Selected (n) ⊕ All matching
picker chọn list — KHÔNG tạo được list mới"]
  M[("membership
custom_lists ⟷ contacts")]
  E1 --> P
  E3 --> P
  E4 --> P
  E6 --> P
  E7 --> P
  E2 -->|"tick/untick nhiều list → nút xác nhận
nhãn động: Add to N / Remove from N list(s)
(có + Create New riêng)"| M
  E5 -->|"list loại Company"| M
  P --> M
  M --> V["Bộ lọc của SDR (§1.3)
+ member count (sync trễ vài giây)"]
  classDef default fill:#fff,stroke:#CCC8D5;

4.2 · OPS.0.8 — Assign list cho SDR ✅ Có

DTO — assign qua assignedToIds (verify UAT 16/07)

4.3 · OPS.0.6 — List rules (approval + hằng số vận hành) ❌ Chưa có

Activity — hành trình Ops chuẩn bị & giao list (kèm approval gate to-be)

flowchart TD
  A(["Ops cần feed việc cho SDR"]) --> B["Filter /contacts theo ICP (§4.1)"]
  B --> C["Add to list — tạo mới / chọn list có sẵn"]
  C --> D{"Chất lượng list ổn?"}
  D -->|"Chưa — lọc lại"| B
  D -->|"Ổn"| E{{"❌ to-be OPS.0.6: approval gate
draft → approved (chỉ list approved mới assign được)"}}
  E --> F["Assign list cho SDR — assignedToIds (§4.2)"]
  F --> G["Member chưa-từng-gửi → SDR lọc
Lifecycles: Prospect (case A, §1.3)"]
  G --> H(["SDR bắt đầu vòng lặp §5"])
  classDef default fill:#fff,stroke:#CCC8D5;

5 · Phase 2 — The SDR Loop

Toàn bộ 11 flow của Phase 2 là MỘT vòng lặp: contact list → workspace → email → follow-up → reply → classify → quay lại list hoặc thoát ra deal/suppression.

Activity — một ngày làm việc của SDR (không còn 3 view — gửi mail theo trường hợp)

flowchart TD
  A(["SDR login → mở list được giao (§5.2)"]) --> INB{"INBOX: có reply
mới của khách?"}
  INB -->|"Có"| R["Trả lời reply trong thread (§5.8)
hệ thống auto-nhãn → SDR set lifecycle (§5.9)"]
  R --> Q1{"Interested?"}
  Q1 -->|"✅"| G["(to-be G2) tạo deal → handoff KAM"]
  Q1 -->|"🥶 / 🆘"| INB
  G --> INB
  INB -->|"Hết reply"| L["Quét MEMBERS list
quick-filter pin: Lifecycles · Has signal · New signal since follow-up
+ cột Last Contact 💬 — SDR KHÔNG '+ Add filter'"]
  L --> C{"Trường hợp gửi?"}
  C -->|"Signal mới sau email cuối"| D["Gửi lại có ngữ cảnh (⚡/💼)"]
  C -->|"Chưa từng gửi (Prospect)"| N["First-touch email"]
  C -->|"Đã gửi · Last Contact dài"| F["Follow-up trong thread (§5.7)"]
  D --> O["Gửi tay → auto-log → lifecycle/sent-date đổi (§5.6)"]
  N --> O
  F --> O
  O --> C
  C -->|"Hết"| P(["Xong việc hôm nay"])
  classDef default fill:#fff,stroke:#CCC8D5;

Không còn thứ tự 3 view cứng. Ưu tiên: reply (Inbox) → signal mới → chưa gửi → follow-up im lâu; nhận biết qua Inbox + quick-filter pin + cột Last Contact (do bị khoá "+ Add filter").

Vòng lặp SDR ↔ User guide Flow — cả vòng đã chạy, chỉ hở đúng bước hand-off

flowchart TD
  L["Login
(Flow 1)"] --> O["Mở list được giao & tìm contact
(Flow 2)"]
  O --> M["Quản lý / classify contact
(Flow 3)"]
  M --> S["Gửi email 1:1
(Flow 4)"]
  S --> RP(["Khách reply về"])
  RP --> IN["Inbox: đọc & trả lời
(Flow 5)"]
  IN --> FU["Follow-up khi khách im lặng
(Flow 6)"]
  FU --> OC["Kênh khác — WhatsApp / LinkedIn
(Flow 7)"]
  OC --> Q{"Interested?"}
  Q -->|"Chưa · 🥶 tạm dừng · 🆘 loại"| O
  Q -->|"Có ✅"| HO["Hand-off sang KAM
(Flow —, ❌ SDR.0.17 chưa build)"]
  class L,O,M,S,RP,IN,FU,OC,Q ok;
  class HO gap;
  classDef default fill:#fff,stroke:#CCC8D5;
  classDef ok fill:#ECFDF3,stroke:#12B76A;
  classDef gap fill:#FEE4E2,stroke:#D92D20,color:#912018;

Xanh = bước đã chạy được (Flow 1–7 map thẳng vào User guide) · Đỏ = lối ra Interested→KAM chưa build (SDR.0.17). Vòng lặp trọn vẹn trừ đúng 1 hand-off.

5.0 · View & quyền của SDR/KAM (khác Ops/Admin) ✅ verify source + live 20–23/07

Nguyên tắc phân vai: Ops/Admin chuẩn bị & sở hữu data (tạo list, giao việc, sửa CRM tổng); SDR/KAM chỉ LÀM VIỆC trên list được giao. UI enforce khác biệt này ở 3 tầng: (1) menu, (2) trang bị ẩn, (3) hành động bị khoá trong từng trang. Ma trận từng hành động + evidence file ở §5.4c — mục này là bản tóm nhìn-nhanh.

Tầng 1 — Menu Sales Management (SDR thấy 8 / 15)

Admin Sales v2 = 15 mục; SDR/KAM bị trim còn 8 ⇒ SDR không tiếp cận CRM tổng (Contacts/Companies), chỉ list được giao + Inbox (§5.2). Landing sau login = /projects (G16 — nên đổi về /segments).

Tầng 2–3 — SDR/KAM làm được gì / KHÔNG (Ops/Admin đầy đủ)

5.1 · SDR.0.1 — Login → làm việc trên list được giao (gửi mail theo trường hợp) ✅ Có ↔ User guide: Flow 1–2

SDR login → mở list được giao. SDR bị khoá "+ Add filter" (chỉ quick-filter pin sẵn — lockFilters, §1.3) nên KHÔNG tự dựng 3 view; SDR gửi mail theo trường hợp (§1.3). Các công thức lọc dưới đây mô tả LOGIC từng trường hợp (chạy ở tầng API + Inbox); ảnh minh hoạ:

Ba bề mặt filter của lean — mỗi thanh lọc cái gì (số kiểm chứng list 17072026v3)

flowchart TD
  subgraph MB["List · thanh members — lọc CONTACT"]
    MB1["Lifecycles
Prospect: 359 → 107"]
    MB2["Has signal (cấp CONTACT)
Yes: 359 → 246"]
  end
  subgraph CR["List · rail company — lọc COMPANY (rồi ra người của company đó)"]
    CR1["Lifecycle"]
    CR2["Has signal (cấp COMPANY)
Yes: 111 → 29"]
  end
  subgraph IB["Inbox · thanh filter — lọc thread/reply"]
    IB1["Lifecycles · Contact Classification · Owner"]
    IB2["Work Experience → Company type
Sponsor: 27 → 25"]
    IB3["Countries · Cities · + Add filter"]
  end
  MB --> R1(["Tập CONTACT đã lọc"])
  CR --> R2(["Company khớp → người của company đó"])
  IB --> R3(["Thread / reply đã lọc"])
  MB2 -.->|"cùng tên 'Has signal' · KHÁC cấp"| CR2
  classDef default fill:#fff,stroke:#CCC8D5;

Ba bề mặt độc lập: thanh members lọc trực tiếp trên CONTACT · rail company lọc trên COMPANY rồi trả về người của company khớp · thanh Inbox lọc thread/reply. "Has signal" tồn tại 2 cấp — contact đích thân có signal (members) vs company có signal (rail).

DTO — công thức lọc ở tầng API (chạy thật 16/07 chiều, số khớp tuyệt đối)

5.2 · SDR.0.25 — Xem list được giao ✅ Có ↔ User guide: Flow 1–2

Hình 10 (§4.2): SDR thấy đúng các list của mình kèm member count. Danh sách list "được giao" = query customLists lọc theo assignee = user hiện tại; row hiển thị memberCount + badge role của assignedToIds + cột Category (category:SDR). Gap P2: chưa có cột "work-through progress" (VD "34 of 120 worked") — lean có thể suy từ count các bộ lọc (worked = tổng − New Prospects).

DTO — list được giao (verify introspection)

5.3 · SDR.0.3 — Account / Contact workspace ✅ Có · UAT 5/5 PASS ↔ User guide: Flow 2 (workspace)

DTO — contact workspace (verify introspection)

5.4 · SDR.0.10 — Tự chọn contact đích ✅ Có ↔ User guide: Flow 2 (pick contact)

V1 đúng chủ trương "con người quyết định who": SDR đứng ở workspace (hình 14), xem work experience + lifecycle + hoạt động cũ rồi tự chọn ai để email. Không có AI gợi ý — đúng lean, không phải gap.

5.4b · Team coverage — "held by teammates" (contact thuộc different owner) ✅ verify code + API + UI 20/07 ↔ User guide: Flow 2 (held by teammates)

Tính năng lên UAT sau đợt capture 19/07 (FE plan merge-coverage-into-member-table): trong list detail, chọn 1 company ở rail trái → cuối bảng members xuất hiện block dòng xám view-only + pill "N held by teammates" — những contact ở CÙNG COMPANY đó nhưng không thuộc list đang mở, đang được người khác giữ trong list của họ. Mục đích: chống double-touch ở cấp company/account — SDR list độc quyền (§Δ3 #3) chỉ chặn trùng CONTACT, không chặn 2 rep cùng đánh 1 COMPANY qua 2 contact khác nhau; block này lấp đúng lỗ đó (soft guard: chỉ hiển thị, chưa chặn gửi — G1 vẫn mở).

Điều kiện hiển thị — contact phải thỏa ĐỦ 4 điều kiện

Semantics đã kiểm chứng (API 20/07, token SDR "Dong SDR" + đối chứng admin)

Chưa chốt (cần dev confirm): (1) contact nằm trong list KHÁC của chính mình có bị BE loại không — FE chỉ dedup member của list đang mở; (2) list không assign cho ai có tính là "người khác giữ" không (mọi list ở Battery đều có assignee nên chưa tách được). Nguồn FE: use-coverage-rows.ts · contacts-v2-in-different-owner.gql.ts (commit "merge team-coverage rows into member table").

5.4c · Member-row actions + role gating + lifecycle lock ✅ verify source 20/07

Action trên 1 dòng member (list detail) — bảng chia 2 mode (Lean/Simple vs Full); SDR/KAM hard-lock ở Simple. Gating verify từ source HEAD:

SDR fixed list + per-menu capability (verify live + source 20/07)

⚠️ View-as-role không 100% trung thực cho membership capability: add/remove/export khoá theo useAdminRealRoles() (REAL role) chứ không theo impersonated flag → super-admin "view as SDR" vẫn thấy +Add members/Remove; chỉ SDR/KAM thật mới mất. Visibility gate (route, sidebar, create/actions/assign, Simple lock, ⋮ hide, coverage lock) thì impersonation-aware. Nguồn: gt2-260720-*.md (member-row / contact-detail / sdr-gating).

5.5 · SDR.0.11 — Compose email 1:1 ✅ Có ↔ User guide: Flow 4

5.6 · SDR.0.12 — Send → auto-log → rời việc hôm nay ✅ Có (theo model mới) ↔ User guide: Flow 4 (send/log)

DTO — send & email log (verify UAT 16/07)

Sequence — send → auto-log → lifecycle tự nhảy → rời việc hôm nay

sequenceDiagram
  autonumber
  participant SDR as SDR (Compose)
  participant GQL as GraphQL
  participant DB as Mongo (email_logs · contacts)
  SDR->>GQL: sendEmailLog(input{from, to, subject, content})
  GQL->>DB: insert email_logs (auto-log — không ghi tay)
  DB-->>DB: sync job ghi contact.lastEmailSentDate
(⚠️ trễ cỡ phút — lifecycle enum KHÔNG tự nhảy, verified 16/07)
  GQL-->>SDR: true
  Note over DB: lastEmailSentDate xuất hiện ⇒ hết là "chưa gửi",
Last Contact về mới — đúng nghĩa "rời việc hôm nay"

5.7 · SDR.0.13 — Follow-up ✅ Có — N do mỗi SDR tự đặt ↔ User guide: Flow 6

Logic trường hợp Follow-up (tầng API/admin) — 3 điều kiện

Tinh chỉnh (mới): thêm điều kiện tùy chọn thứ 4 Has new signals since our last email = Yes (§5.1, field aHasSignalSinceReply) → tách nhóm follow-up “nóng” — contact đã im NHƯNG company/vai trò vừa có tin mới (⚡/💼) sau email cuối → ưu tiên gửi lại vì có ngữ cảnh.

Việc còn lại: không còn gì chặn. N do từng SDR tự đặt; UAT sẵn aiGenerateFollowupEmail (AI viết follow-up) có thể gắn vào bước reply — P2, không chặn.

5.8 · SDR.0.15 — Mở reply kèm thread ✅ Có ↔ User guide: Flow 5

Đã verify live 21/07: Conversations 2-pane (thread list | thread, Expand all) chạy thật; đọc "là reply hay không" bằng mũi tên hướng ↙ inbound (khách) / ↗ outbound (mình) — §5.9. Cấu trúc dữ liệu đúng: thread qua preEmailLogId PASS, Inbox v2 đã Done Release Prod. Còn 1 gap hạ tầng (không chặn flow): đường sync reply trên UAT chập chờn (lúc nhận lúc không) nên E2E "khách reply → tự nổi lên Inbox" chưa test ổn định được — theo dõi ở G7 (P1).

Sequence — reply → nổi lên Inbox → đọc thread → classify

sequenceDiagram
  autonumber
  participant M as Mail (inbound)
  participant SYS as Sync (BE)
  participant DB as Mongo
  participant SDR as SDR (Inbox v2)
  participant GQL as GraphQL
  M-->>SYS: reply của khách (⚠️ UAT chập chờn — G7)
  SYS->>DB: email_logs mới (preEmailLogId → thread)
contact.syncDateRepliedEmailLog = now
  Note over DB: contact tự nổi lên Inbox (In Conversation + Received a reply)
  SDR->>GQL: emailLogs(condition{emails: [contact]}) — đọc thread đầy đủ
  SDR->>GQL: as-is — updateLifecycleContactV2(id, {nextLifeCycles: [NotNow]})
  SDR->>GQL: to-be (BE đã có) — setCategorizeEmailLog(logId,
{categorize: NotNow, contactId})
  GQL->>DB: cập nhật lifecycle + side-effects ⇒ contact rời khỏi nhóm chờ ở Inbox

5.9 · SDR.0.16 — Classify reply ✅ Có per-reply auto-chip ✅ · SDR set lifecycle cấp contact tay · ↔ User guide: Flow 5

Reply hay send? — đọc HƯỚNG mũi tên, không đọc sự-hiện-diện của chip

flowchart TD
  MSG(["1 message trong thread"]) --> DIR{"Mũi tên hướng?
(EmailLogType)"}
  DIR -->|"↙ inbound (replied)"| INB["Reply THẬT của khách"]
  DIR -->|"↗ outbound (sentOut)"| OUT["Email MÌNH gửi đi"]
  INB --> CHIP1["Chip categorize THẬT
Interested / OOO / Not Interested…"]
  OUT --> CHIP2["Chip 'Open'
(= chưa classify)"]
  CHIP1 --> READ["SDR đọc reply"]
  READ --> LC["SDR set lifecycle contact — tay
updateLifecycleContactV2
(chỉ khi lifecycle hiện tại rỗng HOẶC ∉
PlatformSignUp·InProject·ProjectCompleted — §5.4c)"]
  W["⚠️ CẢ 2 chiều đều có chip ⇒ đừng dùng sự-hiện-diện của chip.
Tell tin cậy = HƯỚNG mũi tên"] -.-> DIR
  classDef default fill:#fff,stroke:#CCC8D5;

DTO — classify (verify UAT 16/07)

Cơ chế classify thực tế — reply auto-classify (BE) · SDR set lifecycle contact (có khoá)

1. Reply về → BE producer tự đọc nội dung → gán chip categorize (1/11 nhãn EmailLogCategorizeEnum) cho chính message đó, hiển thị read-only trên message + item thread list. SDR KHÔNG bấm classify reply.
2. SDR đọc reply — chip là gợi ý + lịch sử quét nhanh cả thread; không sửa được (click chỉ mở/đóng message).
3. SDR set lifecycle ở cấp CONTACT (updateLifecycleContactV2) — quyết định chính thức, TÁCH khỏi chip reply (chip KHÔNG tự đổi lifecycle contact — verified 16/07). Chỉ set được khi lifecycle hiện tại RỖNG hoặc KHÔNG thuộc {PlatformSignUp, InProject, ProjectCompleted} — ở 3 stage này chip read-only (“cấm rời”, §5.4c).
4. Lọc “chưa classify”: field categorizes của EmailLogConditionInput có sẵn → thêm tab/filter trong Inbox (P1, FE-only).
5. Lifecycle Interested → điểm nối handoff KAM (SDR.0.17): hiện toast "Tạo deal & chuyển KAM?" khi G2 ship.

flowchart LR
  A(["Reply của khách
trong thread"]) --> B["BE tự đọc nội dung reply
→ gán chip categorize (auto · read-only)"]
  B --> R["SDR đọc reply (chip = gợi ý)"]
  R --> LK{"Lifecycle contact hiện tại ∈
PlatformSignUp·InProject·ProjectCompleted?"}
  LK -->|"Có → chip khoá (§5.4c)"| X["KHÔNG đổi được bằng tay"]
  LK -->|"Không / rỗng"| C["SDR set lifecycle CONTACT
updateLifecycleContactV2"]
  C --> E{"Lifecycle?"}
  E -->|"✅ Interested"| F["(to-be G2) tạo deal → handoff KAM"]
  E -->|"🥶 NotNow / OOO…"| G["Ẩn khỏi view làm việc,
re-entry rule"]
  E -->|"🆘 OptedOut / DNC…"| H["Suppression — mọi send path né"]
  W["⚠️ SDR KHÔNG classify reply — chip do hệ thống gán"] -.-> B
  classDef default fill:#fff,stroke:#CCC8D5;

Chip reply = hệ thống gán tự động (BE producer), read-only với SDR/KAM. SDR chỉ đọc rồi set lifecycle cấp contact (1 call updateLifecycleContactV2) — trừ khi contact đang ở 3 stage khoá (§5.4c). Filter "chưa classify" dùng field categorizes có sẵn.

5.10 · SDR.0.17 — Interested → deal → handoff KAM ❌ Chưa có ↔ User guide: chưa có Flow (hand-off chưa tài liệu hoá — deferred)

5.11 · SDR.0.18 — Xử lý OptedOut / Do Not Contact ✅ Có (tay) · gap chặn cứng ↔ User guide: Flow 3 (lifecycle)

6 · Phase 3 — KAM Calls + AI Outcome ❌ Toàn bộ chưa build

6 flow của KAM chưa có UI/BE — phần này là to-be thuần, chia 2 mức theo độ sẵn sàng viết spec:

Activity — KAM call flow (đề xuất — toàn bộ chưa build)

flowchart TD
  A(["Contact Interested
(handoff từ SDR — G2)"]) --> B["KAM book call qua Zoom API (KAM.0.1)"]
  B --> C["Call vào calls list — filter
lifecycle CallScheduled (KAM.0.2)"]
  C --> D["Prep: mở workspace của account"]
  D --> E{"⚠️ #10 Consent ghi âm
(Đức §201 StGB + GDPR)?"}
  E -->|"OK"| F["Call + recording (KAM.0.5)"]
  F --> G["Transcript (⚠️ #12 Zoom native vs ASR)
→ account memory (KAM.0.6)"]
  G --> H["AI outcome {outcome, why, confidence}
(⚠️ #11 chốt enum) (KAM.0.7)"]
  H --> I{"Confidence thấp?"}
  I -->|"Có"| J["needs_review → KAM confirm / sửa (KAM.1.8)
→ lưu làm eval data"]
  I -->|"Không"| K["Move deal theo outcome"]
  J --> K
  classDef default fill:#fff,stroke:#CCC8D5;

7 · SYS behaviors (chạy ngầm)

8 · GAP register hợp nhất

Tin tốt: 3 blocker khác trong spec đã giải xong bằng verify thực tế — #6 inbound reply (UAT đã sync được reply của khách) · #14 lifecycle enum (schema có đủ nhãn) · #3 schema tokens (đã xác định assignedToIds).

9 · Kế hoạch đề xuất (phased)

1. Saved/pinned filters (G4) — pin quick-filter cho từng trường hợp (signal mới · prospect) cho SDR; follow-up "im lâu" vẫn qua cột Last Contact (SDR không filter ngày). Xong bước này: SDR loop end-to-end trọn vẹn. Effort: nhỏ.
2. Chặn cứng suppression (G1) — điều kiện an toàn để gửi thật ở quy mô. Effort: BE nhỏ, P0.
3. Per-reply classify + Email Logs cho SDR (G5, G6) — hoàn thiện nhánh xử lý reply. G5 đang chạy sẵn trong sprint.
4. Deal + handoff KAM (G2) — conversion event; mở khoá phase 3. Kèm KAM.0.2 (calls view = filter) và KAM.1.8 spec.
5. Zoom stack (G21) — sau khi chốt #10/#11/#12. Tận dụng hạ tầng recording/transcript sẵn có của Interview/Meeting.
6. Polish (G8–G12) — approval gate, role Ops, priority flag, progress, subject prefill.

10 · Phụ lục — nguồn

Tài liệu song hành cho người dùng cuối (Admin/Ops/SDR): v4.html + bản riêng reps v4.html — hướng dẫn thao tác theo luồng công việc. Cập nhật tài liệu: sửa trực tiếp LEAN-LAUNCH/index-v3.html (v1/v2 giữ làm mốc). Mermaid render local qua mermaid.min.js (không cần mạng). In PDF: Ctrl/Cmd+P.