ヘルプデスク

用語
ヘルプデスクプロジェクトの構造を決定する
Easy Projectにメールボックスを接続する
プロジェクト構成を設定する方法
プロジェクト構成のセットアップ方法–詳細
チケット処理の使い方
メールテンプレートを設定する方法
グローバル設定を構成する方法
フィルタ "反応が必要"
ヘルプデスク ユーザー
コーナー状況

これらの手順では、UIからヘルプデスクを構成するためのすべての手順を実行します。 メールボックスのEasyProjectへの接続から、プロジェクト設定、ダッシュボードの微調整まで。 これは、cron（またはサーバー側でスケジュールされたタスク）を構成するための技術マニュアルではありません。 HelpDeskを機能させるには、cronがすでに構成されている必要があります。

 

0用語

次のマニュアルの最初の用語集から始めましょう。

メールボックス -Easy Projectに接続された電子メールアドレス。受信した電子メールは、それぞれのヘルプデスクプロジェクトでチケットに処理されます。
チケット -メールボックスで受信した電子メールから作成されたタスク、またはヘルプデスクプロジェクトでクライアントによって内部的に作成されたタスク
ヘルプデスクプロジェクト– チケットを作成できるヘルプデスクに接続されたプロジェクト
ドメイン– 電子メールアドレスの2番目の部分 たとえば、email worker.Joe@client.comのドメインはclient.comだけです。
キーワード– に含まれる単語または単語の文字列 メールの件名
SLA - サービスレベルの学位 Easy Projectで使用されている簡略化された意味で、クライアントから送信されたチケットに会社が対応する時間を短縮しました。 時間で計算
元のメール– チケットが作成されたヘルプデスクメールボックスに送信された電子メール
演算子 - この用語は、チケットを扱うサポートワーカーに使用されます。

 

1ヘルプデスクプロジェクトの構造を決定する

すべてのチケットに対して単一のプロジェクトを作成するか、ヘルプデスクメールボックスを区別するか、または異なるクライアント用に特別なプロジェクトを作成するかによって、構成を開始する前にプロジェクトの構造を決定する必要があります。 この決定は、このマニュアルに記載されているその他の手順に影響します。

ここでは可能性があります：

1.1すべてのチケットの単一プロジェクト

XNUMXつのメールボックスからメールを収集するプロジェクトがXNUMXつしかない場合は、決定する必要はありません>> メールボックスに送信されたすべての電子メールは、同じプロジェクト内にチケットを作成します。

例：すべてのクライアントはsupport@mycompany.comにサポート要求を送信します

このプロジェクトがどのレベルであるかは関係ありません。基本的に、プロジェクト構造のどの部分でも独自の生活を送っています。 ただし、単一のプロジェクトから始めて、後でHelpDeskを拡張し続けることを計画している場合は、以下のオプションが表示されます。

1.2 XNUMXつのメールボックス、より多くのヘルプデスクプロジェクト

例：メールボックスsupport@mycompany.comを使用します。 受信したすべての電子メールは、一般的なプロジェクトに入ります。 しかし、特別なプロジェクトと特別な条件を持つXNUMX人のクライアントがいます>ドメインclient.comからの電子メールは特別なプロジェクトで処理されます。

もちろん、この方法でもっと多くの顧客を切り離すことができます。 この場合、プロジェクト構造は次のようになります。

もうXNUMXつのオプションは、最初のレベルにデフォルトのヘルプデスクプロジェクトを配置し、その下に特別なプロジェクトを配置することです。

時々使われるかもしれない異なった方法は構造です：

> Client1
>>商業プロジェクト
>>実施のためのプロジェクト
>>ヘルプデスクのプロジェクト

> Client2
>>商業プロジェクト
>>実施のためのプロジェクト
>>ヘルプデスクのプロジェクト

ただし、さまざまな問題からいくつかの集計リスト、統計、または要約へのチケットを収集することを計画している場合は、これはお勧めできません。

1.3より多くのメールボックス、特別なクライアントプロジェクトはありません

例: メールボックスsupport@mycompany.com、info@mycompany.com、it@mycompany.comを使用しており、メールはメールボックスに従ってのみソートされます。 送信者によると。

そのような場合は、3プロジェクトを同じレベルにして、おそらくそれらすべてをカバーするメインプロジェクトの下に置くことができます。

これらのプロジェクトは完全に無関係で、組織の別々のセクションに分類されることがあります。それらは異なるプロジェクトツリー（異なる上位プロジェクトの下）に存在することがあります。

1.4特別なクライアントプロジェクトを含む、より多くのメールボックス

現在のEasyProject HelpDesk機能では、送信者と受信メールボックスの組み合わせではなく、送信者のみがクライアントを分離できます。

例： メールボックスsupport@mycompany.com、info@mycompany.com、it@mycompany.comを使用しています。 ドメインclient.comからサポートリクエストを送信する特別なクライアントがあります

推奨構造は次のとおりです。

一般的なプロジェクト構造に戻るときは、さらに考慮すべき点がいくつかあります。 ヘルプデスク処理を組織の別の部門（開発など）と統合することを目的としている場合は、ヘルプデスクプロジェクトをプロジェクト構造のもう少し深いところに配置することを検討することをお勧めします。

正しいプロジェクト構造により、ビジネスのさまざまなフェーズにわたってさまざまなレポート、リスト、統計を生成できます。

 

2メールボックスをEasyProjectに接続する

これで、HelpDeskコンポーネントの実際のセットアップから始めることができます。 Easy Projectでメールボックスを処理するには、次の方法で接続する必要があります。

2.1管理>>ヘルプデスク>>すべてのメールボックス>>メールボックスの追加

2.2メールボックスの有効な資格情報を入力する– テストをクリック Easy Projectがメールボックスに確実にアクセスできるようにする

設定メモ：

• アクティブ -メールボックスは、Easy Projectによって定期的にスキャンされ、新しい未読メッセージがないか確認されます。 無効にすると、EasyProjectはメールボックスをチェックしません。 ただし、将来の使用に備えて、メールボックスをEasyProjectに保持することができます。
• 別の送信者を使用する -メールサーバー上のユーザーがメールボックスと同じでない場合（たとえば、HelpDesk-mail-user）。 ここに、ユーザーが表す有効なマリボックスを入力します。
• SSL -メールサーバーでSSL証明書を使用する場合
• OAuthを有効にする – OAuth 2.0プロトコルは、代替の認証方法として、何百もの有名なサービスで使用されています。 ヘルプデスクのメールボックスについては、外部アプリケーションを使用して送信者の資格情報を確認するために使用できます。現在サポートされているのは Googleワークスペース （以前のG Suite）と Microsoft Exchangeの アカウント。 各フィールドに正確に何を入力するかを知るには、他のアプリケーションのOAuth2.0ドキュメントを読む必要があります。 もちろん、サイトURL、クライアントID、クライアントシークレット、認証URL、トークンURL、スコープなどの必要な情報を見つけるには、他のアプリケーションへの管理者アクセス権が必要です。
  
• フォルダ --Easy Projectで、特定のフォルダーのみに未読メールがないかチェックする場合。
• 成功するとに移動します –メールがEasy Projectによって正しく処理された場合（チケットが作成された場合）、そこに移動されます
• 失敗した場合はに移動します –電子メールが正しく処理されない場合（チケットが作成されていない場合）、そこに移動されます

接続をテストしたら、[追加]をクリックします。

2.2.1MicrosoftおよびGoogleアカウントのOAuth2.0クレデンシャルの場所

OAuth2.0プロトコルを使用してEasyProjectをGoogleWorkspaceアカウントに接続するには、でアカウントを作成する必要があります。 Google Cloud Platform、そこに提供されている必要な資格情報を取得し、アプリケーションのメールボックス設定にコピーします。 いくつかの便利な手順が見つかります こちら.

EasyProjectをOAuth2.0プロトコルを使用してMicrosoftExchangeアカウントに接続するには、でアカウントを作成する必要があります。 Microsoft Azure ポータルで、そこに提供されている必要な資格情報を取得し、アプリケーションのメールボックス設定にコピーします。 いくつかの便利な手順が見つかります こちら.

アクセス トークンには有効期限があり (最大 6 か月)、無制限のものを作成することはできません。 この時間が経過すると、メールボックスは機能しなくなり、新しいトークンを生成してアプリケーションに再入力する必要があります。

" という形式の OAuth 2.0 アクセス URL/organizations/oauth2/v2.0/authorize" は、アプリケーションへのアクセスが組織内で有効になっている場合にのみ有効です。それ以外の場合、アクセス URL は "/[テナントID]/organizations/oauth2/v2.0/authorize"。正しい設定は、[エンドポイント] セクションにあります。

Microsoft Azure で 2 要素認証 (XNUMXFA) が設定されている場合、接続されているすべてのメールボックスを更新する必要があります。

2.2.1.1 エラー「ユーザーは認証されていますが、接続されていません」

これは、メールボックスの登録に使用された、選択された Azure ユーザーがメールボックスにアクセスする権限を持っていないためです。 この場合、Office 365 を使用するにはライセンスが必要なため、ユーザーが管理者である場合は十分ではありません。ユーザーが権限を委任している場合 (管理者などによる承認が必要なため、メールボックスへのアクセスを追加することはできません) )、彼は Azure で適切なスコープのアクセス許可を取得し、同時にこのオプションを無効にする必要があります。

解決法：

• ユーザーは、アクセスしているメールボックスの直接の所有者である必要があります (そのために必要なアクセス許可を持っています)。
• または、そのメールボックスへのアクセスを許可された別の (ライセンスを取得した) ユーザーである可能性もあります。

もう 3 つの考えられる問題は、アカウントが IMAP ではなく POP3 として作成されていることです。 POPXNUMX はシステムで OAUTH をサポートしていません。

解決法：

• Azure と Easy Project の両方でアカウントが IMAP として設定されていることを確認してください。

2.2.1.2 エラー: Microsoft Help Desk は正常に接続されますが、しばらくすると動作しなくなります

オフライン アクセスの権限を有効にするのを忘れました。

2.2.1.3 ユース ケース: 多数のメールボックス、XNUMX 人のスーパー ヘルプ デスク ユーザー

Microsoft Exchange 内に複数のヘルプ デスク メールボックスが設定されていて、これらすべてのメールボックスへのアクセス権を XNUMX 人のユーザーに委任したい場合は、 Microsoft365管理センター » 管理センター » Exchange。

Exchange 管理センター セクションにリダイレクトされます。 ここで、[受信者] » [メールボックス] タブをクリックし、アクセス権を委任するメールボックスを選択します。 右側のポップアップ サイドバーが開き、[委任] をクリックします。

下にある [読み取りと管理 (フル アクセス)] のサインと [編集] ボタンをクリックします。

次に、メールボックスの所有者と同じ権限を持つこのメールボックスのメンバーになるユーザーを検索して追加できます。

選択したユーザーは、Easy Project 側でヘルプ デスク管理者権限を持っている必要があります。

2.2.2 Azure Active Directory で OAuth 2.0 認証を有効にする

OAuth 2.0 認証を使用すると、クライアント アプリケーションから Web サービスにアクセスできます。 これを行う方法は、使用する助成金によって異なります。 このチュートリアルではでは、Azure Active Directory でアプリケーションのクライアント資格情報の付与タイプを構成する方法を学習します。

2.3 メールボックス スキャンの頻度を設定する

メールボックスを右クリックして[設定]を選択します。

これでメールボックス設定に戻りましたが、追加設定があります。 デフォルトでは、毎分5分に設定されています。 しかし、10分ごとにこの設定をすることをお勧めします。 Easy Projectに接続されているメールボックスが多数ある場合は、この自動スキャンタスクの実行時間が長くなり、頻繁なスキャンでサーバーが過負荷になり、アプリケーション全体の動作が遅くなる可能性があります。

ボタンのメモ：

• 実行–メールボックススキャンを手動で開始します
• 履歴–過去のメールボックススキャンを表示
• 削除– EasyProjectでスキャンしたメールボックスからメールボックスを削除します
• 非アクティブ化–自動メールボックススキャンを非アクティブ化します

2.4 自動無効化

メールボックスを定期的に処理すると、特に複数のメールボックスがある場合、サーバー リソースが消費されます。 このため、メールボックスの処理を自動的に無効にするメカニズムを実装しました。 メールの認証とダウンロードに 3 回失敗しました. Disable は、フィールド Active がオフになることを意味します。 設定の確認、テスト、有効化は引き続き行うことができます。

なぜ？ リソースを節約するため。 サーバーが機能していないメールボックスに ping し続ける必要があるのはなぜですか?

 

3プロジェクト構成

メールボックスはEasyProjectによって接続およびスキャンされますが、これまでのところ、チケットを作成する場所を設定していません。 プロジェクトがヘルプデスクに接続される前は、一般にすべてのタスクにプロジェクトが必要なため、チケットを作成することはできません。

この部分は、各プロジェクトの目的に応じて、さまざまなシナリオに分割されます。

3.1メールボックスのデフォルトプロジェクト

前の章の例では、これがプロジェクトになります デフォルトのヘルプデスク、INFO –一般、IT –一般、SUPPORT –一般、 すなわち、送信者の特定のドメインに制限されていません。

1. クリック "ヘルプデスクに追加選択したプロジェクトのプロジェクト概要ページの「」オプション。
   
2. プロジェクトがデフォルトになるメールボックスを選択します
3. 下にスクロールして Save

この章では、すべてのヘルプデスクプロジェクト設定の完全な説明が続きます。

3.2特別クライアントプロジェクト

第X章1の例から、これらはプロジェクトでしょう： Bohemia Sun、Trains Francais、クライアント123、クライアントABC、クライアントXYZ、クライアント1 >>ヘルプデスクのプロジェクト、クライアント2 >>ヘルプデスクのプロジェクト

1. プロジェクトを選択
2. 下記のハイライトされたフィールドに記入してください。 設定メモはスクリーンショットの下にあります
3. 下にスクロールして 保存します。

設定メモ：

• メールボックスのデフォルト - しない] このプロジェクトを特別なクライアントプロジェクトとして設定する場合は、任意のメールボックスを選択してください。
• このプロジェクトに処理されたメール、ドメイン、キーワード–このセクションのすべての設定は OR 演算子、つまり 少なくとも1つの条件が満たされると、このプロジェクトでチケットが作成されます。
• 電子メールを送信者に入力 - このオプションを選択すると、作成者の電子メールが新しいチケットに自動的に入力されます。このオプションは、受信電子メールの処理ではなく、実際のユーザーによってチケットが作成されるプロジェクトがある場合に便利です。
• キーワード–この例では、メールがで受信された場合 ANY ヘルプデスクメールボックスには文字列全体が含まれています 私はClient ABC社から来ました、 チケットはこのプロジェクトに分類されます。 他のプロジェクトで同じキーワード文字列を使用しないでください。文字列を持つデータベースの最初のレコードだけが指定されたキーワード文字列を使用します。
• メールまたはドメイン–受信メールは、メールのFROMフィールドでこれらの値についてスキャンされます。 この例では、送信者は、clientABC.comで終わるメールボックスを持つ人でも、別の電子メールを持つ特定の人でもかまいませんが、このプロジェクトで彼のチケットを並べ替えることができます。

すべてのヘルプデスクプロジェクト設定の完全な説明は、次の章でさらに続きます。

重要：1つのプロジェクトを両方のプロジェクトに設定するのはベストプラクティスではありません。 メールボックスのデフォルト 特定のメールまたはドメインに対してANDが指定されています。 送信者はこのプロジェクトでチケットを作成しますので、指定する必要はありません。 このような設定は混乱を招く可能性があります。

3.2.1クロージングとアーカイブの特別なクライアントプロジェクト

このようなプロジェクトが終了すると（事実上読み取り専用になります）、チケットを内部で作成することはできません。 したがって、このプロジェクトは特別なクライアントプロジェクトではなくなり、ヘルプデスク設定で設定されたドメインからの電子メールは不明として処理され、一般的なヘルプデスクプロジェクトに分類されます。

アーカイブされたプロジェクトにも同じことが言えます。

 

4プロジェクト構成–詳細

ヘルプデスクで使用できるプロジェクトの種類を区別したので、残りのプロジェクト設定について引き続き説明します。 プロジェクトがヘルプデスクに接続されたら、プロジェクトのヘルプデスク構成ページにアクセスする方法はXNUMXつあります。

• 管理>>ヘルプデスク>>すべてのヘルプデスクプロジェクト>>編集
• プロジェクト設定>>ヘルプデスク

4.1基本設定

設定メモ：

• タスクタイプ–このプロジェクトの新しいチケットはこのタスクタイプで作成されます
• 担当者–このプロジェクトの新しいチケットがこのユーザーに割り当てられます
• 同僚–このプロジェクトの新しいチケットには、これらの同僚が含まれます（複数選択可能）
• 自動チケット更新–ワークフローによっては、実際に解決され、開いたままになっているチケットが存在する場合があります。 このような場合、非更新のステータスと期間に応じて自動クローズを設定できます。 チケットを閉じるだけでなく、テンプレートからのフォローアップメールを自動的に送信して、送信者にチケットが閉じられたことを通知したり、チケットの解決に満足していることを尋ねたりすることができます。
• 毎月の契約時間–この設定は、クライアントが毎月一定時間のサポートを前払いしている特別なクライアントプロジェクトにのみ使用する必要があります
• 集計時間–クライアントとの契約には、未使用の時間を前月から次の月に転送するオプションがある場合があります。 クライアントが10時間のプリペイド時間を持っているが、7月中に3時間しか使用しなかった場合、XNUMX時間はXNUMX月に転送されます
• 残り時間–残り時間。 鉛筆ボタンを使用すると、残り時間を手動でクリアできます–0に設定
• 集計開始日–前払い期間が始まる日。 すべての暦月に共通の日、つまり1〜28日を選択する必要があります
• 集計期間–元の契約時間にリセットされる前に集計された時間の期間。 四半期の終わりまでにまだ13時間残っている場合（四半期の終わりは集約された開始日によって決定されます）、それらは新しい四半期に転送されません。 時間は10にリセットされます

当面の時間は、プロジェクトのエントリに費やされた時間です。 どのマニュアルがこのマニュアルでさらに説明されます。

4.2 SLA

これはヘルプデスクプロジェクトの重要な指標ですが、特にSLA違反が認められる可能性のある特別なクライアントプロジェクトにとっては重要です。 前述のように、チケットは、ヘルプデスクプロジェクトへのアクセスが特別に制限されているクライアントによって、電子メールで作成することも、システム内から直接作成することもできます。 どちらの場合も、SLA設定にわずかなニュアンスがあります。

4.2.1電子メールで生成されたチケットのSLA

設定メモ：

• 名前– SLAのタイトル（ヘルプデスクプロジェクトでのSLA管理を改善するため）
• キーワード - SLAが電子メールで生成されたチケットに設定されている場合は記入する必要があります。 この場合、Eメールの件名に含まれている場合、チケットにSLAの指定（時間、優先順位、タスクタイプ）が与えられる特定のキーワードがあります。
• 応答までの時間–チケットの最初のステータス変更が行われなければならない期限。 ステータスの変更は、チケットが確認され、クライアントに通知されたことを示します
• 解決時間–チケットを閉じる期限>>チケットを閉じた状態にする
• 優先度–キーワードを含む電子メールからの新しいチケットがこの優先度を持ちます
• タスクタイプ–キーワードを含む電子メールからの新しいチケットはこのタスクタイプになります。 これは、たとえば、クライアントが製品の欠陥を発見し、それを標準のサポート要求としてではなく、欠陥として直接報告したい場合に役立ちます。 したがって、クライアントは、たとえば件名で書き込みます 欠陥 - チケットはヘルプデスクマネージャーが分類する必要はありません。
• 稼働時間に基づいてSLAをカウントする– SLAの期限は、非稼働日または24日の時間帯には設定されません。 一部のSLAは労働時間のみに制限されている場合がありますが、他のSLAは7時間年中無休に設定できます
• SLAの稼働時間–SLAの時間枠
• 就業日–週末、休日、その他の非就業日が登録されている就業カレンダー

4.2.2SLAの順序

レベル、キーワード、キーワード文字列が増えると、順序を正しく保つことが重要になります。 メールの件名は、ヘルプデスク設定の順序に従ってキーワードがチェックされます。

例： "Critical"と "Critical bug"に対して契約上定義されたキーワードがあり、それぞれが異なるSLAを持っています。 電子メールが処理されるときに、2つの件名が区別されるようにする必要があります。

この場合、SLAの "Critical bug"を "Critical"の上に置く必要があります。 メールオブジェクト処理のメカニズムは単純です。

1. メールの件名で「致命的なバグ」を検索する
2. 上記の文字列が件名に含まれていない場合は、次の文字列を検索します。この場合は "Critical"です。
3. 上記の文字列が件名に含まれていない場合は、さらにキーワードを検索してください。
4. 最後のSLAは、すべての科目に*マークを使用した一般（指定されていないレベルの）キーワードでなければなりません

「Critical bug」の前に「Critical」を入れると、件名に「Critical bug」が含まれるEメールは「Critical」SLAに分類されるため、正しく処理されません。

一般に、より具体的なキーワード文字列は、その位置を高くする必要があります。

クライアントチケットのSLAが違反されました。 これを確実に管理するために何をしますか。 この場合、プロジェクト設定>>ヘルプデスクに移動し、一番下までスクロールします

4.2.3クローズドチケットのSLAのリセット

また、SLAセクションの上部に設定があります。

有効にすると、一度閉じられ、クライアントからの別の応答によって再開されたチケットは、チケットを再開したクライアントの応答の時点から、新しいものとしてカウントされます。
例：チケット＃1234は月曜日の16:00にオープンしました。 SLAは48時間です=>解決する時間は水曜日の16:00までです。 チケットは火曜日の10:00にオペレーターによってクローズされました。 クライアントは、火曜日の14:00に詳細情報が必要であると再度​​返信しました。 チケット＃1234には、木曜日の14:00に新しいSLAが設定されています。

無効にすると、SLAは常にチケットが作成された元の時間からカウントされます。
例：最初のケースのシナリオの場合。 火曜日のクライアントから14：00に返信された後、SLAはリセットされず、水曜日16：00のままになります。 クライアントが木曜日にチケットを再開したときも同様です。 チケットは期限切れとして強調表示されます。

最後の注意から、この設定はチケットが単純で解決が厳密に定義できるプロジェクトでのみ無効にすべきであることは明らかであるので、クライアント側からチケットを再度開く理由はありません。

4.2.4内部で作成されたチケットのSLA

前にも述べたように、チケットは電子メールだけでは作成できません。 Easy Projectには高度なアクセスレベルコントロールがあり、クライアントにシステムへの直接アクセスを制限された権限で提供することができます（チケットの作成、チケットの編集、ニュースの閲覧など）。

ログインユーザーが標準タスクのように作成したチケットでは、SLAを決定する方法が少し異なります。 処理された電子メールがないため、キーワードでSLAを判断することはできません。 下の画像で説明しましょう。

内部で作成されたチケットのSLAを作成するときは、キーワードを空白のままにしてください。 SLAは優先度とトラッカーの組み合わせによって決定されます。 設定を保存すると、キーワードは表示されなくなり、このSLAは内部的に作成されたチケットに使用されます。 Trackerを空のままにすると、キーワードのみが考慮されます。

ワークフローを効果的に構成することにより、プロジェクトにチケットがさらに含まれている場合でも、特定のタスクタイプでのみチケットを作成するようにクライアントを制限できます。 たとえば、クライアントにタスクタイプのヘルプデスクチケットとバグのみの使用を許可できるため、これらのタスクタイプにのみSLAを設定できます。 他のすべてのタスクタイプは、クライアントから送信されないため、ヘルプデスクチケットとは見なされないため、SLA設定は必要ありません。

4.2.5SLAイベントとレポート

SLAレポートは、個々のSLAイベントに基づいています。 これらのイベントは、ヘルプデスクチケットごとに表示できます。ヘルプデスクチケットの下部メニューにあるSLAイベントを確認するだけです。 チケットが応答/解決されたら、ここでそのSLAイベントを確認できます。このイベントでは、他の情報の中でも、最初の応答が行われるまでに実際に経過した時間（時間単位）がわかり、値を直接比較できます。特定のヘルプデスクプロジェクトのSLA設定に従って、SLA応答のフルフィルメント（つまり、最初の応答に必要な時間）とSLA解決のフルフィルメント（つまり、チケットの解決に必要な時間）。 それに加えて、誰がいつチケットに応答/解決したか、そしてこのチケットがどのプロジェクトに属しているかを即座に確認できます。 時間レコードは、それぞれ正または負の記号（+/-）で表示されます。 SLAがコンパイルされているかどうかを強調するために、緑色/赤色で表示されます。

SLAイベントは、以前ではなく、顧客に電子メールを送信してサポートチケットが実際に応答したときにのみ作成されます。 チケットにコメントを追加しても、そのようなコメントが単なる内部メッセージなのか顧客の要求に対する応答なのかが明確ではないため、SLAイベントの作成にはつながりません。

サポートチケットをあるプロジェクトから別のプロジェクトに移動しても、SLAイベントは再計算されません。 チケットのSLAは、そのようなチケットが作成された元のプロジェクトから残っています。 SLAの再計算は、タスクタイプまたは優先度の変更によってのみトリガーされます。

すべてのSLAイベントのリスト（概要）を表示するには、/ easy_sla_eventsに移動するか、メインのヘルプデスクダッシュボード（/ easy_helpdesk）のサイドバーメニューにある[SLAレポート]メニュー項目をクリックします。

SLAイベントは、さまざまなSLA、カスタムフィールド、またはその他の基準に従って簡単にフィルタリングできます。

全体的なSLA統計に要約されたすべてのSLAイベントは、SLAレポートダッシュボードにあります。 デフォルトでは、このダッシュボードはメインのヘルプデスクダッシュボードのトップメニューで利用できます。 ダッシュボードを使用すると、失敗したSLA応答、失敗したSLA解決、および平均初回応答の全体的な割合を即座に確認できます。 ダッシュボードは他の多くのページと同様に標準のパーソナライズされたページであるため、ダッシュボードに表示されるすべてのモジュールをカスタマイズして、ニーズに合わせて調整できます。

4.2.6チケットSLAレポート

上記に加えて、チケットの上でSLAレポートを作成することもできます。

バージョン11plus.2.0から、チケットにはXNUMXつの新しいフィールドがあります。

• 最初のSLA応答の履行 -チケットの最初のSLAイベントから取得
• 最後のSLA解決の履行 -チケットの最後のSLAイベントから取得

機能

チケットが作成されます->ヘルプデスクオペレーターが応答します-> SLAイベントが作成されます->このSLAイベントの値がチケットの前述の属性にコピーされます->クライアントが返信します->オペレーターがクライアントに応答します->新しいSLAイベントが作成されます- >チケット属性にコピーしたSLA回転フルティルメントの値。

値はどこにありますか

チケット自体には最も重要なSLAレポートデータが含まれているため、チケットのすぐ上にSLA満足度に関するレポートを作成できます。
いくつかの例：

• チケット解決の成功率
• SLA応答/解決に失敗したチケットの絶対数の折れ線グラフ

4.3カスタムヘッダーとフッター

この設定は、ヘルプデスクの電子メール通信、つまり電子メールで生成されたチケットでの通信に関係します。 さまざまなヘルプデスクプロジェクトからの電子メールを、企業IDの使用、用語の仕様、さらには機密保持の否認に合わせてカスタマイズできます。

4.4アラート

SLAが侵害されないようにするために、遅延アラートの形で問題が発生していることを関係者に通知する自動アラートを使用する可能性があります。

もう1つのタイプのAlertsは、クライアントが特定の時間数のサポートを前払いしている（4.1の章で説明されているように）プロジェクトで費やされた時間を監視します。

設定メモ：

• サポートチケットの期日を監視する–より正確には 期限 SLAによると。 有効にすると、SLA期限が近づいているときにアラートが生成されます。 以下に説明するその他の設定
• 期限内に費やされたサポートチケットを監視する–指定された前払いの月間時間のプロジェクトに費やされた時間を監視する
• 受信者を設定する必要があるアラートのリスト–これらは事前設定されたアラートであり、通知の送信先となる電子メールアドレスを入力するだけで済みます。
• 構成済みアラートのリスト–パラメーターが欠落していないアラート
• 各アラートをクリックすると、事前設定されたパラメータが編集可能になります。
• 警告/警告：通知の重大度
• サポートチケットの期限–アラートウォッチSLAが期限を解決します（チケットの締め切り）
• 応答までのサポートチケット時間–アラートはSLA応答期限を監視します（ステータスの最初の変更）
• サポートチケットのプリペイド時間–プロジェクトでのプリペイド月間時間の支出を警告します

最後のアラートで監視された時間は、プロジェクトのヘルプデスク設定に記載されているタスクタイプのチケットにログオンしている時間です。

例：プロジェクトのデフォルトのタスクタイプはヘルプデスクチケットです。 一部のSLAは、タスクタイプのバグ用に構成されています。 プロジェクトには、チケットでは使用されない他のタスクタイプ（タスク、機能開発）が含まれています。 このような場合、前払い時間はヘルプデスクチケットとバグに対してのみ有効です。 このアラートでは、他のタスクタイプに費やされた時間は考慮されません。

4.5保存/削除

更新–プロジェクトのヘルプデスク設定で行われた変更を保存します
削除–ヘルプデスクからプロジェクトを削除します。 これは、プロジェクト全体を削除することを意味するのではなく、 プロジェクトの HelpDesk への接続を削除する.

5チケット処理

これまでに説明した膨大な量の設定について説明した後、別の設定に戻る前に、実際的な意味をいくつか見てみましょう。 チケットの仕組みを説明し、いくつかの機能をスキップするための簡単な使用例から始めます。 それらについては後で説明します。

5.1電子メールで生成されたチケット

メールで作成されたチケットを正しく処理するには、標準フィールド「メールで"と"ccメール「アクティブです。チェックインできます 詳細»管理»タスクタイプ»ヘルプデスクチケット»標準フィールド。 これらの標準フィールドが欠落している場合は、管理者によって無効にされている必要があります。

5.1.1電子メールはEasyProjectによって処理され、チケットは決定されたプロジェクトで作成されます

注意：

• email to：チケットが作成されたEメールフォームの送信者
• タスクが作成されたメールボックスの指定
• SLA値–違反した場合、赤で強調表示されます
• 解析された電子メール–これは電子メールのテキストコンテンツです。 パフォーマンスが最適化されているため、画像はこのビューに直接表示されません（特に、チケットに多くの返信があり、それぞれに会社のロゴが付いた署名が含まれている場合、次のそれぞれのサイズが大きくなるため、チケットの読み込みに非常に長い時間がかかります返事）
• 添付ファイルとして利用可能な完全な電子メール–元の電子メールに画像が含まれている場合は、EasyProjectで直接表示できます。

5.1.2返信を書いて、チケットを更新します

SLAの応答を満たすには、ステータスを変更してクライアントに初めて返信する必要があります。 次の例では、チケットの通信について心を開いてください。通信が技術的にどのように機能するのかを示すためだけのものです。

マネージャは、チケットの受け取りについて顧客に返答を書き、オペレータに割り当て、ステータスを変更しました。 チェックボックスをオンにすると、返信がクライアントに送信されます（電子メール）。

テンプレートから顧客にクイックEメールを送信する

クライアントにメールを送信するには、XNUMXつのオプションがあります。 ヘルプデスクチケットを更新する場合、「テンプレートから顧客にクイックメールを送信する」オプションがあり、チケット送信者の回答のメールテンプレートを選択できます。 テンプレートを選択すると、電子メールが即座に送信されるため、これ以上のアクションは必要ありません。 テンプレートが選択されていない場合でも、通常どおり、テンプレートを選択して次のステップで電子メールの送信を確認するオプションがあります（下部の[顧客に電子メールを送信（プレビュー付き）]チェックボックスをオンにして保存します）。この目的機能は主に顧客に電子メールを送信するときの時間を節約することです。

5.1.3外部の電子メールに更新を送信する（email to）

[保存]をクリックすると、チケットに対して行われた更新が保存され、クライアントに返信を送信するダイアログが表示されます。

注意：

• メールテンプレート–メールテンプレートを設定している場合は、いずれかを選択できます。 または、ステータスに応じてテンプレートがプリセットされます。 この機能については、以降の章で説明します。
• メール送信者–これはFROMとしてクライアントに表示されます。 このフィールドの人口の設定については、以降の章で説明します。
• メールの件名–メールテンプレートに応じてカスタムまたはプリセット。 デフォルトでは、チケットの件名が入力されます
• メールの受信者–元のメールの送信者。 CCまたはTOに元の電子メールの受信者が他にいた場合は、それらもこのフィールドに追加されます。
• メールの返信–これは常に元のメールが送信されたヘルプデスクメールボックスです
• メールコピー–他の受信者を追加できます
• メール本文–テンプレートが選択されていない場合、テンプレートはチケットの最後のコメントと元の電子メールテキストで構成されます。 コンテンツは編集可能です。
• 添付ファイル–電子メールで送信する添付ファイルを選択できます。 チケットの更新時にアップロードした最近のメールまたは新しいファイルである可能性があります
• メールの送信–メールはすべての受信者に送信されます
• メールを送信しないでください–チケットの詳細に戻ります

チケットの詳細を振り返ると、SLAの応答が消えたことがわかります。

5.1.4クライアントからの返信–メールとチケットのペアリング方法

クライアントはあなたの返信を受け取り、返信します。 匿名ユーザー（システムに登録されていないユーザー）からのコメントとして返信が追加されます。

ここでクライアントの返事がどのように正しいチケットへの道を見つけたのかを説明しましょう。

前の手順で、マネージャーがクライアントに電子メールを送信したとき、電子メールには、チケットのIDを含む非表示の見出しが含まれていました（すべての電子メールと同様）。 電子メールに返信することにより、このヘッダーはクライアントの返信にも含まれていたため、ヘルプデスクはそれを識別し、同じIDでチケットに返信を追加しました。

受信したEメールをシステム内のチケットとペアにする方法はすべて次のとおりです。

1. タスクIDが保存されている電子メールの隠された見出し
2. "＃"とタスクIDの組み合わせが検索されるEメールの件名
3. これが見つからない場合は、件名だけで番号が検索されます。

したがって、クライアントがヘルプデスクのメールボックスに新しい電子メールを書き込み、件名にチケット番号（タスクID）を追加しても、ペアになります。 次の例のように。

ヘルプデスクメールボックスへの新しい電子メール：

チケットの後続のメモ：

5.1.5最終返信–チケットはクローズされます

オペレータからの最後の返信で、チケットはクローズされています。 チケットを閉じた後、解決のためのSLAもチケット詳細から消えます。

クライアントが再度応答すると、チケットは定義されたステータスに再度開かれます（この設定については後で説明します）。

5.1.6チケット所有者フィールド

チケット所有者フィールドは、ヘルプデスクチケットでの使用を目的としたオプションの標準フィールドです。 ドロップダウンリストを使用すると、作成済みのすべての内部ユーザーからXNUMX人のユーザーを選択でき、このXNUMX人のユーザーがチケットの所有者と見なされます。 このフィールドは、必要なタスクタイプに対して有効または無効にできます（[管理]»[タスクタイプ]»[ヘルプデスクチケット]»に移動し、フィールドにチェックマークを付けて保存します）。 デフォルトでは、チケット所有者フィールドは無効になっているため、ヘルプデスクマネージャは管理に移動して特定のタスクタイプに対して有効にする必要があります。 ヘルプデスクマネージャーは、ヘルプデスクチケットのこのフィールドに基づいて、チケットの所有者に応じて、受信、クローズ/解決、または更新されたチケットの数を簡単に確認できます。 したがって、これにより、ヘルプデスクの洞察（ダッシュボード、統計）とレポートが定義された期間にわたって大幅に改善/簡素化される可能性があります。 ワークフロー設定とアクションボタンは、他の標準フィールドやカスタムフィールドと同じように、チケット所有者フィールドに適用できます。

5.1.7 電子メールの宛先、CC でさまざまなデータ ソースから選択

畑で メール 〜へ & メール cc データ ソースから電子メールを検索する機能が追加されました。

• 個人連絡先（CRM）
  
• ステークホルダー
  
• アカウント（CRM）
  
• ヘルプデスク ユーザー (ヘルプ デスク)
  

この機能はデフォルトでは無効になっています。有効にするには、管理 >> プラグイン >> に移動します。 電子メールフィールドのオートコンプリート - 機能の編集とアクティブ化 電子メールフィールドのオートコンプリート そして必要なデータリソース。

データ リソースを有効にすることなく、この機能はネイティブにユーザーを検索します。

機能

有効にすると、タスク フィールドの [電子メール宛先] および [CC] がオートコンプリートとして機能します。

5.2内部で作成されたチケット

クライアントがシステム内で直接チケットを送信する場合、ワークフローは、他のタスクを操作しているかのように定義できます。 クライアントがヘルプデスクチケットまたはバグを作成できるようにします。 それらは最初はデフォルトのステータスになります（ほとんどの場合、単に新規と呼ばれます）。 次に、一連のチケット更新とによって、クライアントとオペレーターの間で通信が行き来します。 担当者を変更するこれは、すべてのユーザーがコミュニケーションをアクティブに保つために必要です。 SLAは、Eメールで生成されたチケットの場合と同様にモニターされます。応答：状況の変更。 解決：チケットを閉じます。

5.3 RESTAPIを介して作成されたチケット

REST APIを介して（たとえばWebフォームから）作成されたタスク/チケットは、電子メールから作成されたヘルプデスクチケットのように見える可能性があります。 「easy_helpdesk_mailbox_usernameたとえば、APIを介したパラメータ： issue [easy_helpdesk_mailbox_username] = 'support@company.com "。 これにより、新しく作成されたタスクは、指定された電子メールアドレスからのヘルプデスクチケットのように見え、それに応じてSLA設定が適用され、お礼のメッセージが送信者に送信されます。

 

6メールテンプレート

前の章ですでに予見されていましたが、処理の適切な説明がなければ、今ほど理解するのは簡単ではありません。 紹介していない最後のヘルプデスクメニュー項目。

電子メールテンプレートは、クライアントとのコミュニケーションを一定レベルの自動化および形式化することによって、あなたの会社を専門的に扱うものとして認識します。

メールテンプレートの重要なプロパティは メールボックスごとに設定されています。 support@mycompany.comに送信される電子メールには、メールボックスIT@mycompany.comからのテンプレートを使用することはできません。

6.1メールテンプレートの作成

メールテンプレートには、自動返信と標準テンプレートの2種類があります。 それらは異なって設定されていないので、両方のケースを一度に説明します。

6.1.1新しいテンプレートを追加する

6.1.2基本属性

設定メモ：

• メールボックスに使用–このテンプレートを使用できるメールボックス
• タスクステータス–このステータスに従って、外部メールに返信を送信するときに、テンプレートがダイアログに事前に入力されます（5.1.3章を参照）。
  • 電子メールから新しく作成されたチケットへの自動返信としてテンプレートを使用するには、ステータスを（デフォルトで設定されている）デフォルトに設定します。 管理>>タスクステータス） 実際には、電子メールからチケットが作成されると、このテンプレートに従った自動返信がすぐに送信されます。 これは、チケットが作成されたこと、および次のステップがどうなるかをクライアントに確認するために使用できます。
  • ステータスを空のままにしておくこともできます。その場合、メール送信ダイアログで自動的に事前入力されることはありませんが、ユーザーは手動で選択することができます。
• 件名–件名には何が含まれますか
• 自動返信にタスクIDを含めることをお勧めします。同じクライアントで多数のチケットがある場合、クライアントと話しているときにそれらをよりよく区別できるようになります。
• クライアントの元の電子メールを使用した実際の件名も使用できます。

6.1.3動的トークンとメール本文

動的トークンを使用して、特定のチケット情報をクライアントに提供できます。 テンプレートでは、以下のいずれかとして入力され、クライアントに送信される電子メールでは、チケットの実際の値に置き換えられます。

自動返信の簡単な例。

6.1.4重要な動的トークン

メールテンプレートを効果的に使用する予定の場合は、トークンを含める必要があります。 ％task_note％ テンプレートに。 最後にチケットに追加したコメントを使用し、それをテンプレート内の他のテキストで囲みます。

発信メールに企業署名を追加するには、トークンを使用します ％user_signature％。 ユーザーのプロファイルに設定できる現在のユーザー（チケットを更新している）のHTML署名を使用します。

例： サポートオペレータのコメント、チケットに費やした合計時間、ユーザーの会社の署名を含む簡単なテンプレートを考案しましょう。

これがテンプレートの外観です。

これは、オペレーターがコメントチケットの更新を書き込む方法です。

そして、これはテンプレートに従って送信されたEメールになります。

注： 特定のプロジェクトで特別な見出しと電子メールの脚注を付けて電子メールテンプレートを使用する場合（4.3。）、電子メールテンプレートだけでなく、電子メールテンプレートによって追加された部分だけでなく、プロジェクトヘッダーとフッターがクライアントに送信する電子メール全体をラップします。最後のコメント

6.1デフォルトのメールテンプレート

ヘルプデスクの電子メールテンプレートを次のように選択することができます デフォルト。 つまり、顧客にコメントを送信するときに、テンプレートが事前に選択される可能性が高くなります（サポートエージェントの手作業が少なくなります）。

動作は次のとおりです。

前提条件

• 1つのメールテンプレートをデフォルトとして設定できます
• すべてのメールテンプレートにはリンクされたメールボックスが必要です
• システム内により多くのメールボックスを持つことができます
• メールテンプレートは特定のステータスに接続されている場合があります（ただし、必須ではありません）

状況

• チケットは手動で作成されます（電子メールからではありません）- からのテンプレートは、ステータスに応じて事前に選択されています。 見つからない場合、デフォルトのテンプレートが事前に選択されています
• チケットは、デフォルトの電子メールテンプレートが使用されているものとは異なるメールボックスから作成されます–このメールボックスを持つテンプレートは、ステータスに基づいて事前に選択されています（現在と同じ）=> テンプレートが割り当てられていないステータスを使用している場合、テンプレートは自動的に事前選択されません
• デフォルトのテンプレートが使用されているメールボックスからチケットが作成されます–テンプレートはステータスに基づいて事前に選択されています–そのようなテンプレートが見つからない場合、デフォルトのテンプレートが事前に選択されます

SLAデータを非表示

選択したユーザータイプ（[管理] >> [ユーザータイプ] >> [編集]）について、SLA応答とタスク詳細の解決時間に関する情報を非表示にすることができます。

SLAは、特定のユーザーに対して非表示にすることもできます（[管理] >> [ユーザー] >> [編集]）。

ユーザーまたはユーザーの種類に関する設定の少なくとも1つが有効になっている場合、ユーザーにはSLAは表示されません。

ヘルプデスクメールのヘッダーとフッター

電子メール通知のグローバルに設定されたヘッダーとフッター（[管理] >> [設定] >> [電子メール通知]）は、ヘルプデスクから送信される電子メールの一部ではなくなります。

ヘルプデスクメールのヘッダーとフッターを追加するには、特定のプロジェクトのヘルプデスク設定に移動します（[プロジェクト] >> [設定] >> [ヘルプデスク]）。

データベース構成を確認する

テストをアップグレードすると、以前は正しく連携していた2つの構成での非互換性が明らかになりました。

データベースサーバーとconfig / database.ymlの両方が同じ（推奨）utf8mb4セットを持っていることを確認してください。

1）etc / my.cnf

character_set_server = utf8mb4
collat​​ion_server = utf8mb4_unicode_ci

2）config / database.yml

生産：
  アダプタ：mysql2
  データベース：簡単
  ホスト：127.0.0.1
  ユーザー名：簡単
  パスワード：「EASY_STRONG_PASSWORD」
  エンコーディング： utf8mb4

これらが揃っていない場合は、プロジェクトへのジャンプ、担当者の選択、フィルターなど、オートコンプリートフィールドを使用できません。

最後に、このコマンドを実行して、すべてのテーブルエンコーディングを正しく設定する必要があります。

YOUR_DB_NAMEのDB用。 行う
  `mysql -eのTABLEの場合" use $ {DB}; show tables; " --batch --skip-column-names | xargs`; 行う
    echo "$ {DB}。$ {TABLE}の変換"
    mysql -e "alter table $ {DB}。$ {TABLE} CONVERT TO文字セットutf8mb4 collat​​e utf8mb4_unicode_ci;"
  行われ
行われ

YOUR_DB_NAMEの代わりに、データベースの名前を入力します。

Note：正しいデータベース構成は、Webアプリケーションを完璧に実行するための一般的な要件です。 これは、この新しいバージョンのEasyProjectの特定の要件だけではありません。

カスタムデザインブレーク（CSSなし）

カスタムブランディング（ロゴ、色、背景）があり、アップグレード後に故障した場合–すべてのスタイルが欠落している、サイトが壊れているように見える、簡単に修正できます。

/ easy_theme_desingsページに移動>>デザインを見つける>>再コンパイル>>再度ロードします。 デザインを修復し、スタイルをロードします。

7グローバル設定

ユーザビリティ全体を見てきたので、残りの設定の説明を終えることができます。

設定メモ：

• 送信者–クライアントへのチケット返信でFROMとしてリストされている電子メール（第5.1.3章に関連して）
  • 現在ログに記録されているユーザー–チケットを更新しているユーザー
  • メール通知からのデフォルト–システムからユーザーに標準通知を送信するために使用されるメール。 始まる 管理>>設定>>電子メール通知
  • メールボックスアドレス–クライアントから元のメールを受信した電子メール
  • この設定は、最後のチェックボックス[カスタム送信者を許可する]とゆるく結びついています–有効にすると、プロジェクトのヘルプデスク設定で送信者としてカスタム電子メールを設定できます。 プロジェクトの設定にメールが入力されている場合、送信者の設定が上書きされます
• タスク属性の更新を有効にする–有効にすると、チケットの特定の属性を電子メールで変更できます。 たとえば、書くことによって 優先度：高 メール本文では、それに応じて優先順位を変更します。 これはかなり高度な機能であり、クライアントと一緒に使用することはお勧めできません。
• 自動生成されたメールを受け入れる–ニュースレターなど
• 受信した電子メールのCCを無視する–有効にすると、CC内の電子メールは処理されず、フィールドで使用されます。メールで"チケットの（5.1.3章。メール受信者に関する注意）
• クライアントの応答後にステータスを変更する–クライアントがチケットを更新する応答を書き込むたびに、ステータスはそれに応じて変更されます。 これは、オペレーターから返信が送信された後、チケットがクローズ状態になる場合に特に役立ちます。 クライアントが追加の質問で返信しない限り、チケットは閉じられたままになり、アクティブなリストから非表示になります。 クライアントが応答すると、チケットは再び開かれ、開いているチケットのアクティブなキューに戻ります。
• ステータスが次の場合にチケットのSLAを一時停止します–チケットはクライアントからの入力を待機しているため、SLAの期限が決定されていない場合、これらはステータスです。これがないと、オペレーターはサポートを提供できません。
• ステータスが– SLAが通常測定されている場合、チケットのSLAをカウントします。 これらの機能を使用すると、チケットサイクルを適切に設定できます。 たとえば、オペレーターはクライアントに詳細情報を要求し、ステータスを 受動的 SLAは一時停止しています。 クライアントが応答すると、ステータスはに変わります。 相談 チケットが返答されたときに、SLA期限までの残り時間に従ってSLAが再計算されます。

バージョン 12 では、ヘルプ デスクは別の興味深い指標を受け取りました - サポートによって解決されたチケット。 サポートチームを離れたことのないチケットの総数または比率を報告できます。

機能

1. まず、ヘルプ デスク >> ヘルプ デスク設定で、どのユーザーがサポートのメンバーであるかを定義する必要があります - サポートで解決 設定
   
   
   
2. サブタスク/関連タスクの設定により、サポートによって解決されたチケットにサブタスクまたは関連タスクを含めることができるかどうかが決まります
3. ここで、ヘルプ デスク メニューの [再計算] ボタンを押すことをお勧めします。
   
   これにより、過去 90 日間のチケットが評価されます
4. 最後に、タスクリストに移動してフィルターを見つけます サポートにより解決
   
   

このフィルターは、サポートのメンバーにのみ割り当てられたチケットを表示します (ポイント 1 の設定に従って)。 ポイント 2 の設定に基づいて、サブタスクまたは関連タスクを含むチケットは、サポートによって解決済みとしてカウントされる場合とカウントされない場合があります。

 

8フィルター「反応が必要」

「反応が必要」は、ヘルプデスクチケットとCRMケースの属性です。 デフォルトでは、この属性は「いいえ」に設定されています。 それに答える人にチケット/ケースが割り当てられると、「はい」に変わります。 電子メールメッセージを送信することによって で送信者に割り当てるのではなく クライアントゾーンまたはEasy Project。 そのような場合、チケット/ケースの譲受人は変更されないままであるため、意図された受信者は更新が行われたことに気付かないかもしれません。 これを防ぐには、受信者は定期的に「反応が必要」属性を「はい」に設定してすべての項目を確認し、自分に割り当てられていない場合でも確認または回答する必要があることを確認します。 またはあなたが必要なときにそれを使用することができます すでに回答した顧客チケットを「マーク」するにはまだ作業が残っています そしてあなたは後でまた顧客に知らせる必要があります。 を使用するフィルタからのタスク"モジュールでは、以下のようなホームページ、CRMの概要、またはヘルプデスクの概要にボックスを作成するだけです。

 

9人のヘルプデスクユーザー（バージョン11以降）

近年のヘルプデスクへの最大の追加の中には、いわゆるヘルプデスクユーザーがあります。 それらの目的は、EasyProjectへのクライアントアクセスの管理を簡素化することです。 また、クライアント自身がチケットを送信し、アプリケーションで直接オペレーターと通信するのがはるかに簡単になります。

9.1前提条件

ヘルプデスクユーザーの管理は許可の下にあります ヘルプデスクユーザーの表示/管理 [管理] >> [役割と権限]の[ヘルプデスク]セクションの下。

ヘルプデスクユーザーの作成を開始する前に確認するもうXNUMXつの設定は、[管理] >> [ページのカスタマイズ] >> [ヘルプデスクユーザー] >> [テンプレートの概要]です。 基本的な「スターター」構成には、既存のページテンプレートが必要です。 次のように設定されているテンプレートがあることが重要です。 デフォルト –このテンプレートは、新しいヘルプデスクユーザーに自動的に適用されます。 そうしないと、ヘルプデスクユーザーはログイン後に空のページを表示することになります。

ヘルプデスクのユーザーページには、次の3種類のモジュールが含まれています。

• 新しいチケットフォーム–設定はありません。クライアントの便宜のために配置するだけです。
• ヘルプデスクチケット–ヘルプデスクユーザーが作成したチケットのリスト。 各ユーザーは、自分で作成したチケットのみを表示できます。 このモジュールは、アプリケーション内の他のすべての「リスト」モジュールと同様に構成可能です。 チケット内のヘルプデスクユーザーに表示されるフィールドが含まれています。 ヘルプデスクユーザーにオープンチケットとクローズドチケットの両方を表示する場合は、別々のモジュールで表示することをお勧めします。
• 掲示板–カスタム情報をクライアントと共有したい場合に備えて。

9.2ヘルプデスクのユーザー管理

ヘルプデスクユーザーのリストは、ヘルプデスクダッシュボードのコントロールボタンの個別の項目として利用できます。

すべての属性が必要です：

• First Name
• 氏名
• メール=ログイン
• 言語設定
• プロジェクト–これはこのユーザーからのチケットが作成されるプロジェクトです。 ここでは、ヘルプデスクに接続されている開いているプロジェクトのみを選択できます。
• パスワード – ユーザーの作成中に、パスワード トークンを生成するオプションとともにパスワードを入力する必要があります。これにより、ユーザーは電子メール内のリンクを介して自分のパスワードを設定できます。ユーザーの編集中には、明らかにパスワードの変更は必要ありません。

追加の権限：

各ユーザーには、すべてのタスクを表示および管理するための追加の権限を付与できます。

すべてのタスクを表示 = ヘルプ デスク ユーザーが同じプロジェクトの下で作成されたすべてのチケットを表示できるようにします

すべてのタスクを管理する = ヘルプ デスク ユーザーは、すでに作成されたチケットの特定のフィールド (タイトル、説明、および新しい添付ファイルの追加も可能ですが、古い添付ファイルは編集できません) を編集できます。

使用事例

クライアントは、ヘルプ デスクにチケット用の特別なプロジェクトを持っています。このクライアントに代わってヘルプ デスク ポータルにログインし、チケットを送信するユーザーが増えています。これらのユーザーの 1 人は、提供するサービスを評価する必要があるため、送信されたすべてのチケットを確認する必要があります。

9.2.1CSVインポート

バージョン11plus.2.0から、CSV経由でヘルプデスクユーザーをインポートすることができます。 このオプションについては、コンサルタントにお問い合わせください。

9.3ヘルプデスクユーザーとしてのログイン

ヘルプデスクユーザーは、通常のユーザーとは異なるエントリポイントを介してログインします。 ログインボタンの下のログイン画面で、スイッチを見つけることができます。 クライアントをヘルプデスクログインに誘導するには、URLを使用します / HelpDesk / login. 前述のように、ログイン名として電子メールが使用されます。

重要：ヘルプデスクユーザーは、技術的には通常のユーザーから独立しています。 XNUMX人の通常ユーザーとXNUMX人のヘルプデスクユーザーに同じ電子メールを使用できます。
しかし、実践はこれが当てはまらないことを示唆しています。 ヘルプデスクユーザーアカウントを設定するか、ユーザーに完全なアカウントが必要であると判断します。 XNUMX人の両方のタイプのアカウントは、テスト目的でのみ使用する必要があります。

ログイン後、ポータル自体は管理者によって構成されたホームページで構成されますが、ヘルプデスクユーザー自身によって構成することはできません。 右上隅で、編集モードを含むプロファイルにアクセスできます。 その横にあるログアウトボタン。 既存のチケットをクリックするか、新しいチケットを作成すると、ユーザーはチケットの詳細にリダイレクトされ、そこでコメントや添付ファイルを追加できます。 ホームページに戻るには、左上隅のロゴをクリックするだけです。

ヘルプデスクユーザーには役割と権限設定がなく、特定の領域への追加アクセスを提供することはできません。 上記のリストは、彼らがアクセスできるすべてのものです。 アプリケーション内のアイテムへのリンクを送信しないでください。 それは アクセスが拒否されました メッセージ。

9.3.1ヘルプデスクユーザーのLDAP認証

バージョン11plus.2.0以降、ヘルプデスクユーザーはLDAPを介して認証できます。

構成は、[管理] >> [プラグイン] >> [ヘルプデスクユーザー] >> [編集]-[新しい認証モード]にあります。

フォームは通常のLDAP構成と同じですが、唯一の違いはヘルプデスクユーザーに適用されることです=>ページ/ helpdesk / login

9.4チケットの操作

クライアントの観点から

ヘルプデスクユーザーは、ホームページの新しいチケットフォームからチケットを作成します。 使用可能な属性は、件名、説明、および添付ファイルのみです。 哲学は、クライアントがカスタマーケアの助けを必要とするときに組織の問題について心配するべきではないということです。 彼らは単に問題を述べ、解決策を期待しています。 プロジェクトの選択、カテゴリ、カスタムフィールド、優先度の選択はありません –これらはすべてサポートチームの責任です。

チケットは、ヘルプデスクユーザーに直接設定されるプロジェクトで作成されます。 分野 メールで送信 チケットには、ヘルプデスクユーザーの電子メールで記入されています。 このユーザーも次のように設定されます ヘルプデスクの作成者 隠された属性であるチケットの 著者これは Easy Project のすべてのタスクの一般的な属性です)。これにより、チケットを次の場所に移動した場合でも、常にチケットが表示されるようになります。

 

コーナー状況

• タスク担当者がプロジェクトのメンバーではない状況は、次の場合に発生する可能性があります。
  • 担当者はプロジェクトから削除されましたが、タスクは引き続き担当者に割り当てられています。
  • 自動チケット更新プロセスは、一部のチケットが以前のプロジェクトメンバーに自動的に割り当てられるように、ヘルプデスクモジュール内で設定されます。
• SLA応答に関する情報がタスクの詳細に表示されるのは、タスクがそれぞれのトラッカーで定義されているデフォルトのステータスにある場合のみです。
• チケットが SLA を一時停止している場合は、チケットの優先度を変更しないことを強くお勧めします。そのようなアクションは、そのチケットの SLA の正しい計算に悪影響を与えるためです。