Fin Proceduresを社内で推進する方法

Finに質問に答えさせることは強力な第一歩です。Proceduresはそれをさらに進め、Finが繰り返し発生する複数ステップの問題を解決できるようにします。単にプロセスを説明するだけでなく、実際に完了させます。

そのためには、Finは通常、社内システムの情報や操作にアクセスする必要があり、エンジニアリングやそのシステムを所有するチームの助けが必要になることがあります。

このガイドはProceduresを社内で推進するサポートおよびオペレーションリーダー向けです。依頼範囲の設定、技術的関係者との自信を持った対話、最初のプロジェクトを承認されやすい小規模に保つ方法を支援します。

Finはすでに情報提供の質問に優れています。Proceduresはリアルタイムデータやシステム操作に依存する問題を解決する別の価値を解き放ちます。例えば注文状況の確認、サブスクリプションの照会、返品処理などです。

ここから社内での推進活動が始まります。顧客の問題がライブデータやシステム操作に依存する場合、チームはData ConnectorsとAPIアクセスが必要です。

機会は単なる回避ではありません。より速い解決、繰り返しの手作業の削減、そして最も多いタスクでのスムーズな顧客体験です。

Intercomの2026年カスタマーサービス変革レポートによると、表面的なFAQにとどまらずAIを実際のworkflowsに統合するチームは、ROIと指標が大幅に向上しています。多くのチームがAIに投資していますが、成熟した展開に至っているのは少数です。

すべてのProcedureがエンジニアリング作業を必要とするわけではありません。技術的関係者を巻き込む前に、既存のもので何が作れるか探りましょう。

Procedureが他システムの情報を必要とするがエンジニアリングがまだ利用できない場合、Loop in teammate / agentステップを代用できます。Data Connector構築中にteammateが手動でそのステップを完了し、全体のProcedureフローをテストし影響を測定できます。

ここから始めることで二つの利点があります：Proceduresの構築方法を学び、エンジニアリング投資の根拠となる測定可能な結果を生み出せます。

これらの用語に不慣れな場合、このセクションは依頼範囲の設定と社内説明に必要な知識をカバーします。

API（Application Programming Interface）は、ソフトウェアシステム間で情報を交換するための構造化された方法です。あるシステムが別のシステムからデータを必要とするとき、APIを通じてリクエストを送り、応答を受け取ります。

Data ConnectorはAPIコールを使い、Finが注文状況やサブスクリプション更新日など特定の情報を安全に取得または送信できるようにします。各コネクターは通常、特定のタスク用に設計されています。詳しくはData Connectorsをご覧ください。

Procedureはこれらのコネクターを多段階プロセス内で使用し、Finが質問に答えるだけでなく問題解決を支援します。詳しくはProceduresをご覧ください。

最初のプロジェクトは小規模に始め、繰り返し可能な1つのプロセス、1つのシステム、Finが実際に必要とする少数のデータフィールドに絞りましょう。依頼が絞られているほど、進行が速くなります。

Finはシステム全体へのアクセスは不要です。通常は承認された少数のデータを安全に取得または送信するための1つの方法が必要です。エンジニアリングやシステム所有者がFinがアクセスできるフィールドを正確に定義し、それ以上はありません。

完全な技術設定については、記事designing and using your APIs with Data connectorsを参照してください。

最良の社内ケースは具体的なプロセスから始まります。エンジニアリングを巻き込む前に、自動化したい正確なプロセスとFinがそれをうまく行うために必要な最小限のデータを書き出しましょう。

良い最初のProcedureは通常、狭く、繰り返しが多く、サポートチームに既によく理解されています。

以下の基準を使って最適な候補を特定してください：

最も成功しているチームは段階的にProceduresを採用します：

1. 統合不要：knowledge baseのコンテンツだけを使ってFAQスタイルのフロー、トラブルシューティングガイド、ルーティングロジックを自動化します。

2. 読み取り専用アクセス：Finを1つのシステムに接続して情報を参照します（例：注文状況、アカウント詳細、サブスクリプション日）。ここで最初のData Connectorが登場します。

3. 書き込みアクション：Finが別のシステムでアクションを実行できるようにします（例：返金処理、サブスクリプションのキャンセル、レコードの更新）。これはより深いEngineeringの関与が必要で、通常は信頼が確立された後に行われます。

フェーズ1または2から始めると、すぐに結果を示せて、その結果を使ってフェーズ3の根拠を作れます。

Engineeringや関連システムを所有するチームにアプローチする前に、自動化したい内容を正確にマッピングします。これは最も重要なステップで、よくマッピングされたプロセスは技術的な会話を速くし、依頼を断りにくくします。

1. プロセスを平易な言葉でステップごとに書き出します。何がトリガーか？各ステップで何が起こるか？顧客は最後に何を受け取るか？

2. Finが別のシステムからデータを必要とする、またはアクションを取る必要がある正確な箇所を強調します。これがData Connectorの接点です。

3. 各接点ごとにFinが必要とする具体的なデータフィールドをリストアップします。全データベースではなく、このプロセスに必要な最小限のフィールドだけ。

4. 各システムを所有するチームを特定します。必ずしもEngineeringとは限りません。Salesforce、Jira、請求プラットフォーム、または他の内部ツールを管理するチームかもしれません。

Procedureの構築には2種類の調整が必要です：日々の所有権の明確化と承認を得るために関与すべきステークホルダーの把握。

これは必ずしもエンジニアリングの会話ではありません。Finが必要とするデータがSalesforce、Jira、請求プラットフォーム、または他の内部ツールにある場合、主要なステークホルダーはソフトウェアエンジニアではなく、そのシステムを所有するチームかもしれません。まずシステムオーナーを特定し、その後エンジニアリングの関与が必要かどうかを判断してください。

同じ手順でも、部屋にいる人によって非常に異なる見せ方ができます。ピッチを準備する前に、リーダーシップがすでに責任を負っている優先事項を確認し、その目標の一つに直接貢献する形で手順を提示してください。

エンジニアリングの合意が得られたら、開発者またはシステムオーナーにCreate data connectors for Finガイドを共有してください。API接続、認証、データ変換、テストを含むセットアップ全体のプロセスが説明されています。

実際の障害はロードマップのタイミングであることがあります。エンジニアリングは原則的に協力的でも、次の計画サイクルまで利用できないことがあります。それは合理的な結果であり、失敗ではありません。

1. プロセスを平易な言葉でエンドツーエンドでマッピングします。すべてのステップ、すべてのデータフィールド、すべてのシステム接点を文書化してください。

2. Data Connectorsを必要としない手順を構築します。ガイド付きトラブルシューティング、トリアージフロー、knowledge baseに基づく自動化は今すぐ価値を生み出します。

3. Loop in teammate / agentステップを、最終的にData Connectorを使用するステップの橋渡しとして使用します。

4. すでに構築した手順からボリュームデータを収集し、結果を追跡します。これが次の要望の証拠となります。

5. 範囲をできるだけ狭くして、キャパシティが空いたときにエンジニアリングの要望がすぐに適用できるようにします。

スコーピングの支援を受け、障害を話し合い、他のチームがどのように類似の内部会話を乗り越えたかを聞くことができます。幅広く役立ち、参加は無料です

より実践的で専用のサポートを求める場合、認定されたExperts ProgramはFinとData Connectorsを専門とする独立コンサルタントや開発者とつながります。1:1の指導を希望し、よりカスタマイズされた道に投資する意欲がある場合に適した選択肢です