CRMはほぼ使えている。カスタマイズ、他ツールとの連携、入れ替えのどれを選ぶ？

滞っている作業から始める

CRMは連絡先、商談、フォローアップの管理には十分役立っているかもしれません。ところが契約更新になると、値引きに承認が必要で、作業がメールに移ってしまいます。

これは更新業務を調べる理由にはなります。ただし、設定を変えるべきか、製品が対応する機能を追加すべきか、別のツールと連携すべきか、CRMを入れ替えるべきかは、まだ分かりません。

まず一人がその作業を完了する様子を、手間取る箇所も含めて確認します。何を入力し、どこで情報を探し、誰が判断し、完了をどう確認するのかを記録してください。CRMがすでにうまく処理している仕事も別に書き出します。変更後も残すべきものです。

承認が必要な契約更新

次は仮の例です。営業担当者が更新案を作り、マネージャーが値引きを承認し、担当者が合意した提案を顧客に送ります。現状では担当者が更新内容をメールに写し、後から判断結果をCRMに入力し直しています。

「承認を催促してばかりだ」という不満は明快です。ただし原因はさらに確かめる必要があります。

• CRMには承認タスクを割り当てる機能があるのに、担当者が見つけられない、または使い方を教わっていないのでしょうか。
• 更新を記録し、適切なアクセス権を適用できるものの、承認の手順には製品が対応する追加機能が必要なのでしょうか。
• 判断に必要な情報は、引き続きその情報を管理すべき別のシステムにあるのでしょうか。
• そもそもCRMは、一人の顧客に複数の契約と個別の更新がある状態を正確に表せるのでしょうか。

答えによって必要な変更は異なります。見つけられないタスクは画面を増やしても解決しません。更新を誤った種類のレコードとして保存しているなら、システムをつないでも解決しません。

今使っているCRMで何ができるか確認する

管理者か提供会社に、現在契約している製品のエディションと、社員が実際に持つ権限で、一連の作業を実演してもらいましょう。上位エディションのデモでは、現在の契約で使える機能は確認できません。

最初に設定と研修を確認します。既存の項目、表示、タスク、権限設定で不足を埋められるかもしれません。営業担当者とマネージャーに手順どおり試してもらいます。正しく完了できるなら、開発より画面の分かりやすさや研修の改善が次の一手かもしれません。

本当に機能が足りない場合は、現在の製品が正式に対応する拡張方法を調べます。提供会社が対応する拡張箇所、現在のエディションで許される範囲、追加機能の保守担当者、更新後のテスト方法を確認してください。営業資料の「カスタマイズ可能」は、確認事項の出発点です。

Microsoftの モデル駆動型アプリのガイド は、範囲を限定した参考例です。データのモデル化、プロセスの定義、アプリの構成、セキュリティロールの設定は別々の作業として説明されています。これは同社のプラットフォームについての説明であり、すべてのCRMに同じ制御機能がある証拠ではありません。

現実的な三つの選択肢を書き出す

仮の更新業務については、次の三つを判断メモに書けます。それぞれ、適している可能性と、選ぶ前に必要な根拠を示します。

この仮の例では、暫定的な判断をこう記せます。「まずCRMにある承認機能を試す。現在のエディションが必要な権限と更新履歴に対応するかは未確認。試験で両方を確認できれば続行し、具体的な機能が不足していれば拡張か連携を検討する。必要な契約・更新レコードを表せない場合は入れ替えを調べる」。

連携に意味がある場合

各システムの役割が明確なら、連携を検討する価値があります。更新の例では、承認に必要な契約条件を別のサービスがすでに保持しているかもしれません。そのサービスの仕事を丸ごとCRMで再現するより、判断に必要な情報を届ける方が合理的な場合があります。

ただし情報の意味を決めてください。「承認済み」は、マネージャーが提案された値引きを認めた状態でしょうか。それとも顧客が更新を受け入れた状態でしょうか。誰が変更でき、承認後に更新内容が変わったらどうするのでしょうか。

Microsoftの システム間で意味を変換するためのガイド は、同じ業務上の概念をシステムごとに異なって解釈しうることと、その変換を保守する追加作業を説明しています。そこで示す特定の構成を選ばなくても、「この意味の整合を誰が保つか」は確かめる必要があります。

別のツールを選ぶ前に、実際に使う製品とエディションが必要な連携に対応することを確認します。そのうえで更新失敗時の担当者を決めます。二つ目の契約や接続機能にも管理する人が必要です。

CRMの基本構造が合わない場合

根本的な不一致とは、事業で管理すべき対象や、その対象が従うルールを、製品が十分に表せないことです。

例えば一人の顧客に複数の契約があり、それぞれに更新、承認、履歴があるとします。提案された方法が顧客レコードの「更新日」を毎回上書きするだけなら、ほかの更新をどう残すか確認してください。入れ替えを決める前に、必要な関連レコードを製品が扱えるか調べます。

扱えるなら、正式に対応する拡張が妥当かもしれません。扱えないなら、回避策を重ねても肝心の問題が残りえます。単に画面が使いづらいという不満より、入れ替えを裏付ける強い根拠です。

入れ替えにも作業が伴います。レコードと添付ファイルの移行、有用な履歴の保存、権限設定、必要な連携の再構築、新しいシステムで社員が仕事を進めるための支援です。見栄えのよい営業デモだけで適合性を判断せず、難しい更新業務を新システムで実演してもらいましょう。

導入後の作業も比較する

三つの選択肢すべてに同じ問いを当てます。誰が契約更新を申請・承認できるか。誰が仕組みを保守するか。提供会社が製品を更新した後はどうなるか。継続費用は何か。

必要に応じて契約料と必要なエディション、設定や開発、社員研修、サポート、連携の保守、将来の移行作業を含めます。この業務について実際の条件と見積もりを使ってください。小さな拡張にも継続的な責任があり、入れ替えには発端の機能をはるかに超える作業が生じえます。

英国政府の 技術調達ガイド は、既存製品の調整とソフトウェア開発を、ニーズ、実行能力、継続的な提供会社の管理と併せて検討しています。比較の参考にはなりますが、民間企業のCRM判断に共通の正解を示すものではありません。

実効性のある最小の変更を試す

確認した不足を本当に解消できる、最小の案を選びます。対応するテスト環境で、架空だが代表的なレコードを使ってください。実際の契約更新、顧客への連絡、本番環境の変更には触れず、試験結果が広範な導入を裏付けるまで現在の手順を使えるようにします。

更新の例なら、通常の承認、却下、変更後に再承認が必要な提案、承認権限のない人による操作を試します。別システムも関わるなら、データの更新が届かない場合と復旧も試します。試験の止め方、テスト用レコードと設定の削除方法、結果の残し方を事前に決めてください。実際の顧客判断を取り消すことを前提にしてはいけません。

役立つ結果は具体的です。担当者が必要な作業を確認でき、正しいマネージャーが判断でき、更新レコードに判断とその背景が残ることです。手作業が残るなら記録し、それぞれ担当者を決めます。その後、試験結果で判断メモを更新します。

私たちは カスタムソフトウェア と API連携サービス を提供しています。CRMの不足を一緒に調べたい場合は、困っている作業、サンプルのレコード、現在のシステムで残したい部分をお持ちください。作業範囲、ライセンス、引き継ぎ、継続的なサポートは案件ごとに取り決めます。

CRMを変える前によくある質問