---
title: "Phần mềm quản lý công ty du học của bạn có thực sự chuyển tiền không? Khoảng trống giữa lưu hồ sơ và thanh toán"
description: "Tôi từng xây một phần mềm quản lý công ty du học, rồi bán nó đi. Vì sao 'tất cả trong một' là một cái bẫy, và điều duy nhất mọi CRM chưa bao giờ được sinh ra để làm: thực sự chuyển tiền của bạn."
date: "2026-02-07"
category: "Chiến lược kinh doanh"
keywords: "Chiến lược kinh doanh"
author: "Raphael Arias"
cover: "/images/blog/blog-education-agency-management-system-payments-gap.jpg"
lang: "vi"
wordCount: 7104
url: https://qualyhq.com/vi/blog/phan-mem-quan-ly-du-hoc-khoang-trong-thanh-toan
---
## Site navigation

- [Cho trường học](/vi/giao-duc-quoc-te/cho-truong-hoc.md) — Dành cho các trường có sinh viên quốc tế
- [Cho đại lý](/vi/giao-duc-quoc-te/cho-dai-ly.md) — Dành cho các đại lý giáo dục
- [Bảng giá](/vi/bang-gia)
- [Demo 5 phút](/vi/demo.md) — Video demo 5 phút
- [Đăng nhập](https://dashboard.qualyhq.com)

# Phần mềm quản lý công ty du học của bạn có thực sự chuyển tiền không? Khoảng trống giữa lưu hồ sơ và thanh toán

> Tôi từng xây một phần mềm quản lý công ty du học, rồi bán nó đi. Vì sao 'tất cả trong một' là một cái bẫy, và điều duy nhất mọi CRM chưa bao giờ được sinh ra để làm: thực sự chuyển tiền của bạn.

Một phần mềm quản lý công ty du học theo dõi dòng tiền: học viên, cách tính hoa hồng, hóa đơn, trạng thái thanh toán. Nhưng nó không chuyển tiền — nó không thu học phí từ học viên bằng một loại tiền tệ, cũng không trả cho trường bằng một loại tiền tệ khác. Chính khoảng trống đó, giữa phần mềm biết bạn được nợ bao nhiêu và một hệ thống thanh toán thực sự chuyển được số tiền ấy, là nơi các công ty du học vẫn tiếp tục thất thoát tiền trong năm 2026.

Tôi từng sáng lập một phần mềm quản lý công ty du học. Nó tên là EducationLink, tôi xây nó cho các công ty tư vấn du học quốc tế, và năm 2020 tôi bán nó cho Edvisor. Vậy nên khi tôi nói cho bạn biết những hệ thống này làm được và không làm được gì, tôi không đọc lại website của đối thủ — tôi đang kể cho bạn nghe điều tôi đã thiết kế phần mềm của mình để làm, và điều duy nhất tôi bỏ ngỏ, bởi vì vào thời điểm đó gần như không ai xây được nó.

Điều tôi bỏ ngỏ là thế này: **phần mềm chưa bao giờ thực sự chuyển đồng nào cả.** Nó tính hoa hồng chính xác đến từng đồng. Nó xuất hóa đơn. Nó cho bạn biết, đến từng xu, trường nợ bạn bao nhiêu và học viên nợ trường bao nhiêu. Rồi nó dừng lại — bởi vì bản thân số tiền vẫn phải bò qua tài khoản ngân hàng của bạn, qua chênh lệch tỷ giá, và qua chu kỳ thanh toán của trường. Hồ sơ thì sạch sẽ hoàn hảo. Còn việc chuyển tiền vẫn là một lệnh điện chuyển tiền quốc tế kèm một lời cầu nguyện.

Đây là sự phân biệt mà gần như không ai trong ngành gọi thẳng tên, và nó lại là thứ tốn kém nhất: khác biệt giữa **phần mềm theo dõi tiền của bạn** và **hệ thống thanh toán chuyển tiền của bạn**. Phần mềm quản lý của bạn là cái thứ nhất. Nó không phải, và chưa bao giờ được sinh ra để làm, cái thứ hai.

## Một CRM du học thực chất làm gì — và dừng lại ở đâu

Một CRM du học — EducationLink, Edvisor, [AMS](https://ams4you.com/), [Ally](/allyhub.md), cả tá cái khác — là phần mềm có nhiệm vụ giữ sự thật về học viên, hồ sơ, thỏa thuận và hoa hồng của bạn, để con số đúng nằm ở đúng cột. Nhiệm vụ đó là có thật và đáng để trả tiền. Những phần mềm hiện đại làm việc này rất tốt. Chẳng hạn, [chính module kế toán của EducationLink](https://geteducation.link/education-agents/) bao trùm quản lý thỏa thuận, tính hoa hồng, xuất hóa đơn, theo dõi thanh toán của học viên, hoàn tiền và chia hoa hồng cho đại lý phụ. Trên giấy tờ, danh sách tính năng đó đọc lên như thể "thanh toán đã được lo xong".

Chưa xong đâu. Hãy đọc lại danh sách tính năng đó với một câu hỏi duy nhất: **từ nào trong số đó chuyển được dù chỉ một đồng qua biên giới?** Không từ nào cả. "Tính hoa hồng" là phép tính số học. "Xuất hóa đơn" là một file PDF. "Theo dõi thanh toán của học viên" là một trường trạng thái bạn cập nhật *sau khi* tiền đã về qua một kênh nào đó khác. CRM ghi nhận rằng một khoản thanh toán đã xảy ra; nó không làm cho khoản đó xảy ra. **CRM của bạn nói cho bạn sự thật về số tiền được chuyển ở chỗ khác.**

Cách rõ ràng nhất để nhìn thấy khoảng trống này là đi theo một học viên đi xuyên qua nó. CRM nói cho bạn biết học viên nợ trường 12.000 AUD và bạn sẽ nhận hoa hồng 25%. Tuyệt vời. Bây giờ: học viên đang ở São Paulo với đồng real, trường ở Melbourne, bạn là công ty du học đứng giữa, và hoa hồng của bạn phải được tách ra rồi trả về cho bạn nhiều tuần sau đó. CRM của bạn có quan điểm về mọi con số trong câu đó và không hề can dự gì vào ba lần đổi tiền, hai lần chuyển khoản và một lần đối soát mà câu ấy thực sự đòi hỏi. Đó không phải là lỗi của phần mềm. Đó là ranh giới của những gì *loại* phần mềm đó được sinh ra để chạm tới.

## Theo dõi tiền so với chuyển tiền

Sự phân biệt này đáng được gọi tên, bởi vì gọi tên nó chính là cách bạn bắt đầu đánh giá phần mềm một cách trung thực. **CRM của bạn theo dõi tiền. Một hệ thống thanh toán chuyển tiền.** Theo dõi nghĩa là ghi nhận nghĩa vụ: được nợ, đã xuất hóa đơn, đã trả, đã chia. Chuyển nghĩa là làm việc thật: thu từ học viên, đổi tiền tệ, trả cho trường, hoàn lại tiền. Đa số CRM du học theo dõi rất đẹp và không chuyển gì cả — việc chuyển tiền được lặng lẽ đẩy ra ngoài cho ngân hàng của bạn, và cho bất cứ cách nào học viên tự xoay xở ở đầu bên kia.

Điều này quan trọng vì hai việc có kiểu thất bại hoàn toàn khác nhau, và những hồ sơ gọn gàng của CRM che giấu mớ hỗn độn trong việc chuyển tiền. Một CRM tốt sẽ nói cho bạn, một cách chính xác, rằng một khoản hoa hồng đã quá hạn 47 ngày. Nó sẽ không nói cho bạn biết rằng bạn mất 4% khoản đó vào chênh lệch tỷ giá lúc tiền vào, thêm một khoản phí cố định lúc tiền ra, và rằng "12.000 AUD" mà trường nhận được thực ra chỉ còn 11.300 AUD sau khi một ngân hàng trung gian cắt phần của nó — để lại cho bạn phải đi đòi một khoản hụt mà hồ sơ khăng khăng là không nên tồn tại. Con số trong CRM và con số trong tài khoản ngân hàng trôi dạt khỏi nhau, và việc khớp lại chúng là công việc mất một ngày mỗi tháng mà không ai dự trù. (Tôi đã viết bản đồng hành về mặt vận hành cho bài này — [năm câu hỏi chốt sổ hằng tháng để đối soát CRM với ngân hàng](/blog/education-agency-crm-payments-reconciliation.md) — nếu bạn muốn công việc đó dưới dạng một danh sách kiểm tra.)

Để đặt một con số lên đó: một công ty du học luân chuyển khoảng **2 triệu AUD tiền của học viên mỗi năm** — mức khiêm tốn, vài trăm học viên — bị chảy máu 4% chênh lệch tỷ giá lúc tiền vào cùng một khoản phí điện chuyển tiền cố định trên mỗi lần chi ra thì đang mất **cỡ khoảng 80.000 AUD mỗi năm** vào việc chuyển tiền mà họ không nhìn thấy, trước cả khi có ai đó trễ hạn hay tính sai. Đó không phải sai số làm tròn; ở mức biên lợi nhuận điển hình của một công ty du học, nó có thể là ranh giới giữa tuyển thêm người và không tuyển. Tôi đã từng viết về [những chi phí ẩn của thanh toán giáo dục quốc tế](/blog/hidden-costs-international-payments-education.md) — những khoản chênh lệch và phí trung gian nằm *bên trong* tỷ giá chứ không nằm trên bất kỳ hóa đơn nào. Khoảng trống giữa lưu hồ sơ và thanh toán chính là lý do những chi phí đó vẫn ẩn: CRM của bạn không có tầm nhìn nào vào việc chuyển tiền, nên nó không thể chỉ cho bạn một chỗ rò rỉ mà nó chưa bao giờ được sinh ra để thấy. *(Con số 80.000 AUD kia là một minh họa dựa trên các giả định đã nêu, không phải một con số được báo giá — hãy chạy nó trên khối lượng của riêng bạn và chênh lệch tỷ giá của chính ngân hàng bạn.)*

## Chuyện này không mới — cứ hỏi bất kỳ đại lý du lịch nào

Nếu chuỗi sự việc này nghe quen tai, thì đúng là nó phải quen. Nó đã xảy ra rồi với một ngành trung gian ăn hoa hồng khác: các đại lý du lịch.

Suốt nhiều thập kỷ, phần mềm của đại lý du lịch là GDS — Sabre, Amadeus, Galileo — cái màn hình biết mọi mức giá vé, mọi đơn đặt chỗ, mọi khoản hoa hồng. GDS theo dõi tất cả. Nhưng nó không *chuyển* gì cả; tiền đi qua một cơ chế thanh toán bù trừ ngân hàng riêng, cồng kềnh — hệ thống thanh toán bù trừ BSP của ngành hàng không — và qua chính chu kỳ thanh toán của các hãng bay. (Sự chia cắt đó, và [vì sao ngành giáo dục quốc tế xây được nửa GDS nhưng chưa bao giờ xây nửa thanh toán bù trừ](/blog/why-international-education-has-no-gds-settlement-layer.md), chính là toàn bộ câu chuyện về cái lớp còn thiếu.) Rồi hai chuyện xảy ra nối tiếp nhau. Đầu tiên các hãng bay cắt hoa hồng về gần bằng không, siết biên lợi nhuận của đại lý cho tới khi từng đồng rò rỉ đều đáng kể. Rồi các fintech — những chuyên gia thanh toán — tiến vào bên dưới GDS và giành lấy quyền sở hữu số tiền mà GDS chưa bao giờ thực sự chuyển, bởi vì đó là nơi phần biên lợi nhuận có thể thu hồi đang ẩn náu.

Phép so sánh này không hoàn hảo, và cũng nên thành thật về chỗ nó gãy: các hãng bay *chủ động* cắt phăng hoa hồng của đại lý vì internet cho phép họ bán trực tiếp, trong khi các trường không dễ gì bỏ qua công ty du học — kênh đại lý mới là cách sinh viên quốc tế thực sự được tuyển, nên một cú sụp hoa hồng ở quy mô như hàng không là khó xảy ra. Nhưng bạn không cần cú sụp để bài học vẫn đúng. Bạn chỉ cần *cú siết*, và cú siết đã ở đây rồi: Úc đã [siết chặt quy định về hoa hồng đại lý đối với chuyển trường trong nước](https://thepienews.com/australia-tightens-agent-commission-rules-for-onshore-transfers/) theo các cải cách về liêm chính năm 2025 của họ, và ngành giảng dạy tiếng Anh đang công khai lo lắng về [chuyện hoa hồng leo thang](https://thepienews.com/commission-creep-elt-sector-concerns-rise-over-agent-costs/). Khi biên lợi nhuận còn dày, bạn không để ý việc chuyển tiền tốn của bạn bao nhiêu. Khi các cơ quan quản lý và các đối tác bắt đầu nén hoa hồng của bạn, **mỗi đồng mất đi trong lúc chuyển tiền đều trừ thẳng vào một biên lợi nhuận mà bạn không còn đủ khả năng để rò rỉ.** Đây là cược có thể chứng minh sai của tôi cho hai đến ba năm tới: các CRM du học sẽ hoặc xây hệ thống thanh toán thực sự vào trong sản phẩm, hoặc nhường tiền lại cho các nhà cung cấp thanh toán chuyên biệt — y hệt như các GDS đã làm. Hồ sơ tốt tự thân sẽ hết đủ dùng ngay khoảnh khắc biên lợi nhuận mỏng đi.

## Cách tự kiểm toán CRM của bạn: theo dõi so với chuyển

Bạn không cần phải tin lời tôi về bất kỳ điều nào trong đây. Hãy lấy CRM du học hiện tại của bạn và cho từng tác vụ tiền tệ chạy qua một câu hỏi: **phần mềm có làm việc này, hay nó chỉ bảo tôi đi làm việc này ở nơi khác?** Đây là bản đồ trung thực cho một bộ công cụ điển hình của một công ty du học.

| Tác vụ tiền tệ | CRM du học của bạn | Một hệ thống thanh toán thực sự |
| --- | --- | --- |
| Tính hoa hồng được nợ | Có — đây là chức năng cốt lõi | Không phải việc của nó |
| Xuất hóa đơn | Có | Không phải việc của nó |
| Thu học phí từ học viên | Không — chỉ ghi nhận sau khi tiền về | Có — phương thức thanh toán nội địa, bằng đồng tiền của học viên |
| Đổi tiền tệ | Không — xảy ra tại ngân hàng của bạn | Có — theo một mức phí phẳng, được công bố rõ ràng |
| Trả cho trường số tiền ròng | Không — bạn làm việc này thủ công | Có — tự động, tức thời |
| Chia và trả cho đại lý phụ/tư vấn viên | Thường tính ra phần chia; đa số không chuyển tiền cho các thương vụ của chính bạn | Có — thực thi việc chi trả |
| Xử lý hoàn tiền xuyên biên giới | Ghi nhận khoản hoàn; không chuyển nó | Có — trả tiền về theo đúng đường nó đã đến |
| Đối soát ngân hàng với hồ sơ của bạn | Không — công việc thủ công một ngày mỗi tháng | Có — tự đối soát, vì nó đã chuyển tiền |

*"Không" ở đây nghĩa là CRM ghi nhận hoặc chỉ dẫn, nhưng bản thân số tiền được chuyển qua một kênh khác — thường là ngân hàng của bạn. Dòng đại lý phụ là điểm tinh tế đáng để bạn tự kiểm chứng: một số nền tảng (Ally chẳng hạn) có chuyển tiền bên trong thị trường riêng của họ, nhưng điều đó khác với việc thu và chia học phí trên các thỏa thuận trực tiếp của chính bạn với trường. Đã kiểm chứng tháng 6/2026 dựa trên mô tả công bố của các nhà cung cấp; hãy xem đây là bản đồ theo loại, không phải một báo giá theo từng sản phẩm, và hãy kiểm tra hợp đồng của chính bạn.*

Chính cái khuôn mẫu ấy mới là điểm mấu chốt. Mọi thứ ở nửa "tính và ghi nhận" trong hành trình của một học viên, CRM của bạn làm tốt. Mọi thứ ở nửa "thực sự chuyển tiền", nó trả ngược lại cho bạn. Nếu bạn từng thắc mắc vì sao mình mua phần mềm tinh vi mà vẫn dành tuần cuối mỗi tháng để khớp bằng tay các thông báo chuyển tiền với sao kê ngân hàng — thì đó chính là ranh giới. Bạn đã mua công cụ ghi sổ. Còn chuyển tiền thì vẫn là bạn.

Tôi đã vạch cùng ranh giới này, một cách thẳng thừng hơn, khi tôi lập luận rằng [đa số công ty du học nhỏ chưa nên mua CRM vội](/blog/should-small-education-agencies-invest-in-crm-payment-systems.md): những triệu chứng cuối cùng biện minh cho việc mua phần mềm — chia phần cho đại lý phụ, đa tiền tệ, đối soát ngốn hết ngày, bỏ lỡ [khoản hoa hồng cần đòi](/blog/how-education-agent-commissions-work.md) — gần như tất cả đều là vấn đề *chuyển tiền*, chứ không phải vấn đề quản lý danh bạ. Và một CRM xịn hơn không sửa được vấn đề chuyển tiền.

Còn một lý do nữa khiến mặt chuyển tiền cắn đau hơn vẻ ngoài của nó: nó không chỉ là vấn đề của bạn. **Cách bạn chuyển tiền cũng chính là cách các đại lý phụ và tư vấn viên của bạn trải nghiệm việc làm việc với bạn.** Khi một khoản chia chạy qua ngân hàng của bạn bằng tay, đại lý phụ là người phải chờ, ăn một khoản cắt tỷ giá trên đường xuống, và không thể đối soát cái đã về với cái đã hứa — mà lòng tin của đại lý phụ chính là đường tiếp tế mà cả doanh nghiệp bạn dựa vào để vận hành. Một khoản chia trễ hay thiếu, với họ, không đọc thành "ngân hàng chậm"; nó đọc thành "công ty này khó lấy được tiền". Sửa cách tiền di chuyển, một cách lặng lẽ, là một quyết định giữ chân đối tác chẳng kém gì một quyết định về chi phí. (Các trường ở đầu chuỗi đối mặt với hình ảnh phản chiếu của điều này: [trả hoa hồng cho đại lý theo lịch thay vì bới ra từ một hộp giày đầy hóa đơn](/blog/how-schools-pay-education-agent-commission.md) giờ đây là một nghĩa vụ tuân thủ, không chỉ là phép lịch sự.)

## Bạn thực sự cần gì, theo quy mô công ty

Một khi bạn tách việc theo dõi tiền khỏi việc chuyển tiền, câu hỏi "tôi cần phần mềm nào" có được một câu trả lời gọn gàng hơn nhiều — bởi vì hai việc này lớn lên theo hai đường cong hoàn toàn khác nhau. **CRM thì bạn có thể trì hoãn; hệ thống thanh toán thì không.** Một bảng tính theo dõi tiền tốt trong một thời gian dài. Nhưng ứng biến việc chuyển tiền — điện chuyển ngân hàng, các app chuyển tiền cá nhân, học viên trả bằng bất cứ cách nào họ xoay được — là một sai lầm ngay từ học viên xuyên biên giới đầu tiên của bạn, vì đó là nơi thất thoát ngầm về tỷ giá và phí bắt đầu. Đây là bản đồ trung thực theo quy mô. (Toàn bộ lập luận về *khi nào* việc nâng cấp CRM là đáng nằm ở [bài viết có-nên-mua-CRM](/blog/should-small-education-agencies-invest-in-crm-payment-systems.md); đây là góc nhìn theo dõi-so-với-chuyển của cùng quyết định đó. Nếu bạn còn đang phân vân liệu có cần một hệ thống quản lý hay không, [hướng dẫn bảng-tính-so-với-CRM-so-với-tất-cả-trong-một](/blog/do-you-need-education-agency-management-system.md) đi qua từng nấc trưởng thành và các tín hiệu kích hoạt mua chính xác.)

| Quy mô công ty | Theo dõi tiền (CRM / hồ sơ) | Chuyển tiền (hệ thống thanh toán) |
| --- | --- | --- |
| Đơn lẻ / gia đình (≤50 học viên/năm, không có đại lý phụ) | Một bảng tính kỷ luật, một chủ, một tab hoa hồng | Cần từ học viên đầu tiên — một hệ thống thanh toán chuyên cho giáo dục, không bao giờ dùng điện chuyển ngân hàng |
| Nhỏ (≈50–150/năm, 1–2 điểm đến) | Bảng tính vẫn ổn; chỉ cần CRM nhẹ nếu quan hệ bắt đầu tuột | Không thể thương lượng — thất thoát đa tiền tệ và hoàn tiền đã có thật |
| Trung bình (≈5–50 nhân sự, có đại lý phụ, đa điểm đến) | Giờ hãy mua một CRM du học thực sự — Ally, AMS hoặc tương tự — chia phần và đối soát làm gãy một bảng tính | Điểm chịu áp lực: các khoản chia phải được *trả*, không chỉ được tính |
| Lớn / đại lý tổng (mạng lưới, rủi ro tuân thủ) | CRM du học đầy đủ, thường tích hợp với các nền tảng phía trường | Chuyển tiền ở quy mô lớn: chi trả tự động, đối soát sẵn sàng cho kiểm toán, báo cáo theo quy định |

*Bảng này lập bản đồ nhu cầu, không phải nhà cung cấp. "Cần" ở cột thanh toán nghĩa là việc chuyển tiền xuyên biên giới nên chạy trên một hệ thống thanh toán chuyên biệt ở quy mô đó; nó không có nghĩa bạn phải mua CRM nặng nhất. Đã kiểm chứng tháng 6/2026 dựa trên các ngưỡng trong bài viết quyết-định-CRM của chúng tôi; hãy xem các dải quy mô là chỉ dẫn mềm, không phải các mốc cứng.*

Đọc bảng từ trên xuống dưới và sự bất đối xứng chính là điểm cốt lõi: cột CRM leo thang chậm — bảng tính, rồi CRM nhẹ, rồi hệ thống đầy đủ — và bạn thực sự có thể chờ ở mỗi bước. Cột thanh toán nói "cần" ngay ở dòng đầu tiên và không bao giờ nới ra. **Gần như mọi công ty du học đều đầu tư quá sớm vào CRM và đầu tư quá muộn vào việc chuyển tiền.** Họ mua một CRM để thấy mình chuyên nghiệp rồi vẫn tiếp tục đẩy tiền qua ngân hàng để tiết kiệm một khoản phí — đúng ngược. Nếu CRM còn chưa cần đến, cũng không sao; một cách chuyển tiền an toàn thì vẫn cần.

Một phản biện hợp lý ở đây, nhất là từ ai đã đọc bài về CRM kia: thêm một hệ thống thanh toán chẳng phải là thêm một công cụ nữa để áp dụng, với đúng cái rủi ro áp-dụng-nửa-vời từng giết chết các đợt triển khai CRM sao? Thực tế thì không — và đây là khác biệt then chốt. **Một CRM chỉ hoạt động nếu nhân viên của bạn thay đổi thói quen và ghi lại mọi thứ; một hệ thống thanh toán hoạt động vì chính học viên làm phần việc đó.** Họ bấm vào một đường link và trả bằng đồng tiền của họ; số tiền, việc đổi tiền, việc trả cho trường và việc chia phần diễn ra ở phía bên kia mà đội của bạn không phải chạm vào. Không có kỷ luật hằng ngày nào phải duy trì, và đó chính xác là lý do chuyển tiền là thứ đầu tiên an toàn nhất nên sửa, chứ không phải thứ đáng sợ nhất.

## Một lời về EducationLink, vì tôi đã xây nó

Bạn có lý khi không tin một nhà sáng lập chỉ khen thứ mình đã bán, nên đây là phiên bản cân bằng. EducationLink là một CRM tốt và, theo những gì tôi quan sát được từ bên ngoài, chủ hiện tại của nó đang lái nó về phía hệ sinh thái Edvisor rộng hơn thay vì đầu tư vào việc quản lý du học sâu và phức tạp — vốn là thứ mà nhiều người dùng nặng ký của EducationLink thực sự dựa vào. *(Điểm cuối đó là nhận định của tôi với tư cách người sáng lập và từ việc trò chuyện với các công ty du học, không phải một thông báo có tài liệu của Edvisor — hãy kiểm chứng nó với chính tài khoản của bạn trước khi hành động.)* Nếu bạn là người dùng EducationLink đang cảm thấy sự trôi dạt đó, thì bản năng nhìn quanh là đúng.

Nhưng hãy để ý bản năng đó thường *sai* ở đâu. Người ta đi tìm một CRM tốt hơn — một pipeline mượt hơn, một bảng điều khiển gọn hơn — trong khi thứ thực sự đang làm họ đau lại là việc chuyển tiền. Bạn có thể đổi CRM ba lần và vẫn đang đổi tiền ở ngân hàng và trả cho trường bằng tay. Nước cờ thực sự có lời không nhất thiết là một CRM mới; nó là đặt một hệ thống thanh toán thực sự phía sau cái CRM bạn đang có. Qualy được xây để đứng cạnh CRM du học của bạn, kể cả EducationLink — có một [so sánh trực tiếp giữa Qualy và EducationLink](/compare/educationlink.md) nếu đó đúng là tình huống của bạn.

## Đừng săn tìm cái "tất cả trong một" nữa. Hãy mua đúng công cụ cho đúng việc.

Lời chào hàng gốc của EducationLink — và của mọi CRM đã cố đi theo nó — là *tất cả trong một*: một lần đăng nhập cho CRM, hồ sơ, kế toán và thanh toán, mọi thứ trong một cái hộp duy nhất. Đó là một lời hứa hấp dẫn, và nó có một lỗi cấu trúc mà vài năm qua đã khiến không thể phớt lờ: **khi một nhà cung cấp duy nhất sở hữu mọi chức năng, mọi chức năng di chuyển theo lộ trình của nhà cung cấp đó.** Khi cái hộp bị mua lại, bị định vị lại, hay đơn giản là hạ ưu tiên phần bạn phụ thuộc, bạn không mất một tính năng — bạn mất cả bộ cùng lúc, vì bạn đã gửi tất cả vào cùng một chỗ. "Tất cả trong một" là kiến trúc mong manh nhất tồn tại, chính *vì* nó gộp tất cả vào một. Cùng cái logic một-điểm-hỏng-hết ấy áp dụng cho kênh tuyển sinh của bạn: giao hết quan hệ với trường cho một nhà tổng hợp duy nhất là bạn đã gửi cả sổ sách của mình vào hộp của người khác — đó chính là lập luận trong [nhà tổng hợp so với thỏa thuận trực tiếp với trường](/blog/education-agent-aggregator-vs-direct-school-agreements.md).

Giải pháp bền vững lại là giải pháp buồn tẻ: **các công cụ tốt nhất trong hạng mục của chúng, tích hợp được với nhau.** Chọn CRM du học mạnh nhất ở thị trường của bạn và để nó xuất sắc ở việc theo dõi doanh nghiệp bạn. Hôm nay, nếu bạn muốn thứ gần nhất với một bộ suite quản lý du học đầy đủ, [Ally](/allyhub.md) (allyhub.co) có sự tương đương tính năng thực sự với những gì các "tất cả trong một" từng chào — và nó là chuẩn mực trên thực tế cho các công ty du học Brazil. Rồi chọn hệ thống thanh toán mạnh nhất ở việc chuyển tiền, và nối hai thứ lại. **Một công cụ tích hợp được với các công cụ khác sẽ sống sót qua việc mất bất kỳ công cụ nào trong số đó.** Một công cụ *là* tất cả các công cụ khác thì không thể.

Đây chính là kiến trúc mà Qualy được xây một cách có chủ đích. Nó [tích hợp gốc với Ally](/allyhub.md) — đồng bộ doanh số, thanh toán và hoa hồng — nên bạn có được *trải nghiệm* tất-cả-trong-một mà không có *rủi ro* tất-cả-trong-một. Và ở nơi không có kết nối gốc, có [một API công khai](/api.md) và [một tích hợp Zapier vươn tới hơn 7.000 ứng dụng](/zapier.md), để hệ thống thanh toán của bạn cắm vào bất kỳ CRM, bảng tính hay cổng tự dựng nào bạn thực sự đang chạy. Điểm cốt lõi không phải là Qualy làm mọi thứ. Điểm cốt lõi thì ngược lại: Qualy làm một việc — chuyển tiền — và kết nối với mọi thứ làm phần còn lại.

Và đây là câu tách bạch hai bên. Ally và các CRM mạnh khác sẽ theo dõi một khoản chia cho đại lý phụ, phần cắt của một tư vấn viên, một khoản hoa hồng đa tiền tệ một cách hoàn hảo. **Nhưng theo dõi một khoản chia không phải là trả nó** — thu tiền của học viên, tách ra và *trả* phần chia, gửi cho trường số tiền ròng qua biên giới. Việc thực thi đó là phần các CRM tính ra rồi trả ngược lại cho bạn, và nó là công việc cụ thể mà Qualy tồn tại để làm.

## Đóng khoảng trống thanh toán ở Việt Nam: đồng nội tệ ra, ngoại tệ về

Ở Việt Nam, phần "theo dõi tiền" trong lập luận này gần như không thay đổi — nhưng phần "chuyển tiền" thì mang một dáng vẻ rất cụ thể của địa phương, và chính chỗ đó cho thấy vì sao khoảng trống lại đau đến vậy. Hầu như mọi phụ huynh và học viên Việt Nam đều đã có sẵn công cụ để trả tiền tức thời: **chuyển khoản liên ngân hàng 24/7 qua Napas 247 với mã VietQR**, cùng các ví điện tử **MoMo, ZaloPay và VNPay**. Quét một mã QR, xác nhận trong app ngân hàng, tiền về trong vài giây — đây là chuẩn mực hằng ngày, chứ không phải một tính năng ngoại lai.

Vấn đề là: một CRM du học chung chung không thể *chạm* vào bất kỳ đường ray nào trong số đó. Nó không tạo ra được một mã VietQR động khớp đúng học phí, không kéo được tiền từ ví MoMo của học viên, không hòa giải được một khoản trả VNPay với hóa đơn nó đã xuất. Nó chỉ có một trường trạng thái để bạn đánh dấu "đã trả" *sau khi* việc thu tiền đã diễn ra ở đâu đó khác. Vậy nên trong thực tế, một tư vấn viên gửi số tài khoản ngân hàng qua Zalo, phụ huynh chuyển khoản Napas 247, và ai đó khớp bằng tay với hồ sơ trong CRM. Hồ sơ đẹp; việc thu tiền thì hoàn toàn nằm ngoài phần mềm.

### Vì sao đường ray nội địa lại là chỗ khoảng trống nằm

Khi học phí phải sang một trường ở Úc, Anh, Canada hay Mỹ, cây cầu mặc định là một lệnh điện chuyển tiền quốc tế bằng SWIFT — chậm, tốn phí cố định, và ăn một khoản chênh lệch tỷ giá ẩn bên trong tỷ giá quy đổi VND. Học viên mất khoản chênh đó lúc tiền ra; công ty du học mất khoản chênh thứ hai khi hoa hồng phải quay ngược về Việt Nam. CRM của bạn không nhìn thấy khoản nào cả — nó chỉ thấy con số học phí gốc và con số hoa hồng gốc, cả hai đều đúng trên giấy và cả hai đều không khớp với thứ thực sự về tài khoản.

Cách đóng khoảng trống là để **học viên trả bằng VND qua chính đường ray họ đã dùng — VietQR/Napas 247 hoặc ví điện tử — trong khi trường vẫn nhận đúng đồng tiền của mình.** Việc thu nội địa, việc quy đổi ở một mức phí phẳng được công bố, việc trả cho trường và việc tách hoa hồng cho công ty du học đều diễn ra ở phía hệ thống thanh toán, không phải trên bàn của tư vấn viên. Học viên không phải ra ngân hàng làm thủ tục chuyển tiền quốc tế; công ty du học không phải đi đòi một khoản hụt do một ngân hàng trung gian tạo ra.

### Điều này đổi gì cho một tư vấn viên ở Việt Nam

Sự khác biệt lớn nhất là mặt vận hành: thay vì gửi số tài khoản qua Zalo rồi khớp sao kê bằng tay vào cuối tháng, mỗi khoản trả gắn với đúng học viên và đúng đợt học phí ngay từ lúc quét mã. Với các gói **trả góp** trải qua ngày lên đường và thường có hơn một người trả — phụ huynh trả tiền cọc, học viên trả phần còn lại — mỗi đợt có mã VietQR riêng và lời nhắc riêng bằng tiếng Việt. Và vì hệ thống vừa ghi nhận vừa chuyển tiền, nó tự đối soát: con số trong hồ sơ và con số về tài khoản không còn trôi dạt khỏi nhau. Nếu bạn muốn xem cụ thể việc này khớp với quy trình của công ty bạn ra sao, [hãy liên hệ với chúng tôi](/vi/lien-he.md) hoặc [đặt một buổi demo](/vi/demo.md).

## Lời sửa là một hệ thống thanh toán, không phải một CRM tốt hơn

Vậy đây là chỗ tôi đặt lời chào hàng duy nhất mà bài này có. Cái khoảng trống tôi để lại trong EducationLink chính là khoảng trống Qualy được xây để đóng: nó không phải một CRM và cũng không muốn làm CRM. Nó là **hệ thống thanh toán** đứng phía sau bất kỳ CRM nào bạn đang chạy — học viên trả bằng đồng tiền của họ qua [các phương thức thanh toán nội địa](/features/payment-methods-for-students.md), trường nhận đúng số tiền ròng sạch sẽ [một cách tự động](/features/automatic-accounting-for-ed-agents.md), [các khoản chia cho đại lý phụ và tư vấn viên](/features/master-and-sub-agent-payments.md) được *trả ra*, không chỉ được tính, và cả guồng máy tự đối soát bởi vì hệ thống ghi nhận khoản thanh toán chính là hệ thống *đã thực hiện* nó. Chi phí là một khoản phí phẳng trên mỗi giao dịch, được công bố rõ từ đầu, thay vì một tỷ lệ phần trăm ẩn bên trong tỷ giá.

Cứ giữ CRM của bạn. EducationLink, Ally, AMS, một bảng tính kỷ luật — bất cứ thứ gì theo dõi doanh nghiệp bạn. Chỉ cần đừng để "chuyển tiền" đồng nghĩa với ngân hàng của bạn cộng một lời cầu nguyện. CRM của bạn nói cho bạn biết bạn được nợ bao nhiêu. Hãy chắc rằng có một thứ gì đó thực sự đi và lấy về số tiền ấy.

## Nguồn

- [Edvisor mua lại EducationLink](https://blog.edvisor.io/edvisor-acquires-educationlink): thương vụ mua lại EducationLink của Edvisor năm 2020, nêu tên Raphael Arias là nhà sáng lập kiêm CEO của EducationLink.
- [The PIE News — Edvisor mở rộng mạng lưới công ty du học với thương vụ EducationLink](https://thepienews.com/edvisor-expands-agency-network-with-educationlink-acquisition/): bài đưa tin độc lập của báo ngành về cùng thương vụ và quy mô mạng lưới của EducationLink.
- [EducationLink](https://geteducation.link/education-agents/): phần mô tả của chính sản phẩm về năng lực CRM, quản lý học viên và kế toán (tính hoa hồng, xuất hóa đơn, thanh toán của học viên, hoàn tiền, đại lý phụ).
- [The PIE News — Úc siết chặt quy định về hoa hồng đại lý đối với chuyển trường trong nước](https://thepienews.com/australia-tightens-agent-commission-rules-for-onshore-transfers/): bối cảnh cải cách liêm chính năm 2025 cho cú siết hoa hồng.
- [The PIE News — Hoa hồng leo thang: ngành ELT lo lắng về chi phí đại lý tăng](https://thepienews.com/commission-creep-elt-sector-concerns-rise-over-agent-costs/): mối lo của ngành về chi phí hoa hồng đại lý đang tăng.
- [The PIE News — "Chỉ 60% các cơ sở của chúng tôi trả đúng hạn"](https://thepienews.com/only-60-of-our-institutions-pay-on-time/): lời kể của các đại lý về việc trả trễ và không trả của các cơ sở đối tác, minh họa vấn đề chu kỳ thanh toán bù trừ.

## Câu hỏi thường gặp

### Một CRM du học có xử lý thanh toán quốc tế không?

Không theo nghĩa mà đa số người ta hình dung. Một CRM du học như EducationLink, Edvisor hay Ally tính hoa hồng, xuất hóa đơn và theo dõi trạng thái thanh toán. Nó không thu học phí bằng đồng tiền của học viên, không đổi tiền, cũng không gửi số tiền ròng cho trường — việc chuyển đó vẫn diễn ra qua ngân hàng của bạn. CRM theo dõi tiền; nó không chuyển tiền. Một hệ thống thanh toán riêng mới làm việc chuyển.

### Khác biệt giữa theo dõi tiền và chuyển tiền trong phần mềm du học là gì?

Theo dõi tiền là việc CRM của bạn làm: nó giữ sự thật về học viên, thỏa thuận và hoa hồng — cái gì được nợ, đã xuất hóa đơn, đã trả và đã chia. Chuyển tiền là việc của một hệ thống thanh toán: thu từ học viên, đổi tiền tệ, trả cho trường và hoàn lại tiền. Đa số phần mềm du học theo dõi rất đẹp và không chuyển gì cả, để lại việc chuyển tiền thực sự cho ngân hàng của bạn.

### EducationLink có xử lý thanh toán cho các công ty du học không?

EducationLink có một module kế toán — tính hoa hồng, xuất hóa đơn, theo dõi thanh toán của học viên, hoàn tiền và chia cho đại lý phụ. Nhưng đó là các chức năng ghi sổ: phép tính, tài liệu và trường trạng thái. Việc thu tiền xuyên biên giới từ học viên và trả tiền cho trường xảy ra bên ngoài phần mềm, qua ngân hàng của bạn. Một hệ thống thanh toán chuyên biệt có thể đứng cạnh EducationLink để làm phần nó không làm.

### Vì sao tôi vẫn phải đối soát thanh toán bằng tay dù phần mềm đã theo dõi chúng?

Bởi vì phần mềm của bạn theo dõi tiền nhưng không chuyển tiền. Nó ghi nhận các số tiền nó kỳ vọng, nhưng tiền đi qua một kênh riêng — ngân hàng của bạn — nơi áp các khoản chênh lệch tỷ giá và phí trung gian mà CRM không nhìn thấy. Con số được ghi và con số về tài khoản trôi dạt khỏi nhau, và khớp chúng lại là công việc thủ công một ngày mỗi tháng. Một hệ thống thanh toán tự đối soát vì nó vừa ghi nhận vừa chuyển khoản thanh toán.

### Tôi là người dùng EducationLink đang lo về sản phẩm. Tôi nên làm gì?

Trước hết, hãy tách hai vấn đề. Nếu bạn cần một CRM tốt hơn — pipeline, hồ sơ, tài liệu — thì đó là một quyết định. Nhưng nếu nỗi đau của bạn là thu tiền xuyên biên giới, thất thoát tỷ giá, trả tiền cho trường bằng tay hay chia phần cho đại lý phụ, thì đó là vấn đề chuyển tiền, và đổi CRM sẽ không sửa được nó. Bạn có thể giữ CRM và đặt một hệ thống thanh toán phía sau nó.

### Chuyện gì đã xảy ra với các đại lý du lịch có liên quan đến các công ty du học?

Các đại lý du lịch chạy trên hệ thống GDS (Sabre, Amadeus) ghi lại mọi mức giá vé và hoa hồng nhưng chưa bao giờ chuyển tiền. Khi các hãng bay cắt hoa hồng, biên lợi nhuận bị siết khiến từng đồng rò rỉ đều đáng kể, và các fintech chuyên về thanh toán giành lấy việc chuyển tiền mà GDS chưa bao giờ sở hữu. Các công ty du học đối mặt với cú siết, không phải cú sụp — trường không thể bỏ qua đại lý như hãng bay đã bỏ qua họ — nhưng bài học về nơi biên lợi nhuận rò rỉ vẫn đúng.

### Qualy có thay thế CRM du học của tôi không?

Không. Qualy cố ý không phải một CRM. Nó là hệ thống thanh toán đứng sau CRM hiện có của bạn — EducationLink, Edvisor, Ally, AMS hay một bảng tính — và lo phần chuyển tiền mà chúng chỉ theo dõi: thu từ học viên bằng tiền nội địa, trả cho trường số tiền ròng một cách tự động, chi ra các khoản chia cho đại lý phụ và tư vấn viên, và tự đối soát. Bạn giữ CRM; Qualy chuyển tiền.

### Một công ty du học cần phần mềm gì theo quy mô?

Tùy vào việc bạn muốn nói đến công việc nào. CRM lớn lên chậm: một công ty đơn lẻ hoặc nhỏ dưới ~150 học viên mỗi năm chạy tốt trên một bảng tính kỷ luật, một công ty trung bình có đại lý phụ và nhiều điểm đến cần một CRM du học thực sự như Ally hay AMS, và các công ty lớn cần một bộ suite đầy đủ. Chuyển tiền thì khác — một hệ thống thanh toán chuyên biệt cần có từ học viên xuyên biên giới đầu tiên, ở mọi quy mô. Bạn có thể trì hoãn CRM; bạn không thể ứng biến việc chuyển tiền.

### Nền tảng tất-cả-trong-một có tốt hơn các công cụ riêng tích hợp với nhau không?

Tất-cả-trong-một thì tiện nhưng mong manh về cấu trúc: khi một nhà cung cấp sở hữu chung CRM, kế toán và thanh toán, một thương vụ mua lại hay một thay đổi lộ trình có thể làm dịch chuyển cả bộ của bạn cùng lúc. Các công cụ tốt nhất trong hạng mục mà tích hợp được thì bền hơn — bạn chọn CRM mạnh nhất cho thị trường của mình và hệ thống thanh toán mạnh nhất, rồi nối chúng lại. Một công cụ tích hợp với công cụ khác sống sót qua việc mất bất kỳ cái nào; một công cụ là tất cả các cái khác thì không.

### Qualy có tích hợp với Ally và các phần mềm du học khác không?

Có. Qualy tích hợp gốc với Ally (allyhub.co), đồng bộ doanh số, thanh toán và hoa hồng, để các công ty du học Brazil và những nơi khác có trải nghiệm tất-cả-trong-một mà không có rủi ro tất-cả-trong-một. Ở nơi không có kết nối gốc, Qualy có một API công khai và một tích hợp Zapier vươn tới hàng nghìn ứng dụng, để hệ thống thanh toán cắm vào bất kỳ CRM, bảng tính hay cổng tự dựng nào bạn đang chạy. Qualy làm một việc — chuyển tiền — và kết nối với các công cụ làm phần còn lại.

### CRM của tôi đã tính các khoản chia cho đại lý phụ — vì sao tôi cần một hệ thống thanh toán riêng?

Tính một khoản chia và trả nó là hai việc khác nhau. Một CRM du học mạnh sẽ theo dõi một khoản hoa hồng cho đại lý phụ hay tư vấn viên hoàn hảo. Nhưng thực thi nó — thu tiền của học viên, tách ra khoản chia, trả cho từng bên và gửi cho trường số tiền ròng qua biên giới — là chuyển tiền, không phải ghi sổ. Một số nền tảng chuyển tiền bên trong thị trường riêng của họ, nhưng điều đó khác với việc thanh toán cho các thương vụ trực tiếp của chính bạn với trường. Việc thực thi đó là phần Qualy được xây để làm.

### Học viên và phụ huynh Việt Nam có thể trả học phí qua VietQR hoặc ví điện tử không?

Có — và đó chính là điểm mấu chốt. Với một hệ thống thanh toán chuyên biệt đứng sau CRM của bạn, học viên trả bằng VND qua đúng đường ray họ đã dùng hằng ngày: chuyển khoản Napas 247 với mã VietQR, hoặc ví như MoMo, ZaloPay, VNPay. Việc thu, quy đổi và trả cho trường bằng đồng tiền của trường diễn ra ở phía hệ thống. Một CRM chung chung không thể tự kéo tiền qua VietQR hay ví — nó chỉ ghi nhận sau khi tiền đã về.

### Vì sao trả bằng VND tại chỗ lại tốt hơn chuyển tiền quốc tế bằng SWIFT?

Một lệnh chuyển tiền quốc tế bằng SWIFT tính một khoản phí cố định và ăn một khoản chênh lệch tỷ giá ẩn bên trong tỷ giá quy đổi VND, và học viên còn phải làm thủ tục ở ngân hàng. Khi học viên trả bằng VND qua VietQR hay ví điện tử còn trường vẫn nhận đúng đồng tiền của mình, việc quy đổi diễn ra ở một mức phí phẳng được công bố, không có ngân hàng trung gian cắt phần dọc đường, và hoa hồng của công ty du học được tách ra rồi trả về mà không cần một lệnh chuyển quốc tế thứ hai.

## Related articles

- [Should small education agencies invest in a CRM and payment system? Mostly, no.](/blog/should-small-education-agencies-invest-in-crm-payment-systems.md)
- [How education agent commissions work: rates, gross vs net, and getting paid on time](/blog/how-education-agent-commissions-work.md)
- [The Hidden Costs of Payments in International Education: What You Need to Know](/blog/hidden-costs-international-payments-education.md)

## More on Qualy

**Lĩnh vực**

- [Cho trường học](/vi/giao-duc-quoc-te/cho-truong-hoc.md) — Dành cho các trường có sinh viên quốc tế
- [Cho đại lý](/vi/giao-duc-quoc-te/cho-dai-ly.md) — Dành cho các đại lý giáo dục

**Hỗ trợ**

- [Trạng thái hệ thống](https://qualyhq.statuspage.io/) — Trạng thái hệ thống Qualy
- [Liên hệ](/vi/lien-he.md)

**Sản phẩm**

- [Demo](/vi/demo.md)
- [Ý kiến khách hàng](/vi/y-kien-khach-hang.md) — Xem khách hàng nói gì về Qualy
- [Trung tâm minh bạch](/vi/trung-tam-minh-bach.md)
- [API](/vi/api.md) — API Qualy cho thanh toán du học và đại lý giáo dục
- [Blog](/vi/blog) — Blog Qualy về thanh toán trong giáo dục quốc tế

**Pháp lý (bằng tiếng Anh)**

- [Điều khoản chung](/terms-and-conditions.md) — Điều khoản và Điều kiện
- [Điều khoản người thanh toán](/terms-for-payers.md) — Điều khoản cho người thanh toán