要約

  • 指定のID保持ベータに未参加のアカウントでは、統合時に両方の連絡先が実行中のワークフローから外れる。ベータでは主レコードだけが進行状態を保つ。
  • 一括統合の「最終更新」基準は非表示の内部プロパティも含める。新しい更新と、優先すべき顧客対応は別の判断になる。
  • 再登録はワークフローの先頭から始まる。統合自体を取り消せないため、履歴だけでなく残った仕事の行き先まで確認する必要がある。

顧客台帳の重複が一件減れば、整理担当者は成果を報告できる。顧客にとっては、その一件より次の連絡が来るかどうかの方が大事だ。管理画面の達成感と、相手が待つ時間は、同じ尺度では測れない。

例えば、同じ顧客の連絡先が二つあるとする。片方では製品デモ後の案内が実行待ちで、もう片方では試用中の様子を確認する対応が待っている。本人確認を済ませ、二つを統合する。これは仮の例だが、ここで生じる問いは単純である。二つの未完了業務は、どこへ行くのか。

HubSpotの公開資料を読むと、過去の保存と未来の実行に別々のルールがある。統合を単なる台帳整理と呼ぶには、その差が大きい。

履歴がそろうほど、安心しやすい

HubSpotのレコード統合の説明では、活動や関連付け、プロパティの履歴を統合後のレコードに集める。顧客の過去を一か所で追えるようになるのは、分かりやすい利点だ。開いた画面に以前のやり取りがそろっていれば、仕事も引き継がれたように見える。

しかし、該当するワークフローを使うProfessionalまたはEnterpriseのアカウントでは、Primary ID Preservation for Merged Recordsという公開ベータへの参加が分岐点になる。未参加なら、統合時に両レコードが実行中のワークフローから登録解除される。参加済みなら、主レコードの待機、分岐、実行待ちアクションは続き、副レコードはそれまで動いていたワークフローから外れる。

つまりベータでは、主レコードを残すという操作が、進行中の経路を一つ残す判断にもなる。副レコードの古い活動が履歴に入っても、その後に予定されていた仕事が自動的に移るわけではない。

冒頭の例なら、どちらを主にするかで、デモ後の案内と試用確認の扱いが変わる。顧客への約束は二つのままだ。システム上のレコードが一つになったことだけでは、その残りを処理したことにならない。

整理担当者は重複が消えたことを確認し、営業担当者は会話履歴が残ったことを確認する。どちらも正しい確認だ。その二つの間に、まだ起きていない仕事の確認が抜け落ちる余地がある。

新しいレコードが偉いわけではない

一括処理では、残すレコードを決める規則が必要になる。重複管理ツールには、接点の日時、作成日時、最終更新などを使う選択肢がある。最終更新による選択では、非表示の内部プロパティも評価対象に入る。

日時で順番を決めるのは簡単だ。その順番が、顧客対応の優先順位と一致するとは限らない。最近書き換わったレコードより、古い方のレコードに重要な次の一手が待っていることもある。

ベータの仕組みでは、その並べ方がワークフローの継続にも関与する。更新日時が、いつの間にか業務の選考委員になっている。時刻を比べる能力と、どの顧客対応を守るかを決める能力は、ずいぶん違う。

必要なのは全件を会議に持ち込むことではない。まず本当に同じ人物の記録かを確認し、そのうえで進行中の仕事を持つ候補を分ければよい。何も待っていないレコードと、次の連絡を待つレコードを同じ処理単価で扱うから、見えない負担が後工程に回る。

入り直しは続きからではない

HubSpotには統合された連絡先の登録設定もある。初期状態では、統合によるデータ変更で条件を満たしても、新しいワークフローへ自動登録されない。登録を許可する設定はできるが、それは以前の位置を戻す機能ではない。

再登録の説明は、先頭から再び進むと定めている。済んだはずの初期アクションも再び経路に含まれ、実行の可否はその時点の条件に従う。抜けた仕事を戻そうとして、済んだ仕事まで再び予定に入れる可能性が生まれる。

手動登録も先頭から始まる。後半だけを実行したい場合、HubSpotは必要なアクションから始まる別のワークフローを作成または複製して、そこへ手動登録する方法を案内している。

復旧担当者が知るべきなのは、元のワークフロー名だけでは足りない。顧客に何を済ませ、何をまだしていないのか。その境界を調べて、残りの仕事を組み直す必要がある。台帳上の数クリックが、別の人の調査時間に変わる場所だ。

完了の判定を一歩先へ

ワークフロー詳細画面にはアクション、イベント、時刻が記録される。統合の時点と登録解除、再登録、実際の実行を照合する方が、見た目の整った履歴より強い確認になる。具体的な売上への影響を判断するには、そのアカウントの統合前の位置と統合後の実行記録が必要だ。

統合を取り消して元の二つに戻す機能もない。追加のメールアドレスを外し、そのアドレスで新規連絡先を作ることはできるが、新しい記録を作る操作である。過去のIDを追えることと、二つの進行状態を復元できることは同じではない。

だから、整理が終わったと言う前に、次の仕事の行き先を決める。続行するのか、人に引き継ぐのか、理由を持って取りやめるのか。そこまで決まれば、レコード統合は顧客対応を助ける。決まらなければ、未処理の仕事をきれいな引き出しにしまっただけだ。