我們以「真正到達」
為唯一指標。
我們的堅持 — 不是口號，是每次發送的底線。
你發出的每一則訊息，我們都會 100% 全量向電信網絡提交送出請求，這是關鍵承諾，而且每筆發送紀錄都可在儀表板查核。我們不會為了壓低成本而少送你已委託的訊息，保證不虛報「發送成功」。
每一筆都附電信商級送達回報（DLR），帶狀態與原因碼。凡回報未送達收件人的訊息，我們會與電信商追查，並以可追溯的報告向你說明 — 看的是實際送達，也有報告可查。真正到達，才是我們唯一承認的標準。
全量提交承諾：進線 = 提交
每筆附電信商 DLR
DLR 透明回拋
每一條訊息都有電信商真實送達回報，附電信商級錯誤碼。不是「submitted = success」。
{
"message_id": "msg_01HF8K7Z9TX2",
"to": "+852•••••567",
"status": "DELIVERED",
"carrier": "direct_route",
"submitted_at": "2026-05-28T08:14:22Z",
"delivered_at": "2026-05-28T08:14:23Z",
"latency_ms": 1247,
"error_code": null
} 金融服務客戶可收到每月匯總報告 — 送達率、平均延遲、電信商級分項。
全量提交保證 (關鍵承諾)
你經 API 送出的每一個發送請求，我們承諾如實向電信商提交 — 不暗中丟棄、不偷減筆數、不把「API 已接受」和「已送進網絡」混為一談。
不少企業換過供應商後才發現：儀表板上的「已送出」與自己系統的請求日誌對不上；高峰時流量默默被限；月結筆數少了一截，卻難以舉證。我們把這件事寫進服務承諾：我們接受的請求數 = 我們向電信網絡提交的次數 — 可在儀表板即時對帳，亦可匯出供內部稽核。DLR 告訴你電信商之後怎麼處理；這項承諾告訴你，流量在離開我們平台前沒有被吃掉。
API 回傳成功，但實際進入電信商隊列的筆數對不上；請求日誌與供應商報表無法逐筆核對。
1 個已接受的發送請求 = 1 次向網絡提交。之後失敗由 DLR 誠實回報 — 但提交本身不會少做。
不走灰路
灰路是較便宜的第三方轉發，會隱藏寄件人身份。電信商可偵測，送達默默下滑，而你從「submitted」報告看不出來。
我們以 SS7 直連全球各區電信商。每條訊息成本較高 — 但這正是 DLR 真實的原因。
「submitted」被當作成功。真實送達率 60–75%。無法稽核哪些訊息真的到達。
電信商確認送達回報。正當流量 95%+ 送達率。其餘誠實匯報。
合規
- PDPO（香港個資例）：個人資料僅用於你委託的用途，僅保留合規期內，按要求提供資料存取支援。
- OFCA 短訊發送人登記制：我們代你登記
#Sender ID 並維護。 - GDPR：對有歐盟資料主體的客戶，我們作為 SCC 標準合約條款下的資料處理者。
- 台灣個資法 / 中國網路安全法：跨境發送的合規上線流程中按區域處理。
- ISO 27001：認證流程進行中。
我們對誰說不
可接受使用政策（AUP）是信任訊號，不是法律附錄。
我們拒絕：釣魚短訊、冒充銀行 / 政府 / 電信商的訊息、無收件人同意的冷推、未受規管的投資推介（pump-and-dump）、以及使用不屬於寄件人的 Sender ID。
如果潛在客戶的用例引發疑慮，由合規團隊在簽約前審核。這是我們保護其他客戶送達率的方式。