転職サービス有料化アップデート

デザイナー1名 / PM 1名 / エンジニア3名

ある転職サイトのサービスアップデートに伴い、有料化の施策もアップデート致しました。

ログイン後はサービス名含めた全ての要素が閲覧できます。

施策前の有料化の状況

施策前は、基本的に電話で有料化の営業を行っていました(この営業は、現在も併用で行われています)

しかし、よりスマートに有料化に持っていく為、サービスとして有料化プランの画面とシステムを用意することとなりました。

サービスはどの様にマネタイズしているか?

サービスは一般的な転職サイトと違い、求職者と事業者をマッチングして求人を紹介するサービスです。その後採用されたら課金が発生するビジネスモデルです。

スカウトも無ければ、一般的なエージェントサービスと違い年収の30%をいただくような事もありません。

それには、主に以下の理由があります。

スカウトがない理由

  • 主なターゲットの事業者は忙しいので、スカウトを送るのが億劫な人が多いと考えているから
  • IT業界と違い、1日中ずっとパソコンの前にいるわけではないので、スカウトを送るようなサービス設計と相性が悪い

年収の30%をいただかない理由

  • 個人店舗でやっている事業者も多いので、採用にそこまで大きな金額をかけられないから

エージェントサービスですが、年収の30%を頂かない代わりに、全てをインターネットで完結させて、圧倒的に安い採用コストを実現しました。

どの様な料金体系にするか?

サービスの利用金体系は、役職ごとの採用によって異なってきます。

ターゲットとしている求職者の層には、主に4つの役職があり、それぞれに異なる料金体系をとっております。

これにより、月額課金制のデメリットであった、「いい人材を採用できなかったのにお金だけとられた」ということがなくなり、また成果報酬型の「能力にかかわらず同じ料金を請求される」ということがなくなります。

また、初回申し込み時に預かり金として「10万円」をいただいております。

これは、いわば敷金と同じで、プラン解約時に返金されますが、リスクヘッジとしていただく資金となっております。

これを導入することによって、運営側で審査をするということがなくなり、ユーザーに迅速にサービスを提供することが出来るため、ユーザー・運営側両方にメリットがあるものとなっております。

営業資料のブラッシュアップしていく

有料プランの事業者獲得は、営業が直接事業者へ出向いても行っており、その際にもちろん資料を見せながら提案します。

その提案資料をブラッシュアップしました。

後程紹介する有料プランの事業者獲得のためのLPを、この資料を基に作っていくことになる為、提案資料のブラッシュアップはマストで行いました。

まず初めに、私が現在の資料から必要がないテキスト・ページ・画像のチェックを行い、代わりのテキスト、ページ構成を練り直し、Indesignを使いデザインを行いました。

デザインのチェックは、Indesignでページを書き出し、Figmaに張り付けて行いました。

こうすることで、いつでも・誰でもFigma上でコメントを残せて、かつ履歴も残せます。

有料プラン事業者獲得のLPを作成する

提案資料のブラッシュアップが終わったら、有料プラン事業者獲得のためのLPを作っていきました。

このLPは資料とはユースケースが全然違うため、構成を一新して作成しております。

一番多いユースケースとして、「電話営業をしてLPを見た」というケースです。まだまだ走り出して間もないサービスの為、SEOで流入するユーザーも少なく、かといってSEMで有料サロンを獲得するより、電話営業で確実にメリットを訴求した方が獲得率も高いので、現在は電話営業でLPを見るユーザーが多いです。

その為、一番最初にサービスのメリット配置しました。

一番目につきやすいファーストビューに、プラン一覧へのリンクを配置。「預かり金」「職種ごとの採用課金制」という少し変わった料金体系を認知してもらってから、LPにある「申し込み」ボタンを押して新規登録した後、管理画面上のプラン申し込み画面へ移ってもらう遷移としました。

また、詳しい資料を見たいユーザーもいる為、資料のPDFへのリンクを配置。スマホ版では通信制限の事を考え、資料へのリンクに「PDFが開きます」と注釈を加えております。

パターン・ユースケース・フローチャートを言語化していく

有料化の要件定義が出来た段階で、パターン・ユースケース・フローチャートを言語化していきました。

このパターンを元に、エンジニアが必要な機能を実装して、私がFigmaで画面を作っていくという同時進行で制作していきました。

主なパターンとユースケース

  • 無料→有料
    • 無料と聞いて始めて、有料プランを営業から聞いてプランを変更した
      • おそらく一番多いパターン
  • 登録なし→有料
    • 新規営業でLPを見て、そのまま有料プランを契約した
  • 登録している→有料
    • 登録しているがログインしていなくて、LPを見て有料プランを契約したい
  • 有料→無料
    • 採用が終了したので、ひとまず預かり金を返して欲しいから、無料に切り替えた
  • (有料→無料)→有料
    • 無料に切り替えたが、また人が採用したくなったので、再度有料に切り替えた
      • 有料⇄無料はこのローテーションの繰り返し
  • 有料プランA→有料プランB
    • プランが増えたら、将来的に起こり得るパターン
    • とりあえずお試しで初めてみて、よかったからプランをアップグレードした

入金方法はどうする?

パターンも出来てきた段階で、ユーザーにどのように入金させるか考えることになりました。

理想的に言えば、全てクレジットカードで入金してもらいたいところでした。なぜなら、手数料がかかりますが、いつ振り込んだか確認する必要がないからです。

ですが、個人店が多い事業者も多く、クレジットカードを持っていない事もある為、「クレジットカード」「銀行振り込み」の2種類の入金方法を設けました。

画面をデザインしていく

定義する要件が全て決まったので、画面を作りこんでいきました。

事業者側はPCで使っている人が多いため、今回はPC版から作っていきました。

メニューを考える

まず、どのようなメニューを配置するか項目を考えることにしました。要素を分解して、以下のようなメニューにしました。

有料化に関連するメニュー

  • プラン情報
    • プラン一覧
      ここから有料プラン申し込みに移る
    • 現在ご利用中のプラン
      プラン申し込み後、現在契約しているプランを見ることができる
  • 請求情報
    • 会社・請求先情報
      会社情報および請求先情報が登録される
    • お支払い情報
      預り金、採用資金の支払先情報。カード払いと銀行振り込みが選べる
    • 請求・入金一覧
      預り金の預かり証や、採用の請求書、今月と過去の請求一覧が見れる
    • 預り金返金口座
      預り金の返金口座を登録できる

プラン申し込み画面をデザインする

この有料化施策の一番のキモである、プラン申し込み画面をデザインしていきました。

デザインするにあたり、まずは要素分解をすることにしました。主に以下の要素で構成されています。

プラン申し込みの要素

  • 請求先情報
    会社情報、および請求先情報
  • 支払い情報
    採用資金の支払い情報
  • 預り金情報
    預り金の返金先の口座
  • ご確認
    最後の確認画面

「請求情報」と同じ情報を、この申し込み画面で入力します。

「請求情報」で埋めていた場合は、デフォルトで埋まっている設定となっております。

請求先情報をどうデザインするか?

請求先情報は、サービス設計が似ているWantedlyを参考にして、項目を決めていきデザインしていきました。

会社情報は、事業者登録時のヒアリングシートでも聞いている項目な為、記載済みの場合はデフォルトで埋まっている設定としました。

住所登録を簡単にするために、オートコンプリートを導入いたしました。

請求先情報は、会社情報と同じことが多々あると思われたため、「会社情報と同じにする」というボタンを設けました。ここは当初はチェックボックスにする予定でしたが、チェックしたかどうかのデータを保持できないので、ボタン形式としました。

支払い情報をどうデザインするか?

支払い情報は、「クレジットカード払い」「銀行振り込み」の2種類があります。

この画面は非同期通信であるSPAの特性を生かし、タブにしてポチポチと押してもらえれば、支払い方法を切り替えられる仕様としました。

銀行振り込みは指定した口座を表示するだけでよいですが、カード払いの場合、

  • 新しくカード登録して手続する
  • 登録済みのカードを変更して手続する
  • 変更をやめて、既に登録してあるカードで手続きをする

の3パターンのユースケースが考えられたため、デザインは3つ作りました。

預り金返金口座をどうデザインするか?

預り金返金口座は、実装工数削減の為に、以前展開していたECサービスのコンポーネントを流用して、作成しました。

しかしそのまま流用するとトンマナが合わないため、トンマナを揃え、さらにモーダルの画面に最適化したデザインに作り直しました。

確認画面をどうデザインするか?

必要項目を全て入力したら、最後に確認画面に移ります。

項目を一つ一つ確認して、変更したい箇所が出てきた場合のことを考え、項目ごとに「変更する」のボタンを配置し、すぐに該当箇所を変更できるようにしました。

また、最後に利用規約に同意してもらう必要があるのですが、少しでも「楽な」体験をしてもらうために、よくあるチェックボックスを押してもらう形式ではなく、利用規約へのリンクを配置し、「申し込む」を押した時点で利用規約に同意するものとしました。

預り金支払い画面をどうデザインするか?

申し込み完了後、預り金決済画面に移りますが、ここはカード払いと銀行払いで若干異なります。

カード払いの場合、申し込み完了画面と預り金決済画面へ移る文言が表示され、遷移先が決済画面となり、カード情報・金額を確認し「支払いを確定する」ボタンを押すと、決済が走り申し込み完了となります。

銀行振り込みの場合、申し込み完了画面に、支払金額と振込先銀行口座が表示されます。

尚、「プランを申し込んだが、預り金を支払わずに終了した」ケースの場合もあり、その場合プラン一覧画面に、この申し込み画面のモーダルが開くボタンが表示されます。

請求先情報で工夫したこと

請求先情報は、前述の通り「会社・請求先情報」「お支払い情報」「請求・入金一覧」「預り金返金口座」です。

「会社・請求先情報」「預り金返金口座」は決済が走らない為、情報を入力する画面だけ設け、ボタンを押したら情報が変更されるようにしました。

「お支払い情報」は、決済が走る為、まず画面は現在の設定を確認できる画面とし、ボタンを押したらモーダルが起動。決済情報を慎重に確認してできるようにしました。

「請求・入金一覧」は、項目を

  • 内容
    決済の返金や請求書のタイトル。請求書の場合リンクとなっており、クリックすると請求書が開く
  • 発行日
  • 支払い・返金日
    支払期日があるものは、目立つように赤字で表示
  • 料金
  • 支払い・返金情報
  • 預かり証

の6つで要素分解しました。

ただ横長の画面はスマホでは使いづらい為、ここはPCとスマホで大きくデザインを変えています。

スマホの場合は1カラムとし、「内容」がタイトルとなり、その他の項目がカラムの中に配置されます。

決済が走らない場合は「楽な」体験を、決済が走る場合は「慎重な」体験を心掛けました。

スマホ版のデザインも作成する

今回はPC版から作ったので、最後にスマホ版のデザインも作りました。

今回は明確にお金が関係する案件だったので、しっかりと全ての画面のスマホ版を作成しました。

テストしてリリースする

最後に皆でテストしてリリースして、完了です!

制作を終えて

今回のリニューアルは、ユーザー側が絡んでくる前回と違いパターンは少なかったですが、お金が関係してるものだったので、「楽な」体験「慎重な」体験の出し分けに注意しながらデザインを行いました。

まだまだ磨きこめる余地がありそうですが、それよりもプランを増やすことの方がマストの為、サービスがワークしてから磨きこみをかけていきたいと思っております。

お問い合わせはこちら