こんにちわ。4回目の登場となる菊地です。
今回は顧客管理ツールについてお話したいと思います。
「ユーザを管理する」という傲慢な思想では十分な顧客管理はできません。「最高のおもてなしをする為にお客様の事を知り尽くしたい」という、ホスピタリティ溢れる気配りが円滑な顧客管理を実現します。
【01】顧客管理ツールとは?
文字通り顧客を管理する機能を集めた運営者向けのツールです。
ユーザの登録情報や行動の履歴を参照、サービスの開放や制限、サイト内を巡回するパトロール機能など、運営に携わる管理者が必要とする機能を網羅したツールを指します。
【02】なぜ必要?
小規模なサービスを運営していたり、スタッフ全員がデータベース管理システム(mysqlなどのDBMS)やUNIXのコマンドなどに精通している場合、わざわざ顧客管理ツールを作ったりしないケースも多いのではないでしょうか?
「ユーザの登録情報みたいなら管理者権限でデータベース覗けばいいじゃないの」
↑こんな感じですね。
ただ、果たしてそれがベストでしょうか?
小規模なサービスはいずれ大規模なサービスに育てるのが目標でしょうし、大規模サービスに発展して顧客管理が煩雑になった時、サポートスタッフがデータベース管理に精通していなかったとしたら、いくら優秀なサポートスタッフでも、その力を発揮するのは難しいでしょう。
「その時になったら作ればいいんじゃない?」
確かにその通りなのですが、現実的には、想定される顧客管理情報を見越してサービスを構築している事が前提となります。
顧客管理に必要な情報を記録していなければ、その情報を引き出すツールを開発する事は不可能です。
それ故、「想定していなかった情報」を過去にさかのぼって抽出するのはほぼ不可能です。
また、それらを見越してサービスを構築する事と、それに伴う管理機能を作る事はほぼ同じ手間です。後から作るのは二度手間と言えるでしょう。
例:
とある機能におけるユーザの利用時間を記録していないのに、サポートスタッフに「このユーザの利用時間が知りたいから、出してほしい」と言われても、それに応える事はほぼ不可能です。
サービスを立ち上げる段階で顧客管理ツールの要件を定める事は必須と言えます。
前置きはここまで、それでは具体的にどのような機能が必要か、実例を挙げてご紹介します。
【03】アクセス制限
顧客管理ツールは個人情報の集合体です。ユーザの行動や登録情報はもちろん、課金コンテンツであれば決済の情報、商品の郵送をしているコマース系のコンテンツであれば住所など、極めてクリティカルな情報を取り扱うことになります。
その為、外部からのアクセスを厳しく制限する必要があります。
・BASIC認証
盗聴や改竄が容易ではあるが、文字通りベーシックな認証方法。
・プロキシサーバを経由してアクセスさせる
たとえば、オフィスのIPを指定して、当該IP以外からのアクセスは排除します。
アクセス制限の無いプロキシサーバを経由することでアクセスを許可します。
また、顧客管理ツールにアクセスするメンバーは、大人数であることが前提です。
サポートスタッフ、パトロールスタッフ、マーケティングスタッフなどなど、そしてそれらの職種の中でも、正社員、派遣社員、上司、部下、アルバイトなど、責任の重さもまちまちなスタッフがアクセスします。
その為、スタッフの権限に合わせた機能を開放する必要があります。
・ACL(アクセス制御リスト)による制限
アクセス可能なサーバやネットワーク上の情報を、管理ユーザの権限レベルに応じて制限する仕組みです。


例:ユーザの個人情報の閲覧権限は特定の社員のみ付与し、アルバイトスタッフはサービスにおける行動履歴のみ閲覧権限を付与するなど。
【04】顧客情報の閲覧機能
個人情報のため、閲覧できるスタッフはごく限られています
ユーザの登録情報や行動履歴を参照する機能です。
・プロフィール情報


・課金状況


・サービスの利用状況


などなど、主にサポートスタッフがユーザからの問い合わせに回答する為に必要な情報を参照するケースが多いでしょう。
実は、ここの要件が最も複雑で拡張性を必要とします。
顧客情報の閲覧機能に必要な要件は以下の通りです。
・時系列で確認できる
・逆引きで検索できる(メールアドレスやメンバーID等から顧客情報を引き出せる)
一言に要件といっても、サービス内容が違えばそれも変動します。上記に挙げた数例はあくまで大前提となります。
サービスの特性を掴んで予めデータを収集していないと、サポートスタッフに「このクレームを解決するにはこの情報が必要」と言われた時、往々にして「そんな情報は記録していない」と回答せざるを得ない状況に陥ります。
ディレクターは、この辺りのハンドリングを求められます。
【05】アクセス解析(様々な統計)
webサービスを運営するにあたって、ユーザの動向は気になるところです。こちらも単純なアクセス履歴だけではなく、各サービスの利用属性や数値化された統計なども大切な情報です。
・アクセスしたユーザのIPやUA(ユーザエージェント)のリスト


・各サービスの属性別利用動向


※画像は都道府県別の会員分布の一例
いかがでしたでしょうか?
ここで紹介した管理ツールは一例に過ぎません。サービスの数だけ必要な管理ツールは変わっていきます。
ライブドアでは「その程度の情報量で顧客の事をわかった気になるな!」と言っちゃうディレクターを募集しています。

今回は顧客管理ツールについてお話したいと思います。
「ユーザを管理する」という傲慢な思想では十分な顧客管理はできません。「最高のおもてなしをする為にお客様の事を知り尽くしたい」という、ホスピタリティ溢れる気配りが円滑な顧客管理を実現します。
【01】顧客管理ツールとは?
文字通り顧客を管理する機能を集めた運営者向けのツールです。
ユーザの登録情報や行動の履歴を参照、サービスの開放や制限、サイト内を巡回するパトロール機能など、運営に携わる管理者が必要とする機能を網羅したツールを指します。
【02】なぜ必要?
小規模なサービスを運営していたり、スタッフ全員がデータベース管理システム(mysqlなどのDBMS)やUNIXのコマンドなどに精通している場合、わざわざ顧客管理ツールを作ったりしないケースも多いのではないでしょうか?
「ユーザの登録情報みたいなら管理者権限でデータベース覗けばいいじゃないの」
↑こんな感じですね。
ただ、果たしてそれがベストでしょうか?
小規模なサービスはいずれ大規模なサービスに育てるのが目標でしょうし、大規模サービスに発展して顧客管理が煩雑になった時、サポートスタッフがデータベース管理に精通していなかったとしたら、いくら優秀なサポートスタッフでも、その力を発揮するのは難しいでしょう。
「その時になったら作ればいいんじゃない?」
確かにその通りなのですが、現実的には、想定される顧客管理情報を見越してサービスを構築している事が前提となります。
顧客管理に必要な情報を記録していなければ、その情報を引き出すツールを開発する事は不可能です。
それ故、「想定していなかった情報」を過去にさかのぼって抽出するのはほぼ不可能です。
また、それらを見越してサービスを構築する事と、それに伴う管理機能を作る事はほぼ同じ手間です。後から作るのは二度手間と言えるでしょう。
例:
とある機能におけるユーザの利用時間を記録していないのに、サポートスタッフに「このユーザの利用時間が知りたいから、出してほしい」と言われても、それに応える事はほぼ不可能です。
サービスを立ち上げる段階で顧客管理ツールの要件を定める事は必須と言えます。
前置きはここまで、それでは具体的にどのような機能が必要か、実例を挙げてご紹介します。
【03】アクセス制限
顧客管理ツールは個人情報の集合体です。ユーザの行動や登録情報はもちろん、課金コンテンツであれば決済の情報、商品の郵送をしているコマース系のコンテンツであれば住所など、極めてクリティカルな情報を取り扱うことになります。
その為、外部からのアクセスを厳しく制限する必要があります。
・BASIC認証
盗聴や改竄が容易ではあるが、文字通りベーシックな認証方法。
・プロキシサーバを経由してアクセスさせる
たとえば、オフィスのIPを指定して、当該IP以外からのアクセスは排除します。
アクセス制限の無いプロキシサーバを経由することでアクセスを許可します。
また、顧客管理ツールにアクセスするメンバーは、大人数であることが前提です。
サポートスタッフ、パトロールスタッフ、マーケティングスタッフなどなど、そしてそれらの職種の中でも、正社員、派遣社員、上司、部下、アルバイトなど、責任の重さもまちまちなスタッフがアクセスします。
その為、スタッフの権限に合わせた機能を開放する必要があります。
・ACL(アクセス制御リスト)による制限
アクセス可能なサーバやネットワーク上の情報を、管理ユーザの権限レベルに応じて制限する仕組みです。
例:ユーザの個人情報の閲覧権限は特定の社員のみ付与し、アルバイトスタッフはサービスにおける行動履歴のみ閲覧権限を付与するなど。
【04】顧客情報の閲覧機能
個人情報のため、閲覧できるスタッフはごく限られています
ユーザの登録情報や行動履歴を参照する機能です。
・プロフィール情報
・課金状況
・サービスの利用状況
などなど、主にサポートスタッフがユーザからの問い合わせに回答する為に必要な情報を参照するケースが多いでしょう。
実は、ここの要件が最も複雑で拡張性を必要とします。
顧客情報の閲覧機能に必要な要件は以下の通りです。
・時系列で確認できる
・逆引きで検索できる(メールアドレスやメンバーID等から顧客情報を引き出せる)
一言に要件といっても、サービス内容が違えばそれも変動します。上記に挙げた数例はあくまで大前提となります。
サービスの特性を掴んで予めデータを収集していないと、サポートスタッフに「このクレームを解決するにはこの情報が必要」と言われた時、往々にして「そんな情報は記録していない」と回答せざるを得ない状況に陥ります。
ディレクターは、この辺りのハンドリングを求められます。
【05】アクセス解析(様々な統計)
webサービスを運営するにあたって、ユーザの動向は気になるところです。こちらも単純なアクセス履歴だけではなく、各サービスの利用属性や数値化された統計なども大切な情報です。
・アクセスしたユーザのIPやUA(ユーザエージェント)のリスト
・各サービスの属性別利用動向
※画像は都道府県別の会員分布の一例
いかがでしたでしょうか?
ここで紹介した管理ツールは一例に過ぎません。サービスの数だけ必要な管理ツールは変わっていきます。
ライブドアでは「その程度の情報量で顧客の事をわかった気になるな!」と言っちゃうディレクターを募集しています。
コメントする