業務:大量の月末請求

月末のカード請求業務が、ヌケモレなく実施されるようになった!

それぞれのお客様への「請求金額」について、、、いつ誰が入力し、いつ誰が承認したのか、全てがリアルタイムに捕捉できるようになった。しかも、クレジット会社 API (Stripe API)にアクセスしてくれる「自動工程」のおかげで、ワークフローシステムからダイレクトにカード課金される。つまり、経理システムへの「二重入力」といった二度手間もなくなった。

課題:人間依存の低減

しかし、、、この業務プロセス(第556話)は、いまだ「人間のデータ入力」に依存している。つまり、肝心の「課金額」の入力については人間(担当営業)が担当している。

たしかに、「お客様情報」は自動でセットされているし、「カード請求コード」(Stripe CustomerID)だって予めセットされている。更には「請求作業の一覧」もヌケモレなく引き受け待ちリストに表示されているので、複数人で協調して請求作業を行うこともカンタンになっている。つまり「入力の省力化」については、かなり高いレベルで実現できているとは思うのだが。。。

もっとも「課金額」(請求額)の情報は、ワークフローシステムから見て「外部システム」にあたる「売上管理システム」にある。なんとかして売上集計を自動取得させることはできないものか? (「APIエコノミー」が叫ばれる今日、業務プロセス改善の行きつく先は「無人化」だと思う。。。)

[クレジットカード課金プロセス-再帰呼出&全自動]


業務:毎月のカード課金

月末の請求業務が、大幅に省力化された!

新しいワークフローアプリでは、担当営業が登録した「今月の請求金額」が部長承認されれば、そのまま自動的に「クレジットカード課金」が行われる。経理サイドが「請求書の印刷/押印/郵送」といった作業を行う必要はナイ。当然ながら「銀行入金確認」といった作業もイラナイ。Stripe 万歳! API エコノミー万歳! Questetra 万歳!

ちなみに、お客様にも好評だ。

「請求書の承認」や「振込の手続」といった実作業がなくなった事(!)もさることながら、費用明細が「通知メール」で確認できるのがイイ(!!)、らしい。(ペーパレス)

(「銀行API」も早くオープン化されればイイのに…)

課題:誰に請求してないか?

ただ、、、現状では「全てのお客様に請求できたか?」が分かりにくい。

たしかに『1r.課金額の入力』からワークフローを手動開始(再利用開始)するだけだ。しかし、その開始を「手動」に依存すると、たとえば「前月請求したお客様全員にヌケモレなく請求する」が実現しづらいのだ。

請求件数が増えれば、いつの日か「請求し忘れ」が発生するだろう。。。(ハテサテ)

[クレジットカード課金プロセス-再帰呼び出し]

業務:登録カードへの課金

「クレジットカード登録」の仕組みはできた! (前回記事参照)

『カード番号』や『CVC』といったカード情報は Stripe 社(決済代行会社)に預けられ、ワークフロー側にはその「預かり番号」としての『Stripe Token』(tok_{24文字})だけが流れる仕組みだ。つまり、日本政府が「2018年3月までにクレジットカード情報の非保持化を!」と言っている要件についても満たすことができたと言える。(非保持化=カード情報保護のための第一の対策)

コレで「自社システムからカード情報が漏洩するリスク」はゼロになったと言ってもイイ! 安心して Web 登録してもらえる!!

※ Stripe Token は一度の処理にしか使えない仕様(single-use token)となっており、この例では『Stripe Token』から『Stripe CustomerID』(cus_{14文字})への自動変換も同時に行われています。(自動工程「Token to Cus_ID」)

課題:課金オペレーションにおける手作業の排除

しかし、良く考えてみれば、、、実現したのは「カード情報の保護」だけだ。

たとえば『課金金額』を間違えたり、たとえば『課金相手』を間違えたり、、、そんな「課金オペレーション」のミスリスクについては、ゼロになっていない。たとえば「Xさんのメールアドレス」に「Yさんの名前宛」で課金予告を送ってしまったとか、、、、考えるだけで寒すぎる。「課金業務フロー」における
  • お客様の名前
  • お客様のメールアドレス
  • Token or CustomerID
あたりのデータは、自動的にあらかじめ入力されているようにしたい。そうなっているだけでミス率はゼロに近づくハズだ。下流工程でチェックを担当する「頼りない上司」の負担も、少しは軽減されるだろう。

[クレジットカード課金プロセス]