Mở đầu — vì sao bài này quan trọng
Nếu bạn từng làm Customer Service, có một điều gần như chắc chắn: bạn đã "chạm" vào dữ liệu nhiều hơn bạn nghĩ. Mỗi lần bạn kéo báo cáo ticket volume theo tuần, mỗi lần bạn xem con số CSAT tụt sau đợt cao điểm, mỗi lần bạn lọc danh sách khách hàng phàn nàn về một tính năng cụ thể — bạn đang làm một phiên bản thô sơ của phân tích dữ liệu. Vấn đề là hồi làm CS, bạn phụ thuộc vào giao diện có sẵn của Zendesk, Freshdesk hay Intercom: bấm nút, chọn filter, xuất Excel. Còn khi bước sang vai trò BA (Business Analyst), bạn sẽ đối mặt với những câu hỏi mà không giao diện dựng sẵn nào trả lời được — và lúc đó, SQL trở thành ngôn ngữ giúp bạn tự đi lấy câu trả lời.
Đây chính là điểm mà rất nhiều ex-CS đánh giá thấp bản thân. Họ nghĩ "tôi không phải dân kỹ thuật, SQL chắc khó lắm". Thực tế ngược lại: nền tảng CS cho bạn một lợi thế mà dân IT thuần túy phải mất nhiều tháng mới có được — bạn hiểu dữ liệu đó có ý nghĩa gì đối với khách hàng và với business. Một câu truy vấn SQL với bạn không phải là bài toán trừu tượng, mà là câu hỏi rất cụ thể: "Có bao nhiêu khách hàng mở lại ticket trong vòng 48 giờ sau khi được đánh dấu đã giải quyết?"
Bài này tập trung vào đúng một việc: giúp bạn — người xuất thân CS — biến kỹ năng đọc dữ liệu vận hành thành kỹ năng viết SQL để tạo ra insight mà một BA cần. Chúng ta sẽ không biến bạn thành Data Engineer. Chúng ta biến bạn thành một BA biết tự trả lời câu hỏi của mình bằng dữ liệu.
Khái niệm cốt lõi
Vì sao ex-CS có lợi thế đặc biệt khi học SQL
Ba lý do khiến bạn đi nhanh hơn người khác:
Thứ nhất, bạn đã quen với mô hình dữ liệu của CRM. Zendesk, Freshdesk, Intercom về bản chất đều là các bảng: một bảng tickets, một bảng customers (hoặc users), một bảng agents, một bảng conversations hoặc comments. Khi bạn từng lọc "ticket của khách hàng VIP, thuộc nhóm Billing, trạng thái Open" — bạn đã tư duy đúng theo kiểu bảng và điều kiện lọc. SQL chỉ là cách viết lại tư duy đó bằng cú pháp.
Thứ hai, bạn đã quen với các chỉ số vận hành. Ticket volume, CSAT (Customer Satisfaction), FCR (First Contact Resolution), AHT (Average Handle Time), backlog, reopen rate... Đây là những khái niệm business, không phải kỹ thuật. Một BA giỏi là người biến câu hỏi business thành truy vấn dữ liệu. Bạn đã có sẵn "vế business" — thứ khó dạy nhất.
Thứ ba, bạn có trực giác về "số này đúng hay sai". Khi một query trả về "CSAT trung bình 4.8/5 trong tháng có nhiều phàn nàn", bạn sẽ ngờ ngợ rằng có gì đó sai — có thể do chỉ tính những khách đã trả lời survey. Trực giác này cực kỳ quý; dân kỹ thuật thuần thường thiếu nó.
SQL tối thiểu một ex-CS BA cần nắm
Bạn không cần học hết SQL. Bạn cần vững khoảng bảy mảnh ghép sau, và chúng đủ cho 80% công việc BA hằng ngày:
- SELECT ... FROM ...: chọn cột nào, từ bảng nào. Tương đương "hiển thị cột nào trong report".
- WHERE: lọc điều kiện. Tương đương filter trong Zendesk ("status = open", "channel = email").
- ORDER BY: sắp xếp. Tương đương sort theo ngày tạo, theo mức độ ưu tiên.
- GROUP BY + hàm tổng hợp (COUNT, SUM, AVG, MIN, MAX): gom nhóm và đếm/tính trung bình. Đây là trái tim của mọi báo cáo — "đếm số ticket theo từng category".
- HAVING: lọc sau khi đã gom nhóm ("chỉ hiện category có trên 100 ticket").
- JOIN: nối hai bảng lại. Ví dụ nối
ticketsvớicustomersđể biết ticket này thuộc khách hàng thuộc gói nào. - Hàm ngày tháng và CASE WHEN: tính khoảng thời gian (resolution time), phân loại theo điều kiện.
Từ "report vận hành" sang "insight cho BA"
Đây là khác biệt cốt lõi cần khắc sâu. Report vận hành trả lời câu hỏi cái gì đã xảy ra: "Tháng 5 có 12.400 ticket". Insight của BA trả lời câu hỏi tại sao và nên làm gì: "37% ticket tháng 5 xoay quanh lỗi thanh toán qua VNPay, tập trung ở khách hàng dùng app phiên bản cũ — đề xuất ưu tiên fix flow thanh toán trong sprint tới".
SQL là cây cầu nối hai thế giới. Bạn dùng nó để bóc tách con số tổng thành các lát cắt (segment, thời gian, kênh, hành vi), rồi từ các lát cắt đó rút ra khuyến nghị. Một BA không chỉ đưa số — BA đưa câu chuyện có bằng chứng.
Tình huống thực tế
Ví dụ 1 — Tiki: từ "backlog đang cao" sang "chốt được yêu cầu sản phẩm"
Giả định bạn là ex-CS Lead vừa chuyển sang BA tại một sàn thương mại điện tử như Tiki. Product Owner nói mơ hồ: "Team CS phàn nàn backlog cao, xem giúp có phải cần thêm người không." Nếu chỉ nhìn giao diện Freshdesk, bạn chỉ thấy con số tổng backlog 3.200 ticket. Nhưng bạn viết một query gom nhóm theo category và created_week:
SELECT category, COUNT(*) AS so_ticket
FROM tickets
WHERE created_at >= '2026-05-01'
GROUP BY category
ORDER BY so_ticket DESC;
Kết quả: 44% backlog nằm ở category "Hoàn tiền / hủy đơn", và hầu hết đều là khách hỏi lại "đơn của tôi hoàn tiền tới đâu rồi". Bạn đào sâu thêm, JOIN với bảng orders và phát hiện những đơn này đều có trạng thái "Đang xử lý hoàn tiền" quá 5 ngày.
Insight bạn mang ra họp: vấn đề không phải thiếu người CS, mà là quy trình hoàn tiền chậm khiến khách hỏi đi hỏi lại, tạo ra ticket "rác" chiếm gần một nửa backlog. Bài học: dữ liệu giúp bạn phản bác một giả định sai ("thuê thêm người") và định hình một yêu cầu sản phẩm thật (làm màn hình tra cứu trạng thái hoàn tiền self-service). Đây chính là lúc bạn tạo giá trị vượt xa một CS thuần.
Ví dụ 2 — MoMo: đo reopen rate để chứng minh chất lượng giải quyết
Giả định bạn làm BA tại một ví điện tử như MoMo. Đội quản lý tự hào FCR đạt 89%. Nhưng bạn nghi ngờ, vì hồi làm CS bạn biết agent hay bấm "resolved" để đóng số cho đẹp. Bạn viết query đo tỷ lệ ticket được mở lại trong 72 giờ:
SELECT
COUNT(CASE WHEN reopened_at IS NOT NULL
AND reopened_at <= DATE_ADD(resolved_at, INTERVAL 3 DAY)
THEN 1 END) 100.0 / COUNT() AS reopen_rate_pct
FROM tickets
WHERE resolved_at >= '2026-06-01';
Kết quả: reopen rate là 21%. Nghĩa là cứ 5 ticket "đã giải quyết" thì 1 quay lại. FCR 89% là con số ảo. Bạn phân tách tiếp theo nhóm vấn đề và thấy reopen tập trung ở "chuyển tiền lỗi nhưng bị trừ số dư". Bài học: một chỉ số đẹp có thể che giấu vấn đề thật. Với trực giác CS cộng SQL, bạn phát hiện được điều mà báo cáo mặc định của hệ thống không bao giờ chỉ ra, và biến nó thành yêu cầu điều tra root cause cho team kỹ thuật.
Ví dụ 3 — chuỗi bán lẻ dùng Zendesk: phân khúc khách để ưu tiên tính năng
Giả định bạn là BA tại một chuỗi bán lẻ dùng Zendesk. Team sản phẩm muốn biết nên xây tính năng self-service cho nhóm khách nào trước. Bạn JOIN bảng tickets với bảng customers (có cột segment: Regular / Premium):
SELECT c.segment,
COUNT(t.id) AS so_ticket,
AVG(t.satisfaction_score) AS csat_tb
FROM tickets t
JOIN customers c ON t.customer_id = c.id
WHERE t.created_at >= '2026-04-01'
GROUP BY c.segment;
Kết quả: nhóm Premium chỉ chiếm 12% tổng khách nhưng tạo ra 38% ticket, và CSAT của họ lại thấp nhất (3.6/5). Bài học: đây là nhóm tạo doanh thu cao nhưng đang bức xúc nhất — ưu tiên làm self-service và cải thiện trải nghiệm cho họ có ROI cao nhất. Một quyết định sản phẩm được chống lưng bằng dữ liệu segment, thay vì cảm tính. Chính khả năng "cắt lát" dữ liệu theo góc nhìn khách hàng là thứ ex-CS làm giỏi hơn ai hết.
Hướng dẫn từng bước
Đây là quy trình sáu bước để biến một câu hỏi mơ hồ thành insight bằng SQL:
Bước 1 — Dịch câu hỏi business thành câu hỏi dữ liệu. Khi ai đó nói "CSAT đang giảm", hãy hỏi lại: giảm ở kênh nào, nhóm khách nào, so với kỳ nào? Viết ra câu hỏi cụ thể: "So sánh CSAT trung bình theo kênh (email, chat, hotline) giữa tháng 5 và tháng 6."
Bước 2 — Xác định bảng và cột cần dùng. Bạn cần bảng nào? Có cần JOIN không? Với câu trên: bảng tickets, cột channel, satisfaction_score, created_at. Chưa cần JOIN.
Bước 3 — Viết truy vấn từ đơn giản đến phức tạp. Đừng viết câu hoàn chỉnh ngay. Bắt đầu bằng SELECT * FROM tickets LIMIT 10 để nhìn dữ liệu thật. Rồi thêm WHERE, rồi thêm GROUP BY. Xây dần từng lớp.
Bước 4 — Kiểm tra tính hợp lý (sanity check). Query trả 4.9/5 nhưng có nhiều phàn nàn? Nghi ngờ ngay. Kiểm tra xem có phải chỉ tính ticket có survey không (WHERE satisfaction_score IS NOT NULL vô tình làm sai lệch mẫu). Đây là bước ex-CS mạnh nhất.
Bước 5 — Cắt lát để tìm nguyên nhân. Con số tổng ít giá trị. Hãy GROUP BY theo thời gian, kênh, category, segment. Insight nằm ở sự chênh lệch giữa các lát cắt.
Bước 6 — Chuyển thành câu chuyện và khuyến nghị. Đừng dừng ở bảng số. Viết một câu: "Phát hiện X, do Y, đề xuất Z." Đó mới là sản phẩm của BA.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm giữa COUNT() và COUNT(cột). COUNT() đếm mọi dòng; COUNT(satisfaction_score) chỉ đếm dòng có giá trị (bỏ qua NULL). Nhiều ex-CS tính "tỷ lệ hài lòng" mà quên rằng phần lớn khách không điền survey, dẫn tới mẫu thiên lệch nghiêm trọng.
Lỗi 2 — Quên rằng JOIN có thể nhân đôi dòng. Khi nối tickets với comments (một ticket nhiều comment), COUNT ticket sẽ bị thổi phồng. Mẹo: luôn kiểm tra số dòng trước và sau JOIN.
Lỗi 3 — Lọc bằng WHERE trên hàm tổng hợp. Muốn "category có trên 100 ticket" thì phải dùng HAVING, không phải WHERE. WHERE chạy trước khi gom nhóm, HAVING chạy sau.
Lỗi 4 — So sánh ngày sai vì kiểu dữ liệu. created_at thường là datetime. WHERE created_at = '2026-06-01' sẽ bỏ sót cả ngày vì giờ khác 00:00:00. Dùng khoảng >= '2026-06-01' AND < '2026-06-02'.
Mẹo vàng: Luôn dùng LIMIT khi khám phá dữ liệu mới để không kéo hàng triệu dòng. Đặt tên cột kết quả bằng tiếng Việt không dấu hoặc tiếng Anh rõ nghĩa (AS reopen_rate) để báo cáo dễ đọc. Và khi bí, hãy dùng AI để giải thích query — nhưng luôn tự sanity-check kết quả bằng trực giác CS của bạn.
Bài tập thực hành
Hãy tưởng tượng bạn có một bảng tickets với các cột: id, customer_id, channel, category, status, satisfaction_score, created_at, resolved_at, reopened_at. Viết SQL (hoặc mô tả logic nếu chưa có công cụ chạy) cho các yêu cầu sau:
- Đếm số ticket theo từng
channeltrong tháng 6/2026, sắp xếp giảm dần. - Tính CSAT trung bình theo
category, chỉ lấy category có từ 50 ticket trở lên (gợi ý: dùng HAVING). - Tìm 10 khách hàng tạo nhiều ticket nhất trong quý 2/2026.
- Tính thời gian giải quyết trung bình (resolved_at − created_at) theo từng
category(gợi ý: dùng hàm chênh lệch thời gian như TIMESTAMPDIFF). - Thử thách: Viết một đoạn insight 3–4 câu dựa trên kết quả tưởng tượng của câu 2 và 4 — trong đó nêu phát hiện, nguyên nhân giả định, và một khuyến nghị sản phẩm cụ thể. Đây là bước biến bạn từ người viết query thành một BA thực thụ.
Tóm tắt
Nền tảng Customer Service không phải là điểm yếu khi học SQL — nó là bệ phóng. Bạn đã quen với mô hình dữ liệu của CRM, đã hiểu các chỉ số vận hành như CSAT, FCR, reopen rate, và quan trọng nhất là có trực giác về việc "con số này đúng hay đáng ngờ". SQL chỉ là công cụ giúp bạn tự trả lời những câu hỏi mà giao diện dựng sẵn của Zendesk hay Freshdesk không trả lời được.
Hãy nắm chắc bảy mảnh cốt lõi: SELECT, WHERE, ORDER BY, GROUP BY với hàm tổng hợp, HAVING, JOIN, và xử lý ngày tháng cùng CASE WHEN. Với chúng, bạn đủ sức bóc tách backlog thành yêu cầu sản phẩm (như ví dụ Tiki), lật tẩy một chỉ số đẹp nhưng ảo (như reopen rate ở MoMo), hay phân khúc khách để ưu tiên tính năng đúng chỗ (như chuỗi bán lẻ dùng Zendesk).
Điều phân biệt một BA với một người chỉ biết chạy report là gì? BA không dừng ở con số — họ biến con số thành câu chuyện có bằng chứng và khuyến nghị hành động. SQL là cây cầu, còn góc nhìn khách hàng bạn tích lũy từ những năm làm CS chính là thứ khiến câu chuyện đó thuyết phục. Hãy luyện tập đều đặn, luôn sanity-check, và tự tin rằng bạn đang đứng trên một lợi thế mà ít người chuyển ngành nào có được.