MAKE + JODOO

MakeとJodooで実現するAI契約受付レビュー

MakeとJodooを使って契約受付レビューを実行し、リスクレベル、優先度、レビューの振り分け先、不足情報、推奨担当者、次の最適アクション、レビュー状況を返し、その結果を追跡可能なJodooレコードに保存します。

一貫した評価基準で契約受付データをレビューするリスクレベル、優先度、レビューの振り分け先、不足情報、推奨担当者、次の最適アクション、レビュー状況をJodooに書き戻す担当者キューとフォローアップ状況を可視化する本番データソースにワークフローを適用する前に、Makeの検証結果を活用する公開用の検証ではMakeのRun onceモードを使用しているため、取得したスクリーンショットでシナリオ履歴内のwebhook bundle、モジュールバブル、オペレーション数、HTTPレスポンスを確認できます。

動画ウォークスルー

Makeデモで起こること

この動画では、Northstar Logistics MSA renewalが、金額、部門、目標署名日、不足している保険情報、更新の背景情報とともにワークフローに入り、その後Jodooに運用レコードとして保存される流れを紹介しています。

  1. Custom webhookが申請を受信

    Northstar Logistics MSA renewalが、金額、部門、目標署名日、不足している保険情報、更新の背景情報とともにワークフローに入ります。

  2. Makeが構造化されたレビューフィールドを準備

    このワークフローでは、曖昧な文章を返すのではなく、リスクレベル、優先度、レビューの振り分け先、不足情報、推奨担当者、次の最適アクション、レビュー状況を明確なフィールドとして保持します。

  3. HTTPモジュールがJodooに書き込み

    テスト済みの実行では、レビュー結果がJodooに送信され、ブリッジからJodoo data IDを受け取ります。

  4. Makeの検証結果は確認可能なまま保持

    公開用の検証ではMakeのRun onceモードを使用しているため、取得したスクリーンショットでシナリオ履歴内のwebhook bundle、モジュールバブル、オペレーション数、HTTPレスポンスを確認できます。

  5. Jodooがチーム用レコードを保持

    Jodooアプリには、契約名、取引先、契約種類、申請部門、契約金額、目標署名日、不足情報が保存され、レビューとフォローアップに活用されます。

デモ概要

Makeが申請をレビューし、Jodooがフォローアップを管理

この実装は、シナリオキャンバスの可視性、Run onceでのテスト、モジュール履歴を重視するオペレーションチームに適しています。このページでは、視覚的なシナリオ設定、実際の実行、Jodooへの書き戻しをすべて確認できます。HTTPモジュールの証跡も視覚的で、メソッド、エンドポイント、ボディタイプ、解析済みレスポンス、完了ステータスをコードエディタを開かずに確認できます。

Makeシナリオ

Make Custom webhookがサンプルペイロードを受信し、HTTPモジュールが構造化フィールドをJodooに送信します。

構造化された判定

このワークフローは、Northstar Logistics MSA renewalに対して、リスクレベル、優先度、レビューの振り分け先、不足情報、推奨担当者、次の最適アクション、レビュー状況を返します。

Makeの実行成功

Makeの実行履歴には、HTTPモジュールの完了、実行の詳細、Jodoo data IDのレスポンスが表示されます。

Make実装の詳細

まずCustom webhookから始め、サンプル申請を貼り付け、Makeにbundleを推定させてから、判定フィールドをHTTPモジュールのボディにマッピングします。

契約受付レシピの詳細

契約受付では、HTTPモジュールがJodooに書き込む前に、Make bundle内でcounterparty、value、target signature date、不足書類のフィールドを見える状態で保持する必要があります。

Jodooへの書き戻し

Jodooは契約受付レコードを保存し、次のアクションを可視化します。

運用上のフォローアップ

推奨される次のアクションは、法務と財務に振り分ける前に、不足している保険証明書とデータ処理確認を依頼することです。

再利用可能なキット

活用キットには、ハンドブック、Jodooフィールド設計図、Makeワークフローレシピが含まれます。

プラットフォーム設定メモ

Make特有のポイント

Jodooのレコードモデルは一貫して保てますが、各エージェントプラットフォームでは構築スタイル、テスト画面、本番への引き継ぎ方法が異なります。

  • 設定の検証

    この検証ではRun onceを使用しているため、受信したbundleとHTTPレスポンスを確認できます。

  • アクション経路

    HTTPモジュールでは、メソッド、URL、ボディタイプ、レスポンス解析を確認可能な状態で保持できます。

  • レシピの焦点

    シナリオ履歴は、オペレーション数、所要時間、書き戻しレスポンスの視覚的な記録を提供します。

  • 本番計画

    本番計画では、webhookの担当範囲、router、エラーハンドラー、オペレーション数をカバーする必要があります。

  • 証跡の詳細

    公開用の検証ではMakeのRun onceモードを使用しているため、取得したスクリーンショットでシナリオ履歴内のwebhook bundle、モジュールバブル、オペレーション数、HTTPレスポンスを確認できます。

  • 実行証跡

    HTTPモジュールの証跡も視覚的で、メソッド、エンドポイント、ボディタイプ、解析済みレスポンス、完了ステータスをコードエディタを開かずに確認できます。

  • 構築の詳細

    まずCustom webhookから始め、サンプル申請を貼り付け、Makeにbundleを推定させてから、判定フィールドをHTTPモジュールのボディにマッピングします。

  • 実装パス

    高額契約、緊急請求、不足情報ありのケースで異なるJodooキューが必要な場合は、基本検証の後にrouterを使用します。

  • ガードレール

    Run onceの検証をアクティブなワークフローに切り替える前に、オペレーション数、webhookの担当範囲、シナリオのスケジューリングを確認してください。

  • レビュー管理

    HTTPモジュールの周囲にエラーハンドラーを追加し、書き戻し失敗時に再試行するか、手動レビュー経路へ移せるようにします。

  • シナリオレシピ

    契約受付では、HTTPモジュールがJodooに書き込む前に、Make bundle内でcounterparty、value、target signature date、不足書類のフィールドを見える状態で保持する必要があります。

  • ワークフロー調整

    最初のJodoo書き戻し検証が安定した後は、routerで中リスクの更新案件と高リスクの新規契約を分岐できます。

ワークフローキット

同じ契約受付レビューループを構築する

ハンドブックを確認し、ワークフローのレシピをコピーし、Makeワークフローを調整する際はJodooのフィールドモデルを活用してください。

ソリューションハンドブック

チームで再利用できるもの

Makeが視覚的なシナリオを処理し、Jodooが担当者キュー、レビュー状況、フォローアップのために契約受付レビューフィールドを保存します。

業務ワークフローJodooフィールドモデルエージェントプロンプト展開チェックリスト

再利用可能なワークフロー

ワークフローが判断し、Jodooが業務を前に進めます。

  1. 01

    Custom webhook

    Northstar Logistics MSA renewalで契約受付テストを開始します。まずCustom webhookから始め、サンプル申請を貼り付け、Makeにbundleを推定させてから、判定フィールドをHTTPモジュールのボディにマッピングします。

  2. 02

    Makeシナリオ

    Make Custom webhookがサンプルペイロードを受信し、HTTPモジュールが構造化フィールドをJodooに送信します。

  3. 03

    HTTPモジュール

    構造化JSONをJodoo書き戻しブリッジに送信します。HTTPモジュールの証跡も視覚的で、メソッド、エンドポイント、ボディタイプ、解析済みレスポンス、完了ステータスをコードエディタを開かずに確認できます。

  4. 04

    検証レスポンス

    プラットフォームでの実行成功とJodoo data IDを表示します。公開用の検証ではMakeのRun onceモードを使用しているため、取得したスクリーンショットでシナリオ履歴内のwebhook bundle、モジュールバブル、オペレーション数、HTTPレスポンスを確認できます。

  5. 05

    Jodooキュー

    担当者レビュー、ステータス管理、フォローアップ用のフィールドを保存します。Run onceの検証をアクティブなワークフローに切り替える前に、オペレーション数、webhookの担当範囲、シナリオのスケジューリングを確認してください。

ワークフローループ

Makeの契約受付レビューからJodooへ

  1. Custom webhookが契約受付レビューを受信する、またはまず合成データで開始します。

  2. Makeは焦点を絞ったレビュー指示を適用し、リスクレベル、優先度、レビューの振り分け先、不足情報、推奨担当者、次の最適アクション、レビュー状況を返します。

  3. HTTPモジュールが構造化された出力をJodoo書き戻しブリッジへ送信し、data IDを受け取ります。

  4. 契約受付では、HTTPモジュールがJodooに書き込む前に、Make bundle内でcounterparty、value、target signature date、不足書類のフィールドを見える状態で保持する必要があります。

  5. 最初のJodoo書き戻し検証が安定した後は、routerで中リスクの更新案件と高リスクの新規契約を分岐できます。

  6. シナリオ履歴は、各モジュール、所要時間、オペレーション数、受け付けられたJodooレスポンスを示すため、法務オペレーションにとって最適な検証証跡です。

  7. まずCustom webhookから始め、サンプル申請を貼り付け、Makeにbundleを推定させてから、判定フィールドをHTTPモジュールのボディにマッピングします。

  8. 高額契約、緊急請求、不足情報ありのケースで異なるJodooキューが必要な場合は、基本検証の後にrouterを使用します。

  9. Jodooは契約受付フォームのレコードを作成し、契約名、取引先、契約種類、申請部門、契約金額、目標署名日、不足情報、リスクレベルを保存します。

  10. チームはキューをレビューし、担当範囲を割り当て、次のアクションを完了します。法務と財務に振り分ける前に、不足している保険証明書とデータ処理確認を依頼します。

  11. Run onceの検証をアクティブなワークフローに切り替える前に、オペレーション数、webhookの担当範囲、シナリオのスケジューリングを確認してください。

  12. HTTPモジュールの周囲にエラーハンドラーを追加し、書き戻し失敗時に再試行するか、手動レビュー経路へ移せるようにします。

フィールドマッピング

エージェントの出力をJodooフィールド化

エージェントまたはソースデータJodooレコードのフィールド
元の申請詳細契約名、取引先、契約種類、申請部門
レビュー判定フィールド不足情報、リスクレベル、優先度、レビューの振り分け先、推奨担当者
ワークフローレスポンスソースプラットフォーム、元のワークフロー出力

エージェントレシピ

プロンプトと構造化出力

Makeの役割

1件の契約受付レビュー申請を確認し、Jodooで保存・振り分け・レポート可能な構造化フィールドを返してください。まずCustom webhookから始め、サンプル申請を貼り付け、Makeにbundleを推定させてから、判定フィールドをHTTPモジュールのボディにマッピングします。

レビュー指示

Northstar Logistics MSA renewalのサンプル文脈を使い、リスクレベル、優先度、レビューの振り分け先、不足情報、推奨担当者、次の最適アクション、レビュー状況を判断し、推奨する次のアクションは具体的にしてください。契約受付では、HTTPモジュールがJodooに書き込む前に、Make bundle内でcounterparty、value、target signature date、不足書類のフィールドを見える状態で保持する必要があります。

書き戻し仕様

予測可能なJSONオブジェクトをHTTPモジュール経由で送信してください。Jodooは毎回同じフィールド名を受け取る必要があります。Makeは、キャンバス、フィルター、router、モジュール単位の実行履歴を使って引き継ぎを説明したいオペレーションチームに適しています。

必須出力

監査用コンテキストとして、risk level、priority、review route、missing information、suggested owner、next best action、review status、source_platform、agent_confidence、original workflow outputを返してください。

Makeの管理項目

Run onceの検証をアクティブなワークフローに切り替える前に、オペレーション数、webhookの担当範囲、シナリオのスケジューリングを確認してください。HTTPモジュールの周囲にエラーハンドラーを追加し、書き戻し失敗時に再試行するか、手動レビュー経路へ移せるようにします。webhook URLの担当者と、本番の申請データを扱うモジュールを編集できる担当者を文書化してください。

契約受付の実装メモ

契約受付では、HTTPモジュールがJodooに書き込む前に、Make bundle内でcounterparty、value、target signature date、不足書類のフィールドを見える状態で保持する必要があります。最初のJodoo書き戻し検証が安定した後は、routerで中リスクの更新案件と高リスクの新規契約を分岐できます。シナリオ履歴は、各モジュール、所要時間、オペレーション数、受け付けられたJodooレスポンスを示すため、法務オペレーションにとって最適な検証証跡です。

{
  "contract_name": "Northstar Logistics MSA 更新",
  "counterparty": "Northstar Logistics",
  "contract_type": "基本サービス契約",
  "contract_value": 186000,
  "currency": "USD",
  "risk_level": "中",
  "priority": "高",
  "review_route": "法務、その後財務",
  "missing_information": "更新済み保険証明書とデータ処理補遺の確認",
  "suggested_owner": "法務オペレーション",
  "next_best_action": "不足書類を依頼し、法務レビューへ回す",
  "review_status": "受付内容のフォローアップが必要"
}

Jodooスターターアプリ

契約受付スターターアプリ

契約受付レビューのワークフローをチーム向けに調整する際は、このフィールドモデル、ビュー、自動化を活用してください。

含まれるフィールド

  • 契約名
  • 取引先
  • 契約種類
  • 申請部門
  • 契約金額
  • 目標署名日
  • 不足情報
  • リスクレベル
  • 優先度
  • レビューの振り分け先
  • 推奨担当者
  • 次の最適アクション
  • レビュー状況
  • ソースプラットフォーム
  • 元のワークフロー出力

推奨ビュー

  • 受付後のフォローアップが必要
  • 法務レビューキュー
  • 財務レビューキュー
  • 高優先度の契約
  • すべての契約申請

自動化ルール

  • Makeが構造化出力を返した後にJodooレコードを作成する。
  • 高優先度または例外レコードを適切な担当者キューへ移動する。
  • 不足情報または保留理由がある場合、推奨担当者に通知する。
  • 元のワークフロー出力を監査コンテキストとして保持する。

展開チェックリスト

本番前に確認すべきこと

  • シナリオを有効化する前に、合成データをCustom webhookへ送信する。
  • 編集後にHTTPモジュールを再度開き、保存されたJSONマッピングを確認する。
  • シナリオ履歴を使って、ステータス、オペレーション数、レスポンスボディを確認する。
  • router、filter、通知の追加は、基本の書き戻しが安定してから行う。
  • Run onceの検証をアクティブなワークフローに切り替える前に、オペレーション数、webhookの担当範囲、シナリオのスケジューリングを確認してください。
  • HTTPモジュールの周囲にエラーハンドラーを追加し、書き戻し失敗時に再試行するか、手動レビュー経路へ移せるようにします。
  • webhook URLの担当者と、本番の申請データを扱うモジュールを編集できる担当者を文書化する。
  • 最初のJodoo書き戻し検証が安定した後は、routerで中リスクの更新案件と高リスクの新規契約を分岐できる。
  • シナリオ履歴は、各モジュール、所要時間、オペレーション数、受け付けられたJodooレスポンスを示すため、法務オペレーションにとって最適な検証証跡です。

実装リファレンス

設定内容をチーム向けに残す

ワークフロー

Makeの契約受付からJodooレコードへ

Makeが視覚的なシナリオを処理し、Jodooがチームで絞り込み、割り当て、レビューできるレコードを保持します。

  1. Custom webhookが契約受付レビューを受信する、またはまず合成データで開始します。

  2. Makeは焦点を絞ったレビュー指示を適用し、リスクレベル、優先度、レビューの振り分け先、不足情報、推奨担当者、次の最適アクション、レビュー状況を返します。

  3. HTTPモジュールが構造化された出力をJodoo書き戻しブリッジへ送信し、data IDを受け取ります。

  4. 契約受付では、HTTPモジュールがJodooに書き込む前に、Make bundle内でcounterparty、value、target signature date、不足書類のフィールドを見える状態で保持する必要があります。

  5. 最初のJodoo書き戻し検証が安定した後は、routerで中リスクの更新案件と高リスクの新規契約を分岐できます。

  6. シナリオ履歴は、各モジュール、所要時間、オペレーション数、受け付けられたJodooレスポンスを示すため、法務オペレーションにとって最適な検証証跡です。

  7. まずCustom webhookから始め、サンプル申請を貼り付け、Makeにbundleを推定させてから、判定フィールドをHTTPモジュールのボディにマッピングします。

  8. 高額契約、緊急請求、不足情報ありのケースで異なるJodooキューが必要な場合は、基本検証の後にrouterを使用します。

  9. Jodooは契約受付フォームのレコードを作成し、契約名、取引先、契約種類、申請部門、契約金額、目標署名日、不足情報、リスクレベルを保存します。

  10. チームはキューをレビューし、担当範囲を割り当て、次のアクションを完了します。法務と財務に振り分ける前に、不足している保険証明書とデータ処理確認を依頼します。

  11. Run onceの検証をアクティブなワークフローに切り替える前に、オペレーション数、webhookの担当範囲、シナリオのスケジューリングを確認してください。

  12. HTTPモジュールの周囲にエラーハンドラーを追加し、書き戻し失敗時に再試行するか、手動レビュー経路へ移せるようにします。

Jodooレコード

Jodooに保存される内容

ワークフロー実行後、Jodooには契約名、取引先、契約種類、申請部門、契約金額、目標署名日、不足情報、リスクレベルといった主要フィールドが保持されます。

契約名取引先契約種類申請部門契約金額目標署名日不足情報リスクレベル優先度レビューの振り分け先推奨担当者次の最適アクションレビュー状況ソースプラットフォーム元のワークフロー出力

実際のテスト実行

Makeワークフローが契約受付内容をJodooに書き込みました

スクリーンショットには合成データを使用しており、Makeの設定、成功した実行、そしてワークフローによって作成されたJodooの行を確認できます。

Jodoo向け契約受付レビューのMake設定

Makeシナリオ設定

Make Custom webhookがサンプルペイロードを受信し、HTTPモジュールが構造化フィールドをJodooに送信します。

Jodoo書き戻しを含むMakeの契約受付レビュー成功実行

Makeの実行成功

Makeの実行履歴には、HTTPモジュールの完了、実行の詳細、Jodoo data IDのレスポンスが表示されます。

Make出力から作成されたJodoo契約受付レビューのレコード

Jodooへの書き戻し

契約受付レビューはJodooに書き込まれ、契約名、取引先、契約種類、申請部門、契約金額、目標署名日の各フィールドを確認できます。

FAQ

よくある質問

Jodooのレコード、ワークフロー、アプリテンプレートとエージェントプラットフォームを組み合わせて使う際の回答です。

このMake契約受付レビューはエンドツーエンドでテスト済みですか?

はい。検証では合成データ、実際のMake実行、そして検証マニフェスト付きのJodoo書き戻しスクリーンショットを使用しています。

契約受付レビューにMakeを使う理由は何ですか?

シナリオキャンバスの可視性、Run onceでのテスト、モジュール履歴を重視するオペレーションチームにはMakeが適しています。Jodooはその後、レビューとフォローアップのための永続的なレコードを保持します。

このMake実装は他のプラットフォーム例と何が違いますか?

公開用の検証ではMakeのRun onceモードを使用しているため、取得したスクリーンショットでシナリオ履歴内のwebhook bundle、モジュールバブル、オペレーション数、HTTPレスポンスを確認できます。まずCustom webhookから始め、サンプル申請を貼り付け、Makeにbundleを推定させてから、判定フィールドをHTTPモジュールのボディにマッピングします。契約受付では、HTTPモジュールがJodooに書き込む前に、Make bundle内でcounterparty、value、target signature date、不足書類のフィールドを見える状態で保持する必要があります。

ワークフロー実行後にJodooは何を保存しますか?

Jodooは、契約名、取引先、契約種類、申請部門、契約金額、目標署名日、不足情報、リスクレベル、優先度、レビューの振り分け先に加えて、監査コンテキスト用に元のワークフロー出力を保存します。

後から本番データソースに接続できますか?

はい。まずは検証済みの合成データ実行から始め、契約受付レビューのスキーマが安定したら、フォーム、ポータル、受信箱、API、社内システムへ接続できます。高額契約、緊急請求、不足情報ありのケースで異なるJodooキューが必要な場合は、基本検証の後にrouterを使用します。

チームが引き続きレビューすべき内容は何ですか?

ワークフローは判定フィールドを準備できますが、担当者は引き続き、事業リスク、支払いや法務の承認、最終的な運用判断をレビューする必要があります。webhook URLの担当者と、本番の申請データを扱うモジュールを編集できる担当者を文書化してください。

次のステップ

契約受付を追跡可能なフォローアップへ

まずは検証済みのMake実行を1回行い、その後は同じ書き戻しパターンを周辺のレビューキューや運用上の引き継ぎにも再利用できます。Run onceの検証をアクティブなワークフローに切り替える前に、オペレーション数、webhookの担当範囲、シナリオのスケジューリングを確認してください。