契約期間がまだ残っていても、終了や非更新を通知する判断は先に必要かもしれません。終了日が近づいてから確認すると、事前通知の期限を過ぎていることがあります。
Busa CLMは、契約台帳、義務、リマインダーを使ってこの運用を整理します。日付を根拠のある担当付きの行動に変える仕組みであり、詳細な法的審査や相手への通知を代行するものではありません。
まず四つの日付を区別する
終了日は現在の契約期間、更新日は次の更新時点、通知期限は通知行為が必要な最終時点です。義務の期限は個別の納品や証明などに対応します。関連していても一つの満了欄へまとめると、先に必要な判断が見えなくなります。
署名済みの原文から、適用条件と通知方法まで確認します。営業日、時差、発送ではなく到達が必要かといった点は担当者の判断が必要です。ファイル名から推測した日付やAgentの抽出を法律意見として採用しません。
公式テンプレート・英語デモデータ
ステップ1：導入し、契約の正式な記録を作る
紹介ページでサインインし、対象ワークスペースへインストールします。Contractsには相手、種類、段階、担当者、業務責任者、価額、開始・終了・更新・通知日、リスク、次の行動を保存します。ブラウザーから契約を作成・編集できます。
Obligationsは契約に結び付いた義務の担当、期限、状態、証拠メモです。Approvalsは契約に関連する承認や通知の引き継ぎと決定を保存します。既存システムが正式な台帳なら、重複する真実を作る前に責任と参照関係を定めます。
契約文、価格、相手情報は適切な権限で管理します。テンプレートの導入だけで電子署名、メール、外部CLMにつながるわけではありません。
ステップ2：根拠のある待ち行列をAgentに依頼する
例えば「署名済み契約と台帳を読み、今後60日間の通知期限・更新日・義務期限を分けて示してください。担当者、原条項、次の行動を付け、不明な日付や通知方法は確認待ちとしてください。更新権限を推測せず、相手へ連絡しないでください」と依頼できます。
60日はこの依頼の検索範囲であり、既に動作する通知サービスの保証ではありません。原文との対応を確認した後、担当者または外部Agent処理が義務や承認リマインダーをBusabaseに作成します。AirAppはその記録を判断しますが、画面から新しい義務やリマインダーを作りません。ブラウザーの作成・編集は契約が対象です。
台帳に日付があるだけでは、担当者が行動できるとは限りません。閲覧権限、期待する結果と期限の理解も確認します。
公式テンプレート・英語デモデータ
ステップ3：最も早い判断期限から扱う
Renewalsで更新と通知の期限を確認し、契約を開いて責任者と次の行動を確認します。必要な資料が不足しているなら未解決事項を残し、安心できる状態表示で判断を代用しません。
Acknowledgeは更新通知の確認日時を保存する操作です。相手へ通知が届いた証明ではありません。実際の通知は許可された経路で行い、発送や受領の証拠を別に残します。義務の完了も実際の成果や証拠メモで確認し、未解決なら再開します。
ステップ4：承認した範囲を明確にする
Approvalsで承認、修正依頼、保留と注記を記録します。決定は対象の業務行へ直接書き込まれ、アプリが強制する別人のCRマージ待ちではありません。画面名が承認だからといって、全変更が隔離されると説明しないことが大切です。
リマインダーの承認は署名、法務審査完了、外部条件への同意を意味しません。何を了承したのかを注記に残し、必要な決定権者の判断につなぎます。アプリはメール送信、電子署名、相手への連絡、外部CLM更新を行いません。
公式テンプレート・英語デモデータ
ステップ5：日付・判断・実行を分けて検証する
一件の通知期限を原契約へ戻って確認し、担当、行動、根拠を照合します。義務とリマインダーが正しい契約につながり、確認操作・内部承認・実際の通知証拠が区別されているか確認します。
概要の90日以内の更新・通知、30日以内の義務は発見の入口です。長期の重要事項を省略する運用規則ではありません。誰が定期確認し、新契約を追加し、条件変更を再検証するかを決めます。
公式画像は英語のデモであり、実際に通知した証拠ではありません。ソース説明で現在の挙動を確認し、まず次の重要な通知期限から運用を整えてください。
次の通知期限から始める
Busa CLMのテンプレートページを開き、サインインして対象ワークスペースへ導入します。近く判断が必要な契約から、条項・通知期限・担当者・次の行動を確認し、義務とリマインダーを整理してください。確認操作と実際の通知証拠は分けて記録します。