担当者の業務
期限付きアクションを担当し、重要な成果を更新し、不足する背景情報を補い、阻害要因を表面化します。
- 未完了業務には必ず担当者を設定
- 次のアクションがない有効な関係を許可しない
- 阻害要因を見えないままにしない
CRMソフトウェアの使い方：データを有用に保つ日次ルーティン
CRMをレポート義務から、顧客対応チーム、マネージャー、データ責任者、システム管理者の業務リズムへ変えます。
レコードが次のアクションの判断に役立てば、現場はCRMを継続的に使います。管理レポートのためだけのデータ入力は次第に行われなくなります。
- 担当者の日次キュー
- マネージャーの確認頻度
- 管理者による変更統制
各顧客対応の前・最中・後にCRMを活用
目的は最新の判断記録であり、漏れのない書き起こしではありません。
- 01
キューから始める
期限内・期限超過のアクション、優先度の高い関係、例外、会議をレビューします。
- 02
関係を開く
企業、関係者、最近の活動、未完了業務、コミットメント、リスクを確認します。
- 03
判断を準備
期待する成果、必要な根拠、担当者、代替策を特定します。
- 04
結果を記録
曖昧な「フォロー済み」というメモではなく、判断と重要な背景を記録します。
- 05
次のアクションを作成
担当者、期限、期待する成果、関連する顧客状況を割り当てます。
各役割に明確な判断を伴うルーティンを用意
適切な運用頻度によって、CRMを監視システムに変えることなく有用性を維持できます。
マネージャーによる確認
経過期間、ステージ進行、カバレッジ、停滞業務、コミットメント、例外をレビューします。
- 元レコードを確認
- 判断を支援
- 動きのない業務を終了
データ管理体制
重複、古いレコード、担当者未設定、無効な定義、使用されていないビューを解消します。
- 統合ルール
- 必須フィールド
- 指標の定義
管理
ワークフローの使いにくさ、未使用フィールド、権限、自動化の失敗、変更バックログをレビューします。
- 不要な項目を削除
- 変更をテスト
- 責任分担を文書化
CRMの利用不振を招くシステム動作を改善
トレーニングですべての定着問題が解決するわけではありません。
パイプライン会議の前にしかCRMを更新しない
システムが過去を振り返るレポート作業になってしまう。
日次キュー、背景情報、次のアクションを担当者にとって役立つものにします。
レコードに長文メモはあるが構造化された結果がない
マネージャーが進捗、リスク、次のアクションを区別できない。
判断に必要な少数のフィールドを記録し、重要な背景は文章で残します。
各チームが個別のスプレッドシートを管理している
共有CRMに、実業務で必要なフィールド、ビュー、速度が不足しています。
スプレッドシートをプロセス上のシグナルとして分析し、統制されたモデルを調整します。
ダッシュボードの数値をめぐって議論になる
定義とデータリネージュが信頼されていない。
ルールを公開し、レビュー担当者が元レコードを開けるようにします。
CRMの利用に関する質問
CRMデータはどのくらいの頻度で更新すべきですか？
重要な成果と次のアクションは、やり取りの直後に記録します。マネージャーとデータ責任者は、会議前に一括更新を求めるのではなく、経過期間、品質、定義を定期レビューで確認します。
顧客とのやり取り後に何を記録すべきですか？
結果、関連する根拠または背景、変更されたステータス、責任者が明確な次のアクションとその担当者・期限、影響を受ける顧客レコードを記録します。
チームでCRMの定着率を高めるにはどうすればよいですか？
不要な入力を減らし、日次キューと顧客情報を有用にし、フィールドを実際の判断に合わせ、ダッシュボードを元業務に結び付け、管理者が統制された方法で使いにくさを改善できるようにします。
Jodooなら現場が実際に使うルーティンに合わせてCRMを設計可能
役割別ビュー、関連レコード、ルール、リマインダー、ダッシュボードにより、管理者は担当責任を可視化したまま使いにくさを改善できます。
- 分断されたスプレッドシートを置き換えるチーム
- 明確に異なる役割を持つプロセス
- 定着施策を継続的に改善する組織
標準の生産性機能を重視するならパッケージCRMが有利
日常業務が高度なメール、カレンダー、通話、シーケンス、会話インテリジェンスに依存する場合は、構成性を優先する前にそれらの標準ワークフローをテストします。
Jodooで始める
CRMアプリケーションを使用