Bỏ qua tới nội dung chính

Biểu mẫu liên hệ trên website nên hỏi mấy ô? Cách HAYWEB cắt ô thừa mà vẫn gọi lại được

Nguyễn Thế Quyền — nhà sáng lập HAYWEBXuất bản 13 phút đọc
Bảng thông tin nền xanh đậm chia hai cột đối nhau về cái giá của mỗi ô hỏi thêm trong biểu mẫu liên hệ — cột trái là giá phải trả bằng khách gồm thêm một lý do bỏ dở, thêm thời gian gõ trên điện thoại và thêm một cớ để hoãn lại; cột phải là giá phải trả bằng nghĩa vụ gồm phải biết lưu ở đâu, phải biết ai xem được, phải biết giữ bao lâu và phải xóa được khi khách đòi, kèm ghi chú rằng thu thập dữ liệu không cần thiết nằm trong nhóm vi phạm hay gặp theo cảnh báo của Bộ Công an

Bài 7 lý do website không ra khách xếp biểu mẫu quá dài vào lý do thứ sáu và nói gọn trong ba câu: mỗi ô thừa là thêm một lý do để khách bỏ dở. Câu đó đúng nhưng chưa đủ để quyết, vì nó chưa trả lời được câu khó hơn — ô nào là thừa. Bài này trả lời đúng câu đó, và trả lời bằng một phép tính có hai vế chứ không phải một.

Cảnh thường gặp: chủ tiệm ngồi với người làm web, và mỗi bên thêm một ô vì lý do nghe đều hợp lý. Thêm ô ngân sách để khỏi mất công báo giá cho người không đủ tiền. Thêm ô địa chỉ để biết có giao được không. Thêm ô nghe từ đâu để đo quảng cáo. Xong xuôi thì biểu mẫu có bảy ô, và ba tháng sau không ai hiểu vì sao trang có người vào mà hộp thư thì trống.

Vì sao lời khuyên “biểu mẫu càng ngắn càng tốt” chưa đủ để quyết?

Trả lời ngắn: Vì nó chỉ tính một nửa cái giá. Một ô hỏi thêm lấy đi hai thứ cùng lúc: một phần khách chịu điền tới cuối, và một phần quyền tự do của chính bạn — vì từ giây khách bấm gửi, món thông tin ấy là thứ bạn phải giữ, phải biết giữ ở đâu, và phải xóa được khi khách đòi.

Vế thứ nhất thì ai làm web cũng thuộc. Vế thứ hai mới là phần ít được nói, và nay nó không còn là chuyện đạo đức nghề nghiệp nữa mà là chuyện luật. Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 ban hành ngày 26 tháng 6 năm 2025 và có hiệu lực từ ngày 1 tháng 1 năm 2026. Nghị định hướng dẫn số 356/2025 ban hành ngày 31 tháng 12 năm 2025, cũng có hiệu lực từ ngày 1 tháng 1 năm 2026. Nghĩa là ở thời điểm bạn đọc bài này, cả hai đã đang chạy.

Chi tiết đáng chú ý nhất với người dựng biểu mẫu nằm ở bài cảnh báo doanh nghiệp trên cổng thông tin điện tử Bộ Công an. Trong nhóm vi phạm mà doanh nghiệp hay mắc, mục đầu tiên là thu thập dữ liệu cá nhân không cần thiết. Không phải làm lộ, không phải đem bán — chỉ là hỏi thừa. Cùng danh sách ấy còn có việc chia sẻ thông tin khách khi chưa có đồng ý rõ ràng, và việc suy đoán rằng khách đã đồng ý chỉ vì họ im lặng hoặc vì họ đang dùng dịch vụ của mình.

Đọc xong ba dòng đó thì phép tính đổi hẳn. Trước đây bỏ một ô là mất một mẩu thông tin có thể tiện. Bây giờ giữ một ô không dùng tới là ôm một nghĩa vụ không cần ôm.

Một ô đáng giữ lại khi nào?

Trả lời ngắn: Khi nó qua được cả ba câu hỏi dưới đây. Trượt một câu là cắt, không cần bàn thêm. Phép thử này chạy trên từng ô một, không chạy trên cả biểu mẫu.

Bảng nền xanh đậm trình bày phép thử ba câu hỏi cho từng ô của biểu mẫu liên hệ — câu một hỏi thiếu ô này thì có gọi lại được cho khách không, câu hai hỏi có dùng tới nó ngay trong lần liên hệ đầu tiên không, câu ba hỏi có hỏi sau bằng miệng được không; kèm ghi chú rằng trượt một câu là cắt ô đó và bộ ô tối thiểu của phần lớn tiệm nhỏ chỉ gồm tên gọi cùng một cách liên hệ
Hình 01 — Phép thử chạy trên từng ô. Câu thứ ba là câu cắt được nhiều ô nhất, vì phần lớn thứ ta muốn biết đều hỏi được trong chính cuộc gọi đầu.
  1. Thiếu ô này thì có liên hệ lại được cho khách không? Nếu không thì đây là ô bắt buộc, giữ. Trong thực tế chỉ có một cách liên hệ là bắt buộc, không phải hai. Hỏi cả số máy lẫn thư điện tử là hỏi thừa một ô, trừ khi bạn thật sự trả lời bằng cả hai đường.
  2. Có dùng tới nó ngay trong lần liên hệ đầu tiên không? Ô ngân sách hay trượt ở đây. Người ta điền một con số phòng thủ, bạn gọi tới vẫn phải hỏi lại từ đầu, và rốt cuộc con số ấy chỉ làm một việc là dọa bớt người bấm gửi.
  3. Hỏi sau bằng miệng có được không? Đây là câu cắt được nhiều ô nhất. Địa chỉ, ngày muốn hẹn, tình trạng cụ thể, nghe tiệm từ đâu — hỏi trong cuộc gọi đều nhanh hơn, và câu trả lời còn thật hơn hẳn thứ khách gõ vội trên điện thoại.

Chạy hết ba câu cho một biểu mẫu bảy ô, phần lớn tiệm nhỏ còn lại đúng hai: một ô để gọi đúng tên khách, và một ô để liên hệ được. Nếu bạn thấy con số đó ít quá, hãy để ý là mọi thứ vừa bị cắt không biến mất — chúng chỉ chuyển sang chỗ hỏi rẻ hơn và chính xác hơn.

Có một ngoại lệ đáng giữ: ô mô tả ngắn để khách kể việc họ cần. Nó không lọc ai cả, nhưng nó giúp bạn gọi lại đúng người vào đúng lúc thay vì gọi mò. Để ô này không bắt buộc, và đặt nhãn theo cách mời kể chứ đừng bắt khai.

Hỏi rồi thì phải giữ thế nào cho đúng?

Trả lời ngắn: Trả lời được sáu câu về đường đi của dữ liệu trước khi dựng cái ô. Bài cảnh báo của Bộ Công an khuyên doanh nghiệp rà soát đúng luồng ấy — và may cho người làm web, sáu câu đó cũng chính là nội dung của trang chính sách.

Bảng nền xanh đậm liệt kê sáu câu phải trả lời được trước khi dựng ô nhận thông tin khách trên website — thu những gì, thu của ai, thu để làm gì, lưu ở đâu, ai trong tiệm mở xem được, và giữ trong bao lâu; kèm ghi chú rằng trả lời xong sáu câu này thì phần chữ cho trang chính sách gần như tự viết ra
Hình 02 — Sáu câu về đường đi của dữ liệu. Trả lời không được câu nào thì chưa nên mở ô hỏi thứ đó, vì phần chưa trả lời được chính là phần sẽ hỏng.

Sáu câu ấy là: thu những gì, thu của ai, thu để làm gì, lưu ở đâu, ai trong tiệm mở xem được, và giữ trong bao lâu. Nghe đơn giản nhưng câu thứ tư và thứ sáu là hai câu hay đứng hình nhất. Đa số tiệm nhỏ trả lời câu thứ tư bằng cụm “nó về thư điện tử của em” mà không biết thư đó còn được chuyển tiếp cho ai; và gần như không ai trả lời được câu thứ sáu, vì chưa ai từng nghĩ tới việc xóa.

Còn một điểm nữa nằm ngay trong bài cảnh báo và rất dễ làm sai trên web: sự đồng ý phải rõ ràng và tự nguyện, không được suy ra từ sự im lặng của khách hay từ việc khách đang dùng dịch vụ. Dịch sang việc cụ thể khi dựng biểu mẫu, nó nghĩa là ô đánh dấu đồng ý phải để trống sẵn cho khách tự tích, chứ không tích sẵn hộ; và câu đồng ý phải nói rõ đồng ý cho việc gì, chứ đừng viết một câu chung chung rồi gộp luôn cả việc gửi tin khuyến mãi về sau vào đó.

Ba việc kỹ thuật còn lại thì cùng bài ấy gói trong một cụm quen thuộc: thu ở mức tối thiểu, mã hóa, phân quyền cho người được xem, và có sao lưu. Với một tiệm nhỏ, phân quyền nhiều khi chỉ đơn giản là đừng dùng chung một tài khoản thư cho cả nhà. Và có một ranh giới không được bước qua trong bất cứ hoàn cảnh nào: mua bán dữ liệu cá nhân là hành vi bị cấm.

Phần trang nào phải có trên website thì bài website doanh nghiệp cần những trang nào đã nói, còn phần gom thông tin trước khi dựng thì nằm ở bài chuẩn bị gì trước khi làm website. Riêng những chỗ cần chắc chắn về nghĩa vụ pháp lý cho đúng ngành của mình, nên hỏi người có chuyên môn thay vì làm theo bài trên mạng, kể cả bài này.

Cách HAYWEB tiếp cận

HAYWEB không chỉ áp dụng chạy phép thử ba câu trên từng ô đang có rồi cắt thẳng ô nào trượt, giữ lại đúng một cách liên hệ chứ đừng hỏi cả số máy lẫn thư điện tử, và trước khi dựng bất cứ ô nào thì trả lời trước sáu câu về đường đi của dữ liệu — thu gì, của ai, để làm gì, lưu ở đâu, ai xem được, giữ bao lâu, mà còn kết hợp toàn diện với:

  • Kết cấu bài viết theo chuẩn 2026 — chi tiết chia sẻ qua tư vấn trực tiếp.
  • Cách trình bày thông tin để công cụ tìm kiếm AI (ChatGPT, Gemini, Perplexity, AI Hay) trích dẫn chính xác.
  • Đo lường bằng Google Search Console thật — theo dõi thứ hạng, lượt hiển thị và nhấp chuột từng bài để tối ưu theo dữ liệu.
  • Điểm bảo mật Mozilla Observatory 100 trên 100 và tốc độ Lighthouse trên 90 giữ nguyên qua mọi lần cập nhật, kiểm tra hàng ngày.
  • Cách HAYWEB chọn bộ ô theo từng ngách — gồm cách đặt nhãn mời kể thay vì bắt khai, cách bố trí ô mô tả để khách chịu viết, và cách nối biểu mẫu về Zalo mà vẫn giữ được đường đi của dữ liệu rõ ràng — chia sẻ qua tư vấn trực tiếp.

Trải nghiệm khách hàng như ví dụ thực tế trên — và còn hơn, vì HAYWEB sở hữu thêm các chỉ tiêu nâng cao chuẩn 2026 chỉ chia sẻ qua tư vấn trực tiếp.

Những ô đã cắt thì hỏi lúc nào?

Trả lời ngắn: Hỏi trong cuộc gọi đầu tiên, và hỏi theo thứ tự khách dễ trả lời. Cắt một ô khỏi biểu mẫu không phải là từ bỏ thông tin đó, mà là dời nó sang chỗ lấy được nhiều hơn.

Cách làm rẻ nhất là viết sẵn bốn câu hỏi vào một tờ giấy dán cạnh máy, rồi hỏi theo đúng thứ tự đó mỗi lần gọi lại. Thứ tự có ích: hỏi việc họ cần trước, hỏi thời gian mong muốn sau, rồi mới tới địa chỉ hay phạm vi. Chuyện tiền để cuối, và hỏi bằng cách đưa khoảng chứ đừng hỏi thẳng ngân sách — người ta trả lời khoảng dễ hơn nhiều so với trả lời một con số.

Câu “anh chị biết tiệm qua đâu” cũng nên chuyển vào cuộc gọi thay vì để trên biểu mẫu. Trên biểu mẫu nó là một ô thừa mà ai cũng chọn bừa; trong cuộc gọi nó là một câu hỏi ngắn có câu trả lời thật, và đó mới là số dùng được. Cách ghi lại và dùng câu trả lời ấy nằm ở bài khách đến từ đâu khi các bảng đo đá nhau.

Ô đã chốt rồi thì dựng thế nào cho khách điền nhanh?

Trả lời ngắn: Ba việc, và cả ba đều không làm biểu mẫu dài thêm dòng nào. Đây là phần thuần kỹ thuật, nói cho người làm web là họ làm được ngay.

  • Mỗi ô một nhãn nhìn thấy được. Hướng dẫn của Google trên web.dev nói rõ phải dùng thẻ nhãn cho từng ô nhập. Chữ mờ nằm sẵn bên trong ô không thay được nhãn, vì nó biến mất ngay khi khách bắt đầu gõ, và lúc cần kiểm lại thì không còn gì để đối chiếu.
  • Khai đúng thuộc tính tự điền. Cũng tài liệu ấy khuyên khi một ô có giá trị tự điền phù hợp thì nên khai. Ô tên khai giá trị dành cho tên, ô số máy khai giá trị dành cho số điện thoại, ô thư khai giá trị dành cho thư điện tử. Trình duyệt sẽ đổ sẵn, khách chỉ việc chạm. Tài liệu của MDN cho biết cách khai này giúp người dùng điền nhanh và ít sai hơn, đặc biệt với người hạn chế vận động hoặc nhận thức, và nó cũng khớp một tiêu chí của bộ hướng dẫn tiếp cận nội dung web phiên bản 2.2.
  • Chọn đúng kiểu ô để điện thoại bật đúng bàn phím. Ô số máy phải bật bàn phím số, ô thư phải bật bàn phím có dấu a còng. Nghe nhỏ nhưng với 70 phần trăm người vào bằng điện thoại thì đây là khác biệt giữa điền một tay và điền hai tay. Bài thiết kế ưu tiên điện thoại nói kỹ phần trải nghiệm trên màn nhỏ.

Một câu của Google trên web.dev đáng dán lên tường khi hai bên ngồi chốt biểu mẫu: cách đơn giản nhất để giảm độ phức tạp của một biểu mẫu là bỏ bớt những ô không cần thiết. Không phải chia trang, không phải làm thanh tiến độ, không phải hiệu ứng. Bỏ bớt ô.

Cuối cùng, đừng quên rằng biểu mẫu không phải là cách liên hệ duy nhất và với nhiều ngành nó còn không phải cách chính. Nút gọi và nút nhắn Zalo nên nằm cạnh biểu mẫu chứ không nằm dưới nó. Với trang chạy tiền quảng cáo thì phần bố trí này quan trọng hơn nữa, và bài trang đích cho quảng cáo đã nói riêng.

Câu hỏi thường gặp về biểu mẫu liên hệ

Biểu mẫu liên hệ nên có mấy ô?

Với phần lớn tiệm nhỏ là hai ô bắt buộc — tên gọi và một cách liên hệ — cộng thêm một ô mô tả ngắn để không bắt buộc. Con số này không phải mốc thiêng; nó là kết quả sau khi chạy phép thử ba câu trên từng ô. Ngành có quy trình phức tạp hơn thì có thể cần thêm, nhưng mỗi ô thêm phải trả lời được vì sao nó không hỏi sau được.

Hỏi cả số điện thoại lẫn thư điện tử có sao không?

Có, đó thường là một ô thừa. Chỉ giữ cả hai nếu bạn thật sự trả lời khách bằng cả hai đường. Nếu thực tế bạn luôn gọi hoặc luôn nhắn Zalo thì ô thư điện tử chỉ làm biểu mẫu dài thêm và thêm một món dữ liệu bạn phải giữ mà không dùng tới.

Ô đánh dấu đồng ý nhận thông tin có được tích sẵn không?

Không nên. Bài cảnh báo doanh nghiệp trên cổng thông tin điện tử Bộ Công an nêu rõ sự đồng ý phải rõ ràng và tự nguyện, và không được suy ra từ sự im lặng của khách hay từ việc khách đang dùng dịch vụ. Ô tích sẵn hộ khách chính là kiểu suy đoán đó. Ngoài ra nên tách bạch: đồng ý để được liên hệ về đúng việc đang hỏi là một chuyện, đồng ý nhận tin khuyến mãi về sau là chuyện khác, đừng gộp hai thứ vào một dòng.

Dữ liệu khách gửi qua biểu mẫu phải giữ bao lâu?

Bài này không đưa ra một con số, vì thời hạn phụ thuộc mục đích bạn đã nêu khi thu và vào quy định áp cho ngành của bạn. Điều làm được ngay là chọn một thời hạn, viết nó ra trong chính sách, và làm đúng thứ mình đã viết. Trả lời không được câu giữ bao lâu thì đó là dấu hiệu phần này cần hỏi người có chuyên môn trước khi mở ô thu thập.

Dùng biểu mẫu của bên thứ ba hay tự dựng thì hơn?

Cả hai đều dùng được, nhưng dùng của bên thứ ba thì câu hỏi lưu ở đâu và ai xem được có thêm một tầng nữa: dữ liệu đang nằm trên dịch vụ của ai, ai trong tiệm có tài khoản, và khi khách đòi xóa thì bạn xóa được ở đâu. Trả lời được ba câu ấy thì dùng bên thứ ba hoàn toàn ổn.

Biểu mẫu ngắn có làm lọt nhiều khách không nghiêm túc không?

Có, số cuộc phải sàng sẽ tăng. Nhưng đổi lại bạn không mất những người nghiêm túc mà ngại khai. Cách xử lý đúng không phải dựng thêm ô để chặn, mà là sàng trong cuộc gọi đầu — chỗ đó sàng nhanh hơn và không đuổi nhầm ai.

Bắt đầu thế nào sau khi đọc xong bài này?

Ba việc, và việc đầu làm được trong mười phút. Bước 1 — mở biểu mẫu hiện tại của mình ra, viết từng ô thành một dòng, rồi chạy ba câu hỏi trên từng dòng. Ô nào trượt thì gạch, đừng bàn thêm. Bước 2 — với các ô còn lại, trả lời sáu câu về đường đi của dữ liệu; câu nào chưa trả lời được thì đó chính là việc phải làm trước khi mở ô ấy. Bước 3 — kiểm xem trang của mình đang đứng ở đâu bằng công cụ miễn phí kiểm tra website, mất khoảng 30 giây và không cần đăng ký; hoặc nếu muốn chốt bộ ô cho đúng ngách của mình thay vì theo khung chung, liên hệ HAYWEB tư vấn trực tiếp — nhà sáng lập Nguyễn Thế Quyền trả lời, không qua trung gian bán hàng.

Kiến thức liên quan

Nền tảng — nên đọc trước

Học tiếp — chuyên sâu

Cùng chủ đề

Cần làm website chuyên nghiệp? Gọi trực tiếp HAYWEB.

Nhà sáng lập Nguyễn Thế Quyền trả lời trực tiếp, không qua trung gian bán hàng. Hoặc so sánh website của bạn với chuẩn HAYWEB trên 7 chỉ tiêu kỹ thuật — chỉ cần URL, không cần đăng ký.

Tài liệu tham khảo

  1. Cổng Thông tin điện tử Bộ Công an — cảnh báo, hướng dẫn doanh nghiệp phòng ngừa nguy cơ vi phạm pháp luật về bảo vệ dữ liệu cá nhân (nhóm vi phạm hay gặp gồm thu thập dữ liệu cá nhân không cần thiết, chia sẻ thông tin khách khi chưa có đồng ý rõ ràng, và suy đoán đồng ý từ sự im lặng hoặc từ việc khách đang dùng dịch vụ; khuyến nghị rà soát luồng dữ liệu gồm thu gì, của ai, để làm gì, lưu ở đâu, ai truy cập được, giữ bao lâu; sự đồng ý phải rõ ràng và tự nguyện; áp dụng thu tối thiểu, mã hóa, phân quyền truy cập và sao lưu; khi lộ lọt thì cô lập nguồn, báo cơ quan chức năng và báo người bị ảnh hưởng; cấm mua bán dữ liệu cá nhân — trang KHÔNG nêu mức phạt cụ thể) — retrieved 2026-08-15.
  2. Cổng Thông tin điện tử Chính phủ — Nghị định số 356/2025/NĐ-CP quy định chi tiết một số điều và biện pháp thi hành Luật Bảo vệ dữ liệu cá nhân (trang văn bản chính thức ghi ngày ban hành 31-12-2025, ngày có hiệu lực 01-01-2026, người ký Nguyễn Hòa Bình) — retrieved 2026-08-15.
  3. Cổng Thông tin điện tử Chính phủ — Luật số 91/2025/QH15 Luật Bảo vệ dữ liệu cá nhân (trang văn bản chính thức ghi ngày ban hành 26-06-2025 và ngày có hiệu lực 01-01-2026) — retrieved 2026-08-15.
  4. web.dev (Google) — Payment and address form best practices (cách đơn giản nhất để giảm độ phức tạp của biểu mẫu là bỏ bớt những ô không cần thiết; khi một ô có giá trị tự điền phù hợp thì nên khai thuộc tính autocomplete; dùng thẻ label cho từng ô nhập; dùng đúng thuộc tính type để điện thoại hiện đúng bàn phím) — retrieved 2026-08-15.
  5. MDN Web Docs — thuộc tính autocomplete (giá trị name cho ô tên, tel cho ô số điện thoại, email cho ô thư điện tử; giúp người dùng điền nhanh và chính xác hơn nhờ bớt phải gõ và phải nhớ, hỗ trợ người hạn chế vận động hoặc nhận thức; khớp tiêu chí 1.3.5 Identify Input Purpose của WCAG 2.2) — retrieved 2026-08-15.