# 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