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

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を再オープンするには、Set ticket stateアクションを使ったworkflowを設定してください。

重要: 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状態変更に当てはまります。

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グループで最初にリストされている状態です。Resolved状態のTicketに顧客が返信しても自動的に再オープンしません。これを処理するには、Set ticket stateアクションを使ったworkflowを設定してください。

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

カスタム状態を使用している場合、顧客が返信すると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のカスタム状態はTicketタイプページの該当システム状態に一致する最初のカスタム状態に設定されます。例えば、「In progress」に移動したTicketは、Ticketタイプページの「In progress」セクションの最初のカスタム状態に設定されます。

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