代表電話の伝言をフォームで受けて、用件・折返しの要否・期限を整え、担当者へ Teams で届けて折返しの漏れを拾う

処理の起点を決める

伝言フォームの回答が送信されたことを起点にします。 When a new response is submitted は回答ごとに動くので、電話を切って入力し終えたその場で、伝言が宛先に届きます。 1時間ごとにまとめて届ける形にはしません。急ぎの伝言ほど、まとめると意味がなくなります。

フローは2本に分けます。 1本目は、伝言を受けて整え、台帳に書いてカードを出すフロー。2本目は、30分ごとに台帳を見て、期限を過ぎても「未対応」のままの伝言を、本人と受付担当にもう一度知らせるフローです。1本目はカードの返事を待って止まっているので、追いかけの役は2本目に持たせます。

フォームは受付担当だけが使います。 社員が自分で伝言を書くことは想定しません。入口を1つにしておけば、台帳に載っていない伝言は無い、と言えます。 机に置く紙のメモは、この構成を入れた日からやめます。

入力データを集める

フォームの項目は、自由記述を1つに絞ります。 用件・期限・急ぎかどうかを別々の欄にすると、受付担当は電話をしながら欄を探すことになります。「用件」の欄に聞いたまま書いてもらい、分けるのはAIの仕事にします。 電話番号と相手の名前だけは、聞き違いを防ぐために専用の欄にします。

質を決めるのは、社員の名簿の「よく受ける取引先」の列です。 「営業の佐藤さん」と言われても、相手の会社名と取引先の列が合えば、3人の佐藤から1人に絞れます。この列が空なら、同じ姓の社員宛ての伝言はすべて受付担当に戻ります。

受付担当の所感は、相手の言葉とは別の欄にします。 「声が焦っていた」「二度目の電話」といった受付担当の受け止めは大事な情報ですが、相手が言った期限と混ぜると、どちらの言葉か分からなくなります。

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

名簿の引き方は、姓だけで引かないことです。 Get items の Filter Query で、まず AI が返した部署と姓で絞り、それでも2人以上なら相手の会社名で取引先の列を見ます。 それでも1人に決まらなければ、候補を全員並べて受付担当に戻します。

直近の伝言は、相手の電話番号で引きます。 同じ番号から7日以内に伝言があり、その伝言が「未対応」なら、今回の伝言には「二度目の電話」の印を付けます。 受け取った社員にとって、これがいちばん急ぐべき合図になります。

AIへ渡す前に整形する

1. 電話番号の形の確認 … 数字とハイフン以外を外し、桁数が固定電話・携帯電話の形に合うかを確かめます。合わなければ「番号要確認」の印を付けます
2. 受付日時の付与 … フォームの送信日時を日本時間に直し、プロンプトに渡します。相手が言った「明日」「午後」を日時に直すときの基準になります
3. 宛先の欄の整え … 「さん」「様」「部長」などの敬称と役職を外し、姓と部署の手がかりに分けておきます
4. 不在の予定の確認 … 名簿の不在の予定に当日が入っていれば、宛先と一緒に代理の担当をカードに出します
5. 長さの確認 … 用件が極端に長いときは、受付担当が別の電話のメモを貼った可能性があるので、そのまま要約せずに受付担当へ戻します

1番目は AI に任せません。 電話番号の確認はフローの式で行い、AIには番号を直させません。 形が合わない番号は、そのまま受付担当へ戻して聞き直してもらいます。

2番目を省くと、期限の日時がずれます。 プロンプトに「今日」がいつかを渡さないと、AIは「明日」を日時に直せないか、根拠の無い日付を書きます。

AIに処理させる

させるのは、聞いたままの用件の文から、相手・用件・折返しの要否・期限・宛先の手がかりを取り出して整えることだけです。 宛先を1人に決めることと、急ぎの度合いの判定は、フローの規則で行います。

3行目と4行目を分けているのが、この構成でいちばん大事な点です。 相手が「明日の午前中に」と言ったなら、期限の文は「明日の午前中」、日時は受付日の翌日の12時です。「近いうちに」なら日時は空にし、文だけを残します。 日時が空の伝言は、2本目のフローでは受付日の夕方を期限として扱います。

3行目がいちばん起きやすい失敗です。 「急ぎで」とだけ言われた伝言を渡すと、AIは「本日中」と期限を書きがちです。書かれた期限が本当に相手の言葉なのかが、受け取った社員に分からなくなります。

指示内容を固定する

あなたは総務部で、代表電話の伝言を整える担当です。
受付担当が電話を聞きながら書いた「用件」の文を読み、項目に分けてください。
書かれていないことを推測で埋めないでください。

【取り出す項目】
1. summary ........ 用件の要約（60字以内）。相手が言ったことだけを書く
2. callback ....... 折返しの要否
   - requested : 折り返してほしいと言っている
   - will_call : 相手がまた電話すると言っている
   - message_only : 伝えてくれればよいと言っている
   - unknown : どれとも書かれていない
3. deadline_text .. 相手が言った期限の言葉を、そのまま写す
4. deadline_at .... deadline_text を日時に直せるときだけ、受付日時を基準に
                    ISO 8601（日本時間）で書く。直せなければ空
5. to_hint ........ 宛先の手がかり（姓、部署、役職、案件の名前）
6. phone_in_text .. 用件の文の中に電話番号があれば、書かれた文字のまま写す

【厳守事項】
- 相手が期限を言っていなければ、deadline_text と deadline_at は空にしてください。
  「急ぎ」「至急」とだけ書かれていても、期限の日時を作らないでください。
- 「午前中」は12:00、「午後」は17:00、「夕方」は17:00、「今日中」は18:00 として
  日時に直してください。それ以外のあいまいな言葉は日時にしないでください。
- 電話番号は、桁を補う、ハイフンを足す、数字を直すことをしないでください。
- 宛先を1人に決めないでください。手がかりだけを書いてください。
- 受付担当の所感（{staff_note}）は、相手の言葉として扱わないでください。
  summary にも deadline_text にも混ぜないでください。
- 用件が空、または伝言ではない内容のときは、summary を空にし、
  status を "not_a_message" にしてください。
- JSON のマークダウンを答えに含めないでください。

【受付日時】{received_at}
【相手】{caller_company} {caller_name}
【宛先（聞いたまま）】{to_raw}
【用件】{message_text}
【受付担当の所感】{staff_note}

「急ぎとだけ書かれていても期限を作らない」を明記しないと、期限が埋まります。 AIは「急ぎ」を見ると、親切に「本日中」を補います。禁じるのは、言葉の印象から日時を作ることそのものです。

「午前中は12時」のように直し方を決めているのは、社員ごとに受け取り方がばらつかないようにするためです。 決めていない言葉は日時にせず、文のまま届けて社員に読んでもらいます。 最後の「JSON のマークダウンを含めない」は、JSON が作れないというエラーへの対処として公式の説明が挙げている一文です。

出力形式を固定する

次の形のJSONで受け取ります。 プロンプトの JSON の形式を Custom にして保存し、毎回この形で返るようにします。

{
  "status": "ok | not_a_message",
  "summary": "",
  "callback": "requested | will_call | message_only | unknown",
  "deadline_text": "",
  "deadline_at": "",
  "to_hint": { "family_name": "", "department": "", "title": "", "project": "" },
  "phone_in_text": ""
}

1つ目の理由は、宛先を決める処理に項目ごとに渡せることです。 to_hint の姓と部署を Filter Query にそのまま入れて名簿を引けます。自由文で返ってくると、どこが宛先でどこが用件かを、もう一度切り分けることになります。

2つ目は、期限を文と日時の2つで持てることです。 カードには deadline_text を大きく出し、deadline_at は2本目のフローが期限切れを判定するために使います。社員は相手の言葉を読み、機械は日時を読みます。

急ぎの度合いは、フローの規則で次のように決めます。

受付担当の所感は、この表に入れていません。 所感は台帳とカードに「受付メモ」として出しますが、規則に入れると、受付担当によって急ぎの度合いがばらつきます。 急ぐべきだと感じたときは、受付担当がチャネルで本人に一声かければ足ります。

システムへ連携する

カードには、電話番号を押せる形で出します。 相手の会社名・氏名・電話番号・期限の文・用件の要約・受付メモに加えて、受付担当が書いた用件の原文を折りたたんで付けます。 要約が相手の言葉を落としていたときに、社員が原文で確かめられるようにするためです。

ボタンの結果は、台帳の「状態」の列に書き戻します。 「折り返した」なら完了、「折返し不要」なら完了、「担当違い」なら受付担当のチャネルへ戻して宛先を選び直してもらいます。社員が何も押さなければ「未対応」のままで、2本目のフローの対象になります。

人が確認する

人が見るのは、受付担当に戻ってきた伝言と、期限切れで再通知された伝言だけです。 宛先が1人に決まり、社員がボタンを押した伝言は、誰も見直しません。

1. 宛先が決まらない伝言を選ぶ … 候補の社員が並んだカードから、受付担当が宛先を選びます。迷ったら相手に折り返して確かめます
2. 番号要確認の伝言を聞き直す … 電話番号の形が合わない伝言は、相手からの着信の記録と見比べます
3. 担当違いで戻った伝言を回し直す … 社員が「担当違い」を押した伝言は、受付担当が別の宛先を選びます
4. 期限切れの伝言を追う … 再通知しても返事の無い伝言は、受付担当が本人に電話か声かけで確かめます

1番目で受付担当が迷う伝言は、名簿の整備の材料です。 同じ取引先からの伝言で毎回迷うなら、その取引先を名簿の「よく受ける取引先」の列に足します。 1か月で戻る件数が目に見えて減ります。

目標は、600件をならして1件2分です。 フォームへの入力に1分、戻ってきた伝言と期限切れの追いかけをならして1分という想定です。

例外に対処する

5行目で原文のまま届けているのは、AIが止まっても伝言は止めないためです。 整っていない伝言でも、届かない伝言よりはずっとましです。 「未整理」の印は、後から台帳を見返すときの目印です。

Teams のメッセージには、およそ28KBの大きさの上限があるとされています。 伝言のカードがこれに当たることはまずありませんが、用件の原文が長すぎる伝言は、要約だけを出して原文は台帳のリンクにします。

記録を残す

• フォームの回答の全文（受付担当が書いた用件の原文と所感）
• AIが返した JSON と、そのときのプロンプトの版
• 名簿を引いた結果（候補の社員と、決まった宛先、受付担当が選び直したかどうか）
• カードを出した日時、社員がボタンを押した日時と結果
• 再通知の日時と回数、受付担当が追いかけた記録
• 相手ごとの「二度目の電話」の回数

4つ目の「ボタンを押した日時」は、折返しの早さの記録になります。 受付から折り返すまでの時間を部署ごとに並べると、伝言が滞りがちな部署が分かります。 責める材料ではなく、不在の予定と代理の担当の決め方を見直す材料です。

最後の行は、取引先との関係を見る材料になります。 同じ相手から二度目の電話が続くなら、その取引先の担当の決め方に問題があります。