呢個財務問題有訊息嘅成分
應收帳款天數——由開發票到收到款嘅平均時間——主要係一個商業同流程問題：付款條款、早付折扣、催收政策、信貸控制。訊息只係入面其中一個槓桿,唔係全部答案。已驗證渠道可以減少摩擦,令提醒更容易被信任同採取行動,但唔會保證縮短應收帳款天數。任何將訊息當成解決方案,而唔係付款條款、信貸決策同升級流程本身嘅收款計劃,都會令人失望。
以下係點樣設計收款訊息序列、需要邊啲控制,同埋應該老實咁量度啲咩。
點解普通 SMS 同電郵喺呢個場景表現唔好
電郵——事務性財務內容經常跌入垃圾或者促銷資料夾,亦冇可靠訊號證明有被睇過。普通 SMS——可以用,但一個冇品牌嘅陌生號碼,喺市場俾促銷 SMS 塞爆嘅情況下,好難同詐騙訊息分開。語音通話——每次接觸成本高,亦要靠對方接聽。
呢個唔代表已驗證渠道就解決咗收款問題,而係話如果收件人清楚見到係邊個發嘅,而且可以一步搞掂,提醒被閱讀同信任嘅機會會高啲。
「已驗證」喺呢度指咩
已驗證 SMS／RCS Business——一個已登記嘅 sender,顯示品牌名同 logo,支援結構化內容同按鈕,收件人見到嘅係驗證標誌同你嘅品牌,而唔係陌生號碼。
WhatsApp Business template——由已驗證商業帳號發出、預先審批嘅訊息 template,可以包含「立即付款」或者「要求延期」呢類動作按鈕。
兩者都要事先登記同審批,所需時間因市場、供應商同你嘅商業 驗證文件完整度而異——唔係一個固定日數,唔可以以此定死上線日期。要預留審核同可能被拒重交嘅時間,唔好假設一次過就過關。
一套訊息序列，唔係單一提醒
收款序列用幾個各有明確角色嘅獨立訊息效果會好過同一個提醒不斷重複、語氣越嚟越急。
1. 到期前提醒（到期日前幾日）
- 講：發票號碼、金額、到期日,同一個俾佢付款或者查看發票嘅連結。
- 唔好講：任何暗示發票已逾期或者要即刻行動嘅字眼——因為仲未到期。
- 前提：發票仍未付款,而且到期日仲未到。如果發訊息前已經入咗數,呢條訊息就唔應該出。
2. 到期通知（到期日或者翌日）
- 講：中性咁講發票已經到期、金額,同付款連結。
- 唔好講：任何似威脅或者暗示後果嘅字眼——呢只係例行通知,唔係升級。
- 前提：發送時仍未付款,盡量喺接近發送時間先核實。
3. 逾期提醒（到期後若干日,時間由你嘅信貸政策決定）
- 講：發票已逾期、重申金額同合約入面實際列明嘅條款（如果有合約列明嘅逾期費）,同付款連結。
- 唔好講：任何冇合約支持嘅內容——唔好暗示法律行動、信貸報告或者合約冇列明嘅費用。
- 前提：仍未付款,理想情況下亦要檢查客戶有冇已經聯絡過（客服 ticket、承諾付款、爭議）——唔應該喺已有對話嘅情況下再自動發逾期通知。
4. 升級
- 講：你嘅信貸政策實際規定接落嚟做咩——通常係轉去人手接觸（打電話或者客戶經理),而唔係再發一個自動訊息,有時亦會配合一封較正式嘅書面通知。
- 唔好講：呢一步唔應該由 template 帶出新嘅主張,應該跟返現有升級流程,同（如適用）法定收款流程,唔應該喺訊息文案入面自行創造一套。
- 前提：經過之前所有步驟後仍未付款,同埋你信貸政策要求嘅內部批核。
實際間隔要按你嘅信貸條款同司法轄區調整——冇一套通用節奏適用於所有發票類型或者客戶關係。
按付款狀態 suppress：要避免嘅失效模式
自動化收款流程入面最傷嘅失效,係不斷追一張已經俾咗錢嘅發票。呢個通常喺以下情況出現：付款狀態嚟自一個有延 遲更新嘅系統（例如隔夜批次處理),但提醒排程比更新頻率更密;紀錄咗部分付款,但提醒邏輯淨係睇一個二元嘅已付／未付欄位;付款俾錯咗發票或帳戶,而呢個落差喺下一次排定發送前冇被發現。
解決方法係架構性嘅,唔係一個訊息設定：將發票／付款狀態當成唯一真相來源,盡量喺接近發送時間先核實,令訊息層做嗰個狀態嘅消費者,而唔係一個獨立、靠舊快照運行嘅排程器。如果你嘅付款系統做唔到接近即時嘅狀態,就要有人手暫停選項,喺接近付款限期時對自動發送保持保守。
Consent 同法律依據
收款訊息唔會純粹因為關乎一筆未付款項,就自動豁免 consent 同營銷規則。視乎司法轄區同渠道：關於已存在債務嘅服務性／事務性訊息,一般同營銷訊息有唔同嘅法律依據,但具體邊啲算事務性、要出咩披露、要提供咩退訂,因國家同渠道而異——WhatsApp 同 RCS 各自仲有自己一套 template 分類規則,係喺一般訊息法之上再加嘅。渠道要求 opt-in 嘅情況下（大部分設定下嘅 WhatsApp Business template）,你需要有攞到嗰個號碼嘅法律依據,同埋有紀錄證明嗰條渠道嘅 consent 係點取得。Quiet hours——限制喺特定時段內聯絡人嘅規定——喺唔少市場都存在,有時明確針對追數聯絡,應該編碼成發送系統強制執行嘅規則,唔應該逐個 campaign 靠人手判斷。
呢個唔可以取代針對你所在市場嘅法律意見。Flowstates 可以幫手將呢啲做成營運控制——時段規則、consent 紀錄、分類、suppression 邏輯——但唔提供法律合 規服務本身,呢個判斷要由你同你嘅法律顧問決定。
渠道 fallback
已驗證 RCS 同 WhatsApp 嘅覆蓋唔係全面嘅——手機支援、營運商鋪開進度同各人 opt-in 狀態都唔一樣。可行嘅序列需要喺主要渠道對某個收件人唔可用時有備援路徑：通常係普通 SMS 或者電郵,承載同樣核心資訊（金額、到期日、付款連結),唔假設較豐富格式一定顯示得到。呢個 fallback 邏輯要事先定好,唔好喺主渠道失敗時靜靜漏咗提醒。
要量度啲咩
追蹤結果,唔係得個「送達數」得個睇：付款完成率——喺指定時間窗口內,提醒後跟住有付款嘅比例;付款所需時間——由某條訊息之後到付款發生（如果有發生）之間隔咗幾耐;點擊到付款——撳咗付款連結嘅人入面,幾多真正完成付款,冇完成嘅喺邊一步流失;回覆、投訴同退訂率——收款訊息嘅投訴或者退訂率上升,係要檢視頻率同語氣嘅訊號,唔係應該繞過嘅嘢;錯發提醒率——即已經俾咗錢或者有爭議嘅發票仍然收到提醒嘅頻率,呢個應該接近零,要明確追蹤,因為佢最能反映你嘅 suppression 邏輯有冇失效。
呢啲數字喺唔同行業、發票金額同客戶關係之間都唔會一樣,我哋亦冇一份 足以代表你自己業務嘅數據可以公佈目標範圍。轉換渠道前後,用你自己嘅基準做比較先有意思。
訊息層擺喺邊
做得好嘅團隊會將提醒序列當成整個收款流程入面嘅一環,而唔係外加嘅一個功能：發票同付款狀態嘅單一真相來源;跨渠道意識（唔好喺客戶已經喺一個渠道回覆或者付款之後再用另一個渠道打擾）;喺付款、爭議同有人手接觸嗰陣做 suppression;一個最終由人,而唔係由 template 擁有嘅清晰升級路徑。
Flowstates 可以營運呢一層訊息——喺有嘅市場用已驗證渠道發送、管理 sender 註冊同 template 審批、執行 suppression 同 quiet hours 規則、渠道唔可用時乾淨咁 fallback——無論係用我哋直接供應嘅容量,定係你已經有合約嘅路由,或者兩者混合。