Vì sao đội tám người vẫn nên dùng danh tính đăng nhập riêng thay vì một tài khoản chung?

Một agency tám người ở Đà Nẵng gọi cho tôi vào cuối tháng trước, giọng khá bối rối: bạn trưởng nhóm vận hành nghỉ việc hôm thứ sáu, đến thứ hai không ai mở được mười bốn hồ sơ của khách, và bên khách phải tự ngồi đặt lại thông tin đăng nhập. Lỗi không nằm ở việc họ thiếu công cụ. Họ có BitBrowser từ hồi ba người, nhưng vẫn dùng chung một tài khoản chủ cho cả tám, nên khi một người rời đi thì ranh giới giữa con người và tài sản cũng biến mất theo.

Chẩn đoán: người rời đi, tài sản đi theo

Trong các đội vận hành tôi từng làm cùng, sự cố kiểu này hay bắt đầu rất hiền. Lúc mới có ba người, chia sẻ một tài khoản cho nhanh. Đến tám người thì vẫn một tài khoản, cộng thêm một file Excel mật khẩu gửi qua tin nhắn. Không ai làm sai có chủ đích, chỉ là không có lúc nào ngồi xuống định nghĩa: ai được mở cái gì, ai được sửa cái gì, và khi ai đó nghỉ thì bàn giao bằng cách nào. Câu trả lời thường không phải phần mềm mới, mà là bốn lớp cần dựng lại.

Bốn lớp: Người, Quyền, Tài sản, Đối soát

Người là danh tính đăng nhập riêng cho từng thành viên, không phải một tài khoản chung. Quyền là tập hợp thao tác được phép, gắn theo vai trò chứ không gắn theo tên người. Tài sản là hồ sơ, nhóm, proxy và Cookie, được xếp theo từng khách hàng. Đối soát là nhật ký thao tác đọc được vào cuối tuần, để biết ai sửa cấu hình lúc nào.

Bốn lớp này phải tách nhau thì mới sửa được từng chỗ. Ví dụ thực tập sinh chỉ cần mở hồ sơ để đăng nội dung đã được duyệt, không cần quyền sửa proxy, càng không cần quyền xuất Cookie. Khi bạn ấy nghỉ, chỉ việc thu hồi một danh tính đăng nhập; mười bốn hồ sơ vẫn nằm nguyên dưới tên công ty. Nghe đơn giản, nhưng đúng là thứ mà agency ở Đà Nẵng chưa làm.

Bảng phân quyền nên có trước khi thêm người thứ tư

Hệ thống bốn vai trò (quản trị, quản lý, thành viên, tùy chỉnh) cho phép dựng đúng bảng này mà không cần viết code. Cột "tùy chỉnh" là chỗ tôi hay dùng nhất: một nhóm trưởng chỉ được quản lý đúng ba khách hàng của mình, không thấy gì của các nhóm khác. Lưu ý thêm là mỗi hồ sơ gắn được tối đa ba nhãn, toàn hệ thống tối đa hai mươi nhãn, nên đặt tên nhãn theo mã khách hàng ngay từ đầu, đừng đặt theo tên nhân viên.

Giá niêm yết mới là một nửa câu chuyện

Đội hay so giá theo số hồ sơ, rồi giật mình khi tháng thứ tư tăng từ ba lên tám người. Tiền nằm ở ghế thành viên.

Bảng quy theo 1 USD = 25.873 VND, lấy từ trang giá công bố ngày 16/10/2026, và "chưa công bố" không có nghĩa là không hỗ trợ. Điều tôi muốn đội Đà Nẵng thấy là cột cuối cùng: cùng tám người, bên nào cho thêm từng ghế với ~52.000 đồng thì khác hẳn bên bắt nhảy lên gói ~1,18 triệu đồng. Đó là khoảng cách chi phí thật sự giữa "mua công cụ" và "vận hành một đội".

Trang giá OmniLogin với hai cột Free Edition và Pro Edition Licenses, thanh trượt điều chỉnh số browser profiles và team members

Trang giá GemLogin, các gói được liệt kê theo số lượng hồ sơ kèm lựa chọn thanh toán

Bảy bước bàn giao, làm một lần rồi thành thói quen

Bước 1: Đăng ký tài khoản chủ và bật xác thực hai yếu tố

Việc cần làm: lập tài khoản công ty bằng email và số điện thoại của tổ chức, bật xác thực hai yếu tố. Lý do: tài khoản chủ là nơi giữ toàn bộ quyền. Bẫy hay gặp: đăng ký bằng email cá nhân của một nhân viên, người đó nghỉ là mất quyền quản trị.

Màn hình đăng ký và cài đặt, các trường thông tin cơ bản cùng bước xác nhận điều khoản

Bước 2: Dựng vai trò trước, thêm người sau

Việc cần làm: tạo bốn vai trò theo bảng ở mục 3. Lý do: gán quyền theo vai trò thì thêm hay bớt người chỉ mất một thao tác. Bẫy hay gặp: thêm tám người rồi sửa quyền từng người một.

Bước 3: Cấp danh tính đăng nhập riêng cho từng thành viên

Việc cần làm: mỗi người một tên đăng nhập và mật khẩu riêng. Lý do: nhật ký thao tác mới quy được về đúng người. Bẫy hay gặp: một tài khoản chủ đăng nhập đồng thời trên nhiều máy; phần mềm không hỗ trợ kiểu dùng này, nên phải chia ghế thành viên.

Bước 4: Chia nhóm hồ sơ theo khách hàng, không chia theo nhân viên

Việc cần làm: mỗi khách một nhóm, đặt tên theo mã hợp đồng. Lý do: nhân viên có thể thay, khách thì ở lại. Bẫy hay gặp: đặt nhóm theo tên người, đến lúc bàn giao phải đổi tên hàng loạt.

Danh sách hồ sơ được xếp theo nhóm, mỗi dòng có mã riêng và thông tin cấu hình đi kèm

Bước 5: Gán quyền theo nhóm rồi cho chạy thử ba ngày

Việc cần làm: để một thành viên thử mở, sửa, xuất trong môi trường thật. Lý do: bảng phân quyền chỉ đúng khi có người thử nó. Bẫy hay gặp: gán quyền quá rộng "để khỏi vướng", rồi không dò được lỗi khi có sự cố.

Bước 6: Bàn giao bằng mã chia sẻ có thời hạn hoặc chuyển chủ hồ sơ

Việc cần làm: dùng mã chia sẻ có hạn 7 đến 30 ngày cho việc ngắn hạn, dùng chức năng chuyển chủ khi thay người phụ trách hẳn. Lý do: hai việc này khác nhau, mã chia sẻ không làm thay đổi chủ sở hữu. Bẫy hay gặp: gửi mã qua tin nhắn rồi quên mất, để mã còn hiệu lực khi người nhận đã rời đội.

Bước 7: Đọc nhật ký vào chiều thứ sáu

Việc cần làm: rà các thao tác sửa proxy, xuất Cookie, xóa hồ sơ trong tuần. Lý do: đa số sự cố có dấu hiệu trước vài ngày. Bẫy hay gặp: chỉ mở nhật ký khi đã có chuyện.

Năm cái bẫy mà đội nào cũng dính ít nhất một lần

Dùng chung một tài khoản đăng nhập cho cả team là bẫy đầu tiên. Thứ hai là để mã chia sẻ quá hạn mà không thu hồi. Thứ ba là xóa hồ sơ trong thùng rác: xóa ở đó là mất hẳn, không khôi phục được, nên với hồ sơ của khách hãy chuyển chủ thay vì xóa. Thứ tư là quên bật xác thực hai yếu tố cho tài khoản chủ. Thứ năm, tế nhị hơn, là giao quyền xuất Cookie cho người không cần đến nó chỉ vì "cho tiện".

Bốn dòng đối soát cuối tuần

Sau khi dựng lại bốn lớp, agency ở Đà Nẵng mất đúng một buổi chiều, nhưng họ có thêm thứ quý hơn: một quy trình bàn giao bảo vệ được hợp đồng với khách. Nút thắt của một đội vận hành đa tài khoản gần như không bao giờ là số hồ sơ. Nó nằm ở hạt quyền và ở chi phí thêm một người. Cứ định nghĩa rõ ai được làm gì trước, rồi hãy bàn đến việc mua thêm bao nhiêu chỗ.