技術的に複雑なトピックをうまく扱うFin Procedureの構築には反復が必要です。この記事では、実際の手順であるData Connectors Setup and Troubleshooting procedureがどのようにゼロから設計され、連続した反復で洗練され、常に改善をもたらした6つの原則によって形作られたかを説明します。これを使って自分の手順にも同じ考え方を適用してください。

この記事はFin Proceduresの構築と反復を行うチームメンバー向けです。手順エディターで作業し、少なくとも1つの手順を公開していることを前提としています。

この手順はData Connectorの質問全般を扱います：初期設定、認証失敗、APIコールエラー、タイムアウト、レスポンスマッピングの問題、回帰。多くの技術的な内容をカバーし、Finが質問を始める前に顧客のコネクターのライブ診断データを参照するために特別に作られた独自のData Connectorを使用しています。この設計決定だけで手順全体の動作が変わりました。

表面的には「Data Connectorsのヘルプ」は一つのトピックのように聞こえますが、実際には初回設定、認証失敗、壊れたAPIコール、タイムアウト、データマッピング問題、回帰（以前は動作していたが今は動かない）、サポートされていないプロトコル、顧客がまだ必要なものを確信していない場合など、複数の異なる状況をカバーします。これらすべてを一つの手順でうまく扱うには、Finが会話の早い段階でどの状況にあるかを知っている必要があります。

この手順で最も重要な設計決定は、顧客自身のコネクターのライブヘルスデータを取得するために特別に作られた専用のData Connectorです。

顧客がコネクターのURLを共有すると、FinはコネクターIDを使ってGETリクエストを送ります。返ってくるのは：

Finはこのデータを使って、一般的な返答ではなく具体的な内容で最初の意味のある返答を導きます。これが、サポートフォームのように感じる手順と、電話を取る前に問題を調査した誰かと話しているように感じる手順の違いです。

手順は2段階でルーティングします。最初は自動で、Finが診断データを読み取り、顧客に何も尋ねる前にルートを決定します。2段階目は意図に基づき、最初の段階で経路が決まらなければ、Finは顧客の説明を読み取り、該当するサブ手順にルーティングします。

下の表は、Data Connectors Setup and Troubleshooting procedureが扱う13の異なる状況、Finがそれぞれをどのように検出し、どのサブ手順にルーティングするかを示しています。

以下の6つの原則は、手順がどのようにしてそこに至ったか、そして同じ考え方を自分の作業にどう適用するかを説明します。

各原則には以下が含まれます：

Finが顧客に一言も話す前に、顧客が実際に何を求めているのかを把握すべきです。

異なる意図には異なる経路が必要であり、すべての顧客に同じ最初の質問をする手順はほとんどの顧客の時間を無駄にします。

Finは手順を固定の上から下へのスクリプトとして実行しません。非線形の計画アプローチを使用し、会話の進行に応じて以前のステップに戻ったり、先に進んだり、方向を変えたりします。場合によっては、より適した別の手順に途中で切り替えることもあります。

つまり、ステップの順序が必ずしも会話の順序を制御するわけではありません。Finが処理すべき意図に基づいて手順を設計し、厳密なステップバイステップの経路に基づいて設計しないでください。

Data Connectorsに関する質問を扱う手順がこれをよく示しています。

「Data Connectorの質問」は実際には少なくとも5つの異なる会話を含みます：

開始のInstructionステップは、Finに顧客の最初のメッセージを読み、どの状況に該当するかを判断させます。

その後のConditionステップは会話を一致する経路に沿って進めます。

ルーティングはトリガーで行われるため、テストすべきはそこです。適切なツールはライブテストであり、シミュレーションではありません。シミュレーションは意図のマッチングを完全にバイパスし、トリガーを通らずに直接手順を実行するため、Finが最初に正しい手順を選択するかどうかを判断できません。

ルーティングをテストするには、手順を自分だけが対象のライブに設定します。例えば、メールに自社のdomainが含まれるルールです。現実的な開始メッセージを10件送り、2つのことを確認します：この手順が開始すべき時に開始すること、開始すべきでない時に開始しないこと。あいまいなメッセージも含めます。これらは誤ルーティングが最も起こりやすいケースです。誤ったルーティングがあった場合は、Finが手順を使用すべき時と使用すべきでない時をより具体的に説明するようトリガーの記述を厳密にします。

手順が受け取る異なる会話の種類をリストアップします。それらはわずかな違いのある同じ仕事か、本当に異なる仕事かを考えます。本当に異なる場合は2つの選択肢があります：異なるトリガーを持つ別々の手順に分けるか、1つの手順内で分岐として扱うか。仕事が十分に異なり、パフォーマンスを別々に報告したい場合は別々の手順を使います。仕事が密接に関連し、ロジックを1か所で管理したい場合は分岐を使います。

トリガーは、Finがこの手順を使うべき時と使うべきでない時の両方を明確にします。あいまいなトリガーは誤ルーティングの最も一般的な原因です。手順内で顧客に自分の問題を分類させてはいけません。Finはメッセージを読み、そこからルーティングします。顧客の仕事は問題を説明することであり、ラベルを付けることではありません。

Conditionステップは、Finの次の動作が回答によって完全に異なる主要で相互排他的な経路に使います。小さな違いはInstructionステップ内の自然言語でロジックを維持します。これにより手順がシンプルでFinが従いやすくなります。

以下の要因が、仕事を別々の手順に分けるか1つの手順内の分岐として扱うかの選択に役立ちます：

手順が顧客の質問の一部に答えられるData Connectorにアクセスできる場合は、顧客へのインタビューを始める前にそれを呼び出してください。

顧客はこれを有能さとして感じます。最初にインタビューする手順はフォームのように感じられます。

顧客の質問が特定のコネクタに関する場合、Data Connectors Setup and Troubleshooting手順は一度だけコネクタ名を尋ねます。その後、専用の診断用Data Connectorを呼び出し、以下のフィールドを取得します：

Finの最初の意味のある応答はそのデータを使用します。実際の違いは以下の通りです（以下の値は例示です）：

Data Connectorが実行された後、Finの最初のメッセージを声に出して読んでください。既に取得したデータで答えられる質問をしている場合は、データを十分に活用していません。

顧客に質問を押し付けるのではなく、データを読むConditionステップにより多くの判断を任せてください。

手順で利用可能なData Connectorsを一覧にしてください。それぞれについて「最初の顧客質問の前にこれを呼び出せるか？」と自問してください。可能なら、データ取得を最初に行うように構成を変えてください。顧客はFinが既に下調べを済ませていると感じるはずです。

診断データを取得したら、そのデータに基づいて直接分岐してください。顧客に既に検出できる状態を説明させないでください。

Data Connectorが実行された後、その応答は一時的なコンテキストとして利用可能になります。read属性アクションで個々のフィールドを読み取り、その値に直接分岐するConditionステップを使用してください。

以下の表は、特定のData Connectorフィールド値がConditionステップの分岐とFinが取るべき対応アクションにどのように対応するかを示しています：

各分岐は、その状態に特化した異なる開始メッセージを生成します。

各分岐について、「この分岐のFinの応答は、この正確な状態の実際の顧客が読んでも意味が通じるか？」と自問してください。

正常なコネクタの分岐は誤りやすいことが多いです。なぜなら診断を続けたくなる本能があるからです。それを抑えてください。コネクタが正常に見える場合はそう伝え、会話を前に進めてください。

取得するすべてのデータを見て、それがConditionステップを駆動すべきかどうかを考えてください。

ロジックを厳密に保ち、各分岐を顧客が見る唯一の応答であるかのように書いてください。

データ駆動型手順で最も一般的な失敗モードは、Data Connectorからのエラーではありません。結果が返されない成功した呼び出しです。

通常、これは顧客の入力が何とも一致しないために起こります。

Data ConnectorのURLは正確でなければなりません。顧客がタイプミス、末尾のスラッシュ、その他の変化により意図したコネクタと一致しないURLを提供すると、Data Connectorはエラーではなく空のフィールドを返すことがよくあります。

明示的な処理がなければ、Finは実際には見つけていないデータに基づいて応答を生成し続ける可能性があります。

修正方法は、主要なフィールドが空またはnullかどうかをチェックするConditionステップです。そうであれば、Finは顧客にData Connectors設定でデータコネクタのURLを確認し、正確に入力するように求めます。Data Connectorは修正されたURLを使って再度実行されます。

ほぼ一致するが一致しない入力を試してください：

手順がこれらのケースを検出して回復しない場合、フォールバックパスは十分に強力ではありません。

Data Connectorを呼び出すたびに、すぐ後に「結果なし」のConditionステップを追加してください。

その分岐では：

手順はテストを通じて信頼性が高まります。Intercomは段階的に異なる問題を検出する3つのツールを提供しています。順番に使ってください。各ツールは前のツールが見つけられない問題を見つけます。

手順エディタの右上にあるReviewをクリックしてください（Testの隣）。

Reviewは手順の設定を静的解析し、特定の修正案とともに問題のリストを返します。ビルド時の問題を検出します。例えば：

Reviewは会話を実行したり、Finが実際にランタイムでどう振る舞うかを表示しません。設定のみを検査します。シミュレーションに時間をかける前に構造的な問題を修正するために最初に実行してください。

シミュレーションは開始メッセージに対して手順をエンドツーエンドで実行し、顧客向けの出力はありません。トランスクリプトは最終応答以上のものを示します：Finの各ステップでの思考、選択された分岐、属性の更新、Data Connectorの呼び出し。成功基準を添付して応答、属性値、コネクタ呼び出し、結果を検証し、シナリオを繰り返し可能な合否チェックに変えられます。

シミュレーションはインテントマッチングを完全にバイパスします。手順を直接実行し、トリガーが正しく発火するかはテストしません。インテントルーティングをテストするには、自分だけを対象にしたライブテストを使用してください（後述）。

Reviewがクリアでシミュレーションが合格したら、本物のエンドツーエンド体験をテストします。手順を自分だけを対象にライブ設定します。例えば、メールに自社のdomainが含まれるルールです。これにより、顧客に公開せずに実際の会話で完全な体験をテストできます。満足したら、対象ルールをすべての顧客に更新します。ルール変更の保存は新しいドラフトを作成するため、変更を有効にするには再度Set liveをクリックしてください。

ライブテストはシミュレーションでは捉えられないことを検出します。トリガーが正しく発火すること、実際の会話の流れ、そして各応答が文脈に沿って届く際の感触です。

Finの最初の応答が顧客にとって適切に感じられたテスト会話の割合を追跡します。「正しくルーティングされたか？」だけでなく、「思慮深い人間がこの最初の応答を有用と感じるか？」を問います。

時間をかけて、Intercomで既に利用可能な客観的な指標（解決率、CSAT、会話処理時間）とこれを結びつけます。手順の改善が機能していれば、これらの指標が動くはずです。

順番にレイヤーを進めてください：

手順をライブ設定するたびに、Intercomは「何が変わったか？」のメモを書くよう求めます。その欄を形式的なものではなく、本当の変更履歴として扱ってください。瞬間的には面倒に感じますが、数週間後に特定の変更と指標の変化を結びつける記録となります。

手順は決して完成しません。常に改良を続け、各変更は手順が良くなるという小さな賭けです。バージョン履歴はその賭けの記録です。解決率、CSAT、処理時間が変更後に動いた場合、明確なメモが何がいつ変わったかを示し、推測ではなく特定の編集に変化を追跡できます。

変更が何をし、なぜそうしたのかを書きます。場所だけでなく：

2番目のバージョンは6週間後に行動できるメモです。1番目はそうではありません。

パフォーマンスが低下した場合、バージョン履歴からロールバックします：

既存のメモ（バージョン履歴の鉛筆アイコン）を編集して、過去の変更が実際に何をしたかを明確にすることもできます。

指標が下がったら、まずバージョン履歴を開きます。下落の日付と変更メモを照合します。原因は通常、その直前に出荷された変更です。

Data Connectors Setup and Troubleshooting手順の最初のバージョンは、何かを調べる前に顧客に質問しました。Finは有用なことを言う前に3〜4の質問をしました。技術的には機能していましたが、形式的に感じられました。

次の反復で診断用Data Connectorが導入されました。その単一の追加が手順全体の性格を変えました。Finは質問で始めるのではなく、特定の観察から始められました—「あなたのconnectorは過去7日間で64％の成功率で、最新のエラーは401でした」—そして直接問題の修正に進みました。

その後、意図ルーティングは診断フローから分離されました。Data Connectorsの機能を尋ねる顧客は壊れたconnectorの顧客とは異なる経路を通りました。これにより、単に機能の回答が必要な人に対して多くの無関係な診断質問が排除されました。

各反復は実際の会話で見つかった特定の失敗パターンによって推進されました：誤った分岐に入った顧客、ルーティングが予期しなかったケース、技術的には正しいが文脈で役に立たない応答。推測からの反復はありません。すべて証拠に基づいています。

手順が機能している最も明確な信号はFinの最初の返信の質です。この手順が存在する前は、故障したconnectorについて尋ねる顧客は何度か質問に答えてから指示を受けていました。手順では、Finの最初の意味のある返信は実際に見つけたことを先導します：connectorの状態、過去1週間の成功率、最新のエラーコード。診断はインタビューではなくデータから始まります。

ルーティングの深さも重要です。13の異なる経路があることで、それぞれの状況に合った案内が提供されます。SOAP統合について尋ねる顧客には、サポートされていることについて直接的で正直な回答があり、どこにも導かないトラブルシューティングフローではありません。connectorは正常でもデータが正しくマッピングされていない顧客は、最初に認証トラブルシューティングに送られません。

会話で人間のエージェントが必要な場合、引き継ぎメモにはすでにconnector名、connectorのURL、問題のカテゴリが含まれています。チームメイトは顧客のメッセージを読む前に文脈を把握しています。設計上は小さなことですが、手順の最後の1ステップのメモが引き継ぎを再スタートではなく継続に変えます。

これら6つの原則が組み合わさると、Data Connectorsの例のような手順は予測可能な構造に従う傾向があります：

原則6 — 正直なchangelogを保つこと — は構造の一歩ではありませんが、時間とともに全体を改善可能にするものです。何がいつ変わったかの明確な記録がなければ、すべての反復は推測に過ぎません。

最高のFin Proceduresは、巧妙な最初の草案のおかげで効果的になるのではありません。実際の会話からの証拠によって、すべての反復が推進されるため効果的になります。

最もボリュームの多いprocedureから始めましょう。まず原則1を適用してください：受け取る可能性のあるすべてのintentをマッピングし、ルーティングが機能していることを確認します。そこから構築していきます。

最初のバージョンが出発点です。良いバージョンは、繰り返し洗練されたものです。