MAKE + JODOO

Make + JodooによるAI顧客オンボーディング引き継ぎ

MakeとJodooで顧客オンボーディングの引き継ぎを処理する流れを確認できます。元の申請をレビューし、構造化された判定フィールドを返し、結果をJodooへ書き戻し、担当者、ステータス、次のアクションを見える化します。

1

一貫した評価基準で顧客オンボーディングデータをレビュー

2

オンボーディング段階、リスクレベル、不足情報、キックオフ優先度、導入担当者、カスタマーサクセス担当者、次の最適アクションをJodooに書き込み

3

担当者キューとフォローアップ状況を見える化

4

ワークフローを本番データソースへ適用する前にMakeの検証結果を使用

5

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

動画ウォークスルー

Makeデモで起きること

動画では、Aster Retail Groupが契約済みプランの背景、本番稼働目標、関係者メモ、導入リスク、不足している連携詳細を含めてオンボーディングに入るケースをMakeが処理し、その後Jodooが業務用レコードとして保存する流れを紹介します。

  1. Custom webhookが申請を受信

    Aster Retail Groupが、契約済みプランの背景、本番稼働目標、関係者メモ、導入リスク、不足している連携詳細を含めてオンボーディングに入ります。

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

    ワークフローは、まとまりのない文章を返すのではなく、オンボーディング段階、リスクレベル、不足情報、キックオフ優先度、導入担当者、カスタマーサクセス担当者、次の最適アクションを明確に保持します。

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

    テスト実行では、レビュー結果をJodooに送信し、ブリッジからJodooデータIDを受け取ります。

  4. Makeの検証結果を確認可能

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

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

    Jodooアプリは、レビューとフォローアップのために、顧客名、プランまたはパッケージ、契約金額、主担当連絡先、本番稼働目標、導入担当者、オンボーディング段階を保存します。

デモ概要

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

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

Makeシナリオ

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

構造化された判定

ワークフローは、Aster Retail Groupについて、オンボーディング段階、リスクレベル、不足情報、キックオフ優先度、導入担当者、カスタマーサクセス担当者、次の最適アクションを返します。

成功したMake実行

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

Make実装の詳細

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

顧客オンボーディングレシピの詳細

顧客オンボーディングの引き継ぎでは、HTTPモジュールがJodooへ書き込む前に、Makeバンドルで顧客名、プラン、本番稼働目標、関係者メモ、キックオフリスク、導入担当者を見える状態にしておく必要があります。

Jodooへの書き戻し

Jodooは顧客オンボーディングレコードを保存し、次のアクションを見える状態に保ちます。

業務フォローアップ

推奨される次のアクションは、キックオフを設定し、導入担当者を割り当て、本番稼働計画の前に連携要件を収集することです。

再利用可能なキット

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

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

Make特有のポイント

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

  • 設定の検証

    検証ではRun onceを使用するため、受信バンドルとHTTPレスポンスを確認できます。

  • アクション経路

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

  • レシピの焦点

    シナリオ履歴により、オペレーション、所要時間、書き戻しレスポンスを視覚的なレコードとして確認できます。

  • 本番計画

    本番計画では、Webhookの担当範囲、ルーター、エラーハンドラー、オペレーション使用量を扱う必要があります。

  • 証跡の詳細

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

  • 実行証跡

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

  • 構築の詳細

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

  • 実装経路

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

  • ガードレール

    Run onceの検証を有効なワークフローに切り替える前に、オペレーション使用量、Webhookの担当範囲、シナリオのスケジュールを確認してください。

  • レビュー管理

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

  • シナリオレシピ

    顧客オンボーディングの引き継ぎでは、HTTPモジュールがJodooへ書き込む前に、Makeバンドルで顧客名、プラン、本番稼働目標、関係者メモ、キックオフリスク、導入担当者を見える状態にしておく必要があります。

  • ワークフロー適用

    ルーターを使うことで、エンタープライズアカウント、不足している導入データ、緊急の本番稼働日をそれぞれ別のオンボーディングキューへ分岐できます。

ワークフローキット

同じ顧客オンボーディング引き継ぎループを構築

ハンドブックを確認し、ワークフローレシピをコピーし、Makeワークフローを適用する際にJodooのフィールドモデルを活用できます。

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

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

  1. 01

    Custom webhook

    Aster Retail Groupを使って顧客オンボーディングテストを開始します。Custom webhookから開始し、サンプル申請を貼り付け、Makeにバンドルを推定させてから、判定フィールドをHTTPモジュールのボディへマッピングします。

  2. 02

    Makeシナリオ

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

  3. 03

    HTTPモジュール

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

  4. 04

    検証レスポンス

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

  5. 05

    Jodooキュー

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

ワークフローループ

Makeの顧客オンボーディング引き継ぎからJodooへ

  1. Custom webhookが、まず合成データで顧客オンボーディングの引き継ぎを受信または開始します。

  2. Makeが絞り込まれたレビュー指示を適用し、オンボーディング段階、リスクレベル、不足情報、キックオフ優先度、導入担当者、カスタマーサクセス担当者、次の最適アクションを返します。

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

  4. 顧客オンボーディングの引き継ぎでは、HTTPモジュールがJodooへ書き込む前に、Makeバンドルで顧客名、プラン、本番稼働目標、関係者メモ、キックオフリスク、導入担当者を見える状態にしておく必要があります。

  5. ルーターを使うことで、エンタープライズアカウント、不足している導入データ、緊急の本番稼働日をそれぞれ別のオンボーディングキューへ分岐できます。

  6. シナリオ履歴により、カスタマーサクセス責任者は、営業から何が届き、ワークフローが何を判断し、Jodooがフォローアップ用に何を保存したかを説明できます。

  7. 検証後、MakeでCRM検索、Slack通知、リスクのある引き継ぎ向けのエスカレーション経路を追加できます。

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

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

  10. Jodooは顧客オンボーディング管理レコードを作成し、顧客名、プランまたはパッケージ、契約金額、主担当連絡先、本番稼働目標、導入担当者、オンボーディング段階、リスクレベルを保存します。

  11. チームはキューをレビューし、担当範囲を割り当て、次のアクションを完了します。キックオフを設定し、導入担当者を割り当て、本番稼働計画の前に連携要件を収集します。

  12. Run onceの検証を有効なワークフローに切り替える前に、オペレーション使用量、Webhookの担当範囲、シナリオのスケジュールを確認してください。

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

フィールドマッピング

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

エージェントまたはソースデータJodooレコードのフィールド
ソース申請の詳細顧客名、プランまたはパッケージ、契約金額、主担当連絡先
レビュー判定フィールドオンボーディング段階、リスクレベル、不足情報、キックオフ優先度、引き継ぎサマリー
ワークフローレスポンスソースプラットフォーム、元のワークフロー出力

エージェントレシピ

プロンプトと構造化出力

Makeの役割

1件の顧客オンボーディング引き継ぎ申請をレビューし、Jodooが保存、振り分け、レポートできる構造化フィールドを返します。Custom webhookから開始し、サンプル申請を貼り付け、Makeにバンドルを推定させてから、判定フィールドをHTTPモジュールのボディへマッピングします。

レビュー指示

Aster Retail Groupのサンプルコンテキストを使用し、オンボーディング段階、リスクレベル、不足情報、キックオフ優先度、導入担当者、カスタマーサクセス担当者、次の最適アクションを判断し、推奨される次のアクションを具体的に保ちます。顧客オンボーディングの引き継ぎでは、HTTPモジュールがJodooへ書き込む前に、Makeバンドルで顧客名、プラン、本番稼働目標、関係者メモ、キックオフリスク、導入担当者を見える状態にしておく必要があります。

書き戻し契約

予測可能なJSONオブジェクトをHTTPモジュール経由で送信します。Jodooは実行ごとに同じフィールド名を受け取る必要があります。Makeは、業務チームがキャンバス、フィルター、ルーター、モジュール単位の実行履歴を使って引き継ぎを説明したい場合に役立ちます。

必須出力

監査コンテキストとして、オンボーディング段階、リスクレベル、不足情報、キックオフ優先度、導入担当者、カスタマーサクセス担当者、次の最適アクション、source_platform、agent_confidence、元のワークフロー出力を返します。

Makeの管理ポイント

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

顧客オンボーディング実装メモ

顧客オンボーディングの引き継ぎでは、HTTPモジュールがJodooへ書き込む前に、Makeバンドルで顧客名、プラン、本番稼働目標、関係者メモ、キックオフリスク、導入担当者を見える状態にしておく必要があります。ルーターを使うことで、エンタープライズアカウント、不足している導入データ、緊急の本番稼働日をそれぞれ別のオンボーディングキューへ分岐できます。シナリオ履歴により、カスタマーサクセス責任者は、営業から何が届き、ワークフローが何を判断し、Jodooがフォローアップ用に何を保存したかを説明できます。検証後、MakeでCRM検索、Slack通知、リスクのある引き継ぎ向けのエスカレーション経路を追加できます。

{
  "customer_name": "Aster Retail Group",
  "plan_or_package": "成長業務展開プラン",
  "contract_value": 42000,
  "primary_contact": "Jordan Lee",
  "go_live_target": "2026-07-15",
  "implementation_owner": "オンボーディング業務チーム",
  "onboarding_stage": "キックオフ準備",
  "risk_level": "中",
  "missing_information": "連携要件とデータ移行担当者",
  "kickoff_priority": "高",
  "customer_success_owner": "CSチームリード",
  "next_best_action": "キックオフを設定し、連携要件を収集する"
}

Jodooスターターアプリ

顧客オンボーディングスターターアプリ

顧客オンボーディング引き継ぎワークフローをチーム向けに適用する際に、フィールドモデル、ビュー、自動化を活用できます。

含まれるフィールド

  • 顧客名
  • プランまたはパッケージ
  • 契約金額
  • 主担当連絡先
  • 本番稼働目標
  • 導入担当者
  • オンボーディング段階
  • リスクレベル
  • 不足情報
  • キックオフ優先度
  • 引き継ぎサマリー
  • 次の最適アクション
  • カスタマーサクセス担当者
  • ソースプラットフォーム
  • 元のワークフロー出力

推奨ビュー

  • 新規顧客引き継ぎ
  • キックオフ準備完了
  • 不足情報
  • リスクのあるオンボーディング
  • すべてのオンボーディングレコード

自動化ルール

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

展開チェックリスト

本番前に確認すべきこと

  • シナリオを有効化する前に、合成データをCustom webhookへ送信します。
  • 編集後にHTTPモジュールを再度開き、保存済みのJSONマッピングを確認します。
  • シナリオ履歴を使って、ステータス、オペレーション、レスポンスボディを確認します。
  • 基本の書き戻しが安定してから、ルーター、フィルター、通知を追加します。
  • Run onceの検証を有効なワークフローに切り替える前に、オペレーション使用量、Webhookの担当範囲、シナリオのスケジュールを確認してください。
  • HTTPモジュールの周辺にエラーハンドラーを追加し、書き戻しに失敗した場合に再試行するか、手動レビュー経路へ移せるようにします。
  • Webhook URLの担当者と、本番の申請データを扱うモジュールを編集できる担当者を文書化します。
  • ルーターを使うことで、エンタープライズアカウント、不足している導入データ、緊急の本番稼働日をそれぞれ別のオンボーディングキューへ分岐できます。
  • シナリオ履歴により、カスタマーサクセス責任者は、営業から何が届き、ワークフローが何を判断し、Jodooがフォローアップ用に何を保存したかを説明できます。
  • 検証後、MakeでCRM検索、Slack通知、リスクのある引き継ぎ向けのエスカレーション経路を追加できます。

ワークフローキット

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

ワークフロー

Makeの顧客オンボーディングからJodooレコードへ

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

  1. Custom webhookが、まず合成データで顧客オンボーディングの引き継ぎを受信または開始します。

  2. Makeが絞り込まれたレビュー指示を適用し、オンボーディング段階、リスクレベル、不足情報、キックオフ優先度、導入担当者、カスタマーサクセス担当者、次の最適アクションを返します。

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

  4. 顧客オンボーディングの引き継ぎでは、HTTPモジュールがJodooへ書き込む前に、Makeバンドルで顧客名、プラン、本番稼働目標、関係者メモ、キックオフリスク、導入担当者を見える状態にしておく必要があります。

  5. ルーターを使うことで、エンタープライズアカウント、不足している導入データ、緊急の本番稼働日をそれぞれ別のオンボーディングキューへ分岐できます。

  6. シナリオ履歴により、カスタマーサクセス責任者は、営業から何が届き、ワークフローが何を判断し、Jodooがフォローアップ用に何を保存したかを説明できます。

  7. 検証後、MakeでCRM検索、Slack通知、リスクのある引き継ぎ向けのエスカレーション経路を追加できます。

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

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

  10. Jodooは顧客オンボーディング管理レコードを作成し、顧客名、プランまたはパッケージ、契約金額、主担当連絡先、本番稼働目標、導入担当者、オンボーディング段階、リスクレベルを保存します。

  11. チームはキューをレビューし、担当範囲を割り当て、次のアクションを完了します。キックオフを設定し、導入担当者を割り当て、本番稼働計画の前に連携要件を収集します。

  12. Run onceの検証を有効なワークフローに切り替える前に、オペレーション使用量、Webhookの担当範囲、シナリオのスケジュールを確認してください。

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

Jodooレコード

Jodooに保存される内容

ワークフロー実行後、Jodooは顧客オンボーディングに関する永続的なフィールドを保持します。顧客名、プランまたはパッケージ、契約金額、主担当連絡先、本番稼働目標、導入担当者、オンボーディング段階、リスクレベル。

顧客名プランまたはパッケージ契約金額主担当連絡先本番稼働目標導入担当者オンボーディング段階リスクレベル不足情報キックオフ優先度引き継ぎサマリー次の最適アクションカスタマーサクセス担当者ソースプラットフォーム元のワークフロー出力

実際のテスト実行

Makeワークフローが顧客オンボーディングをJodooに書き込み

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

Jodooと連携する顧客オンボーディング引き継ぎのMake設定

Makeシナリオ設定

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

Jodooへ書き戻すMakeの顧客オンボーディング引き継ぎ成功実行

成功したMake実行

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

Make出力から作成されたJodooの顧客オンボーディング引き継ぎレコード

Jodooへの書き戻し

顧客オンボーディングの引き継ぎがJodooに書き込まれ、顧客名、プランまたはパッケージ、契約金額、主担当連絡先、本番稼働目標、導入担当者フィールドが表示されています。

FAQ

よくある質問

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

このMakeの顧客オンボーディング引き継ぎはエンドツーエンドでテストされていますか?

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

顧客オンボーディングの引き継ぎにMakeを使う理由は何ですか?

シナリオキャンバスの見える化、Run onceテスト、モジュール履歴を必要とする業務チームにはMakeが適しています。その後、Jodooがレビューとフォローアップ用の永続的なレコードを保持します。

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

公開検証ではMakeのRun onceモードを使用しているため、取得したスクリーンショットでシナリオ履歴内のWebhookバンドル、モジュールバブル、オペレーション数、HTTPレスポンスを確認できます。Custom webhookから開始し、サンプル申請を貼り付け、Makeにバンドルを推定させてから、判定フィールドをHTTPモジュールのボディへマッピングします。顧客オンボーディングの引き継ぎでは、HTTPモジュールがJodooへ書き込む前に、Makeバンドルで顧客名、プラン、本番稼働目標、関係者メモ、キックオフリスク、導入担当者を見える状態にしておく必要があります。

ワークフロー実行後、Jodooには何が保存されますか?

Jodooは、顧客名、プランまたはパッケージ、契約金額、主担当連絡先、本番稼働目標、導入担当者、オンボーディング段階、リスクレベル、不足情報、キックオフ優先度に加え、監査コンテキストとして元のワークフロー出力を保存します。

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

はい。検証済みの合成データ実行から開始し、顧客オンボーディング引き継ぎスキーマが安定したら、フォーム、ポータル、受信トレイ、API、社内システムを接続できます。高額契約、緊急の請求書対応、不足情報のケースで異なるJodooキューが必要な場合は、基本検証の後にルーターを使用します。

チームがレビューし続けるべきことは何ですか?

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

次のステップ

顧客オンボーディングを追跡可能なフォローアップへ

まず検証済みのMake実行を1件作成し、その後、隣接するレビューキューや業務上の引き継ぎに同じ書き戻しパターンを再利用します。Run onceの検証を有効なワークフローに切り替える前に、オペレーション使用量、Webhookの担当範囲、シナリオのスケジュールを確認してください。