Xuất góp ý

Sao chép toàn bộ nội dung dưới đây và gửi lại để cập nhật tài liệu.

ĐÂY LÀ BẢN CŨ — nội dung trước khi cập nhật theo 69 góp ý của Quý khách. Giữ lại để đối chiếu. Bản mới nhất nằm ở tệp index.html. Góp ý trên trang này lưu riêng, không lẫn với bản mới.
Bản cũ · trước khi cập nhật theo góp ý

Hệ thống Quản lý Vận hành
Activation Event

Giai đoạn 1 — Nền tảng quản lý nhân sự thời vụ, hàng hoá tại điểm và nghiệm thu chiến dịch

Khách hàng
[Tên khách hàng]
Đơn vị triển khai
[Tên công ty]
Ngày phát hành
[Ngày]
Phiên bản
1.0

PHẦN ITổng quan giải pháp

1.1 · Bối cảnh & định vị

Một chiến dịch Activation trải trên nhiều địa điểm, nhiều tỉnh thành, kéo dài nhiều tuần, huy động hàng chục đến hàng trăm nhân sự thời vụ làm việc theo ca. Bài toán cốt lõi không nằm ở “quản lý sự kiện” mà ở vận hành lực lượng lao động thời vụ phân tán, kèm hệ kho hàng tại nhiều điểm và kênh thu thập dữ liệu khách hàng ngay tại chỗ.

Sản phẩm đầu ra cuối cùng của mọi dự án là Báo cáo nghiệm thu với Nhãn hàng — chứng minh chiến dịch đã chạy thật, có kiểm soát, có số liệu và hình ảnh làm bằng chứng.

Ba trục giá trị chạy song song

TrụcChuỗi vận hànhKết thúc bằng
Nhân sựTuyển → Đào tạo → Ký hợp đồng → Phân ca → Chấm công → Thưởng phạt → LươngBảng lương + Đánh giá năng lực
Hàng hoáNhập về điểm → Bàn giao ca → Phát cho khách → Kiểm đếm → Trả lạiXuất–Nhập–Tồn + Quy trách nhiệm thất thoát
Dữ liệuChỉ tiêu KPI → Data khách thu tại điểm → Số liệu vận hànhBáo cáo nghiệm thu

1.2 · Trục dữ liệu xương sống

Dự án
Địa điểm — mỗi địa điểm đồng thời là một kho hàng
Ca làm việc → Phân công cho từng PG (đơn giá gắn ở đây)
Chấm công · Lỗi & Thưởng · Bàn giao ca
Hoạt động tại điểm → Lượt tương tác với khách
Data khách hàng · Ảnh bằng chứng · Xuất kho · Cộng chỉ tiêu KPI
Tồn kho tại booth

Ba nguyên tắc thiết kế nền tảng

1.3 · Các bên tham gia

Vai tròPhạm vi làm việc
Quản trị viênToàn hệ thống, quản lý kho trung tâm
AgencyCác dự án của mình: tạo dự án, tuyển dụng, điều hành, chốt lương
Supervisor (SUP)Vùng / địa điểm được giao trong dự án: quản PG, duyệt đơn, duyệt công
PG / CTVCa làm việc được phân: chấm công, ghi nhận hoạt động, nhận & bàn giao hàng
Nhãn hàng (Client)Dự án của mình, chỉ xem: tiến độ, số liệu, báo cáo nghiệm thu
Ứng viênNộp hồ sơ qua link công khai, chưa cần tài khoản

1.4 · Nguyên tắc cấu hình động

Yêu cầu của Quý khách nhiều lần nhấn mạnh “tuỳ từng dự án”, “tuỳ từng đơn vị”, “không áp cố định”. Chúng tôi thiết kế toàn bộ quy tắc thành tham số cấu hình, không cố định trong mã nguồn.

Mẫu chính sách cấp hệ thống Chọn khi tạo dự án Sao chép vào dự án Chỉnh sửa riêng
Sao chép chứ không tham chiếu: sửa mẫu gốc không ảnh hưởng đến dự án đang chạy. Đây là nguyên tắc bắt buộc để tránh tai nạn thay đổi chính sách khi chiến dịch đang diễn ra.

Những gì cố ý giữ cố định

Để hệ thống đơn giản, dễ vận hành và bảo trì lâu dài, bốn nội dung sau được giữ cố định thay vì cho tuỳ biến tự do:

Chi tiết 51 tham số cấu hình theo dự án xem Phần III.

1.5 · Phạm vi bàn giao

Thành phầnNội dung
Web quản trịDành cho Quản trị viên, Agency, Supervisor và Nhãn hàng
Web vận hành cho PG/CTVChạy tốt trên trình duyệt điện thoại, dùng ngay không cần cài ứng dụng
Bộ API cho ứng dụng mobileToàn bộ giao diện lập trình để đội mobile xây dựng app iOS/Android, bao gồm cơ chế đồng bộ dữ liệu ghi offline

1.6 · Công nghệ

Thành phầnCông nghệ
Máy chủ ứng dụng.NET 9
Cơ sở dữ liệuPostgreSQL
Web quản trị & vận hànhAngular 21
Giao diện lập trình cho mobileREST API · JWT · OpenAPI
Lưu trữ hình ảnh & tệpMinIO (chuẩn S3)
Thông báo thời gian thựcWebSocket

Hệ thống chạy được trên cloud (AWS / Azure / GCP / VNG / Viettel) hoặc máy chủ riêng của Quý khách.

1.7 · Quy mô hệ thống

Chỉ tiêuGiá trị
Nhóm chức năng14
Chức năng chi tiết88
Màn hình~100
Tham số cấu hình theo dự án51

1.8 · Ký hiệu sử dụng trong tài liệu

Ký hiệuÝ nghĩa
(không ký hiệu)Chức năng theo đúng yêu cầu Quý khách đã nêu
★ Đề xuấtHạng mục chúng tôi chủ động đề xuất bổ sung — không có trong yêu cầu ban đầu nhưng cần thiết để chu trình vận hành khép kín. Mỗi hạng mục đều kèm giải thích lý do
? Cần chốtNội dung cần Quý khách xác nhận — tổng hợp tại Phần V
Về phạm vi tài liệu này: đây là bản mô tả nghiệp vụ để Quý khách rà soát và xác nhận. Phần khối lượng, tiến độ và báo giá sẽ được lập riêng sau khi chốt xong nghiệp vụ.

PHẦN IIChi tiết chức năng & nghiệp vụ

Phần này mô tả chi tiết nghiệp vụ của từng chức năng để Quý khách hình dung rõ hệ thống sẽ hoạt động như thế nào, đồng thời làm cơ sở cho việc chốt đặc tả ở giai đoạn đầu dự án.

Quản lý người dùng đa vai trò & Kiểm soát truy cập

6 chức năng

A1 · Quản lý tài khoản người dùng

  • Quản lý tài khoản của cả 6 nhóm đối tượng: Quản trị viên, Agency, Supervisor, PG, PG, Nhãn hàng
  • Tạo, sửa, khoá / mở khoá tài khoản; gán vai trò và phạm vi làm việc
  • Tên đăng nhập là số điện thoại Việt Nam — hệ thống chuẩn hoá tự động khi lưu để tránh trùng lặp giữa các cách viết (0912…, +84912…, 84912…) ★ Đề xuất
  • Số điện thoại thay đổi được mà không mất dữ liệu lịch sử. Hệ thống dùng mã định danh nội bộ riêng, số điện thoại chỉ là thông tin đăng nhập ★ Đề xuất
  • Một người có thể tham gia nhiều dự án với vai trò khác nhau trong từng dự án
Vì sao tách mã định danh khỏi số điện thoại: PG đổi số rất thường xuyên. Nếu buộc tạo tài khoản mới thì toàn bộ lịch sử làm việc và đánh giá của người đó bị mất.

A2 · Đăng nhập & Bảo mật tài khoản

  • Đăng nhập bằng số điện thoại và mật khẩu; quên mật khẩu, khôi phục tài khoản qua email hoặc số điện thoại
  • Chính sách độ mạnh mật khẩu, buộc đổi mật khẩu định kỳ (bật/tắt được)
  • Tự động khoá tài khoản khi nhập sai quá số lần quy định
  • Lịch sử đăng nhập: ghi nhận mọi lần đăng nhập của từng tài khoản — thời điểm, thiết bị, địa chỉ IP, thành công hay thất bại ★ Đề xuất
Vì sao cần lịch sử đăng nhập: gian lận phổ biến nhất trong vận hành PG là nhờ người khác chấm công hộ — đưa tài khoản cho đồng nghiệp đăng nhập giúp. Lịch sử đăng nhập cho thấy cùng một tài khoản được truy cập từ hai thiết bị khác nhau trong cùng một ca, là căn cứ đối chiếu khi nghi ngờ.

A3 · Xác thực hai lớp ★ Đề xuất

Vì sao đề xuất: tài khoản Agency và Quản trị viên nắm quyền chốt lương và điều chỉnh đơn giá — nếu bị chiếm quyền sẽ gây thiệt hại tài chính trực tiếp. Xác thực hai lớp là biện pháp bảo vệ tiêu chuẩn cho nhóm tài khoản này.
  • Ba phương thức: mã OTP qua SMS · mã OTP qua Email · ứng dụng sinh mã (Google Authenticator)
  • Bật/tắt theo từng vai trò — khuyến nghị bắt buộc với Quản trị viên và Agency, tuỳ chọn với Supervisor, không áp dụng với PG
  • Mã dự phòng khi mất thiết bị; ghi nhận thiết bị tin cậy để không phải xác thực lại mỗi lần đăng nhập

A4 · Hồ sơ cá nhân & Cài đặt người dùng ★ Đề xuất

Vì sao đề xuất: mỗi người dùng cần tự quản lý thông tin và mức độ nhận thông báo của mình. Nếu không có, mọi thay đổi nhỏ đều phải nhờ quản trị viên — không khả thi khi hệ thống có hàng trăm PG.
  • Cập nhật thông tin cá nhân, ảnh đại diện, đổi mật khẩu, chọn ngôn ngữ giao diện, bật/tắt từng loại thông báo và từng kênh nhận (trong ứng dụng / email / tin nhắn)

A5 · Vai trò & Phân quyền

  • Phân quyền chi tiết đến từng thao tác (xem / thêm / sửa / xoá / duyệt) cho từng màn hình
  • Phân quyền theo vai trò và phân quyền riêng cho từng cá nhân
  • Phân quyền theo phạm vi: Supervisor chỉ nhìn thấy dữ liệu của các địa điểm được giao trong dự án ★ Đề xuất
  • Phân quyền theo trường dữ liệu: ba lớp đơn giá hiển thị khác nhau tuỳ vai trò (xem mục Bảng giá ca làm việc) ★ Đề xuất
  • Phân cấp duyệt đơn từ: Quản lý – Supervisor – PG
Vì sao cần phân quyền theo phạm vi và theo trường: một dự án có nhiều Supervisor phụ trách các vùng khác nhau, không thể để họ nhìn thấy PG và số liệu của nhau. Phân quyền theo trường là điểm mấu chốt để Supervisor quản được PG của mình mà Nhãn hàng không nhìn thấy phần chênh lệch.

A6 · Đăng nhập hỗ trợ ★ Đề xuất

Vì sao đề xuất: PG đứng ở booth gặp sự cố không chấm công được, gọi về tổng đài. Không có chức năng này, đội hỗ trợ phải hỏi mật khẩu của PG hoặc đoán mò — vừa mất an toàn vừa chậm.
  • Quản trị viên đăng nhập dưới danh nghĩa một người dùng để xem đúng những gì họ đang thấy và xử lý giúp. Toàn bộ thao tác trong phiên hỗ trợ được ghi nhật ký riêng, phân biệt rõ với thao tác của chính người dùng

Hồ sơ đối tác, Danh mục & Kho địa điểm tổ chức

4 chức năng

A7 · Hồ sơ Agency / Nhãn hàng / Nhà cung cấp

  • Thông tin: tên công ty, mã số thuế, mô tả thương hiệu và sản phẩm dịch vụ, logo công ty
  • Bổ sung: địa chỉ, người đại diện, người liên hệ chính ★ Đề xuất
  • Một tổ chức có thể đồng thời là Agency và Nhãn hàng — đáp ứng trường hợp nhãn hàng tự triển khai chiến dịch ★ Đề xuất
  • Danh sách nhân sự thuộc tổ chức; các dự án liên quan; trạng thái Đang hoạt động / Ngừng hợp tác

A8 · Danh mục dùng chung

Quản lý tập trung các danh mục dùng lại xuyên hệ thống, thêm/sửa được mà không cần lập trình:

Danh mụcSử dụng ở đâu
Loại nhân sự (PG: PG / PB / Mascot / MC / KTV / Helper / Khác)Định biên, phân ca, bảng giá
Loại dự án · Ngành hàngPhân loại, so sánh hiệu quả
Loại địa điểm (TTTM, siêu thị, toà nhà, trường học, công viên…)Kho địa điểm
Loại lỗi & thưởng (mẫu)Nguồn sao chép vào dự án
Loại quà tặng · Đơn vị tínhKho hàng
Loại công cụ làm việcCấp phát thiết bị
Loại sự cốBáo cáo sự cố
Loại chỉ tiêu KPIMục tiêu chiến dịch
Đơn vị hành chính (Tỉnh / Xã)Địa điểm

A9 · Kho địa điểm tổ chức

  • Thông tin điểm: tên, loại, địa chỉ đầy đủ, tỉnh/xã, toạ độ GPS, diện tích, giá thuê tham khảo, lượng người qua lại ước tính, hình ảnh, ghi chú
  • Bổ sung: người liên hệ tại điểm, giờ hoạt động, có sẵn nguồn điện và nước không, quy định riêng của điểm (giờ được setup, giờ tháo dỡ) ★ Đề xuất
  • Lịch sử tổ chức: điểm này đã chạy dự án nào, thời gian nào, đạt bao nhiêu phần trăm chỉ tiêu
  • Hiển thị dạng bản đồ: bấm vào một điểm hiện popup các thông số chính — diện tích, giá thuê, hiệu quả, lượng người qua lại
  • Chỉ số hiệu quả tự tổng hợp từ dữ liệu các dự án đã chạy tại điểm ★ Đề xuất
  • Lịch sử hiệu quả chỉ hiển thị cho Agency đã từng chạy tại điểm đó, tránh lộ dữ liệu cạnh tranh ★ Đề xuất? Cần chốt

A10 · Mẫu chính sách ★ Đề xuất

Vì sao đề xuất: mỗi dự án có quy định khác nhau về mức phạt, quy tắc chấm công, tiêu chí đánh giá. Không có cơ chế mẫu thì mỗi lần mở dự án mới đều phải khai báo lại từ đầu — mất thời gian và dễ sai sót, đặc biệt với đơn vị chạy nhiều chiến dịch song song.
  • Bảy loại mẫu: quy tắc chấm công · bộ lỗi & thưởng · mẫu ca làm việc · bộ tiêu chí đánh giá · mẫu hợp đồng · mẫu form tuyển dụng · mẫu báo cáo nghiệm thu
  • Tạo mẫu ở cấp hệ thống → khi tạo dự án chọn mẫu → hệ thống sao chép toàn bộ vào dự án → chỉnh sửa riêng mà không ảnh hưởng mẫu gốc

Tiện ích hệ thống

3 chức năng

A11 · Đa ngôn ngữ giao diện ★ Đề xuất

Vì sao đề xuất: hai lý do thực tế. Thứ nhất, nhiều nhãn hàng là công ty đa quốc gia và người phụ trách phía nhãn hàng có thể là người nước ngoài — họ cần xem được báo cáo và bảng điều khiển. Thứ hai, xây dựng hạ tầng đa ngôn ngữ ngay từ đầu rẻ hơn nhiều so với bổ sung sau khi hệ thống đã hoàn thiện.
  • Giai đoạn 1 cung cấp tiếng Việt (mặc định) và tiếng Anh cho phần giao diện quản trị và báo cáo
  • Người dùng tự chọn ngôn ngữ hiển thị, lưu theo tài khoản
  • Quản trị viên chỉnh sửa được nội dung dịch trực tiếp trên giao diện, không cần lập trình viên
  • Bổ sung ngôn ngữ thứ ba về sau chỉ là công việc nhập nội dung dịch

A12 · Cấu hình hệ thống ★ Đề xuất

Vì sao đề xuất: các thông số kỹ thuật cần thay đổi được mà không phải nhờ lập trình viên và không phải dừng hệ thống.
  • Cấu hình gửi email · nhà cung cấp SMS/Zalo · giới hạn kích thước và định dạng tệp tải lên · thời gian lưu trữ hình ảnh · thông tin đơn vị hiển thị trên báo cáo và hợp đồng · logo và bộ nhận diện trên giao diện

A13 · Nhập & Xuất dữ liệu Excel ★ Đề xuất

Vì sao đề xuất: Agency thường đã có sẵn danh sách PG và danh sách địa điểm trên Excel. Không có công cụ nhập hàng loạt thì việc đưa dữ liệu ban đầu vào hệ thống trở thành rào cản lớn nhất khiến dự án chậm khởi động.
  • Nhập hàng loạt: danh sách PG · danh sách địa điểm · danh mục hàng hoá · danh sách ứng viên
  • Có tệp mẫu chuẩn để tải về; hệ thống kiểm tra dữ liệu trước khi nhập và báo cáo chi tiết từng dòng lỗi thay vì từ chối toàn bộ tệp
  • Xuất Excel từ mọi màn hình danh sách theo đúng bộ lọc đang áp dụng

Hồ sơ nhân sự (PG / CTV)

4 chức năng

B1 · Hồ sơ PG / CTV / Helper

Nhóm thông tinNội dung
Cơ bảnHọ tên, ngày sinh, giới tính, quê quán, địa chỉ hiện tại, email, điện thoại, mã số thuế cá nhân
Hình ảnhẢnh chân dung, ảnh toàn thân (theo khung chuẩn)
Giới thiệuPhần tự giới thiệu bản thân
Kinh nghiệmVai trò đã làm, công việc cụ thể, link tham chiếu
Giấy tờẢnh CCCD hai mặt
Thể chấtChiều cao, cân nặng, số đo ba vòng
Tài chính Số tài khoản, ngân hàng, chủ tài khoản — bắt buộc để chi trả lương
Khác Khu vực sẵn sàng làm việc, phương tiện di chuyển, ngoại ngữ
  • Hai mức hồ sơ: Cấp 1 (chưa có CCCD) — không được phân vào ca làm việc; Đầy đủ (có CCCD và số tài khoản) — phân ca bình thường
  • Quy tắc này được hệ thống kiểm soát ở bước phân ca — không tạo được dòng phân công cho PG hồ sơ cấp 1, chứ không chỉ hiện cảnh báo trên màn hình ★ Đề xuất
  • Quy trình duyệt hồ sơ: PG nộp hồ sơ → Agency/Supervisor kiểm tra giấy tờ → duyệt hoặc từ chối kèm lý do
  • Danh sách hạn chế theo Agency: đánh dấu PG không hợp tác nữa kèm lý do; hệ thống cảnh báo khi phân ca. Không áp dụng chặn trên toàn nền tảng ★ Đề xuất

B2 · Quan hệ Agency – PG

  • Mỗi Agency quản lý danh sách PG riêng. Agency không nhìn thấy PG của Agency khác
  • Một PG làm cho nhiều Agency là chuyện bình thường của lao động thời vụ — hệ thống hỗ trợ đầy đủ
  • Xử lý trùng số điện thoại: Agency B thêm PG mà số đã tồn tại trên hệ thống → hệ thống nhận diện và gắn quan hệ, không tiết lộ PG này đang thuộc Agency nào khác ★ Đề xuất
  • Nguồn PG: tự thêm tay / từ tuyển dụng / PG tự đăng ký được duyệt
  • Trạng thái quan hệ: Đang hợp tác / Tạm ngưng / Ngừng hợp tác

B3 · Lịch sử làm việc

  • Danh sách dự án đã tham gia, số ca, tổng giờ làm, điểm đánh giá từng dự án
  • Phạm vi hiển thị: Agency chỉ thấy lịch sử của các dự án do chính mình chạy ★ Đề xuất? Cần chốt

B4 · Điểm tin cậy ★ Đề xuất

Vì sao đề xuất: đây là chỉ số quan trọng nhất khi chọn PG cho ca làm việc. Bỏ ca là rủi ro lớn nhất của vận hành Activation — thiếu một PG là booth hoạt động không đúng kịch bản, ảnh hưởng trực tiếp tới chỉ tiêu và uy tín với nhãn hàng.
  • Hệ thống tự tính, không nhập tay: tỉ lệ đi làm đúng giờ · tỉ lệ bỏ ca · số lần đi muộn · số lần vi phạm
  • Hiển thị ngay tại màn hình phân ca: “PG này đã bỏ 2 ca trong 30 ngày qua”

Quản lý dự án

11 chức năng

C1 · Tạo & quản lý dự án

  • Thông tin: mã dự án (sinh tự động), tên dự án, loại dự án, Bên thực hiện, Nhãn hàng, thông tin nhãn hàng và sản phẩm, logo và banner chiến dịch, thời gian dự án, người phụ trách
  • Tạo theo hướng dẫn từng bước (5 bước), cho phép lưu nháp giữa chừng: Thông tin chung → Địa điểm & Lịch → Nhân sự & Bảng giá → Hàng hoá & Hoạt động → Chính sách ★ Đề xuất
  • Sao chép dự án: tạo dự án mới từ dự án cũ, giữ nguyên địa điểm, hoạt động, chính sách, bảng giá; chỉ khai lại nhân sự và lịch ★ Đề xuất
Vì sao đề xuất sao chép dự án: với các chiến dịch lặp lại theo quý, đây là chức năng tiết kiệm thời gian nhiều nhất — thay vì khai báo lại hàng chục địa điểm và toàn bộ chính sách.

Vòng đời dự án:

NhápĐang tuyểnSẵn sàngĐang chạyKết thúc vận hànhĐã nghiệm thuĐã chốt lươngĐóng

C2 · Mục tiêu chiến dịch (KPI)

  • Khai báo chỉ tiêu theo từng địa điểm và từng khoảng thời gian: số data khách hàng thu thập, doanh thu, số quà phát ra, số lượt tải ứng dụng, số lượt tương tác
  • Cấu trúc: Loại chỉ tiêu × Phạm vi (toàn dự án / địa điểm / ngày) × Con số mục tiêu × Đơn vị
  • Hệ thống tự đối chiếu thực tế với chỉ tiêu, hiển thị phần trăm hoàn thành theo thời gian thực
  • Mọi chỉ tiêu khai ở đây tự động xuất hiện trong báo cáo nghiệm thu cuối dự án — không phải tổng hợp lại bằng tay ★ Đề xuất

C3 · Địa điểm thực hiện

  • Chọn một hoặc nhiều địa phương (Tỉnh / Xã) → chọn địa điểm cụ thể từ kho địa điểm hoặc tạo mới
  • Trang mô tả địa điểm với các thông số cụ thể, hình ảnh, mô tả bổ sung
  • Mỗi địa điểm khai thêm: toạ độ GPS chuẩn (dùng kiểm soát chấm công), bán kính cho phép chấm công, Supervisor phụ trách, thời gian hoạt động riêng có thể khác thời gian dự án tổng ★ Đề xuất
  • Mỗi địa điểm đồng thời là một kho hàng — tạo địa điểm là tự động tạo kho tương ứng ★ Đề xuất

C4 · Booth & khu vực chức năng

  • Hình ảnh booth kèm theo
  • Khai báo các khu vực hoạt động trong booth: khu tư vấn bán hàng, khu trải nghiệm sản phẩm, khu trò chơi, khu kho… kèm lưu ý riêng từng khu
  • Khu vực được dùng để gán cho từng hoạt động và từng ca làm việc

C5 · Hoạt động tại điểm ★ Đề xuất

Vì sao đề xuất: trong tài liệu yêu cầu, phần “kiểm đếm quà tặng phát ra”“thu thập data khách hàng” được nêu dưới dạng câu hỏi mở. Đây lại chính là nơi sinh ra toàn bộ số liệu cho báo cáo nghiệm thu — thứ để thanh toán với nhãn hàng. Chúng tôi đề xuất gom tất cả — phát quà, sampling, thu data, mini game, tư vấn bán hàng — về một mô hình thống nhất thay vì xây riêng từng loại. Lợi ích: thêm một hình thức hoạt động mới về sau chỉ là thay đổi cấu hình, không cần lập trình lại và không phát sinh chi phí.

Cấu hình từng loại hoạt động:

Cấu hìnhNội dung
Thông tin chungMã, tên, mô tả, khu vực thực hiện
Thu data khách?Không / Có → chọn mẫu form (tự thiết kế các trường cần thu)
Yêu cầu ảnh?Không / Có → số ảnh tối thiểu
Trừ kho?Không / Có → chọn mặt hàng và số lượng, hỗ trợ combo nhiều quà trong một lần phát
Tính vào chỉ tiêu nàoChọn loại KPI tương ứng
Giới hạn mỗi kháchKhông giới hạn / 1 lần trong ngày / 1 lần trong cả dự án
Bắt buộc trong ca?Có / Không

Cách vận hành: tại điểm, PG ghi nhận một lượt tương tác = 1 khách × một hoặc nhiều hoạt động. Mỗi lượt tự động sinh ra:

Dữ liệu khách hàng+Ảnh bằng chứng+Phiếu xuất kho+Cộng chỉ tiêu KPI+Gắn với ca / địa điểm / PG

Các tình huống đặc thù đã được tính đến:

  • Sampling không thu data (mở bia, nước ngọt cho khách dùng thử tại chỗ, PG thu lại vỏ và nắp chai): cấu hình hoạt động không cần form, không cần ảnh; PG bấm nút đếm hoặc nhập tổng số cuối ca ★ Đề xuất
  • Tặng nhiều quà cùng lúc (gấu bông + móc khoá, bút + mũ): khai thành một combo, hệ thống trừ kho đúng từng thành phần
  • Mini game: hệ thống ghi nhận kết quả trò chơi (khách chơi gì, trúng gì) và trừ quà tương ứng. Việc xây dựng bản thân trò chơi tương tác nằm ngoài phạm vi giai đoạn này ? Cần chốt
  • Ô đồng ý cung cấp thông tin trong form thu data khách hàng, lưu kèm thời điểm — đáp ứng Nghị định 13/2023 về bảo vệ dữ liệu cá nhân ★ Đề xuất

C6 · Định biên nhân sự

  • Khai số lượng và loại nhân sự (PG: PG / PB / Mascot / MC / KTV / Khác) theo từng điểm và cho cả dự án
  • Phân biệt rõ ba mức: Định biên (kế hoạch) ≠ Danh sách nhân sự (đã tuyển được) ≠ Phân ca (đã xếp lịch cụ thể) ★ Đề xuất
  • Hiển thị tỉ lệ lấp đầy và cảnh báo khi ngày chạy đến gần mà chưa đủ người ★ Đề xuất

C7 · Bảng giá ca làm việc ★ Đề xuất

Vì sao đề xuất: giải quyết đúng tình huống Quý khách đã nêu — khi triển khai qua Supervisor, Supervisor thường hưởng phần chênh lệch (nhãn hàng trả 300k/ca, qua Supervisor còn 250k/ca cho PG). Hệ thống cần quản lý được cả ba mức giá, đồng thời đảm bảo mỗi bên chỉ nhìn thấy phần thuộc về mình.
Lớp giáÝ nghĩaAi được xem
Giá bánBên đặt hàng trả bên thực hiệnQuản lý dự án · Người xem báo cáo
Giá trung gianBên thực hiện trả Điều phối viênQuản lý dự án · Điều phối viên
Giá chi trảThực trả cho PGQuản lý dự án · Điều phối viên · và chính PG đó
  • Bảng giá khai theo: loại nhân sự × loại ngày (thường / cuối tuần / lễ tết) × địa điểm
  • Khi phân ca, hệ thống lấy giá mặc định nhưng cho phép ghi đè riêng từng người trong từng ca — đáp ứng tình huống cùng một ca nhưng hai PG có mức giá khác nhau
  • Phần chênh lệch tự tính, chỉ hiển thị cho Quản lý dự án ★ Đề xuất
  • Hỗ trợ hai kiểu nhân sự: tính theo công (có chấm công, mặc định) và tính theo khối lượng công việc (khoán, không chấm công) — đúng trường hợp Supervisor mà Quý khách đã nêu ★ Đề xuất? Cần chốt

C8 · Chính sách dự án

  • 51 tham số cấu hình được theo từng dự án, chia 6 nhóm: Chấm công · Lỗi & Thưởng · Lương · Đơn từ · Kho · Đào tạo — chi tiết xem Phần III
  • Chính sách được khoá lại khi dự án chuyển sang trạng thái Đang chạy. Muốn sửa phải ghi lý do và lưu nhật ký; thay đổi chỉ áp dụng từ thời điểm sửa trở đi, không hồi tố các ca đã chấm công ★ Đề xuất
Vì sao khoá chính sách khi dự án chạy: đây là nguyên tắc bảo vệ cả hai phía khi có tranh chấp — PG không thể bị áp mức phạt mới cho những ca đã làm xong, và đơn vị vận hành có căn cứ rõ ràng để giải thích.

C9 · Nhân sự dự án

  • Danh sách người tham gia và vai trò trong dự án: Người phụ trách, Supervisor, PG, tài khoản xem của Nhãn hàng
  • Supervisor được gán phạm vi là danh sách địa điểm cụ thể — chỉ nhìn thấy PG, ca làm việc, kho hàng và đơn từ của các điểm mình phụ trách ★ Đề xuất
  • Thêm PG vào dự án và phân ca là hai bước riêng biệt ★ Đề xuất

C10 · Tài liệu dự án

  • Kho tài liệu chung của dự án (brief, quy định, hướng dẫn vận hành), phân loại nội bộ / dành cho PG, có quản lý phiên bản, liên kết sang module Đào tạo

C11 · Checklist đóng dự án ★ Đề xuất

Vì sao đề xuất: khi chiến dịch kết thúc, đội ngũ giải tán rất nhanh và mọi thứ dở dang trở thành thất thoát. Không có danh sách kiểm tra bắt buộc thì công cụ thất lạc, hàng thừa không ai trả, và lương treo vài tháng là chuyện thường gặp.
  • Danh sách kiểm tra bắt buộc trước khi chuyển dự án sang trạng thái Đóng: đã thu hồi hết công cụ làm việc · đã trả hàng thừa về kho trung tâm hoặc về nhãn hàng · đã xử lý xong toàn bộ chênh lệch và thất thoát · đã chốt và chi trả lương · PG đã xác nhận thu nhập · đã xuất báo cáo nghiệm thu · đã bàn giao dữ liệu khách hàng · đã thu hồi quyền truy cập của nhân sự thời vụ
  • Mỗi mục hiển thị số liệu thực tế còn tồn đọng, bấm vào là nhảy thẳng tới màn hình xử lý
  • Không cho đóng dự án khi còn mục chưa hoàn tất, trừ khi người quản lý xác nhận bỏ qua kèm lý do

Tuyển dụng

6 chức năng

D1 · Trình tạo form tuyển dụng

  • Nhà tuyển dụng tự thiết kế form theo yêu cầu thực tế của từng dự án bằng thao tác kéo thả, tương tự Google Form
  • 10 loại trường: văn bản ngắn, văn bản dài, số, ngày tháng, chọn một, chọn nhiều, tải ảnh, tải tệp, số điện thoại, email
  • Kèm mô tả vị trí và công việc (JD), thông tin dự án, thời gian làm việc, các trường đặc thù (số đo ba vòng, thời gian có thể đáp ứng…)
  • Một số trường luôn bắt buộc và không xoá được (Họ tên, Điện thoại, Email) ★ Đề xuất
  • Cùng công cụ này được dùng lại để thiết kế form thu thập dữ liệu khách hàng tại điểm — một công cụ phục vụ hai mục đích ★ Đề xuất
Vì sao khoá ba trường bắt buộc: đây là dữ liệu dùng để chuyển ứng viên thành hồ sơ PG. Nếu cho xoá thì luồng chuyển đổi sẽ gãy và phải nhập lại thủ công.

D2 · Trang ứng tuyển công khai

  • Mỗi form sinh ra một đường link chia sẻ; Agency đăng lên các kênh tuyển dụng của mình
  • Ứng viên nộp hồ sơ không cần tài khoản trên nền tảng
  • Xác thực mã OTP qua số điện thoại trước khi nộp ★ Đề xuất
  • Ghi nhận nguồn ứng viên theo từng kênh chia sẻ — biết kênh nào thực sự hiệu quả để tập trung ngân sách ★ Đề xuất
  • Nếu số điện thoại đã có hồ sơ trên hệ thống, tự động điền sẵn thông tin, ứng viên không phải nhập lại ★ Đề xuất
Vì sao bắt buộc xác thực OTP: không có bước này, dữ liệu ứng viên sẽ bị spam ngay trong tuần đầu tiên và toàn bộ công sức sàng lọc trở nên vô nghĩa.

D3 · Quản lý ứng viên

  • Danh sách ứng viên theo dự án và kho ứng viên tổng hợp xuyên dự án — ứng viên trượt dự án này vẫn được giữ lại để mời cho dự án khác
  • Hiển thị dạng bảng danh sách và bảng trực quan theo trạng thái (Kanban) để kéo thả
  • Mọi lần chuyển trạng thái ghi lại người thực hiện, thời điểm và ghi chú; cho phép lùi trạng thái nhưng có ghi nhật ký
  • Bộ lọc: dự án, trạng thái, khu vực, chiều cao, kinh nghiệm, nguồn tuyển
  • Thao tác hàng loạt: chọn nhiều ứng viên cùng lúc để chuyển trạng thái, gửi lời mời, hoặc mời sang dự án khác ★ Đề xuất

Vòng đời ứng viên — chuẩn hoá 8 trạng thái ★ Đề xuất

Mới nộpĐã liên hệHẹn phỏng vấnĐã phỏng vấnĐạtĐã gửi lời mờiĐã xác nhận

Các nhánh rẽ: Không đạt · Ứng viên từ chối · Không liên lạc được

Vì sao cần thao tác hàng loạt: một đợt tuyển có thể vài trăm hồ sơ — không thể xử lý từng hồ sơ một.

D4 · Xác nhận hợp tác & Tạo tài khoản

Trong tài liệu yêu cầu, luồng này được ghi chú là “cần tính toán”. Chúng tôi đề xuất phương án sau:

  1. Agency bấm “Gửi lời mời”
  2. Hệ thống gửi tin nhắn SMS / Zalo / Email kèm link xác nhận có thời hạn
  3. Ứng viên mở link, xem thông tin dự án, ca dự kiến, mức thù lao
  4. Bấm “Đồng ý tham gia” → xác thực mã OTP
  5. Chưa có tài khoản: tạo mới (đăng nhập bằng số điện thoại). Đã có tài khoản: đăng nhập và gắn vào dự án
  6. Bổ sung giấy tờ còn thiếu (CCCD, số tài khoản)
  7. Chính thức vào danh sách nhân sự dự án
  • Lời mời hết hạn sau số ngày cấu hình được (mặc định 3 ngày) → tự chuyển sang trạng thái “Không phản hồi”, giải phóng suất cho người khác ★ Đề xuất
  • Ứng viên từ chối phải chọn lý do từ danh mục — dữ liệu này giúp cải thiện chất lượng tuyển dụng các đợt sau ★ Đề xuất

D5 · Hệ thống PG dự phòng (Backup)

  • PG dự phòng không trực tiếp tham gia chương trình nhưng theo thoả thuận với Agency/Nhãn hàng vẫn nhận một khoản tiền tương đương việc giữ người, chi trả sau khi kết thúc dự án
  • Nếu trong quá trình thực hiện có gọi đến PG dự phòng mà PG không đáp ứng được thì khoản thù lao giữ chỗ không được tính
  • Bật/tắt theo từng dự án — đây là chức năng cộng thêm tuỳ từng đơn vị sử dụng
  • Vòng đời: Đang giữ chỗ → Được gọi → Nhận việc (chuyển thành PG chính thức) / Từ chối khi gọi (mất phí) → Kết thúc (được trả phí) ★ Đề xuất
  • Phí giữ chỗ tự động đưa vào bảng lương như một khoản thu nhập riêng, không tính theo ca ★ Đề xuất

D6 · Báo cáo tuyển dụng ★ Đề xuất

Vì sao đề xuất: tuyển không đủ người là rủi ro lớn nhất trước khi chiến dịch chạy. Cần nhìn thấy sớm để kịp bổ sung kênh tuyển.
  • Số ứng viên theo từng bước, tỉ lệ chuyển đổi giữa các bước, thời gian trung bình mỗi bước, hiệu quả theo từng kênh tuyển dụng, so sánh định biên với số đã xác nhận và cảnh báo thiếu người

Đào tạo & Hợp đồng

3 chức năng

E1 · Tài liệu & Khoá học dự án

  • Hình thức bài học: tài liệu văn bản, video, slide trình chiếu, nội dung soạn trực tiếp trên hệ thống
  • Đo thời gian học của PG — video tính theo phần trăm đã xem thực tế, tài liệu tính theo phần trăm đã cuộn, chỉ tính khi màn hình đang hiển thị ★ Đề xuất
  • Tài liệu cập nhật liên tục trong quá trình dự án — quản lý phiên bản, PG được thông báo khi có bản mới
  • Nội dung hoạt động tại điểm liên kết trực tiếp tới tài liệu đào tạo tương ứng
  • Đánh dấu bài học bắt buộc / tham khảo. Bài bắt buộc phải hoàn thành trước ca đầu tiên nếu chính sách dự án bật quy định này ★ Đề xuất
Vì sao đo thời gian học theo cách này: nếu chỉ đo thời gian mở trang thì PG mở rồi để đó, chỉ số trở nên vô nghĩa và không dùng để đánh giá được.

E2 · Bài kiểm tra

  • Bài kiểm tra có điểm số, là tuỳ chọn theo từng dự án — có dự án bắt buộc đạt mới được làm việc, có dự án chỉ cần đọc tài liệu training
  • Có thể bỏ qua hoàn toàn bước kiểm tra đầu vào; việc kiểm tra có thể tổ chức ở bất kỳ thời điểm nào trong dự án
  • Không đạt → tổ chức đào tạo lại và làm lại bài; không đạt tiếp có thể bị loại
  • Cấu hình: điểm đạt, số lần làm lại tối đa, thời gian làm bài, trộn thứ tự câu hỏi ★ Đề xuất
  • Dạng câu hỏi: trắc nghiệm một đáp án, nhiều đáp án, đúng/sai ★ Đề xuất
Vì sao không làm câu tự luận: phải chấm tay, không phù hợp với quy mô hàng trăm PG và làm chậm toàn bộ khâu chuẩn bị nhân sự.

E3 · Hợp đồng điện tử

  • Ký sau khi ứng viên xác nhận hợp tác và hoàn thành bài học / bài kiểm tra
  • Soạn theo mẫu có sẵn hoặc tự soạn mới tuỳ đơn vị
  • Hệ thống tự điền thông tin PG, dự án và mức thù lao vào mẫu → PG xem → xác nhận bằng mã OTP → ghi nhận thời điểm ký, địa chỉ IP, thiết bị và mã kiểm tra toàn vẹn nội dung → xuất file PDF
  • Giai đoạn này áp dụng hình thức “xác nhận trực tuyến”, làm căn cứ thoả thuận hợp tác giữa hai bên ở mức nội bộ. Chữ ký số có giá trị pháp lý đầy đủ cần tích hợp nhà cung cấp chứng thư số, là hạng mục riêng nằm ngoài phạm vi này ? Cần chốt
  • Chính sách dự án: bắt buộc ký hợp đồng trước ca đầu tiên hay không. Nếu bắt buộc, hệ thống chặn chấm công khi chưa ký ★ Đề xuất

Lịch & Phân ca

6 chức năng

F1 · Mẫu ca & Sinh lịch làm việc

Yêu cầu của Quý khách nêu rõ ba tình huống khó: dự án kéo dài nhiều tuần, ngày làm cách quãng, và giờ làm khác nhau giữa các ngày. Chúng tôi giải quyết bằng cơ chế ba lớp:

  1. Khai báo mẫu ca — Ca sáng 09:00–13:00, Ca chiều 13:00–17:00, Ca tối 17:00–21:00, kèm số lượng nhân sự theo từng loại
  2. Sinh lịch theo quy tắc lặp — chọn địa điểm, khoảng ngày, kiểu lặp (hàng ngày / chỉ cuối tuần / cách ngày / chọn thứ trong tuần), mẫu ca áp dụng → hệ thống sinh toàn bộ ca cụ thể
  3. Chỉnh sửa lẻ từng ca sau khi sinh — đổi giờ, đổi số lượng người, thêm hoặc xoá ca riêng lẻ; ca đã sửa được đánh dấu riêng

Vừa tạo lịch nhanh cho dự án dài hàng tháng, vừa xử lý được mọi trường hợp ngoại lệ.

F2 · Phân ca cho PG

  • Phân ca hàng loạt nhanh chóng: chọn nhiều PG × nhiều ca, gán một lần
  • Phân ca theo đặc thù riêng: từng cá nhân, trong từng ca cụ thể, tại từng địa điểm cụ thể, với mức thù lao riêng cho ca đó — đáp ứng tình huống ca ngày lễ tết, hoặc cùng một ca có hai PG nhưng giá khác nhau
  • Xem theo nhiều góc: theo người (lịch cá nhân), theo địa điểm, theo ngày, theo nhãn hàng

Bảy quy tắc kiểm tra tự động khi phân ca ★ Đề xuất

Tình huốngXử lý
PG chưa đủ giấy tờ (chưa có CCCD)Chặn không cho phân
PG đã có ca khác trùng giờChặn không cho phân
PG chưa ký hợp đồng (nếu chính sách bắt buộc)Cảnh báo, chặn khi chấm công
PG chưa hoàn thành đào tạo bắt buộcCảnh báo, chặn khi chấm công
PG vượt số giờ làm tối đa trong ngàyCảnh báo
Ca chưa đủ định biênHiển thị dấu hiệu thiếu người
PG nằm trong danh sách hạn chế của AgencyCảnh báo

F3 · Thay đổi lịch & Thông báo

  • Lịch chỉnh sửa được ngay cả khi dự án đang chạy — đáp ứng thay đổi phát sinh, đúng như yêu cầu đã nêu
  • Tự động thông báo tới tất cả người liên quan: PG bị ảnh hưởng, Supervisor phụ trách điểm, người quản lý dự án
  • Không cho sửa hoặc xoá ca đã có dữ liệu chấm công. Muốn huỷ phải dùng chức năng “Huỷ ca” kèm lý do, bản ghi cũ vẫn giữ nguyên để làm căn cứ ★ Đề xuất
  • Lưu lịch sử mọi thay đổi: ai đổi, đổi gì, lúc nào ★ Đề xuất

F4 · PG xác nhận ca ★ Đề xuất

Vì sao đề xuất: biện pháp đơn giản nhưng giảm đáng kể rủi ro thiếu người tại điểm — vấn đề tốn kém nhất trong vận hành Activation.
  • PG nhận thông báo ca được phân và xác nhận sẽ đi làm. Ca chưa được xác nhận trước ngưỡng thời gian quy định sẽ cảnh báo cho Supervisor để chuẩn bị người thay thế

Vòng đời phân công:

Đã phânĐã xác nhậnĐang làmHoàn thành|Vắng ca|Đã huỷ|Đã đổi

F5 · Thay người khẩn cấp ★ Đề xuất

Vì sao đề xuất: đây là tình huống xảy ra gần như mỗi ngày và tốn kém nhất trong vận hành Activation. Sáu giờ sáng PG báo ốm, ca chín giờ — Supervisor phải gọi điện lần lượt từng người trong danh bạ, vừa chậm vừa sót. Thiếu một PG là booth chạy sai kịch bản, ảnh hưởng trực tiếp tới chỉ tiêu và uy tín với nhãn hàng.
  • Supervisor bấm “Tìm người thay” ngay trên ca bị trống
  • Hệ thống tự lọc ứng viên phù hợp: đang rảnh trong khung giờ đó · ở gần địa điểm · hồ sơ đầy đủ giấy tờ · đã hoàn thành đào tạo và ký hợp đồng · không nằm trong danh sách hạn chế — kèm điểm tin cậy để cân nhắc
  • Ưu tiên hiển thị nhóm PG dự phòng của dự án trước
  • Gửi lời mời hàng loạt qua thông báo và tin nhắn, ai nhận trước được ca; hệ thống tự đóng lời mời với những người còn lại
  • Nhận xong tự cập nhật phân công, giữ nguyên mức thù lao của ca, và thông báo cho các bên liên quan
  • Ghi nhận lý do ca bị trống (PG báo nghỉ, vắng không lý do, nhãn hàng tăng người) để phục vụ thống kê và đánh giá

F6 · Ca mở cho PG tự nhận ★ Đề xuất

Vì sao đề xuất: với chiến dịch trải trên hàng chục địa điểm, phân ca thủ công từng người cho từng ca là khối lượng công việc rất lớn và luôn trễ. Cho phép PG tự nhận ca chuyển phần việc này sang chính người lao động, đồng thời tăng tỉ lệ lấp đầy vì PG chủ động chọn ca hợp lịch của mình.
  • Người quản lý đăng các ca còn trống dưới dạng ca mở, giới hạn theo khu vực và loại nhân sự
  • PG xem danh sách ca mở phù hợp với mình và bấm đăng ký
  • Hai chế độ cấu hình: tự động duyệt (ai đăng ký trước được ca) hoặc chờ Supervisor duyệt
  • Áp dụng đầy đủ bảy quy tắc kiểm tra như phân ca thủ công — trùng giờ, giấy tờ, đào tạo, giờ tối đa
  • Tự đóng ca mở khi đã đủ định biên

Vận hành tại điểm

11 chức năng
Nhóm chức năng dành cho PG. Bàn giao dưới dạng web chạy tốt trên trình duyệt điện thoạibộ API đầy đủ để phát triển ứng dụng mobile.

G1 · Màn hình chính của PG ★ Đề xuất

  • Ca làm việc hôm nay kèm nút chấm công nổi bật và chỉ đường tới điểm · Việc cần làm (bài học chưa hoàn thành, hợp đồng chưa ký, giấy tờ còn thiếu, ca chưa xác nhận) · Thông báo mới · Thu nhập tạm tính của dự án đang chạy

G2 · Chấm công vào / ra

  • Ảnh chỉ được chụp trực tiếp từ camera, không cho chọn ảnh có sẵn trong máy; ảnh có đóng dấu thời gian
  • Kèm toạ độ GPS hoặc chấm công qua mạng wifi tại điểm — hạn chế gian lận
  • Ghi nhận thêm để phục vụ đối chiếu: thời điểm trên thiết bị, thời điểm máy chủ nhận, độ chính xác GPS, khoảng cách tới điểm, mã thiết bị ★ Đề xuất
  • Không cho chấm công sớm quá 60 phút trước giờ ca (cấu hình được)
  • Giới hạn phạm vi chấm công: chỉ chấm được trong bán kính quy định quanh địa điểm (mặc định 100m, cấu hình theo từng điểm). Chấm ngoài vùng vẫn được nhưng bắt buộc nhập lý do và đánh dấu chờ duyệt ★ Đề xuất
  • Hỗ trợ chấm công khi không có mạng: ứng dụng lưu tại máy, có mạng thì tự gửi lên và hệ thống ghi nhận đầy đủ
  • Xử lý quên chấm công ra: hệ thống tự đóng ca sau khoảng thời gian quy định, đánh dấu “thiếu chấm công ra” và không tính công cho tới khi Supervisor duyệt tay ★ Đề xuất
  • Không chấm công cả ca → ghi nhận “Vắng ca”, áp dụng mức phạt tương ứng ★ Đề xuất
  • Lịch sử chấm công hiển thị dạng lịch biểu cho cả PG và cấp quản lý theo dõi
Vì sao cần quy tắc quên chấm công ra: nếu không, ca đó sẽ treo vô thời hạn và trở thành tranh chấp khi chốt lương — tình huống xảy ra gần như hàng ngày trong thực tế vận hành.

G3 · Checklist mở & đóng booth ★ Đề xuất

Vì sao đề xuất: đây là cách rẻ nhất và thuyết phục nhất để chứng minh với nhãn hàng rằng booth có thật, được setup đúng thiết kế và dọn dẹp đúng quy định. Bộ ảnh này đưa thẳng vào báo cáo nghiệm thu.
  • Đầu ca: ảnh toàn cảnh booth, ảnh khu vực trưng bày, xác nhận đã nhận đủ hàng, xác nhận thiết bị hoạt động
  • Cuối ca: ảnh booth sau khi dọn, xác nhận tồn kho, xác nhận bàn giao thiết bị
  • Nội dung checklist cấu hình theo từng dự án, bật/tắt được

G4 · Ghi nhận hoạt động tại điểm

Luồng chuẩn khi phát quà kèm thu data:

  1. Chọn hoạt động → nhập số điện thoại khách bằng bàn phím số
  2. Hệ thống cảnh báo nếu số đã ghi nhận trong dự án
  3. Điền form thông tin theo cấu hình của hoạt động
  4. Tích ô đồng ý cung cấp thông tin
  5. Chụp ảnh bằng chứng
  6. Chọn quà tặng (đơn lẻ hoặc combo nhiều món)
  7. Lưu → tự trừ tồn kho → cộng chỉ tiêu → sẵn sàng cho khách tiếp theo
  • Mục tiêu tốc độ nhập liệu: dưới 15 giây mỗi khách. Form tối giản 3–4 trường, bàn phím số cho điện thoại, chọn quà bằng nút lớn, tự động làm mới sau mỗi lượt ★ Đề xuất
  • Trừ tồn kho ngay lập tức. Trường hợp mất mạng, dữ liệu đồng bộ sau và cảnh báo cho Supervisor nếu phát sinh chênh lệch
  • Chống trùng dữ liệu khách theo số điện thoại trong phạm vi dự án — cảnh báo nhưng không chặn cứng, vì khách hoàn toàn có thể quay lại thật
  • Sửa hoặc xoá lượt đã ghi chỉ được thực hiện trong ca của mình và trong khoảng thời gian giới hạn; sau đó phải qua Supervisor duyệt ★ Đề xuất
Vì sao tốc độ nhập liệu là yêu cầu bắt buộc: đây là yếu tố quyết định PG có thực sự sử dụng hệ thống hay quay về ghi giấy. Một form chậm 40 giây sẽ bị bỏ ngay trong ngày đầu, và toàn bộ dữ liệu nghiệm thu mất theo.

G5 · Nhận hàng tại điểm

  • PG / Supervisor / PG tại từng điểm nhận bàn giao quà tặng và hàng hoá chuyển về
  • Đối chiếu số thực nhận với phiếu, chụp ảnh, xác nhận ★ Đề xuất
  • Nếu số thực nhận khác số trên phiếu → ghi số thực và lý do → sinh phiếu chênh lệch chờ Agency/Supervisor xử lý ★ Đề xuất
  • Cấu hình theo dự án: cần một người bất kỳ đang trực xác nhận, hay cần tất cả PG đang trực cùng xác nhận ★ Đề xuất

G6 · Bàn giao giữa hai ca

  • Bàn giao cá nhân – cá nhânnhóm – nhóm (nhập đầy đủ nhân sự bàn giao và nhận bàn giao của cả hai nhóm)
  • Nội dung bàn giao: hàng hoá và quà tặng tiêu hao · công cụ làm việc · dữ liệu phát sinh trong ca
  • Luồng: cuối ca hệ thống tự tính tồn còn lại theo sổ → PG ca trước đếm thực tế → nhập số thực → chụp ảnh → gửi bàn giao → PG ca sau xác nhận ★ Đề xuất
  • Nếu số thực đếm khác số theo sổ → sinh phiếu chênh lệch, ghi nhận trách nhiệm ca trước, chuyển Supervisor xử lý ★ Đề xuất
  • Nếu ca sau không xác nhận trong thời gian quy định → tự ghi nhận theo số ca trước khai và gắn dấu “chưa đối chiếu”, báo Supervisor ★ Đề xuất
  • Ca cuối ngày: bàn giao về “tồn qua đêm tại booth” thay vì bàn giao cho người ★ Đề xuất
Nguyên tắc thiết kế: không chặn cứng để vận hành không bị tắc tại booth. Mọi tình huống thiếu xác nhận đều được ghi nhận và báo lên, nhưng không được phép làm PG dừng phục vụ khách.

G7 · Báo cáo cuối ca ★ Đề xuất

Vì sao đề xuất: đây là tài liệu quan trọng nhất của mỗi ca làm việc và là nguồn dữ liệu chính cho báo cáo nghiệm thu. Không có báo cáo cuối ca, mọi số liệu phải tổng hợp lại thủ công vào cuối dự án.
  • Số lượt tương tác và số quà đã phát — hệ thống tự điền, PG xác nhận
  • Tồn kho cuối ca — hệ thống tự điền, PG đếm và xác nhận
  • Ảnh booth cuối ca
  • Ghi chú tình hình: đông / vắng, phản hồi của khách, vấn đề gặp phải
  • Ước lượng lượng người qua booth — nhập tay ở giai đoạn này

Chưa nộp báo cáo cuối ca thì ca chưa được coi là hoàn tất, có thể áp dụng mức phạt theo quy định dự án.

G8 · Báo cáo sự cố tại điểm

  • Các loại sự cố: mất hàng, khách khiếu nại, booth hỏng, thời tiết, an ninh — kèm ảnh và dấu thời gian, có luồng xử lý
  • Phân bốn mức độ; sự cố mức Cao và Khẩn cấp thông báo ngay cho Supervisor và người quản lý dự án ★ Đề xuất
  • Quy trình: Mới → Đang xử lý → Đã xử lý → Đóng, ghi rõ hướng xử lý và người xử lý ★ Đề xuất
  • Sự cố mất hàng liên kết trực tiếp sang phiếu chênh lệch kho để quy trách nhiệm ★ Đề xuất

G9 · Đơn từ trực tuyến (5 loại)

Toàn bộ đơn từ dùng chung một khung xử lý: người tạo · phạm vi (ca / dự án) · lý do · tệp đính kèm · luồng duyệt tối đa 2 cấp · thời hạn xử lý · kết quả và ghi chú người duyệt.

Loại đơnNghiệp vụ
Sửa lỗi chấm côngKhi hệ thống tự ghi lỗi đi muộn / về sớm nhưng PG có lý do chính đáng. Giới hạn 3 lần trong một dự án, cấu hình được theo từng quản lý. Phải nộp trong thời hạn quy định kể từ ca đó. Duyệt xong hệ thống tự cập nhật lại bản ghi công và gỡ điểm phạt tương ứng
Xin nghỉ caPG tạo đơn và được quản lý xác nhận thì không bị coi là bỏ ca. Quản lý cấu hình được: có bật chức năng này không, và phải xin nghỉ trước bao lâu. Duyệt xong ca thành trống và cảnh báo cần người thay thế
Xin nghỉ dự ánCho tình huống phát sinh ngoài kế hoạch khi dự án đang chạy. Được duyệt thì làm căn cứ chốt công tính lương, không bị coi là bỏ dự án hoặc đơn phương chấm dứt hợp đồng. Duyệt xong tự huỷ toàn bộ ca tương lai và chốt công đến ngày nghỉ
Xin đổi caPG muốn đổi ca với nhân sự khác. Cần cả người được đổi ca xác nhận và quản lý duyệt, làm căn cứ ghi lại việc phân ca thay đổi. Hệ thống chặn nếu người nhận đã có ca trùng giờ hoặc vượt giờ làm tối đa. Mức thù lao đi theo người thực làm
Yêu cầu thêm hàng hoá / công cụKhi hàng hoá, quà tặng hết hoặc công cụ cần thay thế, bổ sung. Duyệt xong tự sinh phiếu điều chuyển hàng từ kho trung tâm về điểm — không phải nhập lại

G10 · Tra cứu tài liệu

  • PG xem lại tài liệu đào tạo bất kỳ lúc nào trong dự án và thực hiện các bài kiểm tra được giao bổ sung

G11 · Công & thu nhập của tôi

  • PG theo dõi lịch sử chấm công của mình dạng lịch biểu dự án
  • Hệ thống thông báo cho PG ngay khi bị ghi lỗi đi muộn hoặc về sớm
  • Xem chi tiết: ngày công đã ghi nhận, từng khoản thưởng / phạt kèm lý do cụ thể, thu nhập tạm tính ★ Đề xuất
  • PG xác nhận thu nhập khi chốt lương
Vì sao cho PG xem chi tiết lý do bị trừ tiền: đây là biện pháp giảm tranh chấp hiệu quả nhất và rẻ nhất. Phần lớn khiếu nại lương đến từ việc PG không hiểu vì sao số tiền thấp hơn dự kiến.

Hàng hoá & Công cụ làm việc

5 chức năng

Mô hình kho hàng

Kho của Nhãn hàng — hệ thống KHÔNG quản lý kho này, chỉ gửi yêu cầu
Kho trung tâm của dự án
Kho tại Booth — nhận hàng cần PG đang trực xác nhận
Phát cho khách qua hoạt động tại điểm → trừ tồn
Bàn giao giữa các ca → chốt số, quy trách nhiệm
Trả về kho trung tâm → cần xác nhận hai đầu
Mỗi booth là một kho độc lập, có xuất – nhập – tồn đầy đủ. Tồn thuộc về booth; việc bàn giao ca chuyển trách nhiệm giữ hàng và là điểm chốt số để quy trách nhiệm khi phát sinh chênh lệch.

Hàng hoá chia hai nhóm khác nhau về bản chất: hàng tiêu hao (quà tặng, sản phẩm sampling, vật tư — phát đi là hết) và tài sản (điện thoại, bộ đàm, thẻ đeo, camera — mượn rồi trả, có tình trạng, có giá quy trách nhiệm).

H1 · Danh mục hàng hoá dự án

  • Quà tặng: loại quà, số lượng từng loại, mô tả, hình ảnh, lưu ý
  • Sản phẩm sampling: loại sản phẩm, hình ảnh, số lượng từng loại, lưu ý
  • Mỗi mặt hàng có giá / chi phí tương ứng nếu mất hoặc thất thoát
  • Phân nhóm: quà tặng / sản phẩm sampling / vật tư tiêu hao / công cụ làm việc; đơn vị tính; có quản lý theo mã riêng từng cái hay không ★ Đề xuất

H2 · Yêu cầu hàng gửi Nhãn hàng

  • Tạo yêu cầu gửi nhãn hàng: “ngày X cần 100 gấu bông về điểm Y”
  • Theo dõi trạng thái: Nháp → Đã gửi → Nhãn hàng xác nhận → Đã giao → Đã nhập kho
  • Hệ thống không quản lý kho của nhãn hàng, chỉ ghi nhận yêu cầu và kết quả giao nhận — đúng phạm vi Quý khách đã nêu

H3 · Phiếu kho, Sổ kho & Báo cáo Xuất–Nhập–Tồn

Loại phiếuTừ → ĐếnNgười xác nhận
Phiếu nhập khoNhãn hàng → Kho trung tâmQuản trị viên
Phiếu điều chuyểnKho trung tâm → BoothBên xuất và PG bên nhận
Phiếu phát quàBooth → KháchTự sinh từ hoạt động tại điểm
Phiếu bàn giao caPG ca trước → PG ca sauCả hai phía
Phiếu trả vềBooth → Kho trung tâmCả hai phía
Phiếu trả nhãn hàngKho trung tâm → Nhãn hàngQuản trị viên
Phiếu kiểm kê / điều chỉnhSupervisor hoặc Quản trị viên duyệt
  • Có thể nhập hàng thẳng từ nhãn hàng về booth, không nhất thiết qua kho trung tâm ★ Đề xuất
  • Kiểm kê kho tại các thời điểm: nhập hàng mới, nhập hàng cũ đã có mã, hàng thay thế sửa chữa
  • Sổ kho ghi từng dòng biến động; tồn luôn tính lại được từ sổ — đảm bảo số liệu không sai lệch âm thầm ★ Đề xuất
  • Không cho xoá phiếu đã xác nhận. Sai thì lập phiếu điều chỉnh ngược, giữ nguyên dấu vết ★ Đề xuất
  • Báo cáo Xuất – Nhập – Tồn – Trả lại theo Dự án × Kho × Mặt hàng × Khoảng thời gian, các cột: Đầu kỳ · Nhập · Phát ra · Chuyển đi · Chuyển đến · Trả lại · Thất thoát · Cuối kỳ

H4 · Chênh lệch & Thất thoát

Ghi nhận chênh lệch → quy ra giá trị → xác định người chịu trách nhiệm → chọn hướng xử lý → thông báo đến nhân sự thực hiện.

Hướng xử lýHệ quả
Bỏ qua (hao hụt trong định mức)Điều chỉnh sổ kho, không ảnh hưởng lương
Trừ vào lươngTự đẩy khoản khấu trừ sang bảng lương của PG
Bồi thường bằng tiền mặtGhi nhận riêng, không qua lương
Chuyển thành sự cốLập hồ sơ sự cố để điều tra
  • Mức khấu trừ tối đa trên thu nhập kỳ (đề xuất 30%), tránh trường hợp lương âm và rủi ro pháp lý ★ Đề xuất? Cần chốt
  • PG được quyền khiếu nại khoản khấu trừ trong thời hạn quy định ★ Đề xuất

H5 · Công cụ làm việc

  • Cấp phát công cụ làm việc cho PG theo từng dự án: điện thoại, sạc dự phòng, camera, thẻ đeo, bộ đàm…
  • Quản lý số lượng và tình trạng giao – nhận của từng người hoặc theo lô
  • Thiết bị chung của ekip: bàn giao giữa các ca làm việc, giữa hai người hoặc nhóm với nhóm — nhập đầy đủ nhân sự bàn giao và nhận bàn giao của cả hai nhóm
  • Mỗi công cụ có giá quy trách nhiệm tương ứng khi mất hoặc hỏng
  • Ghi nhận tình trạng khi giao/nhận (Tốt / Trầy xước / Hỏng / Mất) kèm ảnh ★ Đề xuất
Vì sao bắt buộc chụp ảnh tình trạng: đây là căn cứ duy nhất khi phát sinh tranh chấp về thiết bị hỏng hoặc mất giữa các ca.

Chấm công & Tính lương

8 chức năng

Chu trình xử lý ★ Đề xuất

Vì sao đề xuất bổ sung khâu Duyệt bảng công: yêu cầu ban đầu đi thẳng từ chấm công sang bảng lương. Trong thực tế đây là khâu sinh ra tranh chấp nhiều nhất. Nguyên tắc chúng tôi áp dụng: dữ liệu chấm công thô không bao giờ bị sửa; mọi điều chỉnh nằm ở tầng bảng công và đều ghi rõ người sửa cùng lý do.
  1. Dữ liệu chấm công thô — PG chấm công, hệ thống ghi nguyên trạng
  2. Bảng công ngày — hệ thống tự tính trạng thái công và điểm lỗi; Supervisor duyệt / điều chỉnh, PG được khiếu nại
  3. Bảng lương kỳ — cộng thưởng phạt, trừ tạm ứng, trừ thuế
  4. Chốt và chi trả — Agency chốt, khoá kỳ, PG xác nhận thu nhập

I1 · Quy tắc chấm công

Toàn bộ quy tắc là tham số cấu hình, thay đổi được theo từng dự án và theo mong muốn của từng nhãn hàng — đúng như yêu cầu “không áp cố định”.

Tham sốMặc định đề xuất
Bán kính cho phép chấm công 100 m
Chấm công sớm tối đa60 phút
Thời gian ân hạn không tính muộn 10 phút
Bậc thang đi muộnXem bảng dưới
Bậc thang về sớm Dùng chung bậc thang với đi muộn
Tự đóng ca khi quên chấm công ra Sau 2 giờ
Bắt buộc ảnh / GPS
Cho chấm công ngoài vùng Có, kèm lý do và cần duyệt

Bậc thang đi muộn ? Cần chốt — xem Q1

Mức đi muộnXử lý
Trong thời gian ân hạnKhông phạt
Ân hạn đến 15% thời lượng caTrừ 1 điểm
15% – 50% thời lượng caTrừ 2 điểm
Trên 50% thời lượng caKhông tính ca làm
  • Số bậc và ngưỡng đều thêm/bớt được, không cố định trong mã nguồn ★ Đề xuất
  • Bậc thang về sớm dùng cùng cấu trúc ★ Đề xuất
Vì sao bổ sung bậc thang về sớm: yêu cầu ban đầu chưa đề cập, nhưng về sớm là tình huống phổ biến ngang đi muộn — thiếu quy tắc này sẽ tạo lỗ hổng trong tính công.

I2 · Hệ thống lỗi & thưởng

  • Danh mục các loại lỗi và thưởng trong dự án, mỗi loại quy ra điểm số; mức độ lỗi/thưởng liên quan đến điểm số cụ thể
  • Ở các dự án khác nhau, một điểm tương ứng số tiền khác nhau — cấu hình riêng theo từng dự án
  • Hai cách ghi nhận: tự động (đi muộn, về sớm, vắng ca, không nộp báo cáo cuối ca, không xác nhận bàn giao) và ghi tay bởi Supervisor (đồng phục không đúng, thái độ với khách, vượt chỉ tiêu, được khách khen) ★ Đề xuất
  • Lỗi ghi tay bắt buộc có mô tả, thời điểm và người ghi; ảnh là tuỳ chọn ★ Đề xuất
  • PG được quyền khiếu nại lỗi ghi tay trong thời hạn quy định ★ Đề xuất
  • Mức phạt tối đa trên tổng thu nhập kỳ — tránh lương âm và rủi ro pháp lý ★ Đề xuất? Cần chốt
  • Toàn bộ lỗi và thưởng của từng cá nhân được tổng hợp vào bảng lương cuối cùng

I3 · Bảng công & Duyệt công ★ Đề xuất

  • Trạng thái công tự sinh: Đủ công / Đi muộn / Về sớm / Thiếu chấm công ra / Vắng ca / Không ghi nhận — kèm số phút đi muộn hoặc về sớm cụ thể
  • Hệ thống tự thông báo cho PG khi phát sinh lỗi
  • Supervisor duyệt công theo ngày hoặc theo tuần, duyệt hàng loạt cho cả điểm
  • Mọi điều chỉnh phải nhập lý do; bản ghi gốc giữ nguyên và hiển thị dấu “đã điều chỉnh”
  • Sau khi duyệt, PG không tạo được đơn sửa lỗi cho ca đó nữa trừ khi Supervisor mở lại
Vì sao Supervisor duyệt chứ không phải Điều phối viên — theo đúng góp ý của Quý khách. Điều phối viên có thể chính là một PG được nâng quyền, làm việc cùng nhóm mà mình duyệt công. Để họ vừa chấm vừa duyệt là mở đường cho thông đồng. Điều phối viên vẫn là người nắm tình hình thực tế nên giữ quyền đề xuất, nhưng người ký duyệt phải đứng ngoài nhóm.

Vì sao cần duyệt hàng loạt: một điểm có thể vài chục dòng công mỗi ngày; nếu bắt duyệt từng dòng thì người duyệt sẽ bấm cho xong và khâu kiểm soát mất tác dụng.

I4 · Bảng lương

Thành phầnCách tính
Tiền côngTổng (đơn giá ca × hệ số) — chỉ tính ca đã duyệt công
Thưởng / Phạt(điểm thưởng − điểm phạt) × mức quy đổi của dự án
Cộng thêmPhí PG dự phòng, phụ cấp, thưởng thêm khác
Khấu trừBồi thường thất thoát + khoản trừ phạt khác
Tạm ứngTổng đã tạm ứng trong kỳ
Thuế TNCNNếu áp dụng
Thực nhậnTiền công + Thưởng/Phạt + Cộng thêm − Khấu trừ − Tạm ứng − Thuế
  • Quản lý lương theo ngàytheo kỳ dự án, bao gồm ngày công, thưởng phạt theo quy tắc dự án, thưởng thêm và trừ phạt khác nếu có
  • Cấu hình cách tính tiền ca: trọn ca / theo giờ thực tế ? Cần chốt
  • Cấu hình kỳ chốt lương và quy tắc trả lương theo từng dự án ? Cần chốt
  • Khấu trừ thuế thu nhập cá nhân — bật/tắt theo dự án, tham số theo hướng dẫn của kế toán Quý khách ? Cần chốt
  • Chốt lương là khoá kỳ: sau khi chốt không sửa được chấm công, lỗi thưởng hay đơn giá của kỳ đó ★ Đề xuất
  • Phát hiện sai sau khi chốt → không mở khoá, mà lập khoản điều chỉnh sang kỳ kế tiếp, ghi rõ lý do và kỳ gốc ★ Đề xuất
  • Xuất bảng lương (Excel) và phiếu lương từng PG (PDF) theo mẫu
Vì sao không mở khoá kỳ đã chốt: đây là nguyên tắc kế toán chuẩn, bảo vệ tính toàn vẹn của số liệu đã nghiệm thu với nhãn hàng và đã chi trả cho PG.

I5 · Tạm ứng lương

  • Tạm ứng lương tương đương số ngày công đã làm
  • Chỉ tạm ứng trên phần công đã được duyệt; mức tối đa theo tỉ lệ cấu hình (mặc định 50%) ★ Đề xuất
  • Ghi nhận ngày, số tiền, người duyệt, hình thức chi; tự động trừ vào bảng lương kỳ ★ Đề xuất

I6 · PG xác nhận thu nhập

  • PG xác nhận thu nhập khi chốt lương
  • Không đồng ý → tạo khiếu nại kèm lý do → Agency xử lý → có thể sinh khoản điều chỉnh kỳ sau ★ Đề xuất
  • Quá thời hạn không phản hồi thì coi như đã xác nhận, quy định rõ trong chính sách dự án ★ Đề xuất

I7 · Hoàn ứng chi phí phát sinh tại điểm ★ Đề xuất

Vì sao đề xuất: tiền taxi chở hàng, tiền ăn ca, in gấp standee bị rách, mua thêm băng keo, tiền điện nước tại điểm — Supervisor thường ứng tiền túi rồi cuối tháng gom hoá đơn đi đòi. Không có chỗ ghi nhận thì mảng chi phí dự án luôn thiếu một khoản không nhỏ, và agency chỉ phát hiện lỗ sau khi đã nghiệm thu xong với nhãn hàng.
  • PG hoặc Supervisor tạo đề nghị thanh toán ngay tại chỗ: chụp hoá đơn, chọn loại chi phí, nhập số tiền, gắn với dự án và địa điểm cụ thể
  • Danh mục loại chi phí cấu hình được: vận chuyển · ăn ca · in ấn · vật tư · điện nước tại điểm · chi phí khác
  • Luồng duyệt hai cấp giống các đơn từ khác; có thể đặt hạn mức tự duyệt cho khoản nhỏ
  • Ghi nhận hình thức chi trả: hoàn tiền mặt, chuyển khoản, hoặc cộng vào bảng lương kỳ
  • Tổng hợp chi phí phát sinh theo dự án và theo địa điểm, đưa vào báo cáo nghiệm thu để đối soát với nhãn hàng nếu thuộc khoản nhãn hàng chịu

I8 · Danh mục ngày lễ & hệ số lương ★ Đề xuất

Vì sao đề xuất: yêu cầu ban đầu có nêu “ca làm việc vào ngày lễ tết giá khác” nhưng không có nơi nào khai báo ngày lễ. Nếu để Supervisor tự nhớ và sửa giá từng ca thì chắc chắn sót — mà sót ngày lễ là tranh chấp lương ngay lập tức.
  • Khai báo danh sách ngày lễ theo năm, dùng chung toàn hệ thống; cho phép thêm ngày đặc biệt riêng của từng dự án (ngày khai trương, ngày cao điểm)
  • Mỗi loại ngày gắn một hệ số lương: ngày thường · cuối tuần · ngày lễ · ngày cao điểm
  • Khi sinh lịch và phân ca, hệ thống tự nhận diện và áp hệ số, vẫn cho ghi đè thủ công từng ca nếu cần
  • Hiển thị rõ hệ số đang áp dụng trên bảng phân ca và trong chi tiết lương của PG

Đánh giá & Báo cáo nghiệm thu

7 chức năng

J1 · Đánh giá sau dự án

  • Bộ tiêu chí linh hoạt, tạo được mẫu dùng lại cho các dự án sau
  • Đánh giá theo từng giai đoạn (ví dụ: đánh giá khả năng học tập trong giai đoạn đào tạo, đánh giá khả năng làm việc) hoặc cho cả dự án
  • Ba chiều đánh giá: Supervisor đánh giá PG · Agency đánh giá Supervisor · Nhãn hàng đánh giá Agency
  • Cách thức đơn giản, thao tác nhanh tương tự đánh giá trên các ứng dụng phổ biến
  • Mỗi tiêu chí có tên, mô tả, thang điểm, trọng số, bắt buộc hay không; kèm ô nhận xét tự do ★ Đề xuất
  • Giai đoạn này đánh giá một chiều (không cho PG đánh giá ngược) để giữ hệ thống đơn giản ★ Đề xuất
  • Kết quả tổng hợp về hồ sơ PG, làm căn cứ lịch sử năng lực cho các dự án sau

J2 · Bảng điều khiển dự án

  • Tiến độ dự án, số điểm đang hoạt động
  • Nhân sự: tỉ lệ lấp đầy định biên, tỉ lệ đi làm đúng giờ, số ca vắng trong ngày
  • Chỉ tiêu KPI: mục tiêu so với thực tế, theo tổng, theo điểm, theo ngày
  • Tồn kho theo điểm kèm cảnh báo sắp hết hàng
  • Sự cố đang mở
  • Hiển thị khác nhau theo vai trò: Nhãn hàng xem chỉ tiêu và hình ảnh, không xem đơn giá và thông tin lỗi phạt của PG ★ Đề xuất

J3 · Báo cáo nghiệm thu

Đây là sản phẩm đầu ra quan trọng nhất — thứ Agency dùng để nghiệm thu và thanh toán với nhãn hàng.

#PhầnNội dung
1Tổng quanSố địa điểm, số ngày chạy, số ca, tổng giờ nhân sự
2Chỉ tiêu KPIMục tiêu so với thực tế, biểu đồ theo ngày / theo điểm / theo khung giờ
3Nhân sựSố lượt PG tham gia, tỉ lệ đi làm đúng giờ, danh sách nhân sự
4Hàng hoáNhập, phát ra, tồn, trả lại, thất thoát theo từng mặt hàng
5Dữ liệu khách hàngSố lượng thu thập được, phân bố theo điểm và theo ngày
6Hình ảnhẢnh booth theo từng điểm, ảnh hoạt động chọn lọc
7Sự cốDanh sách và hướng xử lý
8Đánh giáNhận xét của nhãn hàng
  • Xuất file PDF theo mẫu thiết kế riêng và Excel số liệu thô
  • Bàn giao dữ liệu khách hàng cho nhãn hàng là một thao tác riêng có ghi nhật ký (ai xuất, lúc nào, bao nhiêu bản ghi) — do đây là dữ liệu cá nhân ★ Đề xuất? Cần chốt

J4 · Báo cáo tổng thể

  • Báo cáo tổng hợp trên nhiều dự án, lọc theo thời gian, phân loại dự án, Agency, nhãn hàng, địa điểm — phục vụ đánh giá hiệu quả hoạt động chung của đơn vị

J5 · Tuỳ biến bảng điều khiển ★ Đề xuất

Vì sao đề xuất: mỗi vai trò quan tâm những con số khác nhau — Agency nhìn tỉ lệ lấp đầy nhân sự, Supervisor nhìn ca vắng hôm nay, Nhãn hàng nhìn chỉ tiêu. Cho phép tự sắp xếp giúp mỗi người thấy đúng thứ mình cần, thay vì phải xây nhiều màn hình riêng.
  • Thư viện widget (biểu đồ, con số, danh sách); người dùng kéo thả sắp xếp bảng điều khiển của mình; quản trị viên đặt bố cục mặc định cho từng vai trò

J6 · Phiếu kiểm tra điểm ★ Đề xuất

Vì sao đề xuất: Agency và nhãn hàng vẫn đi thị sát booth trong lúc chiến dịch chạy, hiện tại chỉ chụp ảnh gửi nhóm chat rồi thôi. Chuẩn hoá thành phiếu kiểm tra tạo ra bằng chứng độc lập bên cạnh số liệu do chính PG nhập — đây là thứ có sức thuyết phục cao nhất trong báo cáo nghiệm thu.
  • Người kiểm tra (Supervisor, Agency, hoặc Nhãn hàng) tạo phiếu ngay tại điểm trên điện thoại
  • Bộ tiêu chí kiểm tra cấu hình theo dự án: booth setup đúng thiết kế chưa · hàng hoá bày đủ chưa · PG có mặt đủ và mặc đồng phục đúng chưa · thái độ phục vụ · vệ sinh khu vực · vật phẩm truyền thông còn nguyên vẹn không
  • Mỗi tiêu chí có thang điểm và ô ghi chú; bắt buộc kèm ảnh minh chứng
  • Ghi nhận yêu cầu khắc phục kèm hạn xử lý, giao cho Supervisor phụ trách điểm; theo dõi đến khi đóng
  • Tổng hợp điểm kiểm tra theo địa điểm và theo thời gian, đưa vào báo cáo nghiệm thu

J7 · Đối soát số liệu với nhãn hàng ★ Đề xuất

Vì sao đề xuất: yêu cầu ban đầu coi báo cáo nghiệm thu là “xuất ra file là xong”. Thực tế nhãn hàng sẽ có ý kiến về số liệu, và việc trao đổi qua email kèm nhiều phiên bản file khiến quá trình thanh toán kéo dài. Có vết đối soát rõ ràng thì chốt nhanh hơn nhiều.
  • Agency gửi bản nháp báo cáo nghiệm thu cho nhãn hàng xem trực tiếp trên hệ thống
  • Nhãn hàng phản hồi theo từng mục số liệu — chấp nhận, hoặc nêu ý kiến kèm lý do
  • Agency giải trình hoặc điều chỉnh; mọi lần điều chỉnh đều ghi lại giá trị trước và sau, kèm người thực hiện
  • Khi hai bên thống nhất, báo cáo được chốt và khoá, xuất bản chính thức làm căn cứ thanh toán
  • Lưu toàn bộ lịch sử trao đổi và các phiên bản báo cáo

Thông báo, Truy vết & Tiện ích mở rộng

9 chức năng

K1 · Hệ thống thông báo

  • Kênh: thông báo trong ứng dụng (thời gian thực), thông báo đẩy về điện thoại, email, tin nhắn SMS/Zalo cho việc quan trọng
  • Mười loại sự kiện sinh thông báo: được phân ca · lịch thay đổi · bị ghi lỗi · đơn được duyệt hoặc từ chối · có phiếu hàng chờ xác nhận · có bàn giao chờ xác nhận · lương đã chốt · tài liệu mới · sự cố mức cao · nhắc trước giờ vào ca ★ Đề xuất

K2 · Gửi email hệ thống ★ Đề xuất

  • Hạ tầng gửi email và bộ mẫu email: mời ứng viên, thông báo kết quả tuyển dụng, gửi phiếu lương, gửi báo cáo định kỳ cho nhãn hàng. Mẫu email chỉnh sửa được trên giao diện

K3 · Nhật ký hoạt động & Lịch sử thay đổi dữ liệu ★ Đề xuất

Vì sao đề xuất — và khuyến nghị không cắt hạng mục này: không có nhật ký thì mọi tranh chấp về lương và hàng hoá đều không có căn cứ giải quyết. Đây là hạng mục ít được chú ý nhất nhưng lại là thứ bảo vệ đơn vị vận hành khi xảy ra sự cố.
  • Nhật ký thao tác: ghi lại mọi hành động ảnh hưởng đến tiền bạc và trách nhiệm — sửa bảng công, sửa đơn giá, xử lý thất thoát, chốt và mở lại lương, thay đổi chính sách dự án, xuất dữ liệu khách hàng. Kèm người thực hiện, thời điểm, địa chỉ IP
  • Lịch sử thay đổi dữ liệu: với các đối tượng quan trọng (phân công, chấm công, phiếu kho, bảng lương), ghi lại từng trường bị sửa, giá trị cũ và giá trị mới — tra cứu được bất kỳ lúc nào

K4 · Tác vụ nền & Hẹn giờ ★ Đề xuất

Vì sao đề xuất: nhiều nghiệp vụ phải chạy tự động theo thời gian, không thể chờ người bấm nút.
  • Tự đóng ca khi quên chấm công ra · tự tính điểm lỗi cuối ngày · gửi nhắc trước giờ vào ca · gửi nhắc ca chưa xác nhận · tự đánh dấu lời mời hết hạn · tổng hợp số liệu báo cáo định kỳ · dọn dẹp ảnh quá hạn lưu trữ. Có màn hình giám sát tác vụ và chạy lại khi lỗi

K5 · Tuỳ biến bảng danh sách ★ Đề xuất

Vì sao đề xuất: các màn hình danh sách trong hệ thống có rất nhiều cột (danh sách PG, phân ca, bảng công). Mỗi người dùng quan tâm bộ cột khác nhau. Không có tính năng này, màn hình sẽ hoặc quá tải hoặc thiếu thông tin.
  • Chọn cột hiển thị, sắp xếp thứ tự cột, đặt bộ lọc mặc định, lưu thành “chế độ xem” cá nhân và chuyển đổi nhanh giữa các chế độ xem

K6 · Trường dữ liệu mở rộng ★ Đề xuất

Vì sao đề xuất: mỗi nhãn hàng có thể yêu cầu thu thập thêm một vài thông tin đặc thù mà hiện tại chưa lường trước được. Có cơ chế này thì bổ sung trường mới là thao tác cấu hình, không phải yêu cầu phát triển và không phát sinh chi phí.
  • Thêm trường tuỳ chỉnh cho hồ sơ PG, thông tin dự án, thông tin địa điểm — chọn kiểu dữ liệu, đặt bắt buộc hay không, quyết định có hiển thị trong báo cáo hay không

K7 · Kết nối hệ thống bên ngoài ★ Đề xuất

Vì sao đề xuất: nhãn hàng thường đã có hệ thống CRM hoặc Zalo OA riêng và muốn dữ liệu khách hàng chảy về đó ngay trong lúc chiến dịch chạy, thay vì chờ cuối kỳ nhận file Excel.
  • Cơ chế bắn sự kiện tự động ra hệ thống bên ngoài khi có dữ liệu khách hàng mới, khi ca kết thúc, khi chỉ tiêu đạt mốc. Có màn hình cấu hình địa chỉ nhận, khoá bảo mật, nhật ký gửi và tự gửi lại khi lỗi

K8 · Giao diện & Quản lý menu ★ Đề xuất

  • Bố cục hiển thị, chế độ sáng / tối, thiết lập bộ nhận diện của đơn vị, quản lý menu và phân quyền hiển thị menu theo vai trò — mỗi vai trò chỉ nhìn thấy đúng những mục mình được dùng

K9 · Giám sát hệ thống & Trang bảo trì ★ Đề xuất

  • Trang kiểm tra tình trạng hệ thống (máy chủ, cơ sở dữ liệu, lưu trữ, tác vụ nền); trang thông báo bảo trì khi cần nâng cấp; theo dõi dung lượng lưu trữ ảnh và cảnh báo khi sắp đầy

Giao diện lập trình cho ứng dụng mobile

5 hạng mục
Bao gồm toàn bộ API phục vụ ứng dụng của PG. Không bao gồm việc lập trình ứng dụng — phần xây dựng app iOS/Android là hạng mục riêng.

L1 · Thiết kế & chuẩn hoá API

  • Rà soát toàn bộ giao diện lập trình dùng cho mobile, chuẩn hoá định dạng dữ liệu và mã lỗi, quản lý phiên bản API để ứng dụng cũ vẫn chạy được khi máy chủ nâng cấp

L2 · Xác thực cho thiết bị di động

  • Xác thực bằng token, cơ chế duy trì phiên dài ngày (PG không phải đăng nhập lại mỗi ca), tự động làm mới token, thu hồi quyền truy cập khi tài khoản bị khoá

L3 · API đồng bộ dữ liệu offline

  • Quy chuẩn dữ liệu cho chấm công và ghi nhận hoạt động khi mất mạng; nhận dữ liệu theo lô; xử lý bản ghi trùng lặp khi ứng dụng gửi lại; ghi nhận cả thời điểm trên thiết bị và thời điểm máy chủ nhận để đối chiếu; xử lý xung đột khi cùng một ca có nhiều bản ghi

L4 · Tối ưu cho mạng yếu

  • Phân trang, rút gọn dữ liệu trả về, tải ảnh có nén, tự động gửi lại khi lỗi, giảm dung lượng truyền tải
Vì sao cần hạng mục riêng: booth thường đặt trong trung tâm thương mại hoặc toà nhà — nơi sóng di động yếu. Không tối ưu thì PG sẽ không dùng được ứng dụng đúng lúc cần nhất.

L5 · Tài liệu & bộ công cụ cho đội mobile

  • Tài liệu API đầy đủ, bộ mẫu gọi thử, thư viện kết nối sinh tự động cho ứng dụng, tài liệu hướng dẫn tích hợp và môi trường thử nghiệm riêng

PHẦN IIITham số cấu hình theo dự án

Toàn bộ 51 tham số dưới đây thay đổi được cho từng dự án mà không cần lập trình lại và không phát sinh chi phí.

#Tham sốMặc định
CHẤM CÔNG
1Bán kính cho phép chấm công (m)100
2Chấm công sớm tối đa (phút)60
3Thời gian ân hạn không tính muộn (phút)10
4Bậc thang đi muộn (số bậc và ngưỡng)3 bậc
5Bậc thang về sớm3 bậc
6Giờ tự đóng ca khi quên chấm công ra2 giờ
7Bắt buộc chụp ảnh khi chấm công
8Bắt buộc có GPS
9Cho phép chấm công ngoài vùngCó, cần lý do và duyệt
LỖI & THƯỞNG
10Danh mục lỗi / thưởng và điểm sốSao chép từ mẫu
11Quy đổi 1 điểm = bao nhiêu tiềnTheo dự án
12Mức phạt tối đa (% thu nhập kỳ)30%
13Thời hạn khiếu nại lỗi (ngày)3
LƯƠNG
14Cách tính tiền ca (trọn ca / theo giờ)Trọn ca
15Kỳ chốt lươngTheo dự án
16Bật khấu trừ thuế TNCNTắt
17Ngưỡng và tỉ lệ khấu trừ thuếTheo kế toán
18Bật tạm ứng lươngTắt
19Mức tạm ứng tối đa (%)50%
20Thời hạn PG xác nhận thu nhập (ngày)5
21Hệ số lương theo loại ngày (thường / cuối tuần / lễ / cao điểm)1,0 / 1,0 / 2,0 / 1,5
ĐƠN TỪ
22Bật đơn sửa lỗi chấm côngBật
23Số lần sửa lỗi tối đa trong dự án3
24Thời hạn nộp đơn sửa lỗi (ngày)3
25Bật đơn xin nghỉ caBật
26Phải xin nghỉ ca trước (giờ)24
27Bật đơn xin nghỉ dự ánBật
28Bật đơn đổi caBật
29Bật đơn yêu cầu thêm hàngBật
30Cấp duyệt đơnSupervisor → Agency
KHO HÀNG
31Số người xác nhận khi nhận hàng tại booth1 người / Tất cả
32Bắt buộc bàn giao ca
33Cho phép tồn âm tạm thời
34Thời gian tự xác nhận bàn giao (phút)30
35Mức hao hụt cho phép (%)0
ĐÀO TẠO & HỢP ĐỒNG
36Bắt buộc hoàn thành đào tạo trước ca đầuTắt
37Bắt buộc đạt bài kiểm traTắt
38Điểm đạt bài kiểm tra (%)70
39Số lần làm lại bài kiểm tra3
40Thời gian làm bài (phút)15
41Bắt buộc ký hợp đồng trước ca đầuBật
HOẠT ĐỘNG TẠI ĐIỂM
42Danh sách loại hoạt động và cấu hình từng loạiTheo dự án
43Bật checklist mở / đóng boothBật
44Nội dung checklistTheo dự án
45Bắt buộc báo cáo cuối caBật
46Cảnh báo trùng số điện thoại kháchBật
ĐÁNH GIÁ & KHÁC
47Bộ tiêu chí đánh giáSao chép từ mẫu
48Thời điểm đánh giáCuối dự án
49Bật PG dự phòngTắt
50Mức phí PG dự phòngTheo dự án
51Số giờ làm tối đa của một PG trong ngày12

PHẦN IVVòng đời trạng thái & Phân quyền

4.1 · Vòng đời trạng thái

Đối tượngVòng đời
Dự ánNháp → Đang tuyển → Sẵn sàng → Đang chạy → Kết thúc vận hành → Đã nghiệm thu → Đã chốt lương → Đóng
Ứng viênMới nộp → Đã liên hệ → Hẹn phỏng vấn → Đã phỏng vấn → Đạt → Đã gửi lời mời → Đã xác nhận
Nhánh rẽ: Không đạt / Từ chối / Không phản hồi
Hồ sơ PGNháp → Chờ duyệt → Đã duyệt / Từ chối
Song song: Cấp 1 → Đầy đủ
Phân côngĐã phân → Đã xác nhận → Đang làm → Hoàn thành
Nhánh rẽ: Vắng ca / Đã huỷ / Đã đổi
Chấm côngĐã ghi nhận → Chờ duyệt → Đã duyệt
Nhánh rẽ: Đã điều chỉnh / Từ chối
Phiếu khoNháp → Chờ xác nhận → Đã xác nhận
Nhánh rẽ: Có chênh lệch → Chờ xử lý → Đã xử lý
Đơn từNháp → Chờ duyệt → Đã duyệt / Từ chối → Đã áp dụng
Sự cốMới → Đang xử lý → Đã xử lý → Đóng
Bảng lươngNháp → Chờ duyệt → Đã duyệt → Đã chốt → Đã trả
Hợp đồngNháp → Chờ ký → Đã ký
Nhánh rẽ: Từ chối / Đã huỷ

Các ràng buộc bảo vệ dữ liệu

4.2 · Ma trận phân quyền

Hành độngQuản trị viênAgencySupervisorPGNhãn hàng
Tạo / sửa dự án
Sửa chính sách dự án
Xem giá bán (nhãn hàng trả)
Xem giá trung gian
Xem giá chi trả cho PG
Tuyển dụng, duyệt ứng viên
Phân ca
Sửa lịch ca
Chấm công
Ghi lỗi / thưởng
Duyệt bảng công
Chốt lương
Duyệt đơn từ
Tạo đơn từ
Xuất kho trung tâm về booth
Xác nhận nhận hàng tại booth
Xử lý thất thoát
Ghi nhận hoạt động tại điểm
Xem dữ liệu khách hàng chi tiết
Xem báo cáo nghiệm thu
Xem thông tin cá nhân / CCCD của PG

Toàn quyền  ·  Có điều kiện, theo phạm vi địa điểm được giao hoặc chỉ dữ liệu của chính mình  ·  Không được phép  ·  — Không áp dụng

PHẦN VNội dung cần Quý khách xác nhận

Các nội dung dưới đây ảnh hưởng trực tiếp đến thiết kế hệ thống. Chúng tôi đã kèm sẵn phương án đề xuất dựa trên kinh nghiệm triển khai — Quý khách chỉ cần duyệt hoặc điều chỉnh. Cần chốt trước mốc M0 (tuần thứ 3).

5.1 · Ưu tiên cao — ảnh hưởng lớn tới thiết kế hệ thống

#Nội dung cần xác nhậnĐề xuất của chúng tôi
Q1Bậc thang đi muộn. Mô tả trong yêu cầu hiện đang chồng lấn: "từ 15% thời lượng ca trừ 1 điểm" rồi "15–50% trừ 2 điểm"Trong ân hạn (10 phút): không phạt · Ân hạn đến 15%: trừ 1 điểm · 15–50%: trừ 2 điểm · Trên 50%: không tính ca
Q2Về sớm tính thế nào? Yêu cầu hiện chưa đề cập nhưng thực tế phổ biến ngang đi muộnDùng cùng bậc thang với đi muộn
Q3Tiền công tính trọn ca hay theo giờ thực tế? Ví dụ ca 4 giờ, PG về sớm 30 phút thì trả bao nhiêu?Mặc định trọn ca — đúng thực tế thuê PG theo ca; đi muộn về sớm xử lý bằng điểm phạt. Vẫn cho phép chuyển sang tính theo giờ ở dự án cần
Q7Khi triển khai qua Supervisor, ai trả tiền cho PG? Agency trả thẳng PG, hay trả Supervisor rồi Supervisor tự trả?Hỗ trợ cả hai phương án bằng một tuỳ chọn ở cấp dự án
Q12Mini game triển khai đến đâu ở giai đoạn này?Hệ thống ghi nhận kết quả trò chơi và trừ quà tương ứng. Việc xây dựng trò chơi tương tác là hạng mục riêng
Q18Quy mô vận hành thực tế? Bao nhiêu địa điểm, bao nhiêu lượt tương tác mỗi ngày?Cần con số cụ thể. Tham khảo: 50 điểm × 300 lượt/ngày × 2 ảnh × 30 ngày ≈ 900.000 ảnh cho một chiến dịch — con số này quyết định phương án lưu trữ hình ảnh
Q19Nhãn hàng xem số liệu theo thời gian thực hay chỉ xem báo cáo cuối?Cho xem thời gian thực ở mức tổng hợp (chỉ tiêu, hình ảnh booth) — đây là điểm thuyết phục mạnh nhất khi làm việc với nhãn hàng
Q6Khấu trừ thuế thu nhập cá nhân có triển khai ở giai đoạn này?Xây dựng sẵn công thức nhưng mặc định tắt, bật khi bộ phận kế toán xác nhận cách áp dụng

5.2 · Nghiệp vụ — cần chốt để đặc tả

#Nội dung cần xác nhậnĐề xuất của chúng tôi
Q4Ai duyệt bảng công?Supervisor duyệt theo ngày/tuần, Agency chốt kỳ. Dự án không có Supervisor thì Agency làm cả hai bước
Q5Kỳ chốt lương?Mặc định theo dự án; cho phép chốt tạm theo tuần với dự án dài
Q8Mức khấu trừ và phạt tối đa?30% thu nhập kỳ, cấu hình được — đề nghị rà soát với bộ phận pháp lý
Q9Phát quà có bắt buộc kèm thông tin khách hàng không?Cấu hình theo từng loại hoạt động: quà giá trị thấp không bắt buộc, quà giá trị cao bắt buộc có thông tin và ảnh
Q10Một khách nhận quà nhiều lần trong dự án — chặn hay cho phép?Ba mức cấu hình: không giới hạn / 1 lần mỗi ngày / 1 lần cả dự án. Mặc định cảnh báo nhưng không chặn
Q11Nhãn hàng được xem dữ liệu khách hàng ở mức nào và khi nào?Xem số liệu tổng hợp theo thời gian thực; dữ liệu chi tiết bàn giao khi nghiệm thu qua thao tác có ghi nhật ký
Q13PG chưa có CCCD — chặn ở bước nào?Chặn ở bước phân ca; vẫn cho vào danh sách nhân sự dự án để theo dõi
Q14Bắt buộc ký hợp đồng trước ca đầu tiên?Mặc định bắt buộc (chặn chấm công nếu chưa ký), cho phép tắt ở dự án chạy gấp
Q15Lịch sử và đánh giá PG có chia sẻ giữa các Agency không?Giai đoạn này hoàn toàn không chia sẻ; thiết kế sẵn để bật về sau khi có chính sách rõ ràng
Q16Kho trung tâm theo từng dự án hay dùng chung?Theo từng dự án để dễ đối soát với nhãn hàng; hàng thừa chuyển sang dự án khác bằng phiếu điều chuyển
Q17Có cần quản lý hạn sử dụng và theo lô hàng không?Giai đoạn này chỉ ghi nhận hạn sử dụng ở mức mặt hàng và cảnh báo. Quản lý theo lô sẽ làm tăng đáng kể chi phí và độ phức tạp

5.3 · Tình huống vận hành cần Quý khách cung cấp thêm thông tin

Bảy tình huống dưới đây chắc chắn xảy ra trong thực tế nhưng chưa được mô tả trong yêu cầu. Chúng tôi chưa đủ căn cứ để tự quyết, và nếu thiết kế theo phỏng đoán rồi sai thì phải làm lại — nên cần Quý khách xác nhận trước khi bước vào giai đoạn đặc tả.

#Nội dung cần xác nhậnĐề xuất của chúng tôi
Q20Ca làm việc qua nửa đêm tính vào ngày nào? Ví dụ ca 21:00–01:00. Ảnh hưởng đồng thời tới chấm công, bậc thang đi muộn/về sớm, hệ số ngày lễ và kỳ chốt lươngTính trọn ca vào ngày bắt đầu ca; hệ số ngày lễ cũng lấy theo ngày bắt đầu. Quy ước sai thì tính lương sai hàng loạt và rất khó phát hiện
Q21Supervisor có chấm công không? Nếu khoán theo khối lượng thì căn cứ nghiệm thu là gì — số ca PG đã chạy, số điểm phụ trách, hay số ngày dự án?Hỗ trợ hai kiểu: tính theo công thì chấm công như PG; khoán thì chốt theo số điểm phụ trách × số ngày vận hành. Cần Quý khách chọn kiểu áp dụng
Q22Nhãn hàng huỷ địa điểm giữa chừng thì ca đã phân có trả tiền cho PG không?Thiết kế hai trạng thái huỷ riêng: huỷ có trả tiền (báo muộn hơn ngưỡng, tính theo tỉ lệ cấu hình được) và huỷ không trả tiền. Ngưỡng và tỉ lệ do Quý khách quyết theo thoả thuận với nhãn hàng
Q23Quà tặng và sản phẩm còn thừa cuối dự án xử lý thế nào? Trả nhãn hàng, Agency giữ lại, hay thanh lý? Ai quyết?Mặc định trả về nhãn hàng bằng phiếu trả có xác nhận hai bên. Chuyển sang dự án khác hoặc thanh lý cần bước phê duyệt riêng vì đây là tài sản của nhãn hàng
Q24PG nghỉ giữa dự án thì công cụ đã cấp phát thu hồi ra sao? Có tạm giữ một phần lương đến khi trả đủ thiết bị không?Cho phép tạm giữ một khoản trong bảng lương đến khi hoàn tất bàn giao, mức cấu hình theo dự án. Cần xác nhận có áp dụng không vì phải ghi rõ trong hợp đồng với PG
Q25Một PG làm hai dự án khác nhau của cùng Agency trong một ngày — có cho phép không? Giới hạn giờ tính gộp hay tính riêng?Cho phép, nhưng giới hạn giờ tính gộp trên toàn bộ dự án của cùng Agency; hệ thống cảnh báo khi vượt ngưỡng
Q26Dữ liệu khách hàng trùng giữa các dự án của cùng một nhãn hàng — gộp thành một tệp hay mỗi dự án một tệp riêng?Mỗi dự án giữ tệp riêng để đối soát rạch ròi; đồng thời đánh dấu khách đã xuất hiện ở dự án trước để nhãn hàng biết tỉ lệ khách mới / khách cũ — chỉ số nhãn hàng rất quan tâm

PHỤ LỤCTổng hợp các hạng mục chúng tôi đề xuất bổ sung

Dưới đây là những nội dung không có trong yêu cầu ban đầu nhưng chúng tôi khuyến nghị đưa vào Giai đoạn 1, kèm lý do.

#Hạng mụcVì sao cần
1Khâu Duyệt bảng công giữa chấm công và tính lươngYêu cầu đi thẳng từ chấm công sang lương. Đây là khâu sinh ra tranh chấp nhiều nhất trong thực tế
2Mô hình Hoạt động tại điểm thống nhấtGom phát quà, sampling, thu data, mini game về một mô hình — thêm hình thức mới sau này không phát sinh chi phí phát triển
3Báo cáo cuối caNguồn dữ liệu chính cho báo cáo nghiệm thu; không có thì phải tổng hợp thủ công cuối dự án
4Checklist mở / đóng boothBằng chứng hình ảnh rẻ nhất và thuyết phục nhất với nhãn hàng
5Bảng giá ba lớpGiải bài toán Supervisor hưởng chênh lệch mà Quý khách đã nêu
6Điểm tin cậy của PGBỏ ca là rủi ro tốn kém nhất; cần nhìn thấy trước khi phân ca
7Mẫu ca và sinh lịch theo quy tắc lặpGiải bài toán “nhiều tuần, cách ngày, giờ khác nhau từng ngày”
8Giới hạn phạm vi chấm công, xử lý quên chấm công ra, bậc thang về sớmBa tình huống xảy ra hàng ngày mà yêu cầu ban đầu chưa nêu
9Mức phạt và khấu trừ tối đaTránh lương âm và rủi ro pháp lý
10Khoá kỳ lương và điều chỉnh sang kỳ sauBảo vệ tính toàn vẹn của số liệu đã nghiệm thu
11Ô đồng ý thu thập dữ liệu khách hàngYêu cầu bắt buộc theo Nghị định 13/2023 về bảo vệ dữ liệu cá nhân
12Xác thực OTP chống spam form ứng tuyểnKhông có thì dữ liệu ứng viên bị spam ngay tuần đầu
13Nhật ký hoạt động và lịch sử thay đổi dữ liệuKhông có thì mọi tranh chấp lương và hàng hoá đều không có căn cứ giải quyết
14Sao chép dự ánTiết kiệm thời gian lớn nhất cho đơn vị chạy chiến dịch lặp lại theo quý
15Thao tác hàng loạt ở quản lý ứng viên và duyệt côngQuy mô vài trăm bản ghi mỗi ngày, không thể xử lý từng dòng
16Xác thực hai lớpTài khoản Agency nắm quyền chốt lương — bị chiếm quyền là thiệt hại tài chính trực tiếp
17Đăng nhập bằng OTP cho PGPG quên mật khẩu là nguyên nhân số một khiến không chấm công được tại điểm
18Nhập dữ liệu hàng loạt từ ExcelRào cản lớn nhất khiến dự án chậm khởi động là đưa dữ liệu ban đầu vào hệ thống
19Đa ngôn ngữNhãn hàng đa quốc gia cần xem báo cáo; làm sau tốn kém hơn nhiều
20Trường dữ liệu mở rộngNhãn hàng phát sinh yêu cầu thu thêm thông tin — cấu hình thay vì phát triển mới
21Thay người khẩn cấp khi PG bỏ caTình huống xảy ra gần như mỗi ngày và tốn kém nhất; hiện Supervisor phải gọi điện lần lượt từng người
22Hoàn ứng chi phí phát sinh tại điểmSupervisor ứng tiền túi cho taxi, ăn ca, in gấp — không có chỗ ghi nhận thì chi phí dự án luôn thiếu một khoản
23Phiếu kiểm tra điểmBằng chứng độc lập bên cạnh số liệu do chính PG nhập — có sức thuyết phục cao nhất khi nghiệm thu
24Đối soát số liệu với nhãn hàng trước khi chốtNhãn hàng luôn có ý kiến về số liệu; có vết đối soát thì thanh toán nhanh hơn nhiều
25Checklist đóng dự ánKhông có thì công cụ thất lạc, hàng thừa không ai trả, lương treo vài tháng
26Danh mục ngày lễ & hệ số lươngYêu cầu có nêu “ca ngày lễ giá khác” nhưng không có nơi khai báo; để nhớ thủ công là sót và tranh chấp
27Luân chuyển hàng giữa hai điểmĐiểm A thừa, điểm B hết — thực tế chạy xe qua thẳng, không ai đem về kho rồi phát lại
28Ca mở cho PG tự nhậnVới hàng chục địa điểm, phân ca thủ công từng người là khối lượng rất lớn và luôn trễ

Chúng tôi sẵn sàng trao đổi chi tiết từng hạng mục và điều chỉnh phạm vi triển khai theo kế hoạch ngân sách của Quý khách.

Người liên hệ: [Họ tên] · [Điện thoại] · [Email]