Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là nhà tuyển dụng, trên bàn có hai hồ sơ ứng viên BA fresher. Cả hai đều viết "thành thạo viết user story", "hiểu về quy trình nghiệp vụ", "kỹ năng phân tích tốt". Một người chỉ có bằng đó — những dòng chữ tuyên bố. Người kia đính kèm một link: một BRD hoàn chỉnh, một bộ user story có acceptance criteria, một process map so sánh "as-is" và "to-be", tất cả xoay quanh việc giảm 30% ticket lặp lại cho một hệ thống chăm sóc khách hàng. Bạn gọi ai đi phỏng vấn trước?
Đây chính là lý do bài học này quan trọng đến vậy. CV chỉ tuyên bố năng lực, còn portfolio là bằng chứng. Với một người chuyển nghề từ Customer Service (CS) sang Business Analyst (BA), bạn đang ở vị thế "fresher" trong mắt thị trường BA — dù bạn có 3-5 năm kinh nghiệm làm việc thực tế. Điều khiến một BA fresher nổi bật hơn một BA fresher khác không phải là điểm số, mà là project tự làm — thứ chứng minh bạn không chỉ học lý thuyết mà đã thực sự làm ra được sản phẩm của một BA.
Và đây là tin tốt dành riêng cho bạn: người từ nền CS có một lợi thế mà BA fresher "học chay" từ ngành khác không bao giờ có được — bạn đã sống trong lòng khách hàng, bạn có dữ liệu ticket thật, bạn hiểu nỗi đau người dùng ở mức chi tiết. Portfolio của bạn không cần bịa ra một bối cảnh giả tưởng; bạn có thể "khai thác mỏ vàng" từ chính công việc CS cũ. Đó gọi là CS-leverage — tận dụng nền tảng CS để tạo ra portfolio thuyết phục gấp bội. Bài học hôm nay sẽ chỉ cho bạn cách biến những gì bạn đã trải qua ở tổng đài, ở hộp thư hỗ trợ, ở hệ thống ticket thành những dự án portfolio khiến nhà tuyển dụng phải chú ý.
Khái niệm cốt lõi
Portfolio BA thực chất là gì
Nhiều người mới nghĩ portfolio BA giống portfolio thiết kế — phải đẹp, phải nhiều màu. Không phải. Portfolio BA là bộ sưu tập các sản phẩm công việc (deliverables) thể hiện tư duy phân tích của bạn qua một tình huống nghiệp vụ có thật hoặc giả định hợp lý. Nhà tuyển dụng không chấm bạn ở độ đẹp, họ chấm ở logic: bạn nhìn ra vấn đề gì, bạn đặt câu hỏi gì, bạn đề xuất giải pháp ra sao, và bạn diễn đạt nó có rõ ràng không.
Một portfolio project BA điển hình thường gồm các thành phần: mô tả bối cảnh và vấn đề (problem statement), phân tích stakeholder, quy trình hiện tại (as-is process), quy trình đề xuất (to-be process), yêu cầu (requirements — dưới dạng user story hoặc functional requirement), và đo lường thành công (success metrics). Bạn không cần có đủ tất cả trong mọi project, nhưng càng đi sâu vào chuỗi "vấn đề → phân tích → giải pháp → đo lường" thì project càng có sức nặng.
Vì sao CS-leverage là "vũ khí bí mật"
Khi một BA fresher xuất thân từ ngành tài chính làm portfolio, họ thường phải tưởng tượng ra vấn đề — và người có kinh nghiệm nhìn vào biết ngay là "đồ trong sách". Còn bạn, người từ CS, có ba thứ mà tiền không mua được:
Thứ nhất — nỗi đau thật. Bạn biết chính xác khách hàng bực bội ở đâu, vì bạn từng nghe họ hét vào tai qua điện thoại. Cái "pain point" trong portfolio của bạn là thật, không phải suy diễn.
Thứ hai — dữ liệu thật. Ticket, thời gian xử lý, tỷ lệ khách quay lại phàn nàn, top 10 lý do liên hệ... Đây là kho vàng để bạn phân tích. (Lưu ý: khi đưa vào portfolio, luôn ẩn danh và tổng hợp dữ liệu, không để lộ thông tin nhạy cảm của công ty cũ — sẽ bàn kỹ ở phần lỗi thường gặp.)
Thứ ba — góc nhìn end-user. BA hay bị chê là "xa rời người dùng cuối". Bạn thì ngược lại, bạn là tiếng nói của người dùng. Đó là điểm khác biệt cực mạnh trong câu chuyện portfolio.
Ba dạng project CS-leverage nên chọn
Không phải project nào cũng phù hợp. Với nền CS, có ba dạng "trúng tủ" nhất:
Dạng 1 — Self-service / Deflection project: Phân tích top các lý do khách liên hệ, rồi đề xuất một tính năng tự phục vụ (FAQ động, chatbot, trang tra cứu đơn hàng) để giảm khối lượng ticket. Đây là dạng thể hiện tư duy "giảm chi phí vận hành" — thứ mà mọi doanh nghiệp đều thích.
Dạng 2 — Process improvement project: Lấy một quy trình xử lý ticket rườm rà mà bạn từng khổ sở, vẽ lại as-is, chỉ ra điểm nghẽn, rồi thiết kế to-be. Dạng này thể hiện năng lực phân tích quy trình — cực kỳ core với BA.
Dạng 3 — Feature / Product enhancement project: Từ feedback khách hàng, đề xuất một tính năng mới cho sản phẩm và viết đầy đủ requirement cho nó. Dạng này gần với BA làm product nhất.
Tình huống thực tế
Ví dụ 1 — Chị Ngọc và dự án "giảm ticket đổi trả" cho một sàn TMĐT
Chị Ngọc làm CS agent 3 năm tại một sàn thương mại điện tử tầm trung ở TP.HCM (giả định gọi là ShopViet), chuyên xử lý khiếu nại đổi trả hàng. Khi muốn chuyển sang BA, chị không có bất kỳ deliverable BA nào để khoe. Mentor gợi ý chị làm một portfolio project từ chính nỗi đau chị thuộc nằm lòng.
Chị bắt đầu bằng cách tổng hợp (ẩn danh) khoảng 500 ticket đổi trả trong 3 tháng gần nhất, phân loại thành 6 nhóm lý do. Chị phát hiện: 42% ticket là "khách không biết chính sách đổi trả rõ ràng nên gửi hàng sai cách", dẫn đến vòng lặp qua lại 3-4 lượt trao đổi mỗi ca. Chị viết một problem statement gọn: "Chính sách đổi trả không hiển thị đúng ngữ cảnh khiến 42% ticket phát sinh do khách thao tác sai, tăng thời gian xử lý trung bình từ 8 lên 21 phút/ca."
Từ đó, chị vẽ as-is process (khách gửi yêu cầu → CS trả lời → khách gửi thiếu chứng từ → CS nhắc lại → ...), rồi to-be process với một "return wizard" — luồng hướng dẫn đổi trả từng bước ngay trên app. Chị viết 8 user story kèm acceptance criteria cho tính năng này, và đặt success metric: giảm 30% ticket đổi trả trong 2 quý.
Bài học rút ra: Chị Ngọc không cần công ty cho phép làm dự án thật. Chị chỉ cần lấy hiểu biết của mình về vấn đề, tổng hợp dữ liệu ẩn danh, và tự thiết kế giải pháp trên giấy. Khi phỏng vấn ở một fintech, chị được hỏi sâu về project này suốt 20 phút — và trúng tuyển. Nhà tuyển dụng nói với chị: "Em nói về pain point như người trong cuộc, không như người đọc case study."
Ví dụ 2 — Anh Tuấn và "chatbot deflection" cho ngân hàng
Anh Tuấn từng làm tổng đài viên tại trung tâm chăm sóc khách hàng của một ngân hàng (giả định Bank ABC), 4 năm trả lời câu hỏi về thẻ tín dụng. Anh chọn dạng project self-service. Điểm thông minh: thay vì bịa số, anh dùng kiến thức thật rằng khoảng 60% cuộc gọi anh nhận là 5 câu hỏi lặp đi lặp lại — "sao thẻ bị khóa", "phí thường niên bao nhiêu", "cách kích hoạt thẻ"...
Anh làm một mini requirement document cho chatbot deflection: xác định 20 intent phổ biến nhất (dựa trên trải nghiệm thật), thiết kế conversation flow cho top 5 intent, viết business rule ("nếu khách hỏi về khóa thẻ và đã xác thực OTP → hiển thị hướng dẫn mở khóa; nếu chưa xác thực → chuyển agent"), và ước lượng khả năng deflect 35% cuộc gọi. Anh còn thêm một phần rủi ro tuân thủ: các câu hỏi liên quan thông tin tài khoản phải bắt buộc xác thực — thể hiện anh hiểu bối cảnh ngành ngân hàng nhạy cảm.
Bài học rút ra: Anh Tuấn biến "kinh nghiệm lặp lại nhàm chán" thành lợi thế phân tích. Sự am hiểu domain (ngân hàng) cộng với góc nhìn CS khiến portfolio của anh trở nên "chuyên ngành" chứ không chung chung. Anh nhắm đúng các vị trí BA trong ngành fintech/banking và không phải cạnh tranh với đám đông fresher học chay.
Ví dụ 3 — Sai lầm của bạn Linh: portfolio "đẹp mà rỗng"
Bạn Linh, sau 2 năm CS ở một startup SaaS, làm một portfolio rất công phu về mặt hình thức — nhiều wireframe màu mè, slide đẹp. Nhưng khi phỏng vấn, nhà tuyển dụng hỏi: "Vấn đề gốc em giải quyết là gì? Em dựa vào dữ liệu nào?" thì Linh lúng túng. Hóa ra bạn nhảy thẳng vào giải pháp (vẽ giao diện) mà không có bước phân tích vấn đề, không có problem statement, không có metric.
Sau khi được góp ý, Linh làm lại: quay về khai thác dữ liệu ticket onboarding (top lý do khách rời bỏ trong 7 ngày đầu), xây dựng phân tích user journey, rồi mới đề xuất cải tiến. Lần phỏng vấn sau, bạn tự tin hẳn.
Bài học rút ra: Portfolio BA không chấm ở hình thức mà ở chuỗi lập luận. Đẹp mà rỗng thua xấu mà chặt. Đừng để mình rơi vào bẫy "làm cho đẹp mắt".
Hướng dẫn từng bước
Dưới đây là quy trình 7 bước để bạn xây một portfolio project CS-leverage từ con số không.
Bước 1 — Chọn một "nỗi đau" bạn thuộc nhất. Đừng chọn vấn đề nghe kêu; chọn vấn đề bạn từng xử lý hàng trăm lần và biết mọi ngóc ngách. Ví dụ: "khách hỏi trạng thái đơn hàng liên tục", "quy trình hoàn tiền chậm", "khách không tìm thấy hóa đơn". Sự am hiểu sâu chính là lợi thế.
Bước 2 — Viết problem statement một câu. Công thức: [Ai] gặp [vấn đề gì] dẫn đến [hệ quả đo được]. Ví dụ: "Khách hàng mới không tìm được cách kích hoạt tài khoản, khiến 25% ticket tuần đầu là câu hỏi kích hoạt." Một câu này là xương sống của cả project.
Bước 3 — Tổng hợp dữ liệu (ẩn danh). Nếu bạn còn nhớ số liệu công ty cũ, hãy làm tròn và ẩn danh (đừng ghi tên công ty thật, đừng dùng số chính xác nhạy cảm). Nếu không có số, hãy ước lượng hợp lý và ghi rõ "giả định dựa trên kinh nghiệm". Trung thực về nguồn số quan trọng hơn việc số phải chính xác tuyệt đối.
Bước 4 — Phân tích stakeholder. Liệt kê những ai liên quan: khách hàng, đội CS, đội sản phẩm, đội kỹ thuật, quản lý. Mỗi bên quan tâm điều gì? Đây là nơi bạn thể hiện tư duy đa bên — điều mà một CS agent thuần túy chưa quen nhưng BA bắt buộc phải có.
Bước 5 — Vẽ as-is và to-be process. Dùng công cụ miễn phí như draw.io, Miro, hoặc Lucidchart. As-is mô tả quy trình hiện tại với điểm nghẽn được đánh dấu; to-be mô tả quy trình cải tiến. Đây là "phần thịt" thể hiện năng lực phân tích quy trình.
Bước 6 — Viết requirements. Chuyển giải pháp thành user story kèm acceptance criteria (theo mẫu "As a [vai trò], I want [nhu cầu], so that [giá trị]"). Viết 5-10 story là đủ cho một project mẫu; chất lượng hơn số lượng.
Bước 7 — Định nghĩa success metrics và đóng gói. Nêu rõ đo thành công bằng gì (giảm X% ticket, giảm Y phút xử lý). Sau đó đóng gói toàn bộ thành một tài liệu gọn gàng (Google Doc, Notion, hoặc PDF) và tạo một trang tổng quan một trang (one-pager) tóm tắt — đây là thứ nhà tuyển dụng đọc đầu tiên.
Về nơi đăng: bạn nên có một trang portfolio đơn giản (Notion public page là đủ, không cần code), đính link trong CV và LinkedIn. 2-3 project chất lượng tốt hơn 8 project hời hợt.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhảy thẳng vào giải pháp. Đây là lỗi phổ biến nhất, như trường hợp bạn Linh. Người CS quen "xử lý cho xong" nên hay bỏ qua bước phân tích. Mẹo: luôn dành ít nhất nửa dung lượng project cho phần "vấn đề và phân tích" trước khi chạm tới giải pháp.
Lỗi 2 — Làm lộ thông tin công ty cũ. Tuyệt đối không dán tên khách hàng thật, số liệu tài chính nội bộ, hay screenshot hệ thống có dữ liệu cá nhân. Điều này vừa vi phạm bảo mật vừa khiến nhà tuyển dụng lo ngại về bạn. Mẹo: đổi tên công ty thành "một sàn TMĐT tầm trung", làm tròn số, ẩn danh mọi dữ liệu, và ghi chú rõ "dữ liệu đã được ẩn danh/tổng hợp cho mục đích minh họa".
Lỗi 3 — Project quá tham vọng. Ôm một project "cải tổ toàn bộ hệ thống CX" thì không bao giờ xong và cũng không sâu. Mẹo: chọn phạm vi nhỏ, giải quyết trọn vẹn một vấn đề cụ thể. Một project nhỏ mà đi hết chuỗi vấn đề-giải pháp-đo lường giá trị hơn một project lớn dang dở.
Lỗi 4 — Chỉ có deliverable, không có câu chuyện. Nhà tuyển dụng muốn nghe cách bạn suy nghĩ, không chỉ sản phẩm cuối. Mẹo: viết một đoạn "hành trình phân tích" ngắn cho mỗi project — tôi bắt đầu từ đâu, tôi đặt câu hỏi gì, tôi thay đổi hướng ra sao. Đây chính là phần bạn kể trong phỏng vấn.
Lỗi 5 — Không tận dụng lợi thế CS. Nhiều người chuyển nghề lại cố giấu quá khứ CS vì sợ bị coi thường. Sai lầm! Mẹo: đóng khung CS như một siêu năng lực — "tôi hiểu người dùng cuối ở mức mà BA thông thường không có được". Hãy để nền CS tỏa sáng trong portfolio, đừng che nó đi.
Mẹo vàng: Với mỗi project, chuẩn bị sẵn câu trả lời cho 3 câu hỏi mà nhà tuyển dụng chắc chắn hỏi: (1) Vấn đề gốc là gì và bạn biết nhờ đâu? (2) Vì sao bạn chọn giải pháp này chứ không phải giải pháp khác? (3) Bạn đo thành công thế nào? Trả lời trơn tru ba câu này, portfolio của bạn tự nhiên thuyết phục.
Bài tập thực hành
Bài tập 1 — Ngân hàng nỗi đau (30 phút). Viết ra danh sách 10 "nỗi đau" bạn từng gặp thường xuyên nhất khi làm CS. Với mỗi cái, ghi ước lượng tần suất (bao nhiêu % ticket/cuộc gọi). Khoanh tròn 3 cái bạn hiểu sâu nhất — đây là ứng viên cho portfolio project của bạn.
Bài tập 2 — Problem statement (20 phút). Chọn 1 trong 3 nỗi đau đã khoanh, viết problem statement theo công thức "[Ai] gặp [vấn đề] dẫn đến [hệ quả đo được]". Viết lại 3 lần cho đến khi câu văn thật gọn và có số liệu.
Bài tập 3 — Vẽ as-is process (45 phút). Dùng draw.io (miễn phí), vẽ lại quy trình hiện tại xử lý nỗi đau đó, đánh dấu ít nhất 2 điểm nghẽn bằng màu đỏ. Không cần đẹp, cần đúng logic.
Bài tập 4 — Viết 5 user story (40 phút). Từ giải pháp bạn hình dung, viết 5 user story kèm acceptance criteria. Nhờ một người bạn hoặc mentor đọc và hỏi lại "vì sao" — nếu bạn trả lời được, story đủ chặt.
Bài tập 5 — One-pager (30 phút). Gói toàn bộ thành một trang tóm tắt gồm: bối cảnh, problem statement, giải pháp đề xuất, success metric. Đây sẽ là "mặt tiền" của project trên trang portfolio Notion của bạn.
Hoàn thành 5 bài tập này, bạn đã có phôi thai của một portfolio project CS-leverage hoàn chỉnh đầu tiên.
Tóm tắt
Portfolio là bằng chứng, còn CV chỉ là lời tuyên bố — và điều phân biệt bạn với đám đông BA fresher chính là project tự làm. Là người chuyển từ CS, bạn nắm giữ lợi thế mà không ai học chay có được: nỗi đau thật, dữ liệu thật, và góc nhìn end-user. Hãy khai thác chính công việc CS cũ để xây portfolio, ưu tiên ba dạng project trúng tủ: self-service/deflection, process improvement, và feature enhancement. Đi theo quy trình 7 bước từ chọn nỗi đau, viết problem statement, tổng hợp dữ liệu ẩn danh, phân tích stakeholder, vẽ as-is/to-be, viết requirements, đến định nghĩa metric. Tránh năm cái bẫy chết người — nhảy vào giải pháp, lộ thông tin cũ, tham vọng quá đà, thiếu câu chuyện, và giấu quá khứ CS. Nhớ rằng portfolio BA chấm ở chuỗi lập luận chứ không ở hình thức: đẹp mà rỗng luôn thua chặt mà thật. Chỉ cần 2-3 project chất lượng, đóng gói gọn gàng trên một trang Notion, kèm khả năng kể được hành trình phân tích của mình — bạn sẽ bước vào phòng phỏng vấn BA không phải như một CS agent xin việc, mà như một BA có bằng chứng trong tay.