Một số tổng đài có thể phục vụ nhiều phòng ban, còn máy lẻ giúp người gọi tới đúng nơi cần gặp. Nếu form chỉ giữ các chữ số rồi ghép thành một chuỗi, phần máy lẻ có thể bị nối vào số chính. Nếu bỏ mọi thứ sau chữ “ext”, hệ thống lại mất thông tin hữu ích. Cả hai cách đều làm dữ liệu trông gọn hơn nhưng khiến nhân viên phải hỏi lại khi liên hệ.
Chuẩn hóa số điện thoại có máy lẻ nên bắt đầu bằng một hợp đồng dữ liệu: giữ bản nhập gốc, tách số chính với máy lẻ và biết trường nào dùng để hiển thị, so sánh hoặc tạo liên kết gọi. Bài này trình bày thiết kế đề xuất cho form và CRM. Các chuỗi số trong ví dụ chỉ minh họa cấu trúc từ RFC hoặc dữ liệu tổng hợp; không dùng để gọi, gửi tin hay khẳng định đang thuộc về một tổ chức.
Một chuỗi nhập có nhiều lớp nghĩa
Người nhập có thể ghi số cùng chú thích phòng ban, giờ liên hệ hoặc hướng dẫn đi qua tổng đài. Trước khi viết bộ tách, cần quyết định form muốn thu thập gì. Nếu mục tiêu là số chính và máy lẻ, nên có ô riêng hoặc ví dụ rõ ràng, thay vì để một ô nhận cả đoạn chỉ dẫn. Cách nhập thuận tiện vẫn cần đi cùng thông báo giúp người dùng sửa phần chưa hiểu được.
Mô hình tối thiểu được đề xuất ở đây gồm bản gốc, số chính, máy lẻ, ngữ cảnh vùng nếu cần và thông tin nguồn. Bản gốc giúp rà lại việc chuyển đổi; các trường tách giúp tìm kiếm và liên hệ. Đây là mô hình ứng dụng, không phải yêu cầu mọi CRM phải có đúng năm cột. Dữ liệu nên lưu theo dạng văn bản phù hợp, không biến máy lẻ thành số học chỉ để dễ tính toán.
Giả sử một dòng nguồn mô tả “số chính trong ví dụ RFC, máy lẻ 204”. Sau khi xử lý, giao diện vẫn cần cho người kiểm tra thấy đâu là số chính và đâu là phần bổ sung. Khi không xác định được ranh giới, không nên tự gán những chữ số cuối làm máy lẻ. Một số chính dài hơn dự kiến và một máy lẻ bị nối vào cuối có thể trông giống nhau nếu chỉ xét độ dài.
Máy lẻ không phải đuôi số chính
RFC 3966, mục máy lẻ quy định tham số ext. Dạng minh họa tel:+1-201-555-0123;ext=204 tách số chính khỏi máy lẻ; không ghép thành +12015550123204. Đây là ví dụ cú pháp, không xác nhận số hoạt động hay thiết bị sẽ tự bấm được máy lẻ.
Khi nhận dữ liệu từ nhiều nguồn, hãy xác định nguồn đang cung cấp văn bản cho người đọc hay một URI. Ký hiệu trình bày trong ô form không tự có cùng quy tắc với chuỗi dùng trong liên kết. Không lấy một đoạn có dấu cách và chú thích rồi đặt nguyên vào thuộc tính liên kết gọi. Cũng không thay đổi bản gốc để làm cho URI tạo ra trông giống như dữ liệu người dùng đã gửi.
Với máy lẻ minh họa 0204, nên giữ nguyên chuỗi trong mô hình đề xuất cho tới khi chủ hệ thống xác nhận quy tắc. Không tự bỏ số không đầu chỉ vì trường được đặt tên “extension”. Việc 0204 và 204 có tới cùng nơi hay không phụ thuộc kế hoạch đánh số thực tế; bài viết không coi hai giá trị ấy đương nhiên tương đương.
Hãy tạo quy tắc chuyển đổi có phiên bản trước khi áp dụng lên danh sách đã có. Chẳng hạn, một phiên bản nhận ô máy lẻ riêng nhưng chưa nhận chú thích tự do; phiên bản sau có thể nhận thêm ký hiệu được xác minh bằng mẫu. Khi có lỗi, người quản lý biết dòng nào đã qua quy tắc nào. Điều này hữu ích hơn việc thay cùng lúc mọi dữ liệu rồi cố đoán nguyên nhân từ kết quả cuối.
Số cục bộ cần đúng ngữ cảnh
RFC 3966 về số cục bộ yêu cầu ngữ cảnh phone-context. Ví dụ biên tập tel:204;phone-context=pbx.example.com biểu diễn máy trong một ngữ cảnh giả định, không phải số quốc tế. Không lấy context ghép cơ học vào đầu số rồi tuyên bố đã có số gọi toàn cầu.
Đối với ứng dụng nhận khách từ nhiều thị trường, ngữ cảnh không nên được suy ra chỉ từ ngôn ngữ trang hoặc vị trí trình duyệt. Người dùng có thể đang công tác, dùng số văn phòng ở nơi khác hoặc nhập thay một đơn vị khác. Một lựa chọn vùng rõ ràng, có thể sửa, thường giúp người kiểm tra hiểu ý định tốt hơn một giả định ẩn. Nếu chỉ phục vụ một thị trường, vẫn cần ghi nhận giả định ấy trong thiết kế và thông báo nhập liệu.
Đội kỹ thuật có thể dùng thư viện để hỗ trợ phân tích thay vì tự duy trì mọi quy tắc đánh số. README của libphonenumber phân biệt khả năng kiểm tra theo độ dài với kiểm tra theo độ dài và tiền tố. Vì vậy, tên một hàm có chữ “possible” không nên được đổi thành kết luận “đã xác minh liên hệ” trong giao diện.
Khi tích hợp thư viện, hãy ghi rõ phiên bản và vùng truyền vào cho các trường hợp không có dấu cộng. Chuẩn bị mẫu đã biết đầu vào và kết quả mong đợi trong môi trường thử, rồi kiểm tra thay đổi trước mỗi lần nâng phiên bản. Báo cáo nên giúp người vận hành phân biệt lỗi nhập, thiếu ngữ cảnh và phần ứng dụng chưa hỗ trợ, thay vì chỉ đưa một thông báo “số không hợp lệ” cho mọi tình huống.
Khóa liên hệ khác khóa khách hàng
Giả sử hai hồ sơ tổng hợp cùng số chính nhưng có máy lẻ 204 và 305. Chúng có thể là hai đầu mối trong cùng doanh nghiệp, không phải hai bản nhập trùng. Ngược lại, cùng một người có thể được liên hệ qua số di động và tổng đài văn phòng. Quyết định gộp khách hàng cần căn cứ danh tính khác; chuẩn hóa chuỗi điện thoại chỉ cung cấp thêm một tín hiệu.
Một thiết kế có thể tạo khóa tìm kiếm theo số chính để nhóm các đầu mối dùng chung tổng đài, đồng thời tạo khóa đích liên hệ theo số chính cộng máy lẻ đã biết. Hai khóa phục vụ hai công việc. Nếu chỉ có một cột duy nhất vừa làm khóa gộp vừa làm đích gọi, thay đổi cách chuẩn hóa có thể âm thầm làm thay đổi cả danh sách khách hàng được coi là trùng.
Ngay cả kết quả kiểm tra theo thư viện cũng chưa đủ chứng minh một số đang được giao cho đúng người hoặc còn liên lạc được. FAQ chính thức của libphonenumber nêu giới hạn này. Không tự đánh dấu “khách đã xác nhận” chỉ vì bộ phân tích trả về giá trị hợp lệ.
Khi cần xem xét gộp hồ sơ, nên đọc thêm quy trình gộp khách hàng CRM và bảo toàn liên kết. Bài hiện tại không hướng dẫn chọn hồ sơ giữ lại hay chuyển đơn hàng, ticket. Mục tiêu ở đây là tạo dữ liệu liên hệ có thể giải thích được trước khi dữ liệu ấy trở thành đầu vào của các quyết định khác.
Thử chuyển đổi mà không sửa mù
Một đợt thử nên bắt đầu từ bản sao dữ liệu tổng hợp với các nhóm khác nhau: số chính có máy lẻ riêng; cùng số chính khác máy lẻ; thiếu vùng; văn bản không tách được; máy lẻ có số không đầu. Chỉ cần ít dòng nhưng mỗi dòng phải có lý do tồn tại và kết quả mong đợi. Đừng dùng số người thật làm dữ liệu mẫu để rồi đưa vào ảnh hoặc nhật ký chia sẻ rộng quyền.
Đối chiếu không dừng ở việc chuỗi cuối trông gọn. Cần xem bản gốc còn truy lại được không, máy lẻ có bị nối vào số chính không, trường chưa hiểu có được giữ nguyên để hỏi lại không và dữ liệu xuất ra có làm mất số không đầu không. Với liên kết gọi, kiểm tra riêng khả năng hỗ trợ trên thiết bị được phép thử; không gọi tới các chuỗi minh họa trong bài.
Khi dữ liệu đi qua CSV, giữ riêng việc phân tích file với việc hiểu số điện thoại. Đọc đúng cột và giữ nguyên văn bản là bước đầu; xác định số chính, máy lẻ và ngữ cảnh là bước tiếp theo. Có thể tham khảo kiểm tra CSV trước khi import cho ranh giới đầu vào. Một file đọc thành công không chứng minh thông tin liên hệ đã được diễn giải đúng.
Nếu cần Onter thiết kế form hoặc nối CRM, hãy chuẩn bị vài dòng giả lập cùng cách muốn hiển thị và sử dụng chúng. Một yêu cầu cụ thể như “giữ riêng máy lẻ và không tự gộp đầu mối cùng tổng đài” giúp xác định phạm vi tốt hơn yêu cầu chung “làm sạch số điện thoại”. Có thể trao đổi nhu cầu mà không gửi danh sách liên hệ thật qua biểu mẫu công khai.
