Đến trang thanh toán, khách đã dành thời gian chọn hàng và thường chỉ muốn biết ba điều: mình phải trả bao nhiêu, sẽ nhận theo cách nào và nút cuối sẽ thực hiện việc gì. Một bản dịch mơ hồ ở bước này có thể khiến họ dừng lại dù sản phẩm phù hợp. Viết rõ không có nghĩa thêm lời thúc giục; trước hết cần mô tả đúng dữ liệu, điều kiện và trạng thái mà hệ thống thực sự xác nhận.
Đặt hàng, gửi yêu cầu và thanh toán là những hành động khác nhau
Nhiều nguồn tiếng nước ngoài dùng từ ngắn cho nút cuối vì người trong đội đã quen với luồng mua. Khi chuyển sang tiếng Việt, cần hỏi bấm nút ấy sẽ tạo đơn, gửi yêu cầu báo giá, chuyển sang cổng thanh toán hay thực hiện giao dịch. Không nên chọn một tên nghe dứt khoát rồi để khách tự hiểu. Câu chữ ở thời điểm quyết định phải dựa trên hành động thực, không dựa trên cảm giác câu nào bán hàng tốt hơn.
Ví dụ giả định, website nhận yêu cầu rồi nhân viên kiểm tồn kho và liên hệ xác nhận. Nút “Thanh toán ngay” sẽ không phù hợp nếu chưa có bước trả tiền. Ngược lại, nút “Tiếp tục” quá chung khi thao tác sẽ chuyển khách sang một bước quan trọng. Người dịch nên đưa ra phương án cùng giải thích ngắn về cách hiểu, để chủ sản phẩm xác nhận trước khi áp dụng cho mọi màn hình.
Phần sau nút cũng cần dùng cùng logic. Đã gửi yêu cầu không đồng nghĩa đơn đã được chấp nhận, đơn được tạo không đồng nghĩa tiền đã được ghi nhận. Hãy lập bảng các trạng thái thực và câu được phép dùng cho từng trạng thái. Bảng này sẽ giúp dịch trang, thông báo và email nhất quán; khách không bị nhận một câu ở website và một câu có mức khẳng định khác trong hộp thư.
Vẽ lại luồng thanh toán bằng câu hỏi của khách
Trước khi dịch từng trường, nên đi qua toàn bộ luồng thử. Khách chọn hàng xong sẽ nhập thông tin gì, chọn phương thức nào, có được xem lại không và lúc nào họ rời website? Ghi các bước bằng từ đơn giản, không chỉ tên chức năng nội bộ. Một người chưa quen sản phẩm đọc danh sách ấy cần hình dung mình đang ở đâu và bước tiếp theo là gì.
Ở mỗi bước, hỏi điều khách có thể phân vân. Địa chỉ này để nhận hàng hay xuất thông tin theo yêu cầu? Số điện thoại dùng để liên hệ giao hàng hay xác minh? Lựa chọn nhanh hơn có điều kiện gì? Những câu trả lời cần đến từ đội vận hành. Người dịch có thể làm câu dễ đọc hơn, nhưng không nên tự cam kết thời gian, hình thức xử lý hoặc cách sử dụng thông tin khi chưa có xác nhận.
Một brief tốt nên gửi kèm ảnh hoặc quyền truy cập thử cùng những nhánh đặc biệt. Ví dụ, khách không đăng nhập, giỏ có mặt hàng chưa thể giao, địa chỉ nằm ngoài phạm vi và thanh toán chưa có kết quả cuối. Chỉ xem luồng thành công thường bỏ sót các câu gây lo lắng nhất. Với dịch vụ dịch website, các nhánh này cần được tính vào phạm vi nội dung ngay từ đầu.
Nhãn trường phải cho biết cần nhập gì trước khi khách đoán
Tên người nhận, email, số điện thoại và địa chỉ không phải lúc nào cũng dùng cho cùng một mục đích. Nếu người đặt và người nhận có thể khác nhau, nhãn cần phân biệt rõ. Đừng gọi tất cả là “Thông tin của bạn” rồi phía sau lại yêu cầu tên người nhận. Người dịch nên xem tên trường trong quan hệ với nhóm thông tin và nội dung xác nhận sau đó.
Những yêu cầu định dạng cần được nêu ở nơi người dùng cần biết. Nếu hệ thống yêu cầu một cấu trúc địa chỉ cụ thể, hướng dẫn phải dựa trên cách kiểm tra thực tế. Không nên tự thêm ví dụ số điện thoại của một thị trường rồi coi đó là định dạng bắt buộc cho mọi khách. Cũng không nên dịch tên một trường thành nội dung mang ý nghĩa khác chỉ vì nguồn viết tắt khó hiểu.
Các nhãn cần được cung cấp rõ và liên kết với điều khiển phù hợp trong triển khai. Việc dịch phần chữ hiển thị là một phần; đội kỹ thuật vẫn cần kiểm khả năng tương tác. Không nên chỉ dùng một ví dụ trong ô thay cho mọi thông tin cần thiết rồi kỳ vọng khách nhớ khi đã bắt đầu nhập. Nếu bản dịch làm lộ ra trường khó hiểu, hãy báo vấn đề thay vì cố giải quyết bằng một câu quá dài.
Chi phí cần được gọi tên theo đúng thành phần
Tạm tính, phí giao hàng, khoản giảm và tổng phải trả cần phản ánh cách hệ thống tính. Người dịch không quyết định thuế hoặc chính sách giá, nhưng phải hiểu giá trị nào đang được hiển thị để chọn nhãn. Nếu hệ thống chưa tính xong phí vì khách chưa chọn địa chỉ, không nên gọi con số hiện tại là tổng cuối cùng. Hãy hỏi trạng thái dữ liệu trước khi chọn từ.
Ví dụ, dòng giao hàng đang hiển thị “sẽ xác nhận” không được tự chuyển thành miễn phí. Một mã giảm được tiếp nhận chưa chắc đã áp dụng cho toàn bộ giỏ. Khi nguồn dùng một câu rộng như “Savings”, người dịch nên xác định đó là giảm trực tiếp, chênh lệch so với giá tham chiếu hay một thông tin khác. Chỉ cách gọi đúng mới giúp khách hiểu số đang nhìn thấy mà không cần liên hệ lại.
Nên tạo các giỏ thử khác nhau để đọc toàn bộ phần tổng hợp: có giảm giá, không giảm, thay địa chỉ, đổi phương thức giao và bỏ một mặt hàng. Câu chữ cần khớp số sau mỗi thay đổi. Nếu văn bản và số liệu không cập nhật cùng nhau, ghi đó là vấn đề cần kiểm với kỹ thuật. Không sửa bản dịch để che một trạng thái dữ liệu chưa được xác định.
Lựa chọn giao hàng cần rõ phạm vi, không chỉ tên hấp dẫn
Tên như tiêu chuẩn, nhanh hoặc tiết kiệm chưa đủ giúp khách biết lựa chọn nào phù hợp. Người dịch cần nguồn mô tả thời gian, điều kiện và phạm vi đã được doanh nghiệp duyệt. Không tự biến thời gian dự kiến thành bảo đảm. Nếu thời gian tính từ lúc xác nhận hoặc từ lúc bàn giao cho đơn vị vận chuyển, nội dung cần thể hiện đúng mốc mà quy trình thực sử dụng.
Giả sử khách đặt hàng vào một thời điểm ngoài giờ tiếp nhận. Một câu hứa giao trong ngày có thể bị hiểu rộng hơn chính sách. Người dịch không nên tự sửa thành câu dài với mọi ngoại lệ suy đoán; hãy yêu cầu phần điều kiện được chốt và chọn cách hiển thị phù hợp. Có thể cần một mô tả ngắn ngay lựa chọn cùng liên kết tới chính sách, thay vì dồn mọi thông tin vào tên phương thức.
Với nhận tại điểm giao, cần biết tên điểm, địa chỉ và cách thông báo sẵn sàng. Đặt hàng xong chưa chắc đã có thể đến nhận ngay. Nếu có nhiều địa điểm, không dùng một mô tả chung khiến khách tưởng nơi nào cũng cùng điều kiện. Câu chữ sau khi đặt cần nhắc đúng lựa chọn đã chọn, không trả về thông báo mặc định dành cho giao tới địa chỉ.
Mã ưu đãi: phân biệt được tiếp nhận, hợp lệ và đã áp dụng
Khách nhập mã rồi thấy câu thành công nhưng tổng tiền không đổi sẽ dễ bối rối. Khi dịch, cần hỏi hệ thống dùng thành công cho bước nào. Mã có thể đúng nhưng giỏ chưa đạt điều kiện; cũng có thể ưu đãi áp dụng cho một phần và không hiện dưới hình thức giảm số tiền ngay. Nội dung phải dựa trên logic đã được xác nhận, không chọn một câu chung cho mọi trường hợp.
Thông báo lỗi nên chỉ ra điều người dùng có thể làm tiếp mà không đổ lỗi. “Mã không dùng được” quá rộng nếu hệ thống biết mã đã hết thời gian hoặc không áp dụng cho nhóm hàng đang chọn. Tuy nhiên, không tự viết một nguyên nhân cụ thể khi hệ thống không cung cấp được. Độ chính xác quan trọng hơn cảm giác thông báo có vẻ thông minh.
Hãy kiểm cách nói ở trạng thái chưa nhập, đang kiểm tra, không hợp lệ và đã áp dụng. Nếu cho phép xóa mã, nhãn thao tác phải cho biết đang bỏ ưu đãi hay bỏ sản phẩm. Kiểm thêm trường hợp khách đổi giỏ sau khi mã đã được nhận. Một bản dịch tốt không chỉ giúp nhập thành công lần đầu mà còn giúp họ hiểu những thay đổi về sau.
Thông báo lỗi nhập liệu cần dẫn khách trở lại đúng việc
Một lỗi email nên giúp khách nhận ra trường nào cần kiểm và kiểu vấn đề có thể sửa. Một lỗi địa chỉ cần dựa vào yêu cầu thực của hệ thống, không biến thành lời nhắc chung “thông tin không đúng”. Nội dung lỗi nên có tên trường hoặc ngữ cảnh đủ rõ, đặc biệt khi nhiều mục có lỗi cùng lúc. Người dùng không nên phải thử sửa từng ô ngẫu nhiên.
Có thể so hai ví dụ giả định: “Lỗi 102” và “Kiểm tra lại email nhận thông tin đơn hàng”. Câu sau hữu ích hơn nếu đúng tình huống, nhưng vẫn cần hệ thống giữ dữ liệu đã nhập để khách sửa thuận tiện. Đây là điểm phối hợp: người dịch viết câu, đội thiết kế xác định vị trí và kỹ thuật kiểm hành vi. Chỉ chỉnh câu chữ không tự sửa được cách trang phản hồi.
Tránh dùng ngôn ngữ quy lỗi cho khách khi có khả năng vấn đề từ hệ thống. Nếu chưa xác định nguyên nhân, nói rõ trạng thái được biết và cách kiểm tiếp. Với thao tác có thể tạo nhiều yêu cầu nếu bấm lại, không tự khuyên thử liên tục. Câu hướng dẫn phải được chủ sản phẩm xác nhận theo cách hệ thống xử lý các lần gửi.
Khi chưa biết thanh toán thành công hay chưa, câu chữ phải giữ đúng giới hạn
Một trạng thái chờ phản hồi khác với thất bại được xác nhận. Nếu website chưa nhận được kết quả, người dịch không nên viết “Bạn chưa bị trừ tiền” hoặc “Thanh toán đã thất bại” chỉ để người dùng yên tâm. Những khẳng định đó cần thông tin từ luồng xử lý thực. Câu phù hợp phải nêu điều hệ thống biết, bước cần kiểm và kênh hỗ trợ đã được duyệt.
Doanh nghiệp nên cung cấp cho người dịch các trạng thái từ hệ thống của mình thay vì gửi một chuỗi “Something went wrong” cho mọi lỗi. Đội thanh toán hoặc đội kỹ thuật giải thích khi nào câu được gọi. Người dịch có thể đề xuất tách thông báo để chính xác hơn, nhưng quyết định tích hợp và cách xác định trạng thái thuộc phần nghiệp vụ của đội quản lý sản phẩm.
Trong buổi kiểm thử, dùng các kịch bản được phép trên môi trường thử để xem câu nào xuất hiện khi đóng cửa sổ, quay lại hoặc kết quả đến chậm. Không cần thực hiện giao dịch tiền thật để duyệt bản dịch. Ghi lại điều kiện và câu mong đợi; nếu hệ thống không tái hiện được một nhánh, lưu đó là phần chưa kiểm, không kết luận cả luồng đã ổn.
Trang xác nhận phải giúp khách biết việc tiếp theo
Sau khi gửi thành công, khách cần biết mình đã hoàn tất việc gì và nên chờ gì. Nếu sẽ nhận email, câu ấy phải khớp quy trình thực. Nếu cần nhân viên liên hệ để xác nhận, tránh viết như đơn đã chốt mọi điều kiện. Thông tin hữu ích có thể gồm mã tham chiếu, lựa chọn đã gửi và cách xem trạng thái, tùy chức năng website cung cấp.
Tên trên trang xác nhận cần giống tên ở checkout. Nếu trước đó gọi là nhận tại văn phòng nhưng sau đó lại ghi giao hàng, khách có thể nghĩ lựa chọn đã mất. Các nội dung tự động thường được dịch ở thời điểm khác nhau; hãy kiểm cùng một kịch bản từ đầu đến cuối để phát hiện khác biệt. Sự nhất quán có ý nghĩa thực tế hơn việc mỗi thông báo nghe hay riêng lẻ.
Nếu website và app phục vụ cùng khách, bộ câu trạng thái nên được đối chiếu giữa hai nơi. Có thể trao đổi cùng dịch vụ dịch nội dung ứng dụng để giữ tên thao tác và mức xác nhận thống nhất. Không cần câu chữ giống tuyệt đối khi diện tích màn hình khác, nhưng thông tin về điều đã xảy ra và việc còn chờ không nên thay đổi.
Kiểm bản dịch trên điện thoại và trong các nhánh khó
Chọn một số màn hình hẹp đại diện để xem nhãn, phần phí và thông báo dài. Nếu cần rút câu, ưu tiên bỏ phần thừa thay vì bỏ điều kiện quan trọng. Một tên nút ngắn mà không còn mô tả hành động không phải cải thiện. Đội phát triển cũng cần xem cách xuống dòng và vị trí thông tin, vì giới hạn bố cục không phải lúc nào giải quyết tốt bằng rút ngôn ngữ.
Bảng nghiệm thu nên ghi kịch bản, phiên bản, ngôn ngữ và kết quả. Chọn các trường hợp thiếu dữ liệu, thay lựa chọn giao, bỏ mã, quay lại từ bước ngoài và hoàn tất. Mỗi lỗi cần câu hiện tại, nơi xuất hiện, ảnh nếu cần và vấn đề cụ thể. Phản hồi “dịch khó hiểu” nên được giải thích khách có thể hiểu theo hướng nào và thông tin nào đang thiếu.
Đừng mở rộng lời hứa để làm phần checkout có vẻ hấp dẫn hơn. Cam kết giao, phí và quy trình hỗ trợ phải do doanh nghiệp chốt. Người dịch tạo sự rõ ràng từ thông tin có cơ sở. Bạn có thể đọc thêm kinh nghiệm dịch website tự nhiên hoặc gửi bộ màn hình qua báo giá nhanh để trao đổi phạm vi dịch cùng bước kiểm cần thiết.
Câu hỏi thường gặp
Chỉ gửi ảnh trang thanh toán có đủ để dịch không?
Ảnh giúp hiểu bố cục, nhưng nên có cả danh sách câu và các trạng thái không xuất hiện trong ảnh. Cần biết nút làm gì, dữ liệu nào thay đổi và câu nào do hệ thống gọi. Với biến hoặc nội dung động, phải có mẫu để kiểm câu hoàn chỉnh.
Có nên dịch checkout là thanh toán ở mọi nơi không?
Cần theo hành động và cách tổ chức website. Một bước có thể gồm xem lại đơn, nhập giao hàng và chọn trả tiền, trong khi một luồng khác chỉ gửi yêu cầu. Chọn tên người dùng hiểu được, đồng thời không khẳng định họ đang trả tiền nếu hệ thống chưa thực hiện việc đó.
Người dịch có thể viết lại câu để tăng chuyển đổi không?
Có thể đề xuất câu rõ và phù hợp hơn trong phạm vi được duyệt. Không tự thêm ưu đãi, thời gian hoặc bảo đảm để thúc đẩy thao tác. Những thay đổi có ảnh hưởng nghiệp vụ cần được người phụ trách xác nhận rồi mới đưa vào bản dịch cuối.
Thông báo lỗi nên ngắn đến mức nào?
Cần đủ cho khách nhận ra vấn đề và bước tiếp theo. Câu quá ngắn có thể không hữu ích; câu quá dài dễ che mất việc cần làm. Chọn mức cụ thể theo tình huống và kiểm trên màn hình thực, không áp dụng một số chữ cố định cho mọi lỗi.
Có nên dùng một câu lỗi chung cho mọi tình huống không?
Nếu hệ thống không phân biệt được, nội dung phải giữ đúng giới hạn ấy. Tuy nhiên, nên hỏi đội sản phẩm có thể tách các nhánh quan trọng không. Không dùng một câu thất bại chung cho trạng thái chưa xác định, và không tự nêu nguyên nhân chưa được hệ thống xác nhận.
Có cần dịch cả email sau đặt hàng trong cùng đợt không?
Nên đối chiếu vì khách sẽ đọc cả hai. Nếu email nằm ngoài phạm vi, vẫn cần biết tên trạng thái và nội dung chính để không mâu thuẫn. Doanh nghiệp có thể chia đợt, nhưng cần ghi rõ ai chịu trách nhiệm kiểm sự khớp nhau trước phát hành.
Khách quốc tế có cần cùng cách nhập địa chỉ không?
Cần theo thị trường và khả năng của hệ thống, không chỉ thay nhãn sang ngôn ngữ khác. Người dịch báo điểm khó hiểu; đội phát triển và vận hành xác nhận cấu trúc nhận địa chỉ cùng điều kiện giao. Ví dụ trong ô phải phù hợp phạm vi thật.
Làm sao đánh giá bản dịch checkout đã đủ tốt?
Kiểm câu có đúng hành động và trạng thái, phí có được gọi rõ, nhãn có giúp nhập đúng và lỗi có hướng dẫn phù hợp. Sau đó đi qua các nhánh đại diện trên đầu ra. Chỉ đọc bản song ngữ chưa đủ chứng minh mọi thông báo xuất hiện đúng lúc.
