保存・待機・配信は別の事実
設定したチャネルが実際に報告する状態を確認します。
送信操作は、メッセージの一段階
顧客への回答には準備、待機、配送経路への引渡し、その後の結果があります。すべてが同じ意味ではありません。Tsumiraは対応する外部メッセージに配送情報を残し、実際の状態を読めるようにします。失敗や不達を調べられますが、全提供元の全イベントや、開封した人の理解まで保証するものではありません。
準備と配送の処理を分ける
下書きは送信済みではありません。対応する送信が配送作業を作り、待機・送信中は処理段階、送信は後の輸送結果を表します。先へ進むには設定したワーカーと経路が必要です。待機のままなら、元の依頼を画面が受けたというだけで何度もコピーを送らず、実際の配送経路を確認します。
- 下書きと外部作業
- 待機・送信中の段階
- 設定したワーカーと配送
証拠がある提供元の結果を読む
対応する追跡は、設定した認証済み提供元のイベントから配達、開封、不達を受け取れます。失敗や取消にもそれぞれ意味があります。受領情報は経路の出来事で、本人の注意や同意の証明ではありません。複数宛先の集約状態では失敗や不達が優先される場合があります。誰に届いたかの判断には、利用できる宛先の情報も確認します。
- 配達・開封・不達
- 失敗と取消の区別
- 宛先を考慮した解釈
ワーカーと配信結果を確認する
開封や配達の通知は内容への同意を意味しません。
確認したアドレス
次の対応をメッセージの文脈で決める
配送は外部メッセージ、宛先、元の記録と関係します。顧客の返信は独自の経路と権限を持つ別の出来事で、配達と同義ではありません。住所を直すか、設定を調べるか、次の返答を用意するかを実際の状態から決めます。再試行や配達情報を、顧客が提案を理解し承諾したという根拠へ置き換えないようにします。
- メッセージと業務の文脈
- 返信と配送情報の区別
- 証拠に基づく次の対応
具体的な業務の流れ
送信前に見る
宛先、内容、対応する経路を確認します。
処理を読む
待機・送信中と輸送済みを分けます。
後の証拠を見る
提供元の結果と、特に失敗時の宛先情報を確認します。
適切に続ける
住所や配送の問題を解決し、次の連絡を記録の文脈で決めます。
実務を想定した例
利用例：見積メールの不達を調べる
確認した提案を送った担当者が、後で配送情報を見るとします。元の依頼の成功だけを信じず、不達からアドレスの問題を確認します。別のメッセージは配達済みでも返信がないかもしれません。その状態も、顧客が見積を受け入れた証拠ではありません。
この機能についての質問
送信は必ず配達ですか。
違います。輸送への引渡しと後の配達証拠は別で、利用できる結果は設定した経路によります。
開封は本人の理解を証明しますか。
いいえ。経路の記録であり、理解、承認、合意の証明ではありません。
複数の宛先で失敗表示になるのはなぜですか。
集約が失敗や不達を優先する場合があります。特定の相手は宛先の文脈で確かめます。
すべての提供元が全イベントを出しますか。
一律には説明しません。追跡は対応する統合と、設定した証拠の経路が必要です。
この業務に合う連携を検討する。
想定される連携のアイデアです。シナリオを利用する前に、各アプリの実際の利用可否、権限、対応データをご確認ください。
