EzyOA sử dụng hệ thống mẫu để tách nội dung giao tiếp khỏi mã nguồn và tái sử dụng cùng một nghiệp vụ trên nhiều dịch vụ OA. Một mẫu có thể dùng để tạo tin nhắn văn bản, ánh xạ sang template của nhà cung cấp hoặc thông báo cho nhân viên chăm sóc khách hàng.

Các loại mẫu trong EzyOA

Screenshot 2026-09-23 at 08.02.33.png
EzyOA phân biệt hai khái niệm chính:
Loại mẫuVai trò
Mẫu nội dungLưu nội dung do EzyPlatform quản lý, có thể chứa biến động
Mẫu thông báo OALiên kết mẫu nội dung với template đã đăng ký tại nhà cung cấp
Ngoài ra, một dịch vụ OA có thể chọn mẫu riêng để thông báo cho nhân viên khi có tin nhắn mới.
flowchart LR
    Business["Nghiệp vụ cần gửi tin"] --> Content["Mẫu nội dung"]
    Content --> Message["Tin nhắn hội thoại"]
    Content --> Mapping["Ánh xạ template OA"]
    Mapping --> Provider["Template tại nhà cung cấp"]

    Incoming["Tin nhắn từ khách hàng"] --> StaffTemplate["Mẫu thông báo cho nhân viên"]
    StaffTemplate --> Staff["Nhân viên chăm sóc"]
Việc phân tách này cho phép nội dung nghiệp vụ được quản lý tập trung, trong khi mã template và tham số đặc thù vẫn được cấu hình riêng cho từng dịch vụ OA.

Mẫu nội dung

Screenshot 2026-09-23 at 08.02.59.png
Mẫu nội dung là phần định nghĩa nội dung có thể đọc và chỉnh sửa trong hệ thống quản lý content template của EzyPlatform.
Một mẫu thường gồm:
  • Loại mẫu.
  • Tên mẫu.
  • Tiêu đề.
  • Kiểu nội dung.
  • Nội dung mẫu.
  • Các biến sẽ được thay thế khi gửi.
Ví dụ:
Xin chào !
Bạn có thể kiểm tra trạng thái công việc tại:

Khi gửi, EzyOA kết hợp mẫu với dữ liệu thực tế của người nhận:
displayName = Nguyễn Văn A
taskListUrl = https://example.com/tasks/123
Kết quả:
Xin chào Nguyễn Văn A!
Bạn có thể kiểm tra trạng thái công việc tại:
https://example.com/tasks/123

Các nhóm mẫu nội dung

EzyOA đăng ký sẵn hai nhóm mẫu chính.

Mẫu phản hồi OA

Nhóm này dùng để tạo nội dung gửi trực tiếp cho người dùng trên kênh OA.
Các trường hợp mặc định gồm:
  • Phản hồi chung.
  • Chào người dùng mới.
  • Phản hồi người dùng hiện tại.
  • Thông báo nhân viên sẽ trả lời.
  • Thông tin thanh toán.
  • Danh sách công việc.
Nội dung mặc định chỉ là điểm khởi đầu. Quản trị viên có thể điều chỉnh thông qua hệ thống content template để phù hợp với thương hiệu và ngôn ngữ của dự án.

Mẫu thông báo cho nhân viên

Nhóm này dùng để thông báo cho nhân viên chăm sóc khách hàng khi EzyOA nhận được tin nhắn mới.
Nội dung có thể sử dụng các biến như:



Ví dụ kết quả:
Bạn vừa nhận được tin nhắn "Tôi cần hỗ trợ đơn hàng" từ Nguyễn Văn A.
Mỗi dịch vụ OA có thể chọn một mẫu thông báo cho nhân viên khác nhau.

Các biến trong mẫu

Khi dựng nội dung, EzyOA tổng hợp dữ liệu từ nhiều nguồn:
  • Tài khoản người dùng trong EzyPlatform.
  • Hồ sơ người dùng OA.
  • Thông tin khách hàng.
  • Cấu hình website.
  • Thời gian hiện tại.
  • Tham số do nghiệp vụ truyền vào.
Các biến thường dùng có thể gồm:
BiếnNội dung
displayNameTên hiển thị của người dùng
vocativeCách xưng hô
phone hoặc phoneNumberSố điện thoại
emailĐịa chỉ email
websiteUrlĐịa chỉ website
nowThời gian hiện tại
taskListUrlLiên kết danh sách công việc
totalAmountMoneySố tiền cần thanh toán
mediasDanh sách media gửi kèm
Danh sách thực tế phụ thuộc vào module nghiệp vụ và bộ trích xuất tham số đang được cài đặt.
Nếu cùng một biến xuất hiện ở nhiều nguồn, dữ liệu do luồng gửi cung cấp có thể được kết hợp với dữ liệu được trích xuất từ hồ sơ người dùng và khách hàng.

Luồng tạo tin nhắn từ mẫu

Khi một module yêu cầu gửi tin nhắn theo mẫu, EzyOA thực hiện các bước:
sequenceDiagram
    participant B as Module nghiệp vụ
    participant E as EzyOA
    participant T as Kho mẫu nội dung
    participant U as Dữ liệu người dùng
    participant S as Bộ gửi tin
    participant P as Nền tảng OA

    B->>E: Yêu cầu gửi theo loại và tên mẫu
    E->>T: Tìm mẫu nội dung
    T-->>E: Nội dung và kiểu nội dung
    E->>U: Lấy người dùng, hồ sơ OA và khách hàng
    U-->>E: Dữ liệu biến
    E->>E: Kết hợp và thay thế biến
    E->>S: Chuyển nội dung đã dựng
    S->>P: Gửi tới người nhận
Nếu không tìm thấy mẫu nội dung, quá trình gửi dừng và trả lỗi. EzyOA không tự tạo nội dung thay thế.
Người nhận cũng phải có liên kết với người dùng OA của đúng dịch vụ. Nếu không xác định được định danh trên nền tảng, tin nhắn hội thoại không thể gửi.

Bộ gửi theo mẫu

Nội dung sau khi dựng được chuyển cho một bộ gửi phù hợp với:
  • Mã dịch vụ OA.
  • Loại mẫu.
  • Tên mẫu.
EzyOA ưu tiên bộ gửi chuyên biệt cho đúng loại và tên mẫu. Nếu không có, hệ thống có thể sử dụng bộ gửi mặc định của dịch vụ.
flowchart TD
    Request["Yêu cầu gửi theo mẫu"] --> Exact{"Có bộ gửi chuyên biệt?"}
    Exact -- Có --> Specialized["Dùng bộ gửi chuyên biệt"]
    Exact -- Không --> Default{"Có bộ gửi mặc định?"}
    Default -- Có --> Generic["Dùng bộ gửi mặc định"]
    Default -- Không --> Error["Không thể gửi mẫu"]
Cơ chế này cho phép một mẫu đặc biệt, chẳng hạn danh sách công việc, có cách dựng hoặc gửi riêng mà không ảnh hưởng đến các mẫu văn bản thông thường.

Mẫu thông báo của nhà cung cấp

Một số nền tảng không cho phép gửi nội dung tùy ý trong mọi tình huống. Thay vào đó, ứng dụng phải sử dụng một template đã được tạo hoặc phê duyệt trước trên hệ thống của nhà cung cấp.
EzyOA giải quyết vấn đề này bằng một lớp ánh xạ:
Dịch vụ OA
+ Mẫu nội dung nội bộ
= Mã template tại nhà cung cấp
Mỗi ánh xạ gồm:
  • Dịch vụ OA.
  • Mẫu nội dung nội bộ.
  • Mã template của nhà cung cấp.
  • Cấu hình tham số cho template đó.
Cùng một mẫu nội bộ có thể ánh xạ tới các mã template khác nhau trên các dịch vụ OA khác nhau.
flowchart LR
    Internal["Mẫu nội bộ: xác nhận thanh toán"] --> ZaloA["Zalo OA A<br/>Template: 10001"]
    Internal --> ZaloB["Zalo OA B<br/>Template: 20517"]
    Internal --> Other["Dịch vụ khác<br/>Template riêng"]
Điều này đặc biệt hữu ích khi vận hành nhiều thương hiệu hoặc nhiều tài khoản trên cùng một nền tảng.

Cấu hình ánh xạ template

Tại trang chi tiết dịch vụ OA, quản trị viên có thể:
  1. Chọn một mẫu nội dung.
  2. Nhập mã template đã được nhà cung cấp cấp.
  3. Khai báo cách tạo các tham số.
  4. Lưu cấu hình cho dịch vụ hiện tại.
Khi chuyển sang mẫu khác, giao diện tải lại mã template và cấu hình tham số tương ứng. Nếu chưa có cấu hình, hệ thống trả về một cấu hình trống để quản trị viên nhập mới.
Việc lưu yêu cầu dịch vụ OA phải có bộ xử lý hợp lệ. Phần tham số, nếu được nhập, phải là một đối tượng JSON hợp lệ.
Ví dụ:
{
  "date": "now||DateTime||dd/MM/yyyy",
  "name": "displayName",
  "phone_number": "phone",
  "status": "orderStatus"
}
Trong ví dụ này:
  • date được tạo từ thời gian hiện tại và định dạng lại.
  • name lấy từ tên hiển thị.
  • phone_number lấy từ số điện thoại.
  • status lấy từ tham số do nghiệp vụ gửi vào.

Cách dựng tham số thông báo

Cấu hình tham số không nhất thiết chứa giá trị cuối cùng. Mỗi giá trị có thể chỉ ra nguồn dữ liệu cần sử dụng khi gửi.
flowchart TD
    Mapping["Cấu hình tham số template"] --> Runtime["Dữ liệu lúc chạy"]
    User["Thông tin người dùng"] --> Runtime
    Customer["Thông tin khách hàng"] --> Runtime
    Business["Tham số nghiệp vụ"] --> Runtime
    Time["Thời gian hiện tại"] --> Runtime
    Runtime --> Resolve["Giải quyết từng biến"]
    Resolve --> Payload["Payload gửi nhà cung cấp"]
Ví dụ cấu hình:
{
  "customer_name": "displayName",
  "phone": "phone",
  "created_at": "now||DateTime||dd/MM/yyyy HH:mm",
  "amount": "totalAmountMoney"
}
Payload sau khi giải quyết có thể là:
{
  "customer_name": "Nguyễn Văn A",
  "phone": "0900000000",
  "created_at": "23/09/2026 09:30",
  "amount": "1.250.000 VND"
}
Cú pháp định dạng ngày giờ cho phép chuyển một giá trị thời gian thành chuỗi phù hợp với yêu cầu của template.

Luồng gửi thông báo theo mẫu

sequenceDiagram
    participant B as Module nghiệp vụ
    participant E as EzyOA
    participant C as Mẫu nội dung
    participant M as Ánh xạ template OA
    participant U as Dữ liệu người dùng
    participant P as Nhà cung cấp

    B->>E: Gửi theo loại và tên mẫu
    E->>C: Tìm mẫu nội bộ
    C-->>E: Mã mẫu nội bộ
    E->>M: Tìm ánh xạ theo dịch vụ và mã mẫu
    M-->>E: Mã template OA và cấu hình tham số
    E->>U: Lấy dữ liệu người dùng, khách hàng
    U-->>E: Giá trị biến
    E->>E: Dựng payload tham số
    E->>P: Gửi template notification
Nếu nghiệp vụ cung cấp trực tiếp mã template của nhà cung cấp, EzyOA cũng có thể dùng mã đó để tìm cấu hình tương ứng.

Gửi tin nhắn hoặc thông báo dự phòng

Một nghiệp vụ có thể yêu cầu EzyOA gửi tin nhắn hội thoại trước và dùng thông báo theo mẫu làm phương án dự phòng.
flowchart TD
    Start["Yêu cầu gửi theo mẫu"] --> HasUser{"Có người dùng OA?"}
    HasUser -- Có --> Message["Gửi tin nhắn hội thoại"]
    Message --> Sent{"Gửi thành công?"}
    Sent -- Có --> Done["Hoàn tất"]
    Sent -- Không --> Eligible{"Người dùng đủ dữ liệu nhận thông báo?"}
    HasUser -- Không --> Eligible
    Eligible -- Có --> Notification["Gửi thông báo theo template"]
    Eligible -- Không --> Failed["Không thể gửi"]
    Notification --> Done
Kết quả trả về phân biệt rõ:
  • Trạng thái tổng thể.
  • Trạng thái gửi tin nhắn.
  • Trạng thái gửi thông báo.
  • Lỗi của từng phương thức.
Cơ chế dự phòng không bảo đảm thông báo sẽ được gửi thành công. Người dùng vẫn phải có dữ liệu nhận diện phù hợp, chẳng hạn số điện thoại, và template phải hợp lệ trên nhà cung cấp.

Gửi thử thông báo

Trang chi tiết dịch vụ cung cấp công cụ gửi thử với:
  • Định danh người nhận hoặc số điện thoại.
  • Mã template của nhà cung cấp.
  • Bộ tham số JSON.
Ví dụ:
{
  "date": "23/09/2026",
  "name": "Nguyễn Văn A",
  "phone_number": "0900000000",
  "customer_code": "KH001",
  "status": "Đã cập nhật"
}
Khi gửi thử, cả mã người nhận, mã template và tham số đều bắt buộc. Phần tham số phải là một JSON object hợp lệ.
Công cụ này gửi trực tiếp dữ liệu đã nhập. Nó phù hợp để kiểm tra:
  • Token và quyền gửi.
  • Mã template.
  • Tên tham số.
  • Định dạng dữ liệu.
  • Phản hồi lỗi từ nhà cung cấp.
Gửi thử thành công không bảo đảm mọi lần gửi nghiệp vụ sau đó đều thành công, vì kết quả còn phụ thuộc vào người nhận, dữ liệu thực tế và chính sách của nền tảng.

Mẫu thông báo cho nhân viên

Khi cấu hình một dịch vụ OA, quản trị viên có thể chọn mẫu dùng để thông báo cho nhân viên chăm sóc khách hàng.
Luồng tổng quát:
sequenceDiagram
    participant U as Người dùng OA
    participant E as EzyOA
    participant T as Mẫu thông báo
    participant S as Nhân viên

    U->>E: Gửi tin nhắn
    E->>E: Lưu người dùng và hội thoại
    E->>T: Dựng nội dung thông báo
    T-->>E: Nội dung đã thay biến
    E->>S: Gửi thông báo về tin nhắn mới
Mẫu này độc lập với template notification gửi cho khách hàng. Nó phục vụ luồng thông báo nội bộ và có thể được chọn riêng cho từng dịch vụ OA.

Mẫu mặc định

Khi plugin được khởi tạo, EzyOA bổ sung các mẫu mặc định nếu chúng chưa tồn tại. Cơ chế này có hai đặc điểm:
  • Không tạo trùng mẫu đã có.
  • Không ghi đè nội dung đã được quản trị viên chỉnh sửa chỉ vì plugin khởi động lại.
Các mẫu mặc định giúp hệ thống có nội dung ban đầu cho những luồng phổ biến, nhưng nên được rà soát trước khi dùng ở môi trường thật.

Quản lý đa dịch vụ

Mẫu nội dung được quản lý tập trung, còn ánh xạ template được quản lý theo từng dịch vụ OA.
Thành phầnPhạm vi
Nội dung mẫuDùng chung trong hệ thống
Mã template nhà cung cấpRiêng theo dịch vụ OA
Cấu hình tham số notificationRiêng theo dịch vụ OA và mẫu
Bộ gửi chuyên biệtTheo loại dịch vụ và mẫu
Mẫu thông báo nhân viênĐược chọn riêng cho từng dịch vụ
Thiết kế này tránh phải sao chép toàn bộ nội dung khi có nhiều OA, đồng thời vẫn cho phép mỗi tài khoản sử dụng mã template riêng.

Phân quyền và bảo mật

Các thao tác xem hoặc cập nhật ánh xạ template trong module quản trị yêu cầu:
  • Quản trị viên đã đăng nhập.
  • Có quyền quản lý OA.
Khi cấu hình mẫu, không nên đặt các thông tin sau trực tiếp trong nội dung hoặc JSON tham số:
  • Access token.
  • App secret.
  • Webhook secret.
  • Mật khẩu.
  • Dữ liệu nhạy cảm không cần thiết của khách hàng.
Nội dung mẫu và tham số có thể xuất hiện trong request gửi tới nhà cung cấp hoặc log lỗi. Chỉ nên đưa vào những dữ liệu thực sự cần cho thông báo.

Giới hạn cần lưu ý

  • EzyOA không tự tạo template trên hệ thống của nhà cung cấp.
  • EzyOA không tự gửi template đi duyệt.
  • Mã template phải được lấy từ đúng tài khoản OA hoặc ứng dụng.
  • Tên tham số phải khớp với định nghĩa của nhà cung cấp.
  • JSON hợp lệ về cú pháp chưa chắc hợp lệ về nghiệp vụ.
  • Không phải dịch vụ nào cũng hỗ trợ notification template.
  • Không phải bộ gửi nào cũng hỗ trợ mọi kiểu nội dung hoặc media.
  • Xóa hoặc thay đổi mẫu nội bộ có thể làm các ánh xạ hiện tại không còn sử dụng được.
  • Việc sửa nội dung không tự động cập nhật template đã được phê duyệt tại nhà cung cấp.
  • Hệ thống không cung cấp cơ chế versioning hoặc rollback riêng cho ánh xạ template OA.

Khuyến nghị vận hành

Để quản lý mẫu ổn định:
  • Đặt tên mẫu theo mục đích nghiệp vụ, không theo một chiến dịch ngắn hạn.
  • Dùng cùng một mẫu nội bộ cho cùng một loại sự kiện.
  • Tạo ánh xạ riêng cho từng dịch vụ OA.
  • Kiểm tra JSON tham số bằng dữ liệu mẫu trước khi đưa vào sử dụng.
  • Gửi thử tới tài khoản kiểm thử sau mỗi lần đổi cấu hình.
  • Không đổi hoặc xóa biến đang được module nghiệp vụ sử dụng.
  • Theo dõi phản hồi lỗi của nhà cung cấp sau khi template được cập nhật.
  • Lưu tài liệu về ý nghĩa và nguồn dữ liệu của từng tham số.

Kết luận

Tính năng quản lý mẫu của EzyOA tạo ra ba lớp rõ ràng: nội dung nghiệp vụ, ánh xạ với template của nhà cung cấp và bộ gửi dành cho từng nền tảng.
Nhờ cách tổ chức này, một nội dung có thể được tái sử dụng trên nhiều dịch vụ OA, trong khi mỗi OA vẫn giữ mã template và cấu hình tham số riêng. Điều đó giúp việc thay đổi nội dung, mở rộng kênh và vận hành nhiều tài khoản trở nên nhất quán hơn.