我哋不斷見到嘅規律
同企業級訊息買家傾偈,一個靜靜嘅轉變好明顯。2015 至 2022 年嘅預設架構——單一 CPaaS 用一個 API 處理 SMS、語音、WhatsApp 同電郵——正被拆散。
取而代之嘅唔係另一個產品類別,而係將本來一齊買嘅三個決定分開：
- 應用程式——你發咩訊息、發俾邊個、點解要發。
- 路由供應——邊個提供去到目標網絡嘅連接。
- 訊息營運——路由策略、sender 註冊、監測、供應商升級同報表。
打包式 CPaaS 用一份合約回答晒三個問題。一旦訊息量喺商業上開始有份量,買家就會開始逐個分開回答,因為每個問題「啱嘅答案」變化速度都唔一樣。
1. 單位成本變得清晰
流量細嘅時候,每條訊息嘅價錢係個誤差範圍,方便就值得畀錢。流量大咗,就變成一個有人負責嘅成本項,買家開始問價錢入面幾多係連接本身、幾多係上面嗰層平台。呢個差距有幾大,完全睇目的地、流量類別同談判條款——冇一個統一數字,話俾你聽一個數嘅人係喺度靠估。重點係佢唔再係隱形嘅。
2. 供應商集中度變成必問嘅問題
任何單一供應商都可能表現轉差——某個營運商嘅路由、某個地區平台出事、某次登記爭議。改變嘅唔係開始有事故,而係買家而家會將「呢個供應商突然停用六個鐘會點」當成一個要有書面答案嘅問題。採購部門想要：多個渠道有多個供應商、可以唔使重新談合約就轉路由、對每條路由表現有直接能見度。單一供應商架構令呢三樣都變難,無論供應商係邊個。
3. 合規地圖變得更複雜
美國品牌同 campaign 註冊、RCS 同 WhatsApp sender 上線流程、對訊息內容同紀錄嘅數據保護審查——發送周邊嘅營運範圍擴大咗,而且大部分係實際工作,唔係設定選項。買家想搵個負責呢啲工作嘅人,而呢個人唔應該同時係唯一可以提供流量嘅供應商。
「託管閘道」實際上係咩
呢個詞包含好多內容。實際上,託管閘道係：一個根據目的地、流量類別、路由健康同成本決定邊條路由處理每條訊息嘅路由引擎；一層追蹤 DLR、轉化、延遲同每條路由成本嘅監測；一個負責供應商升級、註冊同事故回應嘅營運團隊；同埋一個俾應用程式用嘅單一 API,唔理背後有幾多個供應商。
呢個模式刻意唔會逼你揀邊個供應路由——閘道下面嘅路由由誰供應（閘道營運方、買家自己直接簽約,定係混合）唔影響營運層點運作。呢個分離正正就係重點：你可以換供應商而唔使改變營運方式,亦可以改變營運方式而唔使重新談供應。
BYOV 嘅位置
BYOV（自帶供應商）就係買家已經有直接關係、想保留自己談到嘅每條訊息成本嗰種情況下嘅做法。閘道接駁去現有嘅 SMPP 或者 HTTP 連接,接手路由、監測同升級。
呢係其中一個選項,唔係終點。有啲買家永遠都唔想自己管供應商關係,寧願直接向操作閘道嗰一方買路由。亦有唔少買家兩樣都做：大部分目的地用供應路由,喺有實際議價能力或者監管理由要自己持有連接嘅地方,就自己簽合約。
對產品團隊嘅影響
如果你喺訊息之上做產品,有三樣嘢會變：API 穩定性變得更重要——當路由層可以獨立於應用程式重新平台化,API 合約就變成長遠承諾；能見度變成採購準則——當你要比較多個供應商,按路由、按營運商嘅儀表板唔再係加分項;供應商揀選變成季度討論,而唔係幾年一次嘅決定——當你可以幾分鐘內轉路由,採購周期會縮短,營運紀律亦會收緊。
對 CPaaS 供應商嘅影響
CPaaS 唔會消失——對初創產品、低流量、冇採購資源嘅團隊嚟講依然係啱嘅答案。改變緊嘅係上限。冇一個放諸四海皆準嘅流量門檻令買家轉身;觸發點通常係一件具體事件——一次嚴重事故、一次價格檢討、某個市場打包路由表現實在唔掂——而唔係圖表上嘅一條線。
回應得好嘅供應商正將自己重新定位為批發級基建：更好嘅 API、更緊嘅 SLA、更少附加服務。回應唔好嘅就繼續加碼打包式賣點。
Flowstates 嘅位置
我哋營運訊息層，亦都可以供應底下嘅路由。客戶可以揀三 種模式其中一種：向我哋買渠道同路由、保留自己嘅供應商合約由我哋操作（BYOV）,或者兩者結合。無論邊種模式,我哋負責嘅嘢都一樣——路由策略、sender 註冊、監測、供應商升級同報表——供應安排係一個你可以隨時改嘅商業決定,唔使重新整合你嘅應用程式。