tài liệu điều tra và estimate

01-nghien-cuu-cong-nghe.md

@@ -0,0 +1,423 @@
+# Nghiên cứu công nghệ Amazon Connect cho D2C Call Center
+
+Ngày kiểm tra tài liệu: 03/09/2026 — **bản sửa lần 2 sau review độc lập** (xem `04-review-doc-lap.md`)
+Đối tượng đọc: PM, solution architect, developer và người cần làm proposal cho khách Nhật.
+
+> **Đính chính quan trọng so với bản 1.** Bản 1 kết luận số 0120/0800 có thể dùng làm caller ID cho outbound campaign. Kiểm chứng lại trực tiếp trong Amazon Connect Telecoms Coverage Guide bản 31/08/2026 cho thấy **toll-free Nhật không nằm trong outbound campaign regions**, và **custom caller ID không khả dụng tại Nhật**. Mục §4 đã được viết lại hoàn toàn.
+
+> Ghi chú tên sản phẩm: tài liệu AWS hiện dùng tên **Amazon Connect Customer**. Trong tài liệu này, “Amazon Connect” và “Connect Customer” cùng chỉ nền tảng contact center của AWS.
+
+## 1. Bài toán cần giải quyết
+
+Khách hàng muốn mở call center D2C khoảng 10–15 chỗ ngồi, chủ yếu gọi sales outbound theo danh sách, có thể bổ sung inbound. Tất cả agent cần gọi đồng thời bằng cùng một số toll-free — **yêu cầu này không thực hiện được nguyên văn, xem §4**; mọi cuộc nói chuyện phải được ghi âm, chuyển thành text, lưu trên AWS và dùng để phân tích sentiment/giọng nói.
+
+Đây không chỉ là bài toán “đặt cuộc gọi”. Một hệ thống vận hành được cần quản lý đồng thời:
+
+- dữ liệu khách và quyền được liên hệ;
+- chiến dịch, lịch gọi, số lần thử lại và suppression/do-not-call;
+- trạng thái agent, phân phối cuộc gọi và after-call work;
+- kết quả nghiệp vụ của cuộc gọi;
+- ghi âm, transcript, phân tích, tìm kiếm và báo cáo;
+- quyền truy cập dữ liệu nhạy cảm, retention, audit và giám sát hệ thống.
+
+## 2. Các thành phần AWS phù hợp
+
+| Thành phần | Vai trò trong giải pháp |
+|---|---|
+| Amazon Connect Customer | Contact center, softphone trên trình duyệt, user/queue/routing, contact flow, inbound và outbound |
+| Customer Profiles + Segments | Nạp CSV danh sách khách, chuẩn hóa profile và tạo segment dùng cho campaign |
+| Outbound Campaigns | Preview/progressive/predictive dialing, AMD, retry, lịch và giới hạn tần suất liên hệ |
+| Agent Workspace | Màn hình agent gồm call controls, customer profile, task/case/guide và app tích hợp |
+| Conversational Analytics (Contact Lens) | Transcript, sentiment, loudness, silence, interruption, category, summary và tìm kiếm cuộc gọi |
+| Amazon S3 + AWS KMS | Lưu recording và file phân tích, mã hóa và lifecycle |
+| EventBridge/Lambda/DynamoDB | Lưu disposition nghiệp vụ, callback, DNC và xử lý sự kiện theo contact ID |
+| Connect data lake/Lake Formation/Athena/QuickSight | Báo cáo nâng cao, phân tích liên chiến dịch và dữ liệu dài hạn |
+| CloudWatch/CloudTrail | Metrics, alarm, log flow và audit API |
+
+### 2.1 Snapshot các thay đổi công nghệ đáng chú ý đến 03/09/2026
+
+- Outbound Campaigns hiện có Guided Campaign Builder, CSV-based segment, preview/progressive/predictive, communication limits, retry và campaign scheduling ngay trong Connect; nhu cầu tự xây dialer cho MVP đã giảm đáng kể — **với điều kiện source number là DID**. Tại Nhật, toll-free không dùng được cho campaign, xem §4.
+- Conversational Analytics hỗ trợ tiếng Nhật cho cả post-call và real-time, summary, information extraction, sentiment và automated evaluation. Real-time dashboard alert cho keyword/sentiment giúp supervisor can thiệp sớm.
+- Persistent agent connection có thể giữ kênh giữa agent và Connect sau khi kết thúc cuộc gọi, giảm thời gian nối agent cho các cuộc outbound tiếp theo. Kết hợp auto-accept và ACW ngắn để giảm khoảng im lặng sau khi khách bắt máy.
+- Connect analytics data lake cung cấp contact/campaign tables để query, nhưng cửa sổ truy cập native là rolling 25 tháng; dữ liệu cần giữ lâu hơn phải export.
+- Global Resiliency hiện hỗ trợ cặp Tokyo–Osaka, nhưng cần gói AWS Enterprise Support hoặc Unified Operations và quy trình onboarding riêng.
+- Amazon Connect Customer Voice ID đã kết thúc hỗ trợ ngày 20/05/2026. Không dùng Voice ID làm nền tảng cho “phân tích tone/emotion” hay xác thực giọng nói trong thiết kế mới.
+- Pricing hiện có gói Connect Customer tích hợp AI theo phút và Customer Basic cho một số khách hàng cũ; phải xác nhận pricing plan của account trước khi dự toán OPEX.
+
+Nguồn: [Amazon Connect release notes](https://docs.aws.amazon.com/connect/latest/adminguide/amazon-connect-release-notes.html), [Global Resiliency requirements](https://docs.aws.amazon.com/connect/latest/adminguide/connect-global-resiliency-requirements.html), [Service quotas and Voice ID end-of-support notice](https://docs.aws.amazon.com/connect/latest/adminguide/amazon-connect-service-limits.html).
+
+## 3. Outbound theo danh sách
+
+### 3.1 Nạp danh sách
+
+Connect Customer cho phép tạo segment từ file CSV. Theo tài liệu hiện tại, file phải:
+
+- là CSV, UTF-8 **không có BOM**;
+- có header;
+- nhỏ hơn 1 GB;
+- map các cột vào standard hoặc custom attributes của Customer Profiles.
+
+Khi import, profile được tạo/cập nhật rồi gom vào segment. Segment đó có thể được chọn trực tiếp trong Guided Campaign Builder. Đây là con đường ít code nhất để có chức năng tương tự phần “list import + campaign dial” của BlueBean.
+
+Nên quy định template tối thiểu:
+
+```text
+external_customer_id,phone_number,full_name,timezone,consent_source,consent_at,do_not_call,campaign_group
+```
+
+Số điện thoại phải được chuẩn hóa E.164, ví dụ số Nhật bỏ số `0` đầu và thêm `+81`.
+
+Nguồn: [Create segments from imported files](https://docs.aws.amazon.com/connect/latest/adminguide/customer-segments-imported-files.html).
+
+### 3.2 Chế độ quay số
+
+| Chế độ | Cách hoạt động | Khi nên dùng |
+|---|---|---|
+| Preview | Agent xem thông tin trước rồi chấp nhận/gọi | Lead giá trị cao, cần đọc lịch sử trước khi gọi |
+| Progressive | Chỉ gọi lead tiếp theo sau khi agent hoàn thành cuộc trước | MVP sales; cân bằng năng suất và rủi ro silent/abandoned call |
+| Predictive | Thuật toán gọi trước dựa trên xác suất bắt máy và agent sắp rảnh | Volume lớn; cần kiểm soát abandonment và tuân thủ pháp lý |
+| Agentless | Flow/voice bot xử lý, không nối agent | Reminder/thông báo tự động, không phải sales có người tư vấn |
+
+Khuyến nghị MVP dùng **progressive** làm mặc định và preview cho nhóm lead cần xem trước. Predictive nên để phase sau vì cần đủ volume để mô hình pacing có ý nghĩa, quota lớn hơn và kiểm soát abandoned call chặt hơn.
+
+Ở agent setting nên bật auto-accept và persistent connection, đồng thời đặt ACW vừa đủ để nhập disposition. AWS gợi ý ACW 30 giây để tối ưu predictive dialer, nhưng dự án phải đo thời gian nhập kết quả thực tế thay vì áp dụng máy móc.
+
+**Ràng buộc phải biết trước khi thiết kế:**
+
+- Source number của campaign **phải là DID**. Tại Nhật, toll-free 0120/0800 không nằm trong outbound campaign regions (§4).
+- Block `Check call progress` (AMD) **chỉ hoạt động cho hai loại cuộc gọi**: cuộc gọi của outbound campaign, và customer-first callback. Mọi loại khác — kể cả cuộc gọi tạo bằng `StartOutboundVoiceContact` — đều rơi vào nhánh `Error`. Nghĩa là nếu tự xây dialer thì mất AMD native.
+
+Outbound Campaigns hỗ trợ:
+
+- source phone number thuộc Connect instance (DID);
+- call progress/answering machine detection (AMD);
+- retry theo disposition kỹ thuật như busy, unanswered, voicemail;
+- active communication time, exception date, schedule và expiry;
+- giới hạn số lần liên hệ theo campaign/toàn instance;
+- campaign metrics và event data.
+
+Lưu ý: disposition của dialer như `HUMAN_ANSWERED`, `SIT_TONE_BUSY`, `AMD_UNANSWERED` không thay cho kết quả nghiệp vụ như “đã bán”, “gọi lại”, “không quan tâm”, “không gọi nữa”. Cần form after-call work để lưu kết quả nghiệp vụ.
+
+Nguồn: [Guided Campaign Builder](https://docs.aws.amazon.com/connect/latest/adminguide/guided-campaign-builder.html), [Outbound campaign best practices](https://docs.aws.amazon.com/connect/latest/adminguide/outbound-campaign-best-practices.html), [BlueBean feature page](https://www.bluebean365.jp/).
+
+## 4. Số điện thoại: cùng một số cho mọi agent
+
+### 4.1 Điều Amazon Connect thực sự hỗ trợ tại Nhật
+
+Trích **Amazon Connect Telecoms Coverage Guide**, bản in ngày 31/08/2026, khối Japan (ảnh chụp: `evidence/japan-telecoms-coverage-2026-08-31.png`):
+
+| Loại số | Number availability | National Outbound | International Outbound | Porting | Custom Caller ID | Region Availability | **Outbound Campaign Regions** |
+|---|:--:|:--:|:--:|:--:|:--:|---|:--:|
+| DID `+81 3` / `+81 6` | ✔ (footnote 2) | ✔ | ✔ | ✔ (hạn chế) | **✘** | ap-northeast-1 | **ap-northeast-1** |
+| DID `+81 50` | ✔ | ✔ | ✔ | ✘ | **✘** | All commercial regions | **ap-northeast-1** |
+| Toll-free `+81 120` / `+81 800` | ✔ | ✔ | ✘ | ✔ | **✘** | All commercial regions | **–** |
+| UIFN | ✔ | ✘ | ✘ | ✔ | **✘** | All commercial regions | **–** |
+
+Footnote (2) của bảng: *"Local Numbers and Porting in Japan is only possible on specific numbers"*.
+
+Cách đọc bảng đã được đối chiếu chéo với các nước khác để loại trừ khả năng nhầm ô gộp: Hàn Quốc (DID → `ap-northeast-2`, Toll-free → `–`), Úc (DID → `ap-southeast-2`, Toll-free/UIFN → `–`), Ý và Áo (Toll-free có National Outbound ✔ nhưng campaign `–`). Mỹ là ngoại lệ duy nhất có cả DID lẫn Toll-free campaign-capable. **Nhật theo mẫu chung.**
+
+### 4.2 Ba kết luận bắt buộc
+
+**(1) Toll-free Nhật không dùng được cho Outbound Campaigns.**
+
+`National Outbound = ✔` với toll-free chỉ có nghĩa là **gọi ra thủ công** với caller ID 0120 được hỗ trợ và CLI được đảm bảo hiển thị. Nhưng cột `Outbound Campaign Regions` để trống. Toàn bộ phần "giống BlueBean" — Guided Campaign Builder, preview/progressive/predictive, AMD, retry theo disposition, communication limits, campaign schedule — đi kèm campaign, và do đó đi kèm DID.
+
+Hệ quả: hai yêu cầu gốc của khách, 「リストをもとに発信できるシステム」 và 「同じフリーダイヤルで全員が発信できる」, **không thể đồng thời thỏa mãn bằng tính năng native**. Đây là quyết định phải đưa cho khách chốt.
+
+**(2) Không có custom caller ID tại Nhật.**
+
+Cột Custom Caller ID = ✘ cho cả 4 loại số. Không tồn tại đường "giữ số ở carrier hiện tại, chứng minh quyền sở hữu rồi hiển thị khi gọi ra". Số nào muốn dùng thì phải claim mới hoặc **port hẳn vào Amazon Connect** — kéo theo việc nghiệp vụ đang chạy trên số đó bị ảnh hưởng.
+
+**(3) Lịch xin và chuyển số là ràng buộc cứng.**
+
+| Yếu tố | Quy định | Ảnh hưởng |
+|---|---|---|
+| Cửa sổ port số Nhật (toll-free và 03/06) | **Thường là ngày 1 và ngày 15 của tháng kế tiếp** | Trượt một nhịp là chậm nửa tháng |
+| Hồ sơ claim số Nhật | Giấy đăng ký doanh nghiệp cấp trong 6 tháng; ID/hộ chiếu người đại diện có tên trong đăng ký; giấy tờ chứng minh địa chỉ cấp trong 6 tháng. Gộp thành một file ZIP | Phải yêu cầu khách chuẩn bị ngay tuần 1 |
+| Địa chỉ cho số `+81 3` / `+81 6` | Phải thuộc **đúng thành phố của area code** | Văn phòng chưa đăng ký ở Tokyo thì không claim được số 03 |
+| Hồ sơ cho toll-free | Nhẹ hơn: đăng ký doanh nghiệp + ID người đại diện; địa chỉ toàn cầu chấp nhận được | |
+| Port | Cần hóa đơn gần nhất + Letter of Authorization theo mẫu AWS + bộ hồ sơ trên | Phải mở Support ticket để AWS kiểm tra số có port được không |
+
+### 4.3 Ba phương án thiết kế
+
+| | **Phương án A (khuyến nghị)** | Phương án B | Phương án B' (cần PoC) |
+|---|---|---|---|
+| Số phát ra | DID `+81 3` (hoặc `+81 50`) | Toll-free 0120 | Toll-free 0120 |
+| Số nhận vào | 0120 | 0120 | 0120 |
+| Cơ chế quay số | Outbound Campaigns native | Tự xây trên `StartOutboundVoiceContact` | Customer-first callback + `Check call progress` |
+| AMD | Có | **Không** | Có, **nếu** PoC xác nhận |
+| Retry / schedule / frequency cap | Native | Tự xây | Tự xây |
+| Chênh effort so với A | – | +18–30 PD | +12–20 PD + 5–8 PD PoC |
+| Rủi ro | Thấp | Cao | Cao, chưa có tài liệu AWS khẳng định |
+
+Khi chọn DID cho phương án A, cần cân nhắc:
+
+- `+81 3` / `+81 6` (số địa lý): tỷ lệ bắt máy tốt nhất, nhưng vướng điều kiện địa chỉ và footnote (2) về tồn kho số.
+- `+81 50` (IP phone): claim dễ, mọi region, nhưng người tiêu dùng Nhật có xu hướng không bắt máy số 050 và các app chặn cuộc gọi gắn cờ mạnh với dải này — ảnh hưởng trực tiếp KPI của một call center bán hàng.
+
+### 4.4 Các điều kiện kỹ thuật khác vẫn đúng
+
+- Connect cho phép đặt outbound caller ID ở queue; mọi agent dùng chung một outbound queue/routing profile thì phát cùng một số.
+- Số phải ở dạng E.164.
+- Carrier và thiết bị đích quyết định cách hiển thị cuối cùng; không cam kết hiển thị tên doanh nghiệp.
+- Toll-free là sản phẩm nội địa: `International Outbound = ✘`. Không gọi ra quốc tế được từ 0120.
+- Khả năng phát caller ID và khả năng dùng số cho Outbound Campaigns là **hai kiểm tra khác nhau** — đây chính là chỗ bản 1 bị nhầm.
+
+Nguồn: [Telecoms Coverage Guide (PDF, 31/08/2026)](https://d1v2gagwb6hfe1.cloudfront.net/Amazon_Connect_Telecoms_Coverage.pdf), [Set up outbound caller ID](https://docs.aws.amazon.com/connect/latest/adminguide/queues-callerid.html), [Region requirements for ordering and porting phone numbers](https://docs.aws.amazon.com/connect/latest/adminguide/phone-number-requirements.html), [Outbound calling restrictions](https://docs.aws.amazon.com/connect/latest/adminguide/outbound-calling-restrictions.html), [Check call progress block](https://docs.aws.amazon.com/connect/latest/adminguide/check-call-progress.html).
+
+## 5. 15 cuộc gọi đồng thời và quota
+
+Khả năng scale của dịch vụ không phải vấn đề, nhưng quota mặc định là blocker:
+
+- `Concurrent active calls per instance`: mặc định **10**, có thể yêu cầu tăng;
+- `Concurrent campaign active calls per instance`: mặc định **0**, có thể yêu cầu tăng.
+
+Active call bao gồm cuộc đang ở flow, đang chờ queue, đang nói với agent và outbound call. Vì vậy không được đặt quota đúng bằng 15 ghế.
+
+Khuyến nghị ban đầu:
+
+- MVP progressive/preview: xin ít nhất 25 concurrent active calls và 25 concurrent campaign active calls;
+- nếu bật inbound đồng thời: tính peak inbound và tăng thêm headroom;
+- khi dùng predictive: sizing lại theo dial rate, answer rate và abandonment target; thường cần campaign call quota lớn hơn số agent đáng kể, không chốt cứng trước load test.
+
+### 5.1 Các quota khác cần biết trước
+
+| Quota | Mặc định | Ảnh hưởng tới dự án này |
+|---|---:|---|
+| Concurrent active calls per instance | 10 | Blocker, phải xin lên 25 |
+| Concurrent campaign active calls per instance | 0 | Blocker, phải xin lên 25 |
+| Connect instances per Region | 2 | Vừa đủ non-prod + prod, không còn chỗ cho sandbox |
+| Phone numbers per instance | 5 | Đủ cho MVP nhưng cần biết khi test nhiều số |
+| Concurrent post-call analytics jobs | 200 | Dư sức cho 15 ghế |
+| Concurrent real-time calls with analytics | 300 | Dư sức cho 15 ghế |
+
+### 5.2 Thời gian phê duyệt
+
+AWS yêu cầu **tạo instance trước** khi gửi yêu cầu tăng quota. Về thời gian, tài liệu AWS nói rõ: yêu cầu nhỏ có thể duyệt trong vài giờ, nhưng **yêu cầu lớn có thể mất tới 3 tuần**, và yêu cầu rất lớn ở quy mô toàn cầu có thể mất hàng tháng. Thời gian AWS/telco phê duyệt không nằm trong person-day phát triển, nhưng **phải nằm trong lịch dự án** — đây là điểm bản 1 chưa thể hiện đủ.
+
+Ngoài ra, để sizing công suất phân tích, AWS đưa công thức: `(phút/cuộc) × 0.4 × (cuộc/giờ) / 60` = số post-call analytics job đồng thời, với giả định thời gian phân tích bằng khoảng 40% độ dài cuộc gọi. Con số này cũng là căn cứ để đặt SLA kiểm tra artifact sau cuộc gọi.
+
+Nguồn: [Amazon Connect service quotas](https://docs.aws.amazon.com/connect/latest/adminguide/amazon-connect-service-limits.html), [Plan ahead with quotas](https://docs.aws.amazon.com/connect/latest/adminguide/plan-ahead-quotas.html), [Availability by Region](https://docs.aws.amazon.com/connect/latest/adminguide/regions.html).
+
+## 6. Ghi âm và lưu S3
+
+Call recording được bật ở instance nhưng còn phải bật trong contact flow bằng block **Set recording and analytics behavior**. Khi cuộc gọi kết thúc, recording được đưa vào S3 đã cấu hình và có thể mở từ contact detail.
+
+Thiết kế khuyến nghị:
+
+- ghi cả agent và customer từ thời điểm cuộc gọi được kết nối;
+- S3 Block Public Access;
+- SSE-KMS bằng customer-managed key cho production;
+- security profile tách quyền xem contact, nghe recording và tải unredacted recording;
+- S3 Lifecycle: Standard → Standard-IA/Glacier → expire theo chính sách;
+- bật CloudTrail data events cho bucket recording nếu yêu cầu audit ai đọc/tải file;
+- alarm khi recording/analytics job lỗi và có quy trình reprocess.
+
+Diễn giải đúng câu “ghi âm mọi cuộc gọi”: chỉ cuộc gọi đã kết nối và có media mới sinh recording. Busy, invalid number hoặc không bắt máy không có hội thoại để ghi; chúng vẫn có contact/campaign event và disposition kỹ thuật.
+
+Connect không hỗ trợ S3 Object Lock ở compliance mode trực tiếp trên bucket recording mặc định. Nếu cần WORM, phải thiết kế bản sao sang bucket archive phù hợp và kiểm tra lại luồng được AWS hỗ trợ.
+
+Nguồn: [Create a Connect instance and data storage](https://docs.aws.amazon.com/connect/latest/adminguide/amazon-connect-instances.html), [Review recorded conversations](https://docs.aws.amazon.com/connect/latest/adminguide/review-recorded-conversations.html), [Encryption at rest](https://docs.aws.amazon.com/connect/latest/adminguide/encryption-at-rest.html).
+
+## 7. Transcript và phân tích hội thoại tiếng Nhật
+
+Với locale `ja_JP`, bảng ngôn ngữ hiện tại đánh dấu hỗ trợ:
+
+- post-call analytics;
+- real-time call analytics;
+- post-contact summaries;
+- information extraction;
+- sentiment analysis;
+- pattern match rules;
+- automated performance evaluations.
+
+Transcript và file phân tích gắn theo contact ID; supervisor có thể tìm, đọc theo từng lượt thoại và nhảy từ text tới đúng timestamp của audio. Analytics còn có:
+
+- sentiment agent/customer và sentiment shift;
+- loudness theo đoạn;
+- talk time, non-talk time;
+- interruption;
+- category theo keyword/pattern/semantic rule;
+- issue, outcome và action item;
+- post-contact summary.
+
+Có thể thêm custom vocabulary để cải thiện product name, brand name, acronym và thuật ngữ chuyên ngành. Mỗi ngôn ngữ chỉ có một vocabulary ở trạng thái default được áp dụng cho analysis tại một thời điểm; vocabulary mới không sửa ngược các transcript cũ. Không đưa PII/confidential data vào vocabulary.
+
+Điểm giới hạn quan trọng: cột **Redaction** cho `ja_JP` hiện để trống. Không được giả định Connect có thể tự che mọi PII tiếng Nhật trong transcript/audio. MVP nên hạn chế đọc thông tin thanh toán nhạy cảm qua điện thoại, dùng quyền truy cập và retention chặt; custom Japanese PII redaction là một workstream riêng nếu bắt buộc.
+
+Nguồn: [Supported languages](https://docs.aws.amazon.com/connect/latest/adminguide/supported-languages.html), [Set recording and analytics behavior](https://docs.aws.amazon.com/connect/latest/adminguide/set-recording-behavior.html), [Example analytics output](https://docs.aws.amazon.com/connect/latest/adminguide/contact-lens-example-output-files.html), [Custom vocabularies for conversational analytics](https://docs.aws.amazon.com/connect/latest/adminguide/add-custom-vocabulary.html).
+
+## 8. “Tone” và “emotion” thực sự đo được gì?
+
+### 8.1 Native và đủ dùng cho MVP
+
+Connect cung cấp:
+
+- **sentiment** positive/neutral/negative theo lượt thoại và toàn cuộc gọi;
+- **loudness** để tìm đoạn nói lớn;
+- interruption, silence/non-talk, talk ratio và talk speed;
+- rule kết hợp, ví dụ sentiment âm + loudness cao + nhiều lần ngắt lời để gắn cờ cuộc gọi cần QA.
+
+AWS định nghĩa sentiment là phân tích nội dung text và tính score theo tần suất/streak của các lượt thoại. AWS cũng khuyến nghị xem loudness cùng sentiment. Vì vậy cụm “voice tone/emotion analysis” nên được nghiệm thu bằng các signal trên, không bằng lời hứa đọc chính xác cảm xúc nội tâm.
+
+Nguồn: [How sentiment scores are determined](https://docs.aws.amazon.com/connect/latest/adminguide/sentiment-scores.html), [Investigate loudness](https://docs.aws.amazon.com/connect/latest/adminguide/contact-lens-loudness.html), [Conversational analytics rules](https://docs.aws.amazon.com/connect/latest/adminguide/build-rules-for-contact-lens.html).
+
+### 8.2 Khi nào cần mô hình custom?
+
+Chỉ làm custom acoustic emotion model nếu khách yêu cầu nhãn cụ thể như angry/excited/sad theo **tín hiệu âm thanh**, có KPI precision/recall và dùng kết quả để ra quyết định. Cần:
+
+1. thống nhất taxonomy cảm xúc và mục đích sử dụng;
+2. thu thập/label audio tiếng Nhật có sự đồng ý và đại diện đủ vùng giọng;
+3. tách kênh agent/customer, trích acoustic features hoặc dùng audio model;
+4. huấn luyện/evaluate trên hold-out set;
+5. human review, drift/bias monitoring và cơ chế không tự động phạt agent;
+6. pipeline batch sau cuộc gọi; real-time chỉ làm khi có business case rõ.
+
+Đây là R&D/ML, không phải cấu hình Connect. PoC không đồng nghĩa production-ready.
+
+## 9. Báo cáo và data lake
+
+Native dashboard đủ cho MVP: trạng thái agent, concurrent calls, contact search, recording/transcript, sentiment, campaign progress, dials/minute, connected/attempted và wait time sau khi khách bắt máy.
+
+Khi cần dashboard nghiệp vụ, dùng:
+
+```text
+Connect data lake / contact & campaign events
+                 + business outcome từ DynamoDB
+                 ↓
+          Lake Formation / Athena
+                 ↓
+             QuickSight
+```
+
+Connect analytics data lake cho truy cập rolling **25 tháng**. Nếu phải giữ lâu hơn, schedule export sang S3 thuộc quyền quản lý của doanh nghiệp rồi áp lifecycle.
+
+Nguồn: [Outbound campaign data in the data lake](https://docs.aws.amazon.com/connect/latest/adminguide/data-lake-outbound-campaigns-data.html), [Data lake retention](https://docs.aws.amazon.com/connect/latest/adminguide/data-lake-data-retention.html), [Reference queries](https://docs.aws.amazon.com/connect/latest/adminguide/data-lake-reference-queries.html).
+
+## 10. Agent workstation và mạng
+
+Agent dùng softphone WebRTC trên browser. AWS hỗ trợ ba phiên bản mới nhất của Chrome, Edge Chromium và Firefox/Firefox ESR; Safari không được hỗ trợ cho Agent Workspace/CCP.
+
+Tối thiểu theo AWS cho CCP-only:
+
+- 54 Kbps up/down cho một audio call, chưa tính CRM và ứng dụng khác;
+- CPU 2 GHz, RAM 2 GB cho riêng CCP;
+- USB headset được khuyến nghị;
+- ưu tiên Ethernet có dây;
+- latency endpoint test trung bình không vượt 300 ms;
+- firewall/proxy phải cho phép các endpoint/port Connect yêu cầu, gồm TCP 443 và UDP 3478 theo hướng dẫn hiện hành.
+
+Thực tế nên cấp máy 8 GB RAM trở lên, browser được quản lý, USB headset có noise cancellation, dual Internet hoặc phương án 4G/5G failover cho site. Con số này là khuyến nghị vận hành, không phải minimum chính thức của AWS.
+
+Nguồn: [Agent headset and workstation requirements](https://docs.aws.amazon.com/connect/latest/adminguide/ccp-agent-hardware.html), [Supported browsers](https://docs.aws.amazon.com/connect/latest/adminguide/connect-supported-browsers.html), [Network troubleshooting](https://docs.aws.amazon.com/connect/latest/adminguide/network-ts.html).
+
+## 11. Bảo mật, riêng tư và quy định tại Nhật
+
+Đây không phải tư vấn pháp lý. Doanh nghiệp cần legal/compliance Nhật phê duyệt script, danh sách và retention.
+
+Các control hệ thống tối thiểu:
+
+- lưu consent source/time và lawful basis của từng lead;
+- DNC/suppression toàn hệ thống, không chỉ giới hạn số lần gọi của một campaign;
+- phát hiện duplicate và loại số invalid trước campaign;
+- giới hạn khung giờ liên hệ và ngày nghỉ;
+- script mở đầu nêu tên doanh nghiệp, người gọi, loại hàng/dịch vụ và mục đích chào bán;
+- nếu khách từ chối, ghi DNC ngay và loại khỏi mọi lần tái liên hệ;
+- công bố mục đích sử dụng recording/transcript; khuyến nghị phát thông báo ghi âm dù FAQ của PPC nói luật không luôn bắt buộc thông báo riêng việc đang ghi;
+- role-based access, audit, retention và deletion workflow.
+
+Cơ quan Bảo vệ Thông tin Cá nhân Nhật cho biết nội dung cuộc gọi có thể là personal information nếu nhận dạng được cá nhân; khi đó doanh nghiệp phải thông báo hoặc công bố mục đích sử dụng. Consumer Affairs Agency nêu nghĩa vụ thông báo trước khi chào bán và cấm tiếp tục/tái chào bán với người đã thể hiện không muốn ký hợp đồng.
+
+### 11.1 Nếu chốt hợp đồng ngay trên điện thoại (電話勧誘販売)
+
+Đây là kịch bản rất dễ xảy ra với D2C bán qua điện thoại, và **bản 1 chưa đề cập**. Ngoài 氏名等の明示 và 再勧誘の禁止 đã nêu ở trên, còn phát sinh:
+
+- **書面交付義務**: phải giao văn bản hợp đồng cho khách theo quy định;
+- **クーリング・オフ 8 ngày**: khách có quyền hủy trong 8 ngày kể từ khi nhận văn bản.
+
+Hệ quả lên hệ thống, cần chốt với legal của khách:
+
+- lưu mốc thời gian gửi và nhận văn bản của từng đơn;
+- có trạng thái "đang trong thời hạn cooling-off" và cơ chế hủy đơn;
+- không tiếp tục chào bán trong giai đoạn đó;
+- gắn được bằng chứng này với `contactId` của cuộc gọi đã chốt đơn.
+
+Nếu khách xác nhận có bán chốt ngay trên điện thoại, đây là một workstream riêng chưa nằm trong estimate hiện tại.
+
+### 11.2 Hồ sơ khách Nhật thường yêu cầu
+
+- **セキュリティチェックシート** theo mẫu của khách;
+- tài liệu **委託先管理** cho việc ủy thác xử lý dữ liệu cá nhân;
+- quy trình xử lý yêu cầu **開示・訂正・利用停止・削除** của cá nhân — đặc biệt quan trọng vì hệ thống lưu cả giọng nói lẫn nội dung hội thoại.
+
+Nguồn chính thức: [PPC FAQ về nội dung và ghi âm cuộc gọi](https://www.ppc.go.jp/all_faq_index/faq1-q1-10/), [CAA Telemarketing Sales guide](https://www.no-trouble.caa.go.jp/what/telemarketing/), [CAA English guide](https://www.no-trouble.caa.go.jp/foreignlanguage/english/telemarketing/).
+
+## 12. Chi phí AWS: cách hiểu và công thức
+
+Trang giá ngày 03/09/2026 cho thấy mô hình Connect Customer mới và Customer Basic cũ có thể cùng tồn tại. Phải xác nhận account/contract của khách trước khi lập bill of materials.
+
+### Connect Customer hiện hành
+
+- voice thông thường: **USD 0.038/phút** cộng phí telephony;
+- Outbound Campaigns voice: **USD 0.045/phút** thay cho mức voice USD 0.038/phút;
+- số điện thoại tính theo ngày; telephony outbound tính theo destination;
+- S3, KMS, CloudWatch, Athena/QuickSight và thuế/phụ phí tính riêng khi phát sinh.
+
+### Một số account còn ở Customer Basic
+
+- voice channel: USD 0.018/phút;
+- conversational analytics: USD 0.015/phút cho 5 triệu phút đầu/tháng;
+- outbound campaign: USD 0.005/attempt + USD 0.025/phút;
+- cộng telephony, number rental và dịch vụ hạ tầng khác.
+
+Công thức sơ bộ cho mô hình mới:
+
+```text
+Monthly AWS ≈ 0.045 × campaign_billable_minutes
+            + Japan outbound telephony
+            + phí thuê số theo ngày (DID gọi ra + toll-free nhận vào)
+            + S3/KMS/logging/reporting
+```
+
+### Ba kịch bản minh họa
+
+Không thể tính chính xác nếu chưa có số liệu thật, nhưng **phải đưa một hình dung về độ lớn** vì đây luôn là câu hỏi thứ hai của khách sau chi phí xây dựng. Bảng dưới đây tính theo mô hình Connect Customer hiện hành, chỉ tính phút **kết nối thật**:
+
+| | Thấp | Trung bình | Cao |
+|---|---:|---:|---:|
+| Agent hoạt động | 10 | 15 | 15 |
+| Cuộc gọi ra / agent / ngày | 80 | 120 | 180 |
+| Cuộc gọi ra / ngày | 800 | 1.800 | 2.700 |
+| Tỷ lệ bắt máy | 10% | 15% | 20% |
+| Cuộc kết nối / ngày | 80 | 270 | 540 |
+| Thời lượng trung bình (phút) | 3 | 3 | 3,5 |
+| Phút kết nối / tháng (20 ngày) | 4.800 | 16.200 | 37.800 |
+| Connect campaign voice @ 0,045 USD/phút | 216 | 729 | 1.701 |
+| Cước viễn thông Nhật @ 0,02–0,06 USD/phút | 96–288 | 324–972 | 756–2.268 |
+| Số điện thoại, S3, KMS, log, báo cáo | 30–80 | 50–120 | 80–200 |
+| **Tổng ước tính / tháng (USD)** | **340–580** | **1.100–1.820** | **2.540–4.170** |
+| Tạm quy đổi 150 JPY/USD | ~5–9 万円 | ~17–27 万円 | ~38–63 万円 |
+
+Cách dùng bảng này:
+
+- **Mọi con số đều là giả định và hiện rõ trên mặt bảng** để khách sửa trực tiếp. Giá trị của bảng là buộc khách cung cấp số liệu thật, không phải là cam kết chi phí.
+- Dải cước viễn thông 0,02–0,06 USD/phút là **giá trị giữ chỗ**, phải thay bằng số thật lấy từ bảng Global Telephony tại ngày báo giá, và tách riêng số cố định với số di động.
+- Nếu account của khách còn ở gói **Customer Basic** cũ thì công thức khác hẳn: voice 0,018 + analytics 0,015 + campaign 0,005/attempt + 0,025/phút. Phải xác nhận pricing plan trước khi lập bảng chính thức.
+- Chưa tính: cuộc gọi inbound, thuế và phụ phí, QuickSight, chi phí truyền dữ liệu, và dự phòng cho việc gọi lại nhiều lần.
+- Nếu ngân sách là ràng buộc, đòn bẩy lớn nhất là **có bật phân tích hội thoại cho 100% cuộc gọi hay chỉ lấy mẫu** — cần hỏi khách sớm.
+
+Không thể tính số tiền tháng đáng tin cậy nếu chưa có: số attempt/ngày, answer rate, average connected duration, ngày làm/tháng, tỷ lệ retry, loại số đích mobile/landline, retention và pricing plan của account.
+
+Nguồn: [Connect Customer pricing](https://aws.amazon.com/products/connect/customer/pricing/), [Pricing appendix](https://aws.amazon.com/products/connect/customer/pricing/appendix/). Giá có thể thay đổi; phải kiểm tra lại khi gửi quotation.
+
+## 13. Kết luận nghiên cứu
+
+Amazon Connect phù hợp và có thể đáp ứng 10–15 seat mà không cần xây PBX/CTI riêng. Phương án native-first giảm code và thời gian, nhưng sáu điểm không được bỏ qua:
+
+1. **Toll-free Nhật không dùng được cho Outbound Campaigns.** Phải để khách chọn giữa "hiển thị フリーダイヤル khi gọi ra" và "tự động quay số theo danh sách" — không có cả hai bằng tính năng native. Khuyến nghị Phương án A: gọi ra bằng DID dùng chung, giữ 0120 để nhận cuộc gọi.
+2. **Lịch số điện thoại là ràng buộc cứng**: hồ sơ pháp nhân, cửa sổ port ngày 1 và 15 của tháng kế tiếp, quota có thể mất tới 3 tuần. Phải khởi động ngay tuần 1 và không cam kết ngày go-live trước khi có xác nhận của AWS.
+3. Bổ sung business disposition + DNC vì dialer disposition không đủ.
+4. Định nghĩa đúng "emotion analysis" và acceptance criteria — dùng sentiment/loudness/interruption, không hứa đọc cảm xúc từ chất giọng.
+5. Có quyết định rõ về PII tiếng Nhật, retention và legal compliance; riêng 電話勧誘販売 còn kéo theo 書面交付 và クーリング・オフ nếu chốt đơn qua điện thoại.
+6. Nhận cuộc gọi vào không thể là tùy chọn: hiển thị một số chung để gọi ra thì chắc chắn có khách gọi lại.

02-giai-phap-va-estimate.md

@@ -0,0 +1,540 @@
+# Giải pháp và estimate triển khai
+
+Ngày lập: 03/09/2026 — **bản sửa lần 2 sau review độc lập** (xem `04-review-doc-lap.md`)
+Đơn vị estimate: **person-day (PD), 1 PD = 8 giờ làm việc hữu ích**.
+
+> **Thay đổi lớn nhất so với bản 1:** số フリーダイヤル 0120/0800 của Nhật **không dùng được** làm số phát cho tính năng quay số tự động theo danh sách của Amazon Connect. Toàn bộ tài liệu này đã được viết lại theo **Phương án A**: gọi ra bằng số cố định 03 (hoặc 050) dùng chung, giữ 0120 để nhận cuộc gọi. Phương án giữ 0120 để gọi ra được trình bày riêng ở §9. Chi tiết bằng chứng: `04-review-doc-lap.md` §1.1.
+
+---
+
+## 1. Assumption dùng để estimate
+
+- Call center phục vụ khách tại Nhật; Connect instance đặt tại `ap-northeast-1` (Tokyo).
+- 10–15 agent, tối đa 15 agent đang nói chuyện cùng lúc; 2 supervisor và 2 admin tối đa.
+- Outbound D2C sales là chính. **Nhận cuộc gọi ở mức cơ bản nằm trong MVP**, vì khi hiển thị một số chung cho mọi cuộc gọi ra thì chắc chắn có khách gọi lại.
+- **Số gọi ra là một số cố định 03/06 hoặc 050 dùng chung cho toàn bộ agent** (Phương án A). Số 0120 nếu khách đã có thì được đưa vào Connect để nhận cuộc gọi.
+- Ngôn ngữ hội thoại, giao diện vận hành và toàn bộ tài liệu bàn giao là tiếng Nhật.
+- Khách cung cấp: AWS account; bộ hồ sơ pháp nhân để xin/chuyển số (xem §5.1); domain/SSO nếu có; mẫu CSV danh sách; kịch bản sales đã được legal duyệt; danh sách số điện thoại dùng để test.
+- MVP dùng màn hình agent và trình tạo chiến dịch có sẵn của Amazon Connect, không xây CRM đầy đủ và không xây portal riêng.
+- MVP có form kết quả cuộc gọi tối giản, danh sách không gọi và hẹn gọi lại; không tích hợp hệ thống đơn hàng/thanh toán.
+- Một môi trường non-production nhỏ và một production; dữ liệu test không dùng thông tin cá nhân thật.
+- Làm việc 8x5; không bao gồm trực 24x7 hay dịch vụ vận hành sau giai đoạn hypercare.
+- Estimate gồm BA/architecture/development/configuration/QA/PM/tài liệu/đào tạo; **không** gồm phí AWS, thiết bị, thuế, license ngoài AWS và **thời gian chờ AWS/nhà mạng/legal**.
+- Range phản ánh độ chưa rõ hiện tại. Báo giá fixed-price nên dùng cận trên và dự phòng thương mại 10% sau discovery.
+
+---
+
+## 2. Danh sách tính năng — mô tả theo ngôn ngữ người dùng
+
+Bảng dưới đây cố ý viết bằng ngôn ngữ nghiệp vụ. Cột "Hệ thống làm gì" là thứ có thể đọc trực tiếp cho khách hàng nghe; cột "Thành phần kỹ thuật" chỉ dành cho đội triển khai.
+
+**Cột "Cách làm" trả lời câu hỏi: cái này là bật sẵn hay phải viết mới?**
+
+| Ký hiệu | Nghĩa | Rủi ro và chi phí bảo trì |
+|---|---|---|
+| **⚙️ Cấu hình** | Dịch vụ AWS đã có sẵn tính năng này. Chỉ bật lên và khai báo tham số, không viết dòng code nào | Thấp nhất. AWS tự nâng cấp, không phải bảo trì |
+| **⚙️+💻 Cấu hình + code nhỏ** | Phần lõi có sẵn, nhưng cần một đoạn code để nối hoặc để bù chỗ thiếu | Trung bình. Đoạn code đó phải tự bảo trì |
+| **💻 Tự xây** | AWS không có sẵn. Phải thiết kế, viết, test và bảo trì | Cao nhất. Là nơi phát sinh lỗi và chi phí về sau |
+| **📄 Thủ tục / tài liệu** | Không phải việc kỹ thuật: hồ sơ, quy trình, phê duyệt | Phụ thuộc bên thứ ba |
+
+### 2.1 Bắt buộc phải có để mở dịch vụ (MVP)
+
+| # | Tính năng | Hệ thống làm gì (đọc là hiểu) | Ai dùng | **Cách làm** | Thành phần kỹ thuật |
+|---:|---|---|---|:--:|---|
+| 1 | Tài khoản và phân quyền | Mỗi người một tài khoản riêng. Agent chỉ thấy phần việc của mình; chỉ quản lý mới nghe được ghi âm; chỉ admin mới sửa được cấu hình. Mọi thao tác nhạy cảm đều để lại dấu vết. | Tất cả | **⚙️** | Connect users, security profiles, CloudTrail |
+| 2 | Nạp danh sách khách hàng | Quản lý tải file CSV lên. Hệ thống tự kiểm tra số điện thoại đúng định dạng, bỏ trùng, loại các số đã đăng ký "không gọi", rồi trả lại báo cáo dòng nào lỗi và lỗi vì sao. | Quản lý | **⚙️+💻** | Customer Profiles, segment từ file CSV |
+| 3 | Tạo đợt gọi (chiến dịch) | Chọn danh sách, đặt khung giờ được phép gọi, số lần gọi lại khi máy bận/không bắt máy, giới hạn tối đa được liên hệ một người bao nhiêu lần, ngày nghỉ không gọi. Bấm chạy hoặc tạm dừng bất cứ lúc nào. | Quản lý | **⚙️** | Outbound Campaigns, Guided Campaign Builder |
+| 4 | Tự động quay số | Hệ thống bấm số thay cho agent. Agent vừa xong cuộc này là có cuộc tiếp theo, không phải nhìn danh sách bấm tay. | Agent | **⚙️** | Progressive/preview dialing |
+| 5 | Nhận biết máy trả lời tự động | Khi gọi ra, hệ thống phân biệt người thật bắt máy với hộp thư thoại hoặc thông báo của nhà mạng, và chỉ nối máy cho agent khi có người thật. | Agent | **⚙️** | Block `Check call progress` (AMD) |
+| 6 | Mọi agent hiện cùng một số | Dù ai gọi thì khách cũng chỉ thấy một số duy nhất của công ty. Khách gọi lại vào số đó thì có người hoặc lời chào tiếp nhận. | Khách hàng cuối | **⚙️ + 📄** | Outbound caller ID ở queue dùng chung |
+| 7 | Gọi được 15 cuộc cùng lúc | Cả 15 chỗ ngồi nói chuyện đồng thời mà không ai bị báo bận vì giới hạn hệ thống. | Tất cả | **⚙️ + 📄** | Tăng quota concurrent calls + campaign calls |
+| 8 | Màn hình làm việc của agent | Khi khách bắt máy, thông tin khách hàng và kịch bản nói hiện lên sẵn. Có nút giữ máy, chuyển máy, kết thúc, và trạng thái rảnh/bận/đang nhập kết quả. | Agent | **⚙️** | Agent Workspace, screen pop, ACW |
+| 9 | Ghi kết quả cuộc gọi | Kết thúc cuộc gọi, agent chọn kết quả: đã bán / quan tâm / hẹn gọi lại / không quan tâm / sai số / không gọi nữa — kèm ghi chú và giờ hẹn. | Agent | **💻** | Step-by-step guide → Lambda → DynamoDB |
+| 10 | Danh sách không gọi | Khách nói "đừng gọi nữa" thì agent bấm một nút. Từ đó mọi đợt gọi sau đều tự động loại số này, không phụ thuộc vào việc ai tạo chiến dịch. | Agent, Quản lý | **💻** | Suppression store, điều kiện lọc khi tạo segment |
+| 11 | Hẹn gọi lại | Agent đặt giờ hẹn; đến giờ, khách hàng đó xuất hiện lại trong việc cần làm, không bị quên và không bị tạo trùng. | Agent | **💻** | Callback records, trạng thái due/completed/cancelled |
+| 12 | Ghi âm mọi cuộc nói chuyện | Mọi cuộc gọi có người bắt máy đều được ghi âm cả hai chiều, lưu trong AWS của chính công ty, có mã hóa. Chỉ người được cấp quyền mới nghe hoặc tải được. | Quản lý | **⚙️** | Recording block, S3 + KMS, lifecycle |
+| 13 | Chuyển hội thoại thành văn bản | Sau cuộc gọi, nội dung được tự động ghi thành text tiếng Nhật, tách rõ lượt nói của agent và của khách. Bấm vào một câu là nhảy đến đúng đoạn ghi âm. | Quản lý | **⚙️** | Conversational Analytics `ja_JP` |
+| 14 | Phân tích sắc thái cuộc gọi | Hệ thống chấm từng đoạn là tích cực / trung tính / tiêu cực, đo độ to giọng, khoảng im lặng và số lần nói chen. Dùng để lọc ra những cuộc cần nghe lại, không dùng để tự động đánh giá agent. | Quản lý | **⚙️** | Sentiment, loudness, interruption, rules |
+| 15 | Nghe lén, nhắc riêng, chen ngang | Quản lý nghe cuộc gọi đang diễn ra để đào tạo; nhắc riêng cho agent mà khách không nghe thấy; hoặc nhảy vào cuộc gọi khi cần cứu tình huống. | Quản lý | **⚙️** | Manager listen-in / whisper / barge |
+| 16 | Tìm lại cuộc gọi | Tìm theo ngày, agent, số điện thoại, kết quả, hoặc theo từ khóa xuất hiện trong nội dung hội thoại. | Quản lý | **⚙️** | Contact search |
+| 17 | Bảng theo dõi thời gian thực | Xem ai đang gọi, ai đang rảnh, ai đang nhập kết quả; đợt gọi còn bao nhiêu số chưa gọi. | Quản lý | **⚙️** | Real-time metrics dashboard |
+| 18 | Báo cáo | Số cuộc gọi ra, tỷ lệ bắt máy, thời lượng trung bình, kết quả theo agent và theo đợt gọi. Xuất được file. | Quản lý | **⚙️** | Historical/saved reports |
+| 19 | Nhận cuộc gọi vào (mức cơ bản) | Khách gọi lại: trong giờ làm việc thì nối cho agent đang rảnh; ngoài giờ thì phát thông báo hoặc cho để lại lời nhắn. | Khách hàng cuối | **⚙️** | Inbound flow, hours of operation, queue |
+| 20 | Cảnh báo và xử lý sự cố | Khi có trục trặc — thiếu file ghi âm, phân tích lỗi, chạm trần số cuộc đồng thời — hệ thống báo cho người phụ trách kèm hướng dẫn xử lý. | Admin | **⚙️+💻** | CloudWatch alarms, EventBridge, runbook |
+| 21 | Đối soát dữ liệu | Mỗi ngày có một bảng đối chiếu: đã gọi bao nhiêu → bao nhiêu cuộc kết nối → bao nhiêu có ghi âm → bao nhiêu có text → bao nhiêu đã nhập kết quả. Lệch ở đâu nhìn ra ngay. | Quản lý, Admin | **💻** | Reconciliation report |
+| 22 | Hồ sơ bảo mật và quyền riêng tư | Bộ tài liệu trả lời câu hỏi của khách về nơi lưu dữ liệu, ai truy cập được, giữ bao lâu, và quy trình khi cá nhân yêu cầu xem hoặc xóa dữ liệu của họ. | Quản lý, Legal | **📄** | セキュリティチェックシート, 委託先管理, retention policy |
+
+### 2.2 Nên có ở giai đoạn sau (Standard)
+
+| Tính năng | Hệ thống làm gì | **Cách làm** | Vì sao chưa làm ở MVP |
+|---|---|:--:|---|
+| Màn hình quản lý danh sách riêng | Một trang web riêng, tiếng Nhật, để trưởng nhóm tự nạp danh sách, xem tiến độ từng danh sách, chia danh sách cho từng agent, sửa nhanh số nhập sai — thay vì thao tác trên màn hình quản trị của AWS | **💻** | Cần MVP chạy thật để biết thao tác nào là thường xuyên nhất |
+| Quản lý kết quả và hẹn gọi lại nâng cao | Sửa hàng loạt, danh sách việc quá hạn, quy tắc ưu tiên cuộc hẹn | **💻** | MVP chỉ cần nhập đúng và không mất dữ liệu |
+| Nối với CRM hoặc hệ thống đơn hàng | Kết quả bán hàng tự động chảy sang hệ thống nghiệp vụ, không phải nhập hai lần | **💻** | Phụ thuộc hệ thống của khách, chưa xác định |
+| Báo cáo kinh doanh | Dashboard tỷ lệ chốt, giá trị đơn, hiệu quả theo nguồn danh sách, theo agent, theo khung giờ | **⚙️+💻** | Cần dữ liệu thật vài tuần mới có ý nghĩa |
+| Đăng nhập một lần (SSO) và tự động hóa hạ tầng | Dùng chung tài khoản công ty; cấu hình được phiên bản hóa và triển khai lại được | **⚙️+💻** | Không chặn việc mở dịch vụ |
+| Cảnh báo tức thời trong lúc gọi | Khi hội thoại chuyển sang tiêu cực hoặc xuất hiện từ khóa cấm, quản lý được báo ngay để vào hỗ trợ | **⚙️+💻** | Cần chốt danh sách từ khóa và quy trình can thiệp |
+
+### 2.3 Có thể cân nhắc về sau (Full / R&D)
+
+| Tính năng | Hệ thống làm gì | **Cách làm** | Điều kiện |
+|---|---|:--:|---|
+| Quay số dự đoán (predictive) | Hệ thống gọi trước nhiều số hơn số agent đang rảnh, dựa trên xác suất bắt máy, để agent gần như không phải chờ | **⚙️** | Cần dữ liệu thật, quota lớn hơn và kiểm soát tỷ lệ cuộc gọi bị bỏ |
+| Tóm tắt cuộc gọi bằng AI | Sau mỗi cuộc, hệ thống tự viết tóm tắt, rút ra vấn đề và việc cần làm | **⚙️** | Cần tinh chỉnh theo nghiệp vụ |
+| Trợ lý gợi ý cho agent | Trong lúc nói chuyện, hệ thống gợi ý câu trả lời từ kho tài liệu | **⚙️+💻** | Cần kho nội dung được chuẩn hóa |
+| Chấm điểm chất lượng tự động | Hệ thống tự chấm cuộc gọi theo bộ tiêu chí, quản lý chỉ xác nhận | **⚙️** | Cần bộ tiêu chí được thống nhất |
+| Xếp ca và dự báo nhân lực | Dự báo lượng việc và xếp ca cho agent | **⚙️** | Cần quy mô lớn hơn |
+| Che thông tin cá nhân trong văn bản | Tự động che số thẻ, địa chỉ, tên trong bản text và trong audio | **💻** | Amazon Connect **chưa hỗ trợ** che tự động cho tiếng Nhật; phải tự xây |
+| Nhận diện cảm xúc qua chất giọng | Gán nhãn giận / vui / buồn dựa trên đặc trưng âm thanh, không dựa vào nội dung nói | **💻 R&D** | Là đề tài R&D, phải PoC trước, xem §8.3 |
+| Dự phòng thảm họa Tokyo–Osaka | Nếu vùng Tokyo gặp sự cố, hệ thống chuyển sang Osaka | **⚙️ + 📄** | Cần gói AWS Enterprise Support và quy trình riêng |
+
+### 2.4 Tóm tắt: phần nào bật sẵn, phần nào phải viết mới
+
+Trong 22 tính năng bắt buộc của MVP:
+
+| Cách làm | Số tính năng | Là những tính năng nào |
+|---|---:|---|
+| **⚙️ Chỉ cấu hình** | 15 | Phân quyền, tạo đợt gọi, tự động quay số, nhận biết máy trả lời, cùng một số gọi ra, 15 cuộc đồng thời, màn hình agent, ghi âm, chuyển thành văn bản, phân tích sắc thái, nghe lén/chen ngang, tìm kiếm cuộc gọi, bảng theo dõi, báo cáo, nhận cuộc gọi vào |
+| **⚙️+💻 Cấu hình + code nhỏ** | 2 | Nạp danh sách (cần script chuẩn hóa số và lọc trước khi đưa vào AWS), cảnh báo sự cố (cần hàm kiểm tra thiếu file) |
+| **💻 Phải tự xây** | 4 | Ghi kết quả cuộc gọi, danh sách không gọi, hẹn gọi lại, đối soát dữ liệu |
+| **📄 Thủ tục/tài liệu** | 1 | Hồ sơ bảo mật và quyền riêng tư |
+
+**Nói ngắn gọn với khách:** phần lõi tổng đài — quay số, ghi âm, chuyển thành văn bản, phân tích tiếng Nhật, báo cáo — là **bật sẵn của AWS, không phải phần mềm chúng ta viết**. Phần phải tự xây chỉ tập trung vào **bốn chỗ mà Amazon Connect không có sẵn**:
+
+| Phải tự xây | Vì sao AWS không có sẵn |
+|---|---|
+| **Ghi kết quả cuộc gọi** | Connect chỉ lưu kết quả kỹ thuật của máy quay số (bận, hộp thư thoại, không bắt máy). "Đã bán / quan tâm / hẹn lại / không quan tâm" là khái niệm nghiệp vụ, không có kho lưu sẵn để tra cứu và báo cáo |
+| **Danh sách không gọi (DNC)** | **Outbound Campaigns không có danh sách chặn dựng sẵn.** Cách duy nhất là gắn cờ trong hồ sơ khách hàng rồi lọc segment trước mỗi đợt gọi — việc gắn cờ và đồng bộ đó phải tự viết |
+| **Hẹn gọi lại** | Cơ chế callback sẵn có của Connect phục vụ khách gọi vào chờ máy, không phải lịch hẹn của nhân viên bán hàng theo giờ Nhật, có chống trùng và có trạng thái |
+| **Đối soát dữ liệu** | Sự kiện cuộc gọi, file ghi âm, bản phân tích và kết quả bán hàng nằm ở bốn nơi khác nhau. Ghép lại thành một bảng "gọi bao nhiêu → có bao nhiêu ghi âm → bao nhiêu có text" là việc phải viết |
+
+Ba trong bốn chỗ này (kết quả, DNC, hẹn gọi lại) nằm chung trong hạng mục **M08** của bảng estimate, và đó cũng là hạng mục có nhiều rủi ro kỹ thuật nhất của MVP.
+
+Ở các phase sau, tỷ lệ đảo chiều: **Standard chủ yếu là code** (màn hình quản lý riêng, tích hợp CRM, kết quả nâng cao), còn **Full core phần lớn lại là bật thêm tính năng có sẵn của AWS** (quay số dự đoán, tóm tắt AI, chấm điểm tự động, xếp ca).
+
+---
+
+## 3. Truy vết từ yêu cầu gốc của khách đến giải pháp
+
+| Yêu cầu gốc (tiếng Nhật) | Nghĩa là gì | Giải pháp | Phase | Nghiệm thu bằng cách nào |
+|---|---|---|---:|---|
+| リストをもとに発信できるシステム | Nạp danh sách rồi hệ thống tự gọi, như BlueBean | CSV → danh sách khách → đợt gọi tự động (progressive/preview) | MVP | Nạp file mẫu, dòng lỗi bị trả về đúng lý do, đợt gọi chạy đúng danh sách, đúng khung giờ, đúng quy tắc gọi lại |
+| 同じフリーダイヤルで全員が発信できる | Ai gọi ra khách cũng thấy cùng một số của công ty | **Không dùng được 0120 cho quay số tự động.** Dùng một số 03/050 chung cho tất cả agent; 0120 dùng để nhận cuộc gọi | MVP | 15 agent gọi ra đều hiện đúng một số, kiểm tra trên ma trận nhà mạng đã thống nhất; gọi lại vào 0120 được tiếp nhận |
+| 15人が同時に発信できる | 15 người nói chuyện cùng lúc không nghẽn | Tăng hạn mức cuộc gọi đồng thời + kiểm thử tải | MVP | 15 cuộc kết nối đồng thời liên tục 30 phút, không có cuộc nào bị báo bận do giới hạn hệ thống |
+| 通話は毎回録音してAWSに保存 | Cuộc nào cũng có file ghi âm, nằm trong AWS của công ty | Bật ghi âm trong luồng gọi, lưu S3 mã hóa | MVP | 100% cuộc gọi có người bắt máy đều có audio hai chiều; cuộc không ai bắt máy có bản ghi sự kiện chứ không có audio |
+| 通話を毎回テキスト化して保存 | Cuộc nào cũng có bản text để đọc và phân tích | Phân tích hội thoại sau cuộc gọi, tiếng Nhật | MVP | 100% cuộc gọi có hội thoại đủ dài đều tạo được bản text; tìm/đọc/tải theo đúng quyền |
+| 声のトーンや感情の分析 | Biết cuộc nào khách khó chịu, agent nói to, nói chen | Sắc thái + độ to giọng + im lặng + nói chen + luật kết hợp | MVP | Nhìn được các chỉ số này trên từng cuộc và trên dashboard; QA xác nhận trên bộ mẫu đã thống nhất |
+| (mở rộng) nhãn cảm xúc theo chất giọng | Máy đọc được cảm xúc từ giọng nói | Mô hình học máy riêng, cần dữ liệu gán nhãn | Tùy chọn | Chỉ nghiệm thu theo precision/recall trên bộ dữ liệu tiếng Nhật hai bên chốt trước |
+| 一部受信もつくるかもしれません | Có thể làm cả nhận cuộc gọi | **Đã đưa vào MVP** ở mức cơ bản: giờ làm việc, hàng đợi, ngoài giờ | MVP | Test trong giờ/ngoài giờ, hàng đợi, cuộc gọi nhỡ |
+
+---
+
+## 4. Kiến trúc đề xuất
+
+```mermaid
+flowchart LR
+    CSV[File CSV danh sách khách] --> CP[Danh sách khách hàng<br/>Customer Profiles + Segments]
+    CP --> OC[Đợt gọi tự động<br/>Outbound Campaigns]
+    DID[Số gọi ra dùng chung<br/>+81 3 hoặc +81 50] --> OC
+    OC --> FLOW[Luồng cuộc gọi ra<br/>nhận biết máy trả lời + ghi âm + phân tích]
+    FLOW --> Q[Hàng đợi outbound]
+    Q --> AW[Màn hình agent<br/>10-15 người]
+    AW --> JP[Khách hàng tại Nhật]
+
+    TFN[Số nhận cuộc gọi<br/>0120/0800] --> IF[Luồng nhận cuộc gọi<br/>giờ làm việc + ngoài giờ]
+    JP -. gọi lại .-> TFN
+    IF --> Q
+
+    FLOW --> S3[S3: ghi âm + bản text<br/>mã hóa KMS + vòng đời lưu trữ]
+    FLOW --> CE[Sự kiện cuộc gọi và chiến dịch]
+    AW --> GUIDE[Form nhập kết quả]
+    GUIDE --> L[Lambda API]
+    L --> DDB[DynamoDB<br/>kết quả, hẹn gọi lại, không gọi nữa]
+    CE --> L
+
+    S3 --> DL[Data lake / Athena]
+    DDB --> DL
+    DL --> QS[QuickSight / BI]
+    CW[CloudWatch + CloudTrail] --- FLOW
+    CW --- L
+```
+
+### 4.1 Luồng một cuộc gọi ra, từ đầu đến cuối
+
+1. Quản lý tải file CSV theo mẫu.
+2. Hệ thống kiểm tra: số đúng định dạng E.164, đủ trường bắt buộc, không trùng, có thông tin đồng ý liên hệ, không nằm trong danh sách không gọi.
+3. Dữ liệu hợp lệ vào danh sách khách hàng và gom thành nhóm để gọi; số bị loại có báo cáo lý do.
+4. Quản lý tạo đợt gọi: chọn số gọi ra, khung giờ, quy tắc gọi lại, giới hạn số lần liên hệ.
+5. Hệ thống quay số khi có agent rảnh; phân biệt người thật / hộp thư thoại / thông báo nhà mạng.
+6. Có người thật bắt máy thì nối cho agent, đồng thời hiện thông tin khách và kịch bản.
+7. Ghi âm và phân tích được bật **trước khi** nối agent.
+8. Kết thúc cuộc gọi, agent nhập kết quả. Chọn "không gọi nữa" thì hệ thống chặn số ngay lập tức; chọn "hẹn gọi lại" thì tạo lịch.
+9. Sự kiện cuộc gọi và kết quả nghiệp vụ được nối với nhau bằng `contactId`, `campaignId`, `profileId`.
+10. Quản lý xem số liệu, nghe ghi âm, đọc text, và xử lý các cuộc bị lỗi.
+
+### 4.2 Dữ liệu tối thiểu cần lưu
+
+| Nhóm dữ liệu | Nội dung | Ghi chú |
+|---|---|---|
+| Khách hàng | mã khách, số điện thoại E.164, tên, nguồn và thời điểm đồng ý liên hệ, cờ không gọi | Nguồn đồng ý là bắt buộc về mặt tuân thủ |
+| Đợt gọi | mã đợt, danh sách nguồn, chế độ quay số, số gọi ra, khung giờ, quy tắc gọi lại, trạng thái | |
+| Lần gọi | mã cuộc gọi, đợt gọi, khách, agent, các mốc thời gian, kết quả kỹ thuật (bận / không bắt máy / hộp thư thoại) | Kết quả kỹ thuật **không** thay cho kết quả bán hàng |
+| Kết quả bán hàng | mã cuộc gọi, mã kết quả, ghi chú, giờ hẹn lại, lý do không gọi nữa, người cập nhật | Do agent nhập |
+| File | mã cuộc gọi, đường dẫn ghi âm, đường dẫn bản phân tích, trạng thái xử lý, nhóm thời hạn lưu | Dùng cho đối soát |
+| Nhật ký | ai, làm gì, trên dữ liệu nào, khi nào | Phục vụ audit |
+
+Không đưa thông tin cá nhân, token, đường dẫn ghi âm có chữ ký hay nội dung hội thoại vào log ứng dụng.
+
+---
+
+## 5. Xử lý các phần khó
+
+### 5.1 Số điện thoại — phần rủi ro nhất của dự án
+
+**Điều đã được xác minh trong Amazon Connect Telecoms Coverage Guide bản 31/08/2026:**
+
+| Loại số Nhật | Gọi ra trong nước | Dùng cho quay số tự động | Custom caller ID | Ghi chú |
+|---|:--:|:--:|:--:|---|
+| DID `+81 3` / `+81 6` | Có | **Có** (`ap-northeast-1`) | Không | Hồ sơ phải chứng minh địa chỉ doanh nghiệp **đúng vùng của area code**; chỉ một số dải số khả dụng |
+| DID `+81 50` | Có | **Có** (`ap-northeast-1`) | Không | Dễ xin hơn, nhưng người Nhật ít bắt máy số 050 |
+| Toll-free `+81 120` / `+81 800` | Có (gọi tay) | **Không** | Không | Chỉ dùng để nhận cuộc gọi, hoặc gọi ra thủ công |
+| UIFN | Không | Không | Không | Chỉ nhận cuộc gọi |
+
+**Hệ quả bắt buộc phải chấp nhận:**
+
+- Không có đường "giữ số ở nhà mạng hiện tại rồi chỉ hiển thị" — Nhật **không hỗ trợ custom caller ID**. Số nào muốn dùng thì phải xin mới hoặc chuyển hẳn vào Amazon Connect.
+- Nếu chuyển số 0120 đang dùng: nghiệp vụ nào đang chạy trên số đó sẽ bị ảnh hưởng, phải có kế hoạch cắt chuyển.
+
+**Kế hoạch xử lý:**
+
+- Tuần 1: mở AWS Support case cho việc xin số, chuyển số, bật gọi ra, và hỏi tồn kho số `+81 3` khả dụng.
+- Tuần 1: yêu cầu khách chuẩn bị 3 loại hồ sơ — giấy đăng ký doanh nghiệp cấp trong 6 tháng, ID hoặc hộ chiếu người đại diện có tên trong đăng ký, giấy tờ chứng minh địa chỉ cấp trong 6 tháng.
+- Bám **cửa sổ chuyển số: thường là ngày 1 và ngày 15 của tháng kế tiếp**. Trượt một nhịp là chậm nửa tháng.
+- Dùng một hàng đợi gọi ra chung và đúng một số gọi ra ở MVP.
+- Test hiển thị số trên NTT cố định và các mạng di động do khách chỉ định.
+- Không cam kết hiển thị tên doanh nghiệp — điều đó do nhà mạng và máy đầu cuối quyết định.
+
+### 5.2 Số cuộc gọi đồng thời
+
+- Hạn mức mặc định: **10** cuộc gọi đồng thời mỗi instance, và **0** cuộc gọi đồng thời cho chiến dịch. Cả hai đều phải xin tăng.
+- MVP đặt mục tiêu **25/25** để có khoảng dự phòng, không xin đúng 15.
+- Phải tạo instance trước rồi mới xin tăng được. **Yêu cầu lớn có thể mất tới 3 tuần** để AWS duyệt.
+- Hạn mức khác cần biết: mặc định **2 instance** mỗi Region (vừa đủ non-prod + prod, không còn chỗ cho sandbox) và **5 số điện thoại** mỗi instance.
+- Có cảnh báo khi chạm trần và dashboard theo dõi số cuộc đồng thời.
+
+### 5.3 "Mọi cuộc gọi đều có ghi âm và text"
+
+- Chỉ cuộc gọi **có người bắt máy và có hội thoại** mới sinh file ghi âm và bản text. Máy bận, số sai, không ai nghe thì không có gì để ghi — nhưng vẫn có bản ghi sự kiện và kết quả kỹ thuật.
+- Bản ghi sự kiện cuộc gọi là nguồn sự thật cho **mọi** lần gọi; ghi âm và bản text là sản phẩm đi kèm khi có hội thoại.
+- Hệ thống tự kiểm tra sau 15 phút; thiếu file thì tạo cảnh báo và đưa vào danh sách xử lý tay. Thời gian phân tích một cuộc gọi thường bằng khoảng 40% độ dài cuộc gọi, nên ngưỡng 15 phút là dư an toàn.
+- Dashboard tách bạch: đã gọi / kết nối / có ghi âm / có text / phân tích lỗi.
+- "Có text" khác với "text chính xác". Cần một bộ khoảng 20 cuộc gọi được người Nhật đối chiếu, thống nhất cách đo lỗi và ngưỡng chấp nhận **trước UAT**, và nạp trước danh sách tên sản phẩm/thương hiệu vào từ điển riêng.
+
+### 5.4 Nhận biết máy trả lời tự động trong môi trường Nhật
+
+Tính năng này được huấn luyện chủ yếu trên thị trường nói tiếng Anh. Ở Nhật còn có 留守番電話サービス và các thông báo của nhà mạng như 「おかけになった電話番号は現在使われておりません」 hay 「電波の届かない場所にいるか、電源が入っていない」. Nhận nhầm thì mất khách tiềm năng hoặc lãng phí thời gian agent.
+
+→ Phải đo trên bộ mẫu thật (cố định, di động, số sai, máy trả lời) và đưa ngưỡng vào tiêu chí nghiệm thu. Nằm trong M11.
+
+### 5.5 Kết quả bán hàng và danh sách không gọi
+
+- Kết quả kỹ thuật của máy quay số (bận, hộp thư thoại, không bắt máy) **không** thay cho kết quả bán hàng.
+- MVP dùng form nhập kết quả ngay trên màn hình agent, lưu qua Lambda vào DynamoDB.
+- Khi chọn "không gọi nữa": cập nhật danh sách chặn trước, rồi mới đồng bộ hồ sơ khách. Mọi đợt gọi mới đều bắt buộc lọc theo điều kiện này.
+- Hẹn gọi lại theo giờ Nhật, chống tạo trùng, có trạng thái đến hạn / đã xong / đã hủy.
+
+### 5.6 "Phân tích tone và cảm xúc" thực sự là gì
+
+- MVP hiển thị: sắc thái tích cực/trung tính/tiêu cực theo từng đoạn và cả cuộc, độ to giọng, khoảng im lặng, số lần nói chen, và luật kết hợp để tự gắn cờ cuộc cần nghe lại.
+- Đây là phân tích **nội dung lời nói**, không phải máy đọc cảm xúc từ chất giọng. Phải thống nhất cách nói này với khách trước khi ký.
+- Dùng để chọn cuộc gọi cho QA, **không** dùng để tự động đánh giá năng lực hay đạo đức agent.
+- Nếu khách muốn nhãn cảm xúc theo chất giọng, phải PoC trước; chỉ estimate production sau PoC.
+
+### 5.7 Thông tin cá nhân trong bản ghi âm và text
+
+- Amazon Connect **chưa hỗ trợ** che tự động thông tin cá nhân cho tiếng Nhật (cột Redaction của `ja_JP` để trống).
+- MVP: không đọc số thẻ/thông tin thanh toán qua điện thoại; dùng link thanh toán hoặc kênh đạt chuẩn riêng. Kèm phân quyền chặt và thời hạn lưu ngắn nhất hợp lệ.
+- Nếu bắt buộc phải che: là một workstream riêng (X02), phải có bộ test đo được độ chính xác theo từng loại thông tin.
+
+---
+
+## 6. Các phương án triển khai
+
+| Phương án | Mục tiêu | Phạm vi | Estimate cộng dồn | Lịch tham khảo |
+|---|---|---|---:|---:|
+| **MVP native-first** | Mở dịch vụ được, chi phí thấp nhất, đủ mọi yêu cầu bắt buộc | Danh sách + đợt gọi tự động, 15 cuộc đồng thời, một số gọi ra dùng chung, nhận cuộc gọi cơ bản, kết quả/không gọi nữa/hẹn lại, ghi âm, text và phân tích tiếng Nhật, báo cáo có sẵn, giám sát và hồ sơ bảo mật | **57–80 PD**; baseline 68 | 9–11 tuần |
+| Standard | Dễ vận hành và nối được với nghiệp vụ | MVP + màn hình quản lý danh sách riêng, kết quả/hẹn lại nâng cao, một tích hợp CRM hoặc đơn hàng, dashboard kinh doanh, SSO/IaC/CI-CD | **99–140 PD**; baseline 120 | 13–17 tuần |
+| Full core | Tối ưu năng suất và chất lượng | Standard + quay số dự đoán, cảnh báo tức thời, tóm tắt AI, trợ lý agent, chấm điểm tự động, xếp ca, BI nâng cao, SMS follow-up, hardening | **166–240 PD**; baseline 203 | 21–29 tuần |
+| Full + R&D/compliance/DR | Nâng cao | Full core + nhận diện cảm xúc theo giọng, che thông tin cá nhân tiếng Nhật, dự phòng Tokyo–Osaka | **221–328 PD** | 29–41 tuần |
+
+Lịch giả định 2–3 người cho MVP, 3–4 người cho Standard, 4–5 người cho Full, các vai trò có thể kiêm nhiệm. **Thời gian theo lịch không bằng person-day chia cho số người**, vì có UAT, phê duyệt của AWS/nhà mạng và các bước phải làm tuần tự.
+
+### Khuyến nghị thương mại
+
+- Chào **MVP Phương án A** nếu khách muốn mở dịch vụ cuối tháng 10 / đầu tháng 11 — và nói rõ mốc này chỉ khả thi nếu hồ sơ xin số được nộp trong tháng 9.
+- Báo giá **hai phương án tách bạch** (§9), không đưa một con số duy nhất, vì phương án giữ フリーダイヤル để gọi ra lệch tới +30 PD.
+- Chạy pilot 5 agent trong 1 tuần trước khi mở đủ 15 agent.
+- Sau 4–6 tuần có dữ liệu thật, quyết định Standard/Full theo tỷ lệ chốt, tỷ lệ bắt máy, thời gian nhập kết quả và nhu cầu của quản lý.
+- Nhận diện cảm xúc theo giọng và che thông tin cá nhân tiếng Nhật nên là PoC có điều kiện, không cam kết fixed-price production ngay.
+
+---
+
+## 7. Estimate chi tiết MVP — Phương án A
+
+| ID | Hạng mục | Làm gì trong hạng mục này | Bàn giao cái gì | PD thấp | PD cao |
+|---|---|---|---|---:|---:|
+| M01 | Khảo sát nghiệp vụ và tuân thủ | Ngồi với khách chốt quy trình gọi, bộ mã kết quả, quy tắc đồng ý liên hệ và không gọi nữa, thời hạn lưu dữ liệu | Tài liệu quy trình, bộ mã kết quả, ma trận nghiệm thu | 3 | 4 |
+| M02 | Thiết kế giải pháp và bảo mật | Vẽ kiến trúc, luồng dữ liệu, phân quyền, mã hóa, các chỉ tiêu phi chức năng | HLD, data flow, mô hình phân quyền | 2 | 3 |
+| M03 | Dựng nền tảng AWS | Tạo môi trường non-prod và prod, kho lưu trữ, khóa mã hóa, log, vòng đời dữ liệu, tag và ngân sách | Hai môi trường chạy được | 4 | 5 |
+| M04 | Số điện thoại và hạn mức | Chuẩn bị hồ sơ pháp nhân, mở case với AWS, theo cửa sổ chuyển số, xin tăng hạn mức, lên kế hoạch test hiển thị số | Số gọi ra + số nhận vào hoạt động, hạn mức đã duyệt | 4 | 6 |
+| M05 | Người dùng và định tuyến | Tạo tài khoản cho 10–15 agent, quản lý, admin; phân nhóm, hàng đợi, hồ sơ định tuyến, thời gian nhập kết quả | Người dùng đăng nhập và nhận cuộc gọi được | 2 | 3 |
+| M06 | Danh sách và đợt gọi | Mẫu CSV, quy tắc kiểm tra dữ liệu, gom nhóm khách, cấu hình quay số, quy tắc gọi lại, khung giờ, giới hạn liên hệ | Nạp danh sách và chạy đợt gọi được | 5 | 7 |
+| M07 | Luồng cuộc gọi, ghi âm, phân tích | Dựng luồng gọi ra, bật ghi âm hai chiều, bật phân tích tiếng Nhật, nạp từ điển riêng, xử lý nhánh lỗi | Cuộc gọi có audio và text | 4 | 5 |
+| M08 | Kết quả, không gọi nữa, hẹn lại | Form nhập kết quả trên màn hình agent, API lưu trữ, danh sách chặn, quy tắc lọc trước khi gọi, trường phục vụ audit | Agent nhập được kết quả, số bị chặn không bị gọi lại | 5 | 7 |
+| M09 | Công cụ cho quản lý | Tìm kiếm cuộc gọi, quyền nghe/tải ghi âm, báo cáo lưu sẵn, nghe lén / nhắc riêng / chen ngang | Quản lý giám sát được đội | 3 | 4 |
+| M10 | Giám sát và vận hành | Cảnh báo, dashboard, kiểm tra thiếu file, nhật ký thao tác, khung tài liệu xử lý sự cố | Bộ cảnh báo có chủ và có hướng dẫn xử lý | 2 | 3 |
+| M11 | Kiểm thử kỹ thuật và tải | Test luồng, ma trận nhà mạng, đo nhận biết máy trả lời trên mẫu tiếng Nhật, test trình duyệt/tai nghe, 15 cuộc đồng thời, các ca lỗi | Báo cáo test và bằng chứng | 6 | 9 |
+| M12 | UAT và ổn định | Hỗ trợ khách nghiệm thu, sửa lỗi, pilot 5 agent, mở rộng 15 agent, hypercare 10 ngày làm việc ở mức 0.5 FTE | Hệ thống chạy thật | 4 | 5 |
+| M13 | Tài liệu và đào tạo (tiếng Nhật) | Sổ tay admin / agent / quản lý, từ điển dữ liệu, 3 buổi đào tạo — toàn bộ bằng tiếng Nhật | Bộ tài liệu và đào tạo | 4 | 6 |
+| M14 | Quản lý dự án | Kế hoạch, quản lý rủi ro, làm việc với AWS và khách, báo cáo tiến độ, kiểm soát phát hành | Điều hành dự án | 3 | 4 |
+| M15 | Nhận cuộc gọi (mức cơ bản) | Giờ làm việc, lời chào, hàng đợi, xử lý ngoài giờ và cuộc gọi nhỡ, ghi âm/phân tích giống outbound | Khách gọi lại được tiếp nhận | 5 | 7 |
+| M16 | Hồ sơ bảo mật và quyền riêng tư | Bảng kiểm bảo mật, tài liệu quản lý bên nhận ủy thác, quy trình khi cá nhân yêu cầu xem/xóa dữ liệu | Bộ hồ sơ nộp cho khách | 1 | 2 |
+| | **Tổng MVP Phương án A** | | | **57** | **80** |
+
+**Baseline lập kế hoạch: 68 PD.**
+
+So với bản 1 (46–63 PD): chênh lệch đến từ việc đưa nhận cuộc gọi vào bắt buộc (+5–7), mở rộng phần số điện thoại theo quy trình Nhật (+2–3), thêm nghe lén/nhắc riêng/chen ngang (+1), thêm đo nhận biết máy trả lời (+1–2), thêm hồ sơ bảo mật (+1–2), và tài liệu/đào tạo hoàn toàn bằng tiếng Nhật (+1–2).
+
+### 7.1 Cùng số đó, nhìn theo "phải viết code hay chỉ cấu hình"
+
+Đây là cách đọc estimate mà khách hàng thường muốn thấy nhất — tiền bỏ ra đi vào việc gì:
+
+| Loại công việc | Nằm ở hạng mục nào | PD thấp | PD cao | Tỷ trọng |
+|---|---|---:|---:|---:|
+| ⚙️ **Cấu hình dịch vụ AWS có sẵn** | M03, M05, M07, M09, M15, phần cấu hình của M06, M10 | 22 | 29 | ~37% |
+| 💻 **Code tự viết** | M08 toàn bộ; script chuẩn hóa danh sách trong M06; hàm kiểm tra thiếu file và đối soát trong M10 | **8** | **12** | **~15%** |
+| 🔍 Khảo sát và thiết kế | M01, M02 | 5 | 7 | ~9% |
+| 📄 Thủ tục với AWS và nhà mạng | M04 | 4 | 6 | ~7% |
+| ✅ Kiểm thử và nghiệm thu | M11, M12 | 10 | 14 | ~18% |
+| 📘 Tài liệu, đào tạo, hồ sơ bảo mật | M13, M16 | 5 | 8 | ~9% |
+| 📋 Quản lý dự án | M14 | 3 | 4 | ~5% |
+| | **Tổng** | **57** | **80** | 100% |
+
+Ba điều đáng nói với khách từ bảng này:
+
+1. **Chỉ khoảng 15% công sức là viết phần mềm mới.** Phần lớn tiền đi vào cấu hình đúng, kiểm thử thật và bàn giao được — chứ không phải xây một hệ thống từ đầu. Đây chính là lý do chọn Amazon Connect thay vì tự dựng tổng đài.
+2. **Kiểm thử chiếm tỷ trọng gần bằng cấu hình.** Với call center, rủi ro không nằm ở chỗ tính năng chạy được, mà ở chỗ hiển thị số đúng trên mọi nhà mạng, âm thanh nghe rõ, và không mất dữ liệu cuộc gọi. Cắt phần này là cắt vào chỗ nguy hiểm nhất.
+3. **Nếu chọn Phương án B (giữ 0120 để gọi ra), phần code tăng gấp ba** — từ 8–12 PD lên 26–42 PD, tức khoảng 35–38% khối lượng, vì phải tự xây lại bộ quay số mà AWS vốn cho sẵn. Đó là chi phí thật của việc giữ số フリーダイヤル, và nó còn kéo dài sang chi phí bảo trì về sau.
+
+---
+
+## 8. Estimate phần tăng thêm
+
+### 8.1 Lên Standard
+
+| ID | Hạng mục tăng thêm | Làm gì | PD thấp | PD cao |
+|---|---|---|---:|---:|
+| S01 | Màn hình quản lý danh sách riêng | Trang web tiếng Nhật để nạp danh sách, xem tiến độ, chia việc, sửa dữ liệu, xem lỗi và nhật ký | 10 | 14 |
+| S02 | Kết quả và hẹn gọi lại nâng cao | Sửa hàng loạt, danh sách quá hạn, quy tắc ưu tiên | 6 | 9 |
+| S03 | Một tích hợp CRM hoặc đơn hàng | Đồng bộ hai chiều với một hệ thống nghiệp vụ | 7 | 11 |
+| S05 | Dashboard kinh doanh | Kho dữ liệu, truy vấn và biểu đồ theo tỷ lệ chốt, nguồn danh sách, agent, khung giờ | 7 | 10 |
+| S06 | SSO, IaC và CI/CD | Đăng nhập bằng tài khoản công ty, cấu hình được phiên bản hóa và triển khai lại | 6 | 8 |
+| S07 | Kiểm thử, tài liệu, PM cho phần tăng thêm | | 6 | 8 |
+| | **Tổng tăng thêm Standard** | | **42** | **60** |
+| | **Cộng dồn MVP + Standard** | | **99** | **140** |
+
+> Mục S04 (nhận cuộc gọi) của bản 1 đã được chuyển vào MVP, nên **không** cộng lại ở đây.
+
+Mỗi hệ thống CRM/đơn hàng bổ sung ngoài hệ đầu tiên: tạm tính **6–12 PD/hệ**, phải estimate lại theo chất lượng API và dữ liệu.
+
+### 8.2 Lên Full core
+
+| ID | Hạng mục tăng thêm | PD thấp | PD cao |
+|---|---|---:|---:|
+| F01 | Quay số dự đoán: pilot, điều tiết nhịp gọi, kiểm soát cuộc bị bỏ, tinh chỉnh hạn mức | 5 | 8 |
+| F02 | Cảnh báo tức thời theo nội dung/sắc thái và quy trình can thiệp của quản lý | 5 | 8 |
+| F03 | Tóm tắt cuộc gọi bằng AI, rút trích kết quả và việc cần làm | 5 | 8 |
+| F04 | Trợ lý gợi ý cho agent và kho tri thức | 8 | 12 |
+| F05 | Chấm điểm chất lượng tự động, lấy mẫu, hiệu chuẩn, coaching | 6 | 9 |
+| F06 | Dự báo và xếp ca | 5 | 8 |
+| F07 | BI nâng cao: phễu, nhóm khách, chất lượng theo agent/đợt gọi, lưu trữ dài hạn | 8 | 12 |
+| F08 | SMS/email theo sau cuộc gọi | 5 | 8 |
+| F09 | Hardening bảo mật, kiểm thử xâm nhập, tải và khả năng phục hồi | 8 | 12 |
+| F10 | UAT toàn diện, triển khai, đào tạo, quản trị thay đổi và PM | 12 | 15 |
+| | **Tổng tăng thêm Full core** | **67** | **100** |
+| | **Cộng dồn đến Full core** | **166** | **240** |
+
+### 8.3 Tùy chọn nâng cao ngoài Full core
+
+| ID | Tùy chọn | Nội dung | PD thấp | PD cao |
+|---|---|---|---:|---:|
+| X01 | Nhận diện cảm xúc theo giọng | Định nghĩa nhãn, kế hoạch gán nhãn, PoC, đánh giá, pipeline xử lý, người xem lại, MLOps tối thiểu | 25 | 40 |
+| X02 | Che thông tin cá nhân tiếng Nhật | Xác định loại thông tin, bộ phát hiện, canh thời gian, che trong text và audio, kho bản gốc hạn chế, QA | 18 | 30 |
+| X03 | Dự phòng Tokyo–Osaka | Điều kiện, thiết kế, nhân bản tài nguyên, chuyển số và agent, dữ liệu, diễn tập | 12 | 18 |
+| | **Tổng ba tùy chọn** | | **55** | **88** |
+| | **Full core + ba tùy chọn** | | **221** | **328** |
+
+**X01 nên được trình bày như một đề xuất PoC riêng có tiêu chí dừng, không phải một dòng trong bảng giá.** Con số 25–40 PD chỉ là phần production tối thiểu sau khi đã có dữ liệu gán nhãn; chi phí thu thập và gán nhãn diện rộng, review pháp lý và license mô hình bên thứ ba không bao gồm.
+
+---
+
+## 9. Phương án B — nếu khách bắt buộc gọi ra bằng フリーダイヤル
+
+Vì Amazon Connect không cho dùng số 0120 làm số phát cho quay số tự động, muốn giữ yêu cầu này thì phải **tự xây bộ quay số**. Đây là việc mà hướng native-first vốn dĩ tránh được.
+
+| ID | Hạng mục tăng thêm so với Phương án A | PD thấp | PD cao |
+|---|---|---:|---:|
+| B01 | PoC bắt buộc: xác nhận gọi ra bằng 0120 hoạt động thật, và kiểm tra khả năng dùng cơ chế callback để có nhận biết máy trả lời | 5 | 8 |
+| B02 | Bộ quay số tự xây: hàng đợi danh sách, điều tiết nhịp gọi, gọi lại, khung giờ, giới hạn liên hệ, lọc danh sách chặn trước khi gọi | 10 | 16 |
+| B03 | Xử lý thay thế cho nhận biết máy trả lời và điều chỉnh thao tác của agent | 2 | 4 |
+| B04 | Kiểm thử và vận hành bổ sung | 1 | 2 |
+| | **Tổng tăng thêm** | **18** | **30** |
+| | **MVP Phương án B** | **75** | **110** |
+
+Nhìn theo cách phân loại ở §7.1: Phương án B đẩy phần **code tự viết từ 8–12 PD lên 26–42 PD**, và toàn bộ phần tăng thêm đó là phần mềm do dự án tự bảo trì, không được AWS nâng cấp theo thời gian.
+
+Rủi ro của Phương án B, phải nói rõ với khách trước khi ký:
+
+- **Mất tính năng nhận biết máy trả lời tự động.** Block này chỉ hoạt động cho cuộc gọi của chiến dịch và cuộc gọi lại kiểu khách được nối trước; các loại khác đều rơi vào nhánh lỗi. Agent sẽ phải tự nghe và tự bỏ qua hộp thư thoại.
+- Toàn bộ phần lịch gọi, gọi lại, giới hạn tần suất phải tự xây và tự bảo trì, thay vì dùng tính năng có sẵn được AWS cập nhật.
+- Không có PoC thì không nên cam kết. Đề nghị tách B01 thành một hợp đồng nhỏ trước.
+
+---
+
+## 10. Vai trò và kế hoạch MVP tham khảo
+
+| Vai trò | Tỷ lệ tham gia trung bình | Trách nhiệm |
+|---|---:|---|
+| PM/BA biết tiếng Nhật | 0.3 FTE | Yêu cầu, làm việc với khách, UAT, rủi ro, đào tạo |
+| Kiến trúc sư Connect/AWS | 0.3 FTE | Kiến trúc, luồng gọi, số điện thoại, hạn mức, bảo mật |
+| Kỹ sư cloud/backend | 0.4 FTE | Lambda, DynamoDB, sự kiện, giám sát |
+| Kỹ sư Connect | 0.4 FTE | Instance, người dùng, định tuyến, đợt gọi, phân tích |
+| QA | 0.2 FTE, tăng ở giai đoạn cuối | Thiết kế test, E2E, đồng thời, UAT |
+| | **≈ 1.6 FTE trung bình** | |
+
+> **Lưu ý cách đọc bảng này.** 68 PD trải trên khoảng 10 tuần (50 ngày làm việc) tương đương **khoảng 1.4–1.6 FTE trung bình**, không phải 3–4 người toàn thời gian. Bản 1 của tài liệu ghi 3.1–3.7 FTE, tương đương 124–185 PD năng lực — lệch 2–3 lần so với chính estimate của nó. Nếu báo giá theo FTE × tháng thì phải dùng bảng này, nếu không giá sẽ bị đội gấp đôi.
+>
+> Lịch dài hơn số PD vì có các giai đoạn chờ: chờ AWS duyệt hạn mức, chờ cửa sổ chuyển số, chờ khách nghiệm thu. Trong các giai đoạn đó đội không trực toàn thời gian.
+
+```mermaid
+gantt
+    title Lịch MVP tham khảo - các mốc số điện thoại là mốc cứng
+    dateFormat  YYYY-MM-DD
+    axisFormat  %d/%m
+    section Mốc cứng ngoài tầm kiểm soát
+    Nộp hồ sơ xin/chuyển số           :milestone, m1, 2026-09-11, 0d
+    Cửa sổ chuyển số 15/10            :milestone, m2, 2026-10-15, 0d
+    Cửa sổ chuyển số 01/11            :milestone, m3, 2026-11-01, 0d
+    AWS duyệt tăng hạn mức (tối đa 3 tuần) :a2, 2026-09-08, 21d
+    section Discovery
+    Yêu cầu nghiệp vụ + quyết định legal :a1, 2026-09-07, 7d
+    section Build
+    Nền tảng + cấu hình Connect        :b1, after a1, 10d
+    Đợt gọi + luồng gọi + phân tích    :b2, after b1, 12d
+    Kết quả/không gọi nữa/hẹn lại      :b3, after b1, 12d
+    Nhận cuộc gọi cơ bản               :b4, after b2, 5d
+    section Verify
+    Tích hợp + test 15 cuộc đồng thời  :c1, after b2, 7d
+    UAT + pilot 5 agent                :c2, after c1, 7d
+    Mở rộng 15 agent + hypercare       :c3, after c2, 10d
+```
+
+Ngày trong biểu đồ chỉ minh họa với giả định kickoff 07/09/2026. **Mốc 「10月後半」 chỉ khả thi nếu hồ sơ xin số được nộp trong tháng 9 và số về kịp cửa sổ 15/10.** Nếu trượt sang cửa sổ 01/11 thì lịch mở dịch vụ phải lùi tương ứng. Đây không phải cam kết lịch khi chưa có xác nhận của AWS.
+
+---
+
+## 11. Tiêu chí phi chức năng và điều kiện mở dịch vụ
+
+### Năng lực và chất lượng
+
+- 15 cuộc gọi kết nối đồng thời, duy trì ít nhất 30 phút.
+- Không chạm trần hạn mức của Connect; không rớt cuộc do lỗi ứng dụng trong test tải.
+- Test kết nối thành công trên từng máy agent; độ trễ trung bình không vượt 300 ms.
+- Âm thanh hai chiều nghe rõ trên ma trận nhà mạng do khách chốt.
+- Nhận biết máy trả lời đạt ngưỡng đã thống nhất trên bộ mẫu tiếng Nhật.
+
+### Đầy đủ dữ liệu
+
+- 100% cuộc gọi kết nối trong test có bản ghi cuộc gọi.
+- 100% cuộc gọi kết nối có hội thoại đủ dài có ghi âm hai chiều và phân tích thành công, trừ lỗi phía AWS đã được ghi nhận và mở ticket.
+- Độ chính xác của bản text được đo trên bộ mẫu tiếng Nhật đã đối chiếu; ngưỡng chấp nhận được hai bên ký **trước** UAT, thay vì mặc định "phải đúng 100%".
+- 100% số được đánh dấu không gọi nữa bị loại trước đợt gọi kế tiếp.
+- Có báo cáo đối soát: đã gọi → kết nối → ghi âm → text → kết quả bán hàng.
+
+### Bảo mật và vận hành
+
+- Agent không nghe hoặc tải được ghi âm ngoài phạm vi được cấp.
+- Kho lưu trữ chặn truy cập công khai; chính sách và vòng xoay khóa mã hóa được review.
+- Không có thông tin cá nhân trong log ứng dụng và log luồng gọi mẫu.
+- Mỗi cảnh báo có người chịu trách nhiệm và có hướng dẫn xử lý; đã diễn tập khôi phục cấu hình.
+- Legal ký duyệt kịch bản, thông báo ghi âm và mục đích sử dụng, thời hạn lưu, quy tắc không gọi nữa và khung giờ gọi.
+
+---
+
+## 12. Rủi ro, phụ thuộc và loại trừ
+
+| Rủi ro / phụ thuộc | Ảnh hưởng | Cách xử lý |
+|---|---|---|
+| **0120 không dùng được cho quay số tự động** | Sai kiến trúc nếu không phát hiện sớm | Đã chuyển sang Phương án A; nếu khách bắt buộc giữ 0120 thì chuyển sang Phương án B kèm PoC |
+| Số về chậm hoặc trượt cửa sổ chuyển số 1/15 | Trễ ngày mở dịch vụ | Nộp hồ sơ tuần 1, bám cửa sổ, chuẩn bị số dự phòng |
+| Không xin được số 03 do điều kiện địa chỉ hoặc hết số | Phải dùng 050, tỷ lệ bắt máy thấp hơn | Hỏi tồn kho số ngay tuần 1, cho khách biết trước sự đánh đổi |
+| Hạn mức chưa được duyệt (có thể mất tới 3 tuần) | Không đạt 15 cuộc đồng thời | Xin 25/25 sớm, kèm dự báo lưu lượng, test tải |
+| **Số gọi ra bị gắn nhãn 迷惑電話** | Tỷ lệ bắt máy tụt dần mà không có lỗi kỹ thuật nào | Theo dõi tỷ lệ bắt máy hằng ngày như chỉ số cảnh báo sớm; đăng ký thông tin doanh nghiệp cho số; nếu nghiêm trọng thì phải nới yêu cầu "một số duy nhất" |
+| **Năng suất progressive thấp hơn kỳ vọng BlueBean** | Khách thấy hệ thống chậm dù nghiệm thu kỹ thuật đạt | Chốt chỉ tiêu số cuộc/agent/ngày ngay ở discovery; nếu cần volume thì đưa F01 lên sớm |
+| **Quản lý phải thao tác trên màn hình quản trị AWS** | MVP bị đánh giá "không dùng được trên thực tế" | Demo màn hình thật ngay trong discovery, chốt quy trình vận hành hằng ngày bằng văn bản, cảnh báo trước khả năng phải kéo S01 lên MVP |
+| **Chốt hợp đồng qua điện thoại kéo theo 書面交付 và クーリング・オフ** | Thiếu quy trình bắt buộc theo 特商法 | Hỏi khách ngay; nếu có thì bổ sung workstream riêng, có legal Nhật xác nhận |
+| Nhận biết máy trả lời sai trong môi trường Nhật | Mất khách tiềm năng hoặc lãng phí agent | Đo trên bộ mẫu thật, đưa ngưỡng vào nghiệm thu |
+| Dữ liệu CSV bẩn, thiếu thông tin đồng ý hoặc múi giờ | Gọi sai hoặc nạp lỗi | Mẫu chuẩn, quy tắc kiểm tra, báo cáo dòng lỗi, khách chỉ định người chịu trách nhiệm dữ liệu |
+| "Cảm xúc" không có định nghĩa đo được | Tranh chấp khi nghiệm thu | Chốt trước: dùng chỉ số có sẵn, hay cần mô hình riêng có KPI |
+| Không có che thông tin cá nhân tiếng Nhật | Rủi ro riêng tư | Hạn chế dữ liệu đọc qua điện thoại, phân quyền, thời hạn lưu ngắn; X02 nếu bắt buộc |
+| Quay số dự đoán tạo cuộc gọi im lặng | Khiếu nại, rủi ro pháp lý | MVP dùng progressive; predictive chỉ sau pilot và có ngưỡng kiểm soát |
+| Mạng hoặc tai nghe của agent kém | Âm thanh xấu, text sai | LAN có dây, tai nghe USB, test kết nối và nhà mạng |
+| Thay đổi luật, giá hoặc dịch vụ AWS | Đổi phạm vi hoặc chi phí | Review lại tài liệu và bảng giá trước khi báo giá và trước khi mở dịch vụ |
+
+Không bao gồm trong estimate cơ sở:
+
+- mua laptop, tai nghe, router, đường truyền, setup văn phòng;
+- phí AWS, AWS Support, số điện thoại, cước viễn thông, SMS/email, license QuickSight;
+- dịch và soạn kịch bản bán hàng, tư vấn pháp lý, xin đồng ý liên hệ từ khách hàng cuối;
+- làm sạch dữ liệu thủ công khối lượng lớn;
+- thanh toán/PCI, quản lý đơn hàng, CRM đầy đủ;
+- di chuyển dữ liệu lịch sử;
+- vận hành 24x7 hoặc hợp đồng SLA dài hạn;
+- gán nhãn dữ liệu khối lượng lớn và license AI bên thứ ba;
+- quá một hệ thống CRM/tích hợp ở mức Standard.
+
+---
+
+## 13. Các câu hỏi phải chốt sau discovery
+
+**Nhóm quyết định kiến trúc — phải trả lời trước khi báo giá:**
+
+1. **Nếu buộc phải chọn một: ưu tiên hiển thị フリーダイヤル khi gọi ra, hay ưu tiên tự động quay số theo danh sách?** Đây là câu hỏi quan trọng nhất của dự án.
+2. Có chấp nhận hiển thị số 03 (Tokyo) khi gọi ra và giữ 0120 chỉ để nhận cuộc gọi không?
+3. Số 0120 hiện có đang ở nhà mạng nào, hợp đồng ra sao, và có chấp nhận **chuyển hẳn** sang AWS không? Nghiệp vụ nào đang chạy trên số đó?
+4. Đã có đăng ký pháp nhân và địa chỉ thuộc vùng của area code muốn dùng chưa? Bộ 3 hồ sơ khi nào nộp được?
+
+**Nhóm quyết định phạm vi và quy mô:**
+
+5. "Cuối tháng 10 / đầu tháng 11" là ngày pilot hay ngày chạy đủ 15 agent?
+6. Mục tiêu số cuộc gọi mỗi agent mỗi ngày và tỷ lệ bắt máy kỳ vọng là bao nhiêu?
+7. Bao nhiêu lead mỗi ngày, gọi trong khung giờ nào, thời lượng trung bình dự kiến?
+8. Danh sách đến từ CSV hay CRM nào; ai chịu trách nhiệm về việc đã có đồng ý liên hệ và chất lượng dữ liệu?
+9. Bộ mã kết quả, quy tắc gọi lại, cam kết thời gian gọi lại và phạm vi danh sách không gọi cụ thể là gì?
+10. Ai là người thao tác hằng ngày (nạp danh sách, tạo đợt gọi)? Người đó dùng được màn hình quản trị AWS bằng tiếng Nhật không, hay bắt buộc phải có màn hình riêng?
+11. Agent ngồi ở Nhật hay nước khác? Có dùng VPN/VDI không?
+
+**Nhóm tuân thủ và dữ liệu:**
+
+12. **Có chốt hợp đồng ngay trên điện thoại không?** Nếu có thì ai lo việc giao 契約書面 và quy trình クーリング・オフ 8 ngày?
+13. Thời hạn lưu ghi âm và bản text là bao lâu; ai được nghe, tải, xóa?
+14. Có nói hoặc thu thập thông tin thanh toán, sức khỏe hay dữ liệu nhạy cảm khác trong cuộc gọi không?
+15. Khách có yêu cầu bảng kiểm bảo mật hoặc tài liệu quản lý bên nhận ủy thác theo mẫu riêng không?
+
+**Nhóm kỹ thuật và vận hành:**
+
+16. "Phân tích tone/cảm xúc" dùng để làm gì, và chấp nhận các chỉ số có sẵn hay cần nhãn theo chất giọng?
+17. Chỉ số bắt buộc trên dashboard là gì: số cuộc gọi, tỷ lệ kết nối, tỷ lệ chốt, doanh số, thời gian nhập kết quả hay điểm chất lượng?
+18. **Ngân sách vận hành AWS mỗi tháng** là bao nhiêu? (quyết định bật phân tích cho 100% cuộc gọi hay lấy mẫu)
+19. Danh sách số điện thoại dùng để test do ai cung cấp và khi nào?
+20. Có yêu cầu SSO, IaC, multi-account, dự phòng thảm họa, RTO/RPO hay chuẩn bảo mật bắt buộc nào không?

03-review.md

@@ -0,0 +1,130 @@
+# Review phạm vi, giải pháp và estimate
+
+Ngày review: **03/09/2026** (review nội bộ lần 1)
+Tài liệu được review: `01-nghien-cuu-cong-nghe.md`, `02-giai-phap-va-estimate.md`.
+
+> ⚠️ **Tài liệu này đã bị thay thế một phần.** Review độc lập lần 2 (`04-review-doc-lap.md`) phát hiện review lần 1 **bỏ sót một lỗi chặn**: số toll-free 0120/0800 của Nhật không dùng được cho Outbound Campaigns, và Nhật không hỗ trợ custom caller ID. Các mục §2, §4, §5 và §7 dưới đây đã được cập nhật theo phát hiện đó. Số liệu estimate hiện hành nằm ở `02-giai-phap-va-estimate.md` bản sửa lần 2.
+>
+> **Bài học rút ra cho quy trình review:** lần 1 chỉ đọc lại kết luận trong tài liệu nghiên cứu, không mở nguồn gốc. Điểm sai nằm ở chỗ tài liệu nghiên cứu đọc đúng cột `National Outbound` nhưng bỏ qua cột `Outbound Campaign Regions` của cùng một bảng. Với các khẳng định quyết định kiến trúc, review phải mở đúng bảng gốc và đọc từng ô, không dựa vào diễn giải.
+
+## 1. Kết luận review
+
+**Đạt để dùng làm bản estimate/pre-proposal sau khi đã sửa theo review lần 2**, với điều kiện ghi rõ đây là ROM estimate dựa trên assumption và phải qua discovery trước khi ký fixed-price.
+
+Các yêu cầu gốc đều đã có giải pháp, phase và acceptance criteria. Estimate không chỉ tính cấu hình Amazon Connect mà đã bao gồm các phần thường bị bỏ sót: business disposition, DNC, callback, quota/number engineering, monitoring, concurrency test, UAT, tài liệu, đào tạo và PM.
+
+## 2. Review coverage yêu cầu
+
+| Hạng mục | Trạng thái | Nhận xét review |
+|---|---|---|
+| List-based outbound | Đủ | Có CSV/Profile/Segment/Campaign, validation, retry và schedule |
+| Một toll-free dùng chung | ❌ **Không đạt — đã sửa ở bản 2** | Toll-free Nhật không nằm trong outbound campaign regions và Nhật không có custom caller ID. Đã chuyển sang Phương án A: DID dùng chung để gọi ra, 0120 để nhận cuộc gọi |
+| 15 simultaneous | Đủ | Đã phát hiện quota mặc định 10/0, có headroom 25/25 và load test |
+| Recording vào AWS | Đủ | Có flow, S3/KMS, RBAC, lifecycle, failure reconciliation |
+| Transcript mỗi call | Đủ sau khi định nghĩa lại | Chỉ connected eligible-speech calls; failed/no-answer có event chứ không có transcript |
+| Sentiment/tone | Đủ, không over-promise | Native signal rõ ràng; acoustic emotion tách thành R&D option |
+| Inbound tiềm năng | ⚠️ **Đã chuyển thành must-have** | Hiển thị một số chung để gọi ra thì chắc chắn có khách gọi lại; để trống số đó là mất lead và tạo rủi ro khiếu nại |
+| Compliance Nhật | Đã bổ sung | Consent/DNC/script/purpose/retention và nguồn cơ quan Nhật |
+| Vận hành production | Đủ cho MVP | Alarm, audit, runbook, training, pilot và hypercare — bản 2 đã định lượng hypercare 10 ngày làm việc ở mức 0.5 FTE |
+| Giám sát chất lượng agent | ⚠️ **Thiếu ở bản 1** | Nghe lén / nhắc riêng / chen ngang không có trong danh sách must-have; đã bổ sung vào MVP |
+| Chi phí vận hành hàng tháng | ⚠️ **Thiếu ở bản 1** | Chỉ có công thức, không có con số. Bản 2 đã thêm ba kịch bản minh họa với giả định hiện rõ |
+
+## 3. Review kiến trúc
+
+### Điểm hợp lý
+
+- Native-first giảm code: Customer Profiles/Segments và Guided Campaign Builder thay cho việc tự xây dialer.
+- Dùng progressive ở MVP phù hợp quy mô 15 agent và giảm rủi ro abandonment so với predictive.
+- Shared queue/source number là cách đúng để dùng caller ID chung — nhưng **số đó phải là DID**, không phải toll-free (xem §2).
+- Recording, transcript và analytics liên kết bằng contact ID; business outcome tách riêng nhưng join được.
+- DNC là suppression toàn hệ thống, không bị nhầm với communication frequency cap.
+- Data lake/QuickSight chỉ đưa vào Standard/Full nên MVP không bị đội chi phí.
+- Custom emotion, PII redaction và DR được tách option vì có uncertainty/dependency lớn.
+
+### Điều kiện cần xác minh bằng PoC/Support
+
+1. ~~Chính số 0120/0800 của khách có được dùng làm source number cho Outbound Campaigns không.~~ **Đã có câu trả lời: không.** Xác minh trực tiếp trong Telecoms Coverage Guide 31/08/2026; vẫn nên lấy xác nhận bằng văn bản của AWS Support để đưa vào hồ sơ.
+2. Tồn kho số `+81 3` khả dụng cho campaign tại `ap-northeast-1`, và điều kiện của footnote (2) về "chỉ một số dải số nhất định".
+3. Caller ID hiển thị trên các carrier/handset mục tiêu như kỳ vọng không.
+4. Với Phương án B': customer-first callback có dùng được caller ID toll-free và block `Check call progress` không.
+3. Chất lượng transcript/sentiment tiếng Nhật trên giọng, thuật ngữ và môi trường thật.
+4. Agent Workspace Guide có đủ UX cho outcome/callback của quy trình cuối cùng; nếu không, chuyển sang thin portal Standard.
+5. Chính sách retention/deletion có đáp ứng legal và quy định nội bộ không.
+
+## 4. Review estimate và phép cộng
+
+Phép cộng của bản 1 đã được kiểm tra lại và **đều đúng về mặt số học**. Nhưng phạm vi đã đổi sau review lần 2, nên con số hiện hành là cột bên phải:
+
+| Nhóm | Bản 1 | **Bản 2 (hiện hành)** | Vì sao đổi |
+|---|---|---|---|
+| MVP | 46–63 | **57–80**, baseline 68 | Inbound vào must-have (+5–7); mở rộng phần số điện thoại (+2–3); nghe lén/chen ngang (+1); đo AMD tiếng Nhật (+1–2); hồ sơ bảo mật (+1–2); tài liệu và đào tạo hoàn toàn bằng tiếng Nhật (+1–2) |
+| Inbound add-on | 5–7 tách riêng | đã gộp vào MVP | Không còn là tùy chọn |
+| Standard increment | 47–67 | **42–60** | Bỏ S04 vì inbound đã nằm trong MVP |
+| Cộng dồn Standard | 93–130 | **99–140**, baseline 120 | |
+| Full core increment | 67–100 | 67–100 | Không đổi |
+| Cộng dồn Full core | 160–230 | **166–240**, baseline 203 | |
+| Advanced options X01–X03 | 55–88 | 55–88 | Không đổi; X01 nên tách khỏi bảng giá chính |
+| Full core + tất cả option | 215–318 | **221–328** | |
+| **Phương án B (giữ 0120 gọi ra)** | không có | **75–110** cho MVP | Phải tự xây dialer, +18–30 PD, và mất AMD native |
+
+### Đánh giá mức estimate
+
+- **MVP 57–80 PD là hợp lý** cho production nhỏ nhưng có compliance/data/analytics; thấp hơn đáng kể chỉ khả thi nếu bỏ disposition/DNC custom, bỏ non-prod hoặc giảm test — không được khuyến nghị.
+- **Standard 99–140 PD hợp lý** khi có portal, một integration và BI. Điểm biến động lớn nhất là API/data quality của CRM/order system.
+- **Full core 166–240 PD hợp lý ở mức ROM**. AI/QA/WFM cần business tuning và change management, không chỉ cấu hình kỹ thuật.
+- **Phương án B 75–110 PD** chỉ nên báo giá sau khi PoC B01 kết thúc; trước đó chỉ báo giá phần PoC.
+- **X01 emotion 25–40 PD chỉ là production track tối thiểu sau khi scope dataset rõ**; nếu phải tự thu/label hàng nghìn giờ audio, effort sẽ lớn hơn và phải estimate riêng.
+- **X02 redaction 18–30 PD là PoC-to-limited-production**, không phải chứng nhận không bao giờ lọt PII. Entity scope và accuracy target có thể làm estimate tăng mạnh.
+- **X03 DR 12–18 PD** chỉ tính work kỹ thuật sau khi khách đủ AWS Support/eligibility; phí/support lead time không bao gồm.
+
+## 5. Kiểm tra double-count và phần thiếu
+
+### Không double-count
+
+- Inbound là add-on MVP nhưng đã nằm trong Standard increment. Khi báo giá Standard, không cộng thêm add-on inbound lần nữa.
+- Standard cumulative = MVP core + Standard increment; Full cumulative = Standard cumulative + Full increment.
+- Native post-call analytics nằm trong MVP; F03 chỉ tính tuning/extraction nghiệp vụ bằng AI, không tính lại việc bật transcript.
+- Native reports nằm trong MVP; S05/F07 tính data pipeline và BI nghiệp vụ nâng cao.
+
+### Các phần cố ý loại khỏi estimate
+
+- AWS/telco/legal waiting time;
+- phí cloud/telephony/equipment;
+- tư vấn pháp lý và chuẩn bị consent;
+- làm sạch dữ liệu khối lượng lớn;
+- payment/PCI và CRM đầy đủ;
+- managed service 24x7;
+- dataset labeling lớn cho ML.
+
+**Đính chính:** kết luận "không thiếu hạng mục bắt buộc nào" của review lần 1 là **sai**. Review lần 2 phát hiện thiếu: nhận cuộc gọi ở mức cơ bản, nghe lén/nhắc riêng/chen ngang, đo AMD trên mẫu tiếng Nhật, hồ sơ bảo mật và quyền riêng tư, bảng chi phí vận hành, quy trình 書面交付 / クーリング・オフ nếu chốt đơn qua điện thoại, và bộ số điện thoại dùng để test. Chi tiết ở `04-review-doc-lap.md` §2.
+
+## 6. Các chỉnh sửa quan trọng sau review
+
+Review đã giữ/bổ sung các guardrail sau trong proposal:
+
+- định nghĩa “every call” thành connected call có media/speech và thêm reconciliation report;
+- tách dialer disposition khỏi business outcome;
+- DNC được xử lý toàn instance, không dùng frequency cap thay thế;
+- tăng quota có headroom, không xin đúng 15;
+- không khẳng định toll-free campaign hoạt động trước khi test số cụ thể;
+- ghi rõ Japanese native PII redaction chưa được support matrix xác nhận;
+- không quảng bá sentiment/loudness là nhận dạng cảm xúc chính xác;
+- tách transcript availability khỏi transcription accuracy và bổ sung Japanese pilot/custom vocabulary;
+- estimate bao gồm PM, UAT, training và production pilot;
+- chỉ dùng predictive sau khi có dữ liệu thật và compliance approval.
+
+## 7. Gate trước khi gửi báo giá chính thức
+
+Chỉ chuyển ROM thành quotation sau khi có các quyết định sau:
+
+- **khách chọn Phương án A hay B** (hiển thị フリーダイヤル khi gọi ra, hay tự động quay số theo danh sách);
+- số điện thoại: loại số, tồn kho `+81 3`, hồ sơ pháp nhân và cửa sổ port đã chốt được chưa;
+- peak volume/AHT/answer rate để sizing quota;
+- CSV/CRM sample và data owner;
+- outcome/DNC/callback workflow;
+- định nghĩa acceptance cho sentiment/tone;
+- retention, recording notice, PII/payment và legal approval;
+- SSO/environments/security standard;
+- KPI dashboard và integration cụ thể.
+
+Nếu khách chưa trả lời, dùng MVP Phương án A **68 PD baseline** (range 57–80), trình bày kèm Phương án B **75–110 PD** như một lựa chọn riêng, và luôn đưa range cùng danh sách loại trừ thay vì một con số fixed duy nhất.

04-review-doc-lap.md

@@ -0,0 +1,290 @@
+# Review độc lập bộ tài liệu Amazon Connect Call Center
+
+Ngày review: **03/09/2026**
+Tài liệu được review: `01-nghien-cuu-cong-nghe.md`, `02-giai-phap-va-estimate.md`, `03-review.md`, `README.md`
+Phương pháp: đọc chéo 3 tài liệu + kiểm chứng lại nguồn AWS gốc tại thời điểm review (docs AWS, Telecoms Coverage Guide bản 31/08/2026 tải trực tiếp và đọc theo từng ô của bảng).
+
+---
+
+## 0. Kết luận review
+
+Bộ tài liệu có chất lượng cao: cấu trúc tốt, có acceptance criteria, đã tránh được hầu hết các bẫy quen thuộc (định nghĩa lại "mọi cuộc gọi", tách dialer disposition khỏi business outcome, quota mặc định, không over-promise về emotion AI). Phép cộng estimate kiểm tra lại đều đúng.
+
+**Nhưng không thể gửi cho khách ở trạng thái hiện tại**, vì một kết luận nền tảng bị sai và nó làm hỏng kiến trúc MVP:
+
+> Số **0120/0800 (フリーダイヤル) của Nhật KHÔNG dùng được làm số phát cho Amazon Connect Outbound Campaigns.**
+> Chỉ DID Nhật (`+81 3`, `+81 6`, `+81 50`) mới được hỗ trợ outbound campaign từ `ap-northeast-1`.
+
+Nghĩa là hai yêu cầu gốc của khách — *「リストをもとに発信できるシステム（BlueBeanのようなイメージ）」* và *「同じフリーダイヤルで全員が発信できる」* — **không thể đồng thời thỏa mãn bằng tính năng native của Amazon Connect**. Đây là quyết định phải đưa cho khách chốt, không phải chi tiết kỹ thuật để "xác nhận với AWS Support sau".
+
+Ngoài ra có 1 lỗi kỹ thuật khác (custom caller ID), 10 thiếu sót về phạm vi/nghiệp vụ, và 7 vấn đề trong estimate. Chi tiết bên dưới.
+
+---
+
+## 1. Lỗi chặn (blocker) — phải sửa trước khi gửi khách
+
+### 1.1 [BLOCKER] Toll-free Nhật không dùng được cho Outbound Campaigns
+
+**Tài liệu hiện đang viết gì**
+
+- `01` §4: *"Bản Amazon Connect Telecoms Coverage Guide, cập nhật 31/08/2026, đánh dấu toll-free Nhật có `National Outbound = supported`; Tokyo là outbound campaign region cho Nhật."*
+- `README`: *"Số 0120/0800 dùng chung làm caller ID outbound nội địa về nguyên tắc được bảng coverage hỗ trợ."*
+- `03` §2: xếp yêu cầu này là **"Đủ nhưng có dependency"**.
+
+**Thực tế trong đúng bản coverage guide đó**
+
+Bảng có 9 cột: `Number availability | National Outbound | International Outbound | Porting Available | Multi-Carrier | Custom Caller ID | Region Availability | Outbound Campaign Regions | Status`.
+Khối Japan gồm 4 hàng (ảnh chụp lưu tại `evidence/japan-telecoms-coverage-2026-08-31.png`):
+
+| Service Type | National Outbound | Intl Outbound | Porting | Custom Caller ID | Region Availability | **Outbound Campaign Regions** |
+|---|:--:|:--:|:--:|:--:|---|:--:|
+| DID `+81 3` / `+81 6` | ✔ | ✔ | ✔ (hạn chế, footnote 2) | ✘ | ap-northeast-1 | **ap-northeast-1** |
+| DID `+81 50` | ✔ | ✔ | ✘ | ✘ | All commercial regions | **ap-northeast-1** |
+| **Toll-free `+81 120` / `+81 800`** | ✔ | ✘ | ✔ | ✘ | All commercial regions | **–** |
+| UIFN | ✘ | ✘ | ✔ | ✘ | All commercial regions | **–** |
+
+Footnote (2): *"Local Numbers and Porting in Japan is only possible on specific numbers"*.
+
+Cách đọc bảng đã được đối chiếu với các nước khác để chắc chắn không nhầm ô gộp: Hàn Quốc (DID → `ap-northeast-2`, Toll-free → `–`), Úc (DID → `ap-southeast-2`, Toll-free/UIFN → `–`), Ý/Áo (Toll-free có National Outbound ✔ nhưng campaign `–`). Mỹ là ngoại lệ duy nhất trong nhóm này: cả DID lẫn Toll-free đều campaign-capable. **Nhật theo mẫu chung, không theo ngoại lệ Mỹ.**
+
+**Diễn giải đúng**
+
+- Toll-free Nhật `National Outbound = ✔` chỉ có nghĩa: **gọi ra thủ công** (agent bấm gọi / API `StartOutboundVoiceContact`) với caller ID là 0120 thì được hỗ trợ và CLI được đảm bảo hiển thị.
+- Nhưng **Outbound Campaigns không nhận số toll-free Nhật làm source number**. Toàn bộ phần "BlueBean-like": Guided Campaign Builder, preview/progressive/predictive, AMD, retry theo disposition, communication limits, campaign schedule — đều đi kèm campaign và do đó đi kèm DID.
+
+**Hệ quả dây chuyền — AMD cũng mất theo**
+
+Đã kiểm tra thêm block `Check call progress` (AMD): block này **chỉ hoạt động cho 2 loại cuộc gọi**: *Outbound campaigns* và *Customer-first callbacks*. Mọi loại khác rơi vào nhánh `Error`. Vì vậy nếu tự xây dialer bằng `StartOutboundVoiceContact` để giữ caller ID 0120 thì **không có AMD native** — với outbound sales tiếng Nhật (留守番電話, "おかけになった電話番号は…", "電源が入っていない") đây là mất mát lớn về năng suất.
+
+**Ba phương án để trình khách**
+
+| | Phương án A (khuyến nghị) | Phương án B | Phương án B' (cần PoC) |
+|---|---|---|---|
+| Số phát ra | DID `+81 3` (hoặc `+81 50`) | Toll-free 0120 | Toll-free 0120 |
+| Số nhận vào | 0120 (claim/port vào Connect) | 0120 | 0120 |
+| Cơ chế quay số | Outbound Campaigns native | Tự xây dialer trên `StartOutboundVoiceContact` | Customer-first callback + `Check call progress` |
+| AMD | Có (native) | **Không** | Có, **nếu** PoC xác nhận callback dùng caller ID của queue và AMD chạy đúng |
+| Retry/schedule/frequency cap | Có (native) | Phải tự xây | Phải tự xây |
+| Rủi ro | Thấp | Cao | Cao, chưa có tài liệu AWS khẳng định |
+| Chênh lệch effort so với A | – | **+18–30 PD** | **+12–20 PD + 5–8 PD PoC** |
+
+Khuyến nghị: chào **phương án A**, giữ 0120 cho inbound và cho nhận diện thương hiệu, và nói rõ với khách rằng "cùng một số cho tất cả agent" vẫn đạt được (một DID dùng chung), chỉ là số đó không phải フリーダイヤル.
+
+**Lưu ý khi chọn DID cho phương án A**
+
+- `+81 3` / `+81 6` (số địa lý): tỷ lệ bắt máy tốt nhất, **nhưng** hồ sơ bắt buộc phải chứng minh địa chỉ doanh nghiệp **thuộc đúng vùng của area code**, và footnote (2) cảnh báo chỉ một số dải số nhất định là khả dụng → phải hỏi AWS về tồn kho số trước khi cam kết.
+- `+81 50` (IP phone): claim dễ hơn, mọi region, **nhưng** người tiêu dùng Nhật có xu hướng không bắt máy số 050 và nhiều app chặn cuộc gọi gắn cờ mạnh với dải này → ảnh hưởng trực tiếp KPI connect rate của một call center bán hàng.
+
+### 1.2 [Lỗi kỹ thuật] Custom Caller ID không khả dụng tại Nhật
+
+`01` §4 viết: *"số phải được claim/port vào Connect **hoặc** được AWS xác minh quyền sở hữu và bật custom caller ID"*.
+
+Sai với Nhật. Coverage guide: **Custom Caller ID = ✘ cho cả 4 loại số Nhật** (DID 03/06, DID 050, Toll-free, UIFN). Không có đường "giữ số ở carrier hiện tại, chỉ chứng minh sở hữu rồi hiển thị". Số 0120 hiện có của khách (nếu có) **bắt buộc phải port vào Amazon Connect** mới dùng được — kéo theo rủi ro gián đoạn nghiệp vụ inbound đang chạy trên số đó.
+
+### 1.3 [Rủi ro lịch] Cửa sổ porting Nhật là cố định, và tăng quota mất tới 3 tuần
+
+Chưa tài liệu nào nêu các con số này, nhưng chúng quyết định trực tiếp việc có kịp 「10月後半か11月上旬」 hay không:
+
+| Yếu tố | Thực tế theo tài liệu AWS | Ảnh hưởng |
+|---|---|---|
+| Cửa sổ port số Nhật (cả toll-free lẫn 03/06) | **Thường là ngày 1 và 15 của tháng KẾ TIẾP** | Hồ sơ nộp trong tháng 9 → sớm nhất port được 01/10 hoặc 15/10; trượt một nhịp là sang 01/11 |
+| Hồ sơ claim số Nhật | 3 loại: giấy đăng ký DN (cấp trong 6 tháng), ID/hộ chiếu người đại diện có tên trong đăng ký DN, chứng minh địa chỉ DN (cấp trong 6 tháng) | Phải yêu cầu khách chuẩn bị **ngay tuần 1**, không phải sau khi ký hợp đồng |
+| Địa chỉ cho số 03/06 | Phải thuộc đúng thành phố của area code | Nếu văn phòng chưa mở/chưa đăng ký → không claim được số Tokyo |
+| Tăng quota | AWS: yêu cầu nhỏ vài giờ, **yêu cầu lớn tới 3 tuần**; phải tạo instance trước | Phải mở case trong tuần đầu |
+| Instances per Region | Mặc định **2** | Non-prod + prod là vừa hết, không còn chỗ cho sandbox → nên xin tăng sớm |
+| Phone numbers per instance | Mặc định **5** | Đủ cho MVP nhưng cần biết trước khi test nhiều số |
+
+Gantt trong `02` §11 đang để "Number/quota support cases: 28d" như một thanh liên tục. Nên thay bằng các **mốc cứng** (ngày nộp hồ sơ → cửa sổ port 1/15 → ngày test carrier) và ghi rõ đây là dependency nằm ngoài tầm kiểm soát của đội dự án.
+
+---
+
+## 2. Thiếu sót về phạm vi và nghiệp vụ
+
+### 2.1 Inbound không thể là "add-on tùy chọn"
+
+Khi 15 agent gọi ra bằng cùng một số, khách hàng Nhật **sẽ gọi lại vào số đó** — đây là hành vi mặc định, không phải trường hợp hiếm. Nếu số đó không có gì trả lời (hoặc tệ hơn: đổ chuông vô tận), thì:
+- mất lead đã quan tâm;
+- gây khiếu nại, và với 特商法 thì việc không liên lạc lại được là điểm yếu khi bị hỏi;
+- nếu là 0120 thì mỗi cuộc gọi lại còn tốn cước của chính khách hàng doanh nghiệp.
+
+→ Đề nghị chuyển **I01–I04 (5–7 PD) từ add-on thành must-have của MVP**, ít nhất ở mức: giờ làm việc + guidance + hàng đợi tối giản + voicemail/announcement ngoài giờ + ghi âm/analytics giống outbound.
+
+### 2.2 Thiếu monitor / whisper / barge cho supervisor
+
+Danh sách must-have `02` §2.1 không có nghe lén (listen-in), nhắc riêng cho agent (whisper) và chen ngang (barge). Với call center outbound sales mới thành lập, 10–15 agent mới tuyển, đây là công cụ đào tạo và kiểm soát chất lượng cơ bản mà supervisor sẽ hỏi ngay ngày đầu. Native của Connect có, nhưng phải cấu hình security profile và phải xử lý mặt pháp lý/thông báo. **Thêm vào MVP, ~1 PD.**
+
+### 2.3 Năng suất progressive 1:1 có thể không đạt kỳ vọng "BlueBean"
+
+`01` §3.2 khuyến nghị progressive cho MVP và đẩy predictive sang Full. Về mặt tuân thủ và rủi ro thì đúng, nhưng về kỳ vọng kinh doanh thì nguy hiểm: progressive là **1 agent rảnh : 1 cuộc gọi**. Với cold call D2C, phần lớn thời gian agent sẽ ngồi chờ đổ chuông/không bắt máy. Khách đang so sánh với BlueBean, nơi predictive là mặc định.
+
+→ Phải chốt **KPI 件数/人/日 ngay ở discovery**. Nếu khách cần volume, F01 (predictive, 5–8 PD) phải nằm trong MVP hoặc phase 2 rất sớm, kèm sizing lại quota và kiểm soát abandonment. Đây là rủi ro "nghiệm thu kỹ thuật đạt nhưng khách thấy hệ thống chậm hơn kỳ vọng".
+
+### 2.4 AMD tiếng Nhật chưa có trong test plan
+
+`Check call progress` được huấn luyện chủ yếu trên thị trường nói tiếng Anh. Môi trường Nhật có các mẫu đặc thù: 留守番電話サービス, thông báo của carrier ("おかけになった電話番号は現在使われておりません", "電波の届かない場所にいるか、電源が入っていない"), và 転送電話. Sai AMD làm mất lead (đánh nhầm thành voicemail) hoặc lãng phí agent.
+→ Thêm vào **M11** một hạng mục đo AMD trên bộ mẫu thật (landline/mobile/số sai/máy trả lời) và đưa ngưỡng vào acceptance.
+
+### 2.5 Rủi ro số bị gắn nhãn 迷惑電話
+
+Gọi ra volume cao liên tục từ **một** số duy nhất là kịch bản kinh điển dẫn đến bị các app chặn cuộc gọi (電話帳ナビ, Whoscall…) và cơ chế lọc của carrier gắn nhãn "営業電話/迷惑電話". Connect rate có thể tụt dần theo tuần mà không có lỗi kỹ thuật nào. Yêu cầu "cùng một số cho tất cả" làm rủi ro này tập trung tối đa.
+
+→ Không có cách khắc phục kỹ thuật thuần túy. Cần: đưa vào mục rủi ro, thống nhất theo dõi connect rate theo ngày như một chỉ số cảnh báo sớm, đăng ký thông tin doanh nghiệp cho số gọi ra, và chuẩn bị sẵn phương án nhiều số (khách phải hiểu rằng nếu chấp nhận nhiều số thì phải nới yêu cầu "cùng một số").
+
+### 2.6 Thiếu 書面交付義務 và クーリング・オフ của 電話勧誘販売
+
+`01` §11 đã nêu 氏名等の明示 và 再勧誘の禁止 — tốt. Nhưng còn thiếu phần có ảnh hưởng trực tiếp đến hệ thống:
+
+- Nếu **chốt hợp đồng ngay trên điện thoại**, 電話勧誘販売 theo 特商法 phát sinh **nghĩa vụ giao 契約書面** và **quyền クーリング・オフ 8 ngày** kể từ ngày nhận văn bản.
+- Hệ quả hệ thống: phải lưu mốc thời gian gửi/nhận văn bản, trạng thái trong thời hạn cooling-off, và cơ chế hủy đơn — cùng với chính sách không tiếp tục chào bán trong giai đoạn đó.
+
+Đây là D2C bán hàng qua điện thoại nên khả năng phát sinh rất cao. Hiện **không có** trong feature list, data model (`BusinessOutcome` chỉ có outcomeCode/callbackAt/DNC) lẫn estimate.
+→ Phải hỏi khách (câu hỏi mới, xem §5) và nếu có thì bổ sung workstream riêng. Đây không phải tư vấn pháp lý; cần legal Nhật của khách xác nhận.
+
+### 2.7 Không có con số chi phí AWS hàng tháng
+
+`01` §12 chỉ đưa công thức và nói "không thể tính đáng tin cậy nếu chưa có input". Về mặt kỹ thuật là đúng và trung thực — nhưng về mặt đề xuất thì đây là **thiếu sót lớn nhất**: câu hỏi thứ hai của mọi khách hàng sau "bao nhiêu tiền build" luôn là 「月いくらかかるの？」. Đưa tài liệu không có con số nào sẽ bị đánh giá là chưa làm xong bài.
+
+→ Bổ sung bảng **3 kịch bản (thấp / trung bình / cao)** với giả định hiện rõ trên mặt bảng: số attempt/ngày, answer rate, AHT, ngày làm việc/tháng, tỷ lệ mobile vs landline. Ghi rõ "giá tại ngày X, phải xác nhận lại khi báo giá" và ghi rõ pricing plan của account (Connect Customer mới vs Customer Basic cũ) là biến số lớn nhất. Một bảng có giả định sai rõ ràng vẫn tốt hơn không có bảng nào, vì nó buộc khách cung cấp số liệu thật.
+
+### 2.8 Thiếu phần trả lời "vì sao Amazon Connect thay vì BlueBean"
+
+Khách tự chọn Connect nên tài liệu không bàn — hợp lý về mặt phạm vi, nhưng rủi ro về mặt thương mại. Khi khách thấy 46–63 PD, họ sẽ tự so với BlueBean (SaaS Nhật, tính theo ghế/tháng, lên sóng trong vài ngày, hỗ trợ tiếng Nhật, đã có sẵn list management + predictive + báo cáo).
+→ Thêm một mục ngắn, trung thực: Connect thắng ở ghi âm/transcript/sentiment tiếng Nhật gắn liền trong nền tảng, dữ liệu nằm trong AWS account của khách, mở rộng và tích hợp không giới hạn; đổi lại là chi phí xây dựng ban đầu, cần người vận hành AWS, và phần list management phải tự làm. Nêu trước sẽ mạnh hơn nhiều so với bị hỏi ngược.
+
+### 2.9 Vận hành danh sách hằng ngày chưa được thiết kế
+
+Customer Profiles + Segments **không phải** là list management theo nghĩa của BlueBean. Những thứ một trưởng nhóm telesales dùng hằng ngày mà Connect không có sẵn khái niệm tương ứng:
+
+- "list" như một thực thể có tiến độ (đã gọi 320/1000, còn lại chia cho ai);
+- phân bổ list theo agent/nhóm;
+- sửa nhanh một số điện thoại nhập sai, xóa một lead theo yêu cầu;
+- đánh dấu "lần thử thứ 3, chuyển sang danh sách cold".
+
+`02` đã xếp thin portal vào Standard (S01, 10–14 PD), nhưng MVP lại giả định supervisor thao tác trực tiếp trên AWS admin console — bằng tiếng Nhật, với khái niệm profile/segment/campaign của AWS. **Đây là rủi ro MVP bị nghiệm thu là "không dùng được trên thực tế"**, dù mọi tiêu chí kỹ thuật đều pass.
+→ Ít nhất phải: demo console thật cho supervisor trong discovery, chốt quy trình vận hành hằng ngày bằng văn bản, và cảnh báo trước rằng S01 có thể phải kéo lên MVP.
+
+### 2.10 Thiếu các thủ tục bảo mật/riêng tư mà khách Nhật thường yêu cầu
+
+- **セキュリティチェックシート** và tài liệu **委託先管理** (khách Nhật gần như luôn yêu cầu khi giao dữ liệu cá nhân cho bên thứ ba) — chưa có trong deliverable.
+- Quy trình xử lý yêu cầu **開示・訂正・利用停止・削除** của cá nhân theo 個人情報保護法 — chưa có, dù dự án lưu recording + transcript chứa giọng nói và nội dung hội thoại.
+- Hợp đồng/điều khoản về việc xử lý dữ liệu cá nhân giữa khách và bên triển khai.
+
+---
+
+## 3. Vấn đề trong estimate
+
+**Đã kiểm tra lại toàn bộ phép cộng — tất cả đều đúng** (M01–M14 = 46/63; I = 5/7; S = 47/67 → 93/130; F = 67/100 → 160/230; X = 55/88 → 215/318). Các vấn đề dưới đây là về nội dung, không phải số học.
+
+### 3.1 [Quan trọng] Bảng FTE mâu thuẫn với số person-day
+
+`02` §11 liệt kê: PM/BA 0.4–0.6 + architect 0.4–0.6 + backend 1.0 + Connect engineer 0.8–1.0 + QA 0.5 = **3.1–3.7 FTE**, chạy trong **8–10 tuần** → năng lực tương đương **124–185 PD**.
+Nhưng MVP chỉ estimate **46–63 PD**. Chênh lệch 2–3 lần.
+
+Đây là rủi ro thực tế khi lập giá: nếu bộ phận thương mại báo giá theo FTE × tháng thì giá sẽ gấp 2–3 lần con số PD; nếu báo theo PD nhưng thực tế giữ đội hình như bảng thì dự án lỗ. Phải chọn một trong hai:
+- giảm bảng FTE xuống mức trung bình ~1.2–1.5 FTE (đúng với 54 PD / 9 tuần), hoặc
+- giữ đội hình và ghi rõ đây là **elapsed time có nhiều giai đoạn chờ** (chờ AWS, chờ port số, chờ UAT của khách), đồng thời tách bạch "PD tính tiền" và "thời gian trực chiến".
+
+### 3.2 Các hạng mục cần bổ sung vào MVP
+
+| Hạng mục | PD đề xuất | Lý do |
+|---|---:|---|
+| Inbound tối thiểu (I01–I04 chuyển thành must-have) | +5–7 | §2.1 |
+| M04 mở rộng: hồ sơ số Nhật, LOA, theo dõi cửa sổ port, 2 loại số, retest | +2–3 | §1.3; hiện chỉ 2–3 PD là quá mỏng cho quy trình Nhật |
+| Monitor / whisper / barge + security profile | +1 | §2.2 |
+| AMD tuning + test bộ mẫu tiếng Nhật | +1–2 | §2.4 |
+| セキュリティチェックシート / 委託先管理 / quy trình 開示・削除 | +1–2 | §2.10 |
+| Tài liệu và đào tạo bằng tiếng Nhật (M13 hiện 3–4 PD cho 3 guide + data dictionary + 3 buổi) | +1–2 | Toàn bộ deliverable là tiếng Nhật cho người dùng cuối Nhật |
+| **Tổng bổ sung** | **+11–17** | |
+
+**MVP đề xuất sau điều chỉnh (phương án A): 57–80 PD, baseline ~68 PD** (so với 46–63/54 hiện tại).
+
+### 3.3 Thiếu định lượng hypercare và cut-over
+
+M12 ghi "hypercare ngắn" không có số. Với call center thật, tuần đầu là lúc phát sinh nhiều nhất (audio, headset, số bị chặn, agent thao tác sai). Phải ghi rõ: ví dụ *hypercare 10 ngày làm việc, 0.5 FTE, giờ hành chính JST*, và mọi thứ ngoài đó là hợp đồng bảo trì riêng.
+
+### 3.4 Thiếu dự phòng cho việc đổi phương án caller ID
+
+Nếu khách kiên quyết giữ フリーダイヤル (phương án B/B'), scope chênh **+18–30 PD** và rủi ro tăng mạnh. Đề nghị **báo giá 2 phương án riêng biệt** thay vì một con số, và ghi rõ phương án B chỉ được cam kết sau PoC.
+
+### 3.5 Bộ dữ liệu đo transcript accuracy chưa có chủ
+
+`02` §5.3 yêu cầu ~20 cuộc gọi được người Nhật đối chiếu. Nhưng bảng vai trò chỉ có "PM/BA bilingual". Cần ghi rõ: ai annotate, mất bao lâu, tính vào PD của bên nào. Nếu là khách làm thì phải nằm trong mục dependency với deadline.
+
+### 3.6 Kế hoạch test không thể dùng lead thật
+
+Chưa có tài liệu nào nói về **test data**: gọi thử vào ai. Không được dùng danh sách lead thật để test (vừa là rủi ro pháp lý, vừa đốt lead). Cần một bộ số test do khách cung cấp (nội bộ, đủ phủ NTT landline + docomo/au/SoftBank/rakuten + máy trả lời + số sai), và bộ số đó cũng là ma trận carrier trong acceptance.
+
+### 3.7 X01 (acoustic emotion) nên tách khỏi bảng tổng
+
+Việc gộp X01 vào con số "Full core + tất cả option 215–318 PD" tuy có ghi chú nhưng vẫn tạo ấn tượng rằng nhận diện cảm xúc theo giọng nói là một hạng mục có thể mua theo giá. Đề nghị trình bày X01 như một **đề xuất PoC riêng có tiêu chí dừng**, không nằm trong bảng estimate chính.
+
+---
+
+## 4. Các điểm đã kiểm chứng là ĐÚNG (giữ nguyên)
+
+Để tránh sửa nhầm những phần đang chính xác — các khẳng định sau đã được đối chiếu lại với tài liệu AWS tại ngày review:
+
+| Khẳng định trong tài liệu | Kết quả kiểm chứng |
+|---|---|
+| `ja_JP` hỗ trợ post-call analytics, real-time call analytics, post-contact summaries, information extraction, sentiment, pattern match rules, automated performance evaluations | **Đúng**, khớp bảng supported languages |
+| `ja_JP` **không** có Redaction | **Đúng** — ô Redaction của ja_JP để trống (chỉ nhóm en/fr/de/it/es/pt có) |
+| Concurrent active calls per instance mặc định 10 | **Đúng**, adjustable, resource level |
+| Concurrent campaign active calls mặc định 0 | **Đúng**, adjustable |
+| Phải tạo instance trước khi xin tăng quota | **Đúng** |
+| Instance Tokyo chỉ gọi campaign được tới số Nhật | **Đúng** — "From instances created in Asia Pacific (Tokyo) you can call all phone numbers based in Japan"; không có tổ hợp khác |
+| Tokyo hỗ trợ Outbound Campaigns, Customer Profiles, Conversational Analytics (kể cả generative AI features), Agent Workspace, data lake | **Đúng**, đủ cả |
+| Voice ID kết thúc hỗ trợ 20/05/2026, không dùng cho thiết kế mới | **Đúng**, có notice chính thức |
+| Global Resiliency cặp Tokyo–Osaka | **Đúng**, nhưng nên ghi rõ **Osaka chỉ là region cho bản replica** |
+| Sentiment là phân tích nội dung text, không phải nhận diện cảm xúc từ chất giọng | **Đúng**, và cách diễn đạt trong tài liệu là chuẩn mực — giữ nguyên |
+| Tách "connected call có media" khỏi "mọi dial attempt" | **Đúng**, và là điểm mạnh nhất của bộ tài liệu |
+
+Bổ sung 2 con số hữu ích cho phần sizing/monitoring:
+
+- Post-call analytics job mất khoảng **40% độ dài cuộc gọi**; công thức của AWS: `(phút/cuộc) × 0.4 × (cuộc/giờ) / 60` = số job đồng thời. Quota mặc định 200 → dư sức cho 15 ghế. Con số này cũng biện minh cho SLA kiểm tra artifact 15 phút trong `02` §5.3.
+- Real-time analytics đồng thời mặc định 300.
+
+---
+
+## 5. Câu hỏi cần bổ sung vào danh sách chốt với khách
+
+Thêm vào `02` §14 (đánh số tiếp):
+
+13. **Nếu buộc phải chọn một: ưu tiên hiển thị フリーダイヤル khi gọi ra, hay ưu tiên tự động quay số theo danh sách?** (Đây là câu hỏi quan trọng nhất của toàn dự án — xem §1.1.)
+14. Có chấp nhận hiển thị số **03 (Tokyo)** khi gọi ra và giữ 0120 chỉ để nhận cuộc gọi không?
+15. Số 0120 hiện có đang ở carrier nào, hợp đồng ra sao, và có chấp nhận **port hẳn sang AWS** không (không có đường "giữ ở carrier cũ, chỉ hiển thị")? Nghiệp vụ nào đang chạy trên số đó?
+16. Doanh nghiệp đã có **đăng ký pháp nhân + địa chỉ tại vùng của area code** muốn dùng chưa? Bộ 3 hồ sơ (đăng ký DN trong 6 tháng, ID người đại diện, chứng minh địa chỉ) khi nào có thể nộp?
+17. Mục tiêu **số cuộc gọi/agent/ngày** và **tỷ lệ bắt máy kỳ vọng** là bao nhiêu? (quyết định progressive hay predictive)
+18. Có **chốt hợp đồng ngay trên điện thoại** không? Nếu có thì ai lo 契約書面の交付 và quy trình クーリング・オフ 8 ngày?
+19. **Ngân sách vận hành/tháng** cho AWS là bao nhiêu? (để chọn giữa bật analytics 100% cuộc gọi hay lấy mẫu)
+20. Danh sách **số điện thoại test** (nội bộ, phủ NTT + các nhà mạng di động) do ai cung cấp và khi nào?
+21. Ai là người bấm nút vận hành hằng ngày (import list, tạo campaign)? Người đó có dùng được **AWS console tiếng Nhật** không, hay bắt buộc phải có portal riêng?
+
+---
+
+## 6. Việc cần làm ngay
+
+Theo thứ tự ưu tiên:
+
+1. **Sửa kết luận về 0120 trong `01` §4, `02` §3/§5.1 và `README`.** Đây là sai sót có thể dẫn đến cam kết một kiến trúc không chạy được.
+2. **Mở AWS Support case ngay** với 3 câu hỏi cụ thể, bằng văn bản, trước khi báo giá:
+   - Số toll-free Nhật có thể dùng làm source number cho Outbound Campaigns không? (dự kiến: không)
+   - Tồn kho số `+81 3` khả dụng cho campaign tại `ap-northeast-1`, và điều kiện footnote (2)?
+   - Customer-first callback có dùng được caller ID toll-free và block `Check call progress` không? (phương án B')
+3. **Đổi cấu trúc báo giá thành 2 phương án** (A: DID + campaign; B: 0120 + dialer tự xây), không đưa một con số duy nhất.
+4. **Bổ sung bảng chi phí AWS/tháng** 3 kịch bản.
+5. Đưa **inbound tối thiểu vào MVP**, cập nhật estimate lên **57–80 PD (baseline ~68)** cho phương án A.
+6. Thay thanh "Number/quota 28d" trong Gantt bằng các **mốc cứng theo cửa sổ port 1/15**, và nói rõ với khách rằng 「10月後半」 chỉ khả thi nếu hồ sơ số được nộp trong tháng 9.
+7. Hỏi 9 câu bổ sung ở §5 trước khi chuyển ROM thành quotation.
+
+---
+
+## Phụ lục — nguồn đã kiểm chứng lại tại ngày review
+
+- Amazon Connect Telecoms Coverage Guide, bản in ngày **31/08/2026** — https://d1v2gagwb6hfe1.cloudfront.net/Amazon_Connect_Telecoms_Coverage.pdf (ảnh khối Japan: `evidence/japan-telecoms-coverage-2026-08-31.png`)
+- Region requirements for ordering and porting phone numbers — https://docs.aws.amazon.com/connect/latest/adminguide/phone-number-requirements.html
+- Outbound calling restrictions — https://docs.aws.amazon.com/connect/latest/adminguide/outbound-calling-restrictions.html
+- Set up outbound campaigns — https://docs.aws.amazon.com/connect/latest/adminguide/enable-outbound-campaigns.html
+- Availability of features by Region (mục Outbound campaigns) — https://docs.aws.amazon.com/connect/latest/adminguide/regions.html
+- Check call progress block (AMD) — https://docs.aws.amazon.com/connect/latest/adminguide/check-call-progress.html
+- Languages supported by features — https://docs.aws.amazon.com/connect/latest/adminguide/supported-languages.html
+- Service quotas — https://docs.aws.amazon.com/connect/latest/adminguide/amazon-connect-service-limits.html

README.md

@@ -0,0 +1,43 @@
+# Bộ tài liệu đề xuất Amazon Connect cho D2C Call Center
+
+Ngày rà soát: **03/09/2026** (bản sửa lần 2)
+Phạm vi: call center tại Nhật, 10–15 agent, chủ yếu outbound sales, có nhận cuộc gọi ở mức cơ bản.
+
+## Tài liệu
+
+| File | Nội dung | Dùng khi nào |
+|---|---|---|
+| [01-nghien-cuu-cong-nghe.md](./01-nghien-cuu-cong-nghe.md) | Kiến thức nền, khả năng và giới hạn thật của Amazon Connect tại Nhật, kèm nguồn AWS gốc | Khi cần tra cứu "cái này có làm được không" |
+| [02-giai-phap-va-estimate.md](./02-giai-phap-va-estimate.md) | Danh sách tính năng viết bằng ngôn ngữ nghiệp vụ, kiến trúc, các phương án, WBS và estimate theo person-day | **Tài liệu chính để trao đổi với khách và lập giá** |
+| [03-review.md](./03-review.md) | Review nội bộ lần 1 — đã được đánh dấu các điểm bị thay thế | Tham khảo lịch sử quyết định |
+| [04-review-doc-lap.md](./04-review-doc-lap.md) | Review độc lập lần 2, có kiểm chứng lại nguồn AWS gốc | Khi cần biết vì sao bản 2 khác bản 1 |
+| `evidence/` | Ảnh chụp bảng Japan trong Telecoms Coverage Guide 31/08/2026 | Bằng chứng cho kết luận về số điện thoại |
+
+## Kết luận ngắn
+
+**Điều quan trọng nhất, cần đưa cho khách quyết định trước mọi việc khác:**
+
+> Số フリーダイヤル 0120/0800 của Nhật **không dùng được** làm số phát cho tính năng quay số tự động theo danh sách của Amazon Connect. Chỉ số DID (`+81 3`, `+81 6`, `+81 50`) mới dùng được, và chỉ từ region Tokyo.
+>
+> Nghĩa là hai yêu cầu của khách — 「リストをもとに発信できるシステム」 và 「同じフリーダイヤルで全員が発信できる」 — **không thể đồng thời thỏa mãn** bằng tính năng có sẵn. Nhật cũng **không hỗ trợ custom caller ID**, nên không có đường giữ số ở nhà mạng cũ rồi chỉ hiển thị.
+
+Các kết luận còn lại:
+
+- **Phương án A (khuyến nghị):** gọi ra bằng một số DID dùng chung cho cả 15 agent, giữ 0120 để nhận cuộc gọi. **MVP 57–80 PD, baseline 68 PD.**
+- **Phương án B** (bắt buộc giữ 0120 để gọi ra): phải tự xây bộ quay số và **mất tính năng nhận biết máy trả lời tự động**. **MVP 75–110 PD**, và chỉ nên báo giá sau PoC.
+- Nhận cuộc gọi vào **không còn là tùy chọn**: hiển thị một số chung khi gọi ra thì chắc chắn có khách gọi lại.
+- Tiếng Nhật `ja_JP` hỗ trợ đầy đủ chuyển hội thoại thành văn bản, phân tích sau cuộc gọi, phân tích thời gian thực, tóm tắt và sắc thái. **Che thông tin cá nhân tự động thì chưa hỗ trợ.**
+- "Cảm xúc" ở mức có sẵn là sắc thái suy ra từ nội dung lời nói, kết hợp độ to giọng, im lặng và nói chen — không phải bộ nhận dạng cảm xúc từ chất giọng.
+- Hai hạn mức mặc định gây chặn là số cuộc gọi đồng thời (mặc định 10) và số cuộc gọi đồng thời của chiến dịch (mặc định 0). Phải tạo instance và xin tăng sớm; **yêu cầu lớn có thể mất tới 3 tuần**.
+- **Lịch số điện thoại là ràng buộc cứng:** cửa sổ chuyển số của Nhật thường là ngày 1 và ngày 15 của tháng kế tiếp, và hồ sơ pháp nhân phải chuẩn bị từ tuần đầu. Mốc 「10月後半」 chỉ khả thi nếu hồ sơ được nộp trong tháng 9.
+
+## Cách dùng khi trao đổi với khách hàng
+
+- Mở đầu bằng **câu hỏi lựa chọn Phương án A hay B** (`02` §13 câu 1–4). Mọi con số đều phụ thuộc câu trả lời này.
+- Dùng bảng tính năng ở `02` §2 để trao đổi — bảng đó cố ý viết bằng ngôn ngữ nghiệp vụ, cột "Hệ thống làm gì" có thể đọc trực tiếp cho khách nghe, và cột "Cách làm" cho biết ngay tính năng nào là **bật sẵn của AWS** (⚙️) và tính năng nào **phải tự viết** (💻).
+- Khi khách hỏi "tiền đi vào đâu", dùng `02` §2.4 và §7.1: trong MVP chỉ khoảng **15% khối lượng là code tự viết**, tập trung vào bốn chỗ Amazon Connect không có sẵn (ghi kết quả cuộc gọi, danh sách không gọi, hẹn gọi lại, đối soát dữ liệu).
+- Dùng bảng truy vết yêu cầu ở `02` §3 để xác nhận phạm vi và cách nghiệm thu.
+- Đưa **bảng chi phí vận hành ba kịch bản** ở `01` §12 để khách sửa trực tiếp các giả định — mục đích là lấy được số liệu thật, không phải cam kết chi phí.
+- Báo giá **hai phương án tách bạch**, theo cận trên của range, cộng dự phòng thương mại 10% nếu hợp đồng fixed-price.
+- Không cam kết ngày mở dịch vụ cho đến khi AWS xác nhận số điện thoại, quyền gọi ra và hạn mức.
+- Không mô tả sắc thái và độ to giọng là "AI đọc chính xác cảm xúc qua giọng nói"; phải thống nhất định nghĩa và cách đo trước khi ký.