例外
利用量の集計の根拠が不確かなとき
勝手に金額を埋めず、確認が必要と表示して人が検証できるようにします。
従量課金の請求
利用量の集計、プランの超過、請求の問い合わせ、決済の失敗。課金まわりのやり取りをVelros AIが受け止め、返信の下書きまで整えます。
運用診断
請求の準備時間
請求の問い合わせ件数
決済失敗の復旧率
オンラインの一人創業者は、月末ごとに利用量をスプレッドシートに集めてStripeの請求書と手で突き合わせ、請求の問い合わせが来ればまたログをひっくり返します。利用量のイベント・料金プランの設定・請求の明細・問い合わせが別々にあり、超過やミスを後から見つけます。請求がずれると、信頼と売上が同時に漏れます。
こうしたデータが、こう整理されます。
実際に入ってくる仕事を集め、それぞれの段階で何を基準に判断するのかまで続けて残します。
-
利用量・請求の信号収集
利用量のイベント・料金プランの超過・請求の問い合わせ・決済の失敗を一つのキューに集めます。
判断 アカウントの識別子で利用量と請求をまとめる。同じアカウントの数字を散らさないため。 -
利用量の集計・突き合わせ
アカウントごとの利用量を集計し、料金プランの上限・請求の明細と突き合わせます。
判断 集計と実際の請求がずれる件を先に上げる。請求の前に捉えないと過大・過少の請求につながるため。 -
請求要約の下書き
請求の要約・超過の案内・問い合わせへの回答の下書きを作ります。
判断 金額は付けず、根拠だけを整理して上げる。金額の確定は人の役目。 -
決済失敗・精算の準備
決済失敗の再試行と精算の資料を整理して人に上げます。
判断 請求が出る実行は準備だけして、確定は人へ渡す。 -
請求の追跡カード
アカウント・利用量・請求の状態・次のアクションを載せたカードを作り、未解決として追跡します。
判断 終結の条件(請求の確定・問い合わせの解決)を付けて、キューから消えないようにする。
根拠が不確かなら、金額を確定しません。
現場で実際に引っかかる例外を、あらかじめ決めておきます。ルールが通らない場面を無理に処理せず、根拠とともに人へ渡します。
例外
超過が一時的な不具合と疑われるとき
すぐに請求せず、原因確認のリストとして上げて、人が判断できるようにします。
例外
請求の問い合わせと返金の依頼が混ざるとき
請求の確認を主のケースとして開き、返金の判断は別に分けて人に上げます。
請求の金額とクレジットは、人が確定します。
お金・契約・個人情報・ブランドがかかる実行は下書きまでにとどめ、送信と確定は人の承認を経てから動きます。
-
請求金額の確定
お金が絡む核心の判断なので、常に人が確定します。
-
料金の調整・クレジットの付与
先例となる金銭の調整なので、人の役目です。
-
大量の請求の送信
一度出ると訂正が煩わしいため、人が検収してから送ります。
-
超過料金の追加請求
顧客のカードに請求が出る実行なので、元に戻す前に人が確定します。
-
適格請求書・精算資料の確定
誤発行の負担があるため、人が検収します。
何で確かめるか
請求が正確で速かったかで見ます。
請求の準備時間
利用量の集計から請求要約の完成までにかかった時間を、導入の前後で実測します。
請求の問い合わせ件数
請求に関する問い合わせの数を、導入の前後で測定します。請求が正確なほど減ります。
決済失敗の復旧率
失敗した決済のうち再び成功した割合を、導入の前後で測ります。
ルール
利用量や決済情報のような機微な個人情報を扱うため、目的に合わせて最小限で保管し、請求の金額と発行は人の確認のあとに確定します。
人が自分で抱えていた仕事が減ります。
散らばった確認と繰り返しの返信を先に整理して上げれば、スタッフは確認と例外の処理に集中でき、人は大事な判断だけを見ます。
運用診断確認が人のところに積み上がります。
月末ごとに利用量をスプレッドシートで集めて請求書を手で合わせ、問い合わせが来ればまた確認します。
処理の準備ができた状態で上がってきます。
利用量と請求の問い合わせが一つのキューに集まって要約まで用意され、金額は人が確定します。
請求の準備の時間
請求の問い合わせの件数
決済失敗の復旧率
この業務を任せる前に、よく聞かれること
従量課金の請求について、実際に最初に確認されることを集めました。
請求の金額をVelrosが確定しますか。
利用量の集計と請求の要約は準備しますが、実際の請求金額の確定と送信は人が確認してから実行します。
料金プランを超えた顧客へ自動で請求しますか。
超過の案内の下書きまでを上げ、追加の請求や料金プランの引き上げは人が判断します。
適格請求書もここで発行しますか。
発行に必要な項目別の利用明細を整理して上げ、実際の発行の確定は人が検収してから進めます。
