Shared Mailbox phù hợp với sales@ và support@ như thế nào?

Trong nhiều doanh nghiệp, các địa chỉ như sales@company.com, support@company.com, info@company.com hoặc contact@company.com được nhiều người cùng sử dụng.

Nếu doanh nghiệp xử lý các địa chỉ này bằng cách tạo một tài khoản chung rồi chia sẻ username và password cho cả team, việc vận hành có thể nhanh ở giai đoạn đầu nhưng rất dễ phát sinh vấn đề về bảo mật, trách nhiệm và quản trị.

Microsoft 365 cung cấp một cách phù hợp hơn: Shared Mailbox.

Microsoft mô tả Shared Mailbox là mailbox được thiết kế cho nhiều người cùng truy cập và gửi email từ một địa chỉ chung, chẳng hạn info@, support@ hoặc các địa chỉ dịch vụ khác. Người dùng có quyền phù hợp có thể đọc thư, trả lời và gửi email dưới danh nghĩa mailbox chung.

Với doanh nghiệp, giá trị lớn nhất của Shared Mailbox không chỉ là “nhiều người cùng xem email”.

Nó giúp biến một địa chỉ chung thành một kênh làm việc được quản trị, thay vì một tài khoản dùng chung không rõ ai đã xử lý gì.

Shared Mailbox là gì?

Shared Mailbox là mailbox trong Exchange Online dành cho nhiều người cùng sử dụng.

Ví dụ:

sales@company.com

support@company.com

hr@company.com

reception@company.com

admin@company.com

Các thành viên không cần đăng nhập trực tiếp bằng password của mailbox. Thay vào đó, Admin cấp quyền cho từng tài khoản cá nhân.

Microsoft hỗ trợ các quyền phổ biến như:

Full Access – đọc, tạo, chỉnh sửa và xóa nội dung trong mailbox.

Send As – gửi email như thể chính Shared Mailbox gửi.

Send on Behalf – gửi email dưới dạng “User on behalf of Shared Mailbox”.

Điều này giúp doanh nghiệp giữ được cả tính chuyên nghiệp lẫn khả năng kiểm soát.

Vì sao sales@ phù hợp với Shared Mailbox?

Một địa chỉ sales@company.com thường không thuộc về một nhân viên cụ thể.

Nó thuộc về Sales Team.

Khách hàng có thể gửi yêu cầu báo giá, hỏi thông tin sản phẩm hoặc yêu cầu tư vấn vào địa chỉ này.

Nếu chỉ forward email từ sales@ sang từng nhân viên, team có thể gặp những tình huống như:

Hai người cùng trả lời một khách hàng.

Không ai trả lời vì nghĩ người khác đã xử lý.

Người gửi không biết đồng nghiệp đã phản hồi chưa.

Khi một Sales nghỉ việc, lịch sử trao đổi nằm trong mailbox cá nhân.

Shared Mailbox giúp giảm các vấn đề này.

Tất cả email vào sales@ nằm trong cùng một mailbox.

Những Sales có quyền phù hợp có thể đọc và xử lý cùng một nguồn dữ liệu.

Nếu cấu hình đúng, email trả lời có thể hiển thị từ:

sales@company.com

thay vì địa chỉ cá nhân của từng Sales.

Đối với khách hàng, trải nghiệm nhất quán hơn.

Đối với Sales Manager, luồng trao đổi cũng dễ theo dõi hơn.

Một workflow thực tế cho sales@

Giả sử khách hàng gửi:

“Chúng tôi muốn nhận báo giá Microsoft 365 cho 50 users.”

Email đi vào sales@company.com.

Một Sales Executive mở mailbox, kiểm tra yêu cầu và trả lời bằng Send As.

Khách hàng nhìn thấy:

From: sales@company.com

thay vì email cá nhân của người xử lý.

Sau đó khi Sales nghỉ phép, một đồng nghiệp khác vẫn có thể xem toàn bộ lịch sử trước đó và tiếp tục xử lý.

Đây là lợi ích rất lớn so với việc conversation nằm trong mailbox cá nhân.

Vì sao support@ còn phù hợp hơn?

Support mailbox là một trong những use case điển hình mà Microsoft đề cập khi nói về Shared Mailbox.

Một địa chỉ support thường có nhiều người cùng theo dõi.

Ví dụ:

support@company.com

Khách hàng có thể gửi lỗi sản phẩm, yêu cầu kỹ thuật hoặc câu hỏi sử dụng.

Nếu team dùng mailbox chung với shared password, sẽ rất khó kiểm soát:

Ai đã đọc?

Ai đã trả lời?

Ai đang xử lý?

Người nào đang dùng password?

Có ai đã nghỉ việc nhưng vẫn biết password không?

Shared Mailbox giải quyết phần quyền truy cập bằng cách gán permission cho từng user.

Khi một Support Engineer nghỉ việc, Admin chỉ cần gỡ quyền của user đó.

Không cần đổi password cho cả team.

Shared Mailbox giúp support giữ một địa chỉ nhất quán

Khách hàng thường không quan tâm nhân viên support cụ thể là ai. Họ chỉ muốn gửi yêu cầu tới:

support@company.com

và nhận câu trả lời từ đúng kênh đó.

Send As đặc biệt phù hợp trong trường hợp này.

Microsoft mô tả Send As là quyền cho phép email xuất hiện như được gửi trực tiếp từ mailbox chung, không hiển thị tên delegate.

Ví dụ:

From: support@company.com

thay vì:

From: anh.nguyen@company.com

Điều này tạo ra hình ảnh chuyên nghiệp và nhất quán hơn.

Send As và Send on Behalf khác nhau thế nào?

Đây là điểm Admin cần hiểu rõ.

Nếu sử dụng Send As, người nhận thấy:

From: support@company.com

Không có thông tin cho thấy nhân viên nào thực hiện thao tác gửi.

Nếu sử dụng Send on Behalf, người nhận sẽ thấy dạng:

Anh Nguyen on behalf of Support

Microsoft xác nhận Send on Behalf hiển thị rõ delegate gửi thay mặt mailbox, trong khi Send As khiến message trông như được gửi trực tiếp từ mailbox.

Với sales@ hoặc support@, nhiều doanh nghiệp thường ưu tiên Send As vì muốn duy trì một identity chung.

Tuy nhiên, lựa chọn này phụ thuộc vào yêu cầu minh bạch và governance.

Full Access có đồng nghĩa với quyền gửi email không?

Đây là một lỗi cấu hình khá phổ biến. Microsoft xác nhận Full Access cho phép người dùng mở mailbox, đọc, chỉnh sửa và xóa message, nhưng không tự động cho phép họ gửi email từ mailbox.

Muốn gửi, Admin vẫn cần cấp thêm:

Send As

hoặc

Send on Behalf.

Vì vậy, với một Sales Executive cần vừa đọc vừa trả lời từ sales@, cấu hình thường cần:

Full Access + Send As

Nếu chỉ cấp Full Access, người dùng có thể mở mailbox nhưng không gửi dưới địa chỉ chung.

Có nên chia sẻ password của sales@ cho cả team không?

Microsoft Shared Mailbox được thiết kế để người dùng truy cập thông qua permission từ tài khoản cá nhân của họ, không phải bằng cách nhiều người đăng nhập cùng một account chung.

Microsoft thậm chí khuyến nghị block sign-in trực tiếp cho account Shared Mailbox được tạo trong Exchange Online, vì đối tượng này không được thiết kế để người dùng đăng nhập như user mailbox bình thường.

Dùng shared password tạo ra nhiều rủi ro.

Khi nhân viên nghỉ việc, doanh nghiệp phải đổi password.

Không dễ xác định ai đã thực hiện thao tác.

MFA trở nên khó quản lý.

Password có thể bị lưu trên nhiều thiết bị.

Audit và governance kém hơn.

Shared Mailbox + user permission là cách an toàn và dễ quản trị hơn.

Shared Mailbox có cần license riêng không?

Microsoft hiện cho phép Shared Mailbox lưu tối đa 50 GB mà không cần gán license riêng.

Tuy nhiên, đây không nên được hiểu là Shared Mailbox hoàn toàn “không bao giờ cần license”.

Nếu mailbox vượt giới hạn dung lượng hoặc cần một số capability nâng cao như archive hoặc compliance feature cụ thể, yêu cầu licensing có thể thay đổi.

Ngoài ra, người dùng truy cập Shared Mailbox vẫn cần license Exchange Online/Microsoft 365 phù hợp của riêng họ theo điều kiện sử dụng.

Doanh nghiệp nên kiểm tra licensing thực tế nếu mailbox có yêu cầu storage hoặc compliance đặc biệt.

Một vấn đề quan trọng: Sent Items

Đây là phần rất dễ bị bỏ sót khi triển khai. Theo mặc định, khi một người gửi email từ Shared Mailbox, message đã gửi có thể được lưu trong Sent Items của người thực hiện gửi, thay vì Sent Items của Shared Mailbox.

Với support@, điều này có thể tạo ra một vấn đề lớn.

Nhân viên A trả lời khách hàng.

Nhân viên B mở mailbox chung nhưng không thấy email đã gửi.

B nghĩ chưa ai xử lý và trả lời lần nữa.

Để tránh điều này, Admin nên cấu hình Shared Mailbox để giữ bản sao của message Send As hoặc Send on Behalf trong Sent Items của mailbox chung. Microsoft hỗ trợ thiết lập này trong Microsoft 365 admin center.

Đây gần như là một cấu hình nên kiểm tra ngay khi triển khai sales@ hoặc support@.

Shared Mailbox có thay thế ticketing system không?

Shared Mailbox rất phù hợp cho những team support nhỏ hoặc workflow email đơn giản.

Nhưng khi khối lượng ticket tăng, doanh nghiệp sẽ bắt đầu cần thêm:

Ticket ID.

Priority.

SLA.

Assignment.

Escalation.

Status.

Reporting.

Customer history.

Automation.

Shared Mailbox bản thân nó không phải một helpdesk platform hoàn chỉnh.

Nếu Support Team chỉ nhận 10–20 email mỗi ngày, Shared Mailbox có thể đủ.

Nếu có hàng trăm request và SLA phức tạp, doanh nghiệp nên cân nhắc ticketing system hoặc CRM service module.

Có thể hiểu:

Shared Mailbox = shared email workflow

không phải:

Shared Mailbox = full ticket management system

Shared Mailbox có thay CRM cho Sales không?

Cũng không.

sales@ giúp nhiều người cùng nhận và trả lời inquiry.

Nhưng nó không quản lý đầy đủ:

Lead stage.

Opportunity value.

Sales pipeline.

Forecast.

Follow-up activity.

Win/loss.

Customer profile.

Nếu Sales Team nhỏ, Shared Mailbox có thể là một điểm tiếp nhận lead rất tốt.

Khi quy trình phức tạp hơn, CRM nên tiếp quản phần pipeline và customer relationship.

Làm sao tránh hai người cùng trả lời một email?

Shared Mailbox không tự động biến mỗi email thành một assigned task.

Đây là hạn chế cần hiểu rõ.

Với team nhỏ, doanh nghiệp có thể xây dựng quy ước đơn giản.

Ví dụ, người xử lý có thể:

Gắn category.

Move email sang folder “In Progress”.

Flag message.

Move sang folder theo tên người phụ trách.

Hoặc team quy định ai mở trước phải đánh dấu ngay.

Với volume cao hơn, doanh nghiệp nên dùng workflow hoặc ticketing platform chuyên biệt thay vì cố biến Outlook thành hệ thống phân công phức tạp.

Có nên tạo folder trong Shared Mailbox?

Có, nhưng nên giữ đơn giản.

Ví dụ support@ có thể có:

Inbox

In Progress

Waiting for Customer

Completed

Hoặc sales@ có thể có:

New Leads

Contacted

Proposal Sent

Closed

Nhưng nếu cấu trúc folder bắt đầu có quá nhiều cấp và nhiều rule phức tạp, mailbox sẽ trở nên khó quản lý.

Khi đó Lists, CRM hoặc Helpdesk có thể phù hợp hơn.

Shared Mailbox có calendar dùng chung không?

Có.

Shared Mailbox có thể bao gồm cả calendar, và người dùng có permission phù hợp có thể truy cập hoặc quản lý calendar đó. Microsoft nêu rằng người có Full Access có thể tạo calendar items cùng nhiều loại item khác trong mailbox.

Use case này có thể hữu ích cho:

Sales appointment calendar.

Support duty schedule.

Reception booking.

Team availability.

Tuy nhiên, nếu mục tiêu chỉ là cho khách hàng tự đặt lịch, Microsoft Bookings có thể phù hợp hơn.

Một mô hình phân quyền đơn giản cho sales@

Doanh nghiệp có 4 Sales Executive và 1 Sales Manager.

Có thể thiết kế:

Sales Executive
→ Full Access
→ Send As

Sales Manager
→ Full Access
→ Send As

Khi một nhân viên nghỉ việc, IT gỡ permission của người đó.

Mailbox và toàn bộ lịch sử vẫn giữ nguyên.

Không cần chuyển ownership vì mailbox vốn thuộc team.

Đây là một lợi thế lớn của Shared Mailbox.

Một mô hình cho support@

Support Team có 5 người.

Tất cả cần đọc và trả lời ticket.

Có thể sử dụng:

Full Access + Send As

và bật lưu Sent Items vào Shared Mailbox.

Team Lead có thể thiết lập convention:

Unread = chưa được xem.

Category = người phụ trách.

In Progress = đang xử lý.

Waiting = đang chờ khách hàng.

Completed = đã xử lý.

Mô hình này khá phù hợp với team support nhỏ.

Nếu volume tăng mạnh, có thể chuyển sang ticketing system sau.

Nên dùng Distribution List hay Shared Mailbox?

Hai công cụ giải quyết vấn đề khác nhau.

Distribution List chủ yếu dùng để phân phối email tới nhiều người.

Ví dụ:

allstaff@company.com

Khi gửi tới địa chỉ đó, email được gửi tới mailbox cá nhân của từng thành viên.

Shared Mailbox lại cung cấp một mailbox chung để nhiều người cùng đọc và xử lý.

Nếu mục tiêu là:

“Gửi một thông báo cho cả nhóm”

→ Distribution List.

Nếu mục tiêu là:

“Nhiều người cùng quản lý một địa chỉ email”

→ Shared Mailbox.

Với sales@ và support@, Shared Mailbox thường phù hợp hơn.

Nên dùng Microsoft 365 Group hay Shared Mailbox?

Microsoft 365 Group phù hợp hơn với collaboration gồm email conversation, SharePoint, Planner và các tài nguyên nhóm.

Shared Mailbox tập trung rõ hơn vào mailbox chung.

Nếu business process xoay quanh việc nhiều người cùng quản lý email bên ngoài, Shared Mailbox đơn giản và tự nhiên hơn.

Nếu team cần workspace cộng tác rộng hơn ngoài email, Microsoft 365 Group hoặc Teams có thể phù hợp hơn.

Lỗi thường gặp: cấp quyền quá rộng

Không phải ai trong công ty cũng cần truy cập sales@ hoặc support@.

Chỉ nên cấp quyền cho những user thật sự tham gia workflow.

Đặc biệt Full Access cho phép người dùng đọc, tạo, chỉnh sửa và xóa nội dung mailbox.

Vì vậy, permission nên được review định kỳ.

Nhân viên chuyển phòng ban hoặc nghỉ việc cần được gỡ quyền nhanh chóng.

Lỗi thường gặp: không phân biệt Send As và Send on Behalf

Nếu Admin cấu hình Send on Behalf trong khi doanh nghiệp muốn khách hàng chỉ nhìn thấy support@, trải nghiệm sẽ không đúng mong muốn.

Ngược lại, có tổ chức muốn biết người cụ thể nào đã trả lời và chọn Send on Behalf.

Do đó, cần thống nhất từ trước:

Identity chung hoàn toàn → Send As

Muốn thể hiện người xử lý → Send on Behalf

Không nên cấu hình ngẫu nhiên.

Lỗi thường gặp: không bật Shared Sent Items

Đây là lỗi rất phổ biến.

Nếu mỗi người chỉ nhìn thấy email đã gửi trong Sent Items cá nhân, team sẽ không có một lịch sử outbound chung rõ ràng.

Admin nên cân nhắc bật:

Copy messages sent as this mailbox.

Copy messages sent on behalf of this mailbox.

Microsoft 365 admin center hỗ trợ các tùy chọn này trong Shared Mailbox settings.

Lỗi thường gặp: biến mailbox thành kho dữ liệu vĩnh viễn

Shared Mailbox không nên là nơi lưu mọi attachment và lịch sử không giới hạn mà không có retention strategy.

Mailbox có thể tăng dung lượng theo thời gian.

Doanh nghiệp nên review:

Mail nào cần giữ?

Retention bao lâu?

Attachment quan trọng có nên đưa sang SharePoint không?

Có cần compliance policy không?

Với tài liệu chính thức, SharePoint thường phù hợp hơn email.

Lỗi thường gặp: dùng auto-forward thay Shared Mailbox

Một số doanh nghiệp cấu hình sales@ rồi forward email tới 5 Sales.

Kết quả là mỗi người có một copy riêng.

Không ai có single source of truth.

Một người trả lời nhưng những người khác không biết.

Shared Mailbox phù hợp hơn vì mọi người cùng làm việc trên một mailbox.

Có nên bật auto-reply?

Tùy use case.

Với support@, auto-reply có thể hữu ích:

“Chúng tôi đã nhận được yêu cầu và sẽ phản hồi trong giờ làm việc.”

Điều này giúp khách hàng biết email đã đến hệ thống.

Với sales@, doanh nghiệp có thể sử dụng auto-reply nhẹ nhàng nếu muốn xác nhận inquiry.

Tuy nhiên, nếu đã có ticketing hoặc CRM automation, nên tránh gửi nhiều confirmation trùng nhau.

Checklist triển khai Shared Mailbox

Trước khi đưa sales@ hoặc support@ vào sử dụng, doanh nghiệp nên kiểm tra:

• Đã tạo Shared Mailbox thay vì user account dùng chung

• Direct sign-in của Shared Mailbox đã được kiểm soát/block nếu phù hợp

• Thành viên được cấp đúng Full Access

• Đã chọn Send As hoặc Send on Behalf rõ ràng

• Sent Items đã được cấu hình để team cùng xem lịch sử gửi

• Không chia sẻ password chung

• Có naming convention rõ ràng

• Có người owner quy trình

• Thành viên nghỉ việc được gỡ permission

• Folder/category workflow được giữ đơn giản

• Có rule tránh xử lý email trùng

• Đã xác định khi nào cần nâng cấp sang CRM/helpdesk

• Có retention và archive policy phù hợp

• File chính thức được chuyển sang SharePoint nếu cần

• Permission được review định kỳ

Kết luận

Shared Mailbox rất phù hợp với những địa chỉ như:

sales@

support@

info@

reception@

khi nhiều người cần cùng đọc và gửi email từ một identity chung.

Microsoft thiết kế Shared Mailbox chính xác cho những trường hợp nhiều người cần truy cập cùng một mailbox, đặc biệt với các địa chỉ thông tin, support hoặc front desk. Người dùng có thể được cấp Full Access kết hợp với Send As hoặc Send on Behalf tùy cách doanh nghiệp muốn hiển thị người gửi.

Với sales@, Shared Mailbox giúp giữ inquiry và lịch sử khách hàng trong một nơi chung.

Với support@, nó giúp team cùng theo dõi và phản hồi khách hàng mà không cần chia sẻ password.

Một nguyên tắc đơn giản là:

Mailbox thuộc về team → Shared Mailbox

User đăng nhập bằng tài khoản cá nhân → cấp permission

Muốn gửi như địa chỉ chung → Send As

Muốn cả team thấy email đã trả lời → bật Shared Sent Items

Khi được cấu hình đúng, Shared Mailbox giúp doanh nghiệp vừa duy trì hình ảnh chuyên nghiệp với khách hàng, vừa quản trị account và quyền truy cập rõ ràng hơn.

F-Tech hỗ trợ doanh nghiệp triển khai Exchange Online, Outlook Shared Mailbox, email domain, permission và quy trình quản trị Microsoft 365 phù hợp với Sales, Support và các phòng ban nội bộ.

Liên hệ F-Tech để được tư vấn cấu hình Shared Mailbox phù hợp với workflow của doanh nghiệp.