顧客サポートチケットのステータスワークフローは、チームが行う業務のための共通言語です。すべての問い合わせに明確なステージがあれば、サポート受信トレイを開く誰もが、新着のもの、対応が必要なもの、進行中のもの、完了したものをすぐに把握できます。同じメンバーが問い合わせの受信、問題の調査、顧客への返信を担うことがある小規模チームでは、この明確さが特に重要です。
有用なステータスシステムに、多くのラベルは必要ありません。むしろラベルが多すぎると、顧客との会話を一覧で確認しにくくなり、どれを選ぶべきか迷いが生じます。目的は、意味のある少数のサポートチケットステージを使い、それぞれをわかりやすく定義し、問い合わせを次の段階へ進めるきっかけについて合意することです。
この記事では、新規の問い合わせから対応中、解決までのシンプルなカスタマーサービスチケットワークフローの作り方と、それを長期にわたって有用に保つ方法を説明します。
共有サポートプロセスでステータス名が重要な理由
ステータス名は、チームが受信トレイを読み、次に何をすべきか判断する方法に影響します。新規とマークされた問い合わせは、まだ対応プロセスに入っていないことをチームに示します。対応中とマークされた問い合わせは、誰かが対応していることを同僚に伝えます。顧客の返信待ちは、なぜ一時的に止まっているのかを説明します。解決済みの問い合わせは、会話が結果に至ったことを示します。
こうした区別がないと、すべての問い合わせが同じように緊急に見えてしまいます。すでに担当者がいる案件をチームメンバーが再び開いて時間を費やしたり、顧客からの返信を待つ会話に混在しているために新規の問い合わせを見落としたりするおそれがあります。明確なチケットステータスの定義は、この曖昧さを減らし、複数人でサポートの責任を共有する際の引き継ぎを容易にします。
名前は、担当者や顧客の種類ではなく、問い合わせの現在の状態を表すべきです。たとえば、担当者は誰が責任を負うかを示し、ステータスは問い合わせが解決までの道のりのどこにあるかを示します。これらの考え方を分けておくことで、ワークフローを理解しやすくなります。
問い合わせ、会話、担当を共有して把握するには、共有チケット管理のための顧客サポートを使うと、これらの要素を一か所にまとめられます。共通のワークスペースがあれば、個々の顧客との会話の文脈を保ちながら、チーム全体で同じステータスの言葉を一貫して使えます。
意味のある少数のステージを定義する
まずは、チームにとって重要なアクションを区別できる最小限のステージから始めましょう。小規模チーム向けの実用的なワークフローでは、4つまたは5つのステータスを使えます。各ラベルは「チームは今、何をする必要があるのか」というシンプルな問いに答えるものであるべきです。
1. 新規
新規は、到着したものの、まだ確認されていない問い合わせに使用します。このステージは明確な出発点を作ります。次のアクションは、問い合わせを読み、顧客が何を必要としているかを理解し、誰が責任を持つべきかを決めることです。
新規を長期的な保留場所にしてはいけません。チームメンバーが問い合わせを評価したら、その実際の次のステップを反映するステータスへ移動します。これにより、新規問い合わせのビューが未対応の作業と一部対応済みの作業の混在になることを防げます。
2. 対応中
対応中は、誰かが問い合わせに積極的に取り組んでいる場合に使用します。問題の調査、回答の作成、解決に必要な情報の調整などが該当します。重要なのは、チームが問い合わせを受け入れ、担当者がそれを先に進められる状態にあることです。
シンプルなワークフローでは、このステータスでさまざまな種類の対応中の作業をカバーできます。それらのラベルを追加してもチームの対応方法が変わらないなら、可能なすべての作業に別々のラベルを設ける必要はありません。割り当てられた担当者と会話の文脈で詳細を確認できる一方、ステータスは一覧で把握しやすいままにできます。
3. 顧客の返信待ち
顧客の返信待ちは、顧客から情報、確認、返信が提供されるまで、チームが合理的に次のステップへ進めない場合に使用します。このステータスは、保留中の会話と、チームがまだ対応する必要がある問い合わせを区別できるため、特に有用です。
また、フォローアップの判断も明確になります。チケットを忘れられたものとして扱うのではなく、チームはその問い合わせが外部からの入力待ちであることを確認できます。顧客から返信があり、さらに対応が必要であれば、対応中に戻します。
4. 解決済み
解決済みは、顧客の問い合わせに回答した、または問題が結果に至った時点で使用します。このステータスはチームに明確な完了地点を与え、完了した会話と進行中の作業を分けます。
解決とは、単に何らかの返信を送ること以上の意味を持つべきです。チームが求められた支援、情報、または結果を提供し、現時点でそれ以上の社内対応が不要になった時点と定義しましょう。顧客が新たな質問をした場合や、問題が未解決のままである場合は、新しい作業を反映するステージにチケットを戻します。
5. クローズ：チームで必要な場合のみ
解決済みの会話をレビューした後、または対応が不要になった後に、別途クローズのステータスが役立つチームもあります。一方で、解決済みで止めてもよいチームもあります。他のワークフローにあるからという理由だけで、クローズを追加してはいけません。チームにとって実際に繰り返し生じる意味のある区別を表す場合にのみ追加してください。
同じ原則は、追加するすべてのステータスに当てはまります。ラベルが存在する価値を持つのは、誰かがより適切な次のアクションを判断する助けになる場合だけです。
問い合わせを次のステージへ移す条件を明確にする
ラベルだけではワークフローになりません。信頼できる顧客サポートチケットのステータスワークフローでは、ステージ間の移行も定義します。同じような会話を扱う際にチームメンバーが同じ結論に達せるよう、各移行について短いルールを書きましょう。
基本的な移行ルールは、次のようになります。
- 新規から対応中：チームメンバーが問い合わせを確認し、次のアクションの担当を引き受けた。
- 対応中から顧客の返信待ち：次の重要なステップが、顧客の返信、詳細情報、または確認に依存している。
- 顧客の返信待ちから対応中：顧客が返信し、チームが行うべき作業がある。
- 対応中から解決済み：問い合わせが結果に至り、それ以上の社内対応が不要である。
- 解決済みから対応中：新しい情報により、さらなる対応が必要であることが分かった。
これらのルールを長大なマニュアルにする必要はありません。各ステータスにつき1文か2文で十分です。重要なのは、顧客の問い合わせを扱う全員がルールを確認でき、日常業務で使われていることです。
誰がステータスを変更するかを決めることも役立ちます。小規模チームでは、現在その問い合わせを扱っている人が通常、その更新を行えます。問い合わせを割り当てる前に1人が受信分を確認する場合は、その人がチケットを新規から移す責任を持つことがあります。正確な取り決めはさまざまですが、責任の所在は理解できるものであるべきです。
ステータスは、単に最後に完了したアクションではなく、必要な次のアクションを反映するべきです。
この原則は、判断が難しいケースで役立ちます。チームが返信を送ったものの、なお調査が必要な場合、チケットは引き続き対応中です。チームが顧客からの情報を必要としている場合は、顧客の返信待ちです。直近で何が起きたかの記録よりも、現在の障害や次のステップのほうが有用です。
ステータスを優先度、担当、メモから分ける
ステータスシステムは、問い合わせに関するあらゆる情報を表そうとしないときに最もよく機能します。チームは、「高優先度の調査」や「Samに割り当て済み」のように、異なる考え方を組み合わせたラベルを作ってステージを過剰に使いがちです。こうしたラベルは緊急度、責任、進捗を混ぜてしまうため、一覧で確認しにくくなります。
- ステータスは、問い合わせの現在のステージを示します。
- 担当は、次のアクションに責任を持つ人を示します。
- 優先度は、チームがどれほど緊急に対応または解決すべきかを示します。
- 会話の詳細は、顧客の問い合わせ、返信、関連する文脈を保持します。
これらの要素を分けることで、チームはより明確な業務上の状況を把握できます。ある問い合わせは高優先度かつ対応中であり得ます。別の問い合わせは同じ人に割り当てられていても、顧客の返信待ちである場合があります。どちらの状況にも特別なステータス名は必要ありません。
顧客の問い合わせと担当を整理するための顧客サポートを使うと、問い合わせ、割り当てられた担当者、解決の進捗を会話とともに管理でき、この区別を支えられます。実務上の利点は、チームメンバーが作業のステージとその背景にある文脈の両方を理解できる共有受信トレイです。
進まなくなった問い合わせをレビューする
よく設計されたサポートチケットステージも、定期的な確認が必要です。次のアクションが不明確なために問い合わせが対応中のままになったり、予想以上に長く顧客の返信待ちになったりすることがあります。定期的なレビューにより、こうした停滞した会話が見えなくなる前にチームは発見できます。
レビューは負担の少ないものにしましょう。チームの業務量に合った定期的な間隔で、未解決の各ステータスを確認し、次の点を問いかけます。
- この問い合わせには明確な担当者がいますか？
- 現在のステータスはまだ正確ですか？
- 次のアクションは何で、誰が実行しますか？
- チームは顧客を待っていますか、それともまだ社内で対応すべきことがありますか？
- この問い合わせは今、解決できますか？
このレビューは、受信トレイを整って見せるためだけにチケットを動かすものではありません。明確な次のステップを取り戻すためのものです。問い合わせに意味のある次のアクションがない場合、チームはより多くの情報を必要としている可能性があります。アクションがあるのに担当者がいない場合は、担当を割り当てます。結果に至っている場合は、解決済みにします。
パターンにも注意しましょう。多くの問い合わせが同じステージで繰り返し停滞する場合、その定義が不明確であるか、引き継ぎに注意が必要な可能性があります。混乱を招くラベルや移行ルールを1つ調整することは、新しいステータスをいくつも追加するより価値がある場合があります。
チームにワークフローを導入する
シンプルに導入することで、定着する可能性が高まります。選択したステータス名、その定義、そしてステータス間を移動するルールを共有しましょう。その後、実際に届く問い合わせを使って、システムがチームの実際の疑問に答えられるかをテストします。
今すぐ対応が必要な問い合わせを、同僚がひと目で判断できるか尋ねてください。同じ状況に対して2人が繰り返し異なるステータスを選ぶ場合は、それを個人の不一致と決めつけず、定義を明確にしましょう。例外を暗記しなくても理解できるワークフローにするべきです。
チームが経験を積んでも、例外的なケースのたびにシステムを変更することは避けましょう。持続性のあるカスタマーサービスチケットワークフローは、一般的な業務を明確に扱い、個別の事情は会話メモと担当によって記録できる余地を残します。1件の問い合わせが複雑だったからではなく、チームのサポートプロセスが実際に変わったときに見直してください。
結論：次のアクションを見えるようにする
シンプルなステータスシステムは、小規模なサポートチームに、顧客対応業務をすぐに理解する方法をもたらします。新規、対応中、顧客の返信待ち、解決済みから始め、意味があり繰り返し生じる違いを表す場合にのみ、別のステージを追加してください。各問い合わせを前に進める条件を定義し、担当と優先度を分け、進まなくなった会話をレビューしましょう。
ワークフローを実践に移す準備はできましたか？ 顧客サポートを使うことで、問い合わせ、担当者、解決の進捗を一か所で整理できます。