チケットのライフサイクルとヘルプデスクでのクライアントとのコミュニケーション
概要
この記事では、ヘルプ デスクでのチケットの作成方法と、システムへのクライアントのアクセスに応じたチケット発行プロセスについて説明します。 さまざまなチケットプロセス設定で何に注意すべきかについてのヒントが見つかります。
この記事には、さまざまな構成に関するヒントと提案が含まれていますが、構成の作成方法については直接説明されていません。 関連記事は次のとおりです。
- ヘルプデスクのドキュメント
- 取扱説明書 （ワークフロー、通知設定）
XNUMX つの主要な通信ルート
まず、チケットが最初から最後まで XNUMX 種類のフローのみをたどる、単純な状況でのチケット ライフサイクルのスキームから始めます。
- メール
- アプリケーション内のフルユーザー
- アプリケーションのヘルプ デスク ユーザー
チケット内の作成とさらなるコミュニケーション
チケットの作成とさらなるコミュニケーションでは、上記のアプローチを組み合わせることができます。
電子メールでチケットを作成し、アプリケーションでフォローアップすることができます (フル ユーザーまたはヘルプ デスク ユーザーによる)。 システム経由でチケットを作成し、電子メールのみをフォローすることも可能です。
例
- チケットは電子メールで作成されます。クライアントは新しい電子メールをヘルプデスクのアドレスに送信します。
- クライアントはシステムにログインし、チケットの作成者であるため、そこでチケットを確認できます。
- クライアントは、権限に応じて、ステータスやその他のフィールドを変更したり、コメントを残すことができます。
例
- クライアントはシステムにログインし、新しいチケットを作成します。
- クライアントは電子メールで更新を受信し、これらの更新を監視するだけであり、システムにログインする必要性を感じなくなります。
例
- クライアントがヘルプデスク ポータル経由でチケットを作成する
- クライアントは電子メールのみをフォローしたいと判断し、ポータルにはログインしなくなりました
- 次に、クライアントはポータル経由でフォローしたいと判断し、私をログに記録し、ポータル経由でいくつかの返信を入力します。
クライアントの利便性を考慮して、どの方法でチケットの作成や更新を許可するかを決定できます。 しかし最も重要なことは、チケットが行き止まりにならないように、考えられるあらゆる状況に対応する必要があるということです。 ワークフローとその他の構成には、必要なすべてのオプションが用意されています。
一般的な問題
クライアントは通常のタスク通知に応答しますが、応答は適切に処理されません。
この話は例 2 に関するものです。クライアントは電子メールでチケットに返信していると考えていますが、その電子メールは既存のチケットとペアになっておらず、代わりに新しいチケットが作成されているか、電子メールがシステムにまったく届きません。 クライアントが通知に返信するか、誤って新しい電子メールを作成します。
原因: 電子メール通知設定では、通知アドレスへの返信が想定されていません。
解決策: クライアントの応答は、ヘルプデスクが指定したアドレスに送信する必要があり、チケット番号を含める必要があります。 通知電子メール アドレス (管理 >> 設定 >> 電子メール通知 >> 通知電子メール アドレス (FROM)) は、クライアントからの返信をキャッチし、最初に通知が送信されたチケットと組み合わせるために、ヘルプデスクのメール アドレスと同じである可能性があります。
もう XNUMX つのオプションは、クライアント ユーザーへの通常の電子メール通知を単純に無効にすることです。 オペレーターが受け取るチケットからのメールのみが、ヘルプ デスクのメール テンプレートを介してアクティブに送信されます。
重要なポイント: クライアントは、受信した電子メール メッセージには当然返信したくなるものです。 返信が適切に処理できるメッセージのみを受信するようにしてください。
クライアントがチケットを「不正」ステータスに変更しました
これは主に、クライアントにアプリケーションに (ヘルプ デスク ユーザーではなく) 完全なユーザーがいる場合に発生します。 クライアントにはステータスを含む多くのフィールドを編集するオプションがある場合があり、さまざまなステータスの意味を誤解する可能性があります。 あるいは、ステータスが変更されると期待していても、ステータスが変更されない場合もあります。
原因: クライアントには正しいステータスを設定する責任があります。
解決策: これは明らかなアンチパターンであり、クライアントはタスクのステータスに関するルールを覚えておく必要はありません。
解決策の XNUMX つは、クライアント アカウントをフル ユーザーではなくヘルプ デスク ユーザーに切り替えることです。 ヘルプ デスク ユーザーはチケットを作成し、既存のチケットにコメントを入力できます。ステータスの変更はヘルプ デスクの設定に基づいているため、クライアントが正しいプロセスを「中断」する可能性はありません。 ヘルプ デスク ユーザーのチケット更新は、実際にはヘルプ デスクの電子メール通信ロジックと設定に従うように設計されています。 唯一の違いは、ユーザーが実際にチケットの物理的な形式を確認して操作できることです。
クライアントのために完全なユーザーを維持する必要がある場合、内部プロセスの一部が中断される可能性があるステータス変更 (または他のフィールド変更) を完全に無効にすることをお勧めします。 更新が必要なチケットを追跡するには、フィールドごとなど、他の方法を使用します。 タスクの最終更新日 (最終更新日)、 最終更新者 (最後の更新を行った人)、リスト内のチケットの最後のコメントを表示して、クライアントが更新を行ったことが明確になるようにすることができます。
例 1 のもう少し複雑なシナリオは、電子メールによるチケット通信を許可するが、クライアントがフル ユーザーでログインすることも許可する場合です。 注意すべき点は次のとおりです。
- クライアントが電子メールで返信した後のステータスの変更がグローバル ヘルプ デスク設定で設定されている
- ログインしているユーザーにはステータス変更の強制はありません。常にステータスを現状維持するオプションがあります。
この場合、応答のキューに、電子メールによって更新される状況 (例: 特定のステータスのフィルター) と、アプリケーション内からクライアントによって更新されるチケット (例: 列のあるチケット リスト) の両方のタイプが含まれていることを確認する必要があります。 最後のコメント).
重要なポイント: クライアントは内部プロセスについて心配する必要はありません。クライアントは問題を提出してあなたとコミュニケーションをとる場所が必要なだけです。プロセスはあなたの側にあり、アプリケーションにはそれをしっかりと設定するためのさまざまなオプションがあります。
フルユーザーとヘルプデスクユーザーの混在
これは、決して組み合わせることが意図されていないソリューションを組み合わせないようにするための強い警告にすぎません。 使用するかどうかを決定できます
- ヘルプ デスク ユーザー - 無料、ハードコーディングされた制限付きアクセス、または
- フル ユーザー - 通常のライセンスを取得したユーザー。何にアクセスできるかを決定します。
ただし、特に同じクライアントに対して、両方を同時に使用しないでください。 技術的には、フル ユーザーとヘルプ デスク ユーザーはまったくつながりません。 ログインページも異なります。 これらは、タスクの異なるフィールド (作成者とヘルプ デスクの作成者) を表します。 したがって、両方のアクセス オプションを提供してクライアントを混乱させる必要はありません。
内部プロセスに関しては、一部のクライアントには完全なユーザーを提供し、他のクライアントにはヘルプ デスク ユーザーのみを提供することが技術的に可能です。 ただし、これには、これらの非常に異なるチャネルからのチケットの処理を混同しないように、正確なプロセスの説明とエージェントのトレーニングが必要です。 組織化が難しいため、クライアント アクセスには XNUMX つのオプションのみを選択することを強くお勧めします。
まとめ
以前の情報をわかりやすい形式に戻してみましょう。 以下は、システムへのクライアントのアクセスのタイプに基づいて発生する可能性のある状況の表です。
| アプリケーションへのクライアント アクセス | チケットを送信するオプション (クライアント) |
チケット（代理店）からのお知らせ |
チケットを更新するオプション (クライアント) |
推奨事項 |
| アクセスなし | ヘルプデスクの電子メール アドレスに電子メールを送信します。 | エージェントはチケットからテンプレート経由で電子メールを送信します。 |
|
|
| フルユーザー |
|
|
|
|
| ヘルプデスクユーザー |
|
エージェントはチケットからテンプレート経由で電子メールを送信します。 |
|
|
