機能別ガイド／ NinjaOne Ticketing

NinjaOne Ticketingの概要とチケットの構成

NinjaOneで問い合わせを記録として管理する機能を説明します。デバイス情報との連携による利点、チケットの構成要素、5つの起票経路、導入前に決めておく項目を解説します。

問い合わせや作業を記録として管理する機能です。デバイス情報と紐づく点が、汎用のヘルプデスクツールとの大きな違いになります。

NinjaOne Ticketingの位置付け

チケットは、対応の記録を残すための単位です。誰が何を依頼し、誰がどう対応し、いつ完了したかを追跡します。

NinjaOneに組み込まれていることの利点は、デバイス情報との連携です。

別のツールを使っている場合、デバイスの状態を確認するために画面を行き来することになります。この往復がなくなる点が実務上の価値です。

チケットは複数の属性を持ちます。

PriorityとSeverityは別の概念です。深刻度は事象そのものの重大さ、優先度は対応の順序を示します。深刻でも急がない案件、軽微でも急ぐ案件が存在するため、分けて管理します。

一般的な流れは次の通りです。

各段階をStatusで表します。どのような状態を用意するかは設計次第です。詳細はBoard・ステータス・SLAの設定で扱います。

チケットが作られる経路は複数あります。

4番目が、NinjaOneならではの経路です。デバイスの異常を検知した時点でチケットが作られるため、利用者からの連絡を待たずに対応を始められます。設定方法はConditionの基本と種類を参照してください。

チケットには対象のデバイスとOrganizationを紐づけられます。

紐づけておくと、次のことができます。

問い合わせ対応では、まず過去の履歴を確認する習慣を付けてください。同じデバイスで繰り返し同じ問題が起きている場合、個別対応ではなく根本原因の解決が必要です。

設定を始める前に、次の5点を決めてください。

3番目を曖昧にすると、全てのチケットが高優先度になります。「業務が止まっているか」「代替手段があるか」といった具体的な基準を決めてください。

【運用のポイント】既に別のツールで問い合わせ管理をしている場合、いきなり全面移行しないでください。まずConditionからの自動起票だけをNinjaOne Ticketingで運用し、効果を確認してから範囲を広げる方が定着します。