メインコンテンツにスキップ

Fin Proceduresでの指示の書き方

自然言語を使ってFin Proceduresで指示を書く方法を学びましょう。

対応者:Beth-Ann Sher

新しいステップをFin Procedureに追加すると、指示ステップがデフォルトのステップになります。指示ステップは最も強力で、Finが自然言語で実行する一貫した作業単位を定義できます。


指示ステップの機能

指示ステップを実行する際、デフォルトでFinは以下のツールにアクセスできます:

指示ステップ内でこれらのツールを使うには、単に@を入力して検索メニューを開きます。

カテゴリ

ツール

説明

ロジックとフロー制御

@Condition

分岐ロジック(IF / ELSE)を追加します。

@Run sub-procedure

共通のフローを再利用したり、メインフローから隠したい複雑なフローを使えます。

@Create sub-procedure

現在のエディターから直接新しいネストフローを作成します。

データ操作

@Read attribute

Finに特定のIntercomデータを手続きのコンテキストに取り込むよう指示します。これにはPeopleの詳細(名前やユーザーロールなど)、Company情報、Conversationの詳細(現在のチャネル、言語、添付ファイルの有無など)、またはTemporaryカスタム属性が含まれます。例:@read name と入力して顧客の名前で挨拶します。

@Update attribute

Finに任意のintercom属性を@updateするよう指示できます。

注意: Finは匿名のleadsで既存のメールや電話がないPeopleのメール属性のみを、Intercomチームによる機能フラグが有効な場合に限り更新できます。それ以外の場合、連絡先情報保護のため更新要求は拒否されます。

@Create attribute

必要な属性がまだ存在しない場合、その場で新しい属性を作成します。

知識とコンテキスト

@Look up content

FinにHelp Centerや外部knowledge baseで特定情報を検索させます。@Look up contentの詳細はこちら。

@Use data connector (Call an API endpoint)

@use data connectorするとFinはそのAPIエンドポイントにアクセスします。1ステップあたり1つのdata connector使用に最適化してください。

@Create data connector

現在のエディターから直接新しいネストフローを作成します。

ルーティングと終了

@End

手続きを即座に終了し、Finに戻します。

@Handoff to team

会話をチームまたはチームメイトに引き継ぎます。

@Handoff to Workflow

手続きを終了し、ユーザーをWorkflowに渡します。

@Switch procedure

現在の手続きを終了し、別の手続きを即座に開始します。これは一方向の遷移です。Finは現在のProcedureを離れ新しいProcedureに即座に入りますが、新しいProcedure終了後に元のProcedureに戻りません。@SwitchはProcedureの引き継ぎとはみなされず、解決状態も変更しません。対象ProcedureのIDにより直接遷移し、対象のオーディエンス適合性チェックはスキップされます。これにより、会話中に更新されたオーディエンスベースのコンテンツターゲティングを適用できます。会社や顧客属性を更新し、その新しい属性値に対応したProcedureに@Switchすると、そのProcedureが即座に実行され、最初からそのオーディエンスに合致していたかのように動作します。

会話アクション

@Add note

inboxのチームメイト向けのメモとして表示される事前定義メッセージを追加します。

@Tag

Finが会話に動的にタグを適用できるようにします。

注意:

  • 一般的に、“@”で始まらない機能はサポートされていません。例えば、Finはメール送信、電話発信、タグ削除はできません。

  • 「別の手続きに移動」「メモを追加」「顧客のOTPを確認」などの自然言語コマンドは避け、サポートされているツールを使ってください。


ベストプラクティス

指示を書く際の2つの基本設計原則があります

1つの指示ステップは意味のある作業単位を表すべきです

関連するアクションを一貫して組み合わせた、よく設計された少数のステップが多数の小さなステップより優れています。同時にステップは大きすぎないようにしてください。目安として、1ステップあたりのdata connector呼び出しは1回に制限し、update attributeやタグの数も必要最低限に減らしてFinの実行速度を上げます。

❌ 効果が低い例:

Step 1 - @read Email. 

Step 2 - Ask for email if it's not there.

Step 3 - @use get_subscription_details

Step 4 - Send a reply listing every API field.

✅ 効果的で構造化された例:

@read email. If it is not known, ask the user for their email before continuing. Then @use get_subscription_details and reply asking the user what they need help with. Include the user's current plan, plan status, and next renewal date in your reply.  

シンプルで明確に保つ

Finが混乱せず指示に従えるよう、常にシンプルで明確に保つよう最適化してください。文脈なしの人間が理解できない指示はFinも理解できません。

具体的でわかりやすい動詞を使いましょう。日常的な動詞(尋ねる、確認する、送る、更新する、エスカレートする)でステップを書き、抽象的・形式的な動詞(検証する、確かめる、実行する、促進する)は避けてください。

❌ 効果が低い例 - 注文番号や追跡番号が何か不明確:

Collect the customers order number: Collect the customers order number and make sure it is valid and not a tracking number.

✅ よく構造化されたステップ - 注文番号の形状と顧客が提供できない場合の対応をFinに伝える:

Collect the customers order number:

If they provided a number but it is longer than 11 characters excluding the # at the start of the number, then let them know that it may be a tracking number and ask them for the order number again.

If the customer can not provide their order number do not continue @Escalate:Support team

確認ステップは必要な箇所だけに追加する

すべてのステップに確認メッセージは不要です。取り消しが難しい操作(注文キャンセル、サブスクリプションの更新やキャンセルなど)の直前に確認ステップを設けてください。情報収集や表示のみのステップは余計なやり取りを省略し、見つけた内容を表示して顧客に誤りを訂正してもらいましょう。取り消しが難しい操作の直前に一度だけ明確に確認してください。

こちらの回答で解決しましたか?