請求書関連の手作業からの解放。 Scalebase（スケールベース）で実現する、新しい契約管理の形。

「請求額の決定から請求書の発行はとにかく人海戦術で、オペレーションなどあってないようなものだった。」丸一日かかっていた請求書の発行を効率化するきっかけや、カスタマーサクセスとの二人三脚で実現したScalebaseの導入手法について、株式会社Onion取締役の小林祥太様にお話を伺いました。

---

-導入前に抱えていた課題を教えてください。

小林様：
もともと、サービスの請求管理はGoogleスプレッドシートで行っていました。スプレッドシート上にお客様の名前とご利用のプランを一覧化していて、その一覧をもとに請求書は手作りして。100社くらいまではそれでも何とか回っていたんですが、それでも毎月15日と末日に請求書発行があるので、時には丸一日請求書作成に費やすこともありましたね。 それで、顧客が増えるにつれ、これは属人的に続けていたら死んでしまうなと（笑）。

そもそもこのやり方だと、プランが増えたり価格を改定したりするたびにMRR（Monthly Recurring Revenue: 月間経常収益）の集計に時間がかかってしまって、投資家説明にもデータの整備が必要、正しい収益を認識できない、とかなり大変な状況ではあったんです。 それで悩んでいたときに、ちょうどScalebaseのお話をいただきました。

---

オペレーション設計と一体となったプロダクト

-Scalebaseを選定したポイントは？

小林様：
それまで、請求額の決定から請求書の発行はとにかく人海戦術で、オペレーションなどあってないようなものだったので、製品側で標準の業務フローを持っていて、それをもとにオペレーションを考える、というやり方はありがたかったですね。

ほかの製品も見たのですが、海外の製品だったのでオンボーディングは自分たちでやらなければならないという制約があったのと、提案価格がまったく合わなかったのでこれは違うかなと。 その点、リリース初期ではあったものの、オペレーション設計をしてくれて導入も一緒に進めてくれるScalebaseは弊社に合っていると思いました。

-導入プロセスについて教えてください。

小林様：
弊社から1名、アルプ社からも担当者をつけていただき、導入作業を行いました。アルプ社側で業務フロー・具体的なオペレーションを決めていただいて、そこに対して弊社の管理しているデータを当てはめていく形で進みました。 導入は2019年の5月～8月。9月にはもう稼働してたかな。

プロダクトの正式リリース前だったけど（注：Scalebase正式リリースは2019年10月）、いいスピード感で進んだと思う。 スタートアップのプロダクトで、なおかつこちらのあるべき像がきれいに整っていなかったにもかかわらず、導入にあたっての要件整理でつまずくこともなく、スケジュール通りにかっちり進みました（笑）。

---

顧客や製品の情報が ひとつのシステムに蓄積されていくメリットは大きい

-導入効果はいかがですか。

小林様：
ちょうど稼働のタイミングと前後して、担当者が1名請求の業務から離れてしまったんですが、それでも問題なく業務が回るようになりました。これは旧来の運用だったら厳しかったと思うので、ちょうど1人月の削減ですかね？作業負荷を減らせるのは嬉しく思います。

あと、今後に対するインパクトとして、製品の単価を上げていきたいと考えているので、そこのオペレーションが省力化されるのは大きいと思いますね。いろんなプランのお客さんが混在しても、ミスなく請求や収益管理ができるわけですから。 プライシングを考える上でも、顧客や製品の情報がひとつのシステムに蓄積されていくというのはありがたいです。

---

周辺業務まで一括対応できる、サブスクリプション製品管理のプラットフォームへ

-今後のScalebaseに期待することは何ですか。

小林様：
製品管理のプラットフォームとして、営業部門、カスタマーサクセス部門、企画部門、管理部門など製品に携わる人々がScalebaseを見るようになればより良い環境が作れると思っています。前段でプライシングについて触れましたが、現在収益認識や分析はまだSFAに頼っている部分も多いので、いずれはそれらも全て1か所で見られるといいなと。

見積書や発注書の作成など周辺業務のオペレーションも、今後機能として追加されたり、連携できる製品がどんどん増えてシナジーを生んでいくと思うので期待しています。 事業がスケールするにつれてMRRを正確に見るのが難しくなったという経営者は多いと思います。そういった事業者に対してのデファクトスタンダードになれるよう、これからも製品のアップデートを頑張って欲しいですね。