Quy tắc xác thực dữ liệu cho biểu mẫu doanh nghiệp giúp giảm việc làm lại

Vì sao biểu mẫu doanh nghiệp tạo ra nhiều việc phải làm lại

Một biểu mẫu có thể trông đầy đủ nhưng vẫn khiến người tiếp nhận gặp khó khăn. Ai đó gửi yêu cầu của khách hàng mà không có số điện thoại, nhập ngày giao hàng trước ngày đặt hàng hoặc tạo một công ty đã tồn tại trong cơ sở dữ liệu. Đội ngũ tiếp theo phải dừng lại, tìm thêm thông tin và yêu cầu sửa lại. Những khoảng trống nhỏ này cộng dồn theo thời gian. Một điều phối viên kinh doanh có thể mất mười phút để hỏi lại khoảng ngân sách còn thiếu. Một quản lý hỗ trợ có thể phê duyệt yêu cầu rồi phát hiện email liên hệ bị gõ sai khi hồ sơ chuyển đến đội dịch vụ. Sau khi lỗi đã đi qua bước bàn giao hoặc phê duyệt, nhiều người có thể phải mở lại bản ghi, cập nhật tài liệu liên quan và giải thích thay đổi.

Thiết kế biểu mẫu kém là nguyên nhân của nhiều lỗi như vậy. Nếu một trường có tên «Chi tiết», người dùng sẽ nhập bất cứ điều gì họ cho là quan trọng. Nếu hai trường có tên gần giống nhau, chẳng hạn «tên tài khoản» và «tên khách hàng», nhân viên có thể sử dụng chúng theo những cách khác nhau. Mọi người không thể tuân theo những quy tắc mà họ không nhìn thấy.

Các quy tắc xác thực dữ liệu tốt cho biểu mẫu doanh nghiệp sẽ phát hiện thông tin thiếu, không nhất quán và lặp lại khi người dùng vẫn đang mở biểu mẫu. Bộ chọn ngày tránh những cách nhập ngày tháng mơ hồ. Việc yêu cầu một phương thức liên hệ giúp yêu cầu không bị rơi vào ngõ cụt. Kiểm tra trùng lặp có thể ngăn việc tạo hai bản ghi cho cùng một khách hàng.

Mục tiêu là thu thập thông tin mà người khác có thể sử dụng ngay. Điều đó không có nghĩa là biến mọi trường thành bắt buộc. Bạn cần yêu cầu những chi tiết cần thiết để định tuyến, phê duyệt, xử lý hoặc hỗ trợ yêu cầu mà không phải trao đổi thêm một vòng.

Ví dụ, biểu mẫu yêu cầu vận hành có thể yêu cầu phòng ban của người gửi, dịch vụ cần dùng và hạn hoàn thành. Biểu mẫu chỉ hiển thị thêm câu hỏi sau khi người dùng chọn một dịch vụ cụ thể. Biểu mẫu vẫn ngắn gọn, còn đội vận hành nhận được một bản ghi có thể xử lý ngay từ lần đầu.

Bắt đầu từ thông tin mọi người cần

Biểu mẫu doanh nghiệp nên thu thập thông tin mà ai đó sẽ dùng để đưa ra quyết định hoặc hoàn thành một công việc. Hãy bắt đầu từ hành động ở cuối quy trình, thay vì lập một danh sách dài những dữ kiện có thể hữu ích sau này.

Biểu mẫu yêu cầu của khách hàng có thể giúp đội hỗ trợ phân công công việc, đặt mức ưu tiên và liên hệ với khách hàng. Biểu mẫu cần tên khách hàng, phương thức liên hệ, loại yêu cầu, mô tả rõ ràng và có thể là số tài khoản. Câu hỏi «Bạn biết đến chúng tôi qua đâu?» không nên xuất hiện nếu đội ngũ không sử dụng câu trả lời.

Hãy ghi lại những quyết định mà mỗi lần gửi biểu mẫu phải hỗ trợ. Đó có thể là phân công người phụ trách, phê duyệt chi phí, lên lịch thăm dịch vụ, tạo hóa đơn hoặc báo cáo một vấn đề lặp lại. Sau đó xác định các trường ảnh hưởng đến những quyết định đó.

Nếu quản lý phê duyệt chi phí đi lại, họ có thể cần số tiền, nhóm chi phí, ngày đi, ngày về và người phụ trách ngân sách. Họ có lẽ không cần số bàn làm việc của nhân viên. Xóa các trường không được sử dụng giúp hoàn thành biểu mẫu nhanh hơn và giảm những lần nhập thông tin qua loa.

Trước khi thiết lập quy tắc, hãy mô tả một lần gửi hợp lệ bằng ngôn ngữ đời thường: «Đội ngũ có thể liên hệ với người gửi, hiểu vấn đề, phân công cho đúng người và nhìn thấy mọi thời hạn liên quan». Cách này thường giúp phát hiện thiếu sót tốt hơn một danh sách kiểm tra từng trường.

Cách tiếp cận này cũng ngăn việc xác thực trường bắt buộc trở nên quá chặt. Hãy yêu cầu một trường vì người tiếp theo không thể làm việc nếu thiếu thông tin đó, không phải vì cơ sở dữ liệu có một cột đang để trống. Yêu cầu hỗ trợ qua điện thoại có thể cần số điện thoại. Yêu cầu chỉ liên hệ qua email thì không cần.

Trong AppMaster, các đội ngũ có thể mô hình hóa dữ liệu cần dùng và xây dựng biểu mẫu dựa trên quy trình thực tế. Hãy bắt đầu nhỏ, thử nghiệm với những người gửi và xem xét yêu cầu, sau đó thêm trường khi một công việc thực tế cần đến. Dữ liệu sạch bắt đầu từ ít câu hỏi hơn nhưng phù hợp hơn.

Thiết lập các trường bắt buộc một cách cẩn trọng

Một trường bắt buộc phải thực sự cần thiết. Chỉ đặt trường đó ở chế độ bắt buộc khi người dùng không thể thực hiện bước tiếp theo nếu thiếu câu trả lời. Với yêu cầu của khách hàng, tên người liên hệ, cách phản hồi và loại yêu cầu có thể là những thông tin cần thiết. Chức danh hoặc số điện thoại phụ thường không cần.

Quá nhiều trường bắt buộc sẽ tạo ra dữ liệu kém chất lượng. Người dùng nhập «N/A», các chữ số ngẫu nhiên hoặc văn bản sao chép chỉ để gửi được biểu mẫu. Việc đó tạo ra đúng phần dọn dẹp mà quy tắc muốn ngăn chặn.

Hãy cho người dùng biết trường nào bắt buộc trước khi họ nhấn Gửi. Dùng nhãn rõ ràng như «Địa chỉ email (bắt buộc)» và áp dụng nhất quán. Đừng chỉ dựa vào màu sắc.

Cho người dùng biết một giá trị hợp lệ trông như thế nào ngay cạnh trường. Một ví dụ ngắn có thể ngăn lỗi không đáng có:

• «Email công việc (bắt buộc): [email protected]»
• «Số đơn hàng (bắt buộc): dùng số gồm 8 chữ số trên biên lai»
• «Ngày liên hệ mong muốn (bắt buộc): chọn một ngày trong tương lai»

Việc xác thực trường bắt buộc phải phù hợp với mục đích của biểu mẫu. Nếu đội hỗ trợ chỉ cần ảnh chụp màn hình cho các vấn đề kỹ thuật, hãy yêu cầu ảnh sau khi người dùng chọn «Sự cố kỹ thuật». Bắt mọi khách hàng tải tệp lên sẽ làm quy trình thêm rườm rà và khiến nhân viên nhận được những tệp đính kèm không liên quan.

Áp dụng logic tương tự cho các trường điều kiện. Khách hàng doanh nghiệp có thể cần nhập tên công ty và mã số thuế, còn khách hàng cá nhân thì không. Chỉ yêu cầu các chi tiết đó sau khi người dùng xác định mình là doanh nghiệp.

Nếu xây dựng biểu mẫu trong AppMaster, bạn có thể kết nối quy tắc trường bắt buộc với luồng biểu mẫu và logic nghiệp vụ. Hãy kiểm thử mọi đường đi trước khi xuất bản: để trống một trường bắt buộc, nhập sai định dạng và chuyển đổi giữa các lựa chọn làm hiển thị trường điều kiện. Chỉ hỏi những thông tin đội ngũ sẽ sử dụng.

Thêm kiểm tra giữa các trường để phát hiện xung đột

Một trường có thể trông đúng khi đứng riêng nhưng lại tạo ra yêu cầu sai khi so sánh với một câu trả lời khác. Xác thực giữa các trường kiểm tra những mối quan hệ này trước khi biểu mẫu được chuyển tiếp.

Ngày tháng là một ví dụ phổ biến. Biểu mẫu nên từ chối ngày kết thúc sớm hơn ngày bắt đầu. Với yêu cầu nghỉ phép, biểu mẫu cũng nên cảnh báo nếu ngày quay lại nằm trong khoảng thời gian nghỉ đã chọn. Đặt thông báo cạnh các trường để người dùng sửa ngay khi thông tin vẫn còn rõ ràng.

Quy tắc chi tiêu cũng thường cần cách kiểm tra này. Nếu nhân viên nhập yêu cầu mua hàng trị giá 2.500 USD trong khi hạn mức thông thường là 1.000 USD, biểu mẫu có thể yêu cầu lý do nghiệp vụ và người liên hệ phê duyệt. Hiển thị các trường đó ngay khi số tiền vượt hạn mức, thay vì chờ đến sau khi gửi.

Thông tin giao hàng cũng cần được kiểm tra. Người chọn «Giao đến khách hàng» phải cung cấp địa chỉ giao hàng đầy đủ. Nếu chọn «Khách đến nhận», địa chỉ nên biến mất hoặc trở thành không bắt buộc. Những trường không liên quan dễ tạo ra dữ liệu khó hiểu.

Một số quy tắc xác thực giữa các trường hữu ích:

• Ngày bắt đầu phải sớm hơn ngày kết thúc.
• Yêu cầu vượt một mức tiền nhất định phải có lý do.
• Giao hàng qua đơn vị vận chuyển cần đường phố, thành phố, mã bưu chính và quốc gia.
• «Cá nhân» và «Tài khoản công ty» không thể cùng áp dụng.
• Phương thức liên hệ ưu tiên phải đi kèm số điện thoại hoặc địa chỉ email tương ứng.

Trong một công cụ no-code như AppMaster, đội ngũ có thể đặt các kiểm tra này trong logic biểu mẫu hoặc trong quy trình nghiệp vụ chạy trước khi ứng dụng lưu bản ghi. Những quy tắc quan trọng cũng nên chạy trên máy chủ để việc nhập dữ liệu, yêu cầu API và ứng dụng di động đều tuân theo chúng.

Gắn mỗi kiểm tra với một quyết định kinh doanh thực tế. Nếu nhân viên có thể xử lý một ngoại lệ sau đó mà không gây ảnh hưởng, đừng chặn biểu mẫu. Nếu các câu trả lời mâu thuẫn có thể dẫn đến hoàn tiền, vấn đề tuân thủ hoặc mất thời gian theo dõi, hãy phát hiện trước khi gửi.

Ngăn bản ghi trùng lặp trước khi chúng lan rộng

Bản ghi trùng lặp biến những sai sót nhỏ thành công việc kéo dài. Khách hàng gửi cùng một yêu cầu hai lần có thể nhận hai câu trả lời. Hai phiên bản của một hóa đơn có thể khiến bộ phận tài chính nhầm lẫn. Khi bản ghi trùng lặp xuất hiện trong báo cáo hoặc dữ liệu xuất ra, ai đó phải tự so sánh từng bản ghi.

Hãy chọn các trường dùng để xác định một bản ghi duy nhất. Số hóa đơn chỉ nên xuất hiện một lần. Email khách hàng thường cũng vậy, dù hộp thư dùng chung có thể cần ngoại lệ. Với yêu cầu dịch vụ, một cách kiểm tra hữu ích có thể kết hợp khách hàng, loại yêu cầu và số tham chiếu.

Kiểm tra dữ liệu mới với các bản ghi hiện có trước khi lưu. Kết quả khớp chính xác phù hợp với số hóa đơn, mã đơn hàng và mã nhân viên. Tên và địa chỉ cần được so sánh linh hoạt hơn vì mọi người có thể nhập theo những cách khác nhau. «Maya Chen» và «Maya C. Chen» có thể là cùng một người, nhưng biểu mẫu không nên tự cho rằng như vậy.

Hiển thị các bản ghi có khả năng trùng thay vì chặn biểu mẫu mà không giải thích. Một thông báo rõ ràng có thể là: «Đã có khách hàng dùng email này. Hãy xem lại bản ghi bên dưới trước khi tạo bản ghi khác». Hiển thị đủ chi tiết để nhân viên đưa ra quyết định, chẳng hạn tên, email, công ty và ngày tạo.

Nhân viên cũng cần một cách rõ ràng để tiếp tục khi những bản ghi tương tự thực sự khác nhau. Hai người liên hệ có thể dùng chung email công việc, hoặc hai khách hàng có thể trùng tên. Hãy cung cấp lựa chọn sử dụng bản ghi hiện có, vẫn tạo bản ghi mới hoặc chỉnh sửa thông tin rồi kiểm tra lại.

Khi bản ghi trùng lặp gây ra nhiều việc xử lý phía sau, hãy yêu cầu người dùng nêu lý do. Ví dụ, đội ngũ kế toán có thể yêu cầu ghi chú trước khi nhân viên tạo nhà cung cấp thứ hai có cùng mã số thuế.

Trong AppMaster, bạn có thể xác định các trường duy nhất trong Data Designer và dùng Business Process để tìm bản ghi khớp trước khi tạo bản ghi mới. Quy trình có thể trả về các bản ghi có khả năng trùng cho biểu mẫu web hoặc di động, sau đó lưu mục mới khi người dùng xác nhận sự khác biệt. Cách này giúp quyết định luôn rõ ràng và tập dữ liệu sạch hơn.

Viết thông báo sửa lỗi để người dùng biết phải làm gì

Thông báo lỗi của biểu mẫu nên giúp người dùng sửa vấn đề trong vài giây. Những cảnh báo mơ hồ như «Dữ liệu nhập không hợp lệ» khiến họ phải tự tìm lỗi và đoán cách khắc phục. Thông báo lỗi tốt nêu rõ trường nào gặp vấn đề, giải thích quy tắc và đưa ra ví dụ có thể sử dụng.

Đặt mỗi thông báo cạnh trường cần chú ý. Nếu biểu mẫu cũng hiển thị phần tóm tắt ở đầu trang, hãy chỉ dùng phần đó để dẫn đến các trường bị lỗi. Đừng bắt người dùng quét cả trang dài để tìm một thông báo nhỏ.

Dùng ngôn ngữ đơn giản, mô tả hành động tiếp theo. Mã nội bộ như «ERR-104» có thể hữu ích cho lập trình viên nhưng không giúp gì cho điều phối viên kinh doanh đang nhập yêu cầu của khách hàng.

• Viết «Nhập email công việc, chẳng hạn [email protected]» thay vì «Định dạng email không hợp lệ».
• Viết «Ngày kết thúc phải trùng hoặc muộn hơn ngày bắt đầu» thay vì «Lỗi khoảng ngày».
• Viết «Đã có khách hàng dùng email này. Hãy tìm khách hàng trước khi tạo bản ghi mới» thay vì «Bản ghi trùng lặp».
• Viết «Nhập số tiền lớn hơn 0» thay vì «Giá trị nằm ngoài phạm vi».

Một thông báo hữu ích giải thích vấn đề mà không đổ lỗi cho người dùng. «Không thể lưu yêu cầu vì số tài khoản cần có 8 chữ số» rõ ràng hơn «Bạn đã nhập sai số tài khoản».

Giữ lại các giá trị hợp lệ khi biểu mẫu phát hiện lỗi. Người đã hoàn thành 14 trường chỉ nên phải sửa trường bị lỗi. Xóa cả trang sau lỗi xác thực sẽ biến một lần sửa mất 20 giây thành công việc phải nhập lại.

Kiểm tra thông báo trên máy tính và di động. Một ghi chú nằm cạnh trường trên màn hình máy tính có thể bị đẩy xuống rất xa trên điện thoại. Người nhập dữ liệu phải nhìn thấy thông báo ngay tại nơi cần sửa.

AppMaster cho phép đội ngũ kết nối các trường biểu mẫu với logic nghiệp vụ trực quan và hiển thị thông báo rõ ràng khi quy tắc không đạt. Biểu mẫu yêu cầu của khách hàng có thể giữ nguyên chi tiết đã nhập trong khi yêu cầu người dùng bổ sung một phương thức liên hệ còn thiếu. Cách này ngăn việc nhập lại và giảm số biểu mẫu bị bỏ dở.

Xây dựng quy tắc xác thực từng bước

Hãy bắt đầu bằng một sơ đồ trường đơn giản. Với mỗi trường, ghi lại lý do thu thập, người chịu trách nhiệm về độ chính xác và quy tắc áp dụng. Trưởng bộ phận vận hành kinh doanh có thể phụ trách thông tin tài khoản khách hàng, còn quản lý hỗ trợ phụ trách nhóm yêu cầu và các lựa chọn ưu tiên. Cách này tránh tạo ra những quy tắc không ai có thể giải thích hoặc duy trì.

Giữ phiên bản đầu tiên ở mức nhỏ. Thêm các quy tắc ngăn những lần sửa tốn kém nhất thay vì cố kiểm soát mọi cách nhập có thể xảy ra. Với biểu mẫu yêu cầu của khách hàng, đó có thể là yêu cầu email liên hệ, kiểm tra ngày yêu cầu nằm sau ngày gửi và kiểm tra xem tài khoản đó đã có yêu cầu đang mở hay chưa.

Xây dựng và kiểm thử từng quy tắc trước khi thêm quy tắc tiếp theo. Hãy kiểm tra một lần nhập hợp lệ, một lần bỏ trống giá trị bắt buộc, hai trường mâu thuẫn như ngày kết thúc sớm hơn ngày bắt đầu và một lần nhập khớp với bản ghi hiện có.

Quan sát điều gì xảy ra sau mỗi lần kiểm thử. Biểu mẫu có trỏ đến đúng trường không? Thông tin đã nhập có được giữ lại không? Người dùng có hiểu cách sửa mà không cần hỏi đồng nghiệp không?

Sau đó, hãy mời những người sử dụng biểu mẫu trong công việc hằng ngày thử nghiệm. Giao cho họ các tình huống thực tế, chẳng hạn ghi nhận yêu cầu lặp lại của khách hàng hoặc gửi một trường hợp khẩn cấp nhưng thiếu số điện thoại. Phản hồi của họ thường cho thấy nhãn chưa rõ và các quy tắc kích hoạt quá sớm.

Trên AppMaster, bạn có thể kết nối các kiểm tra với trường biểu mẫu trực quan và quy trình nghiệp vụ, sau đó kiểm thử luồng trước khi phát hành. Hãy lưu lại ngắn gọn từng quy tắc, người phụ trách và các ví dụ dùng để kiểm thử. Khi chính sách hoặc quy trình thay đổi, đội ngũ có thể cập nhật đúng quy tắc thay vì thêm một cách xử lý tạm thời.

Những sai lầm khiến người dùng khó chịu

Xác thực kém làm mất thời gian vì ngăn người dùng hoàn thành công việc nhưng không giúp họ sửa vấn đề. Các quy tắc xác thực dữ liệu tốt cho biểu mẫu doanh nghiệp bảo vệ chất lượng bản ghi và cho người dùng một hướng xử lý rõ ràng.

Biến mọi trường thành bắt buộc

Đôi khi đội ngũ đánh dấu mọi trường là bắt buộc vì có thể ai đó sẽ cần thông tin sau này. Điều này làm chậm người hoàn thành biểu mẫu và khuyến khích các câu trả lời bịa như «N/A» hoặc «00000». Những giá trị đó tạo ra nhiều việc dọn dẹp hơn một trường để trống.

Chỉ yêu cầu một trường khi quy trình không thể tiếp tục nếu thiếu nó. Yêu cầu của khách hàng có thể cần tên người liên hệ, địa chỉ email và loại yêu cầu. Ở bước đầu tiên, có lẽ chưa cần số điện thoại phụ, quy mô công ty hoặc lựa chọn giao hàng. Hãy hỏi thêm chi tiết khi chúng ảnh hưởng đến một quyết định.

Ngăn người dùng nhưng không hướng dẫn

Thông báo như «Dữ liệu nhập không hợp lệ» cho biết có lỗi nhưng không nói phải làm gì tiếp theo. Đặt lỗi cạnh trường, nêu rõ vấn đề và mô tả định dạng được chấp nhận.

Viết «Nhập địa chỉ email công việc, chẳng hạn [email protected]» thay vì «Lỗi email». Nếu ngày kết thúc sớm hơn ngày bắt đầu, hãy viết «Chọn ngày kết thúc trùng hoặc sau ngày bắt đầu». Những hướng dẫn này giảm số lần thử lại và yêu cầu hỗ trợ.

Xác thực giữa các trường cũng cần cách diễn đạt cẩn thận. Biểu mẫu có thể kiểm tra phương thức giao hàng đã chọn có phù hợp với địa chỉ nhập vào hay không, nhưng nên giải thích xung đột thay vì từ chối toàn bộ lần gửi bằng một cảnh báo chung chung.

Phát hiện trùng lặp cũng có thể gây vấn đề tương tự. Email, tên và thông tin công ty có thể giống bản ghi hiện có nhưng không phải cùng một người. Đừng chặn lần gửi chỉ vì xuất hiện kết quả gần giống. Hãy hiển thị bản ghi có khả năng trùng và cho người dùng lựa chọn xem xét.

Trước khi xuất bản biểu mẫu, hãy nhờ một người chưa quen với quy trình nhập dữ liệu thiếu, xung đột và gần giống với bản ghi hiện có. Nếu họ không biết cách sửa lỗi trong vài giây, hãy điều chỉnh quy tắc hoặc thông báo.

Kiểm tra nhanh trước khi xuất bản

Một biểu mẫu có thể trông hoàn chỉnh nhưng vẫn tạo ra bản ghi xấu. Hãy thử biểu mẫu với những dữ liệu thông thường nhưng lộn xộn trước khi mọi người sử dụng. Nhờ một đồng nghiệp không xây dựng biểu mẫu thử thêm. Họ thường phát hiện nhãn khó hiểu và thông báo lỗi rối rắm nhanh hơn người viết quy tắc.

Lần lượt để trống từng trường bắt buộc. Biểu mẫu chỉ nên chặn việc gửi khi thông tin thiếu thực sự cần thiết. Biểu mẫu phải trỏ đến đúng trường và nói rõ người dùng cần nhập gì. «Nhập email liên hệ để chúng tôi có thể gửi cập nhật» rõ ràng hơn «Dữ liệu nhập không hợp lệ».

Kiểm tra các trường phụ thuộc lẫn nhau bằng những tổ hợp thực tế. Ngày kết thúc giao hàng không được sớm hơn ngày bắt đầu. Nếu người dùng chọn «Email» làm phương thức liên hệ ưu tiên, trường địa chỉ email phải trở thành bắt buộc.

Trước khi xuất bản, hãy gửi biểu mẫu với các mục bị thiếu, thông tin liên quan không khớp và email, mã khách hàng hoặc số tham chiếu đã tồn tại. Đọc từng thông báo sửa lỗi mà không có ngữ cảnh và xem hành động tiếp theo có rõ ràng không. Kiểm thử biểu mẫu trên những loại thiết bị mà đội ngũ và khách hàng sử dụng.

Hãy thử cả kết quả khớp chính xác và gần giống, chẳng hạn cùng một số điện thoại nhưng đã bỏ khoảng trắng hoặc tên công ty có một lỗi chính tả nhỏ. Biểu mẫu nên cảnh báo về bản ghi có khả năng trùng và cho phép người dùng xem bản ghi hiện có. Biểu mẫu không nên âm thầm loại bỏ dữ liệu họ vừa nhập.

Nếu xây dựng biểu mẫu trong AppMaster, hãy kiểm tra giao diện web hoặc di động, quy trình nghiệp vụ xử lý lần gửi và bản ghi cơ sở dữ liệu được tạo ở cuối quy trình. Một quy tắc chỉ hoạt động trên một màn hình sẽ không ngăn được dữ liệu xấu từ việc nhập dữ liệu hoặc một màn hình ứng dụng khác.

Ghi lại các lần kiểm thử thất bại và sửa chúng trước khi phát hành. Mười phút kiểm tra với dữ liệu thực tế có thể ngăn hàng giờ dọn dẹp sau khi biểu mẫu đi vào sử dụng.

Ví dụ: biểu mẫu yêu cầu của khách hàng

Một điều phối viên kinh doanh nhận cuộc gọi từ Northline Foods, một công ty đang yêu cầu báo giá dịch vụ. Cô mở biểu mẫu yêu cầu của khách hàng và nhập tên công ty, tên người liên hệ, dịch vụ cần dùng, ngày giao hàng và mô tả ngắn.

Biểu mẫu yêu cầu số điện thoại hoặc địa chỉ email trước khi lưu. Điều phối viên chưa nhập thông tin nào trong hai thông tin đó, nên biểu mẫu hiển thị: «Thêm địa chỉ email hoặc số điện thoại để đội ngũ có thể liên hệ với khách hàng này». Cô thêm địa chỉ email rồi tiếp tục. Thông báo giải thích cả vấn đề lẫn cách sửa.

Tiếp theo, cô chọn dịch vụ lắp đặt và chọn ngày giao hàng vào ngày hôm sau. Dịch vụ này cần năm ngày làm việc để chuẩn bị. Kiểm tra giữa các trường so sánh dịch vụ với ngày đã chọn và hiển thị: «Dịch vụ lắp đặt cần ít nhất năm ngày làm việc. Hãy chọn ngày từ 18 tháng 6 trở đi hoặc chọn dịch vụ có thời gian chuẩn bị ngắn hơn». Cô có thể sửa yêu cầu trước khi ai đó hứa một ngày không thể đáp ứng.

Trước khi biểu mẫu tạo bản ghi khách hàng, tính năng phát hiện trùng lặp kiểm tra tên công ty, miền email và số điện thoại với các bản ghi hiện có. Tính năng này tìm thấy «Northline Food Ltd» có cùng số điện thoại chính. Biểu mẫu hiển thị khách hàng hiện có và cho phép điều phối viên mở bản ghi đó để thêm yêu cầu hoặc xác nhận đây là khách hàng mới với pháp nhân hoặc số liên hệ khác.

Cô mở bản ghi hiện có, nhận ra đó là cùng một công ty và thêm yêu cầu vào bản ghi này. Đội ngũ kinh doanh giờ đây có một hồ sơ khách hàng duy nhất, một người liên hệ có thể tiếp cận và ngày giao hàng có thể đáp ứng.

Đưa việc xác thực tốt hơn vào biểu mẫu tiếp theo

Hãy chọn một biểu mẫu thường xuyên tạo ra các lần sửa. Biểu mẫu yêu cầu của khách hàng, đề nghị thanh toán chi phí hoặc biểu mẫu khách hàng tiềm năng thường là điểm bắt đầu tốt hơn một quy trình hiếm gặp với hàng chục trường hợp bất thường. Sửa một biểu mẫu được 50 người dùng mỗi ngày có thể loại bỏ lượng lớn việc theo dõi.

Ghi lại điều xảy ra sau khi ai đó gửi dữ liệu sai. Có thể nhân viên hỗ trợ phải gửi email hỏi lại số tài khoản, hoặc bộ phận tài chính phải trả lại các đề nghị có ngày nằm ngoài kỳ được phê duyệt. Hãy biến những lần sửa phổ biến nhất thành các quy tắc xác thực dữ liệu rõ ràng cho biểu mẫu doanh nghiệp.

Bắt đầu bằng các quy tắc ngăn những lỗi người dùng có thể sửa ngay: yêu cầu thông tin nhân viên cần cho bước tiếp theo, kiểm tra các giá trị liên quan như khoảng ngày, tìm email hoặc số hóa đơn đã tồn tại trước khi tạo bản ghi và giải thích vấn đề bằng ngôn ngữ đơn giản ngay cạnh trường.

Sau khi xuất bản biểu mẫu, hãy xem xét các lỗi người dùng gặp phải. Một lỗi lặp lại có thể cho thấy quy tắc đang hoạt động, nhưng cũng có thể là dấu hiệu nhãn, hướng dẫn hoặc thứ tự trường khiến người dùng bối rối. Nếu nhiều người nhập email cá nhân trong khi cần email công việc, hãy ghi «Nhập địa chỉ email công ty của bạn» trước khi gửi thay vì chỉ từ chối sau đó.

Hãy chú ý đến các ngoại lệ thực tế trong kinh doanh. Một nhóm nhỏ khách hàng đã được phê duyệt có thể không cần số đơn đặt hàng. Hãy tạo một đường dẫn ngoại lệ rõ ràng cho nhóm đó thay vì buộc nhân viên phải sửa bản ghi bằng tay sau này.

AppMaster cho phép đội ngũ tạo biểu mẫu doanh nghiệp no-code, xác định các trường dữ liệu và sử dụng quy trình nghiệp vụ trực quan để kiểm tra các điều kiện liên quan đến nhiều trường. Cùng một dự án có thể lưu bản ghi, cung cấp API và tạo giao diện web hoặc di động cho nhân viên.

Hãy chọn một lần sửa lặp lại trong tuần này và ngăn nó ngay tại biểu mẫu. Đo tần suất lỗi xuất hiện sau khi thay đổi. Con số đó sẽ cho biết quy tắc giúp tiết kiệm thời gian hay cần một ngoại lệ rõ ràng hơn.