ネットワークヘルプデスク

ネットワークヘルプデスク

ネットワークヘルプデスクのロゴ
略語	国立
初版	2011年6月
最新バージョン	1.0 [1]
組織	ゼンデスク
基本基準	HTTP、JSON、REST [1]
関連規格	JSR 91: OSSトラブルチケットAPI [2]
ドメイン	問題追跡、バグ追跡、顧客関係管理、プロジェクト管理。[1]
Webサイト	ヘルプデスク

ネットワークヘルプデスクは、問題追跡、バグ追跡、顧客関係管理（CRM）、プロジェクト管理システムの個別のインスタンス間で顧客サポートチケットを共有するための共通APIを提供し、顧客サービスを向上させ、ベンダーロックインを減らすためのオープンスタンダードイニシアチブです。[ 3 ^{] [4]}このイニシアチブは、2011年6月にZendeskによって、 Atlassian、New Relic、OTRS、Pivo​​tal Tracker、ServiceNow、SugarCRMを含む他の8つの創設メンバー組織と共同で作成されました。^{[5] [6] ZendeskとAtlassianの問題追跡製品である}Jiraの最初の統合^[5]は、2011年のAtlassian Summitで発表されました。^[7] 2011年8月までに、34のメンバー企業がイニシアチブに参加しました。^[8]開始から1年後、50を超える組織が参加しました。^{[9] Zendeskインスタンス内では、この機能は}チケット共有としてブランド化されています。^{[10] [11] [12]}

サポート ツールは、一般的に、顧客がリクエストやインシデントレポートを行うことから始まる共通のパラダイムに基づいて構築されます。これらによってチケットが作成されます。各チケットには進行状況があり、注釈や添付ファイルで更新されます。これらの注釈や添付ファイルは、顧客に表示される場合 (パブリック) と、アナリストのみに表示される場合があります (プライベート)。チケットが完了するまで、チケットの進行状況が顧客に通知されます。チケットを完了するために必要な人が別々のサポート ツールを使用している場合、各ツールでチケットの関連情報を維持しながら、各グループがチケットを完了する進行状況を顧客に通知するために、追加のオーバーヘッドが発生します。たとえば、顧客サポートの問題がソフトウェア バグによって発生し、あるシステムを使用してヘルプ デスクに報告され、その後、開発者が別のシステムで修正を文書化し、顧客関係管理ツールで分析する場合、各システムの記録を最新の状態に保ち、回転椅子方式で手動で顧客に通知することは、不必要に時間がかかり、エラーが発生しやすくなります。情報が正しく転送されない場合、チケットが転送されるたびに、顧客は問題を再度説明しなければならない場合があります。^{[13] [14]}

ネットワークヘルプデスクAPIが実装されているシステムでは、顧客のサポート体験に関連する複数の異なるアプリケーションが、一意に識別される1つの共有チケットでデータを同期することができます。^[15]これらのドメインの多くのアプリケーションは、データのインポート、エクスポート、変更を可能にするAPIを実装していますが、ネットワークヘルプデスクは、複数のシステム間で顧客サポート情報を自動的に同期するための共通標準を提供します。^[13]実装されると、2つのシステムは両方とも同じインターフェイスを理解するため、構成を変更するだけですぐにチケットを共有できます。^[16]

特定のチケットに関する 2 つのインスタンス間の通信は、招待の合意、チケット データの共有、チケットの継続的な同期という 3 つのステップで行われます。^[16]この標準では、「完全な委任」(両方のシステムのアナリストがそれぞれ公開コメントと非公開コメントを作成し、ステータスを同期する) と、チケットを受信したインスタンスが非公開コメントのみを作成でき、ステータスの変更は同期されない「部分的な委任」が許可されています。^{[10] [17]}チケットは複数のインスタンスで共有できます。^[11]

• 問題追跡システムの比較
• エンタープライズアプリケーション統合
• エンタープライズ サービス バス
• JavaによるOSS
• Web指向アーキテクチャ

• Vaughan, Stafford、de Young, Anton (2014-03-15)。「第 5 章: チケットの共有」。実践的な Zendesk 管理。O'Reilly Media。ISBN 978-1491900772. OCLC  882259856.

• Twitterのネットワーク ヘルプデスク
• ProgrammableWebのネットワーク ヘルプ デスク