Khi còn làm việc tại Looker (sau này thuộc Google sau thương vụ mua lại), tôi dành phần lớn thời gian trong những căn phòng với các khách hàng đã mua một công cụ BI và đang cố tìm xem phải làm gì với nó. Tôi đã bán được khá nhiều trong những cuộc trao đổi như vậy, và mô thức gần như lúc nào cũng giống nhau.
Khách hàng sẽ mô tả một câu hỏi mà họ muốn trả lời.
Tôi sẽ hỏi họ có dữ liệu gì.
Họ ngập ngừng.
Có khi họ có data warehouse nhưng không có event. Có khi họ có event nhưng không có data warehouse. Có khi họ có cả hai. Câu hỏi họ muốn trả lời hầu như luôn hợp lý. Nhưng hạ tầng để trả lời câu hỏi đó thì gần như chưa tồn tại. (Đó cũng chính là làn sóng Big Data giai đoạn 2010–2020.)
Bài học tôi rút ra sau bốn năm nghe có vẻ không hào nhoáng: bạn cần thu thập và làm sạch dữ liệu. Những phân tích thú vị bạn muốn chạy vào năm 2026 phụ thuộc vào các event mà bạn đã bắt đầu ghi nhận từ năm 2024.
Nếu bạn không làm điều đó, sẽ không có mẹo thông minh nào cứu được.
Gần đây, tôi gia nhập Railway với vai trò Solutions Engineer, ban đầu nghĩ rằng mình sẽ áp dụng một phiên bản nào đó của bài học này cho một stack nhỏ hơn, linh hoạt hơn. Nhưng tôi lại bước vào một vấn đề hoàn toàn ngược lại.
Dữ liệu, email và biểu mẫu… đủ cả
Trước tất cả những thay đổi này, cách chúng tôi làm là phiên bản PLG-to-sales onboarding phổ biến nhất.
Hệ thống email onboarding của chúng tôi lần gần nhất được chỉnh sửa là năm 2022, rồi thêm một lần vào năm 2024. Nói cách khác, chương trình email này trông giống hệt mọi chuỗi email PLG đang cố chuyển đổi lead sang sales.
Với 2,9 triệu người dùng đăng ký trước tháng 4/2026, hẳn bạn sẽ nhớ chuỗi email chào mừng chung chung được gửi ngay khi đăng ký: “Chào mừng đến với Railway, đây là template, đây là tài liệu docs, đây là Discord của chúng tôi.”
Tỷ lệ mở email khoảng 27%. Tỷ lệ phản hồi thì, nói rộng lượng, gần như bằng 0.
Tệ hơn nữa, chúng tôi không hề biết mình đang nói chuyện với ai. Mọi lượt đăng ký phù hợp với ICP sales đều bị đối xử như nhau. Một người đang triển khai dự án cá nhân trong một tập đoàn lớn và một platform team đang dựng hạ tầng production đều nhận cùng một email “đây là template!” ngay ngày đầu tiên.
Đây không phải vấn đề email.
Đây là vấn đề nhắm mục tiêu, chỉ đang khoác áo vấn đề email.
Vì vậy: chúng tôi khuyên các công ty nên khai tử hoàn toàn quy trình sales onboarding đại trà.
Những giàn khoan dầu đã ở đúng chỗ
Người ta hay nói dữ liệu là dầu mỏ. (Biên tập viên chú thích: chúng tôi thấy nó giống plutonium thải hơn.)
Các đồng nghiệp của tôi là Angelo và Echo đã dành thời gian instrument funnel, nhưng không ai thực sự nhìn toàn bộ hành trình từ đăng ký đến closed-won kể từ khi sản phẩm trưởng thành với mảng Enterprise.
Railway hiện có hơn 10.000 lượt đăng ký mỗi ngày. Là một công ty product-led đúng nghĩa, người dùng chỉ cần đăng ký bằng GitHub hoặc email là có thể triển khai thứ gì đó trong vài phút, thậm chí vài giây.
Chúng tôi cố tình không hỏi: “Bạn thuộc công ty nào?” hay “Đội ngũ bạn có bao nhiêu kỹ sư?”
Gần đây có một meme về các onboarding flow kiểu Granola — tra khảo người dùng trước khi cho họ làm bất cứ điều gì. Chúng tôi thì hoàn toàn đi theo hướng ngược lại.
Nhưng cái giá phải trả nhìn lại rất rõ: nếu bạn không hỏi, bạn sẽ không biết. Những công ty thật sự — kiểu sẽ triển khai workload production — sẽ bị chìm trong nhiễu.
Khi tôi mở Hex, con số khiến toàn bộ dự án hình thành là: chúng tôi đã xác định được khoảng 21.000 account phù hợp với ICP sales (ước lượng dựa trên quy mô công ty, thị trường, khu vực, giai đoạn gọi vốn). Nhưng chúng tôi mới tiếp cận chưa tới 1% trong số đó.
Để dễ hình dung, Railway có một Account Executive và hiện tại là hai Solutions Engineer, bao gồm cả tôi. Không có hệ thống nào giúp đưa những account này ra ánh sáng theo cách mà một đội nhỏ có thể xử lý được.
Trong một buổi 1:1, nhà sáng lập Cooper nói rất chuẩn:
“Mọi giàn khoan dầu đều đã ở đúng vị trí. Chỉ là chẳng ai khoan cả.”
Đây là tình huống trái ngược hoàn toàn với mọi cuộc trò chuyện tôi từng có ở Looker.
PostHog đã thu thập product event từ lâu. Metadata khi đăng ký khá phong phú.
Hệ thống nội bộ của chúng tôi (“backboard”) có cái nhìn chi tiết về những gì thực sự đang chạy trong từng project: service, kích thước instance, template, kết nối database, kết quả deploy.
Sau đó tôi thiết lập các dbt model trên data warehouse, với Hex ở phía trước để phân tích.
Câu hỏi đúng hóa ra là:
Trong 10.000 lượt đăng ký mỗi ngày này, đâu là công ty thực sự, và công ty nào đang cần trợ giúp ngay lúc này?
Càn quét toàn bộ các chiều dữ liệu
Cám dỗ lúc này là ngồi cùng đội sales và đoán xem tín hiệu nào trông “giống doanh nghiệp”.
Đừng làm vậy.
Bạn sẽ chỉ chọn những thứ củng cố định kiến sẵn có.
Thay vào đó, trong Hex, tôi:
-
Lấy mọi dimension từ bảng customer và workspace.
-
Với từng dimension hoặc hành vi — như “kết nối database”, “reset credential”, “tải tài liệu trust document”, “thêm teammate” — tính tỷ lệ xuất hiện giữa nhóm account chắc chắn là doanh nghiệp và nhóm chắc chắn là hobbyist.
-
Sắp xếp theo uplift.
Hex giúp việc này khả thi vì nó có schema registry và LLM có thể viết phần boilerplate, nên tôi chỉ cần lặp với prompt thay vì viết đi viết lại cùng một câu GROUP BY hàng chục lần.
Đây thực sự là kiểu việc mà năm năm trước sẽ mất hàng tuần.
Sau đó tôi phải loại bỏ một nhóm tín hiệu nhìn rất đẹp nhưng vô dụng: các tín hiệu mang tính xác định tuyệt đối.
Ví dụ, SSO có uplift cực cao… nhưng chỉ những khách hàng đã nói chuyện với sales mới bật được.
Vậy nên nó chẳng giúp gì trong việc phát hiện một người lạ.
1 = 1.
Logic tương tự cũng loại thêm vài feature hấp dẫn khác.
Quy tắc cuối cùng tôi dùng là:
Một tín hiệu chỉ có giá trị nếu hobbyist hoàn toàn có thể vô tình tạo ra nó, nhưng hiếm khi làm vậy.
Với các GTM Engineer mới vào nghề: những feature trông dự đoán tốt nhất trong confusion matrix thường chính là nơi label đang bị rò rỉ vào input.
Điều gì thực sự dự đoán “đây là doanh nghiệp”?
Một vài tín hiệu, theo thứ tự sức mạnh gần đúng:
Tải tài liệu trust center
Đây là tín hiệu xác suất mạnh nhất. Hobbyist không tải báo cáo SOC 2. Khi sales liên hệ với người đã tải tài liệu này, tỷ lệ phản hồi khoảng 50% — mức hoàn toàn bất thường với email sales.
Số lượng seat và tốc độ tăng seat
Điều này có ý nghĩa vì Railway đã bỏ seat pricing từ năm ngoái, nên đây trở thành tín hiệu dự đoán tốt hơn.
Reset credential
Điều này khiến tôi ngạc nhiên. Giả thuyết tốt nhất: chính sách bảo mật nội bộ nghiêm ngặt hơn, yêu cầu đổi mật khẩu định kỳ. Hoặc người dùng đang va chạm kỳ lạ với auth flow. Cần nghiên cứu thêm.
Kết nối database managed hoặc external
Rất hợp lý. Doanh nghiệp thường cắm dữ liệu thật vào nhanh hơn hobbyist.
Mẫu deploy failure cụ thể
Không phải “deploy fail một lần”, mà là dấu hiệu cho thấy họ đang vật lộn với một vấn đề có hình dáng production thật sự.
Không tín hiệu nào đủ quyết định riêng lẻ.
Nên tôi gom chúng thành một điểm số.
Một điểm số cố tình nhàm chán
Tôi lấy uplift ratio của từng tín hiệu làm trọng số rồi cộng lại thành điểm cho mỗi account.
Thế thôi.
Khoa học dữ liệu cổ điển thuần túy.
Không LLM.
Tôi từng cân nhắc thứ gì đó phức tạp hơn nhưng bỏ qua vì hai lý do:
Thứ nhất, chúng tôi thường chỉ làm việc với một ngày dữ liệu hành vi. Bất kỳ mô hình tinh vi nào hơn weighted sum đều dễ overfit vào một cỡ mẫu chỉ mang tính “cảm giác”.
Thứ hai, đội sales phải đọc hiểu được điểm số này.
Nếu Rahul (AE của chúng tôi) phải hành động dựa trên điểm cao, anh ấy cần nhìn vào hàng dữ liệu và hiểu ngay vì sao điểm cao.
“Trust doc + 8 seat + DB connected” thì dễ hiểu.
“0,87 từ gradient-boosted tree” thì không.
Tôi đã học điều này theo cách khó khăn:
Mô hình chính xác nhất thế giới cũng vô giá trị nếu con người dùng nó không thể nhận ra khi nào nó sai.
Khả năng giải thích gần như luôn quan trọng hơn một chút độ chính xác biên.
Điểm số này dẫn đến hai luồng:
-
Điểm trung bình → email hành vi tự động qua Customer.io, gửi từ inbox người thật
-
Điểm cao → chuyển cho Rahul + đội Solutions để tiếp cận trực tiếp
Toàn bộ kiến trúc chỉ có vậy.
Không quá thông minh.
Điểm đáng giá nằm ở cách chọn tín hiệu.
Đừng drip campaign kiểu cũ
Chiến dịch Customer.io cho nhóm sales ICP không phải chuỗi email chào mừng.
Chuỗi email chào mừng là cách để bạn có tỷ lệ mở thấp.
Thay vào đó, email chỉ được kích hoạt khi event thỏa đồng thời hai điều kiện:
-
Event đó tương quan với việc người dùng là doanh nghiệp
-
Event đó tương quan với việc người dùng đang mắc kẹt nhẹ hoặc chuẩn bị cam kết nghiêm túc
Email được gửi ngay sau event, từ email thật của đội sales.
Nội dung không yêu cầu đặt lịch meeting.
Không pitch gói enterprise.
Chỉ đơn giản:
“Thấy bạn vừa gặp X, tôi có thể hỗ trợ gì không?”
Ngày đầu tiên, với khoảng 300–400 email gửi đi, tỷ lệ mở theo trigger dao động 50–70% trong 24 giờ đầu, so với mức nền 27% của chiến dịch cũ.
Tất nhiên vẫn có lưu ý:
-
Open rate bị bóp méo phần nào bởi Apple Mail Privacy Protection
-
Reply rate mới là thứ quan trọng, và ngày đầu đã có hai phản hồi thật
-
Selection bias rất lớn
-
Mẫu 300 email còn nhỏ
-
Chưa có A/B test hoàn chỉnh
Nhưng nếu cứ chờ nghiên cứu cohort sạch kéo dài sáu tháng thì những thứ thú vị sẽ chẳng bao giờ được viết ra.
Vì sao đa số công ty không làm như vậy?
Một quan điểm có thể gây tranh cãi:
Lý do bạn chưa thấy nhiều tăng trưởng từ GTM Engineering là vì… chúng ta không thực sự đào tạo GTM Engineer.
Con đường PLG-to-sales tiêu chuẩn là:
-
tuyển Business Development Representative
-
prospect từ LinkedIn và Apollo
-
chuyển lead đủ điều kiện cho AE
-
lặp lại
Những đội như vậy tồn tại vì phần lớn startup cần outbound để tăng trưởng.
Tôi từng xây dựng và vận hành motion này tại IBM và Firebolt.
Nó hiệu quả.
Nhưng đắt.
Và mất thời gian ramp.
Railway tăng trưởng bằng sản phẩm và marketing.
Chúng tôi không cần xây đội đó để đạt quy mô hiện tại.
Điều quan trọng:
Thông điệp không phải “hãy thay đội sales bằng một câu SQL query.”
Mà là:
Nếu bạn là công ty PLG và đã có product telemetry, rất có thể bạn đang ngồi trên một danh sách warm account cực kỳ giá trị mà chưa hề nói chuyện với họ.
Lời khuyên cụ thể nếu bạn đang ở giai đoạn sớm hơn
Đây là điều tôi sẽ nói với phiên bản mình thời còn ở Looker.
(Biên tập viên: Railway hưởng lợi khi doanh nghiệp trên Railway phát triển tốt, nên họ chia sẻ miễn phí các insight này.)
Instrument event data ngay từ ngày đầu
PostHog hoặc công cụ tương đương. Cái giá của việc không có historical event khi cần đến rất cao.
Đừng quên retention window của SaaS tool
Nhiều công cụ hành vi chỉ giữ khoảng 90 ngày lịch sử event. ETL dữ liệu ra warehouse.
18 tháng sau bạn chắc chắn sẽ có câu hỏi mà UI của vendor không trả lời nổi.
Brute-force feature trước khi model hóa
Tính hết mọi dimension.
Loại bỏ tín hiệu deterministic
Chúng sẽ làm mô hình trông chính xác giả tạo.
Giữ score dễ hiểu
Weighted sum tuyến tính dễ đọc có giá trị hơn black-box classifier.
Kết lại: sau email là gì?
Phần cuối cùng, cũng là phần tôi thấy thú vị nhất, là chuyện gì xảy ra sau khi khách hàng trả lời email.
Chúng tôi xây hai ứng dụng nội bộ để rút ngắn khoảng thời gian đó.
Ứng dụng đầu tiên bọc quanh DocuSign.
Khi Rahul kết thúc cuộc gọi và chốt điều khoản, anh ấy không cần mở template, tìm đúng pháp nhân hay ping ops để tạo redline.
Anh ấy chỉ điền order form trong công cụ nội bộ do đội operations tự xây.
Ứng dụng thứ hai kết nối entitlement với sản phẩm.
Đó là cả một bài viết khác.
Nhưng đây mới là phần tôi nghĩ nhiều công ty PLG nên học:
Khi bạn đã có data plumbing để tìm đúng account, chi phí biên để dùng chính hệ thống đó cho việc chốt sales và provisioning gần như rất nhỏ.
Như chúng tôi đã nói từ đầu:
Giàn khoan dầu vốn đã ở đó. Chúng tôi chỉ cuối cùng cũng đưa dầu vào nhà máy lọc.