顧客がサポートを求めて連絡を取るとき、彼らが使用するフォームは彼らの経験全体を形作ります。適切に設計されたチケットフォームは、適切な情報を事前に取得し、リクエストを適切なチームに自動的にルーティングし、顧客とエージェントの両方をイライラさせるやり取りを減らします。
Zendeskのチケットフォームは、このエクスペリエンスの基礎です。それらは、顧客がリクエストを送信するときに提供する情報と、その情報がサポートチームのためにどのように整理されるかを決定します。これらのフォームのアカウント設定を正しく行うことは、効率的なサポート業務を実行するために不可欠です。
このガイドでは、チケットフォーム用にZendeskアカウント設定を構成する方法について説明します。最初のフォームを設定する場合でも、さまざまなリクエストタイプに対して多数のフォームを管理する場合でも、フォームを作成、カスタマイズ、および最適化するための管理手順を学習します。
基本的な構成を超えてフォームの外観と動作をカスタマイズする方法を探している場合は、Zendeskリクエストフォームのカスタマイズに関するガイドで、JavaScript API統合やカスタム開発などの高度なオプションについて説明します。
必要なもの
チケットフォームを構成する前に、以下を確認してください。
- 管理者アクセス権を持つZendeskアカウント
- 必要な機能に適したプラン：複数のチケットフォームには、Suite Growth+またはSupport Enterpriseが必要です
- チケットフィールドの基本的な理解（カスタムフィールドは、フォームに追加する前に個別に作成する必要があります）
- 管理センター（Admin Center）（従来の管理インターフェースではない）へのアクセス
前提条件が整ったら、構成プロセスから始めましょう。
ステップ1：Zendeskアカウントでチケットフォーム設定にアクセスする
**管理センター（Admin Center）> オブジェクトとルール（Objects and rules）> チケット（Tickets）> フォーム（Forms）**に移動して、チケットフォームを管理します。
[Forms（フォーム）]ページには、[Active（アクティブ）]タブと[Inactive（非アクティブ）]タブの2つのタブにすべてのチケットフォームが表示されます。アクティブなフォームは、エージェントおよび（構成されている場合）エンドユーザーが利用できます。非アクティブなフォームは、両方のグループから非表示になりますが、後で再アクティブ化できます。
すべてのZendeskアカウントは、少なくとも1つの標準フォームである**デフォルトチケットフォーム（Default ticket form）**から始まります。このフォームは、アクティブなチケットフィールドが1つしかない場合、すべてのアクティブなチケットフィールドを自動的に含みます。追加のフォームを作成すると、作成した新しいフィールドはデフォルトフォームに自動的に表示されません。手動で追加する必要があります。
デフォルトフォームはフォールバックとして機能します。アカウント内のブランドが割り当てられたフォームにアクセスできない場合、Zendeskは代わりにデフォルトフォームを使用します。このため、Zendeskは、複数のフォームを使用する場合でも、すべてのブランドにデフォルトフォームを割り当てておくことを推奨しています。
ステップ2：新しいチケットフォームを作成する
**フォームを追加（Add form）**をクリックして、特定のリクエストタイプ用のカスタムチケットフォームを作成します。いくつかの構成オプションを備えたフォームエディターが表示されます。
フォーム名（Form name）：これは、エージェントがチケットインターフェースのドロップダウンに表示されるものです。「技術サポート（Technical Support）」や「請求に関するお問い合わせ（Billing Inquiry）」など、わかりやすいものを選択してください。
エンドユーザーの可視性（End-user visibility）：「エンドユーザーが編集可能（Editable for end users）」をオンにすると、ヘルプセンター（Help Center）でフォームを利用できるようになります。エージェントのみにこのフォームを使用させたい場合は、このチェックを外したままにします。
エンドユーザー名（End-user name）：オプションで、顧客に別の名前を表示します。たとえば、エージェントには「セールスリクエストフォーム（Sales Request Form）」が表示され、顧客には「セールスへのお問い合わせ（Contact Sales）」が表示される場合があります。
ブランド制限（Brand restrictions）：複数のブランドを管理する場合は、このフォームを使用できるブランドを制限します。これは、ブランドごとに目的が異なり、異なるインテークフィールドが必要な場合に役立ちます。
フィールドの追加（Adding fields）：右側のパネルからフィールドをフォームにドラッグし、フォーム領域内でドラッグして並べ替えます。利用可能なフィールドは次のとおりです。
- テキスト（1行および複数行）
- ドロップダウンメニュー（Dropdown menus）
- チェックボックス（Checkboxes）
- 日付ピッカー（Date pickers）
- 数値フィールド（Numeric fields）
- 正規表現検証フィールド（Regular expression validation fields）
- 複数選択フィールド（Multi-select fields）
- ルックアップリレーションシップフィールド（Lookup relationship fields）
重要な制限（Important limitation）：フィールドプロパティは、フォームレベルではなく、フィールドレベルで設定されます。フィールドを必須にすると、それが表示されるすべてのフォームで必須になります。同じフィールドを1つのフォームでは必須にし、別のフォームではオプションにすることはできません。それに応じてフィールド戦略を計画してください。
ステップ3：フォームフィールドと条件ロジックを構成する
フィールドの配置（Field arrangement）：フォームにフィールドが表示される順序は、ユーザーエクスペリエンスにとって重要です。必須フィールドを最初に配置し、関連するフィールドをグループ化し、情報収集の論理的な流れを考慮してください。ドラッグアンドドロップで並べ替えます。
条件付きフィールド（Conditional fields）：より動的なフォームの場合、他の選択に基づいてフィールドを表示または非表示にできます。これには、ほとんどのプランで利用できる条件付きチケットフィールド機能が必要です。
条件ロジックを設定するには：
- 最初に必要なすべてのフィールドを作成します（トリガーフィールドと条件付きフィールドの両方）
- チケットフォームエディターで、条件付きフィールドセクションを見つけます
- 「製品カテゴリ（Product Category）がハードウェア（Hardware）と等しい場合にのみ製品モデル（Product Model）フィールドを表示する」のようなルールを定義します
避けるべき一般的なフィールド構成の間違い：
- フォームの放棄を増やす、必須フィールドを多すぎること
- 循環依存関係を作成する条件ロジックを使用すること
- フィールドプロパティがすべてのフォームにグローバルに適用されることを忘れること
- ライブにする前に、実際のデータでフォームをテストしないこと
ステップ4：複数のチケットフォームを管理および整理する
![フォームのステータスを管理するためのオプション（[非アクティブ化]や[デフォルトにする]など）を示すドロップダウンメニュー。](/_next/image?url=https%3A%2F%2Fzen-marketing-documentation.s3.amazonaws.com%2Fdocs%2Fen%2Fticket_forms_make_default_v2.png&w=1680&q=75)
デフォルトフォームの変更（Changing the default form）：デフォルトとして使用するフォームにカーソルを合わせ、オプションメニューをクリックして、**デフォルトにする（Make default）**を選択します。以前のデフォルトは、編集して[エンドユーザーのフォーム名（Form name for end users）]の選択を解除しない限り、エンドユーザーに表示されたままになります。
フォームの並べ替え（Reordering forms）：[Forms（フォーム）]ページにフォームが表示される順序は、エージェントとエンドユーザーのドロップダウンに表示される順序と同じです。フォーム名をクリックしてドラッグし、並べ替えます。リストの最初のフォームは、AIエージェントチケット（AI agent tickets）のデフォルトで使用されます。
アクティブ化と非アクティブ化（Activating and deactivating）：現在使用していないフォームを非アクティブ化します。これにより、フォームを削除したり、以前に適用されたチケットに影響を与えたりすることなく、エージェントとエンドユーザーの両方から非表示になります。[非アクティブ（Inactive）]タブに切り替えて[アクティブ化（Activate）]を選択すると、リアクティブフォームになります。
複製と新規作成（Cloning vs creating new）：わずかな変更を加えた同様のフォームが必要な場合は、既存のフォームを複製します。これにより、ゼロから構築するよりも時間を節約できます。要件が大幅に異なる場合は、新しいフォームを作成します。
ステップ5：エンドユーザーにフォームを提示する
ヘルプセンターの統合（Help center integration）：エンドユーザーに表示されるようにマークされたフォームは、ヘルプセンター（Help Center）の[リクエストを送信（Submit a request）]ページに自動的に表示されます。ユーザーは自分のニーズに合ったフォームを選択し、そのリクエストタイプに関連するフィールドを表示します。
Web Widget（クラシック）（Web Widget (Classic)）：Webサイトにサポートを直接埋め込みます。管理センター（Admin Center）> チャネル（Channels）> クラシック（Classic）> Web Widgetに移動して、ウィジェットに表示するフォームを構成します。一部のフィールドタイプ（Regex、Date、Multi-select）は、Web Widgetではサポートされていないことに注意してください。
ダイレクトフォームURL（Direct form URLs）：URLパラメーターを使用して、特定のフォームに直接リンクします。形式は次のとおりです。
https://{company}.zendesk.com/hc/en-us/requests/new?ticket_form_id={form_id}
カスタムフィールドの場合は、tf_subject=Issue descriptionやtf_{field_id}=valueのようなパラメーターを追加して、フィールドを事前に入力することもできます。
ライブ前にテスト（Testing before going live）：広く利用可能にする前に、常にエンドユーザーの視点からフォームをテストしてください。テストチケットを作成し、フィールドが正しく表示されることを確認し、条件ロジックが期待どおりに機能することを確認します。
一般的な問題とトラブルシューティング
正しい構成であっても、問題が発生する可能性があります。一般的な問題の解決策を以下に示します。
フォームがエンドユーザーに表示されない（Form not appearing for end users）：フォーム設定で[エンドユーザーが編集可能（Editable for end users）]が選択されていることを確認します。また、フォームがアクティブであり、非アクティブではないことを確認します。
フィールドが期待どおりに表示されない（Fields not showing as expected）：フィールドプロパティはグローバルであることを忘れないでください。フィールドが必須の場合、どこでも必須です。フィールドが条件ロジックによって非表示になっている場合は、トリガーフィールドに正しい値があることを確認します。
デフォルトフォームが予期せず変更される（Default form changing unexpectedly）：これは、ブランド制限が誤って構成されている場合に発生する可能性があります。ブランドが割り当てられたフォームにアクセスできない場合、Zendeskはデフォルトフォームにフォールバックします。フォーム設定でブランドの割り当てを確認してください。
フォームの順序がドロップダウンに反映されない（Form order not reflecting in dropdowns）：フォームの順序の変更はすぐに有効になりますが、ブラウザのキャッシュにより更新が遅れる場合があります。キャッシュをクリアするか、シークレットウィンドウでテストしてみてください。
フォームが複雑になりすぎた場合：代替アプローチ
チケットフォームは、構造化された予測可能なリクエストタイプに適しています。ただし、制限があります。フォームは静的であり、ビジネスの変化に応じてメンテナンスが必要であり、顧客はサポート構造を理解する前に自分の問題を分類する必要があります。
フォーム戦略を見直す必要がある兆候：
- 多数のフォームがあり、顧客はまだ間違ったフォームを選択している
- 条件ロジックが依存関係の迷路になっている
- 新しい製品またはサービスを追加するには、複数のフォームを更新する必要がある
- フォームが長すぎるか混乱しているため、顧客がフォームを放棄する
eesel AIは、別のアプローチを提供します。静的なフォームを構成する代わりに、既存のZendeskデータ（過去のチケット、マクロ、ヘルプセンター記事）から学習し、会話形式でインテークを処理するAIエージェントを展開します。
AIは、厳格なフォームフィールドではなく、会話を通じて自然にコンテキストを収集します。ドロップダウンから顧客が選択したものではなく、会話の内容に基づいて適切な部門を決定します。また、情報を収集するだけでなく、人間の介入なしに一般的な問題を解決できます。
すでにZendeskを使用しているチームの場合、eesel AIは既存のセットアップと直接統合します。何も置き換える必要はありません。AIは現在の構成と並行して動作し、ルーチンの会話を処理し、複雑な問題をチームにエスカレートします。
適切なチケットフォーム戦略の選択
チケットフォーム用にZendeskアカウント設定を構成すると、顧客がサポートシステムとどのようにやり取りするかを制御できます。手順は簡単です。管理センター（Admin Center）の[Forms（フォーム）]ページにアクセスし、さまざまなリクエストタイプ用のフォームを作成し、フィールドと条件ロジックを構成し、複数のフォームを効果的に整理し、ヘルプセンター（Help Center）またはWeb Widgetを介してエンドユーザーに提示します。
フォームを長期にわたって維持するためのベストプラクティス：
- フォームがまだビジネスニーズに合っていることを確認するために、四半期ごとにフォームを確認します
- 顧客が最も使用するフォームと、避けるフォームを監視します
- 必要な情報を取得しながら、フォームをできるだけシンプルに保ちます
- チームがロジックを理解できるように、フォーム戦略を文書化します
顧客エクスペリエンスの向上よりもフォームの管理に多くの時間を費やしている場合は、会話型AIアプローチがチームと顧客にとってより適切かどうかを検討してください。eesel AIのAIエージェント（AI Agent）は、インテークの複雑さを自動的に処理し、フォームを構成するのではなく、問題の解決に集中できるようにします。
