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

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

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

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

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

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

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

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

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

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

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

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

API（アプリケーションプログラミングインターフェース）は、ソフトウェアシステム間で情報を交換するための構造化された方法です。あるシステムが別のシステムからデータを必要とするとき、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は通常、狭く、繰り返しが多く、サポートチームに既によく理解されています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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