承認済みの変更は、新しいファイルが用意できただけでは完了しません。価格条件が1行変わるだけでも、進行中の提案、顧客へ送ったリンク、メール添付、担当者が別の場所へコピーした説明文に、それぞれ異なるタイミングと方法で影響します。どの経路に新条件を適用し、どの商談では旧条件を維持し、回収できないコピーを例外として残すのかを決める必要があります。
このとき、作業単位は文書全体やアセット一覧ではなく、承認された変更1件の change record です。1つの record が、影響を受ける endpoint の特定から、発効時点に応じた受信者対応、例外、rollback の判断、closeout まで、1件の release incident を追跡します。
change recordでincidentの境界を固定する
change record の最初には、今回承認された差分だけを記します。何が変わったか、誰が承認したか、いつから有効か、incident owner は誰か、どの状態になれば完了とするかを記録します。文書の全履歴やすべてのアセットの状態を書き写す場所ではありません。
たとえば価格表の変更を 価格更新 だけで済ませず、変更項目と適用条件、旧条件を認める範囲、確認が必要な関連要素を分けます。境界を固定することで、無関係な資料まで対象を広げたり、反対に進行中の商談を範囲外に置いたりすることを防げます。
impact endpointはファイル一覧ではなく対応義務で捉える
1件の変更が届く先を endpoint ごとに並べ、それぞれに必要な対応を付けます。
| impact endpoint | 今回のincidentで決める対応 |
|---|---|
| 現在の共有リンク | 新文書の適用と実際のviewerでの確認 |
| 進行中の提案・協議 | 新条件の適用、旧条件の維持、または担当者への承認依頼 |
| メール添付 | 再送の要否と受信者への案内 |
| ダウンロード済みファイル・画面キャプチャ | 回収可否と残る例外 |
| 担当者がコピーした説明文 | 修正責任者と適用完了時刻 |
この表はアセットライブラリを作るための台帳ではありません。今回の変更によって対応が必要になった endpoint だけを集めた incident scope です。同じリンクでも、どの受信者とのどの会話で使われたかによって処理結果は変わります。
effective timeでreceiver handlingを分ける
発効時点はファイルの更新日時とは異なります。承認直後から新条件を使うのか、特定時刻以降に始まる提案だけに適用するのか、進行中の会話には旧条件を維持するのかを先に決めます。
次に受信者を、新資料を再送、変更内容を案内、個別確認が必要、対応なし のように実際の行動で分けます。案内には、変更点、適用開始時期、旧資料を引き続き使えるか、問い合わせ先を含めます。リンクを開いた記録は、変更を理解・承諾したことを意味しないため、同意が必要な事項は直接確認します。
リンクとoffline copyに同じ完了表示を使わない
FeatPaperでは、既存の共有リンクを維持したまま文書を更新できます。incident record には、そのリンクへ新文書を適用したか、ページ順やCTAなどの関連要素を実際のviewerで確認したかを残します。これで完了するのはリンク endpoint までです。
ダウンロード済みPDF、メール添付、画面キャプチャは同時には更新されません。回収を確認できたコピーは完了とし、確認できないコピーは offline copy 未確認 の例外として残します。新資料を再送した事実と、旧コピーが消えたという判断も分けます。
exceptionが残るとrollbackの判断も変わる
新文書に条件の誤りや関連要素の不具合が見つかった場合は、何を戻すのかをincident単位で決めます。リンク先の文書を以前のファイルへ戻すこと、新条件の適用を一時停止すること、受信者へ訂正案内を送ることは、それぞれ別の対応です。
rollback owner、実行基準、戻した endpoint、再案内の対象を record に残します。以前のファイルを復元しても、旧条件の有効性まで自動的に戻るわけではありません。条件の判断が必要なら、承認者が適用範囲をあらためて決めます。
closeoutでは処理結果と残る例外を一緒に承認する
closeout の前に、change record の各 endpoint に 適用完了、受信者対応完了、例外承認、rollback完了 のいずれかの最終処分があるかを確認します。owner のいない項目や、単なる 確認中 は終了状態ではありません。回収できない添付のように解消できない項目は、例外の理由、責任者、再確認時期を残します。
承認された変更1件の影響範囲を最後まで閉じることは、旧版をすべてなくすことではありません。どの endpoint に何を行い、発効時点以降に誰へ何を伝え、何が例外として残ったのかを、1つの change record で確定することです。すべての最終処分と責任者が記録されたとき、release incident をクローズできます。
