作成：Uptech · 更新日: 2026-10-20

送信前の確認点

宛先、注文・契約番号、添付ファイル、引用履歴を確認します。テンプレートの差込値が他案件のまま残らないようにし、金額や対応期限は参照資料と一致させます。返信案の承認が必要な区分も先に決めます。

チャネルをまたぐ案件

チャット後にメールで届いた同じ相談は関連付けます。担当交代時には確認済み事項、顧客へ伝えた内容、次に回答する期限を残します。自動受付通知は実回答と分けて集計し、顧客への回答状況を見失わないようにします。

返信例、禁止表現、営業時間、流入件数とピーク時間、承認に必要な時間を提示してください。チャットの同時対応数は文章量や調査の複雑さを見て評価し、言語対応を含めた体制を個別に確認します。

メールID、チャットID、顧客から示された案件番号を関連付け、同じ相談を二人が同時に処理しないよう担当を割り当てます。担当中、下書き中、承認待ち、送信済み、顧客回答待ちを分けます。別チャネルから追加情報が届いた場合は、元スレッドへの参照を残して判断材料をそろえます。

返信案までを委託するのか、承認済みテンプレートによる送信まで含めるのかを区分ごとに決めます。アカウントの送信権限も範囲へ合わせ、返金、納期確約、契約条件の例外などは下書き承認へ戻します。送信後の修正が難しい宛先や添付の確認を独立した工程にします。

以下は架空の問い合わせT-31の説明例です。顧客がチャットで交換を相談し、後からメールで写真を送ったケースを想定します。写真の受領を返しただけでは交換の可否は決まらず、発注側の承認後に最終回答を送る流れです。

交代する担当者には、既に顧客へ伝えた内容、未回答の質問、確認すべき添付、次回回答の期限を渡します。日本時間の期限をベトナム時間にも併記する運用を採る場合は、システム上の時刻表記も確認します。以下の時刻は説明のためであり、対応時間の約束ではありません。

チャットの同時対応数を件数だけで決めると、長文調査や承認待ちが重なったときに品質が落ちます。定型質問、注文照合、苦情などの種類ごとに、読解、調査、入力、見直しに必要な時間を試行で確認します。保留案件を抱えたまま新規受付を増やす条件も検討します。

受付通知、初回の実回答、次の回答、最終回答を別のイベントとして残します。顧客の返答待ち、発注側の承認待ち、営業時間外を測定時間へ含めるかは、指標ごとに合意します。待ち時間を除く場合も元の経過時間を保持すると、顧客が実際に待った時間を確認できます。

確認票には宛先、宛名、案件番号、金額や日付の根拠、添付ファイル、引用履歴、署名を含めます。複数顧客の情報が混ざっていないか、日本語の断定表現が承認内容を越えていないかも見直します。表現の修正と業務判断の差戻しを分けて記録すると、改善箇所が明確になります。

納品または運用報告では、送信済み、下書き承認待ち、顧客回答待ち、未着手を照合します。承認済みの新しい言い回しは、適用する問い合わせ種類と版を付けてテンプレートへ反映します。過去メールを無条件に学習資料や翻訳素材へ転用せず、利用範囲を確認します。