Từ một kỹ năng đến dịch vụ có người trả tiền: cách thử ý tưởng trên Xianyu

Thay vì viết một bộ cài tự động hay làm hẳn một website, Lany thử cách đơn giản hơn. Anh đăng một dịch vụ triển khai OpenClaw từ xa lên Xianyu (闲鱼, nền tảng mua bán đồ cũ và dịch vụ của Alibaba tại Trung Quốc), với giá thử nghiệm 29,99 tệ.

Sau đó listing có 41 người bấm “想要” (Muốn mua/Muốn có) và mang về tổng cộng khoảng 500 tệ.

500 tệ không phải một khoản thu nhập lớn. Điều đáng chú ý là nó trả lời được ba câu hỏi quan trọng: có người thực sự gặp vấn đề này, có người chịu trả tiền để giải quyết nó, và người bán có thể hoàn thành kết quả đã hứa.

Từ trải nghiệm đó, Lany tổng kết lại một quy trình khá thực dụng để biến một kỹ năng thành dịch vụ có thể bán được.

Đừng bắt đầu bằng câu hỏi “mình biết làm gì?”

“Tôi biết lập trình”, “tôi biết dùng AI”, “tôi biết deploy server” đều là những mô tả về kỹ năng, nhưng chưa phải dịch vụ.

Khách hàng không mua danh sách kỹ năng của bạn. Họ đang có một vấn đề và muốn biết bạn có giải quyết được hay không.

Trong trường hợp OpenClaw, vấn đề khá rõ:

• Người dùng đã biết OpenClaw và muốn sử dụng nó.

• Họ đang mắc ở bước cài đặt hoặc cấu hình.

• Vấn đề có thể được giải quyết bằng remote support.

• Kết quả có thể kiểm tra ngay sau khi hoàn thành.

Lany mô tả dịch vụ của mình bằng một câu:

Tôi giúp những người muốn sử dụng OpenClaw nhưng đang mắc ở khâu cài đặt và cấu hình, thông qua hỗ trợ từ xa để chương trình có thể chạy được.

Có thể dùng cùng cách này cho những dịch vụ khác:

Tôi giúp [nhóm người nào] giải quyết [một vấn đề cụ thể] bằng [cách thực hiện] để đạt được [một kết quả có thể kiểm tra].

Ví dụ, thay vì nói “tôi biết WordPress”, có thể bán dịch vụ chuyển một website WordPress từ server cũ sang server mới.

Thay vì “tôi biết Obsidian”, có thể nhận sắp xếp một đống tài liệu hiện có thành knowledge base có cấu trúc.

Thay vì “tôi biết Markdown”, có thể nhận chuyển một bài Markdown dài thành nội dung đã được định dạng để đăng lên một nền tảng cụ thể.

Phạm vi càng rõ thì càng dễ viết listing, báo giá và biết lúc nào một yêu cầu đã vượt ra ngoài dịch vụ mình đang bán.

Biến kỹ năng thành thứ người khác thực sự có thể mua

Trước khi đăng một dịch vụ, Lany cho rằng nên làm rõ ít nhất bảy thứ.

Điểm quan trọng nằm ở cột cuối cùng.

Một dịch vụ không chỉ cần nói mình làm gì mà còn phải nói rõ mình không làm gì. Nếu phần này mơ hồ, một công việc dự kiến mất 30 phút rất dễ biến thành vài tiếng troubleshoot và support.

Mức giá 29,99 tệ của Lany cũng chỉ là giá để thử thị trường. Nếu chỉ tính thời gian thao tác 30–60 phút, doanh thu gộp chỉ khoảng 30–60 tệ mỗi giờ. Tính thêm thời gian tư vấn trước khi bán, chờ khách và hỗ trợ sau đó thì còn thấp hơn.

Giá thấp có thể hữu ích để giảm rào cản cho vài đơn đầu tiên, nhưng không nên mặc định nó là mức giá lâu dài.

Trước khi đăng, xem người khác đang bán như thế nào

Xianyu có mục “看别人发的”, có thể hiểu là “Xem người khác đăng gì”. Thay vì viết listing ngay, Lany khuyên nên xem khoảng 10 dịch vụ tương tự trước.

Không phải để copy.

Thứ cần tìm hiểu là cách thị trường này đang giao tiếp với người mua.

Có thể lấy 5 listing có nhiều tương tác và 5 listing gần nhất với dịch vụ mình định bán, sau đó ghi lại:

Comment và Q&A đặc biệt hữu ích vì đó là nơi những điểm chưa rõ trong listing xuất hiện.

Nếu nhiều người cùng hỏi “Mac có cài được không?”, “giá này đã gồm kết nối Telegram chưa?” hay “sau khi update bị lỗi thì có hỗ trợ không?”, đó chính là những thông tin nên được đưa vào listing của mình ngay từ đầu.

Chia dịch vụ thành những package dễ hiểu

Một dịch vụ có nhiều phiên bản thì không nên giấu tất cả mức giá trong một đoạn description dài.

Trong ví dụ của Lany, dịch vụ có thể được chia thành:

• Chỉ kết nối Feishu.

• Chỉ kết nối WeChat.

• Feishu + WeChat.

• Một lần support/troubleshoot sau bán hàng.

Ví dụ giá được đặt như sau:

Các mức giá này chỉ là ví dụ của tác giả, không phải bảng giá khuyến nghị.

Cách chia package giúp khách dễ so sánh hơn và người bán cũng bớt phải báo giá lại cho cùng một loại nhu cầu. Quan trọng hơn, những thứ như thêm channel hoặc troubleshoot sau bàn giao không còn mặc nhiên trở thành việc miễn phí trong gói cơ bản.

Gói có giá thấp nhất phải là một dịch vụ thật, có thể mua và hoàn thành độc lập. Không nên đặt một mức giá rất thấp chỉ để lấy click rồi buộc khách phải mua gói đắt hơn.

Số lượng cũng nên phản ánh khả năng làm việc thực tế. Nếu mỗi tuần chỉ đủ thời gian hoàn thành năm đơn thì không có nhiều lý do để đặt tồn kho 999 đơn.

Listing chỉ cần trả lời đúng những điều khách muốn biết

Title mà Lany sử dụng khá đơn giản:

OpenClaw 本地远程部署服务
Dịch vụ triển khai OpenClaw local từ xa

Nó có tên công cụ, cách thực hiện và loại dịch vụ.

Một cấu trúc tương tự có thể là:

[Tên công cụ hoặc vấn đề] + [kết quả] + [loại dịch vụ]

Ảnh đầu tiên cũng không cần quá cầu kỳ. Người xem chỉ cần mất một hoặc hai giây để hiểu mình đang nhìn vào dịch vụ gì.

Phần description nên trả lời được những câu hỏi cơ bản:

Dịch vụ làm gì?
Hỗ trợ hoàn thành việc gì và kết quả cuối cùng là gì.

Dành cho ai?
Người dùng đã làm được đến đâu và hiện đang mắc ở đâu.

Làm bằng cách nào?
Remote, trực tiếp hay bàn giao file.

Bao lâu?
Cho một khoảng thời gian thực tế, bao gồm cả khả năng phải troubleshoot.

Thế nào được tính là hoàn thành?
Nêu những điều có thể kiểm tra sau khi bàn giao.

Khách cần chuẩn bị gì?
Hệ điều hành, thiết bị, error message, account cần thiết và kết quả mong muốn.

Không bao gồm những gì?
Những việc ngoài phạm vi đơn hàng phải được ghi rõ.

Support đến đâu?
Nói rõ thời hạn và những trường hợp cần báo giá lại.

Một listing càng rõ thì càng ít thời gian phải giải thích lại qua chat.

Đừng nhìn mỗi exposure, hãy nhìn cả funnel

Sau khi đăng, một listing sẽ đi qua bốn bước:

Exposure → Click → Inquiry → Order

Nhìn theo từng bước giúp xác định đúng thứ đang có vấn đề.

Nếu gần như không có exposure, hãy kiểm tra keyword, category và việc listing có phù hợp với quy định của nền tảng hay không.

Nếu có exposure nhưng ít người click, vấn đề có thể nằm ở title, ảnh đầu tiên hoặc giá.

Nếu có click nhưng không có inquiry, người xem có thể chưa đủ tin tưởng hoặc chưa hiểu rõ thiết bị của mình có làm được không, cuối cùng sẽ nhận được gì và nếu thất bại thì xử lý thế nào.

Nếu có nhiều inquiry nhưng không thành order, hãy ghi lại những gì khách hỏi và lý do họ không mua.

Nếu cùng một câu hỏi xuất hiện liên tục, đưa câu trả lời vào listing.

Nếu mỗi người hỏi một thứ hoàn toàn khác nhau, có thể phạm vi dịch vụ vẫn còn quá rộng.

Lany cũng khuyên chỉ nên thay đổi một thứ mỗi lần. Nếu cùng lúc đổi title, thumbnail, description và giá thì ngay cả khi số inquiry tăng lên, cũng rất khó biết thay đổi nào thực sự có tác dụng.

Đừng biến tư vấn trước bán hàng thành troubleshoot miễn phí

Đây là vấn đề dễ gặp với dịch vụ kỹ thuật.

Khách gửi một screenshot lỗi. Người bán bắt đầu hỏi log, gửi command, chỉnh config. Nửa tiếng sau lỗi được giải quyết và khách cảm ơn rồi đi.

Để tránh chuyện đó, trước tiên chỉ cần đủ thông tin để biết có nhận được đơn hay không.

Lany thường hỏi năm câu:

1. Bạn đang dùng hệ điều hành và thiết bị nào?

2. Hiện tại mắc ở bước nào, có error message cụ thể không?

3. Kết quả cuối cùng muốn đạt được là gì?

4. Model và các account liên quan đã chuẩn bị chưa?

5. Có chấp nhận mức giá, phạm vi và điều kiện support hiện tại không?

Sau khi có những thông tin này mới xác nhận có làm được hay không, cần bao lâu và giá hiện tại bao gồm những gì.

Password, verification code và API Key không cần gửi cho người bán. Khi remote đến bước cần credential, khách tự nhập.

Trước khi bắt đầu phải thống nhất thế nào mới gọi là xong

“Cài OpenClaw thành công” nghe có vẻ rõ nhưng thực ra vẫn còn nhiều cách hiểu.

Chương trình khởi động được là xong?

Hay model phải trả lời được?

Có bao gồm kết nối Feishu, Telegram hay các channel khác không?

Nếu sau khi cài xong khách muốn thêm một channel thì đó là support hay một yêu cầu mới?

Với gói triển khai OpenClaw cơ bản, Lany đưa ra những điểm nghiệm thu cụ thể hơn:

• Chương trình khởi động bình thường.

• Thực hiện thành công một lần gọi model đã thống nhất.

• Nếu package có cấu hình channel thì channel đó phải connection test thành công.

• Khách biết configuration file, startup command và cách sử dụng cơ bản nằm ở đâu.

Trong quá trình remote, password, verification code và API Key do khách tự nhập. Secret không được đưa vào chat log, screenshot hay public repository.

Nếu phát sinh việc ngoài phạm vi, dừng lại và xác nhận trước khi làm tiếp.

Sau khi hoàn thành, khách tự test ngay tại chỗ. Nội dung xác nhận phạm vi và nghiệm thu nên được giữ lại trên nền tảng.

Một đơn giá rẻ không thể đi kèm support vô hạn

Dịch vụ kỹ thuật có một đặc điểm khó chịu: công việc có thể quay trở lại sau khi tưởng như đã hoàn thành.

Khách tự sửa config, cài lại hệ điều hành, upstream update version hoặc third-party API thay đổi đều có thể khiến một hệ thống đang chạy bình thường bị lỗi.

Vì vậy trước khi nhận đơn cần thống nhất:

• Support kéo dài bao lâu.

• Loại lỗi nào thuộc đơn hàng cũ.

• Thay đổi nào được tính là yêu cầu mới.

Một điều khoản đơn giản có thể nói rằng support chỉ xử lý lỗi cài đặt và khởi động trong phạm vi lần triển khai này. Cài lại hệ điều hành, tự thay đổi config, upstream update, third-party API thay đổi và feature mới cần được đánh giá lại.

Khi báo lỗi, khách nên gửi thời điểm xảy ra, các bước đã thực hiện, screenshot và log liên quan. Không gửi password, verification code hoặc API Key đầy đủ.

Nếu một lỗi xuất hiện nhiều lần ở nhiều khách khác nhau, đừng tiếp tục xử lý nó từ đầu ở từng đơn.

Đưa nó vào FAQ, checklist, script kiểm tra hoặc installation SOP.

Đơn hàng sau nên dễ làm hơn đơn hàng trước.

Những dịch vụ phù hợp để thử theo cách này

Theo Lany, một dịch vụ phù hợp để validation nhanh thường có vài đặc điểm:

• Vấn đề cụ thể và kết quả kiểm tra được.

• Có thể hoàn thành phần chính trong một đến hai giờ.

• Những đơn đầu tiên có thể làm thủ công.

• Sau đó có khả năng chuẩn hóa.

• Không cần bỏ tiền mua inventory lớn từ đầu.

• Nếu thất bại thì thiệt hại thấp.

• Không liên quan đến trách nhiệm hoặc rủi ro quá lớn.

• Nền tảng có category phù hợp.

Environment setup, website migration, format conversion, data cleanup hay tổ chức knowledge base đều là những ví dụ phù hợp.

Ngược lại, custom development kéo dài nhiều tuần, yêu cầu chưa rõ phạm vi, công việc cần giấy phép chuyên môn hoặc có trách nhiệm tài chính lớn không phải lựa chọn tốt cho lần thử đầu tiên.

Có thể đăng phiên bản đầu tiên trong một giờ

Lany chia một giờ đầu tiên như sau.

10 phút đầu, tìm 10 listing tương tự. Ghi lại title, ảnh, giá, package và những câu hỏi trong comment.

Từ phút 10 đến 20, viết được câu “Tôi giúp ai giải quyết vấn đề gì”, sau đó xác định kết quả bàn giao và những gì không bao gồm.

Từ phút 20 đến 35, viết listing, upload ảnh và điền thời gian, support, dịch vụ bổ sung, cách tính giá, khu vực và hình thức bàn giao.

Từ phút 35 đến 50, tạo các package, thiết lập giá và số lượng thực tế.

10 phút cuối, kiểm tra lại category, description, giá thấp nhất, khác biệt giữa các package, privacy và phạm vi support.

Trước khi publish, cần chắc chắn listing không chứa account của khách, địa chỉ server, thông tin liên hệ riêng tư, password hay API Key.

Sau khi đăng thì bắt đầu thu thập inquiry thật.

Đừng quay lại viết một sản phẩm hoàn chỉnh ngay lập tức.

Checklist trước khi publish

• Title có keyword hoặc tên công cụ mà khách thực sự search.

• Nhìn ảnh đầu tiên có thể hiểu dịch vụ đang bán gì.

• Description nói rõ khách hàng, kết quả và thời gian.

• Gói rẻ nhất là một dịch vụ thực sự có thể mua độc lập.

• Các package khác nhau rõ ràng.

• Số lượng phù hợp với khả năng bàn giao.

• Support có thời hạn và phạm vi cụ thể.

• Không có account, địa chỉ, password, API Key hay thông tin riêng tư của khách.

• Có sẵn những câu hỏi cần hỏi trước khi nhận đơn.

• Có cách kiểm tra rõ ràng để xác nhận công việc đã hoàn thành.

Trong bảy ngày đầu, mỗi ngày chỉ cần dành khoảng 10 phút ghi lại:

Exposure → Click/Muốn mua → Inquiry → Order

Funnel mắc ở đâu thì sửa ở đó. Không cần thay tất cả mọi thứ cùng một lúc.

500 tệ không phải phần quan trọng nhất

Dịch vụ OpenClaw của Lany cuối cùng chỉ mang về khoảng 500 tệ.

Với giá 29,99 tệ và mỗi đơn mất 30–60 phút thao tác thủ công, bản thân mô hình đó cũng có giới hạn khá rõ về thu nhập.

Nhưng thử nghiệm đã trả lời được một câu hỏi quan trọng hơn tiền.

Có người đang gặp vấn đề này, họ sẵn sàng trả tiền để giải quyết nó, và dịch vụ có thể bàn giao được.

Nếu inquiry và order tiếp tục tăng, lúc đó mới có lý do để đầu tư vào environment checker, installation script, bộ cài tiêu chuẩn, package troubleshoot nâng cao hay dịch vụ bảo trì.

Trước khi có khách trả tiền, rất khó biết những thứ đó đang giải quyết nhu cầu thật hay chỉ là thứ developer nghĩ rằng người khác sẽ cần.

Vì vậy, nếu có một kỹ năng hoặc ý tưởng muốn thử kiếm tiền, chưa nhất thiết phải bắt đầu bằng việc làm sản phẩm.

Có thể bắt đầu nhỏ hơn.

Đóng gói một vấn đề thành một dịch vụ có phạm vi rõ ràng. Đưa nó đến nơi đã có người tìm kiếm. Thử hoàn thành một giao dịch thật.

Rồi mới quyết định thứ gì đáng để tiếp tục xây.