SaaSの新規契約の顧客で初期設定と利用開始が止まっているものを毎日拾い、止まっている理由の候補とフォローのメールの下書きをカスタマーサクセスへ渡す

処理の起点を決める

Schedule by Zapier で、平日の毎朝8時に動かします。 日ごとの実行では時刻を指定でき、週末を除く切り替えがあります。 時刻は分単位で保証されるものではなく、指定した時刻から数分以内に動くとされています。Schedule by Zapier そのものはタスクを使いません。

時間帯はアカウントの設定に従います。 アカウントの時間帯を変えたときは、Zap を一度止めて動かし直さないと反映されません。Zap の履歴の時刻は UTC で表示されるので、「8時に動いたか」を履歴で確かめるときは9時間ずらして読みます。

毎晩の書き出しの後に動かすことが前提です。 書き出しが朝までに終わっていないと、前日の表で判定します。表に「書き出した日時」の列を置き、今日の日付でなければ Zap を止めて担当者に知らせます。

入力データを集める

質を決めるのは、データの取り込みの失敗回数とキックオフの記録の2つです。 失敗回数が無いと、③で止まっている顧客が「やり方が分からない」のか「まだ手を付けていない」のかを区別できません。キックオフの記録が無いと、「社内展開は来月から」と最初から決まっていた顧客を、止まっていると判定します。

問い合わせは件名と状態だけを寄せます。 本文まで渡すと、顧客の従業員の氏名や給与の数字が含まれることがあります。件名で理由の候補は十分に絞れます。

データの取得方法を決める

止まっている顧客の行は、Google Sheets の Lookup Spreadsheet Rows (Advanced) でまとめて取り出します。一度に最大500行まで取れます。検索する列に「止まっている」の印の列、値に TRUE を指定します。

「止まっている」の印は、スプレッドシートの式で付けます。

いちばん右の2つの条件が、同じ顧客に毎朝通知が飛ぶのを防ぎます。 前回の通知日は Zap が行に書き戻すので、一度知らせた顧客は7日間、印が付きません。

行の書き戻しは、Update Spreadsheet Row で1行ずつ行います。 この手順は1回の実行で1行しか更新できないので、繰り返しの中に置きます。行の ID は、まとめて取り出した手順の出力から渡します。

AIへ渡す前に整形する

1. 書き出しの日時の確認 … 今日の日付でなければ止めます
2. 件数の上限 … 印の付いた行が50件を超えたら、繰り返しに入らず担当者のチャンネルに件数だけを知らせます
3. 担当者の確認 … 担当者の欄が空の顧客は、カスタマーサクセスの責任者へ回します
4. 解約・休止の顧客の除外 … 契約の状態が有効でない顧客は、印があっても除きます
5. キックオフ前の顧客の除外 … キックオフの打合せが終わっていない顧客は、①の手順の判定から外します

2番目を置くのは、書き出しの不具合に備えるためです。 完了日の列が丸ごと空で書き出されると、全社に印が付き、全社分の下書きと通知が作られます。 普段の件数の数倍で止めておけば、被害は通知1件で済みます。

5番目は見落とされやすい項目です。 契約からキックオフまでに日が空く顧客は、①の目安の日を過ぎて印が付きます。まだ説明を受けていない顧客に「ご利用が進んでいないようです」と送ることになります。

3番目は、受け持ちの偏りを見るためにも使います。 担当者の欄が空の顧客は、営業から引き継ぐときに担当が決まらなかった顧客です。ここが毎週出るなら、引き継ぎの手順のほうに穴があります。

AIに処理させる

させるのは、止まっている理由の候補を決まった区分から選び、根拠を示し、区分に合ったフォローの文案を作ることです。

右端の型は、ナレッジのソースに書いておきます。 AIは区分を選び、その区分の型に沿って文案を作ります。scope_mismatch だけは、メールで説明を尽くさず、担当者の電話を勧める型にしています。期待とのずれをメールで説明すると、解約の理由を文章で残すことになります。

3行目がいちばん起きやすい失敗です。 管理者のログインが無い顧客を渡すと、AIは「担当者が退職した可能性があります」と書き足します。担当者がその推し量りを事実と受け取って電話をすると、顧客に失礼な聞き方になります。

指示内容を固定する

あなたはSaaSのカスタマーサクセスで、新規契約の顧客の初期設定を支援する立場です。
この顧客は、初期設定の手順が目安の日を過ぎて止まっています。
次の情報とナレッジだけを根拠に、止まっている理由の候補を判定してください。

【顧客の情報】
会社名：{company}　契約日：{contract_date}　プラン：{plan}
止まっている手順：{next_step}　目安の日からの超過：{overdue_days}日
管理者の直近14日のログイン回数：{admin_logins_14d}
招待済みの利用者：{invited}名　有効な利用者：{active}名
データの取り込みの失敗回数：{import_failures}
直近30日の問い合わせの件名と状態：{tickets}
キックオフの記録：{kickoff_notes}

【判定のしかた】
- reason は次のどれか1つ：admin_absent / data_import / settings_design /
  rollout_waiting / scope_mismatch / unknown
- 区分の意味とフォローの型は、ナレッジの「理由の区分」に従ってください。
- evidence には、判定の根拠にした情報を、上の項目名と値のまま列挙してください。
- 根拠が上の情報に無い区分を選ばないでください。迷ったら unknown です。
- second_reason には、次に可能性のある区分があれば1つだけ入れてください。

【メールの文案】
- 宛先は管理者。件名と本文を作ってください。
- 区分のフォローの型に沿い、ナレッジの手順書の該当ページの名前を1つまで添えてください。
- 本文は400字以内。

【厳守事項】
- 顧客の社内事情（退職、異動、予算、優先度の変化）を推測して書かないでください。
- 値引き、無償の延長、追加のサービスを提案しないでください。
- 解約、契約の見直しに触れないでください。
- 「ご利用が進んでいない」など、顧客を責める言い方をしないでください。

理由の候補を2つまで返させるのは、担当者の判断の幅を残すためです。 管理者のログインが無く、取り込みの失敗もある顧客は、admin_absent とも data_import とも読めます。1つに決めさせると、担当者はもう一方を考えなくなります。

「根拠が無い区分を選ばない」を明記しないと、data_import に寄ります。 初期設定で最も多いつまずきなので、AIは根拠が薄くてもそれを選びがちです。evidence を項目名と値のまま書かせるのは、担当者が根拠を一目で確かめられるようにするためです。

出力形式を固定する

AI by Zapier の出力フィールドを、次の形で定義します。

{
  "reason": "data_import",
  "second_reason": "settings_design",
  "evidence": [
    "import_failures: 4",
    "tickets: 「従業員CSVの取り込みでエラー」対応中"
  ],
  "suggested_channel": "email",
  "mail_subject": "",
  "mail_body": "",
  "note_for_owner": ""
}

1つ目の理由は、reason で通知と集計を分けられることです。 区分が決まった語なので、月末に区分ごとの件数を数えれば、どの手順のどんなつまずきが多いかが分かります。

2つ目は、suggested_channel で連絡の方法を担当者に示せることです。 scope_mismatch のときは call になり、Gmail の下書きは作らず、Slack の通知だけを送ります。電話を勧める顧客に下書きがあると、そのまま送ってしまいます。

担当者への Slack の通知は、次のような形になります。

【初期設定の停滞】〇〇株式会社（契約 9/1・スタンダード）
止まっている手順：③従業員データの取り込み（目安から5日超過）
理由の候補：data_import（次点：settings_design）
根拠：取り込みの失敗 4回／問い合わせ「従業員CSVの取り込みでエラー」対応中
連絡の方法：メール（下書き：「従業員データの取り込みについてのご案内」）

システムへ連携する

承認の手順（Human in the Loop の Request Approval）は、この Zap には置きません。 公式の説明では、繰り返しの手順の中や後には置けないとされています。担当者の確認は、Gmail の下書きを開いて送るという操作そのもので行います。

Slack は、1つのチャンネルへの投稿が1秒に1件までとされています。 担当者へのダイレクトメッセージに分けるのは、読む人を絞るためでもあり、1つのチャンネルに一度に数十件を流さないためでもあります。

責任者には、その朝の件数だけをまとめて知らせます。 繰り返しの後の手順は回数分動くので、loop_iteration_is_last が true のときだけ通る Filter を置き、その後ろに Slack の Send Channel Message を置きます。 中身は、担当者ごとの件数と区分ごとの件数です。責任者は個々の顧客ではなく、誰に偏っているか、どの区分が増えているかを見ます。

テストのときは、繰り返しの1回目しか表示されません。 本番では全件が回るので、最初の数日は印の付く件数を5件程度に絞った表で動かし、Slack の通知が件数どおりに届くかを確かめます。テスト用の preview_loop_values の欄を後の手順に割り当てると、本番で失敗するとされているので、割り当てには使いません。

CRMへは書き込みません。 対応の記録は担当者が残します。送ってもいない下書きの内容がCRMに残ると、顧客に何を伝えたかが分からなくなります。

人が確認する

担当者は、Slack の通知を見てから下書きを開きます。 見るのは次の3つです。

1. 理由の候補と根拠 … 根拠の値が、自分の知っている顧客の事情と合っているか
2. 連絡の方法 … メールでよいか、電話や打合せのほうがよいか
3. メールの文面 … 手順書の案内が合っているか、言い方がその顧客に合っているか
4. 宛先 … 管理者が交代していないか。キックオフの後に管理者が替わった顧客は、表の管理者の欄が古いままのことがあります

1番目で「知っている事情」と合わなければ、そちらを優先します。 電話で「来月まで繁忙期」と聞いていた顧客なら、メールは送らず、保留の列に期限を入れます。保留にした顧客は、期限まで印が付きません。

判定を覆したら、行の「担当者の判断」の列に区分を書きます。 月に一度、AIの区分と担当者の区分が分かれた件を並べると、ナレッジの区分の説明のどこを直すべきかが分かります。

例外に対処する

上から2行目が、いちばん被害の大きい例外です。 書き出しの不具合で全社に印が付くと、全社分の下書きと通知が一度に作られ、担当者は朝いちばんに数百件の通知を受け取ります。

記録を残す

• 判定した日、顧客の契約ID、止まっている手順、超過日数
• AIに渡した情報（利用の記録、問い合わせの件名、キックオフの記録の要点）
• AIの出力（reason、second_reason、evidence、suggested_channel、文案）
• 担当者の判断（送った／直して送った／電話に切り替えた／保留）と、覆した区分
• その後、止まっていた手順が完了した日

最後の行が、この構成の効き目を測る材料です。 フォローから完了までの日数を区分ごとに見ると、どの区分のフォローの型が効いていないかが分かります。