ONMATE / TÍCH HỢP HỆ THỐNG

Tích hợp hệ thống

Kết nối website với dữ liệu và công cụ doanh nghiệp đang dùng.

ONMATE tích hợp biểu mẫu, CRM, thanh toán hoặc phần mềm vận hành theo nhu cầu. Luồng dữ liệu được kiểm thử về phân quyền, bản ghi trùng và xử lý lỗi để đội ngũ giảm nhập liệu thủ công và dễ theo dõi.

Xem phạm vi dịch vụ Trao đổi nhu cầu

Thiết kế biểu mẫu

nhathom.example/wp-admin/admin.php?page=bieu-mau&id=2

WBảng điều khiểnNhà Thơm (mẫu)N

Bảng tinTrangĐơn hàngBiểu mẫuGiao diệnPluginCông cụCài đặtKết nối

Biểu mẫu: Nhận tư vấn quà tặng

Đang bật · 64 lượt gửi trong tuần

TrườngSau khi gửiChống thư rác

Nhãn	Loại	Bắt buộc	Quy tắc kiểm tra
Họ và tên	Văn bản	Có	Từ 2 ký tự
Số điện thoại	Số điện thoại	Có	10 chữ số, bắt đầu bằng 0
Email	Email	Không	Đúng dạng tên@miền
Nhu cầu	Danh sách chọn	Có	4 lựa chọn có sẵn
Ghi chú	Đoạn văn	Không	Tối đa 500 ký tự
Đồng ý liên hệ	Hộp chọn	Có	Phải chọn mới gửi được
Nguồn khách	Ô ẩn	Tự điền	Lấy từ địa chỉ trang (utm)

Ô bẫy chống thư rác đang bật. Form chỉ gửi khi mọi quy tắc trên đạt, và máy chủ kiểm tra lại một lần nữa.

DebugView của GA4

analytics.google.com/analytics/web/#/a1/admin/debugview

AnalyticsNhà Thơm (mẫu) – GA4N

Trang chủBáo cáoKhám pháQuảng cáoQuản trịDebugView

DebugView

Thiết bị: Pixel 7 (gỡ lỗi) ▾

09:12:33generate_lead
09:12:31form_submit
09:11:58form_start
09:11:42scroll
09:11:36page_view
09:11:36session_start

generate_lead09:12:33

form_id: tu-van-qua-tang
lead_source: google / cpc
page_location: https://nhathom.example/qua-tan-gia
ga_session_id: 1791339096
debug_mode: 1

Ghi chú đơn hàng

nhathom.example/wp-admin/post.php?post=3201&action=edit

WBảng điều khiểnNhà Thơm (mẫu)N

Bảng tinTrangĐơn hàngBiểu mẫuGiao diệnPluginCông cụCài đặtKết nối

Đơn hàng #3201

Đang xử lý · 05/10/2026

Sản phẩm

Nến gỗ đàn hương 180 g × 2640.000 ₫
Hộp quà 3 nến × 1590.000 ₫
Phí giao hàng50.000 ₫
Tổng cộng1.280.000 ₫

Thanh toán

Đã thanh toánCổng thanh toán (mẫu) · mã giao dịch pay_7Kq2

Ghi chú đơn hàng

21:41Đã gửi đơn sang phần mềm bán hàng (mẫu).
21:40Nhận lại thông báo cùng mã evt_7Kq2: đã xử lý trước đó, bỏ qua.
21:40Nhận thông báo payment.succeeded. Chữ ký đúng, số tiền 1.280.000 ₫ khớp đơn. Chờ thanh toán → Đang xử lý.
21:38Khách chuyển sang cổng thanh toán.

Bảng theo dõi kết nối

giamsat.nhathom.example/tong-quan

GGiám sát kết nốiNhà Thơm (mẫu)N

Tổng quanKết nốiCảnh báoNhật kýCài đặt

Tổng quan 7 ngày

29/09–05/10/2026

Kết nối theo dõi5Cảnh báo trong tuần1Cần xử lý tay0

Biểu mẫu → CRMKhách gửi form643 thử lạiTốt
Website → Google AnalyticsSự kiện generate_lead59ít hơn CRM 5Trong ngưỡng
Cổng thanh toán → WebsiteThông báo giao dịch291 trùng, bỏ quaTốt
Website → Phần mềm bán hàngĐơn hàng312 gửi lạiSự cố 02/10
Phần mềm bán hàng → WebsiteTồn kho, mỗi 15 phút6720 lỗiTốt

HÀNH TRÌNH TRÊN TÍCH HỢP HỆ THỐNG

Tích hợp tốt là dữ liệu đi đúng nơi một lần, và có người biết lỗi trước khách.

Một đợt tích hợp đi qua nhiều chặng, từ biểu mẫu đến giám sát. Chọn một chặng để xem việc ở đó.

CHẶNG 01

Biểu mẫu

Form chỉ hỏi điều cần để gọi lại, báo lỗi ngay tại ô sai, và chỉ nhận một lần dù khách bấm hai lần.

Sáu chặng quay quanh một điểm. Chọn một chặng để đọc chi tiết.

TÍCH HỢP HỆ THỐNG

SÁU PHẦN VIỆC

Chọn một phần việc để xem
toàn bộ cách làm.

Mỗi phần việc có màn hình làm việc, đầu vào và cách đo riêng.

Chạm vào một thẻ để đổi nội dung bên dưới.

Đang xemForm ngắn, báo lỗi rõ

Nội dung của thẻ Form ngắn, báo lỗi rõChọn thẻ khác

TRÔNG NHƯ THẾ NÀO

Biểu mẫu trông như thế nào.

Ba màn hình: cấu hình trong WordPress, form lúc nhập và gửi xong, yêu cầu trong DevTools.

Trường và quy tắc trong WordPress

Bảy trường: họ tên, số điện thoại, email, nhu cầu, ghi chú, đồng ý liên hệ, nguồn khách. Mỗi trường có loại ô và quy tắc riêng.

Đọc tiếp

Số điện thoại đủ 10 chữ số, bắt đầu bằng 0; ô đồng ý phải chọn mới gửi được; nguồn khách là ô ẩn tự điền.

MÔ PHỎNG · SỐ MẪU

nhathom.example/wp-admin/admin.php?page=bieu-mau&id=2

WBảng điều khiểnNhà Thơm (mẫu)N

Bảng tinTrangĐơn hàngBiểu mẫuGiao diệnPluginCông cụCài đặtKết nối

Biểu mẫu: Nhận tư vấn quà tặng

Đang bật · 64 lượt gửi trong tuần

TrườngSau khi gửiChống thư rác

Nhãn	Loại	Bắt buộc	Quy tắc kiểm tra
Họ và tên	Văn bản	Có	Từ 2 ký tự
Số điện thoại	Số điện thoại	Có	10 chữ số, bắt đầu bằng 0
Email	Email	Không	Đúng dạng tên@miền
Nhu cầu	Danh sách chọn	Có	4 lựa chọn có sẵn
Ghi chú	Đoạn văn	Không	Tối đa 500 ký tự
Đồng ý liên hệ	Hộp chọn	Có	Phải chọn mới gửi được
Nguồn khách	Ô ẩn	Tự điền	Lấy từ địa chỉ trang (utm)

Ô bẫy chống thư rác đang bật. Form chỉ gửi khi mọi quy tắc trên đạt, và máy chủ kiểm tra lại một lần nữa.

Số điện thoại: bắt buộc, 10 chữ số, bắt đầu bằng 0. Chặn số gõ thiếu hoặc nhầm ngay lúc nhập.
Đồng ý liên hệ: khách phải chọn mới gửi được. Là bằng chứng khách cho phép gọi lại.
Nguồn khách là ô ẩn, tự điền từ địa chỉ trang (utm). Mỗi khách vào CRM đều biết đến từ đâu.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Tài liệu tham khảo:web.dev: kiểm tra dữ liệu biểu mẫu ↗W3C WCAG 2.2: nhận biết lỗi nhập liệu ↗MDN: mã trạng thái HTTP ↗

LÀM NHƯ THẾ NÀO

Năm bước làm biểu mẫu.

Hỏi ít, kiểm tra kỹ, báo lỗi rõ; thử làm sai trước khi bật.

01Chốt trường tối thiểu: tên, số điện thoại, nhu cầu. Mỗi ô thêm làm khách dễ bỏ dở.
02Viết quy tắc, câu báo lỗi rõ cho từng trường; số điện thoại dùng ô loại tel.
03Thêm ô đồng ý ghi rõ mục đích, ô ẩn lấy utm, và mã submission_id riêng mỗi lần.
04Kiểm tra lại ở máy chủ, chặn thư rác bằng ô bẫy, chỉ báo xong khi nhận 201.
05Thử 8 tình huống, từ gửi đúng đến tắt mạng; ghi bảng thử rồi mới bật cho khách.

Bạn đưa vào

Các trường cần hỏi và thứ tự
Người nhận yêu cầu và giờ làm việc
Nội dung đồng ý liên hệ
Trang đặt form

Kiểm tra hai lớp, đồng ý rõ ràng, mã lần gửiONMATE cùng doanh nghiệp

Bạn nhận lại

Form chạy trên website, bảng thiết kế trường, bảng thử 8 tình huống, địa chỉ nhận dữ liệu.

Tài liệu tham khảo:web.dev: kiểm tra dữ liệu biểu mẫu ↗MDN: ô nhập số điện thoại (type=tel) ↗MDN: thuộc tính inputmode ↗MDN: thuộc tính autocomplete ↗

CẦN CHUẨN BỊ GÌ

Cần chuẩn bị gì để làm biểu mẫu.

Cần câu khách hay hỏi, người nhận yêu cầu, câu đồng ý đang dùng.

NGUYÊN TẮC

Bảng thiết kế trường: mỗi trường một dòng, ghi loại ô, bắt buộc hay không, quy tắc kiểm tra và trường CRM tương ứng.

BẢNG THIẾT KẾ FORM · SỐ MẪU

docs.google.com/spreadsheets

nhathom-thiet-ke-bieu-mauTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu

	A	B	C	D	E
1	Trường	Loại	Bắt buộc	Quy tắc kiểm tra	Trường trong CRM
2	name	Văn bản	Có	Từ 2 ký tự	Họ và tên
3	phone	Số điện thoại	Có	10 chữ số, bắt đầu bằng 0	Điện thoại (khóa chống trùng)
4	email	Email	Không	Đúng dạng tên@miền	Email
5	need	Danh sách chọn	Có	4 lựa chọn có sẵn	Nhu cầu
6	note	Đoạn văn	Không	Tối đa 500 ký tự	Ghi chú
7	consent	Hộp chọn	Có	Phải chọn mới gửi được	Đồng ý liên hệ
8	utm_source, utm_medium	Ô ẩn	Tự điền	Lấy từ địa chỉ trang	Nguồn khách

Biểu mẫu tư vấnBiểu mẫu liên hệ

Số điện thoại: 10 chữ số, bắt đầu bằng 0. Cũng là khóa chống trùng trong CRM, quan trọng nhất bảng.
Đồng ý liên hệ bắt buộc, không đặt sẵn là đã chọn. Khách tự chọn thì đồng ý mới có giá trị.
Mỗi trường trên form có một trường tương ứng trong CRM. Ghi đủ cột này để ghép không sót.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Số điện thoại kiểm tra chặt

10 chữ số, đầu 0

Đồng ý liên hệ do khách chọn

Không đặt sẵn là đã chọn

Lấy nguồn từ địa chỉ trang

Ô ẩn, khách khỏi nhập

Máy chủ kiểm tra lại

Không tin riêng trình duyệt

Bộ tài nguyên4 mục

KháchNhững câu khách hay hỏi3 đến 5 yêu cầu thật gần đây.
TệpCâu đồng ý đang dùngĐể viết lại cho đúng, dễ đọc.
ẢnhẢnh chụp form hiện tạiKèm lỗi khách từng gặp (nếu có).
BảngNgười nhận và giờ làm việcAi nhận yêu cầu, gọi lại khi nào.

Xem đủ thông số và ghi chú

Nguồn: Kiểm tra dữ liệu biểu mẫu web.dev hướng dẫn kiểm tra ngay trên trình duyệt bằng thuộc tính của HTML (required, pattern, type) và cho người dùng thấy lỗi ở đâu, sửa thế nào.
Nguồn: Báo lỗi phải chỉ ra ô sai bằng chữ WCAG 2.2 yêu cầu khi hệ thống phát hiện lỗi nhập liệu thì ô sai được xác định và lỗi được mô tả bằng chữ cho người dùng, không chỉ bằng màu.
Lưu ý: Kiểm tra ở trình duyệt chưa đủ Dữ liệu có thể đến máy chủ mà không qua trình duyệt, nên máy chủ phải kiểm tra lại mọi trường (OWASP). Kiểm tra ở trình duyệt chỉ để khách sửa nhanh hơn.

Tài liệu tham khảo:web.dev: kiểm tra dữ liệu biểu mẫu ↗W3C WAI: kiểm tra dữ liệu biểu mẫu ↗W3C WCAG 2.2: nhận biết lỗi nhập liệu ↗OWASP: kiểm tra dữ liệu đầu vào ↗

ĐO ĐIỀU GÌ

Đo bằng bảng thử 8 tình huống.

Trước khi bật, thử 8 tình huống bằng tay, ghi vào bảng. Sửa form thì thử lại.

CẦN ĐO

Ca “Không chọn đồng ý” lần đầu vẫn gửi đi; điền đúng thì không lộ.

BẢNG THỬ FORM · SỐ MẪU

docs.google.com/spreadsheets

nhathom-thu-bieu-mauTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu

	A	B	C	D	E
1	#	Cách thử	Mong đợi	Kết quả thật	Tình trạng
2	1	Gửi đủ thông tin đúng	Báo đã nhận; khách vào CRM trong 1 phút	Đúng như mong đợi	Đạt
3	2	Bỏ trống số điện thoại	Báo lỗi tại ô, không gửi	Đúng như mong đợi	Đạt
4	3	Nhập số điện thoại 9 chữ số	Báo lỗi tại ô, không gửi	Đúng như mong đợi	Đạt
5	4	Không chọn đồng ý liên hệ	Không gửi được	Form vẫn gửi đi	Đã sửa 06/10
6	5	Bấm Gửi hai lần liên tiếp	Chỉ có 1 khách trong CRM	Đúng như mong đợi	Đạt
7	6	Gửi lại cùng số điện thoại	Gộp vào khách cũ	Đúng như mong đợi	Đạt
8	7	Tắt mạng rồi bấm Gửi	Báo chưa gửi được, giữ chữ đã nhập	Đúng như mong đợi	Đạt
9	8	Mở bằng điện thoại Android	Hiện bàn phím số ở ô số điện thoại	Đúng như mong đợi	Đạt

Lần thử 06/10Lần thử 21/09

Ca 4 phát hiện lỗi thật: form vẫn gửi khi khách không chọn đồng ý liên hệ.
Ghi “Đã sửa 06/10” rồi thử lại, giữ nguyên dòng để lần sửa form sau biết ca cần thử lại.
Ca 5: bấm Gửi hai lần liên tiếp vẫn chỉ ra một khách, nhờ mã submission_id của lần gửi.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Cách đọc số · số mẫu

Chỉ số	Cho biết	Cần xem lại khi
Ca gửi đúng	Báo đã nhận, khách vào CRM trong 1 phút	Chỉ thấy thông báo mà không mở CRM
Ca làm sai (bỏ trống, thiếu số)	Báo lỗi tại ô và không gửi	Gửi đi rồi mới báo lỗi
Ca bấm Gửi hai lần	Chỉ một khách trong CRM	Hai khách trùng nhau
Ca tắt mạng	Giữ chữ đã nhập, báo chưa gửi được	Mất hết chữ đã nhập

CÁCH ĐỌC

Đọc ba cột: cách thử, mong đợi, kết quả thật.

Đọc tiếp

Dòng nào lệch thì sửa, ghi “Đã sửa” kèm ngày. Cả 8 ca đạt mới bật.

LƯU Ý

Thử cả điện thoại và máy tính: bàn phím và cách báo lỗi khác nhau.

Đọc tiếp

Số trong hình là số mẫu.

Tài liệu tham khảo:web.dev: kiểm tra dữ liệu biểu mẫu ↗W3C WAI: kiểm tra dữ liệu biểu mẫu ↗OWASP: kiểm tra dữ liệu đầu vào ↗

CÁCH TRIỂN KHAI

Cách xử lý các tình huống thường gặp.

Số trong bảng là số mẫu để minh họa cách đọc, không phải kết quả dự kiến.

Form chỉ gửi email vào hộp thư chung

Giữ email làm bản sao, nhưng gửi thẳng dữ liệu vào CRM để không ai phải chép tay.

Lập bảng thiết kế trường từ email đang nhận
Thêm quy tắc kiểm tra và ô đồng ý liên hệ
Gửi thẳng vào CRM, giữ email làm bản sao
Tắt email sau một tuần số khách khớp nhau

Hay nhận số điện thoại sai hoặc thiếu

Chặt quy tắc ở ô số điện thoại và báo lỗi ngay tại ô.

Đặt quy tắc 10 chữ số, bắt đầu bằng 0
Dùng ô type tel với inputmode phù hợp
Viết câu báo lỗi có ví dụ
Thử bằng số thiếu, thừa, có khoảng trắng

Khách bấm Gửi nhiều lần nên bị trùng

Thêm mã lần gửi và vô hiệu nút Gửi trong lúc chờ.

Tạo submission_id cho mỗi lần mở form
Vô hiệu nút Gửi sau khi bấm
CRM bỏ qua mã đã nhận
Thử bấm Gửi hai lần liên tiếp

DẤU HIỆU

Form báo thành công nhưng CRM không có khách

Chỉ số	Giá trị
Thông báo trên trang	Đã nhận yêu cầu
Mã trả về trong tab Mạng	500, máy chủ lỗi
Việc cần làm	Sửa lỗi máy chủ và chỉ báo thành công khi nhận 201

KIỂM TRA

Thông báo trên trang chưa có nghĩa máy chủ đã nhận.

Đọc tiếp

Mở tab Mạng và xem yêu cầu gửi đi có trả 201 không.

DẤU HIỆU

Khách nhập số đúng nhưng form báo sai

Chỉ số	Giá trị
Khách nhập	0900 000 000 (số mẫu)
Quy tắc hiện tại	Chỉ nhận 10 chữ số liền
Việc cần làm	Bỏ khoảng trắng và dấu chấm trước khi kiểm tra

KIỂM TRA

Quy tắc kiểm tra quá chặt, ví dụ không nhận số có khoảng trắng hoặc dấu chấm.

DẤU HIỆU

Số lượt gửi ít hơn hẳn số khách nhắn tin hỏi

Chỉ số	Giá trị
Lượt gửi form trong tuần	12
Khách nhắn tin hỏi trong tuần	40
Việc cần làm	Thử form trên điện thoại Android và iPhone

KIỂM TRA

Form có thể lỗi ở một loại điện thoại hoặc trình duyệt mà người làm không dùng.

Tài liệu tham khảo:MDN: ô nhập số điện thoại (type=tel) ↗MDN: thuộc tính inputmode ↗OWASP: kiểm tra dữ liệu đầu vào ↗

TRƯỚC KHI BẮT ĐẦU

Danh sách kiểm tra.

Đánh dấu từng mục để xem mức sẵn sàng. Trạng thái chỉ lưu trên trình duyệt của bạn.

0%SẴN SÀNG

Chỉ hỏi những trường cần để gọi lại, mỗi trường có lý doSố điện thoại bắt buộc, kiểm tra 10 chữ số và dùng ô type telBáo lỗi bằng chữ ngay tại ô sai, giữ nguyên các ô đã nhậpĐồng ý liên hệ do khách tự chọn và nêu rõ mục đíchCó ô ẩn lấy utm và mã lần gửi duy nhấtMáy chủ kiểm tra lại mọi trường và chỉ trả 201 khi đã nhậnCó ô bẫy chống thư rác và nút Gửi không bấm được hai lầnĐã thử đủ 8 tình huống và ghi vào bảng thử

Tài liệu tham khảo:W3C WCAG 2.2: nhận biết lỗi nhập liệu ↗OWASP: kiểm tra dữ liệu đầu vào ↗OWASP: quản lý khóa và bí mật ↗

Nội dung của thẻ Khách vào CRM đúng ngườiChọn thẻ khác

TRÔNG NHƯ THẾ NÀO

Kết nối CRM trông như thế nào.

Ba màn hình trong CRM: bảng ghép trường, quy tắc chống trùng, quy tắc chia khách.

Mỗi trường của form đi vào đâu

Mười trường ghép sang CRM kèm cách chuẩn hóa: số điện thoại dạng +84…, email viết thường. Đã ghép 9 trên 10 trường.

Đọc tiếp

Dòng vàng là trường page chưa ghép: dữ liệu chưa có chỗ đi sẽ bị bỏ rơi lặng lẽ. Hãy ghép vào “Trang gửi”.

MÔ PHỎNG · SỐ MẪU

crm.nhathom.example/cai-dat/ket-noi/website

NKhách hàngNhà Thơm (mẫu)N

Khách mớiViệc cần làmBáo cáoCài đặt

Kết nối với website

nhathom.example · biểu mẫu “Nhận tư vấn quà tặng”

Ánh xạ trườngChống trùngChia khách

Đang bậtĐã ghép 9/10 trườngGửi thử 1 khách

Trường trên website		Trường trong CRM	Chuẩn hóa
`name`	→	Họ và tên	Bỏ khoảng trắng thừa
`phone`	→	Điện thoại (khóa chống trùng)	Đổi 0900… thành +84900…
`email`	→	Email	Viết thường
`need`	→	Nhu cầu	qua-tan-gia → Quà tân gia
`note`	→	Ghi chú	Giữ nguyên
`utm_source, utm_medium`	→	Nguồn khách	Ghép thành “google / cpc”
`utm_campaign`	→	Chiến dịch	Giữ nguyên
`consent`	→	Đồng ý liên hệ	Phải là true
`submission_id`	→	Mã lần gửi	Duy nhất, để không tạo trùng
`page`	→	Chưa ghép	Bỏ qua hoặc ghép vào “Trang gửi”

Số điện thoại là khóa chống trùng: đổi 0900… thành +84900… để một số luôn có một cách viết.
Nguồn khách ghép từ utm_source và utm_medium thành “google / cpc”, trùng cách viết với Google Analytics.
Còn 1 trường chưa ghép (page). Dòng vàng nhắc: ghép vào “Trang gửi” hoặc ghi rõ bỏ qua có chủ ý.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Khách gửi lại: thêm lần liên hệ

Có khách cũ cùng số điện thoại trong 90 ngày không? Tuần 29/09–05/10: 64 lượt gửi, 58 khách mới, 6 lượt gộp.

Đọc tiếp

Lượt gộp không tạo khách mới mà ghi thêm lần liên hệ, báo người phụ trách cũ. Gửi lần hai, ba thường là khách nghiêm túc.

MÔ PHỎNG · SỐ MẪU

crm.nhathom.example/cai-dat/ket-noi/chong-trung

NKhách hàngNhà Thơm (mẫu)N

Khách mớiViệc cần làmBáo cáoCài đặt

Chống trùng khách

Tuần 29/09–05/10/2026

Ánh xạ trườngChống trùngChia khách

Khách gửi form→Có khách cũ cùng số điện thoại trong 90 ngày?

CóKhông tạo khách mới. Ghi thêm một lần liên hệ và báo người phụ trách cũ.

KhôngTạo khách mới và chia người phụ trách.

Tuần 29/09–05/10

Form gửi vào64Tạo khách mới58Gộp vào khách cũ6

Các lần gộp trong tuần

Ngày	Khách	Khách cũ	Phụ trách	Liên hệ
05/10	Trần Thu Hà	Khách từ 21/09	Hà Trang	Lần 2
04/10	Phạm Mai	Khách từ 12/08	Minh Khoa	Lần 3
03/10	Lê Quốc Bảo	Khách từ 30/09	Hà Trang	Lần 2
02/10	Đỗ Thanh	Khách từ 17/09	Hà Trang	Lần 2
01/10	Vũ Minh Châu	Khách từ 25/09	Hà Trang	Lần 2
30/09	Ngô Bích	Khách từ 03/09	Hà Trang	Lần 2

Có khách cũ cùng số điện thoại trong 90 ngày không? Có thì ghi thêm lần liên hệ, không tạo khách mới.
Tuần này 64 lượt gửi: 58 khách mới + 6 lượt gộp = 64, không lượt nào bị mất.
Phạm Mai gửi lần thứ 3 vẫn do Minh Khoa phụ trách, khách khỏi bị hai nhân viên gọi cùng lúc.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Tài liệu tham khảo:OWASP: API Security Top 10 ↗MDN: mã trạng thái HTTP ↗

LÀM NHƯ THẾ NÀO

Năm bước nối CRM.

Ghép đúng trường trước, rồi chống trùng, chia khách; thử một khách rồi bật.

01Ghép từng cặp trường form với CRM; chưa có chỗ thì tạo thêm hoặc ghi rõ bỏ qua.
02Chuẩn hóa trước khi lưu: số điện thoại một dạng, email viết thường, nguồn khách ghép từ utm.
03Chống trùng theo số điện thoại trong 90 ngày: khách cũ thì ghi thêm lần liên hệ.
04Chia khách: trong giờ chia ngay, ngoài giờ vào hàng chờ, khách gửi lại giữ người cũ.
05Gửi thử một khách, kiểm tra đủ trường, đúng người rồi bật; mỗi tuần đếm lại.

Bạn đưa vào

Địa chỉ nhận dữ liệu của CRM
Khóa API của CRM, cấp riêng cho website
Người nhận khách và giờ làm việc
Các trường đang dùng trong CRM

Ghép trường, chống trùng, chia kháchONMATE cùng doanh nghiệp

Bạn nhận lại

Kết nối form với CRM, bảng ghép trường, quy tắc chống trùng và chia khách, bảng kiểm tra tuần.

Tài liệu tham khảo:OWASP: API Security Top 10 ↗MDN: mã trạng thái HTTP ↗OWASP: phân quyền ↗

CẦN CHUẨN BỊ GÌ

Cần chuẩn bị gì để nối CRM.

Cần quyền tạo khóa API, người nhận khách, các trường CRM đang dùng.

NGUYÊN TẮC

Bảng quy tắc chia khách: mỗi tình huống một dòng, ghi điều kiện, việc làm, người nhận. Khách gửi lại giữ người cũ.

BẢNG QUY TẮC · SỐ MẪU

docs.google.com/spreadsheets

nhathom-quy-tac-chia-khachTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu

	A	B	C	D
1	Tình huống	Điều kiện	Việc làm	Người nhận
2	Khách mới, trong giờ	Thứ Hai đến thứ Bảy, 8:30 đến 17:30	Chia ngay	Xoay vòng Hà Trang, Minh Khoa
3	Khách mới, ngoài giờ	Ngoài khung giờ trên	Vào hàng chờ, chia lúc 8:30	Xoay vòng Hà Trang, Minh Khoa
4	Khách gửi lại	Cùng số điện thoại trong 90 ngày	Ghi thêm lần liên hệ, báo người cũ	Người phụ trách cũ
5	Số điện thoại sai dạng	CRM trả lỗi 422	Ghi nhật ký, báo email cho quản trị	Quản trị website
6	Người phụ trách nghỉ	Được đánh dấu nghỉ trong CRM	Chuyển khách sang người còn lại	Người còn lại

Quy tắcNgười phụ trách

Khách ngoài giờ vào hàng chờ, chia lúc 8:30 ngày làm việc kế tiếp để người nhận gọi trong giờ.
Chống trùng theo số điện thoại trong 90 ngày. Quá mốc này coi là khách mới quay lại.
Có sẵn quy tắc cho người nghỉ phép, để khách không nằm im ở người không đi làm.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Chuẩn hóa số điện thoại

Một dạng trước khi so

Chống trùng theo số

Khách cũ: thêm lần liên hệ

Ngoài giờ vào hàng chờ

Chia khi vào giờ làm

Khóa API riêng cho website

Chỉ có quyền tạo khách

Bộ tài nguyên4 mục

KháchNgười nhận kháchTên, giờ làm, người thay khi nghỉ.
TệpDanh sách khách hiện cóTệp xuất từ CRM hoặc bảng tính.
ẢnhẢnh chụp trường trong CRMDanh sách trường, để ghép đúng kiểu.
BảngQuyền tạo khóa APITài khoản tạo khóa, quyền tối thiểu.

Xem đủ thông số và ghi chú

Nguồn: Giữ quyền của khóa ở mức tối thiểu OWASP API Security nêu các rủi ro như xác thực yếu và phân quyền sai; khóa của website chỉ nên được tạo khách, không có quyền xóa hay xuất toàn bộ danh sách.
Nguồn: Mã trạng thái cho biết kết quả MDN mô tả 201 là đã tạo, 4xx là lỗi từ phía yêu cầu (401 chưa xác thực, 422 dữ liệu không xử lý được), 5xx là lỗi phía máy chủ; mỗi nhóm cần cách xử lý khác nhau.
Lưu ý: Xoay vòng chỉ công bằng khi cùng giờ làm Nếu một người chỉ làm nửa ngày thì ghi rõ trong quy tắc, nếu không khách gửi buổi chiều sẽ dồn vào người không có mặt.

Tài liệu tham khảo:OWASP: API Security Top 10 ↗MDN: mã trạng thái HTTP ↗OWASP: quản lý khóa và bí mật ↗

ĐO ĐIỀU GÌ

Đo bằng bảng kiểm tra hằng tuần.

Mỗi tuần đếm: lượt gửi form, khách trong CRM (cả lượt gộp), khách chưa có người phụ trách.

CẦN ĐO

Hai số đầu phải bằng nhau (64 và 64). Lệch là có khách rơi mất.

BẢNG KIỂM TRA · SỐ MẪU

docs.google.com/spreadsheets

nhathom-kiem-tra-crm-hang-tuanTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu

	A	B	C	D
1	Chỉ số	Số liệu	Cách đếm	Kết luận
2	Lượt gửi form	64	Trong biểu mẫu WordPress
3	Khách trong CRM	64	58 khách mới + 6 gộp vào khách cũ	Khớp
4	Chưa có người phụ trách	0	Lọc trong CRM	Tốt
5	Khách có nguồn là “không rõ”	5	Lọc theo cột Nguồn khách	Cần xem
6	Gọi lần đầu (trung vị)	18 phút	Từ lúc vào CRM đến cuộc gọi đầu	Đạt, dưới 30 phút

Tuần 29/09–05/10Tuần 22/09–28/09

Hai số đầu phải bằng nhau: 64 lượt gửi và 64 khách trong CRM. Lệch nhau là có khách rơi mất.
5 khách có nguồn “không rõ”: nhiều khả năng vào không gắn utm. Xem để biết link nào cần gắn utm.
Gọi lần đầu 18 phút, mục tiêu dưới 30 phút: cho thấy chia khách có giúp gọi nhanh hơn không.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Cách đọc số · số mẫu

Chỉ số	Cho biết	Cần xem lại khi
Lượt gửi so với khách trong CRM	Bằng nhau (đã tính cả lượt gộp)	Lệch mà không biết lý do
Khách chưa có người phụ trách	0	Còn khách chờ chia
Khách có nguồn “không rõ”	Ít, và biết link nào thiếu utm	Không ai kiểm tra
Gọi lần đầu (trung vị)	Dưới mục tiêu, ví dụ 30 phút	Không có số

CÁCH ĐỌC

Đọc từ trên xuống: đúng khi hai dòng đầu bằng nhau và dòng chưa có người phụ trách bằng 0.

Đọc tiếp

Hai dòng cuối theo dõi chất lượng.

LƯU Ý

Dùng trung vị, không dùng trung bình: khách gửi ngoài giờ làm lệch số.

Đọc tiếp

Số trong hình là số mẫu.

Tài liệu tham khảo:OWASP: ghi nhật ký ↗MDN: mã trạng thái HTTP ↗

CÁCH TRIỂN KHAI

Cách xử lý các tình huống thường gặp.

Số trong bảng là số mẫu để minh họa cách đọc, không phải kết quả dự kiến.

Đang chép khách từ email sang bảng tính

Chuyển sang gửi thẳng từ form vào CRM, giữ bảng tính chạy song song một tuần để đối chiếu.

Ghép trường của form với CRM
Gửi thử 3 khách bằng form
So khách trong CRM với email nhận được
Ngừng chép tay sau khi đối chiếu khớp

Một khách xuất hiện nhiều lần

Bật chống trùng theo số điện thoại đã chuẩn hóa và gộp các bản ghi trùng cũ.

Chuẩn hóa số điện thoại về một dạng
Bật chống trùng 90 ngày
Gộp các bản trùng cũ bằng công cụ của CRM
Tuần sau xem số lượt gộp có xuất hiện không

Khách gửi ngoài giờ mà sáng không ai gọi

Dùng hàng chờ ngoài giờ để khách được chia đúng lúc bắt đầu làm việc.

Ghi giờ làm việc vào quy tắc
Cho khách ngoài giờ vào hàng chờ
Chia lúc 8:30 sáng ngày làm việc kế tiếp
Theo dõi thời gian gọi lần đầu

DẤU HIỆU

Khách mới nhưng thiếu người phụ trách

Chỉ số	Giá trị
Khách mới tuần này	64
Chưa có người phụ trách	3
Việc cần làm	Thêm quy tắc chuyển sang người còn lại khi có người nghỉ

KIỂM TRA

Quy tắc chia khách không có nhánh cho tình huống này, thường là khách vào đúng lúc người nhận được đánh dấu nghỉ.

DẤU HIỆU

CRM từ chối khách với mã 422

Chỉ số	Giá trị
Số website gửi sang	0900000000
Dạng CRM chờ	+84900000000
Việc cần làm	Chuẩn hóa số trước khi gửi và báo quản trị khi CRM trả 422

KIỂM TRA

Dữ liệu gửi sang không đúng dạng CRM chờ, ví dụ số điện thoại chưa chuẩn hóa.

DẤU HIỆU

Số khách trong CRM ít hơn số lượt gửi form

Chỉ số	Giá trị
Lượt gửi form	64
Khách mới + gộp	58 + 4 = 62
Việc cần làm	Tìm 2 lượt còn thiếu trong nhật ký gửi và gửi lại

KIỂM TRA

Có lượt gửi bị mất giữa đường, hoặc lượt gộp chưa được tính vào.

Tài liệu tham khảo:MDN: mã trạng thái HTTP ↗OWASP: API Security Top 10 ↗

TRƯỚC KHI BẮT ĐẦU

Danh sách kiểm tra.

Đánh dấu từng mục để xem mức sẵn sàng. Trạng thái chỉ lưu trên trình duyệt của bạn.

0%SẴN SÀNG

Mỗi trường của form có một trường trong CRM, hoặc được ghi là bỏ qua có chủ ýSố điện thoại được chuẩn hóa về một dạng trước khi lưuCó quy tắc chống trùng theo số điện thoại trong 90 ngàyKhách gửi lại được ghi thêm lần liên hệ và giữ người phụ trách cũKhách ngoài giờ vào hàng chờ và được chia khi bắt đầu giờ làm việcKhóa API riêng cho website, chỉ có quyền tạo kháchĐã gửi thử một khách và kiểm tra cả bản ghi lẫn người phụ tráchMỗi tuần so số lượt gửi form với số khách trong CRM

Tài liệu tham khảo:OWASP: API Security Top 10 ↗OWASP: quản lý khóa và bí mật ↗OWASP: phân quyền ↗

Nội dung của thẻ Đo đúng khách, đúng nguồnChọn thẻ khác

TRÔNG NHƯ THẾ NÀO

Theo dõi trông như thế nào.

Ba màn hình: thẻ trong Tag Manager, DebugView của GA4, báo cáo sự kiện chính.

Thẻ GA4 gửi sự kiện generate_lead

Thẻ gửi generate_lead kèm hai thông số form_id và lead_source lấy từ dataLayer. Trình kích hoạt lead_submitted chỉ chạy sau khi máy chủ trả 201.

Đọc tiếp

Dùng tên chuẩn generate_lead để báo cáo hiểu ngay. Đẩy dataLayer sau khi máy chủ trả 201, không phải lúc bấm nút, tránh khách ảo.

MÔ PHỎNG · SỐ MẪU

tagmanager.google.com/#/container/accounts/1/workspaces/12/tags/9

TTag ManagerNhà Thơm (mẫu) · GTM-XXXXXXXN

Tổng quanThẻTrình kích hoạtBiếnThư mụcQuản trị

GA4 – sự kiện generate_lead

Không gian làm việc 12 · chưa xuất bản

Cấu hình thẻ

Loại thẻGoogle Analytics: Sự kiện GA4

ID đo lườngG-XXXXXXXXXX (mẫu)

Tên sự kiệngenerate_lead

Thông sốform_id = {{DL – form_id}}
lead_source = {{DL – lead_source}}

Trình kích hoạt

LoạiSự kiện tùy chỉnh

Tên sự kiệnlead_submitted

Kích hoạt khiMọi sự kiện tùy chỉnh trùng tên

Mã trên trang, chạy sau khi máy chủ trả 201:

1dataLayer.push({ event: 'lead_submitted',2  form_id: 'tu-van-qua-tang', lead_source: 'google / cpc' });

generate_lead là tên chuẩn của GA4 cho khách tiềm năng; báo cáo và quảng cáo hiểu ngay, khỏi đặt tên riêng.
Trình kích hoạt là sự kiện tùy chỉnh lead_submitted: thẻ chỉ chạy khi trang đẩy đúng sự kiện này vào dataLayer.
dataLayer.push chạy sau khi máy chủ trả 201, không chạy lúc bấm nút; form lỗi thì GA4 không đếm khách ảo.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Tài liệu tham khảo:Google Tag Manager: chế độ xem trước ↗Google Analytics: theo dõi sự kiện bằng DebugView ↗Google Analytics: báo cáo form tạo lead ↗

LÀM NHƯ THẾ NÀO

Năm bước theo dõi khách.

Gửi sau kết quả thật, tên chuẩn, utm nhất quán, thử trước khi xuất bản.

01Liệt kê sự kiện, đặt tên chuẩn GA4 (generate_lead, purchase), ghi rõ gửi khi nào.
02Thêm dataLayer.push, chạy sau khi máy chủ trả 201 hoặc cổng báo xong, không chạy lúc bấm nút.
03Trong Tag Manager tạo trình kích hoạt theo sự kiện tùy chỉnh và thẻ GA4 đọc thông số từ dataLayer.
04Gắn utm cho mọi link quảng cáo theo một quy ước, thử bằng xem trước và DebugView.
05Đánh dấu sự kiện chính, xuất bản, rồi mỗi tuần so khách GA4 với CRM theo ngưỡng.

Bạn đưa vào

Quyền sửa Tag Manager và xem GA4
Danh sách sự kiện cần theo dõi
Quy ước đặt tên utm
Chỗ chèn mã trên website

dataLayer, Tag Manager, utm, DebugViewONMATE cùng doanh nghiệp

Bạn nhận lại

Thẻ đã xuất bản, sự kiện đã thử bằng DebugView, quy ước utm, bảng so khớp khách hằng tuần.

Tài liệu tham khảo:Google Tag Manager: data layer ↗Google Tag Manager: trình kích hoạt sự kiện tùy chỉnh ↗Google Analytics: tham chiếu sự kiện (generate_lead, purchase) ↗Google Analytics: tạo địa chỉ có thông số chiến dịch (UTM) ↗

CẦN CHUẨN BỊ GÌ

Cần chuẩn bị gì để theo dõi khách.

Cần quyền sửa Tag Manager, quyền xem GA4 và chỗ chèn mã trên website.

NGUYÊN TẮC

Bảng sự kiện: mỗi sự kiện một dòng, ghi tên, khi nào gửi, thông số, có phải sự kiện chính không. purchase kèm transaction_id.

BẢNG SỰ KIỆN · SỐ MẪU

docs.google.com/spreadsheets

nhathom-su-kien-theo-doiTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu

	A	B	C	D
1	Sự kiện	Khi nào gửi	Thông số đi kèm	Sự kiện chính
2	form_start	Khách bấm vào ô đầu tiên của form	form_id	Không
3	form_submit	Khách bấm Gửi, trước khi máy chủ trả lời	form_id	Không
4	generate_lead	Máy chủ trả 201: khách đã vào CRM	form_id, lead_source	Có
5	begin_checkout	Khách vào trang thanh toán	value, items	Không
6	purchase	Trang cảm ơn, sau khi cổng thanh toán báo thành công	transaction_id, value	Có

Sự kiệnThông số

generate_lead chỉ gửi sau khi máy chủ trả 201, không gửi lúc bấm nút. Chênh với form_submit là lượt gửi lỗi.
Chỉ generate_lead và purchase là sự kiện chính vì là kết quả kinh doanh thật. Đánh dấu thừa làm tối ưu sai.
purchase luôn có transaction_id: GA4 dùng mã này để không đếm một đơn hai lần khi khách tải lại trang cảm ơn.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Gửi sau kết quả thật

generate_lead sau khi nhận 201

Dùng tên sự kiện chuẩn

generate_lead, purchase

utm theo một quy ước

Cùng cách viết mọi nơi

Thử trước khi xuất bản

Xem trước và DebugView

Bộ tài nguyên4 mục

KháchQuy ước đặt tên chiến dịchVí dụ qua-tan-gia, dùng cho utm_campaign.
TệpMã Tag Manager đang gắnMã GTM-… và thẻ đã có.
ẢnhẢnh chụp báo cáo GA4Trang Sự kiện hoặc Thu nạp.
BảngDanh sách đường dẫn quảng cáoTrang đích của từng quảng cáo.

Xem đủ thông số và ghi chú

Nguồn: generate_lead và purchase là sự kiện đề xuất Google Analytics nêu generate_lead cho lúc có một khách tiềm năng được tạo ra và purchase cho lúc hoàn tất mua hàng; dùng đúng tên thì báo cáo hiểu ngay.
Nguồn: dataLayer và trình kích hoạt tùy chỉnh Google Tag Manager dùng data layer để nhận thông tin từ trang, và trình kích hoạt sự kiện tùy chỉnh chạy thẻ khi trang đẩy sự kiện có tên khớp.
Lưu ý: Số GA4 thường thấp hơn số CRM Khách tắt theo dõi hoặc từ chối cookie không được GA4 ghi nhận, nên CRM là số khách thật; GA4 dùng để biết nguồn và xu hướng.

Tài liệu tham khảo:Google Analytics: sự kiện đề xuất ↗Google Analytics: tham chiếu sự kiện (generate_lead, purchase) ↗Google Tag Manager: data layer ↗

ĐO ĐIỀU GÌ

Đo bằng bảng so khớp số khách.

Mỗi tuần đặt cạnh nhau: lượt gửi form, khách trong CRM, sự kiện generate_lead trong GA4. CRM là số thật.

CẦN ĐO

Chênh lệch 5 trên 64 là 7,8%, dưới ngưỡng 15% nên chưa cần sửa.

BẢNG SO KHỚP · SỐ MẪU

docs.google.com/spreadsheets

nhathom-so-khop-khachTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu

	A	B	C
1	Nguồn số liệu	Số khách	Ghi chú
2	Biểu mẫu WordPress	64	61 gửi ngay + 3 sau khi thử lại
3	CRM Khách hàng	64	58 khách mới + 6 gộp vào khách cũ
4	Google Analytics (generate_lead)	59	Một số khách tắt theo dõi hoặc từ chối cookie
5	Chênh lệch GA4 so với CRM	−5 (7,8%)	Lấy 5 chia cho 64
6	Ngưỡng cần xem lại	15%	Trong ngưỡng, không cần sửa

Tuần 29/09–05/10Tuần 22/09–28/09

GA4 ghi 59 khách, ít hơn CRM 5 khách: bình thường. Lấy CRM làm số gốc về khách thật.
Chênh lệch 5 trên 64 là 7,8%. Ghi cả số khách lẫn tỷ lệ phần trăm để tuần nào cũng so cùng một cách.
Ngưỡng 15%: chỉ khi chênh vượt mức này mới kiểm tra thẻ và DebugView, khỏi lo mỗi lần lệch vài khách.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Cách đọc số · số mẫu

Chỉ số	Cho biết	Cần xem lại khi
Số khách của GA4 so với CRM	Ít hơn một chút, trong ngưỡng	Cao hơn CRM
Tỷ lệ chênh lệch	Dưới ngưỡng đã đặt (ví dụ 15%)	Vượt ngưỡng nhiều tuần liền
Nguồn của khách	Có tên rõ: google / cpc, zalo / ads	Phần lớn là (direct) / (none)
Sự kiện theo ngày	Ổn định, không ngày nào về 0	Có ngày về 0 hoặc tăng vọt

CÁCH ĐỌC

Ba dòng đầu cho biết thẻ chạy đúng không; dòng chênh lệch cho biết có cần kiểm tra.

Đọc tiếp

Vượt ngưỡng thì mở DebugView, gửi khách thử.

LƯU Ý

Báo cáo GA4 cần thời gian mới ổn định; dùng DebugView để kiểm tra ngay.

Đọc tiếp

Số trong hình là số mẫu.

Tài liệu tham khảo:Google Analytics: theo dõi sự kiện bằng DebugView ↗Google Analytics: sự kiện chính ↗Google Analytics: báo cáo form tạo lead ↗

CÁCH TRIỂN KHAI

Cách xử lý các tình huống thường gặp.

Số trong bảng là số mẫu để minh họa cách đọc, không phải kết quả dự kiến.

Chạy quảng cáo nhưng không biết khách đến từ đâu

Gắn utm cho từng quảng cáo và gửi generate_lead sau khi nhận khách.

Đặt quy ước utm cho mỗi nguồn
Gắn utm vào địa chỉ trang đích
Tạo thẻ generate_lead trong Tag Manager
Xem nguồn trong báo cáo Sự kiện sau một tuần

Đã có thẻ nhưng số khách GA4 lệch xa CRM

Mở DebugView, gửi một khách thử và xem sự kiện bắn mấy lần, vào lúc nào.

Bật chế độ xem trước của Tag Manager
Gửi một khách thử bằng form
Xem trong DebugView sự kiện bắn mấy lần
Chỉnh trình kích hoạt rồi thử lại

Muốn biết đơn hàng nào đến từ quảng cáo

Gửi purchase kèm transaction_id và gắn utm cho đường dẫn quảng cáo.

Thêm dataLayer.push khi cổng thanh toán báo thành công
Gửi purchase kèm transaction_id và value
Đánh dấu purchase là sự kiện chính
So số đơn của GA4 với số đơn trên website

DẤU HIỆU

generate_lead bắn khi khách vừa bấm Gửi, kể cả khi form lỗi

Chỉ số	Giá trị
Lượt gửi thành công	52
generate_lead trong GA4	71
Việc cần làm	Chuyển dataLayer.push xuống sau khi nhận 201

KIỂM TRA

Đoạn dataLayer.push đặt sai chỗ: chạy lúc bấm nút thay vì sau khi máy chủ trả 201.

DẤU HIỆU

generate_lead bị đếm hai lần cho mỗi khách

Chỉ số	Giá trị
Khách trong CRM	64
generate_lead trong GA4	121
Việc cần làm	Gỡ thẻ cũ, chỉ để lại thẻ trong Tag Manager

KIỂM TRA

Hai thẻ cùng chạy trên một sự kiện, ví dụ một thẻ cũ gắn thẳng trong mã trang.

DẤU HIỆU

Phần lớn khách ghi là (direct) / (none)

Chỉ số	Giá trị
Khách google / cpc	3
Khách (direct) / (none)	40
Việc cần làm	Kiểm tra link quảng cáo có utm và đường chuyển hướng có giữ lại không

KIỂM TRA

Địa chỉ quảng cáo thiếu utm, hoặc utm bị mất khi chuyển hướng.

Tài liệu tham khảo:Google Tag Manager: chế độ xem trước ↗Google Analytics: theo dõi sự kiện bằng DebugView ↗Google Analytics: tạo địa chỉ có thông số chiến dịch (UTM) ↗

TRƯỚC KHI BẮT ĐẦU

Danh sách kiểm tra.

Đánh dấu từng mục để xem mức sẵn sàng. Trạng thái chỉ lưu trên trình duyệt của bạn.

0%SẴN SÀNG

Mỗi sự kiện có tên chuẩn, thời điểm gửi và thông số ghi trong bảnggenerate_lead chỉ gửi sau khi máy chủ trả 201purchase có transaction_id để không đếm trùngChỉ generate_lead và purchase được đánh dấu là sự kiện chínhMọi đường dẫn quảng cáo có utm theo một quy ướcĐã thử bằng chế độ xem trước và DebugView trước khi xuất bảnKhông còn thẻ cũ gắn thẳng trong mã trang gửi trùng sự kiệnMỗi tuần so số khách GA4 với CRM theo ngưỡng đã đặt

Tài liệu tham khảo:Google Analytics: sự kiện đề xuất ↗Google Analytics: sự kiện chính ↗Google Tag Manager: chế độ xem trước ↗

Nội dung của thẻ Đơn đổi khi tiền khớpChọn thẻ khác

TRÔNG NHƯ THẾ NÀO

Thanh toán trông như thế nào.

Ba màn hình: webhook ở cổng thanh toán, giao dịch trong tuần, ghi chú trên đơn.

Địa chỉ nhận và sự kiện đăng ký

Đăng ký 3 sự kiện: payment.succeeded, payment.failed, refund.created. Khóa ký whsec_… chỉ hiện đuôi; mã evt_7Kq2 gửi hai lần, cả hai nhận 200.

Đọc tiếp

Chỉ đăng ký ba sự kiện cần dùng. Cổng gửi lại khi chưa nhận phản hồi, nên nhận ra mã đã xử lý là bắt buộc.

MÔ PHỎNG · SỐ MẪU

dashboard.thanhtoan.example/developers/webhooks

TCổng thanh toánNhà Thơm (mẫu) · Chế độ thậtN

Tổng quanGiao dịchChuyển tiềnPhát triểnWebhookKhóa API

Điểm nhận webhook

Chế độ thật

Điểm nhận

Địa chỉhttps://nhathom.example/wp-json/onmate/v1/payment-webhookĐang hoạt động

Sự kiệnpayment.succeededpayment.failedrefund.created

Khóa kýwhsec_••••••••••••a91fHiệnĐổi khóa

Thông báo tuần qua29Phản hồi 20029Lỗi0

Lần gửi gần đây

Giờ	Sự kiện	Mã sự kiện	Phản hồi	Lần gửi
05/10 21:40	`payment.succeeded`	`evt_7Kq2`	200	1
05/10 21:40	`payment.succeeded`	`evt_7Kq2`	200	2
05/10 18:03	`payment.failed`	`evt_7Jx9`	200	1
04/10 15:22	`refund.created`	`evt_7Gm4`	200	1

Chỉ đăng ký 3 sự kiện cần dùng: payment.succeeded, payment.failed, refund.created; đăng ký thừa chỉ thêm việc.
Khóa ký (whsec_…) kiểm tra thông báo đúng do cổng gửi. Chỉ hiện đuôi, chỉ nằm ở máy chủ.
Mã evt_7Kq2 gửi hai lần, cả hai nhận 200. Cổng hay gửi lại, nên website phải bỏ qua mã đã xử lý.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Giao dịch trong tuần ở cổng

Tuần 29/09–05/10: 23 giao dịch thành công, tổng 19.060.000 đồng. Hoàn tiền 420.000 đồng (đơn #3185), thực nhận 18.640.000 đồng. Giao dịch #3198 thất bại.

Đọc tiếp

Đây là số để đối soát. Giao dịch thất bại không làm đơn thành đã trả; hoàn tiền phải đổi trạng thái đơn tương ứng.

MÔ PHỎNG · SỐ MẪU

dashboard.thanhtoan.example/transactions

TCổng thanh toánNhà Thơm (mẫu) · Chế độ thậtN

Tổng quanGiao dịchChuyển tiềnPhát triểnWebhookKhóa API

Giao dịch

29/09–05/10/2026

29/09–05/10/2026Mọi trạng thái

Tuần 29/09–05/10

Thành công2319.060.000 ₫Thất bại4Hoàn tiền1420.000 ₫Thực nhận18.640.000₫ · sau hoàn tiền

Giao dịch gần nhất

Giờ	Mã giao dịch	Đơn	Số tiền	Trạng thái
05/10 21:40	`pay_7Kq2`	#3201	1.280.000 ₫	Thành công
05/10 18:03	`pay_7Jx9`	#3198	640.000 ₫	Thất bại
05/10 11:26	`pay_7Hn5`	#3192	890.000 ₫	Thành công
04/10 15:22	`pay_7Gm4`	#3185	420.000 ₫	Hoàn tiền
04/10 10:05	`pay_7Fd8`	#3180	1.540.000 ₫	Thành công

23 giao dịch thành công, tổng 19.060.000 đồng; trừ 1 hoàn tiền 420.000 đồng, thực nhận 18.640.000 đồng. Dùng để đối soát.
Giao dịch #3198 thất bại: đơn của khách vẫn ở trạng thái chờ thanh toán trên website, không bị đánh dấu đã trả.
Giao dịch #3185 hoàn 420.000 đồng. Website phải đổi đơn này sang hoàn tiền, nếu không số thực nhận hai bên lệch.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Tài liệu tham khảo:Stripe: webhook (nhận sự kiện, xác thực chữ ký, xử lý sự kiện trùng) ↗MDN: idempotent ↗

LÀM NHƯ THẾ NÀO

Năm bước nhận thông báo thanh toán.

Kiểm tra trước, xử lý sau, trả lời sớm; chữ ký sai thì không tin.

01Tạo địa chỉ nhận thông báo, đăng ký đúng sự kiện; khóa ký chỉ lưu ở máy chủ.
02Kiểm chữ ký từng thông báo; sai thì trả 400, ghi nhật ký, không đổi đơn.
03Tra mã sự kiện: đã xử lý rồi thì bỏ qua nhưng vẫn trả 200 để cổng thôi gửi lại.
04So số tiền với tổng đơn; khớp thì đổi trạng thái, lệch thì giữ đơn, báo quản trị.
05Trả 2xx trong vài giây, việc nặng làm sau; mỗi tuần đối soát giao dịch và tổng tiền.

Bạn đưa vào

Tài khoản cổng thanh toán (quyền cấu hình webhook)
Khóa ký thông báo của cổng
Các trạng thái đơn trên website
Danh sách sự kiện cần nhận

Chữ ký, mã sự kiện, so số tiềnONMATE cùng doanh nghiệp

Bạn nhận lại

Webhook đang chạy, thứ tự kiểm tra 5 bước, bảng đối soát tuần, quy tắc chuyển trạng thái đơn.

Tài liệu tham khảo:Stripe: webhook (nhận sự kiện, xác thực chữ ký, xử lý sự kiện trùng) ↗MDN: idempotent ↗OWASP: API Security Top 10 ↗

CẦN CHUẨN BỊ GÌ

Cần chuẩn bị gì để nhận thông báo thanh toán.

Cần quyền webhook ở cổng, người nhận cảnh báo. Không gửi khóa ký qua tin nhắn.

NGUYÊN TẮC

Mỗi bước kiểm tra một dòng: kiểm gì, đạt thì sao, không đạt thì làm gì. Thứ tự: chữ ký, mã sự kiện, số tiền.

THỨ TỰ KIỂM TRA · SỐ MẪU

docs.google.com/spreadsheets

nhathom-kiem-tra-webhookTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu

	A	B	C	D
1	Bước	Kiểm tra	Nếu đạt	Nếu không đạt
2	1. Chữ ký	Chữ ký trong thông báo khớp khóa ký	Đi tiếp	Trả 400, ghi nhật ký, không đổi đơn
3	2. Mã sự kiện	Mã evt_… chưa từng xử lý	Đi tiếp	Bỏ qua, vẫn trả 200
4	3. Số tiền	Bằng tổng đơn, đúng loại tiền	Đi tiếp	Giữ đơn ở Chờ thanh toán, báo quản trị
5	4. Cập nhật đơn	Đổi trạng thái theo loại sự kiện	Chờ thanh toán → Đang xử lý	Ghi nhật ký
6	5. Trả lời	Trả mã 2xx trong vài giây	Cổng không gửi lại	Cổng gửi lại nhiều lần

Thứ tự kiểm traTrạng thái đơn

Chữ ký sai thì dừng: không đổi đơn, chỉ ghi nhật ký. Thiếu bước này, thông báo giả đổi được đơn.
Mã sự kiện đã xử lý thì bỏ qua nhưng vẫn trả 200, để cổng thôi gửi lại.
Số tiền phải khớp tổng đơn. Không khớp thì giữ đơn ở Chờ thanh toán và báo người xem.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Chữ ký kiểm tra đầu tiên

Sai thì dừng, không đổi đơn

Nhận ra mã đã xử lý

Bỏ qua nhưng vẫn trả 200

So số tiền với tổng đơn

Lệch thì giữ đơn và báo

Trả lời trong vài giây

Việc nặng làm sau

Bộ tài nguyên4 mục

KháchNgười nhận cảnh báoTên, email, nhận khi có sự cố.
TệpDanh sách trạng thái đơnChờ thanh toán, đang xử lý, hoàn tiền…
ẢnhẢnh chụp cấu hình ở cổngMục Webhook, che khóa ký.
BảngBảng đối soát đang dùngĐể làm bảng mới cùng cách đọc.

Xem đủ thông số và ghi chú

Nguồn: Xác thực chữ ký và trả 2xx nhanh Tài liệu webhook của Stripe hướng dẫn kiểm tra chữ ký để biết thông báo đến từ cổng, và trả mã 2xx sớm, trước khi chạy những việc nặng.
Nguồn: Một sự kiện có thể đến nhiều lần Cổng gửi lại khi chưa nhận được 2xx, vì vậy mã sự kiện cần được ghi lại và thông báo đã xử lý thì bỏ qua (MDN: phương thức idempotent cho kết quả như nhau dù gửi nhiều lần).
Lưu ý: Không ghi khóa và số thẻ vào nhật ký OWASP khuyên không ghi dữ liệu nhạy cảm vào nhật ký; chỉ ghi mã sự kiện, mã đơn và kết quả kiểm tra.

Tài liệu tham khảo:Stripe: webhook (nhận sự kiện, xác thực chữ ký, xử lý sự kiện trùng) ↗MDN: idempotent ↗OWASP: ghi nhật ký ↗

ĐO ĐIỀU GÌ

Đo bằng bảng đối soát hằng tuần.

Mỗi tuần đặt số của cổng cạnh số của website. Đúng khi cột Chênh toàn số 0.

CẦN ĐO

Dòng Thực nhận: hai bên đều 18.640.000 đồng (19.060.000 trừ hoàn tiền 420.000).

BẢNG ĐỐI SOÁT · SỐ MẪU

docs.google.com/spreadsheets

nhathom-doi-soat-thanh-toanTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu

	A	B	C	D
1	Mục	Cổng thanh toán	Website	Chênh
2	Giao dịch thành công	23	23 (22 đang xử lý hoặc xong + 1 đã hoàn tiền)	0
3	Tổng tiền thành công	19.060.000 ₫	19.060.000 ₫	0
4	Hoàn tiền	1 giao dịch · 420.000 ₫	1 đơn (#3185) · 420.000 ₫	0
5	Thực nhận	18.640.000 ₫	18.640.000 ₫	0
6	Giao dịch thất bại	4	4 đơn đang chờ thanh toán	0
7	Thông báo gửi trùng	1 (evt_7Kq2)	1, đã bỏ qua	0

Tuần 29/09–05/10Tuần 22/09–28/09

Thực nhận hai bên đều là 18.640.000 đồng (19.060.000 trừ 420.000 hoàn tiền). Đối soát xong thì cột Chênh toàn số 0.
4 giao dịch thất bại khớp 4 đơn đang chờ thanh toán: có thể gọi hỏi khách cần giúp gì.
Thông báo gửi trùng 1 lần, website bỏ qua đúng 1 lần: cơ chế chống xử lý hai lần chạy thật.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Cách đọc số · số mẫu

Chỉ số	Cho biết	Cần xem lại khi
Giao dịch thành công	Số giao dịch của cổng bằng số của website	Website ít hơn cổng
Thực nhận (sau hoàn tiền)	Hai bên cùng một số tiền	Lệch dù chỉ một đơn
Giao dịch thất bại	Bằng số đơn đang chờ thanh toán	Có đơn chờ mà cổng không có giao dịch
Thông báo gửi trùng	Có ghi và đã bỏ qua đúng số lần	Số lần bỏ qua ít hơn số trùng

CÁCH ĐỌC

Đọc từ trên xuống: số giao dịch, số tiền, hoàn tiền, thực nhận.

Đọc tiếp

Chênh đều 0 là xong; khác 0 thì lần theo mã sự kiện.

LƯU Ý

Đối soát cùng khoảng ngày, cùng múi giờ, kẻo giao dịch nửa đêm lệch tuần.

Đọc tiếp

Số trong hình là số mẫu.

Tài liệu tham khảo:Stripe: webhook (nhận sự kiện, xác thực chữ ký, xử lý sự kiện trùng) ↗OWASP: ghi nhật ký ↗

CÁCH TRIỂN KHAI

Cách xử lý các tình huống thường gặp.

Số trong bảng là số mẫu để minh họa cách đọc, không phải kết quả dự kiến.

Đơn đã trả tiền nhưng vẫn ở Chờ thanh toán

Kiểm tra địa chỉ webhook có nhận được thông báo không, rồi sửa chỗ xử lý.

Mở phần Webhook ở cổng xem thông báo gửi đi và mã trả về
Xem nhật ký website tìm mã sự kiện của đơn
Sửa chỗ xử lý đang trả lỗi
Gửi lại thông báo từ cổng và kiểm tra đơn đã đổi trạng thái

Lo thông báo giả hoặc bị gửi trùng

Thêm kiểm tra chữ ký ở đầu và bảng mã sự kiện đã xử lý.

Nhập khóa ký vào máy chủ
Kiểm tra chữ ký ở bước đầu tiên
Lưu mã sự kiện đã xử lý
Thử gửi hai lần cùng một mã

Đối soát cuối tháng luôn lệch tiền

Chuyển sang đối soát hằng tuần để lệch nhỏ được thấy sớm.

Xuất danh sách giao dịch của cổng cho tuần
Đặt cạnh danh sách đơn đã trả của website
Tìm dòng lệch theo mã giao dịch
Ghi nguyên nhân và cách sửa vào bảng

DẤU HIỆU

Cổng báo đã gửi thông báo nhưng đơn không đổi

Chỉ số	Giá trị
Mã sự kiện	evt_9Hx4 (mẫu)
Mã website trả về	400, chữ ký không khớp
Việc cần làm	Kiểm tra khóa ký ở máy chủ có đúng khóa của môi trường đang dùng

KIỂM TRA

Máy chủ trả lỗi cho thông báo nên cổng ghi là chưa nhận; thường do chữ ký sai khóa hoặc lỗi xử lý.

DẤU HIỆU

Số tiền thực nhận của cổng và website lệch nhau

Chỉ số	Giá trị
Thực nhận ở cổng	18.640.000 đồng
Thực nhận ở website	19.060.000 đồng
Việc cần làm	Đổi đơn #3185 sang hoàn tiền (420.000 đồng)

KIỂM TRA

Một giao dịch hoàn tiền chưa được website ghi nhận, hoặc đơn bị xử lý hai lần.

DẤU HIỆU

Một đơn bị cộng hai lần

Chỉ số	Giá trị
Thông báo nhận được	2 lần cùng mã evt_7Kq2
Lần xử lý	2
Việc cần làm	Lưu mã sự kiện và bỏ qua thông báo đã có mã

KIỂM TRA

Thông báo gửi hai lần và website chưa nhận ra mã đã xử lý.

Tài liệu tham khảo:Stripe: webhook (nhận sự kiện, xác thực chữ ký, xử lý sự kiện trùng) ↗MDN: idempotent ↗OWASP: API Security Top 10 ↗

TRƯỚC KHI BẮT ĐẦU

Danh sách kiểm tra.

Đánh dấu từng mục để xem mức sẵn sàng. Trạng thái chỉ lưu trên trình duyệt của bạn.

0%SẴN SÀNG

Chỉ đăng ký những sự kiện đang dùng ở cổng thanh toánKhóa ký nằm trên máy chủ, không có trong mã chạy trên trình duyệtMỗi thông báo được kiểm tra chữ ký trước mọi việc khácMã sự kiện được lưu, thông báo đã xử lý thì bỏ qua và vẫn trả 200Số tiền và loại tiền được so với tổng đơn trước khi đổi trạng tháiĐịa chỉ webhook trả 2xx trong vài giây, việc nặng làm sauGiao dịch thất bại giữ đơn ở Chờ thanh toán, hoàn tiền đổi trạng thái đơnMỗi tuần đối soát số giao dịch và thực nhận giữa cổng và website

Tài liệu tham khảo:Stripe: webhook (nhận sự kiện, xác thực chữ ký, xử lý sự kiện trùng) ↗OWASP: API Security Top 10 ↗OWASP: ghi nhật ký ↗

Nội dung của thẻ Đơn và kho khớp nhauChọn thẻ khác

TRÔNG NHƯ THẾ NÀO

Đồng bộ trông như thế nào.

Ba màn hình: sơ đồ luồng dữ liệu, yêu cầu gửi một đơn, hàng chờ trong tuần.

Đơn đi sang, tồn kho đi về

Đơn đi qua hàng chờ, mang khóa riêng; tồn kho về website mỗi 15 phút. Lỗi thì thử lại sau 1, 2, 4 phút.

Đọc tiếp

Mỗi dữ liệu chỉ một bên được sửa nên hai nơi không lệch. Hàng chờ giữ đơn đến khi phần mềm nhận được.

MÔ PHỎNG · SỐ MẪU

so-do.nhathom.example/dong-bo-don-hang

SSơ đồ luồngCổng đại lý (mẫu)L

Luồng đồng bộ đơn hàng và tồn kho

Nhà Thơm (mẫu)

WebsiteĐơn chuyển sang “Đang xử lý”

Gửi đơn

Hàng chờ gửiMỗi đơn một khóa riêng

POST /orders

Phần mềm bán hàngTạo đơn, trừ kho

Tồn kho Phần mềm bán hàng gửi số tồn về website mỗi 15 phút. Một chiều: website không sửa tồn kho.

Khi gửi lỗi Thử lại sau 1, 2, 4 phút. Chưa được thì đơn nằm ở hàng chờ, thử lại mỗi 15 phút và báo người phụ trách khi quá 15 phút.

Mỗi đơn đi qua hàng chờ, mang khóa riêng. Hàng chờ giữ đơn đến khi phần mềm nhận được.
Tồn kho đi một chiều từ phần mềm về website, mỗi 15 phút. Website chỉ đọc, không sửa.
Lỗi thì thử lại sau 1, 2, 4 phút, rồi vào hàng chờ. Quá 15 phút chưa xong thì báo người phụ trách.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Đơn đã gửi và đơn thử lại

Tuần này 31 đơn sang phần mềm: 29 gửi ngay, 2 gửi sau khi thử lại (#3187, #3194), 0 đơn xử lý tay.

Đọc tiếp

Cột Lần thử cho biết đơn nào chờ lâu. Đơn gửi xong chuyển xanh; chỉ đơn quá 15 phút chưa gửi mới báo người phụ trách.

MÔ PHỎNG · SỐ MẪU

nhathom.example/wp-admin/admin.php?page=ket-noi&tab=hang-cho

WBảng điều khiểnNhà Thơm (mẫu)N

Bảng tinTrangĐơn hàngBiểu mẫuGiao diệnPluginCông cụCài đặtKết nối

Hàng chờ gửi đơn

Sang phần mềm bán hàng · tuần 29/09–05/10

Hàng chờNhật ký gửiKhóa kết nối

Tuần 29/09–05/10

Đã gửi31Gửi ngay29Sau khi thử lại2Cần xử lý tay0

Lượt gửi gần nhất

Đơn	Tạo lúc	Kết quả	Lần thử	Gửi xong
#3201	05/10 21:40	Đã gửi	1	21:41
#3199	05/10 16:52	Đã gửi	1	16:52
#3194	02/10 14:26	Gửi sau thử lại	5	14:45
#3187	02/10 14:12	Gửi sau thử lại	6	14:45
#3184	02/10 11:03	Đã gửi	1	11:03

Hàng chờ trống từ 14:45 ngày 02/10. Không có đơn nào phải gửi lại bằng tay.

31 đơn đã gửi sang phần mềm: 29 gửi ngay, 2 gửi sau khi thử lại, 0 đơn cần xử lý tay.
Đơn #3194 tạo 14:26, thử 5 lần, gửi xong lúc 14:45: đơn thứ hai chịu ảnh hưởng của sự cố 02/10.
Đơn #3187 tạo 14:12, thử 6 lần, gửi xong lúc 14:45. Cột Lần thử cho thấy ngay đơn nào phải chờ lâu.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Tài liệu tham khảo:MDN: mã 503 Service Unavailable ↗MDN: idempotent ↗AWS Architecture Blog: Exponential Backoff and Jitter ↗

LÀM NHƯ THẾ NÀO

Năm bước đồng bộ đơn và tồn kho.

Chọn bên giữ bản gốc, rồi viết cách gửi, thử lại và báo lỗi.

01Lập bản đồ dữ liệu: mỗi loại đi hướng nào, khi nào, bên nào giữ bản gốc.
02Gửi đơn bằng POST kèm khóa riêng; gặp lại khóa cũ thì phần mềm không tạo đơn mới.
03Lỗi tạm thời: thử sau 1, 2, 4 phút rồi vào hàng chờ. Lỗi 401: dừng và báo.
04Đặt lịch kéo tồn kho mỗi 15 phút một chiều từ phần mềm; số tồn không được sửa trên website.
05Thử 8 tình huống: tắt phần mềm vài phút, gửi cùng khóa hai lần, mã hàng lạ.

Bạn đưa vào

Tài liệu API của phần mềm bán hàng
Khóa API cho kết nối này
Bảng mã hàng của hai bên
Người phụ trách khi có sự cố

Một chiều, khóa riêng cho mỗi đơn, thử lại tăng dầnONMATE cùng doanh nghiệp

Bạn nhận lại

Hai luồng đồng bộ, bản đồ dữ liệu, quy tắc thử lại, hàng chờ đơn, bảng thử 8 tình huống.

Tài liệu tham khảo:MDN: phương thức HTTP ↗MDN: idempotent ↗MDN: tiêu đề Retry-After ↗MDN: mã 429 Too Many Requests ↗

CẦN CHUẨN BỊ GÌ

Cần chuẩn bị gì để đồng bộ.

Cần tài liệu API, khóa API riêng và bảng mã hàng hai bên.

NGUYÊN TẮC

Bản đồ đồng bộ: mỗi loại dữ liệu một dòng, ghi hướng đi, thời điểm, bên giữ bản gốc, cách xử lý khi lỗi.

BẢN ĐỒ ĐỒNG BỘ · SỐ MẪU

docs.google.com/spreadsheets

nhathom-ban-do-dong-boTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu

	A	B	C	D	E
1	Dữ liệu	Hướng đi	Khi nào	Bên giữ bản gốc	Khi lỗi
2	Đơn hàng	Website → Phần mềm bán hàng	Khi đơn sang Đang xử lý	Website	Thử lại 1, 2, 4 phút, rồi vào hàng chờ
3	Tồn kho	Phần mềm bán hàng → Website	Mỗi 15 phút	Phần mềm bán hàng	Giữ số cũ, báo khi quá 1 giờ
4	Thông tin người mua	Website → Phần mềm bán hàng	Cùng lúc với đơn	Website	Cùng cách thử lại như đơn
5	Hủy đơn, hoàn tiền	Website → Phần mềm bán hàng	Khi đổi trạng thái	Website	Thử lại, dùng khóa riêng

Dữ liệuMã hàng

Mỗi loại dữ liệu có một cách xử lý lỗi. Đơn hàng thử lại rồi vào hàng chờ, không mất đơn.
Tồn kho: phần mềm bán hàng giữ bản gốc, website chỉ nhận. Một bên sửa thì hai nơi mới khớp.
Hủy đơn và hoàn tiền cũng gửi kèm khóa riêng, nên gửi lại không trừ kho hay hoàn tiền hai lần.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Một chiều cho mỗi dữ liệu

Chỉ một bên được sửa

Khóa riêng cho mỗi đơn

Gửi lại không trùng đơn

Thử lại có tính toán

Tăng dần rồi vào hàng chờ

Quá hạn thì báo người

Đơn quá 15 phút chưa gửi

Bộ tài nguyên4 mục

KháchNgười phụ trách phần mềmNgười liên hệ khi phần mềm lỗi.
TệpTài liệu API của phần mềmĐường dẫn hoặc tệp OpenAPI, nếu có.
ẢnhẢnh chụp sản phẩm và khoĐể ghép mã hàng với website.
BảngBảng mã hàng hiện cóGhép mã hàng website với phần mềm.

Xem đủ thông số và ghi chú

Nguồn: Mã 503 và Retry-After MDN mô tả 503 là máy chủ tạm thời chưa xử lý được yêu cầu; máy chủ có thể gửi tiêu đề Retry-After để báo bao lâu sau nên thử lại.
Nguồn: Thử lại tăng dần có xen ngẫu nhiên AWS Architecture Blog giải thích exponential backoff and jitter: tăng dần thời gian chờ giữa các lần thử để không làm máy chủ vừa phục hồi bị quá tải.
Lưu ý: Mã 4xx thường không nên thử lại Lỗi 401, 403 hoặc dữ liệu sai lặp lại y như cũ khi thử lại; cần dừng và báo người xử lý. Riêng 429 là yêu cầu quá nhiều nên cần chờ theo Retry-After.

Tài liệu tham khảo:OpenAPI: đặc tả mô tả API ↗RFC 9110: ngữ nghĩa HTTP ↗MDN: phương thức HTTP ↗MDN: idempotent ↗

ĐO ĐIỀU GÌ

Đo bằng bảng thử 8 tình huống.

Trước khi bật, thử 8 tình huống, nhất là lúc có sự cố. Cả 8 ca đạt mới bật.

CẦN ĐO

Ca 4 (mã hàng lạ) từng thử lại mãi. Đã sửa: dừng đơn, báo lỗi.

BẢNG THỬ ĐỒNG BỘ · SỐ MẪU

docs.google.com/spreadsheets

nhathom-thu-dong-boTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu

	A	B	C	D
1	#	Tình huống	Mong đợi	Kết quả
2	1	Đơn bình thường	Phần mềm có 1 đơn, tồn kho giảm đúng	Đạt
3	2	Phần mềm bán hàng trả 503	Thử lại 1, 2, 4 phút, vào hàng chờ, có cảnh báo	Đạt
4	3	Gửi cùng khóa hai lần	Chỉ có 1 đơn	Đạt
5	4	Mã hàng không có trong phần mềm	Đơn dừng, báo rõ mã hàng, không thử mãi	Đã sửa 06/10
6	5	Hủy đơn đã gửi	Phần mềm đổi sang Đã hủy, tồn kho hoàn lại	Đạt
7	6	Tồn kho về 0 trong phần mềm	Website hiện Hết hàng trong tối đa 15 phút	Đạt
8	7	Dùng khóa hết hạn	Nhận 401, có cảnh báo, không thử lại	Đạt
9	8	Hai khách đặt cùng một giây	Hai đơn riêng, không lẫn nhau	Đạt

Lần thử 06/10Lần thử 21/09

Ca 2 thử đúng tình huống ngày 02/10: phần mềm trả 503. Cứ tắt kết nối vài phút để thử.
Ca 4 phát hiện lỗi thật: mã hàng lạ làm đơn thử lại mãi. Đã sửa: dừng đơn, báo mã sai.
Ca 7 (khóa hết hạn) nhận 401 và không thử lại: thử bao nhiêu lần cũng vậy. Báo người xử lý ngay.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Cách đọc số · số mẫu

Chỉ số	Cho biết	Cần xem lại khi
Ca đơn bình thường	Phần mềm có đúng 1 đơn, tồn kho giảm đúng	Có đơn nhưng tồn kho không đổi
Ca phần mềm trả 503	Thử lại rồi vào hàng chờ, có cảnh báo	Mất đơn hoặc không ai biết
Ca gửi cùng khóa hai lần	Chỉ có 1 đơn	Hai đơn giống nhau
Ca dùng khóa hết hạn	Nhận 401, báo ngay, không thử lại	Thử lại mãi làm đầy hàng chờ

CÁCH ĐỌC

Đọc ba cột: tình huống, mong đợi, kết quả thật.

Đọc tiếp

Dòng lệch thì sửa, ghi “Đã sửa” kèm ngày. Ca 503: tắt kết nối vài phút.

LƯU Ý

Dùng môi trường thử của phần mềm; chưa có thì dùng đơn thử đánh dấu.

Đọc tiếp

Số trong hình là số mẫu.

Tài liệu tham khảo:MDN: mã 503 Service Unavailable ↗MDN: tiêu đề Retry-After ↗AWS Architecture Blog: Exponential Backoff and Jitter ↗

CÁCH TRIỂN KHAI

Cách xử lý các tình huống thường gặp.

Số trong bảng là số mẫu để minh họa cách đọc, không phải kết quả dự kiến.

Đang nhập tay đơn từ website sang phần mềm

Gửi đơn tự động nhưng giữ email thông báo thêm một tuần để đối chiếu.

Lập bản đồ dữ liệu của đơn
Gửi đơn tự động kèm khóa riêng
So số đơn hai nơi mỗi ngày
Ngừng nhập tay sau khi khớp một tuần

Tồn kho website và phần mềm lệch nhau

Chuyển sang kéo tồn kho một chiều từ phần mềm và khóa việc sửa tồn trên website.

Chọn phần mềm làm bên giữ bản gốc
Kéo tồn kho mỗi 15 phút
Khóa việc sửa tồn trên website
Kiểm tra mã hàng chưa ghép

Sợ mất đơn hoặc tạo trùng khi phần mềm lỗi

Thêm hàng chờ, khóa riêng cho mỗi đơn và cảnh báo khi đơn quá hạn.

Gửi đơn kèm Idempotency-Key
Đặt thử lại 1, 2, 4 phút rồi vào hàng chờ
Cảnh báo khi đơn quá 15 phút chưa gửi
Thử bằng cách tắt kết nối vài phút

DẤU HIỆU

Phần mềm có hai đơn giống nhau cho một đơn trên website

Chỉ số	Giá trị
Đơn trên website	#3187 (1 đơn)
Đơn trong phần mềm	2 đơn
Việc cần làm	Gửi kèm Idempotency-Key: ord-3187 ở mọi lần thử

KIỂM TRA

Đơn được gửi lại khi phản hồi bị mất, nhưng thiếu khóa riêng nên phần mềm tạo thêm đơn.

DẤU HIỆU

Hàng chờ ngày càng đầy mà không đơn nào gửi được

Chỉ số	Giá trị
Mã trả về	401
Số đơn trong hàng chờ	17
Việc cần làm	Thay khóa mới, thử kết nối rồi cho hàng chờ chạy lại

KIỂM TRA

Khóa API hết hạn hoặc bị thu hồi, nên mọi lần thử đều nhận 401.

DẤU HIỆU

Website hiện còn hàng trong khi phần mềm đã hết

Chỉ số	Giá trị
Lần cập nhật cuối	2 giờ trước
Ngưỡng cho phép	1 giờ
Việc cần làm	Kiểm tra lịch kéo tồn kho mỗi 15 phút

KIỂM TRA

Lần kéo tồn kho gần nhất lỗi nên website giữ số cũ.

Tài liệu tham khảo:MDN: idempotent ↗AWS Architecture Blog: Exponential Backoff and Jitter ↗MDN: mã 503 Service Unavailable ↗

TRƯỚC KHI BẮT ĐẦU

Danh sách kiểm tra.

Đánh dấu từng mục để xem mức sẵn sàng. Trạng thái chỉ lưu trên trình duyệt của bạn.

0%SẴN SÀNG

Mỗi loại dữ liệu có hướng đi, thời điểm và một bên giữ bản gốcTồn kho đi một chiều và không sửa được trên websiteMỗi đơn gửi kèm khóa riêng, gửi lại không tạo đơn thứ haiLỗi tạm thời (503, 429) được thử lại tăng dần rồi vào hàng chờLỗi 401, 403 hoặc dữ liệu sai dừng ngay và báo người xử lýĐơn quá 15 phút chưa gửi thì báo người phụ tráchCó bảng ghép mã hàng và xử lý mã hàng lạĐã thử đủ 8 tình huống, gồm cả ca tắt phần mềm vài phút

Tài liệu tham khảo:MDN: mã 429 Too Many Requests ↗MDN: tiêu đề Retry-After ↗MDN: idempotent ↗RFC 9110: ngữ nghĩa HTTP ↗

Nội dung của thẻ Cảnh báo trước khi khách gọiChọn thẻ khác

TRÔNG NHƯ THẾ NÀO

Giám sát trông như thế nào.

Ba màn hình: bảng theo dõi kết nối, thư cảnh báo sự cố, lịch hết hạn của khóa.

Tình trạng bảy ngày của từng kết nối

Mỗi kết nối một dòng, biểu đồ 7 ngày: GA4 59 sự kiện, cổng thanh toán 29 thông báo, phần mềm 31 đơn (2 gửi lại).

Đọc tiếp

Thanh vàng chỉ ngay ngày xảy ra sự cố, khỏi mở nhật ký. Mỗi nhãn (Tốt, Trong ngưỡng, Sự cố) theo điều kiện định trước.

MÔ PHỎNG · SỐ MẪU

giamsat.nhathom.example/tong-quan

GGiám sát kết nốiNhà Thơm (mẫu)N

Tổng quanKết nốiCảnh báoNhật kýCài đặt

Tổng quan 7 ngày

29/09–05/10/2026

Kết nối theo dõi5Cảnh báo trong tuần1Cần xử lý tay0

Biểu mẫu → CRMKhách gửi form643 thử lạiTốt
Website → Google AnalyticsSự kiện generate_lead59ít hơn CRM 5Trong ngưỡng
Cổng thanh toán → WebsiteThông báo giao dịch291 trùng, bỏ quaTốt
Website → Phần mềm bán hàngĐơn hàng312 gửi lạiSự cố 02/10
Phần mềm bán hàng → WebsiteTồn kho, mỗi 15 phút6720 lỗiTốt

Website → Google Analytics: 59 sự kiện, ít hơn CRM 5, trong ngưỡng 15% nên nhãn là “Trong ngưỡng”.
Cổng thanh toán → Website: 29 thông báo, 1 thông báo gửi trùng đã bị bỏ qua đúng cách.
Website → Phần mềm bán hàng: 31 đơn, 2 đơn gửi lại. Thanh vàng “Sự cố 02/10” chỉ đúng ngày lỗi.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Thư cảnh báo gửi người trực

Tiêu đề: 1 đơn chưa gửi được sang phần mềm. Thư nêu mã 503 và việc cần làm: đến 15:30 chưa xong thì gọi người phụ trách.

Đọc tiếp

Thư tốt trả lời ba câu: chuyện gì, mức độ ra sao, việc tiếp theo. Chỉ có mã lỗi thì người trực phải tự tra.

MÔ PHỎNG · SỐ MẪU

mail.google.com · Hộp thư đến

Hộp thư đếnGiám sát · Nhà Thơm (mẫu)

Cảnh báo: 1 đơn chưa gửi được sang phần mềm bán hàng

Giám sát kết nối <canh-bao@nhathom.example> · 02/10 14:28

Kết nối	Website → Phần mềm bán hàng
Phát hiện	02/10/2026 14:27, đơn chưa gửi được sau 15 phút
Mã trả về	503 · máy chủ nhận tạm thời không phản hồi
Đơn đang chờ	#3187 (tạo lúc 14:12)
Thử lại tiếp	14:30, tự động, mỗi 15 phút
Việc cần làm	Không gửi lại bằng tay. Nếu đến 15:30 vẫn chưa gửi được, gọi người phụ trách phần mềm bán hàng.

Mở hàng chờ

Tiêu đề nói thẳng chuyện gì: 1 đơn chưa gửi được sang phần mềm bán hàng. Đọc là biết mức độ.
Mã 503 kèm giải thích tiếng Việt: máy chủ nhận tạm thời không phản hồi. Chỉ có mã thì phải đi tra.
Việc cần làm: không gửi lại tay, hệ thống tự thử lại; đến 15:30 chưa xong thì gọi người phụ trách.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Danh sách khóa và mốc nhắc trước hạn

Khóa phần mềm bán hàng còn 41 ngày (nhắc 18/09, 18/10); khóa CRM còn 164, khóa cổng thanh toán 165. Kèm 4 bước thay khóa.

Đọc tiếp

Khóa hết hạn là sự cố tránh được: nhắc ở mốc 60 và 30 ngày. Thay khóa: tạo mới, thử, chuyển sang, xóa khóa cũ.

MÔ PHỎNG · SỐ MẪU

nhathom.example/wp-admin/admin.php?page=ket-noi&tab=khoa

WBảng điều khiểnNhà Thơm (mẫu)N

Bảng tinTrangĐơn hàngBiểu mẫuGiao diệnPluginCông cụCài đặtKết nối

Khóa kết nối

Hôm nay 07/10/2026

Hàng chờNhật ký gửiKhóa kết nối

Khóa của phần mềm bán hàng còn 41 ngày. Nhắc lần 1 đã gửi 18/09 (còn 60 ngày), nhắc lần 2 sẽ gửi 18/10 (còn 30 ngày).

Kết nối	Loại khóa	Hết hạn	Còn lại	Trạng thái
Phần mềm bán hàng	Khóa API	17/11/2026	41 ngày	Sắp hết hạn
CRM Khách hàng	Khóa API	20/03/2027	164 ngày	Tốt
Cổng thanh toán	Khóa ký webhook	Đổi 21/03/2027	165 ngày	Tốt

Thay khóa không gián đoạn

1Tạo khóa mới ở phần mềm bán hàng, chưa xóa khóa cũ
2Dán vào ô “Khóa mới” và bấm Thử kết nối
3Thử đạt thì chuyển sang khóa mới
4Sau 1 ngày không lỗi, xóa khóa cũ

Khóa phần mềm bán hàng còn 41 ngày. Nhắc lần 1 đã gửi 18/09; nhắc lần 2 sẽ gửi 18/10.
Dòng nổi bật là khóa gần hết hạn nhất. Hai khóa còn lại hơn 160 ngày nên chỉ cần để ý mốc nhắc.
Thay khóa không gián đoạn: tạo khóa mới, thử kết nối, chuyển sang, xóa khóa cũ sau 1 ngày không lỗi.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Tài liệu tham khảo:OWASP: ghi nhật ký ↗MDN: mã trạng thái HTTP ↗

LÀM NHƯ THẾ NÀO

Năm bước giám sát kết nối.

Chọn điều gì là sự cố, báo đúng người, rồi dựng bảng theo dõi.

01Liệt kê từng kết nối và việc khách chịu ảnh hưởng gì nếu nó hỏng.
02Đặt điều kiện có con số: đơn quá 15 phút chưa gửi, mã 401, chữ ký sai.
03Ghi vào sổ tay mỗi cảnh báo: gửi ai, kênh nào, việc cần làm.
04Nhật ký chỉ ghi giờ, mã, kết quả; không ghi khóa, dữ liệu cá nhân. Đặt nhắc thay khóa.
05Mỗi tuần xem bảng 7 ngày, ghi sự cố kèm giờ; mỗi tháng thử một cảnh báo.

Bạn đưa vào

Người nhận cảnh báo và người thay thế
Hộp thư hoặc kênh nhận cảnh báo
Danh sách khóa và ngày hết hạn
Các kết nối cần theo dõi

Điều kiện cụ thể, đúng người, nhật ký sạchONMATE cùng doanh nghiệp

Bạn nhận lại

Bảng theo dõi 7 ngày, sổ tay cảnh báo, thư cảnh báo mẫu, lịch nhắc thay khóa, báo cáo tuần.

Tài liệu tham khảo:OWASP: ghi nhật ký ↗OWASP: xử lý lỗi ↗OWASP: quản lý khóa và bí mật ↗

CẦN CHUẨN BỊ GÌ

Cần chuẩn bị gì để giám sát.

Cần người nhận cảnh báo, kênh nhận, danh sách khóa và ngày hết hạn.

NGUYÊN TẮC

Sổ tay cảnh báo: mỗi cảnh báo một dòng, ghi tên, điều kiện có con số, gửi cho ai, việc cần làm.

SỔ TAY CẢNH BÁO · SỐ MẪU

docs.google.com/spreadsheets

nhathom-so-tay-canh-baoTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu

	A	B	C	D
1	Cảnh báo	Điều kiện	Gửi cho	Việc cần làm
2	Đơn chưa gửi sang phần mềm bán hàng	Quá 15 phút	Người phụ trách bán hàng, quản trị	Chờ tự thử lại; quá 1 giờ thì gọi bên phần mềm
3	Khóa bị từ chối	Mã 401 hoặc 403	Quản trị	Kiểm tra khóa còn hạn, đổi khóa nếu cần
4	Chữ ký thanh toán sai	Từ 1 thông báo	Quản trị	Không đổi đơn; kiểm tra khóa ký ở cổng
5	Số khách GA4 lệch CRM	Trên 15% trong tuần	Người làm quảng cáo	Kiểm tra thẻ trong Tag Manager, DebugView
6	Khóa sắp hết hạn	Còn 60 và 30 ngày	Quản trị	Thay khóa theo 4 bước
7	Tồn kho không cập nhật	Quá 1 giờ	Quản trị	Kiểm tra lịch cập nhật 15 phút

Cảnh báoNgười nhận

Mỗi cảnh báo có điều kiện cụ thể: đơn chưa gửi quá 15 phút. “Khi có lỗi” thì báo quá nhiều.
Lệch giữa GA4 và CRM chỉ báo khi vượt 15% trong tuần. Dưới mức đó là bình thường.
Khóa sắp hết hạn báo hai lần, ở mốc còn 60 và 30 ngày, đủ thời gian thay khóa.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Cảnh báo có điều kiện cụ thể

Ví dụ đơn quá 15 phút

Mỗi cảnh báo có người nhận

Kèm người thay khi nghỉ

Nhật ký không ghi khóa

Chỉ giờ, mã và kết quả

Nhắc thay khóa sớm

Ở mốc 60 và 30 ngày

Bộ tài nguyên4 mục

KháchNgười nhận cảnh báoTên, giờ làm, kênh nhận, người thay.
TệpKhóa API và ngày hết hạnKèm người phụ trách; chưa có thì cùng lập.
ẢnhẢnh chụp thư cảnh báo cũThư báo lỗi từng nhận, nếu có.
BảngLịch sử sự cốLần hỏng, hỏng bao lâu, ai xử lý.

Xem đủ thông số và ghi chú

Nguồn: Ghi nhật ký có chọn lọc OWASP Logging Cheat Sheet nêu nên ghi đủ để điều tra (thời gian, sự kiện, kết quả) và không ghi dữ liệu nhạy cảm như mật khẩu hay khóa.
Nguồn: Khóa và bí mật cần vòng đời rõ OWASP Secrets Management khuyên đặt ngày hết hạn, xoay vòng định kỳ và thu hồi được khi lộ; việc nhắc trước hạn làm xoay vòng thành thói quen thay vì khẩn cấp.
Lưu ý: Thông báo lỗi cho khách khác với cho người trực OWASP Error Handling: khách chỉ thấy lời nhắn ngắn, chi tiết kỹ thuật nằm ở nhật ký và thư cho người trực.

Tài liệu tham khảo:OWASP: ghi nhật ký ↗OWASP: quản lý khóa và bí mật ↗OWASP: xử lý lỗi ↗

ĐO ĐIỀU GÌ

Đo bằng báo cáo kết nối hằng tuần.

Mỗi tuần ghi cho từng kết nối: số lượng, lần thử lại, sự cố kèm giờ, đánh giá.

CẦN ĐO

Phần mềm bán hàng: 31 đơn, sự cố 02/10 (14:05–14:40), “Đã xử lý”.

BÁO CÁO KẾT NỐI · SỐ MẪU

docs.google.com/spreadsheets

nhathom-bao-cao-ket-noiTệp Chỉnh sửa Xem Chèn Định dạng Dữ liệu

	A	B	C	D	E
1	Kết nối	Số lượng trong tuần	Lần thử lại	Sự cố	Đánh giá
2	Biểu mẫu → CRM	64 lượt gửi	3	Không	Tốt
3	Website → Google Analytics	59 sự kiện generate_lead	–	Ít hơn CRM 5 (7,8%)	Trong ngưỡng
4	Cổng thanh toán → Website	29 thông báo	0	1 thông báo trùng, đã bỏ qua	Tốt
5	Website → Phần mềm bán hàng	31 đơn	2	02/10, 14:05 đến 14:40	Đã xử lý
6	Phần mềm bán hàng → Website	672 lần cập nhật tồn kho	0	Không	Tốt

Tuần 29/09–05/10Tuần 22/09–28/09

Mỗi dòng là một kết nối, kèm số lượng trong tuần; nhờ vậy thấy kết nối nào ít bất thường.
Sự cố ghi bằng giờ cụ thể: 02/10 từ 14:05 đến 14:40, để tuần sau đối chiếu nhật ký.
Form → CRM có 3 lượt phải thử lại nhưng đều vào CRM, nên không tính là sự cố.

Giao diện và số liệu minh họa cho thương hiệu giả định Nhà Thơm; không phải kết quả của khách hàng.

Cách đọc số · số mẫu

Chỉ số	Cho biết	Cần xem lại khi
Số lượng của từng kết nối	Có con số rõ trong tuần	Chỉ ghi “bình thường”
Lần thử lại	Có số, tăng đột biến thì xem lại	Không ai đếm
Sự cố	Ghi giờ bắt đầu và kết thúc	Ghi chung chung
Đánh giá	Dựa vào điều kiện đã đặt trước	Theo cảm giác

CÁCH ĐỌC

Đọc theo hàng ngang: kết nối, số lượng, thử lại, sự cố, đánh giá.

Đọc tiếp

Hàng vàng thì đọc phần sự cố; không có hàng vàng là ổn.

LƯU Ý

Một người đọc bảng giờ cố định mỗi tuần, không thì chỉ là hình thức.

Đọc tiếp

Số trong hình là số mẫu.

Tài liệu tham khảo:OWASP: ghi nhật ký ↗MDN: mã trạng thái HTTP ↗

CÁCH TRIỂN KHAI

Cách xử lý các tình huống thường gặp.

Số trong bảng là số mẫu để minh họa cách đọc, không phải kết quả dự kiến.

Chỉ biết kết nối hỏng khi khách phàn nàn

Dựng bảng theo dõi 7 ngày và một cảnh báo cho kết nối quan trọng nhất trước.

Chọn kết nối quan trọng nhất (thường là đơn hàng)
Đặt điều kiện cảnh báo có con số
Gửi thư cảnh báo cho một người cụ thể
Thêm dần các kết nối còn lại

Khóa API từng hết hạn bất ngờ

Lập danh sách khóa kèm ngày hết hạn và đặt nhắc ở mốc 60 và 30 ngày.

Lập danh sách mọi khóa đang dùng
Ghi ngày hết hạn và người phụ trách
Đặt nhắc ở mốc 60 và 30 ngày
Viết 4 bước thay khóa không gián đoạn

Người nhận cảnh báo đã quen bỏ qua

Siết lại điều kiện để chỉ báo khi cần, và thêm việc cần làm vào thư.

Đếm số cảnh báo nhận được trong một tháng
Bỏ hoặc nâng ngưỡng cảnh báo hay báo nhầm
Thêm việc cần làm vào từng thư
Thử một cảnh báo mỗi tháng

DẤU HIỆU

Cảnh báo gửi đi nhưng không ai xử lý

Chỉ số	Giá trị
Cảnh báo trong tuần	14
Cảnh báo được xử lý	3
Việc cần làm	Gửi cho một người cụ thể và ghi rõ bước tiếp theo

KIỂM TRA

Thư thiếu việc cần làm hoặc gửi cho hộp thư chung mà không ai nhận.

DẤU HIỆU

Đơn không gửi được nhưng không có cảnh báo

Chỉ số	Giá trị
Đơn chưa gửi	#3187, 22 phút
Điều kiện cảnh báo	Quá 60 phút
Việc cần làm	Hạ xuống 15 phút và thử lại bằng đơn thử

KIỂM TRA

Điều kiện cảnh báo đặt quá cao hoặc chỉ tính lần thử cuối.

DẤU HIỆU

Khóa hết hạn trước khi ai kịp thay

Chỉ số	Giá trị
Lần nhắc	Còn 3 ngày
Mốc nhắc cần có	60 và 30 ngày
Việc cần làm	Thêm hai mốc nhắc và ghi tên người phụ trách khóa

KIỂM TRA

Chỉ nhắc một lần quá gần hạn hoặc không có người phụ trách khóa.

Tài liệu tham khảo:OWASP: quản lý khóa và bí mật ↗OWASP: ghi nhật ký ↗

TRƯỚC KHI BẮT ĐẦU

Danh sách kiểm tra.

Đánh dấu từng mục để xem mức sẵn sàng. Trạng thái chỉ lưu trên trình duyệt của bạn.

0%SẴN SÀNG

Mỗi kết nối có việc làm khách chịu ảnh hưởng ghi trong sổ tayĐiều kiện cảnh báo có con số, không dùng “khi có lỗi”Mỗi cảnh báo có người nhận và người thay thếThư cảnh báo nêu rõ chuyện gì, mức độ và việc tiếp theoNhật ký ghi giờ, mã và kết quả; không ghi khóa hay dữ liệu cá nhânDanh sách khóa có ngày hết hạn và nhắc ở mốc 60 và 30 ngàyBảng theo dõi 7 ngày có ngưỡng cho từng kết nốiMỗi tháng thử một cảnh báo để chắc người nhận vẫn nhận được

Tài liệu tham khảo:OWASP: ghi nhật ký ↗OWASP: xử lý lỗi ↗OWASP: quản lý khóa và bí mật ↗

NHỚ NHANH

Sáu phần việc, từ biểu mẫu đến giám sát.

Chọn một ô để quay lại đúng phần nội dung ở trên.

CÓ THỂ CẦN THÊM

Dịch vụ website đi cùng.

01Website theo yêu cầuNghiệp vụ riêng, vai trò riêng.02Website bán hàngDanh mục, sản phẩm, giỏ hàng và đơn.03Bảo trì WebsiteSao lưu, cập nhật, xử lý sự cố.

Tích hợp hệ thống

Tích hợp tốt là dữ liệu đi đúng nơi một lần, và có người biết lỗi trước khách.

Biểu mẫu

CRM

Theo dõi

Thanh toán

Đồng bộ

Giám sát

Chọn một phần việc để xem toàn bộ cách làm.

Form ngắn, báo lỗi rõ — Hỏi ít, kiểm tra ngay, kiểm tra lại ở máy chủ, chặn gửi trùng.

Biểu mẫu trông như thế nào.

Trường và quy tắc trong WordPress

Biểu mẫu: Nhận tư vấn quà tặng

Form khi nhập sai, khi gửi xong

Yêu cầu của form trong tab Mạng

Năm bước làm biểu mẫu.

Cần chuẩn bị gì để làm biểu mẫu.

Số điện thoại kiểm tra chặt

Đồng ý liên hệ do khách chọn

Lấy nguồn từ địa chỉ trang

Máy chủ kiểm tra lại

Đo bằng bảng thử 8 tình huống.

Cách xử lý các tình huống thường gặp.

Form chỉ gửi email vào hộp thư chung

Hay nhận số điện thoại sai hoặc thiếu

Khách bấm Gửi nhiều lần nên bị trùng

Danh sách kiểm tra.

Khách vào CRM đúng người — Mỗi lượt gửi form thành một khách, chống trùng, chia đúng người.

Kết nối CRM trông như thế nào.

Mỗi trường của form đi vào đâu

Kết nối với website

Khách gửi lại: thêm lần liên hệ

Chống trùng khách

Chia xoay vòng theo giờ làm việc

Chia khách tự động

Năm bước nối CRM.

Cần chuẩn bị gì để nối CRM.

Chuẩn hóa số điện thoại

Chống trùng theo số

Ngoài giờ vào hàng chờ

Khóa API riêng cho website

Đo bằng bảng kiểm tra hằng tuần.

Cách xử lý các tình huống thường gặp.

Đang chép khách từ email sang bảng tính

Một khách xuất hiện nhiều lần

Khách gửi ngoài giờ mà sáng không ai gọi

Danh sách kiểm tra.

Đo đúng khách, đúng nguồn — Sự kiện chỉ bắn sau khi máy chủ nhận form, qua Tag Manager sang GA4.

Theo dõi trông như thế nào.

Thẻ GA4 gửi sự kiện generate_lead

GA4 – sự kiện generate_lead

Xem sự kiện đến GA4 theo từng giây

DebugView

Sự kiện chính generate_lead trong tuần

Sự kiện chính: generate_lead

Năm bước theo dõi khách.

Cần chuẩn bị gì để theo dõi khách.

Gửi sau kết quả thật

Dùng tên sự kiện chuẩn

utm theo một quy ước

Thử trước khi xuất bản

Đo bằng bảng so khớp số khách.

Cách xử lý các tình huống thường gặp.

Chạy quảng cáo nhưng không biết khách đến từ đâu

Đã có thẻ nhưng số khách GA4 lệch xa CRM

Muốn biết đơn hàng nào đến từ quảng cáo

Danh sách kiểm tra.

Đơn đổi khi tiền khớp — Kiểm chữ ký, bỏ thông báo trùng, so số tiền rồi mới đổi đơn.

Thanh toán trông như thế nào.

Địa chỉ nhận và sự kiện đăng ký

Điểm nhận webhook

Giao dịch trong tuần ở cổng

Giao dịch

Ghi chú trên đơn sau thông báo

Đơn hàng #3201

Năm bước nhận thông báo thanh toán.

Cần chuẩn bị gì để nhận thông báo thanh toán.

Chữ ký kiểm tra đầu tiên

Nhận ra mã đã xử lý

So số tiền với tổng đơn

Chọn một phần việc để xem
toàn bộ cách làm.

Cảnh báo: 1 đơn chưa gửi được sang phần mềm bán hàng