Một phụ huynh thanh toán cho hai con học hai lớp khác nhau. Website lưu tên người trả tiền như tên học viên, rồi chỉ tạo một hồ sơ ghi danh. Đến buổi đầu, giáo viên thiếu một tên trong danh sách, còn bộ phận chăm sóc không biết khoản thanh toán đang gắn với ai. Khi một người thanh toán cho nhiều học viên, website cần tách rõ người liên hệ, người trả tiền và từng ghi danh.
Đây là bài phân tích mô hình dữ liệu và quy trình đối chiếu. Những gia đình, lớp và giao dịch được nhắc tới đều là ví dụ giả định; bài không hướng dẫn hạch toán, xuất hóa đơn hoặc quyết định quyền giám hộ.
Một người thanh toán cho nhiều học viên cần các ghi danh riêng
Trong ví dụ, học viên A học lớp sáng, học viên B học lớp chiều và phụ huynh P thanh toán cho cả hai. Cần ít nhất hai quan hệ ghi danh: A với lớp sáng, B với lớp chiều. Đơn thanh toán có thể là một hoặc nhiều tùy giải pháp, nhưng không được làm mất hai quan hệ học tập độc lập này.
Hồ sơ P chứa thông tin liên hệ và vai trò đã được xác nhận trong phạm vi cần thiết. Hồ sơ A và B chứa dữ liệu người học tương ứng. Việc P là người trả tiền không tự chứng minh P là người được quyền xem mọi thông tin học tập hoặc nhận mọi thông báo. Những quyền đó cần được trung tâm xác minh theo quy trình, không suy ra từ một lần chuyển tiền.
Tên và số điện thoại của phụ huynh có thể xuất hiện ở nhiều đơn. Dùng chúng làm khóa duy nhất của ghi danh sẽ khiến lần đăng ký thứ hai ghi đè lần thứ nhất. Ngược lại, tạo một phụ huynh mới cho từng con sẽ làm phân tán thông tin liên hệ và gây khó khăn khi cần cập nhật số liên lạc chính.
Tài liệu HubSpot về liên kết bản ghi là một ví dụ cho cách giữ các hồ sơ riêng rồi nối quan hệ. Nó không có nghĩa CRM tự hiểu quan hệ học viên–người thanh toán. Đội triển khai vẫn phải định nghĩa đúng đối tượng, nhãn và phạm vi dữ liệu của trung tâm.
Đặt vai trò vào quan hệ, không dán vào mọi hồ sơ
Một người có thể thanh toán cho học viên này nhưng chỉ là liên hệ khẩn cấp của học viên khác. Nếu hồ sơ người đó có một trường toàn cục “vai trò: phụ huynh thanh toán”, các quy trình dễ áp dụng sai sang mọi người học liên quan. Vai trò cần gắn với đúng mối quan hệ và phạm vi có hiệu lực.
HubSpot hỗ trợ nhãn quan hệ giữa bản ghi. Đây là cách tham khảo để mô tả một người liên hệ đang đóng vai trò gì trong một liên kết cụ thể. Khả năng tạo nhãn và giới hạn còn phụ thuộc gói dịch vụ, quyền và đối tượng hỗ trợ; không nên hứa một tài khoản bất kỳ có đầy đủ tính năng này.
Trong mô hình đề xuất, có thể có nhãn người thanh toán, người nhận thông báo học tập hoặc người liên hệ khẩn cấp theo nhu cầu đã xác minh. Không nhất thiết tạo đủ mọi nhãn nếu trung tâm không dùng. Mỗi nhãn phải trả lời một công việc thật, tránh xây danh mục vai trò dài mà nhân viên không biết khi nào chọn.
Quyền xem dữ liệu không nên tự cấp chỉ vì có liên kết. Một bản ghi có quan hệ với học viên là dữ kiện; ai được đọc điểm, sửa thông tin hoặc nhận tài liệu là quyết định phân quyền khác. Nếu thay người liên hệ, cần cập nhật đúng quyền theo quy trình thay vì chỉ đổi dòng tên hiển thị.
Cũng không nên sao chép ngày sinh, thông tin sức khỏe hoặc kết quả học tập vào hồ sơ người trả tiền để tiện tìm kiếm. Điều đó làm tăng dữ liệu phải bảo vệ và có thể khiến thông tin của hai học viên bị trộn. Hồ sơ từng người nên là nguồn chính cho dữ liệu thuộc người đó.
Một giao dịch cần đối chiếu được nhiều dòng ghi danh
Website cần thể hiện khoản thanh toán gắn với những dòng đăng ký nào và kết quả xử lý của từng dòng. Nếu một lớp còn chỗ còn lớp kia hết chỗ, không thể chỉ trả về một chữ “thành công” rồi để nhân viên giải thích sau. Cách xử lý có thể là kiểm tra đủ tất cả trước khi chốt hoặc cho phép kết quả một phần theo chính sách rõ ràng.
Ví dụ đơn gồm ghi danh A và B. A đã được xác nhận, B đang chờ lớp. Người dùng cần biết trạng thái này trước khi thực hiện bước tiếp theo. Không nên đổi tên người trả tiền thành A để biến cả đơn thành ghi danh A, cũng không tự tạo một lớp tạm cho B nếu trung tâm chưa có quy trình.
Bản ghi đối chiếu nên giữ mã đơn, mã giao dịch được hỗ trợ, danh sách dòng ghi danh và phần giá trị hoặc quyền liên quan theo mô hình hệ thống. Bài viết không đề xuất công thức phân bổ kế toán; nó yêu cầu dữ liệu đủ để biết một cập nhật đang tác động tới dòng nào. Đội tài chính quyết định nghiệp vụ tiền và chứng từ trong phạm vi của họ.
Associations API của HubSpot minh họa thao tác liên kết theo định danh bản ghi. Trong tích hợp học vụ, phải đọc lại đúng hai đầu quan hệ sau khi ghi. Phản hồi tạo hồ sơ thành công không chứng minh đã gắn đúng người trả tiền với cả hai ghi danh.
Khi cổng thanh toán gửi thông báo lại hoặc người dùng bấm gửi lần nữa sau timeout, hệ thống không được tạo thêm hai ghi danh mới. Việc chống trùng cần nhận diện giao dịch và các dòng đăng ký đã có, đồng thời cho phép một người mua thêm khóa học hợp lệ sau này. Chặn mọi đơn có cùng email là giải pháp quá thô.
Đổi một dòng không được làm thay đổi dòng còn lại
Nếu A chuyển lớp, ghi danh B phải giữ nguyên. Nếu B nghỉ theo chính sách, không xóa hồ sơ P hoặc liên kết của P với A. Nếu chỉ một phần cần điều chỉnh tiền, tác động phải được đối chiếu đến đúng dòng và quy trình tài chính có thẩm quyền. Cờ trạng thái của cả đơn không thay được lịch sử từng ghi danh.
Trung tâm cũng có thể đổi người thanh toán ở lần mua sau. Điều đó không nhất thiết chuyển quyền nhận kết quả học tập sang người mới. Cần tách cập nhật dữ liệu liên hệ, cập nhật quan hệ thanh toán và cập nhật quyền truy cập. Ba thao tác cùng xảy ra trong một cuộc gọi không làm chúng thành một dữ kiện duy nhất.
Màn hình cho gia đình nên trình bày theo người học và khóa học, với phần tổng quan người thanh toán khi cần. Không nên buộc phụ huynh dùng hai tài khoản chỉ vì có hai con nếu mô hình cho phép quản lý hộ, nhưng cũng không dùng một tài khoản dùng chung để bỏ qua kiểm tra quyền với từng hồ sơ.
Một danh sách nghiệm thu ngắn có thể bắt đầu từ hai học viên cùng người trả tiền; sau đó thử cùng học viên học hai chương trình; hai người cùng tham gia thanh toán cho một người học; đổi liên hệ; và một dòng đăng ký thất bại. Các kết quả cần được mô tả trước khi thử, vì mỗi trung tâm có chính sách khác nhau.
Kiểm tra thêm gửi lại callback, sửa tên phụ huynh, hủy một dòng và truy cập bằng người không có quyền. Đừng tạo dữ liệu gia đình thật để thử gửi nhầm thông báo. Dữ liệu giả lập đủ để chứng minh quan hệ và phạm vi cập nhật, miễn các bước đọc lại được thực hiện trên đúng đối tượng.
Nếu bạn cần xây website đăng ký học có tích hợp CRM, hãy bắt đầu bằng sơ đồ một người thanh toán cho hai người học và các tình huống thay đổi thực tế. Giá: Liên hệ. Nhận tư vấn & báo giá theo cấu trúc dữ liệu, quyền và điểm đối chiếu, không cần cung cấp dữ liệu trẻ em thật ở bước trao đổi đầu tiên.
