DEVELOPERS BLOGデベロッパーズブログ
- HOME >
- 牧山 直紀のデベロッパーズブログ >
- マッチングサイトの課金モデル
牧山 直紀のデベロッパーズブログ
- 氏名
- 牧山 直紀
- 役職
- 代表取締役
- 血液型
- O型
- 出没
- 主に南国
- 特色
- サメが好き
- 2016/06/02
- WEBメディア運用事業の開始します
- 2015/11/25
- オウンドメディアとは?構築費用、作り方、運用などに関して解説
- 2015/10/08
- ポータルサイト・マッチングサイトの構築に関するあるべき見積もり方法
マッチングサイトは扱う分野によって課金額が異なり、課金モデルが異なる
マッチングサイトは扱う分野によってビジネスモデルが大きく異なります。
扱う分野によって、扱う金額がまず大きく異なり、扱う金額が異なれば、課金の方法、タイミングなどもまた分野ごとに変わってきます。
当ページでは、扱う金額によりどのような課金モデルが考えられるのか?というところに焦点を絞って解説をしていきます。
扱う金額が大きい場合
扱う金額が大きければ必然的にクライアントも個人ではなく企業形態の比率が高くなり、手数料を徴収する際にクレジット決済を導入しても企業という理由、また決済金額が大きいという理由でクレジット決済ではなく、銀行送金を予期したシステムにする必要があります。
扱う金額が大きい場合は、必然的に徴収できる金額も大きくなります。徴収できる金額が大きいと、それだけそこに人件費を投下することが可能となります。
というよりも、受発注間で動く金額が大きい場合には、それなりに人が介入する必要が有るケースが多く、そこに人件費を投下する必要があるという方が正しいかもしれません。
不動産や建築関連、人材紹介のマッチング(求人サイトではない)などは、動く金額が大きいのでそれに比例して、WEB上でさくっと発注、成約が決まらず、そこに至るまでに面談などオフラインでの商談、やり取りが必要になってきます。
こうなると、課金モデルとしては、以下の2つに絞られてきます。
●反響発生時に課金する
オフラインでの商談ありきのような大きな金額を扱うマッチングの場合、成約まで追いかけるのは簡単ではありません。
そこで、成約時ではなく、問い合わせ1件、反響1件に対して課金をする、という課金方法が考えられます。
引っ越し一括見積サイトは、高額になるケースもあれば、少額になるケースもあり、成約を把握するまでの経費はかけられないというビジネスモデル上、この反響発生時にて課金をしています。
皆さんが引っ越しされる際に、一括見積サイトを利用すると、その一回の見積もりに対して、5社ほどに見積もり内容が送付され、その見積もりを受け取った5社の引っ越し業者は、その引っ越し一括見積サイトから、いくらか課金されている、と考えるとなんだか不思議な気分になりますね。
この反響発生時課金は、成約時に徴収するような成約料金に対して○○%という大きな手数料は望めませんが、問い合わせ発生時に確実に課金が出来、把握も容易になります。
ただ、完全成果報酬ではなく、半成果報酬なので、受注側から見て、明らかな冷やかしの問い合わせなども当然発生してくるので、それらも含めて請求から除外するなどの運用機能も必要になってくるでしょう。(課金が発動するサイトであれば、当たり前に必要な気のですが、、、)
●成約時に課金する
一旦オフラインにて商談が始まっているのにもかかわらず、成約をしっかりと把握するために、発注者に対してお祝い金などを発行して、成約の連絡をしてもらい、成約時に課金するという方法もあります。
言い方は悪いのですが、お祝い金は、完全成果報酬モデルには必須の「成約告げ口機能」の役割なのです。受注者はレアではありますが、成約は黙っておこう、、、というケースもあります。
そこに発注者に対して、このサイトを通じて成約すれば、〇〇万円あげますよ!としておけば、そのお祝い金欲しさに、発注者は運営事務局に「成約したのでお祝い金下さい」と連絡を入れ、運営者はお祝い金を発行する代わりに成約を把握することが出来るのです。
一聞完全なビジネスモデルに聞こえそうですが、そうではありません。
この成約時課金、つまり完全成果報酬型の場合、一旦オフラインになっているユーザを常にサイトに意識付けることが必要になってきます。
なぜなら、お祝い金を発行しているのにもかかわらず、お祝い金を申請してこない発注者がそこそこ存在するからです。不思議ですが、実際に起こり得るのです。
サイトを通じて成約してるのにもかかわらず、お祝い金を申請してこない理由として、お祝い金があることをそもそも知らなかった、というのが最大の理由となります。
サイトの目立つところにその仕組みを設置して、かつ発注者がアクションを起こした際に自動返信メールで配信するメールに目立つように明記しても、忘れる、見落とすユーザは多いようです。
ただそれも次の方法で、ある程度漏れの数を軽減できることがわかっています。発注者に対しての電話での確認です。反響発生時から起算して、1週間、2週間、1か月、3か月と決めておき、電話にて確認をする方法です。
この場合、運営者の管理画面内の、反響管理などに、反響発生時から1週間、2週間、1か月、3か月経過しているものをすぐに閲覧できるようにして、電話をしたかどうか履歴を残せるようにしておけば、便利ですね。
運営者は日々業務として、管理画面にログインすると、「おっ、今日はこれだけの発注者に、成約したかどうかの電話をかければOKね。がんばろっと!」という具合に運用が可能ですね。
その電話と並行して、ステップメールを送るのも効果的です。これも反響発生時から起算して1週間、2週間、1か月、3か月など、または電話での確認日とは少しずらして、自動で「成約していたらお祝い金申請してくださいね」とメールを送ってあげる事で、発注者に成約している場合の通達を促すことが出来るのです。
このように扱う金額の大きいマッチングサイトの場合、クレジット決済が必要ない分、システムはシンプルになるかと思えば、意外とシステマチックになるのですね。
ただ、初期運用時からそれだけの成約を把握するためのツールが必要になるかと言えばそうではなく、反響が実際に多くなってきたときの追加実装で十分だと思います。
そもそも運用が大変になるぐらい反響が発生していれば、それを軽減するためのツールを前向きに発注いただけると思いますからね。うれしい悲鳴という事です。
これは余談ですが、実際に弊社のお客様で、担当者が毎日4時間かかっていた業務を、運営管理画面を少し拡張しただけで、15分まで縮小できたケースも実際にあります。
扱う金額が小さい場合
扱う金額が小さな場合、受注者からすると成約しても発注者から支払われる金額が小さいため、毎月の固定費用や、反響毎に手数料を支払うのを嫌がります。
また運営者からすると、銀行送金だけでは入金確認や、その他入金催促などの実務を考えると無理があり、クレジット決済機能が必要となってきます。また、扱う金額が小さい場合、よりサイトに対する行動のリアルタイム性が高くなるため、入金関連のタイムラグによってユーザに与えられるストレスはマッチングシステムにとって致命的なロスとなってきます。
扱う金額が小さいという事は、そこから得られる手数料も小さなものになりますので、そこに対して経費を使うことが出来ません。
ですので、出来るだけ人の手を介さないように、様々な機能にて自動化をする必要が有ります。
反響から商談、成約まですべてWEB上で完結させることで、受発注者間の直接やり取りを避け、支払いもすらもWEB上で完結をさせてしまいます。翻訳、ライティングなどがいい例です。オフラインでのやり取りは必要ありません。WEB上のメッセージボードで完結が可能です。
ただ、実際に当事者間が会う必要のある分野ではすべてをWEB上で行うのは難しいですね。金額が小さくてもオフラインでの商談が必要なケースも少なくありません。通訳などがいい例です。金額は小さくても、絶対に当事者間が会う必要が有ります。中には複数人から面接をしたいというケースもあるでしょう。
その場合、反響毎に手数料を支払うのを嫌がる、と文頭で書きましたが、少額決済システムなどで、反響毎に手数料を支払うモデルが必要になってきます。
サイト利用料をデポジットという形で購入してもらいポイントを発行して、反響毎に一定ポイントが減算され、都度決済の手間を軽減させてあげる事も可能です。
とにかく、手数料として徴収できる金額が小さいため、課金箇所は自動化する必要がある、と結論付けられます。
結局言いたいことは・・・
長くなりましたが、まとめると、扱う分野が決まったらまず課金モデルをしっかりと考えることが重要で、この課金モデルの在り方がサイトの仕様を大きく左右し、また同時にサイトの構築ボリュームにも大きく関係してくる、という事でした。
上記で例に挙げた課金パターンはほんの一部で、他にも様々なパターンが考えられますからね。
予算的に、課金管理まで作りこむのが難しい場合は、運営初期は大変でもアナログで管理をすればいいと思います。最初はエクセル管理でも、扱う件数が少なければ問題ありません。
扱う件数が多くなるタイミングは、、、きっとサイトが軌道に乗っていることでしょう。
現在マッチングサイトの構築を考えており、課金モデルに行き詰っている方がもしこの記事を読んでいただけたら、是非お気軽に相談してくださいませ!
関連エントリー
- 2015/10/08
- ポータルサイト・マッチングサイトの構築に関するあるべき見積もり方法
- 2014/10/07
- ウェブメディア・ポータルの成功事例
- 2014/05/21
- 過度な構造的SEOもやりすぎはNG!!
- 2014/03/21
- 低価格でマッチングサイト・ポータルサイトの構築も出来る!
- 2014/01/20
- アナログが必要不可欠なマッチングサイトのビジネスモデルもある
- 2013/12/15
- クラウドソーシングの構築に関して
- 2013/05/14
- 求人サイトにおける成約の把握機能「お祝い金」
- 2013/05/07
- マッチングサイトのデザインの在り方
- 2013/05/01
- ポータルサイトの成功事例よりも失敗事例から学ぶ
- 2013/04/16
- ポータルサイトの設計:多機能が故にユーザを遠ざけてしまっている
- 2013/04/15
- 求人サイト、人材マッチングサイトのビジネスモデル
- 2012/12/19
- マッチングサイトはオープンソースでは妥協の産物になる可能性が高い
- 2012/12/05
- マッチングサイトとポータルサイトの違い
2020/12/15
2020/11/12
2020/10/05
2020/09/11
2020/08/03