IOSOR

IOSOR Kiến thức

STOP và HELP trên DID thuê: chính sách mà hỗ trợ có thể bảo vệ

Cách đội B2B viết chính sách từ khóa STOP/HELP trên số thuê — quyền sở hữu, cách diễn đạt, nhật ký audit và sự thẳng thắn prepaid mà không lệ thuộc cổng bên thứ ba.

Từ khóa không phải autoresponder dễ thương. Trên DID thuê có thể nhận trả lời, STOP và HELP là chính sách tuân thủ và thương hiệu — kịch bản mà hỗ trợ phải bảo vệ được lúc 02:00 mà không bịa kiến thức bộ tộc. Nhắn tin hai chiều thiếu chính sách đó trở thành hàng đợi sự cố im lặng.

IOSOR giữ inbound trên cùng bề mặt white-label prepaid với outbound: quan hệ thương hiệu, đường inbox, ví của bạn — không kẹt ops hàng ngày trong cổng bên thứ ba.

Từ khóa là chính sách, không phải nhiệm vụ phụ của bot

Sản phẩm, pháp lý và hỗ trợ nên ký một trang trước lần gửi hội thoại đầu tiên:

Từ khóa Kết quả bắt buộc Owner
STOP / hủy đăng ký Opt-out được tôn trọng kịp thời; đã ghi log Compliance + messaging ops
HELP / thông tin Đường brand-safe: giờ, kênh, leo thang Lead hỗ trợ
START / tiếp tục (nếu dùng) Re-opt chỉ với ngôn ngữ đồng ý rõ Sản phẩm + pháp lý
Lệnh chiến dịch Tùy chọn; không bao giờ ghi đè STOP Owner chiến dịch

Nếu STOP «thường chạy», bạn không có chính sách — bạn có may.

Viết ngôn ngữ STOP mà hỗ trợ đọc to được

Phản hồi STOP phải ngắn, hướng thương hiệu và rõ ràng:

  • Xác nhận opt-out áp dụng cho chương trình / danh tính này
  • Nói điều gì dừng lại (cảnh báo, lớp marketing, luồng DID này)
  • Chỉ đường người thật nếu khách vẫn cần giúp
  • Tránh đổ ID kỹ thuật hoặc tên thương hiệu bên thứ ba

Log: ai gửi STOP, DID nào, khi nào được tôn trọng, lớp outbound nào bị chặn. Leo thang hỗ trợ phải kéo log đó từ nền tảng của bạn — không săn ảnh chụp màn hình.

HELP khớp giờ thực tế

HELP là nơi thương hiệu hứa quá.

  1. Giờ hỗ trợ thực và múi giờ
  2. Kênh bạn thực sự xếp ca (email, chat, callback) — không ảo tưởng
  3. Khách cần ghi gì (4 số cuối, id đơn)
  4. Bước tiếp nếu không ai online

DID thuê trả lời HELP bằng email chết dạy người dùng phàn nàn to hơn trên mạng xã hội — và đốt niềm tin nhanh hơn OTP muộn.

Ownership và dấu vết audit

Chỉ định owner chính và backup. Khi STOP hỏng production, đó là sự cố tuân thủ, không phải ticket «chỉnh bot».

Yêu cầu:

  • Webhook MO hoặc sự kiện inbox mà stack bạn xác minh được
  • Xử lý idempotent (retry xảy ra)
  • Tương quan: từ khóa inbound → id khách → trạng thái suppressions
  • Quy tắc lưu giữ thân từ khóa có thể chứa PII

White-label nghĩa là agent ở một bề mặt thương mại. «Check cổng kia» không phải mô hình vận hành.

STOP/HELP sụp khi nhận và gửi bị coi là SKU không liên quan.

  • DID thuê có thể nhận MO và gửi nơi quy tắc cho phép
  • Assignment nằm trên tài khoản sau mua — không treo đến khi ai đó click chỗ khác
  • Đích webhook khớp nền tảng bạn đã dùng cho outbound

Đường số của IOSOR là prepaid và vừa kịp: tìm, giữ, mua, gán. Sẵn sàng từ khóa thuộc câu chuyện assignment đó.

Cờ đỏ

  • Phản hồi STOP gọi tên cổng công ty khác
  • Giờ HELP không khớp nhân sự
  • Không có log lúc opt-out được tôn trọng
  • Marketing sửa từ khóa live không review compliance
  • Claim hội thoại live trong khi inbound vẫn in setup
  • Lỗi client đổ thương hiệu upstream

Bắt đầu với IOSOR

Soạn một trang STOP và HELP mà hỗ trợ đọc to trên DID thuê. Nối cả hai từ, chứng minh mỗi từ một dòng kiểm toán, và đặt tên HELP ngoài giờ. Đây là chính sách nói trên một số, không cô lập danh sách từ chối giữa thuê bao, không chấm rác lúc nhận, không kiến trúc hộp thư hai chiều.

Bài: vòng auto-reply inbound Đệm xử lý webhook inbound chống độ trễ từ nhà mạng giữ trước số dư trả trước trước lần ghi nợ đầu tiên.

Điểm chính IOSOR

STOP và HELP là chính sách nói trên DID thuê, không đồng bộ từ chối đa thuê.

Làm: viết lời hỗ trợ đọc được và chứng minh dòng kiểm toán. Đừng: coi từ khóa là nhiệm vụ phụ của bot hoặc đồng bộ danh sách từ chối của thuê khác ở đây.

Hướng dẫn này có hữu ích không?

Hướng dẫn liên quan