Stack trợ lý AI đặt lịch cho phòng khám nhỏ: xây và bán

Stack trợ lý AI đặt lịch cho phòng khám nhỏ - AIToEarn

Tín hiệu mở đầu: hạ tầng đặt lịch mã nguồn mở đang trưởng thành đủ để một builder Việt ghép thành sản phẩm bán được. Cal.com — dự án được mô tả là “scheduling infrastructure for absolutely everyone”, tích luỹ hàng chục nghìn sao GitHub (con số ghi nhận ở mức tham khảo), viết bằng TypeScript/Next.js — là lõi lịch hẹn open-source phổ biến nhất hiện nay. Nhưng điểm đáng chú ý với người muốn kiếm tiền không nằm ở số sao, mà ở giấy phép: Cal.com chuyển sang AGPLv3 từ năm 2022, tách riêng một Enterprise Edition thương mại, và gần đây còn tách nhánh đóng nguồn Cal.diy. Ba tín hiệu này quyết định bạn được phép làm gì khi đóng gói một “trợ lý AI đặt lịch cho phòng khám nhỏ” để bán.

Bài này không dịch README và không hô hào. Mục tiêu là chỉ ra một stack triển khai cụ thể, phân tích license trung thực trước khi bàn tiền, rồi đóng khung ba hướng “xây gì · bán cho ai · validate” kèm ước lượng thời gian MVP và cạm bẫy thực tế cho thị trường phòng khám nhỏ ở Việt Nam.

Vì sao phòng khám nhỏ là ngách đáng làm

Phòng khám tư nhân, nha khoa, spa y tế, phòng khám da liễu — nhóm cơ sở 1–5 bác sĩ — có một nỗi đau rất cụ thể và đo được: lịch hẹn quản lý thủ công qua điện thoại và Zalo, lễ tân quá tải giờ cao điểm, và tỷ lệ bệnh nhân quên lịch (no-show) thường rơi vào khoảng 20–30% theo các khảo sát ngành y tế phổ biến (số tham khảo, dao động theo chuyên khoa). Mỗi ca no-show là một khung giờ trống không thể bán lại. Một trợ lý AI trực 24/7 nhận đặt lịch qua Zalo/website, tự xác nhận, tự nhắc trước 24 giờ và tự lấp chỗ trống từ danh sách chờ — đó là giá trị mà chủ phòng khám hiểu ngay và sẵn sàng trả phí hằng tháng.

Khác với các ngách phần mềm y tế lớn (bệnh án điện tử, HIS) vốn cần chứng nhận và bán cho bệnh viện, mảng đặt lịch cho cơ sở nhỏ có chu kỳ bán ngắn, người quyết định là chính chủ phòng khám, và rào cản kỹ thuật vừa sức một solo builder. Đây đúng tinh thần “ghép repo thành dịch vụ” mà chúng tôi mổ xẻ trong bài xây SaaS ngách từ một repo AI agent.

Phân tích license: bạn được self-host và bán tới đâu?

Đây là phần phải làm trước khi mơ doanh thu, vì nó chặn hoặc mở đường kinh doanh của bạn.

Phần lõi Cal.com — AGPLv3. Bạn hoàn toàn được self-host miễn phí và thậm chí được cung cấp dịch vụ trên nền nó. Nhưng AGPLv3 là copyleft “qua mạng”: nếu bạn sửa đổi mã nguồn Cal.com rồi cho khách dùng qua Internet (SaaS), bạn có nghĩa vụ công khai phần mã đã sửa cho chính người dùng dịch vụ đó. Nghĩa là bạn không thể lấy Cal.com, vá thêm tính năng độc quyền, rồi bán như “phần mềm đóng của riêng tôi” mà giấu mã. Với nhiều mô hình bán lại, đây là ràng buộc lớn nhất — không phải chi phí, mà là copyleft.

Enterprise Edition (thư mục /ee) — giấy phép thương mại. Một số tính năng cao cấp (SSO doanh nghiệp, một số quản trị nâng cao) nằm ngoài AGPL và cần license key trả phí. Đừng vô tình bật các tính năng /ee rồi bán mà không mua quyền — đó là vi phạm rõ ràng.

Cal.com Self-Hosted Commercial License. Nếu bạn muốn né hoàn toàn nghĩa vụ copyleft của AGPL (giữ kín mã sửa đổi của mình), Cal.com bán một giấy phép thương mại self-host. Với builder nghiêm túc muốn đóng gói SaaS thương mại, đây là con đường “sạch” nhất về pháp lý.

Kết luận trung thực cho ba tình huống: (1) làm dịch vụ cài đặt + vận hành hộ, dùng Cal.com không sửa lõi → an toàn với AGPL; (2) build SaaS đa khách trên nền Cal.com có sửa lõi → hoặc công khai mã sửa theo AGPL, hoặc mua commercial license; (3) muốn hoàn toàn không dính copyleft → mua commercial license hoặc dùng lõi lịch tự viết. Bỏ qua bước này là cạm bẫy pháp lý phổ biến nhất của người mới ghép repo đi bán.

Stack triển khai đề xuất

Một trợ lý AI đặt lịch cho phòng khám nhỏ có thể ghép từ bốn lớp, tách bạch rõ để dễ thay thế:

Lớp lịch (nguồn sự thật về khung giờ): Cal.com self-host, hoặc — nếu muốn nhẹ hơn — Google Calendar API cho phòng khám đã quen Google Workspace. Cal.com cho bạn quản lý nhiều bác sĩ, loại dịch vụ, đệm giờ giữa các ca, và webhook khi có booking mới.

Lớp hội thoại (AI): một LLM (API thương mại như GPT/Claude cho chất lượng tiếng Việt tốt, hoặc mô hình mở self-host nếu khách nhạy cảm dữ liệu) đứng sau một luồng có kiểm soát. Đừng để LLM “tự do” chốt lịch — hãy dùng nó để hiểu ý định (đặt/huỷ/đổi lịch, hỏi giá, hỏi địa chỉ) rồi gọi hàm tới Cal.com. Đây là mô hình “trợ lý có ràng buộc” an toàn hơn nhiều so với chatbot tự do.

Lớp kênh: Zalo Official Account là kênh sát thị trường Việt nhất, kèm widget web cắm vào trang phòng khám. Có thể thêm luồng gọi thoại sau.

Lớp tự động hoá & nhắc lịch: đây là nơi n8n toả sáng — nhắc trước 24 giờ, xác nhận, và lấp chỗ trống từ danh sách chờ khi có huỷ. Chúng tôi đã mô tả cách đóng gói n8n thành dịch vụ tính phí trong playbook bán dịch vụ tự động hoá workflow với n8n. Nếu phòng khám còn muốn trợ lý trả lời câu hỏi từ tài liệu nội bộ (bảng giá, quy trình, chuẩn bị trước khám), hãy ghép thêm một lớp RAG như trong pilot Document AI / RAG cho tài liệu nội bộ.

Xây gì · Bán cho ai · Validate

Ba hướng đi từ nhẹ tới nặng, chọn theo khẩu vị rủi ro và kỹ năng của bạn.

Hướng 1 — Dịch vụ “cài đặt & vận hành hộ” (rủi ro pháp lý thấp nhất)

Xây gì: gói triển khai Cal.com + luồng Zalo + nhắc lịch n8n cho từng phòng khám, không sửa lõi Cal.com nên tránh mọi ràng buộc AGPL. Bạn bán công sức cấu hình và vận hành, không bán phần mềm đóng.

Bán cho ai: phòng khám 1–3 bác sĩ chưa có hệ thống, lễ tân quá tải. Định giá gợi ý (ước lượng): phí setup 5–10 triệu đồng/cơ sở + phí vận hành 1–2 triệu/tháng. MVP: khoảng 1–2 tuần cho ca đầu tiên (chủ yếu là cấu hình + nối Zalo).

Cạm bẫy: mô hình này khó nhân bản nếu mỗi khách một kiểu; hãy chuẩn hoá thành checklist và template ngay từ khách thứ hai, nếu không bạn tự biến mình thành freelancer chạy tay.

Hướng 2 — SaaS multi-tenant “trợ lý đặt lịch cho phòng khám”

Xây gì: một sản phẩm SaaS mà mỗi phòng khám là một tenant, có trang quản trị riêng, trợ lý AI cắm sẵn. Đây là hướng có biên lợi nhuận cao nhưng chạm trực tiếp vào license: nếu sửa lõi Cal.com, bạn phải mua commercial license hoặc công khai mã theo AGPL. Cách sạch: gọi Cal.com qua API/webhook như một dịch vụ tách rời, để lớp SaaS của bạn là mã riêng.

Bán cho ai: chuỗi 3–10 phòng khám, hoặc franchise nha khoa/spa y tế. Định giá gợi ý (ước lượng): 500k–1,5 triệu/tháng theo số bác sĩ hoặc số lịch. MVP: khoảng 6–10 tuần cho phiên bản một tenant chạy thật.

Cạm bẫy: đừng để LLM tự chốt lịch dẫn tới đặt trùng hoặc sai khung giờ — mọi thao tác ghi lịch phải qua kiểm tra khả dụng từ Cal.com. Và luôn có nút “chuyển cho người thật” cho ca phức tạp; bệnh nhân y tế không tha thứ cho bot trả lời sai về sức khoẻ.

Hướng 3 — Add-on nhắc lịch & lấp chỗ trống (dễ validate nhất)

Xây gì: một tính năng hẹp — chỉ giải bài toán no-show. Cắm vào lịch sẵn có của phòng khám, tự nhắc và tự mời người trong danh sách chờ khi có huỷ. Nhỏ, dễ đo ROI.

Bán cho ai: phòng khám đã có phần mềm lịch nhưng no-show cao. Định giá gợi ý (ước lượng): tính phí theo hiệu quả — ví dụ chia sẻ giá trị mỗi khung giờ được lấp lại. MVP: khoảng 3–5 ngày, gần như chỉ là một workflow n8n + kênh Zalo.

Cạm bẫy: quá dễ sao chép; hãy dùng nó làm “cửa ngõ” chào hàng rồi bán chéo lên gói vận hành đầy đủ, đừng dừng ở một tính năng.

Cách validate trước khi viết dòng code nào

Trước khi dựng MVP, hãy chốt ba con số từ 3–5 phòng khám thật: tỷ lệ no-show hiện tại, số cuộc gọi đặt lịch mỗi ngày, và ai đang xử lý chúng. Nếu chủ phòng khám không nói được no-show đang tốn bao nhiêu, họ chưa đủ đau để trả tiền — chuyển sang khách khác. Một tuần phỏng vấn tiết kiệm cho bạn hai tháng code sai hướng. Tư duy “validate trước, ghép repo sau” cũng chính là tinh thần của playbook dựng MVP prompt-to-app.

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

Dùng Cal.com để bán dịch vụ cho phòng khám có vi phạm license không?

Không, nếu bạn self-host và không sửa lõi — bạn đang bán công triển khai và vận hành, điều AGPLv3 cho phép. Ràng buộc chỉ phát sinh khi bạn sửa mã Cal.com rồi cung cấp qua mạng: khi đó phải công khai phần sửa cho người dùng, hoặc mua giấy phép thương mại self-host để né copyleft. Tránh bật các tính năng Enterprise Edition (/ee) khi chưa mua quyền.

Có nên dùng LLM để trực tiếp chốt lịch cho bệnh nhân không?

Không nên để LLM tự do ghi lịch. Hãy dùng LLM để hiểu ý định và trích thông tin, còn việc kiểm tra khung giờ khả dụng và ghi booking phải do Cal.com quyết định qua hàm có kiểm soát. Với ngành y tế, luôn để sẵn đường chuyển cho lễ tân thật khi câu hỏi vượt phạm vi đặt lịch.

Không biết code nhiều thì nên bắt đầu từ đâu?

Bắt đầu từ Hướng 3 (add-on nhắc lịch) — phần lớn là cấu hình n8n + Zalo, MVP chỉ vài ngày, và dễ chứng minh ROI cho khách. Sau khi có 2–3 phòng khám hài lòng, mở rộng lên gói vận hành đầy đủ rồi mới cân nhắc SaaS multi-tenant.

Dữ liệu bệnh nhân thì xử lý sao?

Giảm tối đa dữ liệu nhạy cảm chạy qua LLM: chỉ gửi thông tin cần cho việc đặt lịch (tên, số điện thoại, dịch vụ, khung giờ), không gửi tình trạng bệnh. Nếu phòng khám nhạy cảm dữ liệu, ưu tiên self-host cả lớp lịch lẫn mô hình, và ghi rõ chính sách lưu trữ trong hợp đồng dịch vụ.

Bao lâu thì có sản phẩm bán được?

Một add-on nhắc lịch có thể chạy thật trong 3–5 ngày; gói cài đặt & vận hành hộ khoảng 1–2 tuần cho ca đầu; SaaS multi-tenant nghiêm túc cần 6–10 tuần. Con số là ước lượng cho một builder quen stack — hãy cộng thêm thời gian nếu bạn mới với Cal.com hoặc Zalo OA.

— Ban biên tập AIToEarn

Bước tiếp theo

Biến điều vừa đọc thành hành động

Lưu bài để đọc lại, tạo kế hoạch 7 ngày hoặc mở playbook phù hợp.




route
Xem playbook liên quan
Đi từ kiến thức sang hướng triển khai phù hợp.