IOSOR 知識庫

RFP 問題與公開費率表對照

區分 RFP 承諾與公開費率表。依已發布牌價、Live 閘門與錢包真相購買預付費 CPaaS,而非事後才發明牌價的客製報價。

買家常在開啟 RFP 時要求「最優費率」,但公開費率表早已標明 list。這種混用會製造兩套真相:試算表裡的承諾,以及正式發布的費率表。預付費 CPaaS 採購在 list 留在 Pricing、Live 受閘門約束、且 RFP 只問費率表無法單獨回答的問題時才成立。

IOSOR 把公開費率表視為商業脊樑。RFP 問題用來驗證營運證據——支出控制、誠實閘門、目錄 Live——而不是另造一本平行價目。若回覆發明私有 list,財務在第一天前就會繼承兩套帳本。把 RFP 評分綁在已發布費率表上——跳過 Live 閘門的旁路報價不是談判勝利。

把牌價留在公開費率表上

要求凡是你將據以計費的走廊與通道價格,都必須出現在試點將使用的已發布費率表上。RFP 附件可以詢問 volume review 門檻與 hold 規則;但不得用一張永遠進不了 Pricing 的一次性表格取代 list。

任何不在費率表上的數字,在正式發布前都標為無約束力。已簽署卻不見於費率表的 RFP 列,是未來發票爭議,不是勝利。

試點採購應把公開費率表匯出後與 RFP 附件並排核對:只出現在談判表、卻未進入 Pricing 的數字一律標為非正式。簽約前再跑一遍目錄 Live 與 vault 對齊,確認綁定範圍沒有「即將上線」徽章。財務與營運共用同一張已發布 list,帳單週才不會各說各話。

在 RFP 提出 Pricing 無法單獨回答的問題

用 RFP 釐清支出上限、錢包 hold、退款路徑,以及目錄上 Live 的定義。詢問用量暴增時 prepaid messaging 支出如何被控制,以及誠實文案如何對齊平台從不承諾的界線。

走廊分厘價格留給費率表。RFP 掌管流程,而不是營運無法在控制台引用的影子價目表。

簽署前拒絕雙重商業真相

若業務報出一張表、Pricing 顯示另一張,凍結簽署直到單一負責人發布。雙重真相會拆毀 prepaid hold:財務依卡 A 儲值,發送卻依卡 B 扣款。

要求書面指定試點期間費率表更新負責人。聊天說「稍後再同步」,往往就是發票週出現兩套說法的開端。

把採購閘門綁到目錄 Live 誠實度

買預付費就是買當下 Live 的產品。詢問目錄 Live 如何對齊 vault 就緒狀態,以免徽章賣出無法發送的通道。RFP 寫「所有走廊皆可用」必須對應 Live 閘門,而不是期望。

試點範圍只列 Live 產品。即將推出的磁貼屬於路線圖附錄,不屬於具約束力的採購時程。

相關營運路徑

從 IOSOR 開始

請開啟 IOSOR 定價主控台,確認採購清單中的每個通道都直接對應至公開費率表上的有效項目。在進行錢包加值之前,請確保您的測試專案門檻已設定為參照已發布的費率表版本字串,而非離線附件。在簽署合約之前,請確認每個目標通道在目錄中皆標示已驗證的「上線」徽章。 RFP 評分必須綁定已發布費率卡;繞過 Live 門檻的旁路報價不算談判勝利。 公開費率卡與 vault 對齊的 Live 閘門必須同時出現在 RFP 評分表上,缺一不可。

IOSOR 要點

建議書雖用於規範治理、錢包保留門檻與退款路徑,但絕不應成為與訊息定價脫節的獨立儲存庫。當離線銷售報價偏離已發布的定價項目時,系統保留額會依過期數字計算,而即時流量則會根據當前平台費率扣款。務必堅持所有計費費率皆須列於公開費率表中,且合約簽署應綁定已發布的版本標籤。切勿接受未直接反映於執行主控台中的自訂定價附件或未經驗證的離線試算表。

這篇指南有幫助嗎?

相關指南