部門間の引き継ぎ: 営業、手配、カスタマーサービス

マヤが失いかけた案件は、営業で失われたわけではありません。すでに成約していたのです。その案件をほぼ潰しかけたのは、「契約が締結された」瞬間と「旅程の作成が始まった」瞬間の間にあった9日間の空白でした。この引き継ぎのプレイブックは、その9日間の沈黙が謝罪の電話と、あわや顧客を失いかけるという代償を払った後に、マヤの旅行代理店が今も運用しているものです。

キューに9日間放置された6万ドルの予約

ある法人向けリトリートの契約が火曜日に成約しました。営業チームはハイタッチで喜び合いました。署名済みの契約書は共有ドライブにアップロードされました。そしてその後9日間、何も起きませんでした。手配リーダーは営業側がブリーフを転送してくれるものと思い込んでいました。営業側は手配チームにも共有されていると思い込んでいました。何の連絡もないまま、顧客は10日目に電話をかけてきて、本当に予約できているのかと尋ねました。マヤがこの事態を知ったときには、9日間何も起きていなかったことを説明するのに1時間を費やす羽目になりました。

一番奇妙だったのは、その空白そのものではありませんでした。誰もそれを埋める責任を感じていなかったことです。案件はあるシステムでは「成約」と記録されていましたが、「成約後に引き継がれた」ことを記録するシステムはどこにもありませんでした。共有ドライブは受け身の存在にすぎず、誰も定期的に確認を開いていませんでした。

代償は予約そのものではありませんでした。予約は無事に成立しました。代償は信頼であり、これがおそらく数ヶ月間、より小規模な案件で誰にも気づかれずに起き続けていたのだという気づきでした。

実際に存在する3つの引き継ぎ

旅行代理店が1つのチームを超えて成長すると、3つの引き継ぎが発生します。営業から手配への引き継ぎは最も目立つもので、契約が旅程へと変わる瞬間です。手配からカスタマーサービスへの引き継ぎは目立ちませんが、提供の瞬間、つまり旅行者が旅の最中にいて質問が寄せられる瞬間に重要になります。カスタマーサービスから営業への引き継ぎは誰も設計しませんが、健全な代理店であれば必ず機能しているもので、旅行後のフィードバックが数ヶ月後の更新契約や紹介につながります。

それぞれの引き継ぎには固有の失敗パターンがあります。営業から手配への引き継ぎは沈黙によって失敗します(誰も引き取らない)。手配からカスタマーサービスへの引き継ぎは誤伝達によって失敗します(現地チームがブリーフで約束された内容を把握していない)。カスタマーサービスから営業への引き継ぎは忘却によって失敗します(素晴らしい顧客なのに、フォローアップされない)。

マヤの最初の試みの何が間違っていたか

彼女の最初の本能は、フォームを作ることでした。CRM内に12項目の「案件引き継ぎ」テンプレートを設けたのです。1ヶ月も経たないうちに、埋まっているのは3項目だけで、残りは空欄か提案書からのコピペで済まされていました。

問題はフォームそのものではありませんでした。フォームは記録の問題を解決しようとしていましたが、実際の問題は所有権にありました。つまり、引き継ぎが発生した瞬間にそれを担う責任者が誰もいなかったのです。キューに滞留するフォームは、フォームが存在しないのと同じことです。

引き継ぎ契約

フォームに代わって導入されたのは、営業リーダーと手配リーダーが30分の会議で合意した4行の契約でした。その内容は次の通りです。

1. 営業から手配への引き継ぎは、案件が成約した当日に行う15分間のライブミーティングとする。キューなし、非同期のやり取りなし。
2. そのミーティングの成果物は1ページのブリーフとし、ミーティング中に営業が作成し、ミーティング終了前に手配側が承認する。
3. その日に手配側が対応できない場合、案件は指定されたバックアップ担当者に渡す。キューに戻すことは絶対にない。
4. 旅程作成の最初のタスクは「顧客に日程を確認する」とし、24時間以内に完了させる。顧客は1営業日以内に何らかの連絡を受ける。

以上です。ソフトウェアの変更もなく、新しいツールもありません。契約が伝えていたのはただ一つ、どの案件もキューの中で放置されないということでした。

新しい契約が導入された最初の月、マヤはライブ引き継ぎミーティングを3回見学し、その雰囲気を確かめました。それぞれ12〜18分で終わり、両リーダーが案件について明確に一致し、1ページのブリーフに署名し、24時間の期限付きの明確な最初のタスクが設定されていました。かつてキューの中で消えていた案件には、互いに直接話し合った2人の責任者が付くようになりました。

CRMがここで実際に果たす役割

CRMは引き継ぎ自体を解決する役割を期待されなくなりました。その役割はより小さく、より有用なものになりました。ライブ引き継ぎが行われた時刻を記録することです。この単一のフィールド、つまり「引き継ぎ時刻マイナス成約時刻」だけが、代理店が追跡する唯一の引き継ぎ指標になりました。

契約導入前の週、平均滞留時間は38時間で、外れ値として9日間のケースが1件ありました。3週間後には平均4時間になり、最悪のケースでも11時間、いずれも1営業日以内に収まりました。CRMもスタッフも同じままです。変わったのは、誰かがその瞬間の責任を持つようになったことでした。

手配からカスタマーサービスへの引き継ぎ

2つ目の引き継ぎには似た対応を行いましたが、仕組みは異なります。手配部門が作成した旅程は、旅行開始の72時間前にカスタマーサービスのキューに届き、明らかでない好み(食事制限、移動のしやすさ、部屋割りに影響する家族構成など)を確認する15分間の引き継ぎ通話が行われます。

ここでの指標は異なります。現地チームが、本来ブリーフに記載されているべき内容を旅行者に尋ねてしまった回数です。当初は1回の旅行あたり平均3回の確認が発生していましたが、四半期以内に1回未満に減らすことができました。

それ自体で元が取れるカスタマーサービスから営業への循環

3つ目の引き継ぎは、マヤが危うく忘れかけていたものでした。旅行者は旅行から戻ってきた直後、非常に満足しているか、逆に不満を抱えているかのどちらかの状態にあります。代理店は不満を抱えた顧客への対応は得意でしたが、満足した顧客への対応を忘れがちでした。そこでマヤは、火曜日に30分間のレビューを設定し、カスタマーサービスがここ1週間で戻ってきたすべての旅行者について営業リーダーに説明する場を作りました。営業リーダーは最も反応の良い3組を選び、旅行終了から10日以内に個別のフォローアップ電話をかけます。

この週3件のフォローアップ電話による更新契約率は、コールドリストへのアプローチと比べて40%高い水準でした。マヤのカレンダーの中で最もROIの高い1時間になりました。

引き継ぎが機能しているサイン

最も明確なテストは指標ではありません。顧客がマヤに直接電話をかけてこなくなることです。代理店に整った引き継ぎシステムがあると、以前は物事が抜け落ちていた瞬間に責任者が付くようになり、経営層へのエスカレーションが自然になくなっていきます。マヤの受信箱は、週1件の引き継ぎエスカレーションから、四半期に1件程度にまで減りました。

同じシグナルを指標で表すなら滞留時間です。営業の成約から手配の作業開始までの時間が1営業日以内に収まっている限り、システム全体はおおむね健全な状態にあります。それが24時間を超えて延びてきたら、何かが崩れている兆候であり、多くの場合、主担当が不在のときにバックアップ担当者が動いていないことが原因です。

関連記事

• 中規模旅行代理店における営業オペレーション職の構築。案件をコストに変える前に引き継ぎの遅れを察知する役割です。
• トップ営業を維持する段階制コミッション。営業オペレーションが最初に再構築するもう一つの要素です。
• 成約後からオンボーディングへの引き継ぎプロセス。営業からカスタマーサクセスへの引き継ぎの仕組みをより深く掘り下げた記事です。
• リード対応時間。成約前も成約後も、同じ物理法則が働きます。