- Hệ thống thanh toán và doanh thu là yếu tố bắt buộc để kiếm tiền, nhưng đây là hệ thống cốt lõi phức tạp liên quan đến tài chính, sản phẩm, hỗ trợ khách hàng, pháp lý, tuân thủ và cả bán hàng, nên chỉ một sự cố nhỏ cũng có thể lan thành vấn đề vận hành lớn
- Các công ty giai đoạn đầu hoặc đội ngũ sản phẩm mới thường xem thanh toán là một bài toán kỹ thuật và dễ chọn cách tự xây, nhưng trên thực tế có ba lựa chọn: tự xây, dùng bên thứ ba hoặc mô hình lai
- Một hệ thống thanh toán thực tế phải одновременно xử lý tính idempotent, ngày tháng, đo lường mức sử dụng, thuế, hoàn tiền, phân tầng khách hàng, hợp đồng tùy chỉnh, thay đổi giá và ghi nhận doanh thu
- Một số vấn đề sau khi giải quyết một lần thì khá ổn định, nhưng quy tắc thuế, lỗi do khách hàng, chỉnh sửa thủ công và yêu cầu hóa đơn theo từng quốc gia sẽ tiếp tục phình to khi công ty tăng trưởng và mở rộng toàn cầu
- Nên tập trung vào phần cập nhật mức sử dụng và các sự kiện trong vòng đời khách hàng mang tính đặc thù của sản phẩm, còn đăng ký, lập hóa đơn, kế toán và ghi nhận doanh thu thì an toàn hơn nếu giao cho hệ thống thanh toán đóng gói sẵn và ERP bất cứ khi nào có thể
Vì sao thanh toán không chỉ là một tính năng đơn giản
- Hệ thống thanh toán và doanh thu là thứ doanh nghiệp bắt buộc phải có để tạo ra doanh thu
- Khi hoạt động bình thường thì nó hầu như không ai để ý, nhưng thực tế đây là một hệ thống bạch tuộc chạm đồng thời vào nhiều tổ chức và chức năng
- tài chính
- sản phẩm
- trải nghiệm người dùng
- hỗ trợ khách hàng
- khách hàng
- pháp lý
- tuân thủ
- bán hàng
- Chỉ cần một phần bị hỏng, vấn đề có thể nhanh chóng lan sang các khu vực liên quan, và điều này thực sự xảy ra khá thường xuyên
- Nếu không thể thu tiền doanh thu một cách hợp pháp và chính xác, gánh nặng vận hành cho người điều hành doanh nghiệp sẽ tăng lên rất nhiều
Ba mô hình triển khai
- Hệ thống thanh toán thường có ba cách tiếp cận
- tự xây
- hệ thống bên thứ ba hoàn chỉnh
- mô hình lai giữa tự xây và bên thứ ba
- Các công ty giai đoạn đầu hoặc đội ngũ khởi động sản phẩm mới thường có xu hướng tự làm vì họ có kỹ sư và muốn giữ mọi thứ đơn giản
- Nếu nhìn thanh toán như kiểu “đưa file tính phí vào S3 rồi để tác vụ CRON lấy về và xử lý thanh toán”, bạn sẽ hiểu sai rằng đây chỉ là bài toán kỹ thuật
- Cũng như không ai tự triển khai bảo mật hay xử lý ngày tháng từ đầu, thanh toán cũng tốt hơn nếu không tự làm toàn bộ ngay từ đầu
- Hệ thống thanh toán tốt nhất là hệ thống mà bạn không cần phải tự xây toàn bộ
14 nỗi đau của hệ thống thanh toán tự xây
-
Tính idempotent
- Mọi yêu cầu lập hóa đơn và thu tiền thanh toán đều phải là duy nhất và idempotent
- Vấn đề này thường lộ ra khi phải retry do giới hạn API hoặc khi tăng số lượng instance của hệ thống thanh toán
- Nếu xử lý không đúng, sẽ có nguy cơ tính phí trùng lặp
-
Xử lý ngày tháng
- Cần quyết định sẽ tính phí mỗi 30 ngày hay tính theo ngày đăng ký hằng tháng
- Cũng phải xử lý cả các điều kiện như năm nhuận và múi giờ
-
Tính phí theo tỷ lệ và phần còn lại
- Cần quyết định chỉ áp dụng tính phí theo tỷ lệ khi nâng cấp hay cả khi hạ cấp
- Có các lựa chọn như hoàn tiền, cấp credit, bỏ qua, hoặc chặn nâng cấp/hạ cấp
-
Đo lường mức sử dụng
- Cách tính mức sử dụng có thể lên tới hàng chục kiểu khác nhau
- Nó cũng có thể khác nhau theo từng loại khách hàng hoặc thay đổi thường xuyên
-
Định dạng hóa đơn
- Khi chỉ hoạt động ở một quốc gia thì có thể trông khá đơn giản
- Nhưng khi mở rộng, bạn không chỉ phải xử lý sales tax mà còn cả VAT, GST và các khoản phụ thu riêng theo từng quốc gia
- Cuối cùng có thể cần mẫu hóa đơn riêng cho từng thị trường
Độ phức tạp tăng mạnh trong B2B và mở rộng toàn cầu
-
Phân cấp khách hàng phức tạp
- Đặc biệt với khách hàng B2B, họ có thể muốn quản lý quan hệ thanh toán với các công ty con và đối tác
- Bạn sẽ cần cách gộp mức sử dụng về đúng chủ thể thực sự thanh toán
- Những yêu cầu này thường chỉ xuất hiện sau khi công ty đã tăng trưởng và mở rộng
- Nếu pháp nhân của khách hàng hoặc nơi sử dụng khác nhau, thuế có thể cũng khác nhau
- Về mặt pháp lý, có thể phải tách riêng billing statement và invoice
- Các quy tắc liên quan có thể thay đổi vài tháng một lần
-
Thu tiền thanh toán và chống churn
- Cần quyết định sẽ ngừng retry thanh toán vào thời điểm nào
- Khi xảy ra chargeback, phải quyết định sẽ chấm dứt tài khoản, tạm ngưng hay hoàn tiền
-
Tạm dừng và khôi phục
- Khi khách hàng tạm dừng gói đăng ký, cần quyết định sẽ cho phép mức truy cập nào
-
Credit và hoàn tiền
- Nếu chỉ hoàn tiền toàn bộ thì tương đối đơn giản
- Nhưng khi có lỗi một phần, có thể phải chọn giữa hoàn tiền một phần hoặc cấp store credit
- Cũng cần quyết định riêng việc credit có hết hạn hay không
Thuế, hợp đồng và sai sót của con người
-
Xử lý thuế
- Chỉ riêng việc các hạng mục khác nhau áp dụng mức thuế khác nhau cũng đã đủ phức tạp
- Ở quy mô toàn cầu, mức thuế và quy tắc thuế thay đổi thường xuyên
-
Hợp đồng tùy chỉnh
- Nếu chỉ làm PLG thì đây có thể chưa phải vấn đề
- Nhưng khi bắt đầu ký hợp đồng, các ngoại lệ và điều khoản đặc biệt không thể cấu hình dễ dàng theo các giả định cũ sẽ xuất hiện rất nhanh
-
Sai sót của con người
- Khách hàng sẽ mắc lỗi, và vì thế sẽ cần chỉnh sửa tương ứng
- Ngay trong nội bộ công ty cũng có thể cấu hình sai thiết lập của khách hàng rồi phải sửa lại về sau
- Phát hành credit và xuất lại hóa đơn là công việc rất tốn thời gian
- Những thay đổi trong thông tin pháp lý của khách hàng cũng cần được xử lý
- địa chỉ
- VAT ID, v.v.
-
Thay đổi giá có chọn lọc
- Thay đổi giá thường không áp dụng cho mọi khách hàng
- Khi chỉ áp dụng cho khách hàng mới, bạn phải duy trì nhiều phiên bản giá khác nhau để giữ đúng các hợp đồng cũ
-
Ghi nhận doanh thu và doanh thu dồn tích
- Quy tắc ghi nhận doanh thu theo IFRS-15 có một bản đặc tả PDF dài 64 trang
- Nếu còn tự làm cả tích hợp ERP tùy chỉnh thì độ phức tạp sẽ còn tăng thêm
Những vấn đề giải quyết một lần và những vấn đề cứ tiếp tục phình to
- Một số vấn đề thay đổi thường xuyên hơn rất nhiều so với dự đoán, còn một số khác thì sau khi xử lý một lần sẽ gần như không phải đụng lại
- Tính idempotent là ví dụ của một bài toán kỹ thuật mà sau khi giải quyết một lần thì hiếm khi phải chỉnh sửa lại
- Quy tắc thuế thay đổi thường xuyên trên toàn thế giới
- Càng vào nhiều quốc gia, số luật thuế cần theo dõi càng tăng
- Lỗi do khách hàng gây ra xuất hiện khá đều đặn
- Công ty càng tăng trưởng thì quy mô của vấn đề càng lớn
- Sẽ cần nhiều hỗ trợ khách hàng và chỉnh sửa thủ công hơn
- Thanh toán ban đầu có thể trông như một bài toán kỹ thuật, nhưng thực tế nó bắt rễ trong một không gian vấn đề cực kỳ phức tạp đến mức ngay cả người có kinh nghiệm trong ngành cũng khó nắm hết
Những phần không nhất thiết phải tự làm
- Tốt nhất là giao càng nhiều vấn đề thanh toán càng tốt cho các hệ thống bên ngoài
- Cách tiếp cận được khuyến nghị là mua sẵn càng nhiều giải pháp đóng gói càng tốt
- Phần lớn mảng đăng ký và lập hóa đơn có thể do các hệ thống thanh toán xử lý
- Ghi nhận doanh thu và kế toán nên được giao cho ERP đang dùng hoặc các tính năng tích hợp sẵn trong hệ thống khác
- Đội ngũ sản phẩm chỉ nên tập trung vào những phần thực sự đặc thù của sản phẩm như cập nhật mức sử dụng và các sự kiện cơ bản trong vòng đời khách hàng
1 bình luận
Các ý kiến trên Hacker News
Đây là bài viết hay cho những ai phải đưa ra quyết định về billing nhưng chưa có nhiều kinh nghiệm, và cũng hữu ích để người có kinh nghiệm tham khảo
Tuy vậy, câu “Không thể cứ dump các file cần billing lên S3 rồi để một tác vụ CRON thu tiền sao?” khiến tôi cười lớn. Nhìn từ tư duy kỹ sư thì trong bất kỳ tình huống nào đó cũng không phải là ý hay
Quyết định về kiến trúc billing mà tôi thích là tách billing và entitlement trong hệ thống càng nhiều càng tốt. Nếu là gói đăng ký trả trước, tôi thấy cách tốt là trong phần entitlement chỉ lưu ngày hết hạn và chi tiết quyền được cấp trong thời gian hoạt động, còn hệ thống billing thì lưu subscription rồi đồng bộ sang phía entitlement khi cần. Làm vậy sẽ dễ hơn khi con người cần billing thủ công, debug·patch các vấn đề tạm thời, hoặc tích hợp Stripe
Tất nhiên vẫn phải để ngỏ khả năng mở rộng trong tương lai, nhưng bản thân quyết định này thường không hạn chế hệ thống quá nhiều. Đây không phải ý tưởng độc đáo của tôi, nhưng sau khi thử các cách khác kém thành công hơn, tôi đặc biệt thích cách này
Nhiều vấn đề phát sinh từ sự khác nhau giữa payment và billing https://www.wingback.com/blog/saas-payment-vs-saas-billing. Khi mới có khách hàng đầu tiên, bạn chỉ cần nhận vài khoản thanh toán định kỳ nên có thể bắt đầu dễ dàng bằng Stripe hoặc invoice thủ công
Nhưng theo thời gian, ngày càng có nhiều khách hàng enterprise cần entitlement phức tạp hơn, nhiều gói giá, bảo vệ khách hàng hiện hữu, chu kỳ·điều kiện billing và cấp quyền tùy chỉnh. Billing thường không trở thành trọng tâm kỹ thuật, nên các bản hack nhỏ và tính năng bổ sung cứ tích tụ lại, cuối cùng thành một mớ hỗn độn lấy mất nguồn lực phát triển sản phẩm, làm chậm tốc độ bán hàng hoặc giới hạn những gì có thể bán
Độ phức tạp của billing có nhiều bẫy và ngoại lệ ẩn, và ngày nay còn phức tạp hơn vì hầu hết gói giá đều có nhiều giới hạn cùng các yếu tố dựa trên usage, trong khi SaaS được bán trên toàn cầu. Ở các công ty giai đoạn muộn còn có đội hơn 15 kỹ sư chỉ chuyên về billing. Tôi đồng ý rằng nếu đó không phải lõi của sản phẩm thì không nên tự xây hệ thống billing. Nhân tiện, tôi là CTO của nền tảng billing SaaS Wingback
Giờ tôi lại muốn xây một hệ thống như thế, và cảm thấy mình đủ năng lực hơn nhiều so với tưởng tượng
https://arnon.dk/why-you-should-separate-your-billing-from-e...
Khách hàng lưu entitlement trong hệ thống của chúng tôi và kiểm tra khi cần; khi subscription được gia hạn·xóa ở phía nhà cung cấp thanh toán thì thêm rule và entitlement. Cách này giúp làm việc dễ hơn với một hoặc nhiều nhà cung cấp thanh toán, đồng thời làm rõ sự tách biệt mối quan tâm. Tôi chia sẻ thêm vài bài liên quan vì chúng phù hợp với ngữ cảnh này hơn: https://warrant.dev/use-cases/pricing-tiers-and-entitlements..., https://arnon.dk/why-you-should-separate-your-billing-from-e...
Một hệ thống entitlement lý tưởng phải linh hoạt động, tức là rule phải được lưu trong cơ sở dữ liệu, phải xử lý được các kịch bản một lần như khách hàng enterprise, và bên trên phải có một lớp policy. Ví dụ, nó nên hỗ trợ được gần như mọi kịch bản như gói Pro có tối đa 5 seat, gói Growth cho phép dùng một tính năng nào đó N lần mỗi ngày
Một UI để người không phụ trách kỹ thuật có thể thay đổi theo từng khách hàng mà không cần engineering can thiệp cũng là lợi thế lớn. Ở vai trò kỹ sư trước đây của tôi, những việc như vậy luôn cản chân đội phát triển
Cũng có một tập entitlement, nhưng ở giữa có cơ chế policy quyết định khi nào áp dụng hoặc không áp dụng entitlement. Điểm cốt lõi là entitlement không chỉ là vấn đề của billing. Cơ chế policy là lớp keo nối entitlement với mọi thứ khác, nên bạn có thể cấp quyền cho một lãnh đạo ở khách hàng lớn nhất mà không cần gắn với billing
Trước đây tôi từng xây hệ thống billing và khoản phải thu cho một chuỗi nhà thuốc nhỏ, và các hãng bảo hiểm đôi khi gửi những tấm séc khá lớn mà không báo trước gì cả
Dù chúng tôi không billing gì, qua đường bưu điện vẫn có tấm séc 150.000 đô la, rồi vài tháng sau họ mới nhận ra sai sót và yêu cầu trả lại. Có một tài khoản đặc biệt gọi là magic money để giữ những khoản tiền như vậy. Thế giới billing đúng là một khu phố điên rồ
Có phải chỉ gọi nó là magic money trong khi vẫn giữ nguyên khoản nợ trên tài khoản cá nhân không
Tôi cho rằng không nên tiếp cận chủ đề này chỉ từ nỗi khổ của việc tự xây dựng hệ thống billing. Nếu nhiều công ty muốn đi theo hướng đó thì cứ để họ làm
Tôi thừa nhận hệ thống billing rất phức tạp. Nhưng nếu Chargebee, Solvimon, Stripe, Recurly, Orb, Metronome, Lago, Togai, v.v. có những kiến thức đó, thì cũng có thể tập hợp kiến thức ấy vào một nơi
Câu trả lời rốt cuộc là cách tiếp cận phù hợp với chính mình. Nếu là SaaS dựa trên subscription thì có giải pháp phù hợp với nó, còn nếu là API tính theo mức sử dụng thì có giải pháp billing tương ứng
Thay vì khuyên can một thông lệ, ta có thể tập hợp kiến thức, cách tiếp cận, paradigm, pattern lập trình, thực hành tốt và best practices vào một nơi. Cũng có ngoại lệ là các công ty ngoài Mỹ hoặc châu Âu không dùng được giải pháp billing như Stripe. Ví dụ nếu là công ty Venezuela nên không thể tạo tài khoản Stripe, cuối cùng họ phải tự làm giải pháp billing và kết nối với SOAP-XML API khó hiểu của cổng thanh toán địa phương
Riêng việc “tự xây dựng hệ thống billing” có cảm giác giống như “tự xây SIEM” bằng cấu hình Elastic + Grafana. Tôi không khuyến nghị, nhưng hiểu vì sao các bộ phận bảo mật IT lại đi theo hướng đó nhiều như vậy
Hệ thống billing ít phức tạp hơn những thứ mà developer thường xử lý. Bài viết mô tả các yêu cầu pháp lý khó nhằn như điểm đau, nhưng trên thực tế điều đó cũng có nghĩa là thông số kỹ thuật dễ tìm và được tài liệu hóa tốt. Có những phần thay đổi thường xuyên, nhưng các phần đó cũng được gắn nhãn và giải thích rõ
Tôi đồng ý rằng SaaS dựa trên subscription và API dựa trên mức sử dụng có những cách billing phù hợp riêng. Tuy nhiên, mấu chốt là có cho phép khách hàng chuyển gánh nặng trách nhiệm sang hay không, doanh thu có đủ quan trọng để xác minh hay không, và có chịu được phí hoặc tổn thất hay không
Một thứ bài viết này chưa đề cập là bán hàng liên kết, và tùy triển khai sâu đến đâu mà có thể phát sinh khá nhiều việc
Đây là hệ thống cho phép người khác nhận khoản chi trả dựa trên hoa hồng cho các giao dịch bán trong nền tảng
Cần theo dõi mã liên kết tới giao dịch bán và người dùng, gửi khoản chi trả cho bên liên kết qua nhà cung cấp thanh toán mà họ thiết lập, và nếu muốn làm cho đúng thì còn phải cung cấp UI để xem chỉ số khách truy cập, tỷ lệ chuyển đổi và lịch sử chi trả
May là phần lớn có thể xây dần từng bước. Chỉ cần liên kết mã duy nhất với người dùng, rồi liên kết mã đó với giao dịch bán có một tỷ lệ hoa hồng cụ thể; phần còn lại có thể xử lý thủ công hoặc bỏ qua. Ví dụ, tôi trả tiền cho bên liên kết mỗi tháng một lần qua Zelle hoặc PayPal và mất chưa đến 10 phút. Không có frontend theo dõi chuyển đổi, và cũng chưa có ai vì thế mà nói sẽ không làm affiliate
Điều thật sự ấn tượng là nhu cầu phải có khả năng chạy ngược toàn bộ cỗ máy Rube Goldberg này
“Đơn hàng” thì muốn giữ càng tĩnh càng tốt, còn “hóa đơn” thậm chí có nghĩa vụ pháp lý
Ví dụ, giả sử khách mua 5 cái nên được giảm giá nhưng chỉ muốn giữ 3 cái, và tên cùng địa chỉ lại bị gõ sai. Không sao, ta hủy hóa đơn, tạo hóa đơn mới cùng số tiền nhưng sửa tên/địa chỉ, chờ hàng trả về đến nơi và được kiểm tra, rồi lại ghi có và tạo thêm một hóa đơn mới
Lô hàng trả lại ở trạng thái mơ hồ một thời gian, khách lại đặt thêm 5 cái nữa, một cái đến nơi bị vỡ và họ muốn hoàn tiền chứ không muốn đổi hàng. Ngày giao hàng bị tách làm 2 nên hệ thống không áp dụng giảm giá từ 5 cái trở lên. Việc ban đầu tưởng chỉ là 2 đơn hàng đơn giản nhanh chóng biến thành vô số giao dịch và giấy tờ. Khách còn quên mật khẩu nên tạo tài khoản mới bằng email khác. Một năm sau nhìn log sẽ khó hiểu vì sao họ chỉ mua 3 cái mà lại được giảm giá
Tôi không chắc về lời khuyên này. Một nửa các tính năng được nói đến trong bài có thể không cần thiết, và khi doanh nghiệp lớn lên thì hoàn toàn có thể xây dựng dần dần
Cần hiểu các khái niệm như invoice, credit, kỳ tính thuế, thay đổi tính phí theo ngày. Nhưng kiến thức đó không phải là lý do buộc phải thuê ngoài hoặc mua, mà là chất liệu để đánh giá nên tự xây hay mua tốt hơn
API bên ngoài cần cho SaaS chỉ là một bộ xử lý thẻ tín dụng, còn nếu muốn làm cho đẹp thì khoảng hai cái. Tất nhiên sau năm đầu sẽ phát sinh nhiều việc thủ công, kế toán sẽ chỉ ra những sai lầm ngớ ngẩn, và bạn cũng sẽ học được rất nhiều về kế toán
Dù vậy, nếu hôm nay bắt đầu một doanh nghiệp mới, tôi vẫn sẽ so sánh nhiều giải pháp, nhưng tôi tin chắc rằng tự làm không đáng sợ đến thế
Xây hệ thống lúc nào cũng trông có vẻ dễ, và ngày đầu tiên thì thực sự dễ. Nhưng chẳng bao lâu bạn sẽ tốn rất nhiều thời gian giải thích với CFO vì sao báo cáo hoàn toàn rối tung, rồi giải thích với đội hỗ trợ vì sao invoice thất bại, vì sao tính sai giá subscription, cùng nhiều trường hợp ngoại lệ mà bạn thậm chí không biết là tồn tại
Sau đó bạn còn phải đáp ứng các quy định đã thay đổi, hoặc gateway bạn chọn có thể không hỗ trợ khu vực mà bạn đang tăng trưởng
Trước khi nói “chỉ cần làm tốt hơn là được”, hãy nhớ rằng việc đó cũng là thời gian. Đó là thời gian không dùng cho sản phẩm, không dùng để cải thiện mô hình giá, mà là thời gian giậm chân tại chỗ thay vì làm những việc tạo ra tăng trưởng cho doanh nghiệp
Những thứ khác có thể bỏ qua, nhưng về sau nếu không tính được thuế hoặc vi phạm luật KYC thì sẽ rất khổ
Ngoài ra, việc một hệ thống đắt hơn dự kiến và được nhiều công ty có vẻ thông minh sử dụng không có nghĩa là nó phù hợp với mục đích của bạn. Đặc biệt càng không đảm bảo là nó phù hợp với đúng mục đích bạn muốn. Mua không có nghĩa là khỏi phải nghiên cứu
Mục tiêu của người xử lý phần billing này rất đơn giản. Phải cung cấp các lựa chọn phù hợp để đội sales có thể chốt hợp đồng. Cần phối hợp với đội sales để tìm ra vùng “dễ triển khai và đủ để chốt hợp đồng” là gì
Không thể nhấn mạnh điều này đủ. Đội sales thực sự đang tạo ra doanh thu. Đừng than vãn vì hệ thống billing không hoàn hảo. Nghe có thể sốc, nhưng với những vấn đề liên quan đến quan hệ kinh doanh, đôi khi phải xắn tay áo lên và xử lý thủ công
Hãy làm theo cách đơn giản nhất có thể, nhưng hệ thống phải để các đội khác trong công ty đọc và hiểu được, và dù có automation chạy thì vẫn dễ điều chỉnh thủ công. 80% lý do Stripe tạo cảm giác dễ dùng nằm ở đây. Điều chỉnh thủ công là một phần của cuộc sống, và trong một số doanh nghiệp dù hiếm thì cuối cùng vẫn cần
Tính phí theo ngày, các lịch billing khác nhau, trial, thử nghiệm giá mới, giá theo khu vực, thuế theo khu vực, liệt kê bundle bằng nhiều tiền tệ, triển khai giá mới bỗng trở thành tổ hợp 6 loại tiền tệ × X khu vực × Y sản phẩm × Z lịch billing × L ngôn ngữ
Thêm vào đó là thêm subscription mới, gộp các gói subscription, ngừng các gói cũ trong khi chuyển khách hàng sang gói thay thế mới một cách êm thấm, và phải giao tiếp tốt với khách hàng. Nếu là SaaS thì gần như tất cả những việc này phải được automation, self-service và test tốt; nếu không bạn sẽ chết chìm trong hỗ trợ khách hàng và churn
Triển khai thay đổi giá có thể mất từ 3 ngày đến 2 tháng, và xử lý di sản từ các hợp đồng tùy chỉnh ban đầu là ác mộng. Nếu không dễ automation thì không làm được. Tốn quá nhiều thời gian
Nếu trước đây chúng tôi đặt billing trên nền tảng như sản phẩm được nhắc ở đây, rất có thể đã làm tốt hơn nhiều trong việc triển khai hợp đồng tùy chỉnh theo từng phân khúc khách hàng và thay đổi giá
Có 2 vấn đề không được đề cập ở đây nhưng tôi từng tự xử lý
Thứ nhất là khóa sổ cuối tháng/cuối quý. Bài viết có nói đến sổ cái tài khoản, nhưng khi bắt đầu xử lý các công ty đại chúng phải báo cáo số liệu, sẽ có thời điểm khóa sổ nghiêm ngặt và phải bảo đảm mọi thứ diễn ra trơn tru
Thứ hai là kế toán tiền mặt đang chuyển. Bài này giả định bộ xử lý thanh toán chính xác 100% và không có vấn đề gì. Khi đủ lớn, bạn phải có khả năng đối chiếu mọi khoản tiền vào tài khoản ngân hàng với một invoice hoặc hạng mục billing cụ thể. Cũng phải tìm được những invoice không có dòng sao kê ngân hàng tương ứng, và ngược lại xử lý trường hợp tiền vào nhưng không gắn với hạng mục invoice nào. Khả năng xử lý các khoản credit trong tài khoản ngân hàng không liên kết với invoice billing cũng rất quan trọng
Có thể nói tất cả chuyện này là vấn đề của bộ phận kế toán, nhưng nó gắn rất chặt với hệ thống, nên hai đội phải làm việc cùng nhau để không có sai lệch giữa các sổ sách
Kế toán thực sự phải liên tục ở lại đến nửa đêm vì khóa sổ, còn người phía kỹ thuật/kinh doanh thì gặp cảnh cần lấy gì đó từ đội kế toán nhưng trong giai đoạn khóa sổ đội kế toán như biến mất khỏi Trái Đất. Trải nghiệm với tư cách người nhà cũng y như vậy
Kế toán nội bộ và tài khoản ngân hàng sẽ dần lệch nhau, và kế toán sẽ không biết phải bắt đầu tìm vấn đề từ đâu
Tôi tò mò mọi người đang dùng gì để quản lý quyền hạn. Không biết họ dùng hệ thống feature flag, dùng một SaaS riêng như Stigg, hay có một hệ thống nội bộ riêng
Sáng nay tôi lên HN cũng là vì đã viết một bài về việc dùng feature flag cho quản lý quyền hạn: https://prefab.cloud/blog/modeling-product-entitlements-with.... Tôi cũng lấy cảm hứng từ bài của Arnon về định dạng SKU
Feature flag có vẻ không phải nơi hoàn hảo để quản lý quyền hạn, nhưng theo kinh nghiệm của tôi, khi xử lý những bài toán kiểu này, nó thường là công cụ tốt nhất trong số những thứ sẵn có. Tôi muốn nghe các ý kiến khác
Các hạn mức và cờ này được gắn vào “gói”, và gói có thể gắn vào tài khoản. Khi kết hợp các gói, giá trị số sẽ lấy giá trị lớn hơn, còn thẻ thì hợp nhất thành tập hợp. Ngoài ra có thể ghi đè hoặc bổ sung giá trị theo từng tài khoản, nên nếu khách hàng cần PlanX nhưng cần hạn ngạch API tùy chỉnh, chỉ cần ghi đè trực tiếp một giá trị đó trên tài khoản
Cứ gọi là lỗi thời cũng được, nhưng tôi không hiểu vì sao phải thuê bên thứ ba làm những thứ như vậy
Cách cơ bản thì có thể làm bằng feature flag, nhưng các quyền hạn liên quan đến thanh toán và giá, ví dụ việc tổ chức và thay đổi gói cũng như phiên bản, sẽ ngày càng phức tạp do nhiều yêu cầu xung quanh phát sinh theo thời gian. Hãy nghĩ đến nhiều tổ hợp khác nhau giữa tính năng, seat, chiến lược dựa trên mức dùng/đo lường, đăng ký theo nhóm, chuyển đổi gói, gói doanh nghiệp một lần, khách hàng có nhiều đăng ký, giai đoạn khuyến mãi và đăng ký phân tầng, tổng hợp mức dùng, tự động upsell, v.v.
Như trong bài viết, có thể biểu diễn hạn mức bằng các flag có giá trị số, nhưng doanh nghiệp vẫn phải tự triển khai hạ tầng theo dõi mức dùng. Thay vào đó, hãy hình dung việc xuất mức dùng đó sang một dịch vụ quyền hạn, và các quyền hạn dựa trên mức dùng được cập nhật theo thời gian thực giữa các nhóm. Các quyền hạn khác phụ thuộc vào quyền hạn đó cũng có thể được cập nhật cùng lúc. Khi tiến gần hoặc vượt hạn mức, có thể chọn giới hạn mềm: vẫn cho dùng tiếp nhưng thông báo cho đội sales, hoặc giới hạn cứng: hiển thị lời nhắc nâng cấp
Đúng tinh thần của bài gốc, chúng tôi không xây lại hệ thống thanh toán mà hoạt động cùng các giải pháp thanh toán hiện có. Chúng tôi đang bootstrap bằng một thương vụ thoái vốn thành công trước đó và đang làm việc với các khách hàng đầu tiên, nên nếu chỉ muốn trao đổi về chủ đề này cũng có thể liên hệ trent at planship.io
Triển khai beta, xác thực dựa trên vai trò, quyền hạn thanh toán, cho đến yêu cầu khách hàng một lần — tất cả đều có thể được xây bằng feature flag. Các feature flag tốt nhất còn có thể gắn giá trị tùy chọn, nên hạn mức gói API cũng có thể trở thành feature flag
Nếu hỏi đó có phải cách tốt nhất không, thì với từng use case riêng lẻ có lẽ là không. Nhưng một khi đã xây xong, sức cám dỗ dùng nó ở khắp nơi là rất lớn
Quyền hạn phải liên kết rõ với các tính năng khách hàng nhìn thấy, và về mặt khái niệm là các khối tính năng lớn hơn nhiều. Khó khăn của cách tiếp cận này là vẫn phải xét đến rất nhiều khía cạnh liên quan đến thanh toán. Xử lý khách hàng quá hạn, phí vượt mức khi vượt một hạn mức nhất định, nhiều mô hình giá cho cùng một tính năng, đặt lại hoặc chuyển tiếp bộ đếm mức dùng khi đổi/nâng cấp gói — tất cả sẽ làm tăng độ phức tạp rất nhiều theo thời gian
Vì vậy tại Wingback, chúng tôi quyết định cung cấp quyền hạn tính năng riêng, gắn chặt với chuỗi thanh toán và đo lường. Nói thêm, tôi là CTO. Rốt cuộc, tôi nghĩ cả hai cách tiếp cận đều có thể hoạt động tốt, tùy vào độ phức tạp của gói và mức đầu tư hiện có vào feature flag. Nếu có gating tính năng cho khách hàng, việc provision tài khoản khách hàng và cung cấp gói tùy chỉnh sẽ dễ hơn nhiều
Tôi khó chấp nhận toàn bộ cấu trúc lập luận kiểu “hệ thống X rất phức tạp, nên đừng tự xây mà hãy dùng giải pháp có sẵn”
Lời giải tổng quát cho X có thể cực kỳ khó và phức tạp, nhưng use case của tôi chỉ cần một phần cụ thể của độ phức tạp đó. Vì vậy tôi có thể xây một giải pháp riêng chỉ xử lý đúng độ phức tạp mình cần, và nó có thể đơn giản hơn nhiều so với công cụ có sẵn
Tôi hoàn toàn áp dụng lập trường này với ngày giờ. Cách tiếp cận ngày giờ của tôi chỉ cần thư viện cung cấp hai lời gọi hàm. Một hàm chuyển thời gian epoch thành chuỗi thời gian định dạng ISO trong một múi giờ cụ thể, và hàm ngược lại. Tôi hoàn toàn không đụng đến mã thư viện khác, còn mọi thao tác thời gian còn lại được xử lý trong mã của tôi dựa trên hai hàm đó
Ngay từ đầu phải hiểu những điều nên và không nên làm khi xử lý dữ liệu cá nhân, chu kỳ và vòng đời của nhiều tùy chọn thanh toán, giới hạn hoàn tiền, hỗ trợ idempotency, quản lý transaction cơ sở dữ liệu hợp lý với mô hình phù hợp cho nhiệm vụ, phát hành hóa đơn và hiển thị cho khách hàng, v.v.
Không cần tất cả cùng một lúc, nhưng ngay cả bản triển khai đầu tiên có thể chạy được cũng cần ít nhất một nửa trong số đó
Có cảm giác như “14 nỗi đau của việc băng qua đường và vì sao bạn nên mua sách của tôi để đọc”
Nhiều người nghĩ cứ nhắm mắt rồi bắt đầu đi là tốt, để rồi bị thương sớm hoặc chết
Mỗi quốc gia, thậm chí mỗi thành phố, có quy tắc băng qua đường khác nhau. Có thể bạn chưa biết, nhưng phải nhìn cả hai phía. Nhiều người không biết mình bị mù màu nên không phân biệt được đỏ và xanh, rồi chết hoặc bị thương. Bạn đã nhìn hai phía, nhưng đã nhìn lên trên chưa? Ở thành phố có đồ rơi từ cửa sổ xuống, ở nông thôn có thể có chim bay trên đầu, và rác vũ trụ cũng ngày càng rơi xuống Trái Đất nhiều hơn. Vật thể có thể đến từ nhiều hướng
Không phải bài này tệ đến mức đó, nhưng nếu được cấu trúc như một bài viết về phương pháp luận thì sẽ hay hơn. Tôi muốn đọc kiểu đó hơn nhiều so với một bài được đóng khung tiêu cực
Đây là mẫu dự án đùa kiểu “khó đến mức nào chứ?”, vấn đề là mọi điều trong đó đều đúng
Có vô số ví dụ, nhưng nếu tiếp cận sai vấn đề, bạn sẽ sớm đụng câu hỏi “khách hàng phải trả bao nhiêu”, rồi tiếp theo là “vì sao chúng ta đã tính số tiền này thay vì số tiền kia”. Nếu chuyện này xảy ra quá thường xuyên, đội tài chính sẽ đến hỏi bạn đã làm gì mà khiến các báo cáo vận hành công ty, thậm chí cả các báo cáo quyết định có sa thải hay không, trở nên không đáng tin cậy