要件作成のベストプラクティス
AIROは、要件をレシピ、スキル、Genieなど、AIROが構築するWorkatoアセットにマッピングします。 要件が明確であるほど、AIROはより正確にマッピングでき、ブループリントの生成後に必要な手戻りが少なくなります。
書面による要件ドキュメントは必須ではありません。 必要な内容を会話形式で説明し、進めながらAIROに確認質問をさせることができます。 AIROと直接チャットする場合でも、事前にPRDまたはBRDを準備する場合でも、同じ詳細情報がAIROによる要件の適切なアセットへのマッピングに役立ちます。
タスクではなく成果を説明する
改善する一般的な領域だけでなく、自動化が何を達成すべきか、誰のためのものかを明記します。
- 推奨:
When a support ticket is tagged Billing, look up the customer's account status in Salesforce and post a summary to the assigned agent's Slack channel. - 非推奨:
Help our support team with billing tickets.
具体的な成果を示すことで、AIROは関係するシステムと正常な実行の状態を把握できます。 一般的な目標では、AIROが推測する必要があるか、確認質問を1ラウンド行って範囲を絞り込む必要があります。
アプリケーションとオブジェクトを一覧表示する
関係するすべてのシステムと、自動化が読み取りまたは書き込みを行うレコードやオブジェクトの名前を指定します。 これには、たとえば次のようなテーブルが適しています。
| アプリケーション | 目的 | オブジェクト/データ |
|---|---|---|
| Salesforce | 顧客アカウントの検索 | アカウント、ケース |
| Slack | エージェント通知 | チャンネル、メッセージ |
最初にシステム名を指定しない場合、AIROは確認質問を行ってシステムを特定します。 ワークスペースに同じアプリケーションへのコネクションが複数ある場合、たとえばSalesforceサンドボックスとSalesforceプロダクションインスタンスがある場合は、各プロセスで使用するコネクションを指定します。
ビジネスロジックとエラー処理を明記する
AIROのブループリントフローでは、要件をアセットにマッピングする前に、要件で不足している内容を補うための確認質問が行われます。具体的には、次の点に関する質問です。
- 問題とビジネスコンテキスト
- アプリケーションとオブジェクト
- 実行と頻度
- ビジネスロジックと検証
- エラー処理
これらの項目に事前に多く回答しておくほど、AIROが要件をブループリントにマッピングする前に行う必要のある確認質問が少なくなります。 これは、初回ドラフトで欠落しやすい詳細であるビジネスロジックとエラー処理で特に重要です。
- ビジネスロジック: 自動化の動作を変更する条件。 たとえば、単に
handle discount requestsではなく、escalate to a manager if the discount requested is above 15%です。 - エラー処理: ステップが失敗した場合、またはシステムを利用できない場合に実行する内容。 たとえば、単に
handle errorsではなく、retry the API call up to 3 times, then notify the requester and log the failureです。
ブループリントの生成後、特に条件ロジックについて、ブループリントのサブプロセスを元のビジネスルールと照らし合わせて確認します。 基盤となるアセットを構築する前に、各ルールが意図した方法で反映されていることを確認します。
PRDまたはBRDを作成する場合は、一貫した構成にする
要件を、AIROが構築するアセットに明確にマッピングされやすいカテゴリにグループ化します。
- 概要: 自動化が実行する内容と、それが必要な理由。
- アプリケーションとオブジェクト: 関係するシステムとデータ。多くの場合、テーブルで示します。
- トリガー: 各プロセスを開始する内容。
- 機能要件: 自動化が実行する必要がある内容。論理的なセクションに分割します。
- エラー処理と例外: 問題が発生した場合に、条件ごとに実行される内容。
これは必須または網羅的な構成ではありません。 AIROは他の形式でも対応でき、提供された追加コンテキストを使用できます。 このように要件を整理すると、AIROが要件を適切なアセットにマッピングしやすくなり、開始前にギャップを見つけやすくなります。
次のテンプレートを出発点として使用できます。
# PROJECT_NAME PRD
## 概要
[自動化が実行する内容と、それが必要な理由。]
## アプリケーションとオブジェクト
*アプリケーションごとに1行。*
| アプリケーション | 目的 | オブジェクト/データ |
| ----------- | ---------------------------- | ---------------------- |
| [アプリ名] | [この自動化での目的] | [使用するオブジェクトまたはデータ] |
## トリガー
| プロセス | トリガー | 頻度 |
| -------------- | --------------- | ------------------------ |
| [プロセス名] | [トリガーイベント] | [リアルタイム/毎時/毎日] |
## 機能要件
*機能領域ごとに1つのサブセクション。*
### [機能領域名]
- [自動化が実行する必要がある内容]
- [ビジネスルールまたは条件]
## エラー処理と例外
*エラーシナリオごとに1つの条件/解決策ペア。*
**条件**: [この処理をトリガーする内容]
**解決策**:
- [例: 最大N回まで再試行し、その後リクエスト元に通知して失敗をログに記録]
- [例: レコードをスキップし、次のレコードの処理を続行]これらのカテゴリは出発点であり、制約ではありません。 たとえば、Genieの要件には、AIプロバイダーとモデル、使用するスキルとナレッジソース、実行内容、支援対象、コミュニケーション方法を示すジョブの説明を含めることもできます。
次の入力済みの例を確認してください。
Onboarding GenieのPRDの例を参照
Onboarding Genie PRD
概要
Onboarding Genieは、各新入社員のAIアシスタントとして機能します。 リアルタイムのステータス更新を提供し、会議をスケジュールし、アプリケーションアクセスリクエストを処理し、複雑な問題をサポートチームにエスカレーションします。 このAI搭載アシスタントは、オンボーディング全体を通じてパーソナライズされたガイダンスと即時サポートを提供することで、新入社員の体験を変革します。
問題ステートメント
現在、新入社員はオンボーディングの進捗について迷いや情報不足を感じており、次のような状況につながっています:
- 次のステップと期待事項に関する混乱
- 必要なときに支援へアクセスすることの難しさ
- オンボーディングの問題解決の遅延
- 定着率に影響する新入社員満足度の低下
アプリケーションおよびオブジェクト
| アプリケーション | 目的 | オブジェクト/データ |
|---|---|---|
| Workday | 従業員データと管理チェーン | ワーカー、ポジション、マネージャー関係 |
| Outlook | ミーティングのスケジュール設定とカレンダー管理 | ユーザー、カレンダーイベント、空き状況 |
| Okta | 本人確認とアクセスリクエスト | ユーザー、グループ、アプリケーション |
| Jira | 問題の追跡とエスカレーション | チケット、プロジェクト、割り当て |
トリガー
| プロセス | トリガー | 頻度/スケジュール |
|---|---|---|
| Onboarding Genieの有効化 | 新入社員の従業員レコードが開始日に到達 | リアルタイム（イベントベース） |
機能要件
AIアシスタントの有効化とコア機能
要件:
- 新入社員の開始日にOnboarding Genieを有効化する
- Genieは従業員のポジションと部門に基づいてパーソナライズされたガイダンスを提供する必要がある
- Genieはオンボーディングの進捗と次のステップに関するステータス更新を提供する必要がある
実装の詳細:
- パーソナライズのためにWorkdayからワーカー情報を抽出する
- 従業員の部門とロールデータを使用してガイダンスをカスタマイズする
- 質問解釈のための自然言語処理を実装する
- セッション状態と会話履歴を維持する
ミーティングスケジュール設定機能
要件:
- Genieは新入社員からのミーティングリクエストを処理する必要がある
- システムはOutlook Calendarを使用して参加者の空き状況を確認する必要がある
- Genieはデフォルトの所要時間を30分としてカレンダーイベントを作成する必要がある
- ミーティング招待はすべての参加者に自動的に送信する必要がある
- システムはスケジュールの競合を処理し、代替時間を提案する必要がある
実装の詳細:
- 空き状況の確認のためにOutlook Calendar APIと連携する
- 特に指定がない限り、デフォルトのミーティング所要時間は30分
- ミーティング招待に関連するオンボーディングコンテキストを含める
- 競合が発生した場合に再スケジュールオプションを提供する
アクセスリクエスト管理
要件:
- Genieはセルフサービスのアプリケーションアクセスリクエストを処理する必要がある
- システムはOktaを使用してリクエスターの本人確認を行う必要がある
- アクセスリクエストは適切な承認ワークフローにルーティングする必要がある
- Genieは保留中のアクセスリクエストに関するステータス更新を提供する必要がある
- システムはアクセスが付与または拒否されたときにユーザーに通知する必要がある
実装の詳細:
- リクエストを処理する前にOktaを使用して本人確認を行う
- アプリケーションタイプと組織のポリシーに基づいてリクエストをルーティングする
- リクエストのステータスを追跡し、リアルタイム更新を提供する
- リクエストステータスの変更に関する通知を送信する
問題のエスカレーションとチケット作成
要件:
- Genieは人による介入が必要な複雑な問題を特定する必要がある
- システムは、エスカレーションされた問題について、完全なコンテキストを含むJiraチケットを作成する必要があります
- チケットは問題タイプに基づいて適切なサポートチームにルーティングする必要がある
- システムはWorkdayデータを使用して、正しいマネージャーとサポート担当者を特定する必要がある
- エスカレーションされた問題には、会話履歴と関連する従業員情報を含める必要がある
実装の詳細:
- さまざまな問題タイプに対するエスカレーショントリガーを定義する
- 包括的なコンテキストとトラブルシューティング履歴を含むJiraチケットを作成
- 適切なルーティングのためにWorkdayのマネージャールックアップを使用する
- 人によるサポートの参照用にチャット履歴を保持する
- 従業員に推定解決タイムラインを提供する
従業員データ連携
要件:
- システムは新しいEmployee Directory APIエンドポイントを介して従業員情報にアクセスする必要がある
- システムは次の従業員データを取得して利用する必要がある:
- 基本情報: 名、姓、勤務先メール、ワーカーID、電話番号
- 組織の詳細: 部門、コストセンター、マネージャー、直属の部下
- 雇用情報: 開始日、役職名、雇用形態、所在地
- ステータス情報: アクティブ/非アクティブ、PTOステータス
実装の詳細:
- 必須パラメータ: employee_id
- 取得したデータをパーソナライズされたやり取りと適切なルーティングに使用する
- パフォーマンスのために従業員データを適切にキャッシュする
- フォールバック手順を使用してAPI障害を適切に処理する
エラー処理および例外管理
システム可用性の例外
条件: 対象システム（Workday、Outlook、Okta、Jira）が利用不可
解決策:
- 指数バックオフを使用した再試行ロジックを実装する
- 可能な場合はオフラインガイダンスを提供する
- 3回失敗した後、人によるサポートにエスカレーションする
- 監視のためにすべてのシステム可用性の問題をログに記録する
データ連携の例外
条件: 従業員情報の欠落または不完全
解決策:
- パーソナライズされたデータが利用できない場合は、汎用的なオンボーディングガイダンスを使用する
- 欠落データにフラグを付けてHRレビューの対象にする
- オンボーディング品質に影響するデータのギャップをマネージャーに通知する
- 利用可能な情報でサービスを継続する
ビジネスロジックの例外
条件: Genieの機能を超える無効または複雑なリクエスト
解決策:
- 完全なコンテキストと会話履歴を含むJiraチケットを作成
- リクエストタイプに基づいて適切なサポートチームにルーティングする
- 従業員に推定解決タイムラインを提供する
- 問題がエスカレーションされたことを確認する通知を送信する
技術的な実装メモ
- すべてのJiraチケット作成ロジックは、Genieワークフローに直接埋め込む必要がある
- システムはオンボーディング期間全体を通じて、会話のコンテキストと履歴を維持する必要がある
- エスカレーション手順では、人によるサポートのコンテキストとして完全なチャット履歴を保持する必要がある
- エラー処理は適切に行い、次のステップについてユーザーに明確に伝える必要がある
SalesforceからNetSuiteへのPRD例を参照
SalesforceからNetSuiteへの注文同期PRD
概要
Salesforceで作成された販売注文はNetSuiteに自動的に同期されないため、手動でのデータ入力が必要になり、注文フルフィルメントでエラーや遅延が発生します。 このオートメーションは、SalesforceとNetSuiteの間で注文データをリアルタイムかつ双方向に同期し、手動入力を排除して注文処理時間を短縮します。
アプリケーションとオブジェクト
| アプリケーション | 目的 | オブジェクト/データ |
|---|---|---|
| Salesforce | 注文ソースとステータス更新 | 注文、顧客、商品、価格設定 |
| NetSuite | 注文フルフィルメントと照合 | 販売注文、顧客、出荷、追跡 |
| メール | 照合レポート | レポート |
トリガー
| プロセス | トリガー | 頻度/スケジュール |
|---|---|---|
| 新規注文の同期 | Salesforceで注文ステータスがApproved（承認済み）に変更されたとき | リアルタイム |
| 注文ステータス更新の同期 | NetSuite注文ステータスの変更 | 15分ごと（ポーリング） |
| 日次注文照合 | スケジュールされたレポート生成 | 毎日EST 6:00 |
機能要件
新規注文の同期
- 同期前に、すべての必須フィールドが存在することを検証します
- Salesforceの注文形式をNetSuiteの販売注文形式に変換します
- 顧客がNetSuiteに存在するかどうかを確認し、存在しない場合は顧客レコードを作成します
- NetSuiteで販売注文を作成または更新し、その後、生成されたNetSuite注文IDでSalesforce注文レコードを更新します
- 注文合計は0より大きく、請求先住所は完全であり、すべての明細項目に有効なNetSuite SKUがあり、支払条件は承認済みの値と一致し、注文日は未来の日付にできません
注文ステータス更新の同期
- 過去15分間に更新された注文についてNetSuiteにクエリを実行します
- 外部IDフィールドを使用してNetSuite注文IDをSalesforce注文と照合し、その後Salesforce注文のステータスフィールドと追跡フィールドを更新します
- ステータスがShipped（出荷済み）に変更されたときに、顧客通知メールを送信します
- ステータスは、たとえばShipped（出荷済み）からPending（保留中）のように逆方向に遷移できません
日次注文照合
- SalesforceとNetSuiteの両方から、過去24時間に作成または変更された注文を取得します
- 外部IDで注文を照合し、システム間で注文合計（$0.01以内）とステータスを比較します
- 同期されていない1時間以上前の注文にフラグを付けます
- 不一致のExcelレポートを生成し、財務および営業オペレーションにメールで送信します
エラー処理と例外
条件: 注文作成中にNetSuiteで顧客が見つかりません
解決策:
- NetSuiteで顧客レコードを作成し、その後注文作成を再試行します
条件: 商品SKUが無効です
解決策:
- エラーをログに記録し、営業担当者にメールで通知します
条件: NetSuiteコネクションに失敗しました
解決策:
- 指数バックオフを使用して最大3回再試行し、その後手動レビューのキューに入れます
条件: ステータス同期中に一致するSalesforce注文が見つかりません
解決策:
- 警告をログに記録してスキップします
条件: 日次照合中にレポート生成に失敗しました
解決策:
- 1回再試行し、その後ITにエスカレーションします
最終更新日: