顧客情報と後続の書類の関連を維持します。
営業の文脈を、次の文書でも失わない
見積や請求が、転記した顧客名だけを持つ独立した項目にならないようにします。Tsumiraの業務案件との接続は、CRMから構造化された出所の参照を引き継ぎます。案件では商談、顧客、文書や、関連付けたプロジェクトを確認できます。次の操作を判断する前に、仕事の出所と今の取引上の状況を理解する場所になります。
商談と顧客の参照を残す
CRMからは商談の参照、件名、段階、顧客参照、分かる場合は予想金額と受注予定日が渡ります。商談の前にあった依頼の出所を残せる場合もあります。顧客マスターはCRMが管理し、財務側は過去を表示するための名称のスナップショットを持ちます。後から名称を訂正しても、過去の業務上の文脈を理解できるようにする区別です。
- CRM商談と顧客への参照
- 円建て予想金額と受注予定日
- 利用可能な元の依頼情報
関連文書とプロジェクトを確認する
業務案件の詳細では、関連文書の種類、状態、参照番号、税込金額、未収額、期日などを確認できます。CRMや紐付いたプロジェクトへの参照から、権限のある人が仕事の中身を調べられます。案件があるだけで、すべての文書が発行済み、すべてのプロジェクトが作成済みとは限りません。実際の状態を読み、次の適切な操作を選びます。
- 文書の状態と参照番号
- 未収額と期日
- 元レコード・プロジェクトへの関連
顧客情報と後続の書類の関連を維持します。
変更後も、財務の履歴を消さない
CRMの更新はリビジョンを考慮した業務イベントとして渡されます。商談の削除や取込の取消は、出所の撤回として扱い、財務履歴を消す権限にはしません。元の商談が変わっても、経緯を理解できるようにするためです。利用者はCRMの段階と業務案件の文書を分けて確認します。文書の発行には、引き続き適切な権限と確認を伴う財務操作が必要です。
- 出所のリビジョンと状態
- 財務履歴の削除ではない撤回
- 文書ごとの確認を伴う操作
具体的な業務の流れ
元の商談を見る
顧客、提案範囲、予想金額、出所を確認してから引き継ぎを使います。
業務案件を開く
参照と現在の状態を読み、意図した顧客に関連しているか確かめます。
関連する仕事を見る
既存文書の状態や、関連付いたプロジェクトを確認します。
次の操作を判断する
案件を承認そのものと扱わず、見積、請求、プロジェクトへの操作を個別に準備し、確認します。
実務を想定した例
利用例：見積依頼から請求担当へ
構造化された見積依頼がCRM商談になった場合を考えます。請求担当は業務案件から元の商談と顧客情報を確認でき、別文書へ顧客名を写すだけで済ませずに状況を理解できます。既存の文書やプロジェクトとの関連も見たうえで、請求の発行前には範囲、宛先、現在の文書状態を適切な財務処理で確認します。
この機能についての質問
業務案件は、発行済み請求書ですか。
違います。出所、プロジェクト、文書などを関係付ける業務の文脈です。文書には独自の種類、状態、管理された発行手順があります。
会社名の変更で過去の表示も書き換わりますか。
現在の顧客マスターはCRMが持ち、財務は過去の表示用の名称を保持します。過去の重要な内容は実際の財務文書で確認してください。
商談を削除すると財務履歴も消えますか。
接続には撤回とリビジョンを考慮した状態管理があります。元のCRM商談の削除が、財務履歴を消す権限を意味するわけではありません。
通貨と税制は何ですか。
現在の業務金額はJPYで、連動する財務機能には日本の消費税ルールが使われます。外貨やドイツ会計への適合を意味しません。
この業務に合う連携を検討する。
想定される連携のアイデアです。シナリオを利用する前に、各アプリの実際の利用可否、権限、対応データをご確認ください。
