Bot Telegram bán hàng: Tự động hóa shop hiệu quả

Bot Telegram bán hàng là công cụ tự động hóa trên Telegram giúp shop giới thiệu sản phẩm, nhận thông tin đơn, trả lời câu hỏi lặp lại và nối các bước xử lý trong một workflow. Một phiên mua hàng có thể bắt đầu từ menu sản phẩm, đi qua bước chọn số lượng và phương thức thanh toán, rồi chuyển sang xác nhận đơn hoặc gửi cho nhân viên. Một dự án Telegram shop bot trên GitHub còn mô tả luồng chọn ngân hàng, tạo mã QR VietQR, xác nhận thanh toán và gửi sản phẩm; đây là ví dụ triển khai, không phải khả năng mặc định của mọi bot. Bài viết này giúp bạn phân biệt bot trả lời với bot bán hàng, xác định dữ liệu cần lưu như sản phẩm, tồn kho và trạng thái đơn, rồi lập quy trình triển khai cho shop Việt. Bạn cũng sẽ thấy các giới hạn cần tính trước, từ API Token đến bước đối soát thanh toán, cùng cách kết hợp n8n và RevidAPI khi workflow cần tạo nội dung hoặc media.

Tóm tắt nhanh

• Bot có thể nhận đơn qua menu và tin nhắn, nhưng thanh toán QR cần tích hợp provider hoặc quy trình xác nhận riêng.
• Một flow mẫu gồm chọn sản phẩm, chọn số lượng, chọn ngân hàng, tạo QR và xác nhận thanh toán.
• Checklist triển khai bắt đầu từ API Token, câu trả lời tự động, dữ liệu đơn hàng và điểm chuyển nhân viên.

Một tin nhắn “mua sản phẩm A” trong Telegram có thể kích hoạt cả chuỗi xử lý: hiển thị giá, hỏi số lượng, ghi thông tin người nhận và cập nhật trạng thái đơn. Bot Telegram bán hàng là lớp tự động hóa thực hiện chuỗi đó bằng lệnh, nút menu, tin nhắn và các kết nối phía sau, thay vì để nhân viên trả lời từng lượt.

Bot bán hàng khác gì bot trả lời và CRM?

Bot trả lời thường xử lý câu hỏi cố định như “phí ship bao nhiêu?” bằng kịch bản hoặc từ khóa. Bot bán hàng đi xa hơn: nó giữ ngữ cảnh

của cuộc trò chuyện, biết khách đang chọn sản phẩm nào và chuyển sang bước xác nhận đơn. Ví dụ,

sau khi khách chọn 2 áo, bot có thể lưu `product_id`, `quantity` và yêu cầu nhập địa chỉ. Bot CRM tập trung vào hồ sơ và lịch sử khách hàng, chẳng hạn nhãn `lead`, lần mua gần nhất hoặc chuỗi follow-up. Workflow automation lại là cơ chế nối các sự kiện giữa nhiều hệ thống: một tin nhắn mới có thể tạo dòng trong Google Sheets rồi gửi thông báo cho nhân viên. Hai loại này có thể đứng sau bot bán hàng, nhưng không đồng nghĩa với giao diện chat trên Telegram.

Token, trạng thái và điểm chuyển người Bot cần một bot token để Telegram nhận diện ứng dụng; token này thường

được lấy khi tạo bot và phải giữ ngoài mã nguồn công khai. Phần logic hội thoại quyết định khách đang ở bước nào, còn dữ liệu sản phẩm cần tối thiểu mã hàng, tên, giá và tồn kho. Đơn hàng cũng nên có trạng thái rõ như `new`, `awaiting_payment`, `paid` hoặc `cancelled`, thay vì chỉ lưu một đoạn tin nhắn. Khi khách hỏi yêu cầu ngoài kịch bản, khiếu nại hoặc cần tư vấn nhiều điều kiện, bot nên gắn trạng thái `handoff` và chuyển cuộc trò chuyện cho nhân viên. Telegram chỉ là kênh tương tác; bot không tự trở thành nền tảng thương mại điện tử có kho, thanh toán, vận chuyển và báo cáo hoàn chỉnh. Các phần đó vẫn cần hệ thống phía sau hoặc thao tác thủ công.

Từ xem sản phẩm đến tạo đơn Bot Telegram bán hàng có thể biến cuộc trò chuyện thành một luồng mua hàng cụ thể: khách bấm nút xem catalog, chọn sản phẩm, nhập số lượng rồi để lại thông tin nhận hàng. Một dự án Telegram shop bot trên GitHub mô tả cả luồng chọn ngân hàng, tạo mã QR VietQR, xác nhận thanh toán và gửi sản phẩm. Với shop chưa có cổng thanh toán, bước cuối có thể chỉ là ghi đơn ở trạng thái “chờ xác nhận” để nhân viên kiểm tra. Phần hỏi đáp phù hợp với các câu lặp lại như “áo này còn size M không?”, “phí giao đến Đà Nẵng bao nhiêu?” hoặc “đổi hàng trong mấy ngày?”. Bot chỉ trả lời đáng tin khi dữ liệu tồn kho, bảng phí và chính sách có nguồn cập nhật; nếu nhân viên sửa giá trong Google Sheets nhưng workflow không đọc lại sheet, câu trả lời vẫn có thể sai. Sau khi khách gửi tên, số điện thoại, địa chỉ và sản phẩm, bot có thể tạo một bản ghi đơn rồi trả về mã đơn. Trạng thái “đang đóng gói” hay “đã giao” không tự xuất hiện: nó phải

được lấy từ kho, sheet, CRM hoặc hệ thống riêng. Với câu hỏi ngoài kịch bản, bot nên có nút chuyển sang nhân viên thay vì tiếp tục đoán. Thanh toán cũng không phải mặc định có sẵn trong Telegram. Shop có thể gửi QR, nhận ảnh biên lai và chờ xác nhận thủ công, hoặc nối provider có webhook để cập nhật giao dịch. Một bài hướng dẫn về bot Telegram bán hàng cũng mô tả các phần như API Token, trả lời tự động và quản lý nhóm; đó là lớp cấu hình, không phải bằng chứng rằng mọi bot đều có sẵn kho, CRM hay thanh toán.

Một workflow thực tế nên đi từ nhu cầu mua hàng đến xác nhận đơn rồi chuyển cho nhân viên khi có ngoại lệ, thay vì bắt đầu bằng danh sách tính năng. Với shop bán sản phẩm, bạn cần chốt trước dữ liệu tối thiểu: mã sản phẩm, tên, giá, tồn kho, số lượng, tên khách, số điện thoại, địa chỉ và trạng thái đơn như `new`, `waiting_payment`, `paid`, `cancelled`.

Workflow từ nhu cầu đến xử lý đơn

Bot chạy được không có nghĩa dữ liệu đang an toàn. Token lấy từ BotFather có quyền điều khiển bot; nếu đặt thẳng trong file `.env` bị commit lên Git hoặc gửi qua nhóm chat, người khác có thể chiếm quyền gửi tin và đọc luồng xử lý. Bạn nên lưu token trong secret manager, phân quyền kho dữ liệu theo vai trò, che số điện thoại và địa chỉ trong log. Khi nghi token bị lộ, dùng `/revoke` trong BotFather để cấp token mới, rồi cập nhật secret và kiểm tra các webhook đang hoạt động. Thanh toán tự động là điểm dễ tạo đơn sai. Một flow có QR VietQR thường đi qua các bước chọn ngân hàng, tạo mã, xác nhận thanh toán rồi mới gửi sản phẩm; README của một dự án Telegram shop bot mô tả đúng chuỗi này. Bot cần webhook từ cổng thanh toán, mã giao dịch duy nhất và cơ chế idempotency để callback gửi hai lần không giao sản phẩm hai lần. Giao dịch pending, hết hạn QR, sai số tiền hoặc ngân hàng báo thành công nhưng webhook chậm đều phải có trạng thái riêng để đối soát thủ công.

Khi hội thoại vượt khỏi kịch bản Bot trả lời tốt câu “đơn #A102 đang ở trạng thái nào” nếu dữ liệu trạng thái còn đúng. Nó dễ thất bại khi khách gửi ảnh sản phẩm lỗi, đổi địa chỉ

sau khi đóng gói hoặc khiếu nại đơn có nhiều lần trao đổi. Vì vậy, nút “Gặp nhân viên” nên chuyển cả `user_id`, mã đơn, lịch sử tin nhắn và dữ liệu đã thu thập; chỉ chuyển mỗi câu cuối khiến nhân viên phải hỏi lại từ đầu. Workflow còn phụ thuộc uptime của Telegram, máy chủ bot, kho dữ liệu và dịch vụ thanh toán. API có giới hạn và có thể trả lỗi tạm thời; dữ liệu đầu vào như giá hoặc tồn kho sai cũng làm bot trả lời sai rất nhanh. Hãy đặt timeout, retry có giới hạn và ghi `request_id` cho mỗi đơn, thay vì retry vô hạn. Khi bot không hiểu, trả về cùng một câu “vui lòng thử lại” ba lần sẽ làm khách bỏ cuộc. Thiết kế fallback với ba lựa chọn cụ thể: gửi lại menu, nhập mã đơn hoặc chuyển nhân viên; nếu dịch vụ tích hợp tạm ngừng, bot nên báo “chưa xác nhận được thanh toán” và giữ đơn ở trạng thái chờ, không tự báo đã mua thành công.

Các tình huống dưới đây là kịch bản minh họa, không phải số liệu doanh thu, tỷ lệ chuyển đổi hay số đơn thực tế. Điểm cần hình dung là bot Telegram bán hàng nối các thao tác quen thuộc của shop thành một luồng cụ thể: khách chọn sản phẩm, gửi thông tin, thanh toán hoặc đặt lịch, rồi nhận phản hồi tương ứng.

Shop sản phẩm số: bán và giao tài nguyên sau thanh toán Một shop bán khóa học, preset ảnh hoặc tài liệu PDF có thể đưa catalog vào menu bot với tên sản phẩm, giá và nút chọn. Sau khi khách chọn số lượng hoặc gói học, bot thu email nhận tài nguyên và chuyển sang bước xác nhận thanh toán. Kịch bản trong một dự án Telegram shop trên GitHub mô tả luồng chọn sản phẩm, chọn ngân hàng, tạo mã QR VietQR, xác nhận thanh toán rồi gửi sản phẩm; shop có thể dùng Google Sheets để đối chiếu trạng thái thay vì giao file ngay khi khách chỉ bấm “đã chuyển khoản”. Tin nhắn sau mua nên chứa đúng tài nguyên hoặc liên kết có thời hạn, chẳng hạn file ZIP và hướng dẫn tải trên Google Drive. Nếu giao dịch chưa

được xác nhận, bot trả về trạng thái “đang kiểm tra” và lưu mã đơn để nhân viên xử lý, thay vì gửi lại sản phẩm nhiều lần khi khách nhấn nút.

Shop bán lẻ: lọc nhu cầu trước khi chuyển người thật Với shop bán mỹ phẩm, đồ gia dụng hoặc phụ kiện điện thoại, bot có thể hỏi theo thứ tự: khách cần sản phẩm nào, ngân sách khoảng bao nhiêu, màu hoặc kích thước, rồi mới hiển thị nhóm phù hợp. Ví dụ, khách tìm ốp lưng iPhone có thể chọn model “iPhone 15”, màu đen và mức giá dưới 200.000 đồng; các câu trả lời này

được đính kèm khi chuyển cuộc trò chuyện cho nhân viên. Nhân viên không phải hỏi lại từ đầu, nhưng bot cũng không nên tự kết luận các trường hợp như hàng đổi trả hoặc sản phẩm có nhiều biến thể. Một nút “Gặp nhân viên” và mã yêu cầu như `REQ-2409` tạo điểm bàn giao rõ ràng; phần tồn kho và phí giao hàng vẫn cần lấy từ nguồn dữ liệu shop trước khi báo khách.

Cửa hàng dịch vụ: đặt lịch, nhắc lịch và chăm sóc sau buổi hẹn Salon tóc, studio chụp ảnh hoặc trung tâm sửa laptop có thể dùng menu ngày–giờ để nhận lịch, sau đó lưu tên khách, số điện thoại, dịch vụ và thời lượng dự kiến. Khi khách chọn “19:00, thứ Bảy”, bot chỉ nên xác nhận nếu khung giờ còn trống trong lịch

được kết nối; nếu không, nó đưa ra các mốc thay thế thay vì ghi nhận trùng lịch. Trước buổi hẹn, bot gửi nhắc gồm địa chỉ, khoản cần chuẩn bị và nút đổi lịch. Sau khi trạng thái chuyển thành “đã hoàn tất”, tin nhắn chăm sóc có thể hỏi khách cần hóa đơn, muốn đặt lần tiếp theo hoặc cần hỗ trợ gì thêm. Đây là kịch bản minh họa; chưa có dữ liệu trong brief để khẳng định tác động lên số lịch hẹn hay doanh thu.

n8n hoặc AI Studio có thể đứng giữa bot Telegram, bảng dữ liệu và RevidAPI: nhận dữ liệu từ một node, rẽ nhánh theo trạng thái đơn rồi gửi kết quả sang node tiếp theo. Phần Telegram không cần nhúng vào đoạn code RevidAPI dưới đây; bạn cấu hình trigger và credential Telegram riêng trong workflow, tránh đưa bot token vào prompt hoặc Google Sheet công khai. Với shop, RevidAPI phù hợp ở những nhánh cần sinh nội dung hoặc media. Chẳng hạn, khi khách hỏi về một sản phẩm mới, n8n lấy tên, giá và thông tin tồn kho từ bảng dữ liệu, gửi phần mô tả sang model chat, rồi chuyển câu trả lời về bước gửi tin nhắn. Nếu cần ảnh sản phẩm, dùng endpoint tạo ảnh; nếu cần video giới thiệu, lấy model từ danh sách video trước khi gọi job. TTS chưa có endpoint trong dữ liệu API được cung cấp, nên không nên dựng node âm thanh dựa trên giả định đó.

Cách nối workflow

1. Tạo API key tại RevidAPI Dashboard, lưu bằng credential hoặc biến môi trường `REVID_API_KEY` trong n8n. Không đặt key trực tiếp trong node Code.
2. Xác định dữ liệu đầu vào gồm `product_name`, `price`, `stock` và `customer_question`. Node bảng dữ liệu chỉ nên gửi các trường cần thiết sang AI, thay vì đẩy cả bảng đơn hàng.
3. Dùng node HTTP Request gọi RevidAPI, sau đó kiểm tra mã lỗi trước khi nối sang bước trả lời Telegram. Bạn có thể tham khảo workflow RevidAPI cho n8n và workflow kinh doanh, hoặc import mẫu tại n8n RevidAPI và AI Studio. Ví dụ dưới đây gọi endpoint chat đã có trong tài liệu RevidAPI. Header `x-api-key` là cách xác thực được hỗ trợ; không suy diễn endpoint nhận tin nhắn Telegram từ đoạn này.

   curl -X POST "https://revidapi.com/v1/chat/completions" \ -H "x-api-key: $REVID_API_KEY" \ -H "Content-Type: application/json" \ -d '{"model":"claude-sonnet-5","messages":[{"role":"user","content":"Viết câu trả lời ngắn cho khách hỏi về sản phẩm: áo thun cotton, giá 199000 đồng."}]}'

   Nếu workflow cần ảnh, gọi `POST https://revidapi.com/v1/images/generations` với `model` và `prompt`; response trả về `id`, sau đó kiểm tra bằng `GET /v1/images/jobs/{id}`. Với video, lấy model từ `GET https://revidapi.com/v1/video/models` rồi theo dõi job qua `GET /v1/video/jobs/{id}`. Kiểm tra tài liệu API trước khi xuất bản workflow vì model, giá credit và trạng thái job có thể thay đổi.

Bot Telegram bán hàng là gì?

Bot Telegram bán hàng là công cụ tự động hóa trên Telegram để giới thiệu sản phẩm, nhận thông tin đơn, trả lời câu hỏi và nối các bước theo workflow. Một dự án GitHub minh họa flow gồm chọn sản phẩm, chọn số lượng, tạo QR VietQR, xác nhận thanh toán rồi gửi sản phẩm.

Có cần biết lập trình không?

Không nhất thiết. Bạn có thể bắt đầu bằng node và workflow mẫu; nếu cần kết nối kho, Google Sheets hoặc logic riêng, shop có thể thuê người triển khai. Khi tạo bot trực tiếp, quy trình thường gồm lấy API Token và cấu hình trả lời tự động.

Bot có tự động nhận thanh toán không?

Có thể, nhưng bot cần payment provider, webhook và bước đối soát. Với thanh toán QR, workflow nên xử lý cả trạng thái chưa nhận tiền, giao dịch thất bại và trường hợp khách gửi ảnh xác nhận nhưng hệ thống chưa ghi nhận.

Shop nhỏ có nên triển khai không?

Nên thử một luồng lặp lại rõ ràng, chẳng hạn gửi catalog và thu tên, số điện thoại, địa chỉ cho một nhóm sản phẩm. Hãy kiểm thử nội bộ trước, rồi mới thêm kho, nhân viên hoặc thanh toán tự động.

RevidAPI hỗ trợ phần nào?

RevidAPI có thể cung cấp tác vụ nội dung, hình ảnh, video, TTS hoặc media cho workflow phù hợp, nhưng không tự thay thế logic đơn hàng Telegram. Bạn nên bắt đầu với một use case, kiểm thử nội bộ và mở rộng từng bước.

Khám phá workflow miễn phí tại AI Tạo ảnh & Video và lấy API key tại API Marketplace RevidAPI.