Gỡ Rối 3 Bài Toán Thực Chiến “Ám Ảnh” Mọi BA/PO Ngành Viễn Thông

Bài viết được chia sẻ từ chuyên gia Business Analyst

Viễn thông là một trong những domain “khó nhằn” nhất mà tôi từng làm, không phải vì kỹ thuật quá cao siêu, mà vì hệ thống chồng chéo, dữ liệu khổng lồ, quy trình phức tạp và tác động trực tiếp đến doanh thu. BA/PO viễn thông không chỉ “viết tài liệu”, mà giải quyết các bài toán sống còn của hệ thống, vận hành và trải nghiệm khách hàng.

Dưới đây là ba bài toán điển hình tôi từng trực tiếp xử lý, cùng cách tiếp cận thực tế ở góc nhìn BA/PO senior.

Đồng bộ gói cước giữa CRM ↔ Billing để tránh thất thoát doanh thu

Trong hầu hết các telco, CRM là nơi hiển thị thông tin gói cước cho CSKH, còn Billing là hệ thống tính tiền thực tế. Vấn đề nằm ở chỗ hai hệ thống này không phải lúc nào cũng “nói cùng một ngôn ngữ”.

Vấn đề thực tế

Ở một telco, CRM là nơi CSKH nhìn thấy thông tin gói cước, còn Billing là hệ thống thu tiền thực sự.
Nghe thì đơn giản: CRM hiển thị gì thì Billing phải thu đúng như thế.

Nhưng đời không như mơ.
Một ngày đẹp trời, CS báo khách khiếu nại:
“Sao hệ thống báo tôi đang dùng gói 5GB, mà app lại ghi 7GB?”

Điều tra ra mới thấy: CRM cập nhật theo hệ thống Promotion engine, còn Billing lại tính theo một bảng mapping cũ chưa update.

Chỉ 20 khách báo lỗi trong 1 buổi sáng, mà bên tài chính đã giật mình:
“Chết, nếu lệch như vậy trên 200k khách đang dùng gói này thì sao?”

Cách tôi xử lý – Góc nhìn Senior BA

Bước 1 – Mapping toàn bộ data flow

Tôi mở ngay một task data lineage:

• CRM → Integration Layer → Billing 
• Billing → Data Warehouse → App 
• Promotion Engine ↔ CRM 
• Billing ↔ Charging Gateway 

Tôi dùng draw.io để vẽ full luồng, highlight các điểm:

• Nơi sinh ra dữ liệu gói cước 
• Nơi transform 
• Nơi hiển thị 
• Nơi tính tiền 

90% lỗi trong viễn thông nằm ở chỗ không ai biết dữ liệu gốc nằm ở đâu.

Bước 2 – So sánh rule giữa CRM vs Billing

Tôi làm 1 bảng Excel:

Rồi họp với:

• team sản phẩm gói cước 
• team billing 
• team DWH
  

Bước 3 – Xuống đúng nguyên nhân

Đa số bạn BA mới ngồi phỏng đoán số liệu.
Tôi thì lấy sample data trực tiếp từ Billing để xem đối chiếu.
Cuối cùng phát hiện do Promotion engine push rule sai format.

Kết quả

• Fix trong 3 ngày 
• Dùng SQL để validate 200k thuê bao 
• Báo cáo CFO yên tâm vì không thất thoát doanh thu 
• Tạo checklist chuẩn hóa mapping gói cước cho toàn công ty 

Tối ưu quy trình eSIM để tăng conversion và giảm khiếu nại

eSIM là sản phẩm chiến lược của nhiều telco, nhưng cũng là nơi phát sinh rất nhiều vấn đề nếu quy trình không được thiết kế đúng từ đầu.

Vấn đề thực tế

Khi telco bắt đầu push eSIM, mọi thứ quá… rối:

1. Khách quét QR → lỗi 
2. App báo invalid code 
3. CS gọi lên tổng đài không biết khách đang ở bước nào 
4. Billing lại chưa ghi nhận profile eSIM vừa kích hoạt
   

Conversion rate chỉ khoảng 42%, thấp kinh khủng.

Tôi xử lý sao?

Bước 1 – Shadowing quy trình thật

Tôi ra cửa hàng flagship, đứng quan sát 2 tiếng xem CS bán eSIM cho khách thế nào.

Ghi lại 7 điểm nghẽn:

• Khách lớn tuổi không biết quét QR 
• App yêu cầu đăng nhập quá nhiều bước 
• SMS OTP đôi khi delay 
• eSIM profile chưa sync với HLR ngay lập tức 
• App không hiển thị trạng thái “đang kích hoạt” 
• CS không nhìn thấy luồng kích hoạt trên CRM 
• Hệ thống chưa log đầy đủ từng bước 

Bước 2 – Redesign user flow

Tôi vẽ lại flow eSIM từ đầu đến cuối:

App → Identity Verification → Purchase → Generate QR → Activate on device → Sync HLR/HSS → Billing charge

Sau đó đánh số từng trạng thái:

• Step 1: QR generated 
• Step 2: Device scanned 
• Step 3: HLR activated 
• Step 4: Billing OK 

BTLs như Apple/Android có hàng chục edge cases, tôi phải viết thêm:

• Error Code 101 – QR expired 
• Error Code 203 – Device not supported 
• Error Code 501 – HLR pending 

Bước 3 – Đề xuất cải tiến

• Giảm 3 bước login thành 1 
• Hiển thị tiến trình kích hoạt theo thời gian thực 
• Sync trạng thái eSIM sang CRM 
• Thêm retry logic nếu HLR pending quá 20 giây 
• Bổ sung analytics để đo drop-off 

Kết quả

2 tháng sau:

• Conversion tăng từ 42% → 76% 
• Số ticket khiếu nại giảm 60% 
• Thời gian kích hoạt từ 3 phút → còn 40 giây 
• CS khen “dễ tư vấn hơn hẳn” 

Quản lý thuê bao đa SIM và đa dịch vụ trong hệ sinh thái phức tạp

Một khách hàng viễn thông hiện đại có thể dùng nhiều SIM, nhiều dịch vụ và nhiều thiết bị cùng lúc. Nếu không có mô hình dữ liệu thống nhất, hệ thống backend sẽ nhanh chóng trở thành “mớ spaghetti”.

Vấn đề thực tế

Một khách dùng:

• 1 SIM chính (data) 
• 1 SIM phụ (voice) 
• 1 eSIM cho smartwatch 
• 1 gói gia đình 4 người 

Backend telco nhìn như một mớ spaghetti:

• Mỗi SIM 1 profile 
• Mỗi service 1 bảng trong DB 
• Billing thu theo cycle khác nhau 
• App hiển thị lệch thông tin giữa các service 

Khách chỉ cần hỏi một câu:
“Dữ liệu gia đình còn bao nhiêu?”
→ CS không trả lời được.

Cách tôi làm

1. Gom toàn bộ logic dịch vụ vào 1 mô hình thống nhất

Tôi thiết kế Unified Subscription Model, gồm:

• Subscriber 
• Account 
• Service 
• Add-on 
• Device 
• Billing cycle
  

Tất cả nằm trên 1 schema duy nhất.

2. Viết rule chuẩn để dịch vụ con ăn theo dịch vụ cha

Ví dụ:

• Gói Family 200GB 
• 5 thành viên → mỗi người max 40GB 
• Cha mẹ được xem usage tổng 
• Con cái chỉ thấy usage cá nhân 

Những rule như:

IF parent-package, THEN sync child usage cap = package_total / member_count

3. Làm API consolidation cho App + CRM

Trước đó App phải gọi 5 API mới thấy đúng usage.
Tôi gom lại thành 1 API duy nhất:

GET /subscription/usage?subscriberId=xxxx

Backend tự tổng hợp, trả về đúng format:

{

  totalData: 200,

  used: 134.5,

  remaining: 65.5,

  members: [...]

}

4. Build dashboard cho CS

CRM có màn hình:

• Tổng dung lượng 
• Dung lượng từng thành viên 
• Log chia sẻ gói 
• Thời điểm phát sinh bất thường 

Kết quả

• App hiển thị chính xác 98% usage 
• CS giải đáp nhanh hơn 40% 
• Khiếu nại giảm mạnh 
• DWH có dữ liệu sạch để làm predictive analytics 

Bài học xương máu cho BA/PO làm viễn thông

Data luôn là trung tâm của mọi quyết định

Telco là ngành vẫn chạy nhờ data pipelines.
Không hiểu data → không làm được gì.

Luồng hệ thống phức tạp buộc BA phải đọc log

Gói cước chạy qua:
CRM → Charging → Billing → DWH → App
Bạn không đọc log thì không bao giờ đoán đúng lỗi.

Giá trị của BA nằm ở tác động kinh doanh

Thứ doanh nghiệp muốn là tránh mất tiền & tăng trải nghiệm khách.

Đi thực tế quan trọng hơn mọi sơ đồ đẹp

Đừng ngồi phòng lạnh đoán flow.
Ra cửa hàng, nghe khách chửi 10 phút là hiểu vấn đề liền.

Legacy không phải kẻ thù

Telco sống nhờ 20 năm hệ thống cũ.
Bạn phải học cách kéo hệ thống cũ vào flow mới mà không làm nó sập.