TaxPal

TaxPal là nền tảng môi giới dịch vụ kế toán tại Nhật Bản, kết nối ba phía: khách hàng cần kế toán viên hoặc chuyên gia, đội sales / môi giới tiếp nhận và theo đến cùng từng yêu cầu, và kế toán viên / chuyên gia cung cấp dịch vụ. Mỗi phía có khu vực riêng trong sản phẩm, nhưng cùng dùng chung dữ liệu company, case và lịch sử cung cấp dịch vụ.

Năm 2022, tôi là Tech Lead của team tại Việt Nam và điều phối phía Việt Nam trong giai đoạn phát triển chính. Phạm vi của team là Sales Dashboard: hệ thống analytics nội bộ mà đội môi giới và quản lý dùng để theo dõi case, KPI, hiệu suất sales và tỷ lệ chuyển đổi — theo từng nhân viên, từng team và toàn công ty.

Vì sao đây là dự án hệ thống quản lý: phần khó chưa bao giờ là vẽ biểu đồ, mà là quyết định một con số có nghĩa là gì — case nào được đếm, theo ngày làm việc nào, trong kỳ quyết toán nào, với nhân viên đã nghỉ thì sao — rồi trả những con số đó về thật nhanh. Đây cũng là dự án brownfield: xây dashboard mới trên codebase AWS có sẵn, cùng GraphQL resolver, database, authentication và quy trình release của hệ thống cũ.

Nền tảng và người dùng

Khách hàng mang nhu cầu tới. Đội sales / môi giới biến nhu cầu đó thành case, follow và đưa case tới hợp đồng; quản lý theo dõi hiệu suất của từng người, từng team và toàn công ty. Kế toán viên / chuyên gia nhận các case tới lượt mình và có dashboard riêng.

Ba nhóm người dùng, một bộ dữ liệu company và case dùng chung. Sales Dashboard nằm ở phía môi giới của sản phẩm.

Vai trò của tôi

Theo dõi và kiểm soát tiến độ kỹ thuật, schedule và workload của team theo từng menu / milestone.
Điều phối giữa Backend, Frontend và IT Communicator; làm việc định kỳ với khách hàng Nhật Bản.
Phân tích yêu cầu nghiệp vụ thành thiết kế kỹ thuật; breakdown task và estimate.
Review API design và pull request.
Hỗ trợ xử lý các vấn đề khó về GraphQL, Prisma, database và integration; điều phối sửa bug giữa FE và BE.
Đánh giá rủi ro ảnh hưởng tiến độ, làm rõ với khách hàng các điểm chưa rõ trong tài liệu nghiệp vụ.
Quản lý bàn giao và release theo quy trình repository của khách hàng; tổng hợp tình trạng, issue, nguyên nhân và phương án xử lý để báo cáo.

Từ yêu cầu tới hợp đồng: pipeline của case

Mỗi nhu cầu của khách hàng là một case, gắn với dữ liệu company — dữ liệu master mà lịch hẹn, tiến độ và hợp đồng đều liên kết vào. Saler có thể được chỉ định thủ công — hệ thống không ép tổ chức theo một thuật toán auto-assign cứng. Từ đó case đi qua nhiều trạng thái sales: khả năng cao lấy được lịch hẹn, đang có vấn đề cần giải quyết, khó hoặc không khả thi, đang liên hệ nhưng chưa kết nối được, đã xác nhận hoặc bị cancel lịch hẹn, đang follow, đã lên hợp đồng, đã lên hợp đồng kế toán, tạm dừng, hủy hợp đồng, hủy khi renew. Ở phiên bản nghiệp vụ được mô tả, saler tự chọn status trên màn hình case thay vì một state machine tự động hoàn toàn.

Bản đơn giản hóa từ hệ thống status thực tế. Case — không phải khách hàng — là đơn vị để tính mọi số lượng, KPI và tỷ lệ chuyển đổi.

Sales Dashboard hiển thị những gì

Dashboard biến case thành các góc nhìn quản trị: case mới và đang xử lý, số lượng tiếp nhận, KPI, kết quả thực tế, sales, tỷ lệ thành công, hiệu suất theo từng người, từng team và toàn công ty. Trong đó có bảng case theo tuần cho từng thành viên và team, KPI theo ngày / tháng / năm, sales ranking, doanh số theo dịch vụ trong 4 năm gần nhất, và tỷ lệ thành công của pipeline trong khoảng từ hai tuần tới một năm.

Sáu nguồn dữ liệu, một analytics API, một lớp business rule, ba cấp tổng hợp.

KPI target so với actual

Quản lý nhập sales target theo năm, tháng, nhân viên và loại chỉ tiêu. Kỳ chưa có dữ liệu mở ra ở trạng thái trống để nhập mới; kỳ đã có dữ liệu mở ra để chỉnh sửa. Target sau đó được so với kết quả thực tế theo ngày, tháng và năm, để thấy được chênh lệch và xu hướng chứ không chỉ con số tổng.

Target nhập một lần; actual lấy từ chính dữ liệu case, sales và hợp đồng mà cả nền tảng đang dùng.

Đếm một khách hàng một lần: rule xử lý case trùng

Cùng một khách hàng có thể tới nhiều lần, qua các kênh liên hệ khác nhau hoặc vào các thời điểm khác nhau. Rule gom các case có cùng người đại diện, email hoặc số điện thoại phù hợp, và ngày tiếp nhận nằm trong một khoảng quy định. Nhóm có thể là chuỗi: A trùng B, B trùng C thì cả ba thuộc cùng một nhóm. Với mỗi nhóm, dashboard chọn một record đại diện và một giá trị forecast, để số lượng mail, contact và case không bị tăng sai.

Con số trên dashboard chỉ đúng khi rule đếm đúng. Case trùng được xử lý trước khi cộng bất kỳ thứ gì.

Con số phải đúng theo lịch và theo tổ chức

Bảng analytics tối ưu cho việc đọc. Để không phải tính lại toàn bộ từ các bảng giao dịch mỗi lần mở dashboard, bảng thống kê lưu sẵn những gì aggregation cần: kỳ tính toán cùng ngày bắt đầu / kết thúc, thứ tự team, loại thống kê, trạng thái nhân viên, ngày làm việc. Đọc nhanh và query đơn giản hơn; đánh đổi là khi business rule thay đổi có thể phải rebuild lại dữ liệu đó.
Ngày làm việc. Số ngày làm việc còn lại và ngày tiếp nhận hợp lệ được tính theo dữ liệu ngày nghỉ, không theo lịch thông thường.
Kỳ quyết toán. Năm chọn trên màn hình có thể là năm tài chính chạy từ tháng 10 tới tháng 9, nên frontend và backend phải thống nhất date range thay vì lọc theo năm dương lịch.
Nhân viên đã nghỉ. Cờ nghỉ việc nằm ngay trong dữ liệu thống kê, để báo cáo lịch sử vẫn giữ nhân viên cũ mà không xử lý họ như nhân viên đang làm trong mọi phép tính.

Expert Dashboard

Tài liệu dự án còn bao gồm dashboard dành cho chính kế toán viên / chuyên gia: thu nhập, hiệu quả kinh doanh, chiến lược, nhân sự, thừa kế, mức độ ứng dụng CNTT và sự hài lòng khách hàng, so sánh trên radar chart với các mốc cá nhân, nhóm, công ty và giá trị trung bình tham chiếu.

Analytics không chỉ dành cho đội sales nội bộ: chuyên gia có góc nhìn riêng trên bảy chiều hoạt động.

Kiến trúc

Frontend không bao giờ truy cập database trực tiếp. Next.js và React gọi AWS AppSync qua Apollo; schema GraphQL được phân quyền bằng Cognito User Pools và IAM; mỗi request đi qua resolver, use case và repository, rồi Prisma truy cập PostgreSQL trên AWS. Codebase còn có Elasticsearch / OpenSearch cho search và indexing, và hạ tầng AWS được định nghĩa bằng Terraform.

Sơ đồ mức portfolio dựng từ các thành phần trong codebase và tài liệu — không phải bản sao sơ đồ hạ tầng production.

Thêm một API luôn đi cùng một con đường: schema, code generation, resolver, use case, repository, Prisma query, rồi test và seed data. Pull request được phía khách hàng review và phải pass toàn bộ GitHub checks. Migration và seed data tách thành pull request riêng, để một thay đổi schema không bao giờ bị merge lẫn với code nghiệp vụ, vốn khó review và khó rollback.

Một con đường cho mọi API mới, từ yêu cầu tới pull request.

Tối ưu tốc độ dashboard

Dashboard có nhiều widget và nhiều phép thống kê nên hiệu năng là chuyện hằng ngày. Các vấn đề ghi nhận rất cụ thể: API select nhiều field hơn màn hình cần, load cả relation trong khi chỉ cần vài field, kiểm tra dữ liệu bằng nhiều request lặp, một màn hình chỉ khoảng 120 record mà API mất hơn 1 giây, và có dashboard gọi API riêng cho từng team. Cách xử lý: chỉ select dữ liệu cần, dùng relation thay cho query lặp, giảm kích thước response, trả dữ liệu nhiều team trong một API, giảm số request từ frontend, lazy load các widget người dùng chưa xem tới — kèm loading state để phân biệt "đang tải" với "không có dữ liệu".

Cùng một widget, hai cách lấy dữ liệu. Phần lớn cải thiện đến từ việc hỏi ít hơn, và hỏi thưa hơn.

Biểu đồ và QA cho một dashboard dùng để quản trị

Dashboard dùng để quản trị phải chịu được dữ liệu khó. Màu theo team phải dễ đọc khi số team tăng, team vượt ngưỡng dùng chung một style, và một số thống kê chỉ hiện team có thành viên. Giá trị vượt 100% — tới khoảng 200% — vẫn phải nằm trong biểu đồ, tooltip vẫn đọc được, scale đổi theo rule. Vì vậy QA không dừng ở giao diện: field mapping, công thức total, ngày làm việc, case trùng, sort, status, date range, filter, giá trị 0 và null, và cấu trúc từng API response.

Dự án bao phủ những gì

Bài toán của một hệ thống quản lý lớn	Thể hiện trong TaxPal
Pipeline sales nhiều trạng thái	Status của case từ lần liên hệ đầu tới hợp đồng, do saler cập nhật
Quản lý KPI	Target theo năm, tháng, nhân viên, loại chỉ tiêu; target so với actual theo ngày, tháng, năm
Tổng hợp nhiều cấp	Góc nhìn staff, team, toàn công ty; ranking; doanh số theo dịch vụ trong 4 năm
Rule đảm bảo đúng số liệu	Nhóm case trùng, ngày làm việc, kỳ quyết toán, nhân viên đã nghỉ
Hiệu năng đọc	Bảng analytics tính sẵn, chỉ select dữ liệu cần, một API cho nhiều team, lazy load
Phát triển brownfield	Module mới trên codebase AppSync, Prisma và PostgreSQL có sẵn; migration tách pull request riêng
Làm việc với khách hàng Nhật	Họp định kỳ, làm rõ yêu cầu, release qua repository của khách hàng

Các sơ đồ được dựng lại ở mức thành phần từ tài liệu dự án. Chúng lược bỏ URL nội bộ, định danh hệ thống, source code độc quyền và dữ liệu của khách hàng. Ảnh chụp là mockup thiết kế và mô hình dữ liệu đã vẽ lại; tên nhân viên, một logo và một ảnh chân dung đã được làm mờ.

Ảnh 1 trên 4