チケットを操作するための5つのルール

あなたがクライアントであろうとテクニカルサポートスペシャリストであろうと、リモートで(私たちの場合はチケットを介して)対話するとき、あなたと相手の両方がより規律を必要とします。 各チケットは、独自の実行サイクル、参加者、および目的を持つ個別のタスクです。 それでは、 チケットシステムを介して相互作用を最適化する方法は?



画像



1.一対一のルール



各チケット(「バグ」とも呼ばれる)は、問題を報告した人と問題を解決する人の2人の関係を表します。 これがバグの場合- 誰かがそれを報告し、 誰かが理解し、これが質問の場合- 誰かが彼に尋ね、 誰かが答えます。 この問題の解決に関係するのは、どちらの側の人が何人かに関わらず、このコミュニケーションに関係するのは2人だけです。



チケットを作成する人の責任は、問題について話すことです。 チケットを作成するとき、問題が存在すると主張します。 誰かがすべてが機能していると言うことできます、 誰かがそのようなエラーがないと言うことできます。実際、何が問題なのかを理解しています。 チケットを作成するタスクは、その実行可能性を保証することです。 チケットを作成した場合-あなたは閉会の瞬間まで彼の守護天使です。



2番目の側のタスクは、ソリューションを提供することです。 チケットがあなたに割り当てられている場合、あなたの仕事はあなたのソリューションが最良であることを反対側に納得させることです。 この解決策では不十分であるか、効果がないか、問題を完全に解決できないと言われるかもしれません。 もちろん、あなたの仕事は問題の根本を調査し、可能なすべてのオプションを計算し、良い解決策を提供することですが、主な仕事はチケットを閉じることであるため、これはすべて二次的です。



チケットシステムでは、常に自分の問題に対するビジョンを売ります。



2.閉じてください!



チケットシステムはチャットではなく、あなたはここで話しません。 あなたはあなたの質問を解決するためにここにいます。 数週間閉じられていないチケットは、申請者と技術専門家の両方にとって真の悪夢です。チケットは追跡するのが難しく、管理するのはさらに困難です。 チケットには何百ものコメントを含めることができますが、最終的には実際には何が問題であったかを忘れてしまいます。



これはすべて、両当事者の間違いです。 チケットは、簡潔に要点を定式化する必要があります。 理想的なチケットのシナリオは次のとおりです。問題-質問の明確化-簡単な説明-解決策-チケットのクローズ、ありがとうございました。



3.閉じないでください!



バグを見つけてチケットを作成するたびに、時間を費やします。 テクニカルサポートの従業員がチケットを処理するたびに、プロバイダー企業は多くのリソースを使用します。



チケットのクローズを確認し、問題が実際に解決されない場合、お金とプロバイダーのお金を箱に入れます。 チケットが作成された場合、「わかりました。後でわかります」と言うことはできません。 実行中の場合は、問題を解決するためにすべての対策を講じる必要があります。



このように見てください。チケットを作成したときに、頭の中に特定のタスクがあり、 何かがうまくいきませんでした。 現時点で十分な時間がなく、質問を閉じた場合、他の誰かが将来同じバグを見つけて、この問題を解決するために、自分自身とプロバイダーのものを再度費やすことになります。 世界を少し良くして、リクエストに対する完全な応答を受け取るまでチケットを閉じないでください。



4. Shh ....音を立てないでください!



チケットにコメントを残すたびに、それを他の人に宛ててください;さもなければ、あなたのコメントは単に心理学で「コミュニケーションノイズ」と呼ばれるあなたの意見を表現するものと見なされます。 チケットは、2人の参加者間のコミュニケーションであることに注意してください。



問題を解決するために、あなたが連絡している特定の人に質問/要求/要件に常に対処してください。 それ以外はすべて、問題を解決するプロセスを複雑にしますが、決して助けにはなりません。



5.大声で話す



自分に合わないものについては常に話してください。 問題を報告するたびに、何が間違っていたかを正確に説明してください。 製品内で正確に機能しないもの、文書化されていないもの、問題点を説明するのはあなたの仕事です。 あなたはサービスを受けており、問題を報告するのはあなたの権利であり、あなたの期待に正確に合致しないものを説明するのはあなたの義務です。



チケットの式は次のとおりです。「これは私たちが持っているものですが、私たちが持っているべきものです。」 プロジェクトをポイントAからポイントBに移動します。ポイントAで何かがおかしくなったので、ポイントBにいる方が良いでしょう。明らかに、タスクはポイントAからこのラインを描くことです。ポイントB



質問がある場合、これはドキュメントに十分な情報がないことを意味します-これが問題の根本です。 「Xの接続方法」と尋ねる代わりに、「現在のドキュメントにはXの接続方法に関する情報が含まれていません。記入してください。」



チケットを作成するたびに、アーティストのように感じます-ポイントAからポイントBまで明確な線を引きます。








All Articles