Deel
Deel là nền tảng HR & payroll toàn cầu. Giúp doanh nghiệp tuyển dụng, trả lương, quản lý hợp đồng, thuế và tuân thủ pháp lý cho nhân sự ở nhiều quốc gia, không cần thành lập pháp nhân.
- Bắt đầu
- Vai trò và quyền hạn
- Quản lý nhân sự
- Nghỉ phép
- Engage
- Lương thưởng
- Quản lý nhân tài
- Hoạch định lực lượng lao động
- Báo cáo
- Tích hợp & API
Bắt đầu (Deel HR)
- Tạo/xác nhận tổ chức (client org) và thiết lập nền tảng.
- Hiểu “People” hub (nhân sự, tác vụ, cấu trúc).
- Cài thông báo + biết chỗ có hỗ trợ/đào tạo.
- Có checklist rollout tuần đầu gọn gàng.
1) Mục đích, dành cho ai, và bấm ở đâu
Tab này giúp bạn vào Deel với vai trò client và thiết lập nền tảng tối thiểu để các tính năng Deel HR còn lại “khớp” với nhau. Mục tiêu là giảm lỗi setup và biến tuần đầu dùng nền tảng trở nên dễ đoán, có trình tự.
- Dành cho: HR admins, ops, finance/people ops quản lý nhân sự và quy trình HR.
- Khi nào dùng: trước khi import nhân sự, bật tính năng HR, hoặc mời quản lý.
- Vị trí trong điều hướng: Help Center → For business → Account Access → Getting Started.
- Tab liên quan: People Management (tasks/workflows), Roles & Permissions, Integrations & API.
- Kết quả: bạn đăng nhập ổn định, tìm đúng menu chính, và biết “bước tiếp theo là gì”.
2) Mô hình tư duy (luồng tuần đầu)
Hãy coi Deel HR là một nơi tập trung để lưu hồ sơ nhân sự và chạy các quy trình HR lặp lại được (tác vụ, phê duyệt, tài liệu, nghỉ phép, báo cáo). Bước đầu tốt nhất là ổn định quyền truy cập + thiết lập tổ chức, sau đó chuyển sang People và workflows.
- Xác nhận tài khoản + ngữ cảnh tổ chức (đúng workspace/org).
- Cài thông báo để không bỏ lỡ phê duyệt và tác vụ.
- Mở People hub để hiểu hồ sơ nhân sự + hành động liên quan.
- Chọn cách rollout: nhóm pilot → rồi mở rộng.
- Sau cùng: kết nối integrations + dashboard báo cáo.
3) Các đối tượng & thuật ngữ bạn sẽ gặp sớm
Đây là các nhãn thường gặp trong Getting Started và các workflow People lân cận. Nắm các khái niệm này giúp bạn đỡ rối khi đọc help/training người khác.
- Tài khoản client / Tổ chức (Organization): ngữ cảnh pháp nhân/doanh nghiệp bạn đang quản lý.
- Workspace: nơi bạn chuyển ngữ cảnh trong Deel (tuỳ UI có thể khác).
- Hồ sơ nhân sự (Worker profile): bản ghi một người (có thể cần gộp nếu bị trùng).
- Tác vụ / checklist onboarding: các bước vận hành giao cho nhân sự/admin.
- Inbox / Thông báo: nơi các việc cần xử lý và cập nhật xuất hiện.
- Academy: cổng đào tạo chính thức.
4) Vòng đời / state machine
Getting Started không phải state machine cứng, nhưng bạn có thể coi nó là “bậc thang sẵn sàng”: truy cập → quan sát → quy trình → mở rộng. Cách này giúp tránh kiểu “làm integrations trước” rồi loạn.
- Trạng thái A: Đăng nhập được + xác nhận đúng org/workspace.
- Trạng thái B: Cấu hình thông báo + hiểu Inbox.
- Trạng thái C: Mở People hub + hiểu các thao tác nhân sự cơ bản.
- Trạng thái D: Chạy pilot workflow (tasks/time off/docs) cho nhóm nhỏ.
- Điều kiện chuyển trạng thái: chỉ sang bước tiếp khi bước trước cho ra kết quả ổn định, dự đoán được.
5) Các việc cốt lõi cần làm (JTBD)
Thắng lợi đầu tiên thường nhỏ: truy cập ổn định, thông báo rõ ràng, và một routine lặp lại được cho vận hành nhân sự. Dùng các job này như “starter backlog”.
- Đăng ký / hoàn tất onboarding client và xác nhận thiết lập tổ chức.
- Tìm và dùng Inbox cho các việc vận hành hằng ngày.
- Cấu hình thông báo cho phê duyệt và sự kiện quan trọng.
- Xác định nơi thao tác People nằm (tasks, cấu trúc, chỉnh sửa).
- Training 1 quản lý về trách nhiệm và màn hình họ sẽ dùng.
- Tìm đúng nguồn học chính thức để chia cho team.
6) Luồng chuẩn #1 — “Ngày 0: sẵn sàng cho admin”
Dùng ngay khi bạn vừa có quyền truy cập và muốn chắc chắn không bỏ lỡ yêu cầu/phê duyệt.
- Đăng nhập và xác nhận bạn đang ở đúng organization/workspace.
- Mở Inbox phía client và lướt xem các loại mục thường xuất hiện.
- Mở cài đặt thông báo và bật các cảnh báo bạn cần cho vận hành hằng ngày.
- Ghi lại routine hằng ngày: Inbox → approvals → tasks → escalations.
- Mời 1 đồng đội (hoặc manager) để kiểm thử luồng truy cập end-to-end.
- Bookmark 2–3 bài help bạn sẽ dùng lại (vd: notifications, Inbox, Academy).
7) Luồng chuẩn #2 — “Tuần 1: rollout nhóm pilot”
Dùng khi bạn muốn rollout Deel HR an toàn (nhóm nhỏ trước), trước khi coi nó là system of record.
- Chọn nhóm pilot (vd: 1 team hoặc 5–20 nhân sự).
- Trong People, kiểm tra mỗi người pilot có 1 profile sạch (gộp trùng nếu cần).
- Gán một checklist onboarding nhỏ hoặc một vài tasks để test luồng tác vụ.
- Xác thực một luồng phê duyệt (vd: nghỉ phép hoặc yêu cầu tài liệu) từ worker → manager → admin.
- Ghi lại vấn đề: thiếu field, owner không rõ, lỗi phân quyền.
- Cập nhật SOP nội bộ rồi mở rộng sang nhóm tiếp theo.
- Đặt lịch review 15 phút mỗi tuần: lỗi, độ trễ phê duyệt, thiếu dữ liệu.
8) Điểm quyết định (A/B)
Các lựa chọn này quyết định tốc độ rollout và số lượng vấn đề bạn sẽ phải “đuổi” về sau.
| Quyết định | Nếu chọn A… | Nếu chọn B… |
|---|---|---|
| Pilot hay rollout một lần | Pilot trước → ít bất ngờ, khởi đầu chậm hơn | Rollout hết → nhanh hơn, rủi ro cao hơn |
| Mức độ thông báo | Nhiều cảnh báo → ít bỏ sót, nhiều “nhiễu” | Ít cảnh báo → yên hơn, dễ bỏ sót |
| Ai sở hữu Inbox hằng ngày | Một người sở hữu → rõ trách nhiệm | Inbox chung → có cover, nhưng dễ bị “bỏ quên” |
| Cách training | Enablement ngắn mỗi tuần → thấm dần | Một buổi dài → nhanh, nhưng khó nhớ lâu |
9) Lỗi thường gặp + guardrails
Hầu hết vấn đề sớm đến từ ownership mơ hồ và bỏ qua pilot. Dùng các guardrail này để tránh “lao xuống hố”.
- Lỗi: mời người trước khi định nghĩa role → Tránh: set Roles & Permissions trước.
- Lỗi: bỏ qua Inbox/notifications → Tránh: routine hằng ngày + “vệ sinh” thông báo.
- Lỗi: profile nhân sự bị trùng → Tránh: gộp profile trước khi scale.
- Lỗi: không có SOP nội bộ → Tránh: viết 1 trang “cách team mình dùng Deel”.
- Lỗi: làm integrations quá sớm → Tránh: ổn định People + workflows trước.
10) “Thế nào là tốt” + checklist + bài thực hành + tài liệu chính thức
Dùng như “definition of done” cho Getting Started. Nếu tick hết, bạn sẵn sàng chuyển sang People workflows và các module HR.
Thế nào là tốt
- Admins vào đúng org mỗi lần.
- Inbox và thông báo được theo dõi hằng ngày.
- Ít nhất 1 manager đã xác nhận màn hình + trách nhiệm.
- Nhóm pilot chạy xong 1 workflow nhỏ end-to-end.
Checklist: Trước khi làm
- Xác nhận đúng org/workspace
- Rà soát cài đặt thông báo
- Hiểu Inbox và có người sở hữu
- Chọn nhóm pilot
- Gán owner nội bộ
Checklist: Sau khi làm
- Hoàn thành 1 workflow end-to-end
- Log issue và ưu tiên
- Chia sẻ link training nội bộ
- Lên lịch nhóm rollout tiếp theo
- Set lịch review hằng tuần
Bài thực hành (5–15 phút)
Mục tiêu: set “nhịp vận hành” hằng ngày để việc không bị thất lạc.
- Mở Inbox và xác định 2 loại mục bạn sẽ xử lý thường xuyên.
- Chỉnh thông báo để chắc chắn bạn thấy approvals/tasks.
- Viết routine 4 bước mỗi ngày và gửi cho 1 đồng đội.
- Bookmark các bài help bạn vừa dùng hôm nay.
Link tài liệu chính thức (tên bài)
- Cách tạo tài khoản Deel cho client và hoàn tất onboarding
- Cách client dùng Deel Inbox
- Client quản lý Notifications như thế nào?
- Bắt đầu học với Deel Academy
Vai trò & Phân quyền
- Nắm các vai trò admin chính (Org Admin, Group Admin, Manager).
- Gán vai trò quản lý theo cách “an toàn”.
- Tránh cấp quyền quá rộng với dữ liệu payroll/HR.
- Tạo thói quen rà soát quyền truy cập lặp lại được.
1) Mục đích, dành cho ai, và bấm ở đâu
Roles quyết định ai có thể xem và làm gì trong Deel HR. Mục tiêu rất đơn giản: cấp cho đúng người đúng quyền cần để làm việc—và không hơn.
- Dành cho: Org Admins, HR admins, Ops leads quản lý quyền truy cập.
- Khi nào dùng: trước khi mời managers, bật workflows, hoặc chia sẻ reports.
- Vị trí trong điều hướng: Help Center → For business → Account Access → Roles & Permissions.
- Tab liên quan: People Management (gán manager), Reports, Integrations & API (SSO/SCIM).
- Kết quả: mapping vai trò sạch, ít tin nhắn kiểu “tôi không thấy X”.
2) Mô hình tư duy (các lớp truy cập)
Hãy nghĩ theo lớp: admin toàn tổ chức, admin theo nhóm, và quản lý con người. Bắt đầu rộng (Org Admin), rồi thu hẹp (Group Admin), rồi chỉ gán manager đúng chỗ cần.
- Xác định bộ admin tối thiểu.
- Phân tách theo group khi có thể (giảm rủi ro).
- Gán managers cho approvals và direct reports.
- Rà soát quyền định kỳ (đặc biệt sau thay đổi tổ chức).
3) Đối tượng & thuật ngữ
Các thuật ngữ này xuất hiện trong các bài chính thức về roles. Dùng như “từ vựng chung” khi trao đổi với stakeholders.
- Org Admin: quyền quản trị toàn tổ chức (phạm vi rộng).
- Group Admin: quyền admin theo group (phạm vi hẹp hơn).
- Vai trò Manager: trách nhiệm và quyền truy cập của quản lý với team của họ.
- Direct reports: nhân sự thuộc mối quan hệ báo cáo trực tiếp với manager.
- Luồng phê duyệt: các hành động (vd: time off) được chuyển tới managers/admins.
4) Vòng đời / state machine
Quản lý quyền không phải “setup một lần là xong”; nó là việc liên tục. Hãy coi việc gán role như vòng đời: yêu cầu → cấp → kiểm chứng → rà soát → thu hồi.
- Yêu cầu: nhân sự/manager mới cần quyền.
- Đã cấp: gán role (Org Admin / Group Admin / Manager).
- Đã kiểm chứng: user thấy đúng trang và làm được hành động test.
- Đã rà soát: audit quyền theo tháng/quý.
- Đã thu hồi: gỡ quyền khi đổi vai trò hoặc offboarding.
5) Các việc cốt lõi cần làm
Đây là các việc bạn sẽ lặp lại khi công ty lớn dần.
- Gán vai trò manager cho các team.
- Giải thích managers có thể làm gì trên Deel (và không thể).
- Cấp quyền group-admin để uỷ quyền vận hành HR.
- Giữ danh sách Org Admin tối thiểu và luôn cập nhật.
- Xử lý escalations: “thiếu quyền” vs “cấp sai quyền”.
- Chuẩn bị scale bằng SSO/SCIM (nếu áp dụng).
6) Luồng chuẩn #1 — Gán vai trò manager
Dùng khi một quản lý mới cần phê duyệt yêu cầu hoặc quản lý team trong Deel.
- Xác nhận người đó đã có user account trong đúng organization.
- Xác định ai là direct reports của họ (quan hệ/structure).
- Gán vai trò manager theo luồng cài đặt organization.
- Yêu cầu manager đăng nhập và xác nhận họ thấy team view.
- Chạy test: một direct report gửi một request (vd: time off).
- Kiểm tra manager approve/decline được và bạn nhận đúng notification.
7) Luồng chuẩn #2 — Thiết lập mô hình admin tối thiểu
Dùng khi bạn mới bắt đầu Deel HR và muốn tránh tình trạng “ai cũng là admin”.
- Liệt kê các “admin jobs”: HR ops, reporting, approvals, integrations.
- Map job → role: Org Admin cho owner chính; Group Admin cho phần uỷ quyền.
- Giữ số lượng Org Admin thấp nhất có thể (least privilege).
- Ghi rõ ownership: ai duyệt gì, ai duy trì structure, ai audit quyền.
- Mời users và gán roles theo job map.
- Kiểm chứng 10 phút cho mỗi role (làm đúng việc, không thừa quyền?).
- Đặt lịch rà soát quyền (tháng hoặc quý).
8) Điểm quyết định (A/B)
Các quyết định quyền phổ biến nhất ảnh hưởng trực tiếp tới bảo mật và tốc độ vận hành.
| Quyết định | Nếu chọn A… | Nếu chọn B… |
|---|---|---|
| Org Admin hay Group Admin | Org Admin → xử lý nhanh, rủi ro cao hơn | Group Admin → an toàn hơn, cần structure rõ |
| Phạm vi manager | Chỉ direct reports → an toàn hơn, setup nhiều hơn | Hiển thị rộng → dễ hơn, rủi ro riêng tư |
| Rà soát quyền | Hằng tháng → kiểm soát chặt, tốn công hơn | Hằng quý → nhẹ hơn, dọn chậm hơn |
| Tự cấp quyền hay qua ticket | Tự cấp → nhanh, cần guardrails | Ticket → kiểm soát tốt, xử lý chậm hơn |
9) Lỗi thường gặp + guardrails
Hầu hết sự cố quyền là do vô tình. Coi đây như các “luật không tái phạm”.
- Lỗi: quá nhiều Org Admin → Tránh: giới hạn 1–3 owners.
- Lỗi: manager không duyệt được → Tránh: kiểm tra role + mapping direct reports.
- Lỗi: ranh giới group mơ hồ → Tránh: định nghĩa groups trước khi uỷ quyền.
- Lỗi: không có audit trail → Tránh: log thay đổi role (ai/khi nào/tại sao).
- Lỗi: không gỡ quyền → Tránh: thu hồi khi đổi vai trò/offboarding.
10) “Thế nào là tốt” + checklist + bài thực hành + tài liệu chính thức
Dùng phần này như chuẩn “phân quyền đúng cách”.
Thế nào là tốt
- Admins tối thiểu và được đặt tên rõ ràng.
- Managers chỉ thấy đúng thứ cần cho team.
- Thay đổi role được rà soát và ghi lại.
- Gỡ quyền là một phần của offboarding.
Checklist: Trước khi làm
- Định nghĩa admin jobs
- Định nghĩa groups (nếu dùng)
- Xác định managers
- Đặt bước kiểm chứng
- Chọn lịch rà soát
Checklist: Sau khi làm
- Test approvals chạy (vd: time off)
- Xác nhận đúng phạm vi hiển thị
- Ghi rõ owners và cách escalations
- Lên lịch rà soát quyền
- Thêm bước thu hồi khi offboarding
Bài thực hành (5–15 phút)
Mục tiêu: gán 1 manager role và kiểm chứng approvals hoạt động.
- Chọn 1 manager và 1 direct report.
- Gán manager role.
- Cho direct report gửi request (time off là test phổ biến).
- Kiểm tra manager thấy request và thao tác được.
Link tài liệu chính thức (tên bài)
- Cách gán vai trò Manager trong tổ chức của bạn
- Hiểu vai trò của bạn với tư cách Manager trên Deel
- Giải thích quyền của Group Administrator (Group Admin)
- Giải thích quyền của Organization Administrator (Org Admin)
Quản lý nhân sự (People Management)
- Hiểu hồ sơ nhân sự (worker profiles) và các thao tác People quan trọng.
- Cơ bản về import / tạo trực tiếp nhân viên (HRIS contracts).
- Tasks, checklist onboarding, và kiến thức nền về Workflow Builder.
- Giữ dữ liệu sạch (gộp/xoá/chỉnh sửa hàng loạt).
1) Mục đích, dành cho ai, và bấm ở đâu
People Management là “hub vận hành” để duy trì hồ sơ nhân sự và chạy các công việc HR lặp lại (tasks, onboarding steps, và automation). Mục tiêu là dữ liệu nhất quán và giảm follow-up thủ công.
- Dành cho: HR admins, People Ops, người phụ trách onboarding.
- Khi nào dùng: mỗi khi thêm/cập nhật nhân sự, giao tasks, hoặc xây automation.
- Vị trí trong điều hướng: Help Center → For business → Organization & Group Management → People Management.
- Tab liên quan: Roles & Permissions, Time Off, Reports, Integrations & API.
- Kết quả: danh bạ nhân sự sạch + workflows lặp lại được, dễ scale.
2) Mô hình tư duy (People như hệ thống hành động)
Hãy coi People là “nguồn tạo hành động” ngay cả khi nó chưa phải nguồn dữ liệu duy nhất. Profiles giữ dữ liệu; tasks và workflows tạo việc; structure/relations quyết định phạm vi hiển thị và luồng manager.
- Tạo hoặc import hồ sơ nhân sự.
- Thu thập thông tin bắt buộc (fields, forms, documents).
- Gán tasks / checklist onboarding.
- Tự động hoá follow-up bằng Workflow Builder.
- Duy trì structure và relationships để báo cáo/phê duyệt chạy đúng.
3) Đối tượng & thuật ngữ
Các thuật ngữ này xuất hiện thường xuyên trong People Management và là “gạch nền” cho workflows HR.
- Worker profile: hồ sơ của một nhân sự trong Deel.
- Hợp đồng nhân viên trực tiếp (HRIS): luồng thiết lập cho direct employees.
- Import hàng loạt: tạo nhiều direct employees cùng lúc.
- Tasks / checklist onboarding: các bước vận hành được giao.
- Workflow Builder: automation cho workflow tasks.
- Cấu trúc tổ chức & quan hệ nhân sự: grouping và relationships dùng cho directory và org chart.
4) Vòng đời / state machine (sức khoẻ hồ sơ nhân sự)
Dữ liệu People thường đi theo vòng đời “khỏe mạnh” khá rõ. Giữ profiles “khỏe” sẽ làm approvals, analytics và routing manager tốt hơn.
- Đã tạo: có profile (tạo tay hoặc import).
- Đã làm giàu: thu thập đủ field bắt buộc (worker info, demographics nếu bật).
- Vận hành được: đã giao tasks; checklist onboarding đang chạy.
- Đã có cấu trúc: set manager và relations; định nghĩa org structure.
- Được duy trì: bulk edits và lý do chỉnh sửa/change log (nếu có) được dùng khi cần.
- Đã dọn sạch: gộp trùng; xoá profile không còn dùng (khi phù hợp).
5) Các việc cốt lõi cần làm
Dùng như playbook chuẩn cho People Ops hằng ngày trong Deel.
- Tạo hợp đồng/profile nhân viên trực tiếp (HRIS) khi cần.
- Import hàng loạt direct employees.
- Thu thập thông tin nhân sự và field bắt buộc.
- Tạo và quản lý tasks cho nhân sự.
- Thiết lập automation workflows / Workflow Builder tasks.
- Duy trì org structure và worker relations.
- Chỉnh sửa hàng loạt thông tin worker và payroll contract (khi cần).
6) Luồng chuẩn #1 — Thêm nhân sự (thủ công → sẵn sàng)
Dùng khi bạn thêm ít nhân sự và muốn kết quả “sẵn sàng vận hành” đồng nhất.
- Tạo worker profile / direct employee setup theo nhu cầu.
- Thu thập thông tin (fields bắt buộc và demographics nếu bật).
- Gán tasks và/hoặc checklist onboarding tuỳ biến.
- Set manager roles và worker relations (để approvals route đúng).
- Chạy thử 1 tác vụ tự động với Workflow Builder (vd: reminder hoặc yêu cầu tài liệu).
- Xác nhận worker làm được các bước được giao và bạn theo dõi được trạng thái.
7) Luồng chuẩn #2 — Import hàng loạt + dọn dữ liệu
Dùng khi onboarding nhiều direct employees và muốn tránh trùng profile + routing manager bị sai.
- Chuẩn bị dữ liệu import với định danh nhất quán (email/IDs).
- Chạy mass import cho direct employees.
- Kiểm tra ngẫu nhiên 5–10 profiles đã import (độ đầy đủ field).
- Gộp các worker profiles bị trùng (nếu phát hiện).
- Gán onboarding tasks/checklists theo batch.
- Thiết lập org structure và worker relations để routing manager chạy đúng.
- Dùng bulk edit để sửa field thiếu/sai (khi phù hợp).
- Ghi lại SOP import để lần sau làm lại nhanh.
8) Điểm quyết định (A/B)
Chọn phương án phù hợp với quy mô và độ “chín” dữ liệu của bạn.
| Quyết định | Nếu chọn A… | Nếu chọn B… |
|---|---|---|
| Thêm thủ công hay import hàng loạt | Thủ công → ít lỗi hơn, chậm hơn | Import → nhanh, cần kế hoạch dọn dữ liệu |
| Tasks trước hay Workflow Builder trước | Tasks → đơn giản, follow-up thủ công | Workflow Builder → scale tốt, cần thiết kế |
| Làm structure ngay hay để sau | Ngay → approvals/reporting tốt hơn | Để sau → nhanh lúc đầu, rework nhiều hơn |
| Xoá hay gộp trùng | Gộp → giữ lịch sử | Xoá → rủi ro nếu đã được tham chiếu nơi khác |
9) Lỗi thường gặp + guardrails
Các vấn đề này hay gặp khi build People hub nhanh. Dùng guardrails để giữ dữ liệu ổn định.
- Lỗi: thiếu mapping manager → Tránh: set relations ngay trong onboarding.
- Lỗi: trùng profile sau import → Tránh: định danh nhất quán + gộp sớm.
- Lỗi: tasks không rõ owner → Tránh: định nghĩa ownership trong checklist.
- Lỗi: automation chưa test → Tránh: pilot Workflow Builder cho 1 team.
- Lỗi: bulk edits không có audit → Tránh: dùng lý do chỉnh sửa/change log (nếu bật).
10) “Thế nào là tốt” + checklist + bài thực hành + tài liệu chính thức
Nếu bạn tick được các mục này, People Management đã đủ ổn để scale.
Thế nào là tốt
- Profiles là duy nhất (không trùng).
- Fields bắt buộc được thu thập nhất quán.
- Tasks/checklists được dùng cho mọi lần onboard.
- Structure/relations được duy trì để approvals chạy đúng.
Checklist: Trước khi làm
- Quyết định import hay thủ công
- Định nghĩa fields bắt buộc
- Định nghĩa onboarding tasks
- Chỉ định data owner
- Chọn nhóm pilot
Checklist: Sau khi làm
- Spot-check chất lượng profile
- Gộp profiles trùng
- Kiểm tra routing manager
- Test 1 automation
- Ghi SOP
Bài thực hành (5–15 phút)
Mục tiêu: tạo 1 worker record sạch và chạy một workflow nhỏ.
- Tạo (hoặc chọn) 1 worker profile.
- Thu thập/xác nhận các field lõi.
- Gán 1 onboarding task và 1 reminder automation.
- Set quan hệ manager và xác nhận manager nhìn thấy worker.
Link tài liệu chính thức (tên bài)
- Cách tạo hợp đồng nhân viên trực tiếp (HRIS) trên Deel
- Cách import hàng loạt direct employees vào Deel
- Cách gộp (merge) hồ sơ nhân sự
- Cách xoá hồ sơ nhân sự trên Deel
- Thiết lập automation workflows trên Deel
- Checklist onboarding tuỳ biến
- Cách tạo và quản lý Tasks cho nhân sự trong tổ chức
- Cách cấu hình cấu trúc tổ chức và quan hệ nhân sự
- Cách client thu thập thông tin nhân sự
- Cách tự động hoá workflow tasks với Workflow Builder
Nghỉ phép
- Tạo chính sách và quy tắc phê duyệt.
- Xem xét/quản lý yêu cầu một cách nhất quán.
- Điều chỉnh số dư đúng cách (theo tư duy kiểm toán).
- Nắm rõ ranh giới kỳ vọng giữa contractor và nhân viên.
1) Mục đích, dành cho ai, và bấm ở đâu
Nghỉ phép giúp bạn định nghĩa cách yêu cầu được gửi, được chuyển tuyến phê duyệt, và được theo dõi. Mục tiêu là phê duyệt nhất quán và số dư chính xác để quản lý và HR tin tưởng.
- Dành cho: HR admin, People Ops, quản lý phê duyệt nghỉ phép.
- Khi dùng: khi thiết lập chính sách, phê duyệt yêu cầu, hoặc chỉnh sửa số dư.
- Vị trí trong điều hướng: Help Center → For business → Time Off.
- Tab liên quan: Roles & Permissions (người phê duyệt), People Management (mapping quản lý), Reports (theo dõi).
- Kết quả: phê duyệt dự đoán được + hồ sơ nghỉ phép đáng tin cậy.
2) Mô hình tư duy (chính sách → phê duyệt → số dư)
Nghỉ phép là một vòng lặp: chính sách định nghĩa quyền lợi; quy tắc phê duyệt định tuyến yêu cầu; yêu cầu được duyệt sẽ cập nhật số dư. Giữ vòng lặp chặt chẽ để tránh tranh chấp.
- Tạo hoặc tùy biến chính sách nghỉ phép.
- Thiết lập chính sách phê duyệt (ai duyệt, thứ tự duyệt).
- Nhân sự gửi yêu cầu.
- Người phê duyệt xem xét và quyết định.
- Số dư cập nhật; admin chỉ điều chỉnh khi thật sự cần.
3) Đối tượng & thuật ngữ
Đây là các thành phần chính được nhắc nhiều trong các bài hướng dẫn chính thức về nghỉ phép.
- Chính sách nghỉ phép: định nghĩa quyền lợi và quy tắc.
- Chính sách phê duyệt: định nghĩa ai có quyền phê duyệt nghỉ phép.
- Yêu cầu: một mục nghỉ phép đã gửi và đang chờ xử lý.
- Số dư: quyền lợi còn lại sau khi sử dụng/điều chỉnh.
- Nghỉ phép cho nhân viên trực tiếp: luồng quản lý nghỉ phép cho direct employees.
- Kỳ vọng nghỉ phép cho contractor: có thể khác; cần xác nhận cách tiếp cận chính sách.
4) Vòng đời / state machine (trạng thái yêu cầu)
Yêu cầu thường đi theo một luồng trạng thái đơn giản. Dùng nó để chuẩn hóa cách quản lý phản hồi và cách HR audit vấn đề.
- Bản nháp/Đã gửi: nhân sự gửi yêu cầu.
- Đang chờ: chờ theo chuỗi phê duyệt.
- Đã duyệt: được chấp nhận và áp vào số dư.
- Từ chối: bị từ chối; số dư không đổi.
- Đã điều chỉnh: admin áp dụng chỉnh sửa số dư (kèm lý do).
5) Các công việc cốt lõi (JTBD)
Đây là các thao tác lặp lại nhiều nhất của admin/quản lý trong Nghỉ phép.
- Tạo chính sách nghỉ phép tùy biến cho nhân sự.
- Cấu hình các chính sách phê duyệt nghỉ phép.
- Xem xét và quản lý yêu cầu nghỉ phép của nhân viên.
- Quản lý yêu cầu nghỉ phép của direct employees (nếu áp dụng).
- Điều chỉnh số dư nghỉ phép khi cần sửa sai.
- Làm rõ quan điểm/chính sách cho contractor (khi liên quan).
6) Quy trình “happy path” #1 — Thiết lập Nghỉ phép (admin)
Dùng khi bạn bật Nghỉ phép lần đầu và muốn một cấu hình mặc định an toàn.
- Chọn cách tiếp cận chính sách (chuẩn vs tùy biến).
- Tạo chính sách nghỉ phép và xác nhận logic quyền lợi.
- Cấu hình chính sách phê duyệt (quản lý, HR, hoặc cả hai).
- Xác nhận manager được gán đúng trong People/cấu trúc.
- Chạy một yêu cầu thử với một nhân sự pilot.
- Kiểm tra yêu cầu đi đúng tuyến phê duyệt và cập nhật số dư khi được duyệt.
7) Quy trình “happy path” #2 — Xử lý yêu cầu hàng tuần (routine vận hành)
Dùng như nhịp vận hành hàng tuần để tránh tồn đọng và tranh chấp.
- Kiểm tra các yêu cầu đang chờ (hàng ngày hoặc theo lịch cố định).
- Xác thực ngày, trùng lịch, và các phê duyệt bắt buộc.
- Duyệt/từ chối theo chính sách và nhu cầu đảm bảo nhân sự trực.
- Nếu cần sửa sai, điều chỉnh số dư kèm lý do nội bộ rõ ràng.
- Nhắn cho nhân sự khi bị từ chối (kèm bước tiếp theo).
- Spot-check số dư để phát hiện bất thường (tăng/giảm lớn).
- Rà soát hiệu suất phê duyệt (yêu cầu bị kẹt) và sửa manager mapping.
8) Điểm quyết định (A/B)
Các quyết định này kiểm soát mức độ “chặt” của quy trình nghỉ phép.
| Quyết định | Nếu A… | Nếu B… |
|---|---|---|
| Chuỗi phê duyệt | Chỉ quản lý → nhanh, ít giám sát | Quản lý + HR → an toàn hơn, chậm hơn |
| Độ phức tạp chính sách | Chính sách đơn giản → dễ áp dụng | Chính sách tùy biến → chính xác, tốn công thiết lập |
| Điều chỉnh số dư | Hiếm, kiểm soát chặt → ít tranh chấp | Thường xuyên → rủi ro thiếu nhất quán |
| Nghỉ phép cho contractor | Có chính sách → thiện chí, tăng chi phí/độ phức tạp | Không có chính sách → đơn giản hơn, cần làm rõ kỳ vọng |
9) Lỗi thường gặp + guardrails
Sự cố nghỉ phép thường do định tuyến sai hoặc chính sách mơ hồ. Sửa sớm thì mọi thứ dễ hơn.
- Lỗi: định tuyến sai người duyệt → Tránh: kiểm tra manager mapping và chính sách phê duyệt.
- Lỗi: không tài liệu hóa chính sách nội bộ → Tránh: phát hành bản tóm tắt 1 trang.
- Lỗi: điều chỉnh số dư không có bối cảnh → Tránh: ghi rõ lý do nội bộ và truyền thông khi cần.
- Lỗi: bỏ qua yêu cầu bị kẹt → Tránh: rà soát hàng tuần + quy tắc escalation.
- Lỗi: kỳ vọng contractor không rõ → Tránh: quyết định và truyền thông quan điểm.
10) Thế nào là “tốt” + checklist + bài thực hành + tài liệu chính thức
Dùng các mục này làm tiêu chuẩn chất lượng và tài liệu onboarding cho quản lý.
Thế nào là “tốt”
- Quản lý duyệt trong khung thời gian đã thống nhất.
- Số dư khớp với kỳ vọng của chính sách.
- Điều chỉnh hiếm và truy vết được.
- Nhân sự hiểu cách gửi yêu cầu nghỉ.
Checklist: Trước khi làm
- Xác định chính sách
- Gán người phê duyệt
- Xác minh mapping quản lý
- Chọn nhân sự pilot
- Soạn tóm tắt chính sách nội bộ
Checklist: Sau khi làm
- Yêu cầu test đã được duyệt
- Số dư cập nhật đúng
- Thiết lập quy tắc escalation
- Đào tạo quản lý
- Lên lịch audit định kỳ
Bài thực hành (5–15 phút)
Mục tiêu: kiểm chứng chính sách + phê duyệt trong một bài test ngắn.
- Tạo hoặc chọn một chính sách nghỉ phép hiện có.
- Thiết lập chính sách phê duyệt (quản lý).
- Gửi một yêu cầu test cho nhân sự pilot.
- Duyệt và xác nhận số dư cập nhật.
Link tài liệu chính thức (tên bài)
- Cách tạo chính sách nghỉ phép tùy biến cho nhân sự
- Cách cấu hình chính sách phê duyệt nghỉ phép
- Cách xem xét và quản lý yêu cầu nghỉ phép của nhân viên
- Cách quản lý yêu cầu nghỉ phép của direct employees
- Cách điều chỉnh số dư nghỉ phép cho nhân sự
- Client có bắt buộc phải cho contractor nghỉ phép không?
Gắn kết (Engage)
- Hiểu các mảng con của Engage (Mục tiêu, Học tập, Lộ trình nghề nghiệp, Khảo sát, Quản trị/QL người dùng).
- Bắt đầu với 1 chương trình đơn giản (pilot) trước khi mở rộng.
- Xác định người chịu trách nhiệm: HR vs quản lý vs nhân viên.
- Đo mức độ áp dụng bằng các kiểm tra nhẹ.
1) Mục đích, dành cho ai, và bấm ở đâu
Gắn kết (Engage) là nơi bạn chạy các chương trình hỗ trợ phát triển và thu thập phản hồi cho nhân viên (thể hiện qua các mục điều hướng như Mục tiêu, Học tập, Lộ trình nghề nghiệp và Khảo sát). Mục tiêu là cải thiện mức độ gắn kết bằng các nhịp vận hành lặp lại và đo được.
- Dành cho: HR/People Ops, trưởng nhóm, quản lý chạy các nhịp phát triển.
- Khi dùng: khi bạn muốn chu kỳ mục tiêu nhất quán, theo dõi học tập, kế hoạch nghề nghiệp, hoặc khảo sát.
- Vị trí trong điều hướng: Help Center → For business → Deel HR → Engage.
- Tab liên quan: Workforce Planning (kế hoạch + năng lực), People Management (mapping quản lý), Reports (phân tích).
- Kết quả: 1 chương trình pilot chạy end-to-end với người chịu trách nhiệm rõ ràng.
2) Mô hình tư duy (chương trình + chu kỳ)
Hãy coi Engage là một tập các “chu kỳ”: định nghĩa một chương trình (ví dụ: mục tiêu hoặc khảo sát nhanh), triển khai cho một nhóm, thu thập cập nhật, rồi đánh giá kết quả và cải tiến.
- Chọn 1 module (Mục tiêu hoặc Khảo sát) để làm pilot.
- Xác định ai tham gia và ai chịu trách nhiệm follow-up.
- Chạy một chu kỳ ngắn (2–4 tuần) trước khi mở rộng.
- Xem kết quả và điều chỉnh câu hỏi/quy trình.
3) Đối tượng & thuật ngữ
Engage được tổ chức theo các mảng con trong điều hướng chính thức. Dùng chúng như “các tab con trong một tab”.
- Mục tiêu (Goals): nhịp đặt mục tiêu và theo dõi.
- Học tập (Learning): chương trình/khu vực theo dõi học tập.
- Lộ trình nghề nghiệp (Career): khu vực lập kế hoạch phát triển nghề nghiệp.
- Khảo sát (Surveys): thu thập phản hồi (pulse/engagement surveys).
- Quản trị Engage & quản lý người dùng: ai có thể tạo/quản lý chương trình.
4) Vòng đời / state machine
Công việc Engage thường đi theo một vòng đời đơn giản và lặp lại. Giữ vòng đời nhất quán giúp tăng mức độ áp dụng.
- Thiết kế: chương trình được định nghĩa (phạm vi, người tham gia, owner).
- Ra mắt: người tham gia được thông báo và mời tham gia.
- Đang chạy: thu thập cập nhật/phản hồi trong chu kỳ.
- Đánh giá: quản lý/HR xem kết quả và quyết định hành động.
- Cải tiến: tinh chỉnh chương trình cho chu kỳ tiếp theo.
5) Các công việc cốt lõi (JTBD)
Đây là các việc “thực sự làm gì?” phổ biến nhất khi dùng Engage.
- Khởi chạy một chu kỳ mục tiêu cơ bản cho một team.
- Thu thập phản hồi bằng một khảo sát đơn giản.
- Xác định trọng tâm học tập cho một quý.
- Hỗ trợ trao đổi nghề nghiệp bằng template/quy trình gọn nhẹ.
- Thiết lập ai có quyền quản trị chương trình Engage và ai được tham gia.
- Chạy cadence định kỳ (tháng/quý) với nhắc nhở nhất quán.
6) Quy trình “happy path” #1 — Chạy một chu kỳ khảo sát pilot
Dùng khi bạn muốn bắt đầu Engage theo cách rủi ro thấp và chứng minh giá trị nhanh.
- Chọn nhóm pilot (một team hoặc một phòng ban).
- Xác định mục tiêu khảo sát (ví dụ: phản hồi onboarding, pulse hàng tuần).
- Quyết định ai review kết quả và ai chịu trách nhiệm hành động follow-up.
- Phát hành khảo sát và đặt hạn chót.
- Theo dõi tỷ lệ phản hồi và gửi nhắc (nếu quy trình của bạn có hỗ trợ).
- Xem kết quả và chọn 1–2 hành động để thực hiện.
- Thông báo kết quả lại cho người tham gia (khép vòng phản hồi).
7) Quy trình “happy path” #2 — Bắt đầu cadence mục tiêu cùng quản lý
Dùng khi bạn muốn quản lý đặt và review mục tiêu cho đội ngũ một cách đều đặn.
- Chọn độ dài chu kỳ đơn giản (ví dụ: check-in hàng tháng hoặc mục tiêu theo quý).
- Định nghĩa thế nào là “mục tiêu tốt” (tối đa 2–4 mục tiêu/người).
- Giao trách nhiệm cho quản lý về check-in và cập nhật.
- Khởi chạy chu kỳ cho team pilot.
- Check-in giữa chu kỳ và ghi nhận các blocker.
- Tổng kết cuối chu kỳ: đạt được gì và thay đổi gì cho chu kỳ sau.
- Chỉ mở rộng sang nhóm tiếp theo khi pilot ổn định.
8) Điểm quyết định (A/B)
Các quyết định này chi phối mức độ áp dụng và “gánh nặng cho quản lý”.
| Quyết định | Nếu A… | Nếu B… |
|---|---|---|
| Quy mô pilot | Nhỏ → lặp nhanh | Lớn → tác động nhanh hơn, rủi ro cao hơn |
| Owner chương trình | HR sở hữu → nhất quán | Quản lý sở hữu → sát thực tế, chất lượng không đồng đều |
| Độ dài chu kỳ | Ngắn → tạo đà, tốn công hơn | Dài → ít công hơn, học chậm hơn |
| Minh bạch phản hồi | Chia sẻ kết quả → tạo niềm tin | Giữ nội bộ → dễ hơn, ít niềm tin hơn |
9) Lỗi thường gặp + guardrails
Engage thất bại khi mọi người không thấy kết quả. Giữ vòng phản hồi “khép kín”.
- Lỗi: chạy quá nhiều chương trình → Tránh: mỗi lần chỉ 1 pilot.
- Lỗi: không có owner cho follow-up → Tránh: gán owner hành động trước khi launch.
- Lỗi: thu phản hồi rồi im lặng → Tránh: luôn chia sẻ kết quả.
- Lỗi: quá tải cho quản lý → Tránh: chu kỳ đơn giản, time-box rõ ràng.
- Lỗi: quyền admin không rõ → Tránh: định nghĩa quy tắc quản trị/QL người dùng Engage.
10) Thế nào là “tốt” + checklist + bài thực hành + tài liệu chính thức
Dùng các mục này để giữ Engage đơn giản và đo được.
Thế nào là “tốt”
- Một chu kỳ chương trình ổn định đang chạy.
- Owner rõ ràng cho review và follow-up.
- Người tham gia thấy kết quả và hành động.
- Quản lý chạy cadence mà không cần thêm tool khác.
Checklist: Trước khi làm
- Chọn nhóm pilot
- Xác định mục tiêu chương trình
- Gán owner
- Chốt độ dài chu kỳ
- Lên kế hoạch truyền thông
Checklist: Sau khi làm
- Rà soát tỷ lệ phản hồi/cập nhật
- Gán hành động
- Chia sẻ kết quả
- Lên kế hoạch lần lặp tiếp theo
- Quyết định có mở rộng không
Bài thực hành (5–15 phút)
Mục tiêu: thiết kế một chu kỳ pilot trên giấy (thậm chí trước khi bấm trong tool).
- Chọn: Mục tiêu hoặc Khảo sát làm pilot.
- Viết chu kỳ: ngày bắt đầu, ngày kết thúc, owner, người tham gia.
- Chọn 1 chỉ số thành công (ví dụ: 70% tham gia).
- Chọn 1 hành động follow-up bạn cam kết làm sau khi có kết quả.
Link tài liệu chính thức (mục điều hướng)
- Engage → Mục tiêu
- Engage → Học tập
- Engage → Lộ trình nghề nghiệp
- Engage → Khảo sát
- Engage → Quản trị Engage & quản lý người dùng
Lương thưởng (Compensation)
- Thiết lập khung vị trí (job architecture) và dải lương (compensation bands).
- Chạy một chu kỳ xét lương với ngân sách.
- Xử lý kế hoạch đa tiền tệ (nếu dùng).
- Kiểm soát quyền truy cập bằng admin.
1) Mục đích, dành cho ai, và bấm ở đâu
Lương thưởng (Compensation) giúp bạn chuẩn hoá quyết định lương và chạy các chu kỳ xét lương một cách nhất quán. Mục tiêu là giảm quyết định “tuỳ hứng” và làm chu kỳ dễ kiểm tra/đối soát hơn (dải lương, ngân sách, admin, tiền tệ).
- Dành cho: HR/People Ops, đối tác tài chính, quản trị viên lương thưởng.
- Khi dùng: trong các kỳ review lương, phân bậc/leveling, hoặc lập kế hoạch ngân sách.
- Vị trí trong điều hướng: Help Center → For business → Deel HR → Compensation.
- Tab liên quan: People Management (dữ liệu job/worker), Reports (phân tích), Roles & Permissions.
- Kết quả: một chu kỳ lặp lại được mà quản lý có thể làm theo, không bị “loạn bảng tính”.
2) Mô hình tư duy (khung → dải lương → chu kỳ)
Một chương trình lương thưởng “ổn” thường bắt đầu từ cấu trúc, rồi mới chạy chu kỳ. Khung vị trí tạo bản đồ role/level; dải lương tạo khoảng; chu kỳ là nơi thực thi quyết định với ngân sách và phê duyệt.
- Thêm khung vị trí (role/level).
- Thiết lập dải lương theo role/level đó.
- Thêm tiền tệ nếu bạn vận hành toàn cầu.
- Tạo chu kỳ xét lương kèm ngân sách.
- Gán admin và chạy chu kỳ.
3) Đối tượng & thuật ngữ
Các thuật ngữ này lấy trực tiếp từ tiêu đề bài viết chính thức của phần Compensation và giúp bạn định hướng nhanh tính năng.
- Dải lương (Compensation bands): các khoảng lương có cấu trúc cho role/level.
- Chu kỳ xét lương (Compensation cycles): quy trình review theo kỳ.
- Khung vị trí (Job architectures): khung role/level dùng cho lương.
- Ngân sách (Budgets): các kiểu ngân sách của chu kỳ để kiểm soát chi tiêu.
- Tiền tệ (Currencies): hỗ trợ đa tiền tệ để lập kế hoạch.
- Admin lương thưởng (Compensation admins): quản trị viên quản lý tính năng lương thưởng.
4) Vòng đời / state machine (trạng thái chu kỳ)
Chu kỳ xét lương thường vận hành như một vòng đời dự án. Chia theo giai đoạn giúp các bên liên quan hiểu “đang ở bước nào”.
- Thiết kế: chốt phạm vi và ngân sách.
- Chuẩn bị: khung vị trí và dải lương hoàn tất; xác nhận tiền tệ.
- Đang chạy: quản lý/owner đưa đề xuất.
- Rà soát: HR/tài chính rà soát tính nhất quán và ngân sách.
- Chốt: hoàn tất quyết định và truyền thông.
5) Các công việc cốt lõi (JTBD)
Dùng các việc này như kế hoạch triển khai cho chu kỳ xét lương đầu tiên.
- Thêm khung vị trí cho Deel Compensation.
- Thiết lập dải lương.
- Tạo và quản lý các chu kỳ xét lương.
- Chọn kiểu ngân sách cho chu kỳ.
- Thêm tiền tệ cho kế hoạch lương toàn cầu.
- Thêm admin cho Compensation (kiểm soát ai được quản lý chu kỳ).
6) Quy trình “happy path” #1 — Thiết lập nền tảng
Dùng khi bạn chuẩn bị cho chu kỳ đầu tiên và muốn có cấu trúc vững trước khi mời các bên tham gia.
- Định nghĩa khung vị trí (level, role, family) trong tài liệu nội bộ về lương.
- Cấu hình khung vị trí trong Deel Compensation.
- Tạo dải lương tương ứng cho từng level/role.
- Thêm các tiền tệ bạn dự định dùng trong chu kỳ.
- Thêm admin lương thưởng (nhóm owner nhỏ).
- Spot-check: chọn 1 nhân sự mẫu, map vào job/level và band đúng.
7) Quy trình “happy path” #2 — Chạy một chu kỳ xét lương
Dùng khi bạn muốn một quy trình lặp lại được cho quyết định lương, thay vì “vỡ trận spreadsheet”.
- Tạo chu kỳ xét lương mới và xác định phạm vi (ai được đưa vào).
- Chọn (các) kiểu ngân sách cho chu kỳ.
- Xác nhận khung vị trí và dải lương đã sẵn sàng.
- Mời các bên liên quan (quản lý/người phê duyệt) theo quy trình nội bộ.
- Thu đề xuất và rà soát theo tính nhất quán và ngân sách.
- Chốt quyết định của chu kỳ.
- Ghi lại kết quả và bài học cho chu kỳ sau.
8) Điểm quyết định (A/B)
Các quyết định này sẽ quyết định độ phức tạp và tốc độ áp dụng.
| Quyết định | Nếu A… | Nếu B… |
|---|---|---|
| Mức độ chi tiết của khung vị trí | Đơn giản → setup nhanh | Chi tiết → chính xác hơn, tốn công hơn |
| Mức độ “siết” dải lương | Dải chặt → nhất quán | Dải linh hoạt → quản lý tự chủ, rủi ro lệch chuẩn |
| Cách dùng ngân sách | Ngân sách chặt → kiểm soát | Ngân sách lỏng → linh hoạt, rủi ro vượt chi |
| Đa tiền tệ | Một tiền tệ → đơn giản | Đa tiền tệ → thực tế hơn, phức tạp hơn |
9) Lỗi thường gặp + guardrails
Phần lớn vấn đề đến từ cấu trúc yếu hoặc quá nhiều admin. Giữ kỷ luật triển khai.
- Lỗi: chạy chu kỳ trước khi có khung vị trí → Tránh: set khung và dải lương trước.
- Lỗi: phân bậc không nhất quán → Tránh: định nghĩa rule leveling nội bộ.
- Lỗi: quá nhiều admin → Tránh: giữ nhóm owner nhỏ.
- Lỗi: ngân sách không rõ → Tránh: thống nhất kiểu ngân sách và ràng buộc từ đầu.
- Lỗi: rối tiền tệ → Tránh: ghi rõ giả định FX và cách dùng tiền tệ.
10) Thế nào là “tốt” + checklist + bài thực hành + tài liệu chính thức
Phần này là checklist “sẵn sàng chạy comp”.
Thế nào là “tốt”
- Mọi role đều map được vào khung vị trí và dải lương.
- Admin được giới hạn và được training.
- Ngân sách chu kỳ rõ ràng và được thực thi.
- Kết quả chu kỳ được ghi lại và lặp lại được.
Checklist: Trước khi làm
- Khung vị trí đã định nghĩa
- Đã tạo dải lương
- Đã xác nhận tiền tệ
- Đã gán admin
- Đã chọn phạm vi pilot
Checklist: Sau khi làm
- Chu kỳ hoàn tất
- Tuân thủ ngân sách
- Ngoại lệ được ghi lại
- Ghi nhận bài học
- Lên ngày chu kỳ tiếp theo
Bài thực hành (5–15 phút)
Mục tiêu: chuẩn bị một nền tảng “demo” nhỏ.
- Tạo khung vị trí tối giản (2 role × 2 level).
- Tạo 1 dải lương cho mỗi level.
- Thêm 1 tiền tệ bạn dùng.
- Phác thảo kế hoạch chu kỳ giả lập (phạm vi + kiểu ngân sách).
Link tài liệu chính thức (tiêu đề)
- Adding job architectures for Deel Compensation
- Setting up compensation bands with Deel Compensation
- Creating and managing compensation cycles with Deel Compensation
- Types of budgets for Deel Compensation comp cycles
- How to add currencies to Compensation
- How to add admins to Deel Compensation
Quản lý nhân tài (Talent Management)
- Hiểu Talent trong Deel bao gồm gì (ngữ cảnh client vs partner).
- Bắt đầu từ phần tổng quan và các bước cơ bản của quy trình tuyển dụng.
- Quyết định ai chịu trách nhiệm sourcing, sàng lọc và chọn ứng viên.
- Giữ quy trình đơn giản và dễ kiểm tra/đối soát.
1) Mục đích, dành cho ai, và bấm ở đâu
Talent Management trong Deel HR đề cập đến Deel Talent và các hướng dẫn liên quan đến tuyển dụng (gồm tổng quan cho khách hàng và thông tin cho talent partners). Mục tiêu là hiểu dịch vụ, luồng tuyển dụng và các “đầu vào” bạn cần để triển khai hiệu quả.
- Dành cho: recruiter, hiring manager, đội HR đang cân nhắc Deel Talent.
- Khi dùng: khi bạn dự định tuyển qua Deel Talent hoặc phối hợp với talent partners.
- Vị trí trong điều hướng: Help Center → For business → Deel HR → Talent Management.
- Tab liên quan: Integrations & API (tích hợp ATS), People Management (tạo hồ sơ nhân sự mới), Reports.
- Kết quả: một quy trình tuyển dụng tối giản + sơ đồ “ai làm gì” rõ ràng.
2) Mô hình tư duy (intake → sourcing → selection)
Giữ mô hình tư duy đơn giản: mô tả vị trí thật rõ, quyết định nguồn ứng viên, rồi chạy quy trình đánh giá nhất quán. Quá phức tạp sẽ làm chậm tốc độ và giảm chất lượng khi mới áp dụng.
- Intake vị trí: yêu cầu, tiêu chí bắt buộc, timeline.
- Sourcing ứng viên: ứng viên đến từ đâu (Deel Talent/partners/kênh khác).
- Sàng lọc & phỏng vấn: các vòng/stage nhất quán.
- Offer & bàn giao: chuyển sang onboarding/People.
3) Đối tượng & thuật ngữ
Các thuật ngữ này đến từ danh sách mục trong phần Talent Management chính thức.
- Deel Talent (dành cho Khách hàng): phần tổng quan theo góc nhìn client.
- Deel Talent (dành cho Đối tác nhân tài): phần tổng quan theo góc nhìn partner.
- Tuyển dụng với Deel Talent: điểm vào các hướng dẫn tuyển dụng thực tế.
- Trang FAQ: nơi tra cứu các tình huống và làm rõ điểm dễ hiểu nhầm.
4) Vòng đời / state machine
Vòng đời Talent là một “pipeline”. Dù bạn không mô hình hoá mọi stage, việc thống nhất trạng thái sẽ tránh thất lạc ứng viên và giảm nhầm lẫn.
- Intake: vị trí được định nghĩa và duyệt.
- Sourcing: tìm và xác định ứng viên.
- Screening: sàng lọc/đánh giá ban đầu.
- Interviewing: các vòng đánh giá có cấu trúc.
- Decision: offer/không offer và ghi lại quyết định.
- Handoff: bàn giao ứng viên trúng tuyển sang onboarding/People.
5) Các công việc cốt lõi (JTBD)
Dùng các việc này để lập kế hoạch cho vị trí “thật” đầu tiên tuyển theo luồng này.
- Đọc tổng quan cho khách hàng và thống nhất phạm vi với stakeholders.
- Tạo template intake tuyển dụng (yêu cầu, ngân sách, timeline).
- Chạy thử một quy trình tuyển dụng end-to-end.
- Quyết định dùng tích hợp ATS hay theo dõi thủ công.
- Thiết lập quy tắc phối hợp với partner (nếu dùng).
- Định nghĩa bước bàn giao từ “đã tuyển” sang onboarding trong People.
6) Quy trình “happy path” #1 — Tuyển với Deel Talent (tối giản)
Dùng như một blueprint đơn giản cho 1 vị trí để bạn có thể cải tiến nhanh.
- Xác nhận yêu cầu vị trí và timeline tuyển.
- Xem tổng quan Deel Talent (client) để stakeholders hiểu kỳ vọng.
- Chốt cách sourcing và “ai làm gì” (HR vs manager vs partner).
- Đặt 2–4 stage pipeline (screen → interview → decision).
- Sàng lọc ứng viên theo tiêu chí nhất quán.
- Ra quyết định và ghi lại lý do.
- Bàn giao ứng viên trúng tuyển sang các bước onboarding trong People.
7) Quy trình “happy path” #2 — Thiết lập phối hợp với partner
Dùng khi bạn dự kiến làm việc với talent partners và muốn giảm lệch kỳ vọng.
- Đọc tổng quan cho talent partners để hiểu mô hình phối hợp.
- Định nghĩa partner làm gì vs HR/manager làm gì nội bộ.
- Thống nhất format nộp ứng viên và thời gian.
- Thống nhất SLA phản hồi (ví dụ: phản hồi trong 48 giờ).
- Pilot với 1 partner cho 1 vị trí.
- Rà soát cái gì hiệu quả và siết lại quy trình.
8) Điểm quyết định (A/B)
Các quyết định này ảnh hưởng tốc độ và tính nhất quán.
| Quyết định | Nếu A… | Nếu B… |
|---|---|---|
| ATS hay không ATS | ATS → theo dõi tốt hơn | Không ATS → khởi động nhanh, ít hiển thị |
| Số lượng stage | Ít stage → nhanh | Nhiều stage → chặt chẽ hơn, chậm hơn |
| Ai sở hữu screening | HR-owned → nhất quán | Manager-owned → sát bối cảnh, nhưng dễ lệch |
| Có dùng partner không | Dùng partner → tăng nguồn ứng viên | Không partner → vận hành đơn giản |
9) Lỗi thường gặp + guardrails
Tuyển dụng hay “gãy” khi tốc độ và ownership không rõ.
- Lỗi: intake mơ hồ → Tránh: chốt must-have và timeline.
- Lỗi: quá nhiều vòng từ sớm → Tránh: giữ pipeline gọn.
- Lỗi: phản hồi chậm → Tránh: đặt SLA phản hồi.
- Lỗi: không có bước bàn giao onboarding → Tránh: định nghĩa rõ “hired → People”.
- Lỗi: ranh giới partner không rõ → Tránh: ghi rõ trách nhiệm.
10) Thế nào là “tốt” + checklist + bài thực hành + tài liệu chính thức
Giúp bạn giữ tuyển dụng đơn giản, đo được, và lặp lại được.
Thế nào là “tốt”
- Template intake rõ ràng cho mọi vị trí.
- Các stage pipeline nhất quán.
- Đạt SLA phản hồi.
- Ứng viên trúng tuyển chuyển sang onboarding mượt.
Checklist: Trước khi làm
- Yêu cầu vị trí đã viết
- Đã gán owner
- Đã định nghĩa stage
- Đã chốt SLA phản hồi
- Đã có kế hoạch bàn giao
Checklist: Sau khi làm
- Đo cycle time
- Ghi lại quyết định
- Cập nhật quy trình
- Thu phản hồi stakeholders
- Xếp hàng vị trí tiếp theo
Bài thực hành (5–15 phút)
Mục tiêu: thiết kế quy trình tuyển 1 vị trí có thể chạy ngay ngày mai.
- Viết intake 1 trang (must-have, timeline).
- Định nghĩa 3 stage: screen → interview → decision.
- Gán owner cho từng stage.
- Định nghĩa bước bàn giao sang onboarding/People.
Link tài liệu chính thức (tiêu đề)
- Overview: Deel Talent - for Clients
- Hiring with Deel Talent
- Frequently Asked Questions About Deel Talent
- Overview: Deel Talent - for Talent Partners
Hoạch định lực lượng lao động (Workforce Planning)
- Workforce Planning được tài liệu hoá dưới dạng “About Workforce Planning with Engage”.
- Bắt đầu bằng việc xác định phạm vi hoạch định và người phụ trách.
- Dùng dữ liệu People và cấu trúc vai trò làm đầu vào.
- Chạy thử một nhịp hoạch định nhỏ trước khi mở rộng.
1) Mục đích, dành cho ai, và bấm ở đâu
Workforce Planning giúp bạn lập kế hoạch headcount và cấu trúc lực lượng lao động dựa trên năng lực hoạch định liên quan đến Engage được nhắc trong điều hướng tài liệu chính thức. Mục tiêu là biến quyết định nhân sự thành quy trình lặp lại được và minh bạch.
- Dành cho: HR/People Ops, finance partners, lãnh đạo business lập kế hoạch nhân sự.
- Khi dùng: hoạch định theo quý, rà soát thiết kế tổ chức, lập ngân sách headcount.
- Vị trí trong điều hướng: Help Center → For business → Deel HR → Workforce Planning.
- Tab liên quan: Engage, People Management, Compensation, Reports.
- Kết quả: một nhịp hoạch định được ghi lại, có input/output rõ ràng.
2) Mô hình tư duy (inputs → scenarios → decisions)
Xem hoạch định như một vòng lặp: gom đầu vào, dựng kịch bản, chốt kế hoạch, rồi đối chiếu kết quả. Bắt đầu nhỏ—một phòng ban hoặc một quý.
- Đầu vào: dữ liệu nhân sự hiện tại, vị trí đang mở, ràng buộc ngân sách.
- Kịch bản: tuyển mới, backfill, tái cơ cấu, hoặc đóng băng tuyển dụng.
- Quyết định: phê duyệt kế hoạch và người chịu trách nhiệm.
- Rà soát: so sánh kế hoạch vs thực tế và lặp lại cải tiến.
3) Đối tượng & thuật ngữ
Phần chính thức có liên kết Workforce Planning với Engage, nên nên thống nhất thuật ngữ giữa hai khu vực này.
- Hoạch định lực lượng lao động: quyết định headcount và cấu trúc theo thời gian.
- Liên kết Engage: hoạch định được nhắc như “with Engage”.
- Đầu vào dữ liệu workforce: thường lấy từ People directory/cấu trúc tổ chức.
- Kịch bản (scenarios): các phương án so sánh để ra quyết định.
4) Vòng đời / state machine
Hoạch định là vòng đời lặp lại, không phải setup một lần. Dùng các trạng thái này để đồng bộ kỳ vọng của stakeholders.
- Bản nháp (Draft): thu thập đầu vào và ghi rõ giả định.
- Đề xuất (Proposed): chuẩn bị các kịch bản và lựa chọn.
- Phê duyệt (Approved): lãnh đạo duyệt kế hoạch và giả định ngân sách.
- Triển khai (Executed): tuyển dụng/onboarding bám theo kế hoạch.
- Rà soát (Reviewed): so sánh thực tế với kế hoạch; điều chỉnh khi cần.
5) Các công việc cốt lõi (JTBD)
Dùng các việc này làm backlog triển khai ban đầu.
- Xác định phạm vi (team nào, trong khoảng thời gian nào).
- Xác định owner (HR, finance, business lead).
- Thu thập baseline từ People/cấu trúc tổ chức.
- Tạo 2–3 kịch bản và so sánh tác động.
- Chuyển kế hoạch đã duyệt thành hành động tuyển dụng/onboarding.
- Rà soát kế hoạch vs thực tế hàng tháng và cập nhật.
6) Quy trình “happy path” #1 — Chạy một kế hoạch quý mini
Dùng khi bạn mới áp dụng và muốn có “thắng lợi” đầu tiên an toàn.
- Chọn 1 phòng ban và 1 quý làm phạm vi pilot.
- Lấy headcount hiện tại và dữ liệu cấu trúc từ People.
- Định nghĩa ràng buộc (ngân sách, vai trò trọng yếu, timeline).
- Tạo 2 kịch bản: baseline vs tăng trưởng (hoặc baseline vs đóng băng).
- Review kịch bản với stakeholders và chọn 1 kế hoạch.
- Chuyển kế hoạch thành hành động: role cần tuyển, backfill, thời điểm.
- Đặt checkpoint rà soát hàng tháng.
7) Quy trình “happy path” #2 — Rà soát hàng tháng: kế hoạch vs thực tế
Dùng để giữ kế hoạch “bám thực tế”, tránh kiểu “lập một lần rồi bỏ”.
- Lấy snapshot headcount hiện tại (từ People và/hoặc Reports).
- So sánh thực tế vs kế hoạch theo từng team.
- Xác định chênh lệch: role đang mở, attrition, trễ ngày bắt đầu.
- Chốt điều chỉnh: tăng tốc, tạm dừng, hoặc đổi ưu tiên.
- Cập nhật giả định và ghi lại quyết định.
- Thông báo thay đổi cho recruiters và managers.
8) Điểm quyết định (A/B)
Các lựa chọn này quyết định tốc độ áp dụng và độ chính xác.
| Quyết định | Nếu A… | Nếu B… |
|---|---|---|
| Kích thước phạm vi | Nhỏ → học nhanh | Lớn → tác động lớn, rủi ro cao hơn |
| Số lượng kịch bản | 2 kịch bản → rõ ràng | Nhiều → sa lầy phân tích |
| Nhịp rà soát | Hàng tháng → chính xác | Hàng quý → ít overhead, dễ lệch |
| Nguồn đầu vào | Dữ liệu People → nhất quán | Spreadsheet → linh hoạt, dễ lệch dữ liệu |
9) Lỗi thường gặp + guardrails
Hoạch định thất bại khi giả định bị “ẩn” và không ai sở hữu việc theo sát triển khai.
- Lỗi: phạm vi không rõ → Tránh: chốt team và thời gian thật cụ thể.
- Lỗi: không có owner duy nhất → Tránh: chỉ định 1 người chịu trách nhiệm cuối.
- Lỗi: quá nhiều kịch bản → Tránh: giữ 2–3 kịch bản.
- Lỗi: không review plan-vs-actual → Tránh: checkpoint hàng tháng.
- Lỗi: dữ liệu People không được duy trì → Tránh: gán người “sở hữu dữ liệu People”.
10) Thế nào là “tốt” + checklist + bài thực hành + tài liệu chính thức
Giữ hoạch định nhẹ nhàng nhưng lặp lại được.
Thế nào là “tốt”
- Phạm vi và owner rõ ràng.
- Kế hoạch chuyển thành hành động cụ thể.
- Tuân thủ nhịp rà soát.
- Giả định được ghi lại.
Checklist: Trước khi làm
- Chọn phạm vi pilot
- Thu thập đầu vào
- Định nghĩa ràng buộc
- Chuẩn bị kịch bản
- Lên lịch họp review
Checklist: Sau khi làm
- Kế hoạch được duyệt
- Giao việc/hành động
- Chốt timeline tuyển
- Đặt review hàng tháng
- Tạo nhật ký quyết định
Bài thực hành (5–15 phút)
Mục tiêu: tạo kế hoạch cho 1 team trong một tài liệu đơn giản.
- Ghi headcount hiện tại của 1 team.
- Ghi headcount mục tiêu cho quý tới.
- Liệt kê 3 giả định (ngân sách, timeline, vai trò ưu tiên).
- Tạo 2 kịch bản và chọn 1.
Link tài liệu chính thức (tiêu đề)
- About Workforce Planning with Engage
Báo cáo (Analytics 2.0)
- Dùng Analytics 2.0 cho dashboard và báo cáo đã lưu.
- Bắt đầu với 1 dashboard để theo dõi vận hành HR.
- Tạo, lưu và chia sẻ báo cáo theo cách an toàn.
- Nắm các loại báo cáo (và cái nào nên export).
1) Mục đích, dành cho ai, và bấm ở đâu
Reports giúp bạn biến hoạt động trong Deel thành “độ nhìn thấy”: dashboard để giám sát và report để phân tích sâu. Mục tiêu là trả lời nhanh các câu hỏi vận hành (headcount, tổng hợp payroll, tốc độ xử lý quy trình) mà không cần spreadsheet thủ công.
- Dành cho: HR admins, finance partners, ops leaders, analysts.
- Khi dùng: review vận hành theo tuần, báo cáo tháng, audit, cập nhật cho lãnh đạo.
- Vị trí trong điều hướng: Help Center → For business → Reports.
- Tab liên quan: People Management, Time Off, Compensation, Integrations & API (exports/connectors).
- Kết quả: 1 dashboard đã lưu + 1 report đã lưu để stakeholders tái sử dụng.
2) Mô hình tư duy (dashboard vs report)
Dashboard dùng để theo dõi liên tục; report dùng để trả lời một câu hỏi cụ thể và dễ chia sẻ/xuất dữ liệu. Bắt đầu với 1 dashboard, rồi thêm 1 report cho mỗi câu hỏi lặp lại.
- Chọn một câu hỏi hay gặp (vd: “Tình trạng workforce hiện tại?”).
- Tạo dashboard để giám sát nhanh.
- Tạo report chi tiết để drill-down.
- Lưu và chia sẻ với quyền truy cập được kiểm soát.
3) Đối tượng & thuật ngữ
Các thuật ngữ này bám trực tiếp theo bài viết Reports.
- Analytics 2.0: năng lực báo cáo được nhắc trong tài liệu.
- Dashboard: màn hình theo dõi đã lưu.
- Report: truy vấn/màn hình đã lưu có thể chia sẻ.
- Custom report: report do bạn tự thiết kế và chia sẻ.
- Total Payroll Summary Report: báo cáo tổng hợp payroll có thể tải xuống.
4) Vòng đời / state machine (quản trị báo cáo)
Report thường “nở” rất nhanh. Dùng vòng đời nhẹ để báo cáo luôn đáng tin.
- Bản nháp (Draft): tạo report/dashboard cho một câu hỏi.
- Đã kiểm chứng (Validated): đối chiếu số liệu với nguồn tin cậy.
- Công bố (Published): lưu với tên rõ ràng và có owner.
- Chia sẻ (Shared): cấp quyền đúng nhóm người cần.
- Bảo trì (Maintained): rà soát khi định nghĩa/nguồn dữ liệu thay đổi.
- Lưu trữ (Archived): loại bỏ báo cáo cũ để tránh nhầm lẫn.
5) Các công việc cốt lõi (JTBD)
Các việc này khớp bài viết chính thức và nhu cầu phổ biến lúc mới triển khai.
- Nắm kiến thức cơ bản về Analytics 2.0.
- Tạo và lưu dashboards.
- Tạo và lưu reports.
- Quyết định các loại report bạn cần.
- Tạo và chia sẻ một custom report.
- Xem và tải Total Payroll Summary Report.
6) Quy trình “happy path” #1 — Tạo dashboard đầu tiên
Dùng khi bạn muốn có một nơi duy nhất để theo dõi tín hiệu HR/ops hàng tuần.
- Mở Analytics 2.0 và chốt mục đích dashboard (ops, payroll, people).
- Chọn 3–5 chỉ số trả lời câu hỏi tuần của bạn.
- Tạo dashboard và sắp xếp để nhìn là hiểu.
- Lưu dashboard với tên rõ ràng và chỉ định owner.
- Chia sẻ với nhóm tối thiểu cần thiết.
- Review trong họp tuần và tinh chỉnh.
7) Quy trình “happy path” #2 — Tạo và chia sẻ custom report
Dùng khi bạn có một câu hỏi lặp lại và cần câu trả lời nhất quán + view có thể chia sẻ.
- Viết rõ câu hỏi report phải trả lời.
- Tạo report trong Analytics 2.0 bám theo câu hỏi đó.
- Kiểm chứng bằng cách spot-check một vài bản ghi.
- Lưu theo quy ước đặt tên (Team — Mục đích — Tần suất).
- Chia sẻ cho đúng stakeholders.
- Đặt nhắc nhở rà soát report hàng tháng để đảm bảo còn phù hợp.
8) Điểm quyết định (A/B)
Các lựa chọn này ảnh hưởng mức độ tin cậy và chi phí bảo trì.
| Quyết định | Nếu A… | Nếu B… |
|---|---|---|
| Dashboard vs report | Dashboard → giám sát | Report → phân tích sâu |
| Chia sẻ rộng vs hẹp | Rộng → minh bạch, rủi ro | Hẹp → an toàn, nhiều yêu cầu hơn |
| Một report “master” vs nhiều report | Master → một nguồn sự thật, phức tạp | Nhiều → linh hoạt, dễ “phình” |
| Mức độ kiểm chứng | Cao → đáng tin, tốn thời gian | Thấp → nhanh, rủi ro sai số |
9) Lỗi thường gặp + guardrails
Đau khổ reporting thường đến từ định nghĩa mơ hồ và “sprawl” quá nhiều báo cáo.
- Lỗi: định nghĩa metric không rõ → Tránh: ghi định nghĩa trong mô tả report.
- Lỗi: quá nhiều dashboard giống nhau → Tránh: chỉ định owner và archive bản trùng.
- Lỗi: chia sẻ dữ liệu nhạy cảm quá rộng → Tránh: chia sẻ theo nguyên tắc least-privilege và kiểm tra role.
- Lỗi: không kiểm chứng → Tránh: spot-check trước khi publish.
- Lỗi: quên nhu cầu payroll summary → Tránh: chuẩn hoá cách tải và lưu trữ bản tổng hợp.
10) Thế nào là “tốt” + checklist + bài thực hành + tài liệu chính thức
Dùng như checklist nâng cấp “độ trưởng thành” reporting.
Thế nào là “tốt”
- Có 1 dashboard ops dùng hàng tuần.
- Các câu hỏi hay gặp có report đã lưu.
- Report có owner và được bảo trì.
- Chia sẻ đúng vai trò và tôn trọng quyền riêng tư.
Checklist: Trước khi làm
- Xác định câu hỏi
- Chọn dashboard hay report
- Chọn metrics
- Lên kế hoạch kiểm chứng
- Chốt quy ước đặt tên
Checklist: Sau khi làm
- Đã lưu & đặt tên rõ
- Đã spot-check độ đúng
- Đã chia sẻ đúng nhóm
- Đã gán owner
- Đã đặt nhịp rà soát
Bài thực hành (5–15 phút)
Mục tiêu: tạo 1 dashboard hoặc report cho một câu hỏi lặp lại.
- Chọn 1 câu hỏi bạn phải trả lời mỗi tuần.
- Tạo dashboard hoặc report trả lời câu hỏi đó.
- Lưu với tên rõ ràng.
- Chia sẻ cho 1 stakeholder và nhờ họ tự tra lần sau.
Link tài liệu chính thức (tiêu đề)
- Analytics 2.0 Overview in Deel
- How to Create and Save Dashboards in Deel Analytics 2.0
- How to Create and Save Reports in Deel Analytics 2.0
- What Kinds Of Reports Can Be Generated On Deel?
- How to Create and Share a Custom Report
- How To View And Download A Total Payroll Summary Report
Tích hợp & API
- Nắm các nhóm tích hợp (HRIS, ATS, SSO, SCIM, SFTP, API, ...).
- Chỉ bắt đầu identity (SSO/SCIM) khi mô hình role đã ổn định.
- Kết nối HRIS/ATS sau khi dữ liệu People đã sạch.
- Ghi rõ ownership dữ liệu và quy tắc đồng bộ.
1) Mục đích, dành cho ai, và bấm ở đâu
Integrations & API giúp bạn kết nối Deel với các hệ thống khác (HRIS, ATS, kế toán, identity, truyền file, và API). Mục tiêu là giảm cập nhật thủ công và có chiến lược “system-of-record” rõ ràng.
- Dành cho: chủ sở hữu HRIS, IT admins, operations, developers (API).
- Khi dùng: sau khi dữ liệu People và roles đủ ổn định để tự động hoá an toàn.
- Vị trí trong điều hướng: Help Center → For business → Integrations & API.
- Tab liên quan: People Management, Roles & Permissions, Reports.
- Kết quả: 1 tích hợp chạy thật với quy tắc đồng bộ + owner được tài liệu hoá.
2) Mô hình tư duy (hệ thống + quy tắc đồng bộ)
Mọi tích hợp đều cần quyết định “nguồn sự thật” (source of truth). Hãy chốt hệ thống nào làm chủ từng field, rồi định nghĩa hướng đồng bộ và nhịp đồng bộ.
- Chọn hệ thống master cho dữ liệu worker cốt lõi.
- Quyết định Deel sẽ đẩy (push) hay kéo (pull) dữ liệu nào.
- Định nghĩa ai chịu trách nhiệm khi lỗi và cách đối soát.
- Rollout theo pilot trước khi mở cho toàn bộ org.
3) Đối tượng & thuật ngữ (nhóm tích hợp)
Các nhóm này được liệt kê trực tiếp dưới Integrations & API trong navigation chính thức.
- Tích hợp HRIS
- Tích hợp ATS (Applicant Tracking System)
- Tích hợp SSO
- Tích hợp SCIM
- Tích hợp SFTP
- Tích hợp Quản lý người dùng
- Tích hợp Kế toán
- Deel API
4) Vòng đời / state machine (triển khai tích hợp)
Hãy coi tích hợp như rollout sản phẩm để tránh “data drift im lặng”.
- Lên kế hoạch (Planned): use-case, owners, và source-of-truth được chốt.
- Cấu hình (Configured): tạo kết nối và set quyền.
- Pilot (Piloted): kiểm chứng một nhóm user/record nhỏ.
- Theo dõi (Monitored): theo dõi lỗi và drift.
- Mở rộng (Scaled): mở ra toàn tổ chức.
- Bảo trì (Maintained): đối soát định kỳ và quản lý thay đổi.
5) Các công việc cốt lõi (JTBD)
Dùng các việc này làm “kế hoạch triển khai tích hợp”.
- Chọn nhóm tích hợp (HRIS, ATS, SSO, ...).
- Định nghĩa dữ liệu nào sync và sync theo hướng nào.
- Thiết lập identity (SSO/SCIM) để scale quản trị truy cập (nếu cần).
- Kết nối ATS nếu cần đồng bộ pipeline tuyển dụng.
- Dùng SFTP cho luồng dựa trên file nếu bắt buộc.
- Dùng Deel API cho nhu cầu tuỳ biến.
6) Quy trình “happy path” #1 — Kết nối HRIS (pilot)
Dùng khi bạn muốn dữ liệu worker nhất quán giữa các hệ thống.
- Chọn luồng tích hợp HRIS trong Integrations & API.
- Chốt source-of-truth cho các field (name, email, manager, ...).
- Kiểm tra Roles & Permissions để đúng admin có thể cấu hình tích hợp.
- Pilot với một nhóm worker nhỏ.
- Kiểm chứng: worker khớp giữa hai hệ thống và quan hệ manager đúng.
- Ghi tài liệu quy tắc sync và cách xử lý khi lệch dữ liệu.
- Mở rộng cho phần còn lại của org.
7) Quy trình “happy path” #2 — Rollout SSO/SCIM an toàn
Dùng khi bạn sẵn sàng scale quản trị truy cập và muốn giảm invite/remove thủ công.
- Chốt owner hệ thống định danh nội bộ (IT) và policy truy cập.
- Xác nhận mô hình role trong Deel (Org Admin/Group Admin/Manager) đã ổn định.
- Chọn tích hợp SSO để cấu hình đăng nhập.
- Chọn tích hợp SCIM để provisioning (nếu bạn muốn tự động hoá vòng đời user).
- Pilot với một nhóm admin nhỏ và kiểm tra login + quyền.
- Test offboarding: quyền bị gỡ khi user bị deprovision.
- Mở rộng từ từ và theo dõi lỗi truy cập.
8) Điểm quyết định (A/B)
Các lựa chọn này định hình kiến trúc tích hợp.
| Quyết định | Nếu A… | Nếu B… |
|---|---|---|
| API vs tích hợp native | Native → setup nhanh | API → linh hoạt, cần dev |
| Thời điểm bật SSO | Sớm → auth nhất quán | Muộn → ít rủi ro, nhiều thủ công |
| Provisioning SCIM | Dùng SCIM → tự động vòng đời | Không SCIM → quản lý user thủ công |
| Hướng đồng bộ | Một chiều → đơn giản | Hai chiều → phức tạp, rủi ro xung đột |
9) Lỗi thường gặp + guardrails
Sai lầm tích hợp rất “đắt” vì tạo ra drift âm thầm.
- Lỗi: tích hợp trước khi dọn dữ liệu → Tránh: xử lý duplicates và structure trước.
- Lỗi: source-of-truth mơ hồ → Tránh: ghi rõ ownership theo field.
- Lỗi: cấp quyền admin quá rộng để setup → Tránh: least-privilege và giới hạn thời gian.
- Lỗi: bỏ qua pilot → Tránh: pilot nhóm nhỏ.
- Lỗi: không có owner xử lý lỗi → Tránh: chỉ định ai monitor và fix sync issues.
10) Thế nào là “tốt” + checklist + bài thực hành + tài liệu chính thức
Giữ tích hợp an toàn và dễ bảo trì.
Thế nào là “tốt”
- 1 tích hợp chạy ổn cho nhóm pilot.
- Quy tắc source-of-truth được tài liệu hoá.
- Truy cập và offboarding được test.
- Monitoring và ownership rõ ràng.
Checklist: Trước khi làm
- Dữ liệu People đã sạch
- Mô hình roles ổn định
- Owners đã chỉ định
- Sync rules đã viết
- Nhóm pilot đã chọn
Checklist: Sau khi làm
- Pilot đã kiểm chứng
- Đã có cách xử lý lỗi
- Docs đã cập nhật
- Đã có kế hoạch scale
- Đã đặt nhịp đối soát
Bài thực hành (5–15 phút)
Mục tiêu: định nghĩa “hợp đồng tích hợp” trước khi kết nối thật.
- Chọn 1 nhóm tích hợp (HRIS hoặc SSO).
- Liệt kê 5 field và chỉ rõ field nào master ở đâu.
- Ghi hướng sync và nhịp sync.
- Ghi ai chịu trách nhiệm khi lỗi và theo dõi ở đâu.
Link tài liệu chính thức (nhóm theo navigation)
- HRIS Integrations
- Applicant Tracking System (ATS) Integrations
- SSO Integrations
- SCIM Integrations
- SFTP Integrations
- User Management Integrations
- Accounting Integrations
- Deel API