Ticketの状態は明確な期待値を設定し、顧客とチームメイトの両方がTicketの進行状況を把握できるようにします。これらは4つのカテゴリに分類されます：Submitted、In Progress、Waiting on Customer、Resolved。それぞれに異なる動作があります。

Ticket状態のカテゴリ

以下の表は各カテゴリの説明と、そのカテゴリに属する状態の動作を示しています。

Ticket状態カテゴリ	説明	動作
Submitted	「Submitted」状態はTicketの初期段階を示します。	これらの状態はTicket作成時に割り当てられ、Ticketが共有されると顧客に表示されます。
In progress	「In Progress」状態はTicketに対して作業が行われていることを示します。	これらの状態はTicketが共有されると顧客に表示されます。
Waiting on customer	「Waiting on customer」状態は、Ticketを進めるために顧客からの追加情報が必要であることを示します。	このカテゴリの状態は設定によりSLAを一時停止できます。顧客がこの状態のTicketに返信すると、自動的に「In progress」状態に戻ります。カスタムのIn progress状態が設定されている場合は、そのTicketタイプの「In progress」グループで最初にリストされている状態に移行します。どのカスタム状態をデフォルトにするかは、設定 > Inbox > Ticketsの「In progress」リストの最上部に配置することで制御できます。
Resolved	「Resolved」状態はTicketの作業完了を示します。	これらの状態はTicketが共有されると顧客に表示され、「Time to resolve」メトリックの計測に使用されます。この状態のTicketに顧客が返信しても自動的に再オープンしません。顧客の返信でResolved Ticketを再オープンするには、workflowでSet ticket stateアクションを設定してください。

重要：TicketをResolvedに設定しても会話は自動的に閉じません。詳細はこちらをご確認ください。

重要：エンドユーザーによる参加者の追加は、Waiting on Customer状態からTicket状態を変更し、返信がなくてもSLAタイマーを開始します。これは想定された動作です。

Submitted状態のTicket

ワークスペース内のTicketタイプごとに複数のSubmitted状態を設定できます。設定 > Inbox > Ticketsに移動し、必要なだけSubmitted状態を追加してください。

Submitted Ticketタイプに追加の状態を設定すると、Ticketを異なるSubmitted状態間で移動できるようになります。また、他の状態（例：In progress）からSubmitted状態に戻すことも可能です。

よくある質問

Submitted状態での時間を計測するレポートメトリックはどうなりますか？

過去のデータに変更はありません。Submitted状態での時間を計測するレポートメトリックは、すべてのSubmitted状態での時間を考慮します。最初のSubmittedタイムスタンプが解決までの時間の計測に使用されます。

TicketがSubmittedに戻された場合、メッセンジャーのTicketビューは変わりますか？

いいえ、Ticketビューは期待通りにSubmitted状態に戻り表示されます。

workflowでTicketをSubmittedに戻せますか？

はい、workflowのSet ticket stateアクションからSubmitted状態を選択できます。ただし、Ticketがすでにその状態にある場合、状態変更は処理されません。これはすべてのTicket状態変更に当てはまり、Submittedイベントに限りません。

TicketがSubmitted状態に戻された場合、SLAはどうなりますか？

SLAタイマーはworkflowがトリガーされたときに一度だけ開始されます。TicketがSubmitted状態に戻ってもタイマーはリセットされません。以降のSubmitted状態への更新は他の状態変更イベントと同様に扱われます。

Resolved状態からSubmittedに戻す場合、SLAタイマーはリセットされません。
Waiting on customerからSubmittedに戻す場合、SLAは一時停止解除されます。

カスタムTicket状態

これらのカテゴリのいずれかでTicket状態を作成またはカスタマイズでき、それぞれのカテゴリの動作を継承します。

注意：顧客がWaiting on customer状態のTicketに返信すると、そのTicketは自動的にそのTicketタイプのデフォルトのIn progress状態に移行します。workflowは不要です。デフォルトはそのTicketタイプのIn progressグループで最初にリストされている状態です。顧客がResolvedTicketに返信しても自動的に再オープンしません。これを処理するには、workflowでSet ticket stateアクションを設定してください。

スクリーンショットの例では、デフォルトは「With Us」です。これは、特定のTicketタイプのカスタム状態を、設定 > Inbox > TicketsのIn progressリストの最上部に配置することで、どのカスタム状態をデフォルトにするか制御できることを意味します。

カスタム状態を使用している場合、顧客が返信すると、Ticket状態リストの最初/上位の「In progress」状態に切り替わります。

注意：

すべてのTicketタイプはこれらのカテゴリから少なくとも1つの状態を含む必要があります。
Ticket状態は複数のTicketタイプで共有可能です。
ワークスペース全体のTicket状態は同じ内部ラベルを持つことはできませんが、同じ顧客向けラベルを共有することは可能です。

📖 カスタムTicket状態の作成方法とTicket状態のレポート方法を学びましょう。

Inboxでのチームメイトの体験

チームメイトはInboxからTicket作業中にTicket状態（カスタムTicket状態を含む）を確認できます。これらはメインのTicketビュー、リンクアプリ内、Command-Kを使った状態遷移時に表示されます。

利用可能なTicket状態は、そのTicketタイプで設定された状態によります。

InboxのドロップダウンでTicket状態を表示するには、Ticket状態inboxフィルターをオンにする必要があります。👇

設定 > Inbox > TicketsのTicket statesでオンにしてください。

SlackとJiraでのチームメイトの体験（Tickets用）

Ticket状態の内部ラベルはSlack通知に反映されます。

およびJira for Tickets。

顧客体験

顧客はTicketが共有されると、Messenger、メール、またはCustomer portalでTicket状態の顧客向けラベルを確認できます。

Ticket状態を編集またはカスタマイズすると、顧客はMessengerや新しいメール通知で更新されたTicket状態ラベルを確認できます。

更新前に送信されたメールは元のTicket状態ラベルのままです。

API

tickets APIを使って単一のTicketをGETすると、Ticketのカスタム状態の内部および外部ラベルを確認できます。

現在、API経由で変更できるのはTicketのシステム状態のみです。変更すると、そのシステム状態に一致するticket typesページの最初のカスタム状態に設定されます。例えば、「In progress」に移動したTicketは、ticket typesページの「In progress」セクションの最初のカスタム状態に設定されます。

Ticket状態はAPI経由で管理（作成やアーカイブなど）できません。